Re: [PATCH v5 4/8] drm/cma-helper: Use the generic fbdev emulation
On Thu, Aug 23, 2018 at 6:14 AM, John Stultz wrote: > On Mon, Aug 20, 2018 at 11:44 PM, John Stultz wrote: >> Hey Noralf, all, >> I've been digging for a bit on the regression that this patch has >> tripped on the HiKey board as reported here: >> https://lkml.org/lkml/2018/8/16/81 >> >> The first issue was that the kirin driver was setting >> mode_config.max_width/height = 2048, which was causing errors as the >> the requested resolution was 1920x2160 (due to surfaceflinger >> requesting y*2 for page flipping). > > Hey Noralf, > Sorry, I know your probably sick of me. But I just wanted to circle > around on this little bit. So part of the issue I found earlier, was > that I'm running w/ CONFIG_DRM_FBDEV_OVERALLOC=200, to support > Surfaceflinger's request for page flipping. This is what makes the Y > resolution 2160, which runs afoul of the new max_height check of 2048 > in the generic code. > > I was checking with Xinliang, who know the kirin display hardware, > about the max_height being set to 2048 to ensure bumping it up wasn't > a problem, but he said 2048x2048 was unfortunately not arbitrary, and > that was the hard limit of the display hardware. However, with > overalloc, the 1920x2160 res fbdev should still be ok, as only > 1920x1080 is actually displayed at one time. > > So it seems like we might need to multiply the max_height by the > overalloc factor when we are checking it in > drm_internal_framebuffer_create? > > Does that approach sound sane, or would folks prefer something different? I guess we could simply not check against the height limit when allocating framebuffers. But we've done that for userspace buffers since forever (they just allocate 2 buffers for page-flipping), so I have no idea what would all break if we'd suddenly lift this restriction. And whether we'd lift it for fbdev only or for everyone doesn't really make much of a difference, since either this works, or it doesn't (across all chips). -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [RFC v4 7/8] drm/i915: Implement Plane Gamma for Bdw and Gen9 platforms
>-Original Message-
>From: Alexandru-Cosmin Gheorghe [mailto:Alexandru-
>cosmin.gheor...@arm.com]
>Sent: Tuesday, August 21, 2018 3:26 PM
>To: Shankar, Uma
>Cc: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
>dcasta...@chromium.org; emil.l.veli...@gmail.com; seanp...@chromium.org;
>Syrjala, Ville ; Lankhorst, Maarten
>; n...@arm.com
>Subject: Re: [RFC v4 7/8] drm/i915: Implement Plane Gamma for Bdw and Gen9
>platforms
>
>Hi Uma,
>
>On Fri, Aug 17, 2018 at 07:48:50PM +0530, Uma Shankar wrote:
>> Implement Plane Gamma feature for BDW and Gen9 platforms.
>>
>> v2: Used newly added drm_color_lut_ext structure for enhanced
>> precision for Gamma LUT entries.
>>
>> v3: Rebase
>>
>> Signed-off-by: Uma Shankar
>> ---
>> drivers/gpu/drm/i915/i915_pci.c | 5 +++-
>> drivers/gpu/drm/i915/i915_reg.h | 25
>> drivers/gpu/drm/i915/intel_color.c | 58
>
>> drivers/gpu/drm/i915/intel_display.c | 4 +++
>> drivers/gpu/drm/i915/intel_sprite.c | 4 +++
>> 5 files changed, 95 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_pci.c
>> b/drivers/gpu/drm/i915/i915_pci.c index e931b48..40de78c 100644
>> --- a/drivers/gpu/drm/i915/i915_pci.c
>> +++ b/drivers/gpu/drm/i915/i915_pci.c
>> @@ -54,7 +54,10 @@
>> .cursor_offsets = { CURSOR_A_OFFSET, IVB_CURSOR_B_OFFSET,
>> IVB_CURSOR_C_OFFSET }
>>
>> #define BDW_COLORS \
>> -.color = { .degamma_lut_size = 512, .gamma_lut_size = 512 }
>> +.color = { .degamma_lut_size = 512, .gamma_lut_size = 512 }, \
>> +.plane_color = { .plane_degamma_lut_size = 0, \
>> + .plane_gamma_lut_size = 16 }
>> +
>> #define CHV_COLORS \
>> .color = { .degamma_lut_size = 65, .gamma_lut_size = 257 } #define
>> GLK_COLORS \ diff --git a/drivers/gpu/drm/i915/i915_reg.h
>> b/drivers/gpu/drm/i915/i915_reg.h index 0c9f03d..2db6a84 100644
>> --- a/drivers/gpu/drm/i915/i915_reg.h
>> +++ b/drivers/gpu/drm/i915/i915_reg.h
>> @@ -172,6 +172,10 @@ static inline bool i915_mmio_reg_valid(i915_reg_t
>> reg) #define _PHY3(phy, ...) _PICK(phy, __VA_ARGS__) #define
>> _MMIO_PHY3(phy, a, b, c) _MMIO(_PHY3(phy, a, b, c))
>>
>> +/* Plane Gamma Registers */
>> +#define _MMIO_PLANE_GAMC(plane, i, a, b) _MMIO(_PIPE(plane, a, b) +
>> +(i) * 4) #define _MMIO_PLANE_GAMC16(plane, i, a, b)
>> +_MMIO(_PIPE(plane, a, b) + (i) * 4)
>> +
>> #define __MASKED_FIELD(mask, value) ((mask) << 16 | (value))
>> #define _MASKED_FIELD(mask, value) ({
> \
>> if (__builtin_constant_p(mask))\
>> @@ -9713,6 +9717,27 @@ enum skl_power_gate {
>> #define PRE_CSC_GAMC_INDEX(pipe)_MMIO_PIPE(pipe,
>_PRE_CSC_GAMC_INDEX_A, _PRE_CSC_GAMC_INDEX_B)
>> #define PRE_CSC_GAMC_DATA(pipe) _MMIO_PIPE(pipe,
>_PRE_CSC_GAMC_DATA_A, _PRE_CSC_GAMC_DATA_B)
>>
>> +/* Plane Gamma in Gen9+ */
>> +#define _PLANE_GAMC_1_A 0x701d0
>> +#define _PLANE_GAMC_1_B 0x711d0
>> +#define _PLANE_GAMC_2_A 0x702d0
>> +#define _PLANE_GAMC_2_B 0x712d0
>> +#define _PLANE_GAMC_1(pipe) _PIPE(pipe, _PLANE_GAMC_1_A,
>_PLANE_GAMC_1_B)
>> +#define _PLANE_GAMC_2(pipe) _PIPE(pipe, _PLANE_GAMC_2_A,
>_PLANE_GAMC_2_B)
>> +#define PLANE_GAMC(pipe, plane, i) \
>> +_MMIO_PLANE_GAMC(plane, i, _PLANE_GAMC_1(pipe),
>_PLANE_GAMC_2(pipe))
>> +
>> +#define _PLANE_GAMC16_1_A 0x70210
>> +#define _PLANE_GAMC16_1_B 0x71210
>> +#define _PLANE_GAMC16_2_A 0x70310
>> +#define _PLANE_GAMC16_2_B 0x71310
>> +#define _PLANE_GAMC16_1(pipe) _PIPE(pipe, _PLANE_GAMC16_1_A, \
>> + _PLANE_GAMC16_1_B)
>> +#define _PLANE_GAMC16_2(pipe) _PIPE(pipe, _PLANE_GAMC16_2_A, \
>> + _PLANE_GAMC16_2_B)
>> +#define PLANE_GAMC16(pipe, plane, i) _MMIO_PLANE_GAMC16(plane, i, \
>> +_PLANE_GAMC16_1(pipe),
>_PLANE_GAMC16_2(pipe))
>> +
>> /* pipe CSC & degamma/gamma LUTs on CHV */
>> #define _CGM_PIPE_A_CSC_COEFF01 (VLV_DISPLAY_BASE + 0x67900)
>> #define _CGM_PIPE_A_CSC_COEFF23 (VLV_DISPLAY_BASE + 0x67904)
>> diff --git a/drivers/gpu/drm/i915/intel_color.c
>> b/drivers/gpu/drm/i915/intel_color.c
>> index fb8402f..2b5c0cd 100644
>> --- a/drivers/gpu/drm/i915/intel_color.c
>> +++ b/drivers/gpu/drm/i915/intel_color.c
>> @@ -492,6 +492,59 @@ static void broadwell_load_luts(struct drm_crtc_state
>*state)
>> I915_WRITE(PREC_PAL_INDEX(pipe), 0); }
>>
>> +static void bdw_load_plane_gamma_lut(const struct drm_plane_state *state,
>> + u32 offset)
>> +{
>> +struct drm_i915_private *dev_priv = to_i915(state->plane->dev);
>> +enum pipe pipe = to_intel_plane(state->plane)->pipe;
>> +enum plane_id plane = to_intel_plane(state->plane)->id;
>> +uint32_t i, lut_size =
>> +INTEL_INFO(dev_priv)-
>>plane_color.plane_gamma_lut_size;
>> +
>> +if (state->gamma_lut) {
>> +struct drm_color_lut_ext *lut =
>> +
RE: [RFC v4 1/8] drm: Add Enhanced Gamma LUT precision structure
>-Original Message-
>From: Alexandru-Cosmin Gheorghe [mailto:Alexandru-
>cosmin.gheor...@arm.com]
>Sent: Tuesday, August 21, 2018 3:00 PM
>To: Shankar, Uma
>Cc: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
>dcasta...@chromium.org; emil.l.veli...@gmail.com; seanp...@chromium.org;
>Syrjala, Ville ; Lankhorst, Maarten
>; n...@arm.com
>Subject: Re: [RFC v4 1/8] drm: Add Enhanced Gamma LUT precision structure
>
>Hi Uma,
>
>On Fri, Aug 17, 2018 at 07:48:44PM +0530, Uma Shankar wrote:
>> Existing LUT precision structure is having only 16 bit precision. This
>> is not enough for upcoming enhanced hardwares and advance usecases
>> like HDR processing. Hence added a new structure with 32 bit precision
>> values. Also added the code, for extracting the same from values
>> passed from userspace.
>>
>> v4: Rebase
>>
>> Signed-off-by: Uma Shankar
>> ---
>> drivers/gpu/drm/drm_plane.c | 19 +++
>> include/uapi/drm/drm_mode.h | 15 +++
>> 2 files changed, 34 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
>> index 6153cbd..cd71fd0 100644
>> --- a/drivers/gpu/drm/drm_plane.c
>> +++ b/drivers/gpu/drm/drm_plane.c
>> @@ -430,6 +430,25 @@ void drm_plane_force_disable(struct drm_plane
>> *plane) } EXPORT_SYMBOL(drm_plane_force_disable);
>>
>> +/*
>> + * Added to accommodate enhanced LUT precision.
>> + * Max LUT precision is 32 bits.
>> + */
>> +uint32_t drm_color_lut_extract_ext(uint32_t user_input, uint32_t
>> +bit_precision)
>
>You should declare this function in a header file as well.
Thanks Alexandru for the review. Sure, will fix that and resend.
>With that fixed
>Reviewed-by: Alexandru Gheorghe
>
>
>> +{
>> +uint32_t val = user_input;
>> +uint32_t max = 0x >> (32 - bit_precision);
>> +
>> +/* Round only if we're not using full precision. */
>> +if (bit_precision < 32) {
>> +val += 1UL << (32 - bit_precision - 1);
>> +val >>= 32 - bit_precision;
>> +}
>> +
>> +return clamp_val(val, 0, max);
>> +}
>> +EXPORT_SYMBOL(drm_color_lut_extract_ext);
>> +
>> /**
>> * drm_mode_plane_set_obj_prop - set the value of a property
>> * @plane: drm plane object to set property value for diff --git
>> a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h index
>> 8d67243..874407b 100644
>> --- a/include/uapi/drm/drm_mode.h
>> +++ b/include/uapi/drm/drm_mode.h
>> @@ -629,6 +629,21 @@ struct drm_color_lut {
>> __u16 reserved;
>> };
>>
>> +/*
>> + * Creating 32 bit palette entries for better data
>> + * precision. This will be required for HDR and
>> + * similar color processing usecases.
>> + */
>> +struct drm_color_lut_ext {
>> +/*
>> + * Data is U0.32 fixed point format.
>> + */
>> +__u32 red;
>> +__u32 green;
>> +__u32 blue;
>> +__u32 reserved;
>> +};
>> +
>> #define DRM_MODE_PAGE_FLIP_EVENT 0x01 #define
>> DRM_MODE_PAGE_FLIP_ASYNC 0x02 #define
>> DRM_MODE_PAGE_FLIP_TARGET_ABSOLUTE 0x4
>> --
>> 1.9.1
>>
>> ___
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>--
>Cheers,
>Alex G
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [Intel-gfx] [RFC v4 3/8] drm: Add Plane CTM property
>-Original Message-
>From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
>Sent: Wednesday, August 22, 2018 6:36 PM
>To: Brian Starkey
>Cc: Lankhorst, Maarten ;
>dcasta...@chromium.org; intel-...@lists.freedesktop.org; dri-
>de...@lists.freedesktop.org; Shankar, Uma ;
>seanp...@chromium.org; Syrjala, Ville
>Subject: Re: [Intel-gfx] [RFC v4 3/8] drm: Add Plane CTM property
>
>On Wed, Aug 22, 2018 at 12:11:42PM +0100, Brian Starkey wrote:
>> Hi,
>>
>> On Wed, Aug 22, 2018 at 12:53:58PM +0300, Ville Syrjälä wrote:
>> >On Wed, Aug 22, 2018 at 08:40:19AM +, Lankhorst, Maarten wrote:
>> >> fre 2018-08-17 klockan 19:48 +0530 skrev Uma Shankar:
>> >> > Add a blob property for plane CSC usage.
>> >> >
>> >> > v2: Rebase
>> >> >
>> >> > v3: Fixed Sean, Paul's review comments. Moved the property from
>> >> > mode_config to drm_plane. Created a helper function to
>> >> > instantiate these properties and removed from
>> >> > drm_mode_create_standard_properties
>> >> > Added property documentation as suggested by Daniel, Vetter.
>> >> >
>> >> > v4: Rebase
>> >> >
>> >> > Signed-off-by: Uma Shankar
>> >> > ---
>> >> > Documentation/gpu/drm-kms.rst | 3 +++
>> >> > drivers/gpu/drm/drm_atomic.c| 10 ++
>> >> > drivers/gpu/drm/drm_atomic_helper.c | 4
>> >> > drivers/gpu/drm/drm_plane.c | 12
>> >> > include/drm/drm_plane.h | 15 +++
>> >> > 5 files changed, 44 insertions(+)
>> >> >
>> >> > diff --git a/Documentation/gpu/drm-kms.rst
>> >> > b/Documentation/gpu/drm- kms.rst index 8b10b12..16d6d8d 100644
>> >> > --- a/Documentation/gpu/drm-kms.rst
>> >> > +++ b/Documentation/gpu/drm-kms.rst
>> >> > @@ -560,6 +560,9 @@ Plane Color Management Properties ..
>> >> > kernel-doc:: drivers/gpu/drm/drm_plane.c
>> >> > :doc: degamma_lut_size_property
>> >> >
>> >> > +.. kernel-doc:: drivers/gpu/drm/drm_plane.c
>> >> > + :doc: ctm_property
>> >> > +
>> >> > Tile Group Property
>> >> > ---
>> >> >
>> >> > diff --git a/drivers/gpu/drm/drm_atomic.c
>> >> > b/drivers/gpu/drm/drm_atomic.c index f8cad9b..ddda935 100644
>> >> > --- a/drivers/gpu/drm/drm_atomic.c
>> >> > +++ b/drivers/gpu/drm/drm_atomic.c
>> >> > @@ -917,6 +917,14 @@ static int
>> >> > drm_atomic_plane_set_property(struct
>> >> > drm_plane *plane,
>> >> > );
>> >> > state->color_mgmt_changed |= replaced;
>> >> > return ret;
>> >> > + } else if (property == plane->ctm_property) {
>> >> > + ret = drm_atomic_replace_property_blob_from_id(dev,
>> >> > + >ctm,
>> >> > + val,
>> >> > + sizeof(struct
>> >> > drm_color_ctm), -1,
>> >> > + );
>> >> > + state->color_mgmt_changed |= replaced;
>> >> > + return ret;
>> >> > } else if (plane->funcs->atomic_set_property) {
>> >> > return plane->funcs->atomic_set_property(plane,
>> >> > state,
>> >> > property, val);
>> >> > @@ -988,6 +996,8 @@ static int
>> >> > drm_atomic_plane_set_property(struct
>> >> > drm_plane *plane,
>> >> > } else if (property == plane->degamma_lut_property) {
>> >> > *val = (state->degamma_lut) ?
>> >> > state->degamma_lut->base.id : 0;
>> >> > + } else if (property == plane->ctm_property) {
>> >> > + *val = (state->ctm) ? state->ctm->base.id : 0;
>> >> > } else if (plane->funcs->atomic_get_property) {
>> >> > return plane->funcs->atomic_get_property(plane,
>> >> > state, property, val);
>> >> > } else {
>> >> > diff --git a/drivers/gpu/drm/drm_atomic_helper.c
>> >> > b/drivers/gpu/drm/drm_atomic_helper.c
>> >> > index 67c5b51..866181f 100644
>> >> > --- a/drivers/gpu/drm/drm_atomic_helper.c
>> >> > +++ b/drivers/gpu/drm/drm_atomic_helper.c
>> >> > @@ -3616,6 +3616,9 @@ void
>> >> > __drm_atomic_helper_plane_duplicate_state(struct drm_plane
>> >> > *plane,
>> >> >
>> >> > if (state->degamma_lut)
>> >> > drm_property_blob_get(state->degamma_lut);
>> >> > + if (state->ctm)
>> >> > + drm_property_blob_get(state->ctm);
>> >> > +
>> >> > state->color_mgmt_changed = false; }
>> >> > EXPORT_SYMBOL(__drm_atomic_helper_plane_duplicate_state);
>> >> > @@ -3663,6 +3666,7 @@ void
>> >> > __drm_atomic_helper_plane_destroy_state(struct drm_plane_state
>> >> > *state)
>> >> > drm_crtc_commit_put(state->commit);
>> >> >
>> >> > drm_property_blob_put(state->degamma_lut);
>> >> > + drm_property_blob_put(state->ctm);
>> >> > }
>> >> > EXPORT_SYMBOL(__drm_atomic_helper_plane_destroy_state);
>> >> >
>> >> > diff --git a/drivers/gpu/drm/drm_plane.c
>> >> > b/drivers/gpu/drm/drm_plane.c index 03e0560..97520b1
Re: [PATCH v5 4/8] drm/cma-helper: Use the generic fbdev emulation
On Mon, Aug 20, 2018 at 11:44 PM, John Stultz wrote: > Hey Noralf, all, > I've been digging for a bit on the regression that this patch has > tripped on the HiKey board as reported here: > https://lkml.org/lkml/2018/8/16/81 > > The first issue was that the kirin driver was setting > mode_config.max_width/height = 2048, which was causing errors as the > the requested resolution was 1920x2160 (due to surfaceflinger > requesting y*2 for page flipping). Hey Noralf, Sorry, I know your probably sick of me. But I just wanted to circle around on this little bit. So part of the issue I found earlier, was that I'm running w/ CONFIG_DRM_FBDEV_OVERALLOC=200, to support Surfaceflinger's request for page flipping. This is what makes the Y resolution 2160, which runs afoul of the new max_height check of 2048 in the generic code. I was checking with Xinliang, who know the kirin display hardware, about the max_height being set to 2048 to ensure bumping it up wasn't a problem, but he said 2048x2048 was unfortunately not arbitrary, and that was the hard limit of the display hardware. However, with overalloc, the 1920x2160 res fbdev should still be ok, as only 1920x1080 is actually displayed at one time. So it seems like we might need to multiply the max_height by the overalloc factor when we are checking it in drm_internal_framebuffer_create? Does that approach sound sane, or would folks prefer something different? thanks -john ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 4/5] drm/amdgpu: use bulk moves for efficient VM LRU handling (v6)
On 08/22/2018 06:12 PM, Huang Rui wrote:
I continue to work for bulk moving that based on the proposal by Christian.
Background:
amdgpu driver will move all PD/PT and PerVM BOs into idle list. Then move all of
them on the end of LRU list one by one. Thus, that cause so many BOs moved to
the end of the LRU, and impact performance seriously.
Then Christian provided a workaround to not move PD/PT BOs on LRU with below
patch:
Commit 0bbf32026cf5ba41e9922b30e26e1bed1ecd38ae ("drm/amdgpu: band aid
validating VM PTs")
However, the final solution should bulk move all PD/PT and PerVM BOs on the LRU
instead of one by one.
Whenever amdgpu_vm_validate_pt_bos() is called and we have BOs which need to be
validated we move all BOs together to the end of the LRU without dropping the
lock for the LRU.
While doing so we note the beginning and end of this block in the LRU list.
Now when amdgpu_vm_validate_pt_bos() is called and we don't have anything to do,
we don't move every BO one by one, but instead cut the LRU list into pieces so
that we bulk move everything to the end in just one operation.
Test data:
+--+-+---+---+
| |The Talos|Clpeak(OCL)|BusSpeedReadback(OCL)
|
| |Principle(Vulkan)| |
|
++
| | | |0.319 ms(1k) 0.314 ms(2K) 0.308
ms(4K) |
| Original | 147.7 FPS | 76.86 us |0.307 ms(8K) 0.310 ms(16K)
|
++
| Orignial + WA| | |0.254 ms(1K) 0.241 ms(2K)
|
|(don't move | 162.1 FPS | 42.15 us |0.230 ms(4K) 0.223 ms(8K) 0.204
ms(16K)|
|PT BOs on LRU)| | |
|
++
| Bulk move| 163.1 FPS | 40.52 us |0.244 ms(1K) 0.252 ms(2K) 0.213
ms(4K) |
| | | |0.214 ms(8K) 0.225 ms(16K)
|
+--+-+---+---+
After test them with above three benchmarks include vulkan and opencl. We can
see the visible improvement than original, and even better than original with
workaround.
v2: move all BOs include idle, relocated, and moved list to the end of LRU and
put them together.
v3: remove unused parameter and use list_for_each_entry instead of the one with
save entry.
v4: move the amdgpu_vm_move_to_lru_tail after command submission, at that time,
all bo will be back on idle list.
v5: remove amdgpu_vm_move_to_lru_tail_by_list(), use bulk_moveable instread of
validated, and move ttm_bo_bulk_move_lru_tail() also into
amdgpu_vm_move_to_lru_tail().
v6: clean up and fix return value.
Signed-off-by: Christian König
Signed-off-by: Huang Rui
Tested-by: Mike Lothian
Tested-by: Dieter Nützel
Acked-by: Chunming Zhou
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 3 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 64 +++---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h | 11 +-
3 files changed, 57 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index 502b94f..8a5e557 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -1266,6 +1266,7 @@ int amdgpu_cs_ioctl(struct drm_device *dev, void *data,
struct drm_file *filp)
union drm_amdgpu_cs *cs = data;
struct amdgpu_cs_parser parser = {};
bool reserved_buffers = false;
+ struct amdgpu_fpriv *fpriv;
int i, r;
if (!adev->accel_working)
@@ -1310,6 +1311,8 @@ int amdgpu_cs_ioctl(struct drm_device *dev, void *data,
struct drm_file *filp)
r = amdgpu_cs_submit(, cs);
+ fpriv = filp->driver_priv;
A trivial thing is that could be assigned in definition.
anyway, it's
Reviewed-by: Junwei Zhang
+ amdgpu_vm_move_to_lru_tail(adev, >vm);
out:
amdgpu_cs_parser_fini(, r, reserved_buffers);
return r;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index 9c84770..daae0fd 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -268,6 +268,47 @@ void amdgpu_vm_get_pd_bo(struct amdgpu_vm *vm,
}
/**
+ * amdgpu_vm_move_to_lru_tail - move all BOs to the end of LRU
+ *
+ * @adev: amdgpu device pointer
+ * @vm: vm providing the BOs
+ *
+ * Move all BOs to the end of LRU and remember their positions to put them
+ * together.
+ */
+void amdgpu_vm_move_to_lru_tail(struct amdgpu_device *adev,
+ struct amdgpu_vm *vm)
+{
+ struct ttm_bo_global
[Bug 107572] Unrecoverable GPU hang with IP block:gfx_v8_0 is hung
https://bugs.freedesktop.org/show_bug.cgi?id=107572 --- Comment #16 from Andrew Cook --- https://github.com/ValveSoftware/Proton/blob/proton_3.7/PREREQS.md#directx-11-games Suggests using llvm 7 to avoid gpu hangs, is someone able to test that? In addition, is it expected for userspace to be capable of hanging the gpu? Really seems like something the kernel should prevent -- 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 1/3] drm/nouveau: Fix potential memory leak in nouveau_drm_load()
We forget to free drm in all instances of failure, and additionally also forget to destroy the master client if the other client fails initialization. Signed-off-by: Lyude Paul Cc: Karol Herbst --- drivers/gpu/drm/nouveau/nouveau_drm.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c b/drivers/gpu/drm/nouveau/nouveau_drm.c index 5fdc1fbe2ee5..6c88ff776ff6 100644 --- a/drivers/gpu/drm/nouveau/nouveau_drm.c +++ b/drivers/gpu/drm/nouveau/nouveau_drm.c @@ -538,11 +538,11 @@ nouveau_drm_load(struct drm_device *dev, unsigned long flags) ret = nouveau_cli_init(drm, "DRM-master", >master); if (ret) - return ret; + goto fail_alloc; ret = nouveau_cli_init(drm, "DRM", >client); if (ret) - return ret; + goto fail_master; dev->irq_enabled = true; @@ -607,7 +607,9 @@ nouveau_drm_load(struct drm_device *dev, unsigned long flags) fail_ttm: nouveau_vga_fini(drm); nouveau_cli_fini(>client); +fail_master: nouveau_cli_fini(>master); +fail_alloc: kfree(drm); return ret; } -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/3] drm/nouveau: Shut down GPU on kernel shutdown
A little while ago I sent some patches to try to fix issues with initializing the GM107 GPU with nouveau on the ThinkPad P50. The issues I was witnessing were rather bizarre: seemingly at random, initializing the GPU would fail with failed mthds from disp that nouveau had not actually kicked through the evo channel yet. Example: [1.603467] nouveau :01:00.0: disp: outp 02:0006:0f48: aux power -> demand [1.603931] nouveau :01:00.0: disp: outp 03:0002:0f48: no heads (0 3 2) [1.604375] nouveau :01:00.0: disp: outp 04:0006:0f81: no heads (0 3 4) [1.604858] nouveau :01:00.0: disp: outp 04:0006:0f81: aux power -> always [1.605354] nouveau :01:00.0: disp: outp 04:0006:0f81: aux power -> demand [1.605815] nouveau :01:00.0: disp: outp 05:0002:0f81: no heads (0 3 2) --->[1.607289] nouveau :01:00.0: disp: chid 0 mthd data 0400 1000 0002 --->[1.608818] nouveau :01:00.0: disp: chid 1 mthd data 0400 1000 0002 --->[1.609500] nouveau :01:00.0: disp: chid 2 mthd data 0400 1000 0002 [1.612392] [drm:drm_dp_dpcd_read [drm_kms_helper]] sor-0006-0f42: 0x0 AUX -> (ret= 1) 12 [1.612774] [drm:drm_dp_dpcd_write [drm_kms_helper]] sor-0006-0f42: 0x00111 AUX <- (ret= 1) 00 [1.635748] [drm:drm_dp_dpcd_access [drm_kms_helper]] Too many retries, giving up. First error: -6 [1.635752] [drm:drm_dp_dpcd_read [drm_kms_helper]] sor-0006-0f48: 0x0 AUX -> (ret= -6) [1.658128] [drm:drm_dp_dpcd_access [drm_kms_helper]] Too many retries, giving up. First error: -6 [1.658131] [drm:drm_dp_dpcd_read [drm_kms_helper]] sor-0006-0f81: 0x0 AUX -> (ret= -6) These failures would also occur /before/ nouveau had actually pushed anything to the evo channel. Then, later the rest of the GPU would start failing like so: [3.851956] [ cut here ] [3.851958] nouveau :01:00.0: timeout [3.851995] WARNING: CPU: 0 PID: 62 at drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgf100.c:1560 gf100_grctx_generate+0x89d/0x8b0 [nouveau] [3.851997] Modules linked in: serio_raw crc32c_intel xhci_pci i915(O+) xhci_hcd nouveau(O) video mxm_wmi wmi i2c_algo_bit drm_kms_helper(O) syscopyarea sysfillrect sysimgblt fb_sys_fops ttm(O) drm(O) i2c_core [3.852010] CPU: 0 PID: 62 Comm: kworker/0:2 Tainted: G O 4.18.0-rc8Lyude-Test+ #7 [3.852011] Hardware name: LENOVO 20EQS64N0B/20EQS64N0B, BIOS N1EET78W (1.51 ) 05/18/2018 [3.852018] Workqueue: events output_poll_execute [drm_kms_helper] [3.852105] RIP: 0010:gf100_grctx_generate+0x89d/0x8b0 [nouveau] [3.852107] Code: ff 49 8b 7c 24 10 48 8b 5f 50 48 85 db 75 04 48 8b 5f 10 e8 25 5d 30 e1 48 89 da 48 c7 c7 4e e7 2a a0 48 89 c6 e8 65 c1 e9 e0 <0f> 0b bb f0 ff ff ff e9 68 f9 ff ff 0f 1f 80 00 00 00 00 0f 1f 44 [3.852127] RSP: 0018:c927b898 EFLAGS: 00010282 [3.852128] RAX: RBX: 880876c20bd0 RCX: 0006 [3.852130] RDX: 0007 RSI: 0082 RDI: 88089b415570 [3.852132] RBP: c927b958 R08: R09: [3.852133] R10: 880876685f00 R11: 8140cc60 R12: 8808716d2000 [3.852135] R13: c927b8d0 R14: c927b8c8 R15: 88087165c000 [3.852137] FS: () GS:88089b40() knlGS: [3.852139] CS: 0010 DS: ES: CR0: 80050033 [3.852140] CR2: 5621d2c180b8 CR3: 0200a005 CR4: 003606f0 [3.852142] DR0: DR1: DR2: [3.852144] DR3: DR6: fffe0ff0 DR7: 0400 [3.852145] Call Trace: [3.852168] ? nv04_timer_read+0x48/0x60 [nouveau] [3.852191] gf100_gr_init_ctxctl+0x536/0xa40 [nouveau] [3.852212] gf100_gr_init+0x563/0x590 [nouveau] [3.852234] gf100_gr_init_+0x5b/0x60 [nouveau] [3.852255] nvkm_gr_init+0x1d/0x20 [nouveau] [3.852267] nvkm_engine_init+0xb9/0x1f0 [nouveau] [3.852280] nvkm_subdev_init+0xbc/0x210 [nouveau] [3.852292] nvkm_engine_ref.part.0+0x4a/0x70 [nouveau] [3.852304] nvkm_engine_ref+0x13/0x20 [nouveau] [3.852316] nvkm_ioctl_new+0x12c/0x260 [nouveau] [3.852337] ? nvkm_fifo_chan_dtor+0x100/0x100 [nouveau] [3.852358] ? gf100_fermi_mthd+0x100/0x100 [nouveau] [3.852371] nvkm_ioctl+0xe2/0x180 [nouveau] [3.852392] nvkm_client_ioctl+0x12/0x20 [nouveau] [3.852403] nvif_object_ioctl+0x47/0x50 [nouveau] [3.852415] nvif_object_init+0xc8/0x120 [nouveau] [3.852435] nvc0_fbcon_accel_init+0x5b/0x950 [nouveau] [3.852455] nouveau_fbcon_create+0x5bb/0x5e0 [nouveau] [3.852460] ? drm_setup_crtcs+0x247/0xa60 [drm_kms_helper] [3.852464] __drm_fb_helper_initial_config_and_unlock+0x1c0/0x410 [drm_kms_helper] [3.852468]
[PATCH 0/3] drm/nouveau: Fixup module probe to add ->shutdown()
This series is intended to add support for shutting down the GPU on kernel shutdown/reboot using the ->shutdown() hook, similar to what amdgpu does. This is mainly intended to workaround a bios issue on the P50 that was preventing nouveau from initializing the dedicated GM107 GPU on that system properly. You can find more details on this issue in the patch labeled "Shut down GPU on kernel shutdown". Doing this so that it wouldn't race with userspace took a little bit of work (and uncovered one small bug in the process). Mainly, I had to convert nouveau to use the new drm_dev_alloc() and drm_dev_register() helpers to ensure that there isn't any chance that we can race with userspace during shutdown. This also involved removing ->load() and ->unload() and moving their work into nouveau_drm_probe(). == IMPORTANT === This patch series WILL NOT WORK PROPERLY unless you also apply the following patches which fix some leftover device removal issues: https://patchwork.freedesktop.org/series/48596/ This fixes kernel panics on removal on systems with nvidia controlled backlights https://patchwork.freedesktop.org/series/47843/ This fixes issues with DRM connectors getting leaked on device removal, due to hpd_work still being active when unloading nouveau. == IMPORTANT === This also uncovered one small bug in nouveau_drm_load(). Lyude Paul (3): drm/nouveau: Fix potential memory leak in nouveau_drm_load() drm/nouveau: Start using new drm_dev initialization helpers drm/nouveau: Shut down GPU on kernel shutdown drivers/gpu/drm/nouveau/nouveau_drm.c | 180 +++--- 1 file changed, 106 insertions(+), 74 deletions(-) -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/3] drm/nouveau: Start using new drm_dev initialization helpers
Per the documentation in drm_get_pci_dev(), this function is deprecated
and shouldn't be used anymore. As it turns out, we're going to need to
stop using drm_get_pci_dev() anyway in order to allow us to turn off the
card before full system shutdowns, otherwise we'll hit race conditions
with userspace while trying to tear down the card on shutdown.
So, start using drm_dev_get() and drm_dev_put(), and just turn our
load/unload callbacks into open coded init/fini() functions.
Signed-off-by: Lyude Paul
Cc: Karol Herbst
---
drivers/gpu/drm/nouveau/nouveau_drm.c | 173 +++---
1 file changed, 101 insertions(+), 72 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index 6c88ff776ff6..b88b338dc79c 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -458,75 +458,8 @@ nouveau_accel_init(struct nouveau_drm *drm)
nouveau_bo_move_init(drm);
}
-static int nouveau_drm_probe(struct pci_dev *pdev,
-const struct pci_device_id *pent)
-{
- struct nvkm_device *device;
- struct apertures_struct *aper;
- bool boot = false;
- int ret;
-
- if (vga_switcheroo_client_probe_defer(pdev))
- return -EPROBE_DEFER;
-
- /* We need to check that the chipset is supported before booting
-* fbdev off the hardware, as there's no way to put it back.
-*/
- ret = nvkm_device_pci_new(pdev, NULL, "error", true, false, 0, );
- if (ret)
- return ret;
-
- nvkm_device_del();
-
- /* Remove conflicting drivers (vesafb, efifb etc). */
- aper = alloc_apertures(3);
- if (!aper)
- return -ENOMEM;
-
- aper->ranges[0].base = pci_resource_start(pdev, 1);
- aper->ranges[0].size = pci_resource_len(pdev, 1);
- aper->count = 1;
-
- if (pci_resource_len(pdev, 2)) {
- aper->ranges[aper->count].base = pci_resource_start(pdev, 2);
- aper->ranges[aper->count].size = pci_resource_len(pdev, 2);
- aper->count++;
- }
-
- if (pci_resource_len(pdev, 3)) {
- aper->ranges[aper->count].base = pci_resource_start(pdev, 3);
- aper->ranges[aper->count].size = pci_resource_len(pdev, 3);
- aper->count++;
- }
-
-#ifdef CONFIG_X86
- boot = pdev->resource[PCI_ROM_RESOURCE].flags & IORESOURCE_ROM_SHADOW;
-#endif
- if (nouveau_modeset != 2)
- drm_fb_helper_remove_conflicting_framebuffers(aper,
"nouveaufb", boot);
- kfree(aper);
-
- ret = nvkm_device_pci_new(pdev, nouveau_config, nouveau_debug,
- true, true, ~0ULL, );
- if (ret)
- return ret;
-
- pci_set_master(pdev);
-
- if (nouveau_atomic)
- driver_pci.driver_features |= DRIVER_ATOMIC;
-
- ret = drm_get_pci_dev(pdev, pent, _pci);
- if (ret) {
- nvkm_device_del();
- return ret;
- }
-
- return 0;
-}
-
static int
-nouveau_drm_load(struct drm_device *dev, unsigned long flags)
+nouveau_drm_device_init(struct drm_device *dev)
{
struct nouveau_drm *drm;
int ret;
@@ -615,7 +548,7 @@ nouveau_drm_load(struct drm_device *dev, unsigned long
flags)
}
static void
-nouveau_drm_unload(struct drm_device *dev)
+nouveau_drm_device_fini(struct drm_device *dev)
{
struct nouveau_drm *drm = nouveau_drm(dev);
@@ -644,18 +577,116 @@ nouveau_drm_unload(struct drm_device *dev)
kfree(drm);
}
+static int nouveau_drm_probe(struct pci_dev *pdev,
+const struct pci_device_id *pent)
+{
+ struct nvkm_device *device;
+ struct drm_device *drm_dev;
+ struct apertures_struct *aper;
+ bool boot = false;
+ int ret;
+
+ if (vga_switcheroo_client_probe_defer(pdev))
+ return -EPROBE_DEFER;
+
+ /* We need to check that the chipset is supported before booting
+* fbdev off the hardware, as there's no way to put it back.
+*/
+ ret = nvkm_device_pci_new(pdev, NULL, "error", true, false, 0, );
+ if (ret)
+ return ret;
+
+ nvkm_device_del();
+
+ /* Remove conflicting drivers (vesafb, efifb etc). */
+ aper = alloc_apertures(3);
+ if (!aper)
+ return -ENOMEM;
+
+ aper->ranges[0].base = pci_resource_start(pdev, 1);
+ aper->ranges[0].size = pci_resource_len(pdev, 1);
+ aper->count = 1;
+
+ if (pci_resource_len(pdev, 2)) {
+ aper->ranges[aper->count].base = pci_resource_start(pdev, 2);
+ aper->ranges[aper->count].size = pci_resource_len(pdev, 2);
+ aper->count++;
+ }
+
+ if (pci_resource_len(pdev, 3)) {
+ aper->ranges[aper->count].base = pci_resource_start(pdev, 3);
+ aper->ranges[aper->count].size =
[PATCH 1/5] drm/nouveau: Check backlight IDs are >= 0, not > 0
Remember, ida IDs start at 0, not 1!
Signed-off-by: Lyude Paul
Cc: sta...@vger.kernel.org
Cc: Jeffery Miller
Cc: Karol Herbst
---
drivers/gpu/drm/nouveau/nouveau_backlight.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_backlight.c
b/drivers/gpu/drm/nouveau/nouveau_backlight.c
index 408b955e5c39..6dd72bc32897 100644
--- a/drivers/gpu/drm/nouveau/nouveau_backlight.c
+++ b/drivers/gpu/drm/nouveau/nouveau_backlight.c
@@ -116,7 +116,7 @@ nv40_backlight_init(struct drm_connector *connector)
_bl_ops, );
if (IS_ERR(bd)) {
- if (bl_connector.id > 0)
+ if (bl_connector.id >= 0)
ida_simple_remove(_ida, bl_connector.id);
return PTR_ERR(bd);
}
@@ -249,7 +249,7 @@ nv50_backlight_init(struct drm_connector *connector)
nv_encoder, ops, );
if (IS_ERR(bd)) {
- if (bl_connector.id > 0)
+ if (bl_connector.id >= 0)
ida_simple_remove(_ida, bl_connector.id);
return PTR_ERR(bd);
}
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/5] drm/nouveau: Refactor nvXX_backlight_init()
There's literally no difference between any of the backlight init
functions besides the backlight properties they set and the backlight
callbacks that they set, so move all of the duplicated backlight init
code out of there and into nouveau_backlight_init().
This gets rid of a lot of copy pasta!
Signed-off-by: Lyude Paul
Cc: Jeffery Miller
Cc: Karol Herbst
---
drivers/gpu/drm/nouveau/nouveau_backlight.c | 131 +---
1 file changed, 57 insertions(+), 74 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_backlight.c
b/drivers/gpu/drm/nouveau/nouveau_backlight.c
index 7ad90e7610a1..0712b2688e18 100644
--- a/drivers/gpu/drm/nouveau/nouveau_backlight.c
+++ b/drivers/gpu/drm/nouveau/nouveau_backlight.c
@@ -94,48 +94,20 @@ static const struct backlight_ops nv40_bl_ops = {
};
static int
-nv40_backlight_init(struct drm_connector *connector)
+nv40_backlight_init(struct drm_connector *connector,
+ struct backlight_properties *props,
+ const struct backlight_ops **ops)
{
struct nouveau_drm *drm = nouveau_drm(connector->dev);
- struct nouveau_backlight *bl;
struct nvif_object *device = >client.device.object;
- struct backlight_properties props;
- char backlight_name[BL_NAME_SIZE];
- int ret = 0;
if (!(nvif_rd32(device, NV40_PMC_BACKLIGHT) & NV40_PMC_BACKLIGHT_MASK))
- return 0;
-
- bl = kzalloc(sizeof(*bl), GFP_KERNEL);
- if (!bl)
- return -ENOMEM;
-
- memset(, 0, sizeof(struct backlight_properties));
- props.type = BACKLIGHT_RAW;
- props.max_brightness = 31;
- if (!nouveau_get_backlight_name(backlight_name, bl)) {
- NV_ERROR(drm, "Failed to retrieve a unique name for the
backlight interface\n");
- goto fail_alloc;
- }
-
- bl->dev = backlight_device_register(backlight_name, connector->kdev,
- drm, _bl_ops, );
- if (IS_ERR(bl->dev)) {
- if (bl->id >= 0)
- ida_simple_remove(_ida, bl->id);
-
- ret = PTR_ERR(bl->dev);
- goto fail_alloc;
- }
-
- nouveau_connector(connector)->backlight = bl;
- bl->dev->props.brightness = nv40_get_intensity(bl->dev);
- backlight_update_status(bl->dev);
+ return -ENODEV;
+ props->type = BACKLIGHT_RAW;
+ props->max_brightness = 31;
+ *ops = _bl_ops;
return 0;
-fail_alloc:
- kfree(bl);
- return ret;
}
static int
@@ -221,16 +193,13 @@ static const struct backlight_ops nva3_bl_ops = {
};
static int
-nv50_backlight_init(struct drm_connector *connector)
+nv50_backlight_init(struct drm_connector *connector,
+ struct backlight_properties *props,
+ const struct backlight_ops **ops)
{
struct nouveau_drm *drm = nouveau_drm(connector->dev);
struct nvif_object *device = >client.device.object;
struct nouveau_encoder *nv_encoder;
- struct nouveau_backlight *bl;
- struct backlight_properties props;
- const struct backlight_ops *ops;
- char backlight_name[BL_NAME_SIZE];
- int ret = 0;
nv_encoder = find_encoder(connector, DCB_OUTPUT_LVDS);
if (!nv_encoder) {
@@ -240,52 +209,31 @@ nv50_backlight_init(struct drm_connector *connector)
}
if (!nvif_rd32(device, NV50_PDISP_SOR_PWM_CTL(ffs(nv_encoder->dcb->or)
- 1)))
- return 0;
-
- bl = kzalloc(sizeof(*bl), GFP_KERNEL);
- if (!bl)
- return -ENOMEM;
+ return -ENODEV;
if (drm->client.device.info.chipset <= 0xa0 ||
drm->client.device.info.chipset == 0xaa ||
drm->client.device.info.chipset == 0xac)
- ops = _bl_ops;
+ *ops = _bl_ops;
else
- ops = _bl_ops;
+ *ops = _bl_ops;
- memset(, 0, sizeof(struct backlight_properties));
- props.type = BACKLIGHT_RAW;
- props.max_brightness = 100;
- if (!nouveau_get_backlight_name(backlight_name, bl)) {
- NV_ERROR(drm, "Failed to retrieve a unique name for the
backlight interface\n");
- goto fail_alloc;
- }
-
- bl->dev = backlight_device_register(backlight_name, connector->kdev,
- nv_encoder, ops, );
- if (IS_ERR(bl->dev)) {
- if (bl->id >= 0)
- ida_simple_remove(_ida, bl->id);
+ props->type = BACKLIGHT_RAW;
+ props->max_brightness = 100;
- ret = PTR_ERR(bl->dev);
- goto fail_alloc;
- }
-
- nouveau_connector(connector)->backlight = bl;
- bl->dev->props.brightness = bl->dev->ops->get_brightness(bl->dev);
- backlight_update_status(bl->dev);
return 0;
-
-fail_alloc:
- kfree(bl);
- return ret;
}
int
[PATCH 4/5] drm/nouveau: Cleanup indenting in nouveau_backlight.c
Still no functional changes.
Signed-off-by: Lyude Paul
Cc: Jeffery Miller
Cc: Karol Herbst
---
drivers/gpu/drm/nouveau/nouveau_backlight.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_backlight.c
b/drivers/gpu/drm/nouveau/nouveau_backlight.c
index 017d5b7924bb..7ad90e7610a1 100644
--- a/drivers/gpu/drm/nouveau/nouveau_backlight.c
+++ b/drivers/gpu/drm/nouveau/nouveau_backlight.c
@@ -68,7 +68,7 @@ nv40_get_intensity(struct backlight_device *bd)
struct nouveau_drm *drm = bl_get_data(bd);
struct nvif_object *device = >client.device.object;
int val = (nvif_rd32(device, NV40_PMC_BACKLIGHT) &
- NV40_PMC_BACKLIGHT_MASK) >> 16;
+ NV40_PMC_BACKLIGHT_MASK) >> 16;
return val;
}
@@ -82,7 +82,7 @@ nv40_set_intensity(struct backlight_device *bd)
int reg = nvif_rd32(device, NV40_PMC_BACKLIGHT);
nvif_wr32(device, NV40_PMC_BACKLIGHT,
-(val << 16) | (reg & ~NV40_PMC_BACKLIGHT_MASK));
+ (val << 16) | (reg & ~NV40_PMC_BACKLIGHT_MASK));
return 0;
}
@@ -164,7 +164,7 @@ nv50_set_intensity(struct backlight_device *bd)
u32 val = (bd->props.brightness * div) / 100;
nvif_wr32(device, NV50_PDISP_SOR_PWM_CTL(or),
- NV50_PDISP_SOR_PWM_CTL_NEW | val);
+ NV50_PDISP_SOR_PWM_CTL_NEW | val);
return 0;
}
@@ -204,9 +204,10 @@ nva3_set_intensity(struct backlight_device *bd)
div = nvif_rd32(device, NV50_PDISP_SOR_PWM_DIV(or));
val = (bd->props.brightness * div) / 100;
if (div) {
- nvif_wr32(device, NV50_PDISP_SOR_PWM_CTL(or), val |
- NV50_PDISP_SOR_PWM_CTL_NEW |
- NVA3_PDISP_SOR_PWM_CTL_UNK);
+ nvif_wr32(device, NV50_PDISP_SOR_PWM_CTL(or),
+ val |
+ NV50_PDISP_SOR_PWM_CTL_NEW |
+ NVA3_PDISP_SOR_PWM_CTL_UNK);
return 0;
}
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/5] drm/nouveau: Move backlight device into nouveau_connector
Currently module unloading is broken in nouveau due to a rather annoying race condition resulting from nouveau_backlight.c having gone a bit stale over time: [ 1960.791143] == [ 1960.791394] BUG: KASAN: use-after-free in nouveau_backlight_exit+0x112/0x150 [nouveau] [ 1960.791460] Read of size 4 at addr 88075accf350 by task zsh/11185 [ 1960.791521] [ 1960.791545] CPU: 7 PID: 11185 Comm: zsh Kdump: loaded Tainted: G O 4.18.0Lyude-Test+ #4 [ 1960.791580] Hardware name: LENOVO 20EQS64N0B/20EQS64N0B, BIOS N1EET79W (1.52 ) 07/13/2018 [ 1960.791628] Call Trace: [ 1960.791680] dump_stack+0xa4/0xfd [ 1960.791721] print_address_description+0x71/0x239 [ 1960.791833] ? nouveau_backlight_exit+0x112/0x150 [nouveau] [ 1960.791877] kasan_report.cold.6+0x242/0x2fe [ 1960.791919] __asan_report_load4_noabort+0x19/0x20 [ 1960.792012] nouveau_backlight_exit+0x112/0x150 [nouveau] [ 1960.792081] nouveau_display_destroy+0x76/0x150 [nouveau] [ 1960.792150] nouveau_drm_device_fini+0xb7/0x190 [nouveau] [ 1960.792265] nouveau_drm_device_remove+0x14b/0x1d0 [nouveau] [ 1960.792347] ? nouveau_cli_work_queue+0x2e0/0x2e0 [nouveau] [ 1960.792378] ? trace_hardirqs_on_caller+0x38b/0x570 [ 1960.792406] ? trace_hardirqs_on+0xd/0x10 [ 1960.792472] nouveau_drm_remove+0x37/0x50 [nouveau] [ 1960.792502] pci_device_remove+0x112/0x2d0 [ 1960.792530] ? pcibios_free_irq+0x10/0x10 [ 1960.792558] ? kasan_check_write+0x14/0x20 [ 1960.792587] device_release_driver_internal+0x35c/0x650 [ 1960.792617] device_release_driver+0x12/0x20 [ 1960.792643] pci_stop_bus_device+0x172/0x1e0 [ 1960.792671] pci_stop_and_remove_bus_device_locked+0x1a/0x30 [ 1960.792715] remove_store+0xcb/0xe0 [ 1960.792753] ? sriov_numvfs_store+0x2e0/0x2e0 [ 1960.792779] ? __lock_is_held+0xb5/0x140 [ 1960.792808] ? component_add+0x530/0x530 [ 1960.792834] dev_attr_store+0x3f/0x70 [ 1960.792859] ? sysfs_file_ops+0x11d/0x170 [ 1960.792885] sysfs_kf_write+0x104/0x150 [ 1960.792915] ? sysfs_file_ops+0x170/0x170 [ 1960.792940] kernfs_fop_write+0x24f/0x400 [ 1960.792978] ? __lock_acquire+0x6ea/0x47f0 [ 1960.793021] __vfs_write+0xeb/0x760 [ 1960.793048] ? kernel_read+0x130/0x130 [ 1960.793076] ? __lock_is_held+0xb5/0x140 [ 1960.793107] ? rcu_read_lock_sched_held+0xdd/0x110 [ 1960.793135] ? rcu_sync_lockdep_assert+0x78/0xb0 [ 1960.793162] ? __sb_start_write+0x183/0x220 [ 1960.793189] vfs_write+0x14d/0x4a0 [ 1960.793229] ksys_write+0xd2/0x1b0 [ 1960.793255] ? __ia32_sys_read+0xb0/0xb0 [ 1960.793298] ? fput+0x1d/0x120 [ 1960.793324] ? filp_close+0xf3/0x130 [ 1960.793349] ? entry_SYSCALL_64_after_hwframe+0x59/0xbe [ 1960.793380] __x64_sys_write+0x73/0xb0 [ 1960.793407] do_syscall_64+0xaa/0x400 [ 1960.793433] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 1960.793460] RIP: 0033:0x7f59df433164 [ 1960.793486] Code: 89 02 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 8d 05 81 38 2d 00 8b 00 85 c0 75 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 c3 0f 1f 00 41 54 49 89 d4 55 48 89 f5 53 [ 1960.793541] RSP: 002b:7ffd70ee2fb8 EFLAGS: 0246 ORIG_RAX: 0001 [ 1960.793576] RAX: ffda RBX: 0002 RCX: 7f59df433164 [ 1960.793620] RDX: 0002 RSI: 5578088640c0 RDI: 0001 [ 1960.793665] RBP: 5578088640c0 R08: 7f59df7038c0 R09: 7f59e0995b80 [ 1960.793696] R10: 000a R11: 0246 R12: 7f59df702760 [ 1960.793730] R13: 0002 R14: 7f59df6fd760 R15: 0002 [ 1960.793768] [ 1960.793790] Allocated by task 11167: [ 1960.793816] save_stack+0x43/0xd0 [ 1960.793841] kasan_kmalloc+0xc4/0xe0 [ 1960.793880] kasan_slab_alloc+0x11/0x20 [ 1960.793905] kmem_cache_alloc+0xd7/0x270 [ 1960.793944] getname_flags+0xbd/0x520 [ 1960.793969] user_path_at_empty+0x23/0x50 [ 1960.793994] do_faccessat+0x1fc/0x5d0 [ 1960.794018] __x64_sys_access+0x59/0x80 [ 1960.794043] do_syscall_64+0xaa/0x400 [ 1960.794067] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 1960.794093] [ 1960.794127] Freed by task 11167: [ 1960.794152] save_stack+0x43/0xd0 [ 1960.794190] __kasan_slab_free+0x139/0x190 [ 1960.794215] kasan_slab_free+0xe/0x10 [ 1960.794239] kmem_cache_free+0xcb/0x2c0 [ 1960.794264] putname+0xad/0xe0 [ 1960.794287] filename_lookup.part.59+0x1f1/0x360 [ 1960.794313] user_path_at_empty+0x3e/0x50 [ 1960.794338] do_faccessat+0x1fc/0x5d0 [ 1960.794362] __x64_sys_access+0x59/0x80 [ 1960.794393] do_syscall_64+0xaa/0x400 [ 1960.794421] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 1960.794461] [ 1960.794483] The buggy address belongs to the object at 88075acceac0 [ 1960.794483] which belongs to the cache names_cache of size 4096 [ 1960.794540] The buggy address is located 2192 bytes inside of [ 1960.794540] 4096-byte region [88075acceac0, 88075accfac0) [ 1960.794581] The buggy address belongs to the page: [ 1960.794609] page:ea001d6b3200 count:1
[PATCH 0/5] drm/nouveau: Backlight fixes and cleanup
This series fixes some issues with nouveau's backlight support that were causing kernel panics on module reloads, specifically on systems with nouveau handling the backlight of one of the displays. While we're at it, let's cleanup nouveau_backlight.c as well Lyude Paul (5): drm/nouveau: Check backlight IDs are >= 0, not > 0 drm/nouveau: Move backlight device into nouveau_connector drm/nouveau: s/nouveau_backlight_exit/nouveau_backlight_fini/ drm/nouveau: Cleanup indenting in nouveau_backlight.c drm/nouveau: Refactor nvXX_backlight_init() drivers/gpu/drm/nouveau/nouveau_backlight.c | 193 ++-- drivers/gpu/drm/nouveau/nouveau_connector.c | 20 ++ drivers/gpu/drm/nouveau/nouveau_connector.h | 33 drivers/gpu/drm/nouveau/nouveau_display.c | 2 - drivers/gpu/drm/nouveau/nouveau_display.h | 25 --- drivers/gpu/drm/nouveau/nouveau_drv.h | 2 - 6 files changed, 146 insertions(+), 129 deletions(-) -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/5] drm/nouveau: s/nouveau_backlight_exit/nouveau_backlight_fini/
More consistent with the rest of the codebase, no functional changes
here.
Signed-off-by: Lyude Paul
Cc: Jeffery Miller
Cc: Karol Herbst
---
drivers/gpu/drm/nouveau/nouveau_backlight.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_connector.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_connector.h | 4 ++--
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_backlight.c
b/drivers/gpu/drm/nouveau/nouveau_backlight.c
index 3e4874f405ab..017d5b7924bb 100644
--- a/drivers/gpu/drm/nouveau/nouveau_backlight.c
+++ b/drivers/gpu/drm/nouveau/nouveau_backlight.c
@@ -309,7 +309,7 @@ nouveau_backlight_init(struct drm_connector *connector)
}
void
-nouveau_backlight_exit(struct drm_connector *connector)
+nouveau_backlight_fini(struct drm_connector *connector)
{
struct nouveau_connector *nv_conn = nouveau_connector(connector);
struct nouveau_backlight *bl = nv_conn->backlight;
diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c
b/drivers/gpu/drm/nouveau/nouveau_connector.c
index 767e892de9c4..3b288be9c3f7 100644
--- a/drivers/gpu/drm/nouveau/nouveau_connector.c
+++ b/drivers/gpu/drm/nouveau/nouveau_connector.c
@@ -911,7 +911,7 @@ nouveau_connector_late_register(struct drm_connector
*connector)
static void
nouveau_connector_early_unregister(struct drm_connector *connector)
{
- nouveau_backlight_exit(connector);
+ nouveau_backlight_fini(connector);
}
static int
diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.h
b/drivers/gpu/drm/nouveau/nouveau_connector.h
index 5465ae82fb9f..76e79717e451 100644
--- a/drivers/gpu/drm/nouveau/nouveau_connector.h
+++ b/drivers/gpu/drm/nouveau/nouveau_connector.h
@@ -190,7 +190,7 @@ struct drm_display_mode *nouveau_conn_native_mode(struct
drm_connector *);
#ifdef CONFIG_DRM_NOUVEAU_BACKLIGHT
extern int nouveau_backlight_init(struct drm_connector *);
-extern void nouveau_backlight_exit(struct drm_connector *);
+extern void nouveau_backlight_fini(struct drm_connector *);
extern void nouveau_backlight_ctor(void);
extern void nouveau_backlight_dtor(void);
#else
@@ -201,7 +201,7 @@ nouveau_backlight_init(struct drm_connector *connector)
}
static inline void
-nouveau_backlight_exit(struct drm_connector *connector) {
+nouveau_backlight_fini(struct drm_connector *connector) {
}
static inline void
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i915: Add plane alpha blending support, v2.
On Wed, Aug 15, 2018 at 12:34:05PM +0200, Maarten Lankhorst wrote:
> Add plane alpha blending support with the different blend modes.
> This has been tested on a icl to show the correct results,
> on earlier platforms small rounding errors cause issues. But this
> already happens case with fully transparant or fully opaque RGB
> fb's.
>
> The recommended HW workaround is to disable alpha blending when the
> plane alpha is 0 (transparant, hide plane) or 0xff (opaque, disable blending).
> This is easy to implement on any platform, so just do that.
>
> The tests for userspace are also available, and pass on gen11.
>
> Changes since v1:
> - Change mistaken < 0xff0 to 0xff00.
> - Only set PLANE_KEYMSK_ALPHA_ENABLE when plane alpha < 0xff00, ignore blend
> mode.
> - Rework disabling FBC when per pixel alpha is used.
>
> Signed-off-by: Maarten Lankhorst
One question and one minor suggestion inline below, but otherwise,
Reviewed-by: Matt Roper
> ---
> drivers/gpu/drm/i915/i915_drv.h | 2 +
> drivers/gpu/drm/i915/i915_reg.h | 2 +
> drivers/gpu/drm/i915/intel_display.c | 58 +++-
> drivers/gpu/drm/i915/intel_fbc.c | 8
> drivers/gpu/drm/i915/intel_sprite.c | 23 ++-
> 5 files changed, 73 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 3fa56b960ef2..29f75da5fa8c 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -545,6 +545,8 @@ struct intel_fbc {
> int adjusted_y;
>
> int y;
> +
> + uint16_t pixel_blend_mode;
> } plane;
>
> struct {
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 0c9f03dda569..93a1d87cdeb2 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -6561,8 +6561,10 @@ enum {
> #define _PLANE_KEYVAL_2_A0x70294
> #define _PLANE_KEYMSK_1_A0x70198
> #define _PLANE_KEYMSK_2_A0x70298
> +#define PLANE_KEYMSK_ALPHA_ENABLE (1 << 31)
> #define _PLANE_KEYMAX_1_A0x701a0
> #define _PLANE_KEYMAX_2_A0x702a0
> +#define PLANE_KEYMAX_ALPHA_SHIFT24
> #define _PLANE_AUX_DIST_1_A 0x701c0
> #define _PLANE_AUX_DIST_2_A 0x702c0
> #define _PLANE_AUX_OFFSET_1_A0x701c4
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index a0345e7d3c2b..aedad3674b0d 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -3167,6 +3167,12 @@ int skl_check_plane_surface(const struct
> intel_crtc_state *crtc_state,
> return -EINVAL;
> }
>
> + /* HW only has 8 bits pixel precision, disable plane if invisible */
> + if (!(plane_state->base.alpha >> 8)) {
> + plane_state->base.visible = false;
> + return 0;
> + }
> +
> if (!plane_state->base.visible)
> return 0;
>
> @@ -3512,30 +3518,39 @@ static u32 skl_plane_ctl_format(uint32_t pixel_format)
> return 0;
> }
>
> -/*
> - * XXX: For ARBG/ABGR formats we default to expecting scanout buffers
> - * to be already pre-multiplied. We need to add a knob (or a different
> - * DRM_FORMAT) for user-space to configure that.
> - */
> -static u32 skl_plane_ctl_alpha(uint32_t pixel_format)
> +static u32 skl_plane_ctl_alpha(const struct intel_plane_state *plane_state)
> {
> - switch (pixel_format) {
> - case DRM_FORMAT_ABGR:
> - case DRM_FORMAT_ARGB:
> + if (!plane_state->base.fb->format->has_alpha)
> + return PLANE_CTL_ALPHA_DISABLE;
> +
> + switch (plane_state->base.pixel_blend_mode) {
> + case DRM_MODE_BLEND_PIXEL_NONE:
> + return PLANE_CTL_ALPHA_DISABLE;
> + case DRM_MODE_BLEND_PREMULTI:
> return PLANE_CTL_ALPHA_SW_PREMULTIPLY;
> + case DRM_MODE_BLEND_COVERAGE:
> + return PLANE_CTL_ALPHA_HW_PREMULTIPLY;
> default:
> - return PLANE_CTL_ALPHA_DISABLE;
> + MISSING_CASE(plane_state->base.pixel_blend_mode);
> + return 0;
Maybe just add the MISSING_CASE line before the current return? The
macro still expands to 0, so leaving that makes it slightly more clear
what the default fallback is. Same for the glk_ function below.
> }
> }
>
> -static u32 glk_plane_color_ctl_alpha(uint32_t pixel_format)
> +static u32 glk_plane_color_ctl_alpha(const struct intel_plane_state
> *plane_state)
> {
> - switch (pixel_format) {
> - case DRM_FORMAT_ABGR:
> - case DRM_FORMAT_ARGB:
> + if (!plane_state->base.fb->format->has_alpha)
> + return PLANE_COLOR_ALPHA_DISABLE;
> +
> + switch (plane_state->base.pixel_blend_mode) {
> + case
[Bug 102322] System crashes after "[drm] IP block:gmc_v8_0 is hung!" / [drm] IP block:sdma_v3_0 is hung!
https://bugs.freedesktop.org/show_bug.cgi?id=102322 --- Comment #62 from dwagner --- Created attachment 141243 --> https://bugs.freedesktop.org/attachment.cgi?id=141243=edit crash trace with amdgpu.vm_update_mode=3 -- 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 102322] System crashes after "[drm] IP block:gmc_v8_0 is hung!" / [drm] IP block:sdma_v3_0 is hung!
https://bugs.freedesktop.org/show_bug.cgi?id=102322 --- Comment #61 from dwagner --- > Please use amdgpu.vm_update_mode=3 to get back to VM_FAULTs issue. The "good" news is that reproduction of the crashes with 3-fps-video-replay is very quick when using amdgpu.vm_update_mode=3. But the bad news is that I have not been able to get useful error output when using vm_update_mode=3. At first I tried with also amdgpu.vm_debug=1, and with that in 10 crashes not a single error output line was emitted to either the ssh channel or the system journal. I then tried with amdgpu.vm_debug=0, and while a few error lines output become logged, then, not quite anything useful - see also in attached example: [ 912.447139] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, signaled seq=12818, emitted seq=12819 [ 912.447145] [drm] GPU recovery disabled. These are the only lines indicating the error, not even the echo "crash detected!" after the "dmesg -w | tee /dev/tty | grep -m 1 -e "amdgpu.*GPU" -e "amdgpu.*ERROR" gets emitted, much less the theoretically following umr commands. What could I do to not let the kernel die so quickly when using amdgpu.vm_update_mode=3? -- 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 PATCH radeon-alex] drm/amdgpu: amdgpu_kiq_reg_write_reg_wait() can be static
On Tue, Aug 21, 2018 at 10:38 PM Deng, Emily wrote:
>
> Reviewed-by: Emily Deng
Applied. thanks!
Alex
>
> >-Original Message-
> >From: kbuild test robot
> >Sent: Wednesday, August 22, 2018 10:31 AM
> >To: Deng, Emily
> >Cc: kbuild-...@01.org; dri-devel@lists.freedesktop.org; Deucher, Alexander
> >; Koenig, Christian
> >
> >Subject: [RFC PATCH radeon-alex] drm/amdgpu:
> >amdgpu_kiq_reg_write_reg_wait() can be static
> >
> >
> >Fixes: d790449835e6 ("drm/amdgpu: use kiq to do invalidate tlb")
> >Signed-off-by: kbuild test robot
> >---
> > gmc_v9_0.c |2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> >diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
> >b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
> >index 0bf8439..4dd5769 100644
> >--- a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
> >+++ b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
> >@@ -311,7 +311,7 @@ static uint32_t gmc_v9_0_get_invalidate_req(unsigned
> >int vmid)
> > return req;
> > }
> >
> >-signed long amdgpu_kiq_reg_write_reg_wait(struct amdgpu_device *adev,
> >+static signed long amdgpu_kiq_reg_write_reg_wait(struct amdgpu_device
> >*adev,
> > uint32_t reg0, uint32_t
> > reg1,
> > uint32_t ref, uint32_t mask)
> > {
> ___
> 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/1] drm/ttm: Set memory as decrypted for ttm framebuffer mappings
On 08/22/2018 02:09 PM, Christian König wrote:
> Am 22.08.2018 um 20:57 schrieb Jiandi An:
>> Framebuffer memory needs to be accessed decrypted. Ensure the
>> memory encryption mask is not set for the ttm framebuffer mappings.
>
> NAK, the memory not only needs to be decrypted while CPU accessed but all the
> time.
>
> ttm_page_alloc.c and ttm_page_alloc_dma.c should already take care of that
> while mapping the pages.
>
> Regards,
> Christian.
>
The path where the issue comes in is booting guest with AMD SEV enabled while
using virtio-vga device.
The ttm->pages doesn't go through ttm_populate_and_map_pages().
In the kernel path, the virtio_gpu driver calls virtio_gpu_alloc_object() and
goes down to ttm to
allocate pages in ttm_pool_populate(). Driver in guest then does
virtio_gpu_vmap_fb() which goes
down to ttm_bo_kmap_ttm() and does a vmap() for GVA to GPA for those pages. If
SEV is enabled,
decryption should be set in this GVA to GPA mapping. Guest then sends object
attach command to host
via virtio_gpu_object_attach() which stuffs the pages' physical addresses
(guest physical address)
in a scatter list and send them to host QEMU. Host QEMU maps those guest pages
GPA to HPA and access
via HVA while guest write stuff in those pages via GVA.
virtio_gpu_alloc_object()
virtio_gpu_object_create()
sturct virtio_gpu_object bo kzalloc()
ttm_bo_init()
...
ttm_tt_create()
bo->ttm = bdev->driver->ttm_tt_create()
virtio_gpu_ttm_tt_create()
...
ttm_tt_populate()
ttm_pool_populate()
ttm_get_pages(ttm->pages, ttm->num_pages)
virtio_gpu_vmap_fb()
virtio_gpu_object_kmap(obj, NULL)
ttm_bo_kmap
ttm_mem_io_reserve()
ttm_bo_kmap_ttm()
vmap()
struct virtio_gpu_object bo->vmap = ttm_kmap_obj_virtual(>kmap,
_iomem);
virtio_gpu_object_attach() <<== Sending attach backing command
virtio_gpu_object_get_sg_table()
if (bo->tbo.ttm->state == tt_unpopulated)
virtio_gpu_object bo.ttm->bdev->driver->ttm_tt_populate(bo->tbo.ttm,
);
bo->pages = kmalloc(sizeof(struct sg_table), GFP_KERNEL);
sg_alloc_table_from_pages(bo->tbo.ttm->pages) //Getfrom ttm->pages
and put in sg
__sg_alloc_table_from_pages()
There is a separate userspace path for example when displace manager kicks in,
virtio_gpu_alloc_object() followed by virtio_gpu_object_attach() are called
through
the ioctl virtio_gpu_resource_create_ioctl(). The mapping of the pages created
in this
page are handled in the do_page_fault() path in ttm_bo_vm_ops's
ttm_bo_vm_fault() handler.
do_page_fault()
handle_mm_fault()
__do_page_fault()
ttm_bo_vm_fault()
ttm_bo_reserve()
__ttm_bo_reserve()
ttm_mem_io_reserve_vm()
ttm_mem_io_reserve()
bdev->driver->io_mem_reserve()
virtio_gpu_ttm_io_mem_reserve()
mem->bus.is_iomem = false
mem->mem_type == TTM_PL_TT
I originally handled setting pages decrypted for the kernel path for GVA to GPA
mapping in guest
in virtio_gpu_vmap_fb() at the virtio_gpu driver layer. But for the user space
path
virtio_gpu_vmap_fb() is not called. Mapping is handled in the page_fault
handler. So I moved it
to the ttm layer.
What layer do you recommend as more appropriate to handle setting memory
decrypted for GVA to GPA
mapping for thos ttm->pages?
Thanks
Jiandi
>>
>> Signed-off-by: Jiandi An
>> ---
>> drivers/gpu/drm/ttm/ttm_bo_util.c | 12 +++-
>> drivers/gpu/drm/ttm/ttm_bo_vm.c | 6 --
>> 2 files changed, 15 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
>> b/drivers/gpu/drm/ttm/ttm_bo_util.c
>> index 046a6dda690a..b3f5d26f571e 100644
>> --- a/drivers/gpu/drm/ttm/ttm_bo_util.c
>> +++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
>> @@ -29,6 +29,7 @@
>> * Authors: Thomas Hellstrom
>> */
>> +#include
>> #include
>> #include
>> #include
>> @@ -639,7 +640,11 @@ int ttm_bo_kmap(struct ttm_buffer_object *bo,
>> if (ret)
>> return ret;
>> if (!bo->mem.bus.is_iomem) {
>> - return ttm_bo_kmap_ttm(bo, start_page, num_pages, map);
>> + ret = ttm_bo_kmap_ttm(bo, start_page, num_pages, map);
>> + if (!ret && sev_active())
>> + set_memory_decrypted((unsigned long) map->virtual,
>> + num_pages);
>> + return ret;
>> } else {
>> offset = start_page << PAGE_SHIFT;
>> size = num_pages << PAGE_SHIFT;
>> @@ -661,9 +666,14 @@ void ttm_bo_kunmap(struct ttm_bo_kmap_obj *map)
>> iounmap(map->virtual);
>> break;
>> case ttm_bo_map_vmap:
>> + if (sev_active())
>> + set_memory_encrypted((unsigned long)
[pull] amdgpu drm-next-4.19
Hi Dave, Fixes for 4.19: - Fix build when KCOV is enabled - Misc display fixes - A couple of SR-IOV fixes - Fence fixes for eviction handling for KFD - Misc other fixes The following changes since commit 3d63a3c14741ed015948943076f3c6a2f2cd7b27: Merge tag 'drm-msm-next-2018-08-10' of git://people.freedesktop.org/~robclark/linux into drm-next (2018-08-17 10:46:51 +1000) are available in the git repository at: git://people.freedesktop.org/~agd5f/linux drm-next-4.19 for you to fetch changes up to 9d1d02ff36783f954a206dfbf7943b7f2057f58b: drm/amd/display: Don't build DCN1 when kcov is enabled (2018-08-21 14:33:59 -0500) Alex Deucher (1): drm/amdgpu/display: disable eDP fast boot optimization on DCE8 Christian König (3): drm/amdgpu: fix incorrect use of fcheck drm/amdgpu: fix incorrect use of drm_file->pid drm/amdgpu: fix amdgpu_amdkfd_remove_eviction_fence v3 Dmytro Laktyushkin (3): drm/amd/display: fix dp_ss_control vbios flag parsing drm/amd/display: make dp_ss_off optional drm/amd/display: fix dentist did ranges Evan Quan (1): drm/amdgpu: set correct base for THM/NBIF/MP1 IP Leo (Sunpeng) Li (2): Revert "drm/amdgpu/display: Replace CONFIG_DRM_AMD_DC_DCN1_0 with CONFIG_X86" drm/amd/display: Don't build DCN1 when kcov is enabled Samson Tam (1): drm/amd/display: Do not retain link settings Yintian Tao (2): drm/amdgpu: access register without KIQ drm/powerplay: enable dpm under pass-through drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 103 + drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_sched.c | 21 ++--- drivers/gpu/drm/amd/amdgpu/vega20_reg_init.c | 3 + drivers/gpu/drm/amd/amdgpu/vi.c| 4 +- drivers/gpu/drm/amd/display/Kconfig| 6 ++ drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 10 +- drivers/gpu/drm/amd/display/dc/Makefile| 2 +- .../amd/display/dc/bios/command_table_helper2.c| 2 +- drivers/gpu/drm/amd/display/dc/calcs/Makefile | 2 +- drivers/gpu/drm/amd/display/dc/core/dc.c | 21 - drivers/gpu/drm/amd/display/dc/core/dc_debug.c | 2 +- drivers/gpu/drm/amd/display/dc/core/dc_link.c | 6 +- drivers/gpu/drm/amd/display/dc/core/dc_resource.c | 12 +-- drivers/gpu/drm/amd/display/dc/dc.h| 2 +- .../gpu/drm/amd/display/dc/dce/dce_clock_source.c | 6 +- .../gpu/drm/amd/display/dc/dce/dce_clock_source.h | 2 +- drivers/gpu/drm/amd/display/dc/dce/dce_clocks.c| 18 ++-- drivers/gpu/drm/amd/display/dc/dce/dce_clocks.h| 2 +- drivers/gpu/drm/amd/display/dc/dce/dce_dmcu.c | 6 +- .../drm/amd/display/dc/dce/dce_stream_encoder.c| 20 ++-- .../amd/display/dc/dce110/dce110_hw_sequencer.c| 10 +- drivers/gpu/drm/amd/display/dc/gpio/Makefile | 2 +- drivers/gpu/drm/amd/display/dc/gpio/hw_factory.c | 4 +- drivers/gpu/drm/amd/display/dc/gpio/hw_translate.c | 4 +- drivers/gpu/drm/amd/display/dc/i2caux/Makefile | 2 +- drivers/gpu/drm/amd/display/dc/i2caux/i2caux.c | 4 +- drivers/gpu/drm/amd/display/dc/inc/core_types.h| 7 +- drivers/gpu/drm/amd/display/dc/irq/Makefile| 2 +- drivers/gpu/drm/amd/display/dc/irq/irq_service.c | 2 +- drivers/gpu/drm/amd/display/dc/os_types.h | 2 +- .../gpu/drm/amd/powerplay/hwmgr/hardwaremanager.c | 4 +- 32 files changed, 154 insertions(+), 141 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107560] radeon (amdgpu) GDM flip queue failed invalid argument, DisplayPort issues
https://bugs.freedesktop.org/show_bug.cgi?id=107560 --- Comment #6 from Jorge Blasio --- I've an almost identical issue, however I'm using HDMI and I can get back to the graphical session by switching to VT1 and then back to VT2. The issue happens when exiting games from fullscreen. It started after updating Mesa to Mesa git from the padoka PPA. If I revert to Ubuntu's 18.05 Mesa the issue doesn't happen. I'm attaching my dmesg output. -- 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 107560] radeon (amdgpu) GDM flip queue failed invalid argument, DisplayPort issues
https://bugs.freedesktop.org/show_bug.cgi?id=107560 --- Comment #5 from Jorge Blasio --- Created attachment 141242 --> https://bugs.freedesktop.org/attachment.cgi?id=141242=edit dmesg output -- 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 105251] [Vega10] GPU lockup on boot: VMC page fault
https://bugs.freedesktop.org/show_bug.cgi?id=105251 --- Comment #23 from Andrey Grodzovsky --- (In reply to CheatCodesOfLife from comment #22) > You're welcome. > > Not the exact same problem, no. I can get a hard-lock by trying to use > amdvlk to play rpcs3, but it doesn't produce the same error and it's not as > consistent (takes up to 15 minutes to crash) > > Not sure if it's worth noting but I went back and tried every Cemu version > back to 1.5 and a lot of wine versions going back to 2.8. It happens every > time as soon as the game loads. Let's try to get some debug info for the VMC page fault then - Clone and build our open source register analyzer from here - https://cgit.freedesktop.org/amd/umr/ Install trace-cmd utility Load driver with cmd line parameter amdgpu.vm_fault_stop=2 from grub P.S Best to use latest kernel from here - https://cgit.freedesktop.org/~agd5f/linux/log/?h=amd-staging-drm-next After desktop is loaded type sudo trace-cmd start -e dma_fence -e gpu_scheduler -e amdgpu -v -e "amdgpu:amdgpu_mm_rreg" -e "amdgpu:amdgpu_mm_wreg" -e "amdgpu:amdgpu_iv" to enable kernel event tracing log If possible to launch the game from shell then prepend the command with GALLIUM_DDEBUG=always to dump all the MESA commands into files in ~/ddebug_dumps/ Start the game. When the problem happens do the following - as root cd /sys/kernel/debug/tracing && cat trace > event_dump as normal user or root sudo umr -lb > umr_dump sudo umr -O verbose,use_colour -R gfx[.] >> umr_dump sudo umr -O halt_waves,use_colour -wa >> umr_dump dmesg > dmesg_dump Upload a tar/zip of all those files + all the files from ~/ddebug_dumps/ -- 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 v1 1/7] atmel-hlcdc: renamed directory to drm/atmel/
On Wed, Aug 22, 2018 at 10:09 PM, Sam Ravnborg wrote: > Hi Daniel. > >> > > >> > > I'd strongly suggest you group-maintain the entire atmel stuff in >> > > drm-misc instead of only atmel-hlcdc. >> > >> > If OK with Boris then I am fine with this too. >> > Will suggest so in v2. >> >> Boris acked too, but he's on vacation. He said on irc he'll review the >> patches when he's back. Meanwhile I guess you can prep by getting the fd.o >> account requested: >> >> https://www.freedesktop.org/wiki/AccountRequests/ >> >> And checking out the tooling we use to maintain drm-misc: >> >> https://dri.freedesktop.org/docs/dim/getting-started.html > > With enough on the plate already I decided to postpone this > part until the migration to gitlab is done. > Just to tell this was not ignored, only postponed. Migrating the drm repos will start earliest next year (because fd.o admins need to rework some of the infrastructure). And this is the optimistic estimate. We'll also try to make the transition as seamless as possible for committers (the scripting we're using will auto-upgrade remotes and everything, plus accounts will get migrated). Holding off imo doesn't make sense, just means your driver won't land for another 6 months or so, or at least be in some funny maintainer limbo state. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 4/5] drm: Add support for handling linear tile formats
On Tue, Aug 21, 2018 at 07:30:03PM +0100, Alexandru Gheorghe wrote:
> The previous patch added tile_w and tile_h, which represent the
> horizontal and vertical sizes of a tile.
>
> This one uses that to plumb through drm core in order to be able to
> handle linear tile formats without the need for drivers to roll up
> their own implementation.
>
> This patch had been written with Mali-dp X0L2 and X0L0 in mind which
> is a 1 plane YCbCr 420 format with a 2x2 tile, that uses in average 2
> bytes per pixel and where tiles are laid out in a linear manner.
>
> Now what are the restrictions:
>
> 1. Pitch in bytes is expected to cover at least tile_h * width in
> pixels. Due to this the places where the pitch is checked/used need to
> be updated to take into consideration the tile_w, tile_h and
> tile_size.
> tile_size = cpp * tile_w * tile_h
>
> 2. When doing source cropping plane_src_x/y need to be a multiple of
> tile_w/tile_h and we need to take into consideration the tile_w/tile_h
> when computing the start address.
>
> For all non-tiled formats the tile_w and tile_h will be 1, so if I
> didn't miss anything nothing should change.
>
> Regarding multi-planar linear tile formats, I'm not sure how those
> should be handle I kind of assumed that tile_h/tile_w will have to be
> divided by horizontal/subsampling. Anyway, I think it's best to just
> put an warning in there and handle it when someone tries to add
> support for them.
>
> Signed-off-by: Alexandru Gheorghe
> ---
> drivers/gpu/drm/drm_atomic.c | 8 +++
> drivers/gpu/drm/drm_fb_cma_helper.c | 11 -
> drivers/gpu/drm/drm_fourcc.c | 52
> drivers/gpu/drm/drm_framebuffer.c| 19 +--
> drivers/gpu/drm/drm_gem_framebuffer_helper.c | 10 ++--
> include/drm/drm_fourcc.h | 2 +
> 6 files changed, 94 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 3eb061e11e2e..7a3e893a4cd1 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -1087,6 +1087,14 @@ static int drm_atomic_plane_check(struct drm_plane
> *plane,
> return -ENOSPC;
> }
>
> + /* Make sure source coordinates are a multiple of tile sizes */
> + if ((state->src_x >> 16) % state->fb->format->tile_w ||
> + (state->src_y >> 16) % state->fb->format->tile_h) {
> + DRM_DEBUG_ATOMIC("[PLANE:%d:%s] Source coordinates do not meet
> tile restrictions",
> + plane->base.id, plane->name);
> + return -EINVAL;
> + }
> +
> if (plane_switching_crtc(state->state, plane, state)) {
> DRM_DEBUG_ATOMIC("[PLANE:%d:%s] switching CRTC directly\n",
>plane->base.id, plane->name);
> diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c
> b/drivers/gpu/drm/drm_fb_cma_helper.c
> index 47e0e2f6642d..4d8052adce67 100644
> --- a/drivers/gpu/drm/drm_fb_cma_helper.c
> +++ b/drivers/gpu/drm/drm_fb_cma_helper.c
> @@ -87,6 +87,8 @@ dma_addr_t drm_fb_cma_get_gem_addr(struct drm_framebuffer
> *fb,
> struct drm_gem_cma_object *obj;
> dma_addr_t paddr;
> u8 h_div = 1, v_div = 1;
> + u32 tile_w = drm_format_tile_width(fb->format, plane);
> + u32 tile_h = drm_format_tile_height(fb->format, plane);
>
> obj = drm_fb_cma_get_gem_obj(fb, plane);
> if (!obj)
> @@ -99,8 +101,13 @@ dma_addr_t drm_fb_cma_get_gem_addr(struct drm_framebuffer
> *fb,
> v_div = fb->format->vsub;
> }
>
> - paddr += (fb->format->cpp[plane] * (state->src_x >> 16)) / h_div;
> - paddr += (fb->pitches[plane] * (state->src_y >> 16)) / v_div;
> + paddr += (fb->format->cpp[plane] * tile_w * (state->src_x >> 16))
> + / h_div;
> + /*
> + * For tile formats pitches are expected to cover at least
> + * width * tile_h pixels
> + */
> + paddr += ((fb->pitches[plane] / tile_h) * (state->src_y >> 16)) / v_div;
>
> return paddr;
> }
> diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
> index f55cd93ba2d0..d6c9c5aa4036 100644
> --- a/drivers/gpu/drm/drm_fourcc.c
> +++ b/drivers/gpu/drm/drm_fourcc.c
> @@ -557,3 +557,55 @@ int drm_format_plane_height(int height, uint32_t format,
> int plane)
> return height / info->vsub;
> }
> EXPORT_SYMBOL(drm_format_plane_height);
> +
> +/**
> + * drm_format_tile_width - width of a tile for tile formats, should be 1 for
> all
> + * non-tiled formats.
> + * @format: pixel format
> + * @plane: plane index
> + *
> + * Returns:
> + * The width of a tile, depending on the plane index and horizontal
> sub-sampling
> + */
> +uint32_t drm_format_tile_width(const struct drm_format_info *info, int plane)
> +{
> + WARN_ON(!info->tile_w);
> + if (plane == 0 || info->tile_w == 1)
> + return info->tile_w;
> +
> + /*
> + * Multi planar
Re: [RFC PATCH 0/7] add at91sam9 LCDC DRM driver
Hi Daniel. > > > Based on the above, would it be possible to utilise some > > > of these features without any dedicated userspace (mesa) support? > > > Any other driver that has something similar that can be used > > > for inspiration? > > > > This is really an interesting question indeed. > > Needs userspace like everything else. There's unfortunately no real > standard for 2d apis in userspace, which means none of these efforts go > very far. Mostly it's just some custom-made X drivers. > > Adding a generic 2d api to drm is a FAQ, and the answer is "no". And then you went off writing a blog post about it - thanks. The blog post provided a lot of useful answers - great. (Or rather you will write the blog in 5 days, seems to be some time machine involved. (Date is the 27th below the title)). Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 1/7] atmel-hlcdc: renamed directory to drm/atmel/
Hi Daniel. > > > > > > I'd strongly suggest you group-maintain the entire atmel stuff in > > > drm-misc instead of only atmel-hlcdc. > > > > If OK with Boris then I am fine with this too. > > Will suggest so in v2. > > Boris acked too, but he's on vacation. He said on irc he'll review the > patches when he's back. Meanwhile I guess you can prep by getting the fd.o > account requested: > > https://www.freedesktop.org/wiki/AccountRequests/ > > And checking out the tooling we use to maintain drm-misc: > > https://dri.freedesktop.org/docs/dim/getting-started.html With enough on the plate already I decided to postpone this part until the migration to gitlab is done. Just to tell this was not ignored, only postponed. Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Possible use_mm() mis-uses
On Wed, Aug 22, 2018 at 12:44 PM Felix Kuehling wrote: > > You're right, but that's a bit fragile and convoluted. I'll fix KFD to > handle this more robustly. See the attached (untested) patch. Yes, this patch that makes the whole "has to use current mm" or uses "get_task_mm()" looks good from a VM< worry standpoint. Thanks. > And > obviously that opaque pointer didn't work as intended. It just gets > promoted to an mm_struct * without a warning from the compiler. Maybe I > should change that to a long to make abuse easier to spot. Using a "void *" is actually just about the worst possible type for something that should be a cookie, because it silently translates to any pointer. "long" is actually not much better, becuase it will silently convert to any integer type. A good fairly type-safe cookie type is actually this: typedef volatile const struct no_such_struct *cookie_ptr_t; and now something of type "cookie_ptr_t" is actually very hard to convert to other types by mistake. Note that the "volatile const" is not just random noise - it's so that it won't even convert without warnings to things that take a "const void *" as an argument (like, say, the source of 'memcpy()'). So you almost _have_ to explicitly cast it to use it. Linus ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 4/5] drm: Add support for handling linear tile formats
On Tue, Aug 21, 2018 at 07:30:03PM +0100, Alexandru Gheorghe wrote:
> The previous patch added tile_w and tile_h, which represent the
> horizontal and vertical sizes of a tile.
>
> This one uses that to plumb through drm core in order to be able to
> handle linear tile formats without the need for drivers to roll up
> their own implementation.
>
> This patch had been written with Mali-dp X0L2 and X0L0 in mind which
> is a 1 plane YCbCr 420 format with a 2x2 tile, that uses in average 2
> bytes per pixel and where tiles are laid out in a linear manner.
>
> Now what are the restrictions:
>
> 1. Pitch in bytes is expected to cover at least tile_h * width in
> pixels. Due to this the places where the pitch is checked/used need to
> be updated to take into consideration the tile_w, tile_h and
> tile_size.
> tile_size = cpp * tile_w * tile_h
>
> 2. When doing source cropping plane_src_x/y need to be a multiple of
> tile_w/tile_h and we need to take into consideration the tile_w/tile_h
> when computing the start address.
>
> For all non-tiled formats the tile_w and tile_h will be 1, so if I
> didn't miss anything nothing should change.
>
> Regarding multi-planar linear tile formats, I'm not sure how those
> should be handle I kind of assumed that tile_h/tile_w will have to be
> divided by horizontal/subsampling. Anyway, I think it's best to just
> put an warning in there and handle it when someone tries to add
> support for them.
>
> Signed-off-by: Alexandru Gheorghe
Just general comment: I think it'd be awesome (and also a great
demonstration that the tile_h/w approach is sound) if we could subsume the
DRM_FORMAT_MOD_SAMSUNG_64_32_TILE stuff into this.
Probably need a core change to drm_get_format_info for this pair (and
reject it for everything else), with the correct tile sizes set.
-Daniel
> ---
> drivers/gpu/drm/drm_atomic.c | 8 +++
> drivers/gpu/drm/drm_fb_cma_helper.c | 11 -
> drivers/gpu/drm/drm_fourcc.c | 52
> drivers/gpu/drm/drm_framebuffer.c| 19 +--
> drivers/gpu/drm/drm_gem_framebuffer_helper.c | 10 ++--
> include/drm/drm_fourcc.h | 2 +
> 6 files changed, 94 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 3eb061e11e2e..7a3e893a4cd1 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -1087,6 +1087,14 @@ static int drm_atomic_plane_check(struct drm_plane
> *plane,
> return -ENOSPC;
> }
>
> + /* Make sure source coordinates are a multiple of tile sizes */
> + if ((state->src_x >> 16) % state->fb->format->tile_w ||
> + (state->src_y >> 16) % state->fb->format->tile_h) {
> + DRM_DEBUG_ATOMIC("[PLANE:%d:%s] Source coordinates do not meet
> tile restrictions",
> + plane->base.id, plane->name);
> + return -EINVAL;
> + }
> +
> if (plane_switching_crtc(state->state, plane, state)) {
> DRM_DEBUG_ATOMIC("[PLANE:%d:%s] switching CRTC directly\n",
>plane->base.id, plane->name);
> diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c
> b/drivers/gpu/drm/drm_fb_cma_helper.c
> index 47e0e2f6642d..4d8052adce67 100644
> --- a/drivers/gpu/drm/drm_fb_cma_helper.c
> +++ b/drivers/gpu/drm/drm_fb_cma_helper.c
> @@ -87,6 +87,8 @@ dma_addr_t drm_fb_cma_get_gem_addr(struct drm_framebuffer
> *fb,
> struct drm_gem_cma_object *obj;
> dma_addr_t paddr;
> u8 h_div = 1, v_div = 1;
> + u32 tile_w = drm_format_tile_width(fb->format, plane);
> + u32 tile_h = drm_format_tile_height(fb->format, plane);
>
> obj = drm_fb_cma_get_gem_obj(fb, plane);
> if (!obj)
> @@ -99,8 +101,13 @@ dma_addr_t drm_fb_cma_get_gem_addr(struct drm_framebuffer
> *fb,
> v_div = fb->format->vsub;
> }
>
> - paddr += (fb->format->cpp[plane] * (state->src_x >> 16)) / h_div;
> - paddr += (fb->pitches[plane] * (state->src_y >> 16)) / v_div;
> + paddr += (fb->format->cpp[plane] * tile_w * (state->src_x >> 16))
> + / h_div;
> + /*
> + * For tile formats pitches are expected to cover at least
> + * width * tile_h pixels
> + */
> + paddr += ((fb->pitches[plane] / tile_h) * (state->src_y >> 16)) / v_div;
>
> return paddr;
> }
> diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
> index f55cd93ba2d0..d6c9c5aa4036 100644
> --- a/drivers/gpu/drm/drm_fourcc.c
> +++ b/drivers/gpu/drm/drm_fourcc.c
> @@ -557,3 +557,55 @@ int drm_format_plane_height(int height, uint32_t format,
> int plane)
> return height / info->vsub;
> }
> EXPORT_SYMBOL(drm_format_plane_height);
> +
> +/**
> + * drm_format_tile_width - width of a tile for tile formats, should be 1 for
> all
> + * non-tiled formats.
> + * @format: pixel format
> + * @plane: plane index
> + *
> + *
Re: Possible use_mm() mis-uses
On Wed, Aug 22, 2018 at 10:58 PM Linus Torvalds wrote: > > On Wed, Aug 22, 2018 at 12:37 PM Oded Gabbay wrote: > > > > Having said that, I think we *are* protected by the mmu_notifier > > release because if the process suddenly dies, we will gracefully clean > > the process's data in our driver and on the H/W before returning to > > the mm core code. And before we return to the mm core code, we set the > > mm pointer to NULL. And the graceful cleaning should be serialized > > with the load_hqd uses. > > So I'm a bit nervous about the mmu_notifier model (and the largely > equivalent exit_aio() model for the USB gardget AIO uses). > > The reason I'm nervous about it is that the mmu_notifier() gets called > only after the mm_users count has already been decremented to zero > (and the exact same thing goes for exit_aio()). > > Now that's fine if you actually get rid of all accesses in > mmu_notifier_release() or in exit_aio(), because the page tables still > exist at that point - they are in the process of being torn down, but > they haven't been torn down yet. > > But for something like a kernel thread doing use_mm(), the thing that > worries me is a pattern something like this: > > kwork thread exit thread > > > mmput() -> > mm_users goes to zero > > use_mm(mmptr); > .. > > mmu_notifier_release(); > exit_mm() -> > exit_aio() > > and the pattern is basically the same regatdless of whether you use > mmu_notifier_release() or depend on some exit_aio() flushing your aio > work: the use_mm() can be called with a mm that has already had its > mm_users count decremented to zero, and that is now scheduled to be > free'd. > > Does it "work"? Yes. Kind of. At least if the mmu notifier and/or > exit_aio() actually makes sure to wait for any kwork thread thing. But > it's a bit of a worrisome pattern. > >Linus Yes, agreed, and that's why we will be on the safe side and eliminate this pattern from our code and make sure we won't add this pattern in the future. Oded ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Possible use_mm() mis-uses
On Wed, Aug 22, 2018 at 12:37 PM Oded Gabbay wrote:
>
> Having said that, I think we *are* protected by the mmu_notifier
> release because if the process suddenly dies, we will gracefully clean
> the process's data in our driver and on the H/W before returning to
> the mm core code. And before we return to the mm core code, we set the
> mm pointer to NULL. And the graceful cleaning should be serialized
> with the load_hqd uses.
So I'm a bit nervous about the mmu_notifier model (and the largely
equivalent exit_aio() model for the USB gardget AIO uses).
The reason I'm nervous about it is that the mmu_notifier() gets called
only after the mm_users count has already been decremented to zero
(and the exact same thing goes for exit_aio()).
Now that's fine if you actually get rid of all accesses in
mmu_notifier_release() or in exit_aio(), because the page tables still
exist at that point - they are in the process of being torn down, but
they haven't been torn down yet.
But for something like a kernel thread doing use_mm(), the thing that
worries me is a pattern something like this:
kwork thread exit thread
mmput() ->
mm_users goes to zero
use_mm(mmptr);
..
mmu_notifier_release();
exit_mm() ->
exit_aio()
and the pattern is basically the same regatdless of whether you use
mmu_notifier_release() or depend on some exit_aio() flushing your aio
work: the use_mm() can be called with a mm that has already had its
mm_users count decremented to zero, and that is now scheduled to be
free'd.
Does it "work"? Yes. Kind of. At least if the mmu notifier and/or
exit_aio() actually makes sure to wait for any kwork thread thing. But
it's a bit of a worrisome pattern.
Linus
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/5] drm/fourcc: Add tile width and height to drm_format_info
On Tue, Aug 21, 2018 at 07:30:01PM +0100, Alexandru Gheorghe wrote:
> Add two new fields(tile_w and tile_h) to drm_format_info, which
> represent the horizontal and vertical sizes of a tile in tiled
> formats.
> This fields will be used by the next patch to add support in drm
> core for handling framebuffer restrictions and to correctly handle
> source cropping.
>
> Additionally, since I was touching drm_format_info table I decided to
> break the lines to the 80 characters limit, they were already getting
> out of hand, but let's not focus on that, I don't have any problem
> going back to the original line sizes or style them other way, if
> someone wants me to.
>
> Signed-off-by: Alexandru Gheorghe
> ---
> drivers/gpu/drm/drm_fourcc.c | 352 +++
> include/drm/drm_fourcc.h | 4 +
> 2 files changed, 281 insertions(+), 75 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
> index 18bb960e9943..f55cd93ba2d0 100644
> --- a/drivers/gpu/drm/drm_fourcc.c
> +++ b/drivers/gpu/drm/drm_fourcc.c
> @@ -105,81 +105,283 @@ EXPORT_SYMBOL(drm_get_format_name);
> const struct drm_format_info *__drm_format_info(u32 format)
> {
> static const struct drm_format_info formats[] = {
> - { .format = DRM_FORMAT_C8, .depth = 8,
> .num_planes = 1, .cpp = { 1, 0, 0 }, .hsub = 1, .vsub = 1 },
> - { .format = DRM_FORMAT_RGB332, .depth = 8,
> .num_planes = 1, .cpp = { 1, 0, 0 }, .hsub = 1, .vsub = 1 },
> - { .format = DRM_FORMAT_BGR233, .depth = 8,
> .num_planes = 1, .cpp = { 1, 0, 0 }, .hsub = 1, .vsub = 1 },
> - { .format = DRM_FORMAT_XRGB,.depth = 0,
> .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 1, .vsub = 1 },
> - { .format = DRM_FORMAT_XBGR,.depth = 0,
> .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 1, .vsub = 1 },
> - { .format = DRM_FORMAT_RGBX,.depth = 0,
> .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 1, .vsub = 1 },
> - { .format = DRM_FORMAT_BGRX,.depth = 0,
> .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 1, .vsub = 1 },
> - { .format = DRM_FORMAT_ARGB,.depth = 0,
> .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true
> },
> - { .format = DRM_FORMAT_ABGR,.depth = 0,
> .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true
> },
> - { .format = DRM_FORMAT_RGBA,.depth = 0,
> .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true
> },
> - { .format = DRM_FORMAT_BGRA,.depth = 0,
> .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true
> },
> - { .format = DRM_FORMAT_XRGB1555,.depth = 15,
> .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 1, .vsub = 1 },
> - { .format = DRM_FORMAT_XBGR1555,.depth = 15,
> .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 1, .vsub = 1 },
> - { .format = DRM_FORMAT_RGBX5551,.depth = 15,
> .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 1, .vsub = 1 },
> - { .format = DRM_FORMAT_BGRX5551,.depth = 15,
> .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 1, .vsub = 1 },
> - { .format = DRM_FORMAT_ARGB1555,.depth = 15,
> .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true
> },
> - { .format = DRM_FORMAT_ABGR1555,.depth = 15,
> .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true
> },
> - { .format = DRM_FORMAT_RGBA5551,.depth = 15,
> .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true
> },
> - { .format = DRM_FORMAT_BGRA5551,.depth = 15,
> .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true
> },
> - { .format = DRM_FORMAT_RGB565, .depth = 16,
> .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 1, .vsub = 1 },
> - { .format = DRM_FORMAT_BGR565, .depth = 16,
> .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 1, .vsub = 1 },
> - { .format = DRM_FORMAT_RGB888, .depth = 24,
> .num_planes = 1, .cpp = { 3, 0, 0 }, .hsub = 1, .vsub = 1 },
> - { .format = DRM_FORMAT_BGR888, .depth = 24,
> .num_planes = 1, .cpp = { 3, 0, 0 }, .hsub = 1, .vsub = 1 },
> - { .format = DRM_FORMAT_XRGB,.depth = 24,
> .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1 },
> - { .format = DRM_FORMAT_XBGR,.depth = 24,
> .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1 },
> - { .format = DRM_FORMAT_RGBX,.depth = 24,
> .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1 },
> - { .format = DRM_FORMAT_BGRX,.depth = 24,
> .num_planes = 1, .cpp =
Re: [PATCH v2 4/5] drm: Add support for handling linear tile formats
On Wed, Aug 22, 2018 at 4:05 PM, Alexandru-Cosmin Gheorghe
wrote:
> On Wed, Aug 22, 2018 at 04:45:34PM +0300, Ville Syrjälä wrote:
>> On Wed, Aug 22, 2018 at 02:36:06PM +0100, Alexandru-Cosmin Gheorghe wrote:
>> > On Wed, Aug 22, 2018 at 04:18:54PM +0300, Ville Syrjälä wrote:
>> > > On Tue, Aug 21, 2018 at 07:30:03PM +0100, Alexandru Gheorghe wrote:
>> > > > The previous patch added tile_w and tile_h, which represent the
>> > > > horizontal and vertical sizes of a tile.
>> > > >
>> > > > This one uses that to plumb through drm core in order to be able to
>> > > > handle linear tile formats without the need for drivers to roll up
>> > > > their own implementation.
>> > > >
>> > > > This patch had been written with Mali-dp X0L2 and X0L0 in mind which
>> > > > is a 1 plane YCbCr 420 format with a 2x2 tile, that uses in average 2
>> > > > bytes per pixel and where tiles are laid out in a linear manner.
>> > > >
>> > > > Now what are the restrictions:
>> > > >
>> > > > 1. Pitch in bytes is expected to cover at least tile_h * width in
>> > > > pixels. Due to this the places where the pitch is checked/used need to
>> > > > be updated to take into consideration the tile_w, tile_h and
>> > > > tile_size.
>> > > > tile_size = cpp * tile_w * tile_h
>> > > >
>> > > > 2. When doing source cropping plane_src_x/y need to be a multiple of
>> > > > tile_w/tile_h and we need to take into consideration the tile_w/tile_h
>> > > > when computing the start address.
>> > > >
>> > > > For all non-tiled formats the tile_w and tile_h will be 1, so if I
>> > > > didn't miss anything nothing should change.
>> > > >
>> > > > Regarding multi-planar linear tile formats, I'm not sure how those
>> > > > should be handle I kind of assumed that tile_h/tile_w will have to be
>> > > > divided by horizontal/subsampling. Anyway, I think it's best to just
>> > > > put an warning in there and handle it when someone tries to add
>> > > > support for them.
>> > > >
>> > > > Signed-off-by: Alexandru Gheorghe
>> > > > ---
>> > > > drivers/gpu/drm/drm_atomic.c | 8 +++
>> > > > drivers/gpu/drm/drm_fb_cma_helper.c | 11 -
>> > > > drivers/gpu/drm/drm_fourcc.c | 52
>> > > > drivers/gpu/drm/drm_framebuffer.c| 19 +--
>> > > > drivers/gpu/drm/drm_gem_framebuffer_helper.c | 10 ++--
>> > > > include/drm/drm_fourcc.h | 2 +
>> > > > 6 files changed, 94 insertions(+), 8 deletions(-)
>> > > >
>> > > > diff --git a/drivers/gpu/drm/drm_atomic.c
>> > > > b/drivers/gpu/drm/drm_atomic.c
>> > > > index 3eb061e11e2e..7a3e893a4cd1 100644
>> > > > --- a/drivers/gpu/drm/drm_atomic.c
>> > > > +++ b/drivers/gpu/drm/drm_atomic.c
>> > > > @@ -1087,6 +1087,14 @@ static int drm_atomic_plane_check(struct
>> > > > drm_plane *plane,
>> > > > return -ENOSPC;
>> > > > }
>> > > >
>> > > > + /* Make sure source coordinates are a multiple of tile sizes */
>> > > > + if ((state->src_x >> 16) % state->fb->format->tile_w ||
>> > > > + (state->src_y >> 16) % state->fb->format->tile_h) {
>> > > > + DRM_DEBUG_ATOMIC("[PLANE:%d:%s] Source coordinates do
>> > > > not meet tile restrictions",
>> > > > +plane->base.id, plane->name);
>> > > > + return -EINVAL;
>> > > > + }
>> > >
>> > > Feels rather wrong to me to put such hardware specific limitations into
>> > > the core.
>> >
>> > Yeah, the problem is that otherwise drm_fb_cma_get_gem_addr wouldn't
>> > work.
>>
>> If that guy is supposed to give you a tile aligned address then it could
>> just do that and leave it up to the driver to deal with the remainder of
>> the coordinates?
>>
>> >
>> > An alternative, would be to include it in the driver and put an WARN
>> > in drm_fb_cma_get_gem_addr in case someone else uses it with a
>> > src_x/src_y tile multiples.
>> >
>> > What do you think about that ?
>> >
>> > >
>> > > > +
>> > > > if (plane_switching_crtc(state->state, plane, state)) {
>> > > > DRM_DEBUG_ATOMIC("[PLANE:%d:%s] switching CRTC
>> > > > directly\n",
>> > > > plane->base.id, plane->name);
>> > > > diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c
>> > > > b/drivers/gpu/drm/drm_fb_cma_helper.c
>> > > > index 47e0e2f6642d..4d8052adce67 100644
>> > > > --- a/drivers/gpu/drm/drm_fb_cma_helper.c
>> > > > +++ b/drivers/gpu/drm/drm_fb_cma_helper.c
>> > > > @@ -87,6 +87,8 @@ dma_addr_t drm_fb_cma_get_gem_addr(struct
>> > > > drm_framebuffer *fb,
>> > > > struct drm_gem_cma_object *obj;
>> > > > dma_addr_t paddr;
>> > > > u8 h_div = 1, v_div = 1;
>> > > > + u32 tile_w = drm_format_tile_width(fb->format, plane);
>> > > > + u32 tile_h = drm_format_tile_height(fb->format, plane);
>> > > >
>> > > > obj = drm_fb_cma_get_gem_obj(fb, plane);
>> > > > if (!obj)
>> > > > @@ -99,8 +101,13 @@ dma_addr_t
Re: Possible use_mm() mis-uses
On 2018-08-22 02:13 PM, Christian König wrote: > Adding Felix because the KFD part of amdgpu is actually his > responsibility. > > If I'm not completely mistaken the release callback of the > mmu_notifier should take care of that for amdgpu. You're right, but that's a bit fragile and convoluted. I'll fix KFD to handle this more robustly. See the attached (untested) patch. And obviously that opaque pointer didn't work as intended. It just gets promoted to an mm_struct * without a warning from the compiler. Maybe I should change that to a long to make abuse easier to spot. Regards, Felix > > Regards, > Christian. > > Am 22.08.2018 um 18:44 schrieb Linus Torvalds: >> Guys and gals, >> this is a *very* random list of people on the recipients list, but we >> had a subtle TLB shootdown issue in the VM, and that brought up some >> issues when people then went through the code more carefully. >> >> I think we have a handle on the TLB shootdown bug itself. But when >> people were discussing all the possible situations, one thing that >> came up was "use_mm()" that takes a mm, and makes it temporarily the >> mm for a kernel thread (until "unuse_mm()", duh). >> >> And it turns out that some of those uses are definitely wrong, some of >> them are right, and some of them are suspect or at least so overly >> complicated that it's hard for the VM people to know if they are ok. >> >> Basically, the rule for "use_mm()" is that the mm in question *has* to >> have a valid page table associated with it over the whole use_mm() -> >> unuse_mm() sequence. That may sound obvious, and I guess it actually >> is so obvious that there isn't even a comment about it, but the actual >> users are showing that it's sadly apparently not so obvious after all. >> >> There is one user that uses the "obviously correct" model: the vhost >> driver does a "mmget()" and "mmput()" pair around its use of it, >> thanks to vhost_dev_set_owner() doing a >> >> dev->mm = get_task_mm(current); >> >> to look up the mm, and then the teardown case does a >> >> if (dev->mm) >> mmput(dev->mm); >> dev->mm = NULL; >> >> This is the *right* sequence. A gold star to the vhost people. >> >> Sadly, the vhost people are the only ones who seem to get things >> unquestionably right. And some of those gold star people are also >> apparently involved in the cases that didn't get things right. >> >> An example of something that *isn't* right, is the i915 kvm interface, >> which does >> >> use_mm(kvm->mm); >> >> on an mm that was initialized in virt/kvm/kvm_main.c using >> >> mmgrab(current->mm); >> kvm->mm = current->mm; >> >> which is *not* right. Using "mmgrab()" does indeed guarantee the >> lifetime of the 'struct mm_struct' itself, but it does *not* guarantee >> the lifetime of the page tables. You need to use "mmget()" and >> "mmput()", which get the reference to the actual process address >> space! >> >> Now, it is *possible* that the kvm use is correct too, because kvm >> does register a mmu_notifier chain, and in theory you can avoid the >> proper refcounting by just making sure the mmu "release" notifier >> kills any existing uses, but I don't really see kvm doing that. Kvm >> does register a release notifier, but that just flushes the shadow >> page tables, it doesn't kill any use_mm() use by some i915 use case. >> >> So while the vhost use looks right, the kvm/i915 use looks definitely >> wrong. >> >> The other users of "use_mm()" and "unuse_mm()" are less >> black-and-white right vs wrong.. >> >> One of the complex ones is the amdgpu driver. It does a >> "use_mm(mmptr)" deep deep in the guts of a macro that ends up being >> used in fa few places, and it's very hard to tell if it's right. >> >> It looks almost certainly buggy (there is no mmget/mmput to get the >> refcount), but there _is_ a "release" mmu_notifier function and that >> one - unlike the kvm case - looks like it might actually be trying to >> flush the existing pending users of that mm. >> >> But on the whole, I'm suspicious of the amdgpu use. It smells. Jann >> Horn pointed out that even if it migth be ok due to the mmu_notifier, >> the comments are garbage: >> >>> Where "process" in the uniquely-named "struct queue" is a "struct >>> kfd_process"; that struct's definition has this comment in it: >>> >>> /* >>> * Opaque pointer to mm_struct. We don't hold a reference to >>> * it so it should never be dereferenced from here. This is >>> * only used for looking up processes by their mm. >>> */ >>> void *mm; >>> >>> So I think either that comment is wrong, or their code is wrong? >> so I'm chalking the amdgpu use up in the "broken" column. >> >> It's also actually quite hard to synchronze with some other kernel >> worker thread correctly, so just on general principles, if you use >> "use_mm()" it really really should be on something that you've >> properly gotten a
[PULL] drm-misc-next-fixes
Hi Dave, A couple fixes for you that didn't quite make your -rc1 pull last week. I'm sending this since Gustavo is busy organizing linuxdev-br. drm-misc-next-fixes-2018-08-22: - Add an unprepare delay to the tv123wam panel (Sean) - Update seanpaul's email in MAINTAINERS (Sean) Cc: seanp...@chromium.org Cc: s...@poorly.run Cheers, Sean The following changes since commit 2ead1be54b22ccdc93d3030172993e363128f1b4: drm/vkms: Fix connector leak at the module removal (2018-07-28 16:09:39 -0300) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-fixes-2018-08-22 for you to fetch changes up to 4acd8d01a2393f2145ad1db10b2d5c764582a98d: MAINTAINERS: drm-misc: Change seanpaul's email address (2018-08-16 11:48:24 -0400) - Add an unprepare delay to the tv123wam panel (Sean) - Update seanpaul's email in MAINTAINERS (Sean) Cc: seanp...@chromium.org Cc: s...@poorly.run Sean Paul (2): drm/panel: simple: tv123wam: Add unprepare delay MAINTAINERS: drm-misc: Change seanpaul's email address MAINTAINERS | 2 +- drivers/gpu/drm/panel/panel-simple.c | 3 +++ 2 files changed, 4 insertions(+), 1 deletion(-) -- Sean Paul, Software Engineer, Google / Chromium OS ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Possible use_mm() mis-uses
On Wed, Aug 22, 2018 at 7:44 PM Linus Torvalds wrote: > One of the complex ones is the amdgpu driver. It does a > "use_mm(mmptr)" deep deep in the guts of a macro that ends up being > used in fa few places, and it's very hard to tell if it's right. > > It looks almost certainly buggy (there is no mmget/mmput to get the > refcount), but there _is_ a "release" mmu_notifier function and that > one - unlike the kvm case - looks like it might actually be trying to > flush the existing pending users of that mm. > > But on the whole, I'm suspicious of the amdgpu use. It smells. Jann > Horn pointed out that even if it migth be ok due to the mmu_notifier, > the comments are garbage: > > > Where "process" in the uniquely-named "struct queue" is a "struct > > kfd_process"; that struct's definition has this comment in it: > > > >/* > > * Opaque pointer to mm_struct. We don't hold a reference to > > * it so it should never be dereferenced from here. This is > > * only used for looking up processes by their mm. > > */ > >void *mm; > > > > So I think either that comment is wrong, or their code is wrong? > > so I'm chalking the amdgpu use up in the "broken" column. > Hello Linus, I looked at the amdkfd code and indeed the comment does not match the actual code because the mm pointer is clearly dereferenced directly in the macro you mentioned (read_user_wptr). That macro is used in the code path of loading a descriptor to the H/W (load_hqd). That function is called in several cases, where in some of them we are in the context of the calling process, but in others we are in a kernel thread context (hence the use_mm). That's why we check these two situations inside that macro and only do use_mm if we are in kernel thread. We need to fix that behavior and obviously make sure that in future code we don't cast this pointer to mm_struct* and derereference it directly. Actually, the original code had "mm_struct *mm" instead of "void *mm" in the structure, and I think the reason we changed it to void* is to "make sure" that we won't dereference it directly, but clearly that failed :( Having said that, I think we *are* protected by the mmu_notifier release because if the process suddenly dies, we will gracefully clean the process's data in our driver and on the H/W before returning to the mm core code. And before we return to the mm core code, we set the mm pointer to NULL. And the graceful cleaning should be serialized with the load_hqd uses. Felix, do you have anything to add here that I might have missed ? Thanks, Oded ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/2] drm/msm/dpu: fix for cursor blend issue
On Wed, Aug 22, 2018 at 11:19:57PM +0530, Sravanthi Kollukuduru wrote:
> The current driver has the opaque blend mode set as the
> default causing the black box effect around the cursor.
> The fix enables choosing a different blend mode for alpha
> enabled formats.
>
> Changes in V2:
> - Use drm_get_format_name() in the logs (Sean)
>
> Signed-off-by: Sravanthi Kollukuduru
Reviewed-by: Sean Paul
I've applied this to dpu-staging/for-next.
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 26 +-
> 1 file changed, 21 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> index 0cd9456a6c4c..07c2d15b45f2 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> @@ -297,14 +297,29 @@ static void dpu_crtc_destroy(struct drm_crtc *crtc)
> }
>
> static void _dpu_crtc_setup_blend_cfg(struct dpu_crtc_mixer *mixer,
> - struct dpu_plane_state *pstate)
> + struct dpu_plane_state *pstate, struct dpu_format *format)
> {
> struct dpu_hw_mixer *lm = mixer->hw_lm;
> + uint32_t blend_op;
> + struct drm_format_name_buf format_name;
>
> /* default to opaque blending */
> - lm->ops.setup_blend_config(lm, pstate->stage, 0XFF, 0,
> - DPU_BLEND_FG_ALPHA_FG_CONST |
> - DPU_BLEND_BG_ALPHA_BG_CONST);
> + blend_op = DPU_BLEND_FG_ALPHA_FG_CONST |
> + DPU_BLEND_BG_ALPHA_BG_CONST;
> +
> + if (format->alpha_enable) {
> + /* coverage blending */
> + blend_op = DPU_BLEND_FG_ALPHA_FG_PIXEL |
> + DPU_BLEND_BG_ALPHA_FG_PIXEL |
> + DPU_BLEND_BG_INV_ALPHA;
> + }
> +
> + lm->ops.setup_blend_config(lm, pstate->stage,
> + 0xFF, 0, blend_op);
> +
> + DPU_DEBUG("format:%s, alpha_en:%u blend_op:0x%x\n",
> + drm_get_format_name(format->base.pixel_format, _name),
> + format->alpha_enable, blend_op);
> }
>
> static void _dpu_crtc_program_lm_output_roi(struct drm_crtc *crtc)
> @@ -401,7 +416,8 @@ static void _dpu_crtc_blend_setup_mixer(struct drm_crtc
> *crtc,
>
> /* blend config update */
> for (lm_idx = 0; lm_idx < dpu_crtc->num_mixers; lm_idx++) {
> - _dpu_crtc_setup_blend_cfg(mixer + lm_idx, pstate);
> + _dpu_crtc_setup_blend_cfg(mixer + lm_idx,
> + pstate, format);
>
> mixer[lm_idx].flush_mask |= flush_mask;
>
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
>
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/2] drm/msm/dpu: enable cursor plane on dpu
On Wed, Aug 22, 2018 at 11:19:56PM +0530, Sravanthi Kollukuduru wrote:
> Reserve DMA pipe for cursor plane and attach it to the
> crtc during the initialization.
>
> Changes in V2:
> None
>
> Signed-off-by: Sravanthi Kollukuduru
In the future, if someone gives you a Reviewed-by: on a previous version, you
should add it to subsequent versions so people know it's already bee acked.
Reviewed-by: Sean Paul
I've applied this to dpu-staging/for-next.
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 5 ++-
> drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h | 4 +-
> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 53
> +++---
> drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c| 35 +++--
> drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 9 +
> drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h | 4 +-
> 6 files changed, 55 insertions(+), 55 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> index 80cbf75bc2ff..0cd9456a6c4c 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> @@ -2082,7 +2082,8 @@ static const struct drm_crtc_helper_funcs
> dpu_crtc_helper_funcs = {
> };
>
> /* initialize crtc */
> -struct drm_crtc *dpu_crtc_init(struct drm_device *dev, struct drm_plane
> *plane)
> +struct drm_crtc *dpu_crtc_init(struct drm_device *dev, struct drm_plane
> *plane,
> + struct drm_plane *cursor)
> {
> struct drm_crtc *crtc = NULL;
> struct dpu_crtc *dpu_crtc = NULL;
> @@ -2119,7 +2120,7 @@ struct drm_crtc *dpu_crtc_init(struct drm_device *dev,
> struct drm_plane *plane)
> dpu_crtc_frame_event_work);
> }
>
> - drm_crtc_init_with_planes(dev, crtc, plane, NULL, _crtc_funcs,
> + drm_crtc_init_with_planes(dev, crtc, plane, cursor, _crtc_funcs,
> NULL);
>
> drm_crtc_helper_add(crtc, _crtc_helper_funcs);
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
> index e87109e608e9..a89679160237 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
> @@ -375,9 +375,11 @@ void dpu_crtc_complete_commit(struct drm_crtc *crtc,
> * dpu_crtc_init - create a new crtc object
> * @dev: dpu device
> * @plane: base plane
> + * @cursor: cursor plane
> * @Return: new crtc object or error
> */
> -struct drm_crtc *dpu_crtc_init(struct drm_device *dev, struct drm_plane
> *plane);
> +struct drm_crtc *dpu_crtc_init(struct drm_device *dev, struct drm_plane
> *plane,
> +struct drm_plane *cursor);
>
> /**
> * dpu_crtc_register_custom_event - api for enabling/disabling crtc event
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
> index 44ee06398b1d..c04f3f3acae4 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
> @@ -29,6 +29,9 @@
> BIT(DPU_SSPP_TS_PREFILL) | BIT(DPU_SSPP_TS_PREFILL_REC1) |\
> BIT(DPU_SSPP_CDP) | BIT(DPU_SSPP_EXCL_RECT))
>
> +#define DMA_CURSOR_SDM845_MASK \
> + (DMA_SDM845_MASK | BIT(DPU_SSPP_CURSOR))
> +
> #define MIXER_SDM845_MASK \
> (BIT(DPU_MIXER_SOURCESPLIT) | BIT(DPU_DIM_LAYER))
>
> @@ -174,45 +177,35 @@ static const struct dpu_sspp_sub_blks sdm845_dma_sblk_1
> = _DMA_SBLK("9", 2);
> static const struct dpu_sspp_sub_blks sdm845_dma_sblk_2 = _DMA_SBLK("10", 3);
> static const struct dpu_sspp_sub_blks sdm845_dma_sblk_3 = _DMA_SBLK("11", 4);
>
> -#define SSPP_VIG_BLK(_name, _id, _base, _sblk, _xinid, _clkctrl) \
> - { \
> - .name = _name, .id = _id, \
> - .base = _base, .len = 0x1c8, \
> - .features = VIG_SDM845_MASK, \
> - .sblk = &_sblk, \
> - .xin_id = _xinid, \
> - .type = SSPP_TYPE_VIG, \
> - .clk_ctrl = _clkctrl \
> - }
> -
> -#define SSPP_DMA_BLK(_name, _id, _base, _sblk, _xinid, _clkctrl) \
> +#define SSPP_BLK(_name, _id, _base, _features, \
> + _sblk, _xinid, _type, _clkctrl) \
> { \
> .name = _name, .id = _id, \
> .base = _base, .len = 0x1c8, \
> - .features = DMA_SDM845_MASK, \
> + .features = _features, \
> .sblk = &_sblk, \
> .xin_id = _xinid, \
> - .type = SSPP_TYPE_DMA, \
> + .type = _type, \
> .clk_ctrl = _clkctrl \
> }
>
> static struct dpu_sspp_cfg sdm845_sspp[] = {
> - SSPP_VIG_BLK("sspp_0", SSPP_VIG0, 0x4000,
> - sdm845_vig_sblk_0, 0, DPU_CLK_CTRL_VIG0),
> - SSPP_VIG_BLK("sspp_1", SSPP_VIG1, 0x6000,
> - sdm845_vig_sblk_1, 4, DPU_CLK_CTRL_VIG1),
> - SSPP_VIG_BLK("sspp_2", SSPP_VIG2, 0x8000,
> - sdm845_vig_sblk_2, 8, DPU_CLK_CTRL_VIG2),
> - SSPP_VIG_BLK("sspp_3", SSPP_VIG3, 0xa000,
> - sdm845_vig_sblk_3, 12, DPU_CLK_CTRL_VIG3),
>
Re: [PATCH 1/1] drm/ttm: Set memory as decrypted for ttm framebuffer mappings
Am 22.08.2018 um 20:57 schrieb Jiandi An:
Framebuffer memory needs to be accessed decrypted. Ensure the
memory encryption mask is not set for the ttm framebuffer mappings.
NAK, the memory not only needs to be decrypted while CPU accessed but
all the time.
ttm_page_alloc.c and ttm_page_alloc_dma.c should already take care of
that while mapping the pages.
Regards,
Christian.
Signed-off-by: Jiandi An
---
drivers/gpu/drm/ttm/ttm_bo_util.c | 12 +++-
drivers/gpu/drm/ttm/ttm_bo_vm.c | 6 --
2 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index 046a6dda690a..b3f5d26f571e 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -29,6 +29,7 @@
* Authors: Thomas Hellstrom
*/
+#include
#include
#include
#include
@@ -639,7 +640,11 @@ int ttm_bo_kmap(struct ttm_buffer_object *bo,
if (ret)
return ret;
if (!bo->mem.bus.is_iomem) {
- return ttm_bo_kmap_ttm(bo, start_page, num_pages, map);
+ ret = ttm_bo_kmap_ttm(bo, start_page, num_pages, map);
+ if (!ret && sev_active())
+ set_memory_decrypted((unsigned long) map->virtual,
+num_pages);
+ return ret;
} else {
offset = start_page << PAGE_SHIFT;
size = num_pages << PAGE_SHIFT;
@@ -661,9 +666,14 @@ void ttm_bo_kunmap(struct ttm_bo_kmap_obj *map)
iounmap(map->virtual);
break;
case ttm_bo_map_vmap:
+ if (sev_active())
+ set_memory_encrypted((unsigned long) map->virtual,
+bo->num_pages);
vunmap(map->virtual);
break;
case ttm_bo_map_kmap:
+ if (sev_active())
+ set_memory_encrypted((unsigned long) map->virtual, 1);
kunmap(map->page);
break;
case ttm_bo_map_premapped:
diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
index 6fe91c1b692d..211d3549fd9f 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
@@ -249,10 +249,12 @@ static vm_fault_t ttm_bo_vm_fault(struct vm_fault *vmf)
* Speculatively prefault a number of pages. Only error on
* first page.
*/
+
+ /* Mark framebuffer pages decrypted */
+ cvma.vm_page_prot = pgprot_decrypted(cvma.vm_page_prot);
+
for (i = 0; i < TTM_BO_VM_NUM_PREFAULT; ++i) {
if (bo->mem.bus.is_iomem) {
- /* Iomem should not be marked encrypted */
- cvma.vm_page_prot = pgprot_decrypted(cvma.vm_page_prot);
pfn = ttm_bo_io_mem_pfn(bo, page_offset);
} else {
page = ttm->pages[page_offset];
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Possible use_mm() mis-uses
Hi Linus: Thanks for letting us know that. We would fix this ASAP. The kvmgt.c module is a part of GVT-g code. It's our fault that we didn't find this mis-uses, not i915 or KVM guys. Wish they would feel better after seeing this message. Thanks, Zhi. On 08/23/18 00:44, Linus Torvalds wrote: Guys and gals, this is a *very* random list of people on the recipients list, but we had a subtle TLB shootdown issue in the VM, and that brought up some issues when people then went through the code more carefully. I think we have a handle on the TLB shootdown bug itself. But when people were discussing all the possible situations, one thing that came up was "use_mm()" that takes a mm, and makes it temporarily the mm for a kernel thread (until "unuse_mm()", duh). And it turns out that some of those uses are definitely wrong, some of them are right, and some of them are suspect or at least so overly complicated that it's hard for the VM people to know if they are ok. Basically, the rule for "use_mm()" is that the mm in question *has* to have a valid page table associated with it over the whole use_mm() -> unuse_mm() sequence. That may sound obvious, and I guess it actually is so obvious that there isn't even a comment about it, but the actual users are showing that it's sadly apparently not so obvious after all. There is one user that uses the "obviously correct" model: the vhost driver does a "mmget()" and "mmput()" pair around its use of it, thanks to vhost_dev_set_owner() doing a dev->mm = get_task_mm(current); to look up the mm, and then the teardown case does a if (dev->mm) mmput(dev->mm); dev->mm = NULL; This is the *right* sequence. A gold star to the vhost people. Sadly, the vhost people are the only ones who seem to get things unquestionably right. And some of those gold star people are also apparently involved in the cases that didn't get things right. An example of something that *isn't* right, is the i915 kvm interface, which does use_mm(kvm->mm); on an mm that was initialized in virt/kvm/kvm_main.c using mmgrab(current->mm); kvm->mm = current->mm; which is *not* right. Using "mmgrab()" does indeed guarantee the lifetime of the 'struct mm_struct' itself, but it does *not* guarantee the lifetime of the page tables. You need to use "mmget()" and "mmput()", which get the reference to the actual process address space! Now, it is *possible* that the kvm use is correct too, because kvm does register a mmu_notifier chain, and in theory you can avoid the proper refcounting by just making sure the mmu "release" notifier kills any existing uses, but I don't really see kvm doing that. Kvm does register a release notifier, but that just flushes the shadow page tables, it doesn't kill any use_mm() use by some i915 use case. So while the vhost use looks right, the kvm/i915 use looks definitely wrong. The other users of "use_mm()" and "unuse_mm()" are less black-and-white right vs wrong.. One of the complex ones is the amdgpu driver. It does a "use_mm(mmptr)" deep deep in the guts of a macro that ends up being used in fa few places, and it's very hard to tell if it's right. It looks almost certainly buggy (there is no mmget/mmput to get the refcount), but there _is_ a "release" mmu_notifier function and that one - unlike the kvm case - looks like it might actually be trying to flush the existing pending users of that mm. But on the whole, I'm suspicious of the amdgpu use. It smells. Jann Horn pointed out that even if it migth be ok due to the mmu_notifier, the comments are garbage: Where "process" in the uniquely-named "struct queue" is a "struct kfd_process"; that struct's definition has this comment in it: /* * Opaque pointer to mm_struct. We don't hold a reference to * it so it should never be dereferenced from here. This is * only used for looking up processes by their mm. */ void *mm; So I think either that comment is wrong, or their code is wrong? so I'm chalking the amdgpu use up in the "broken" column. It's also actually quite hard to synchronze with some other kernel worker thread correctly, so just on general principles, if you use "use_mm()" it really really should be on something that you've properly gotten a mm refcount on with mmget(). Really. Even if you try to synchronize things. The two final cases are two uses in the USB gadget driver. Again, they don't have the proper mmget/mmput, but they may br ok simply because the uses are done for AIO, and the VM teardown is preceded by an AIO teardown, so the proper serialization may come in from that. Anyway, sorry for the long email, and the big list of participants and odd mailing lists, but I'd really like people to look at their "use_mm()" cases, and ask themselves if they have done enough to guarantee that the full mm exists. Again, "mmgrab()" is *not* enough on its own. You need either
[PATCH 1/1] drm/ttm: Set memory as decrypted for ttm framebuffer mappings
Framebuffer memory needs to be accessed decrypted. Ensure the
memory encryption mask is not set for the ttm framebuffer mappings.
Signed-off-by: Jiandi An
---
drivers/gpu/drm/ttm/ttm_bo_util.c | 12 +++-
drivers/gpu/drm/ttm/ttm_bo_vm.c | 6 --
2 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index 046a6dda690a..b3f5d26f571e 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -29,6 +29,7 @@
* Authors: Thomas Hellstrom
*/
+#include
#include
#include
#include
@@ -639,7 +640,11 @@ int ttm_bo_kmap(struct ttm_buffer_object *bo,
if (ret)
return ret;
if (!bo->mem.bus.is_iomem) {
- return ttm_bo_kmap_ttm(bo, start_page, num_pages, map);
+ ret = ttm_bo_kmap_ttm(bo, start_page, num_pages, map);
+ if (!ret && sev_active())
+ set_memory_decrypted((unsigned long) map->virtual,
+num_pages);
+ return ret;
} else {
offset = start_page << PAGE_SHIFT;
size = num_pages << PAGE_SHIFT;
@@ -661,9 +666,14 @@ void ttm_bo_kunmap(struct ttm_bo_kmap_obj *map)
iounmap(map->virtual);
break;
case ttm_bo_map_vmap:
+ if (sev_active())
+ set_memory_encrypted((unsigned long) map->virtual,
+bo->num_pages);
vunmap(map->virtual);
break;
case ttm_bo_map_kmap:
+ if (sev_active())
+ set_memory_encrypted((unsigned long) map->virtual, 1);
kunmap(map->page);
break;
case ttm_bo_map_premapped:
diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
index 6fe91c1b692d..211d3549fd9f 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
@@ -249,10 +249,12 @@ static vm_fault_t ttm_bo_vm_fault(struct vm_fault *vmf)
* Speculatively prefault a number of pages. Only error on
* first page.
*/
+
+ /* Mark framebuffer pages decrypted */
+ cvma.vm_page_prot = pgprot_decrypted(cvma.vm_page_prot);
+
for (i = 0; i < TTM_BO_VM_NUM_PREFAULT; ++i) {
if (bo->mem.bus.is_iomem) {
- /* Iomem should not be marked encrypted */
- cvma.vm_page_prot = pgprot_decrypted(cvma.vm_page_prot);
pfn = ttm_bo_io_mem_pfn(bo, page_offset);
} else {
page = ttm->pages[page_offset];
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Possible use_mm() mis-uses
On Wed, Aug 22, 2018 at 11:33 AM Linus Torvalds wrote: > > On Wed, Aug 22, 2018 at 11:21 AM Paolo Bonzini wrote: > > > > Yes, KVM is correct but the i915 bits are at least fishy. It's probably > > as simple as adding a mmget/mmput pair respectively in kvmgt_guest_init > > and kvmgt_guest_exit, or maybe mmget_not_zero. > > Definitely mmget_not_zero(). If it was just mmgrab()'ed earlier, the > actual page tables might already be gone. Side note: we _could_ do the mmget_not_zero() inside use_mm() itself, if we just knew that the mm was at least mmgrab()'ed correctly. But for some of the uses, even that isn't clear. It's not entirely obvious that the "struct mm_struct" exists _at_all_ at that point, and that a mmget_not_zero() wouldn't just have some use-after-free access. Again, independent lifetime rules could show that this isn't the case (ie "exit_aio() is always called before exit_mmap(), and kill_ioctx() takes care of it all"), but it would be good to have the users of "use_mm()" actually verify their lifetime rules are correct and enforced. Because quite often, the lifetime rule might nbot be a mmu notifier or aio_exit at all, but just be "oh, the user won't exit until this is all done". But do you *control* the user? What if the user is buggy? Linus ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/syncobj: Drop add/remove_callback from driver interface
On Wed, Aug 22, 2018 at 11:09:21AM -0500, Jason Ekstrand wrote:
> Fine with me.
>
> Reviewed-by: Jason Ekstrand
Thanks for the review, applied to drm-misc-next.
-Daniel
>
> On Wed, Aug 22, 2018 at 4:29 AM Daniel Vetter
> wrote:
>
> > This is used for handling future fences. Currently no driver use
> > these, and I think given the new timeline fence proposed by KHR it
> > would be better to have a more abstract interface for future fences.
> > Could be something simple like a struct dma_future_fence plus a
> > function to add a callback or wait for the fence to materialize.
> >
> > Then syncobj (and anything else really) could grow new functions to
> > expose these two drivers. Normal dma_fence would then keep the nice
> > guarantee that they will always signal (and through ordering, be
> > deadlock free). dma_future_fence would then be the tricky one.
> >
> > This also fixes sphinx complaining about the kerneldoc.
> >
> > Cc: Jason Ekstrand
> > Cc: Dave Airlie
> > Cc: Chris Wilson
> > Signed-off-by: Daniel Vetter
> > ---
> > drivers/gpu/drm/drm_syncobj.c | 15 ---
> > include/drm/drm_syncobj.h | 5 -
> > 2 files changed, 20 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
> > index adb3cb27d31e..3a8837c49639 100644
> > --- a/drivers/gpu/drm/drm_syncobj.c
> > +++ b/drivers/gpu/drm/drm_syncobj.c
> > @@ -120,14 +120,6 @@ static int
> > drm_syncobj_fence_get_or_add_callback(struct drm_syncobj *syncobj,
> > return ret;
> > }
> >
> > -/**
> > - * drm_syncobj_add_callback - adds a callback to syncobj::cb_list
> > - * @syncobj: Sync object to which to add the callback
> > - * @cb: Callback to add
> > - * @func: Func to use when initializing the drm_syncobj_cb struct
> > - *
> > - * This adds a callback to be called next time the fence is replaced
> > - */
> > void drm_syncobj_add_callback(struct drm_syncobj *syncobj,
> > struct drm_syncobj_cb *cb,
> > drm_syncobj_func_t func)
> > @@ -136,13 +128,7 @@ void drm_syncobj_add_callback(struct drm_syncobj
> > *syncobj,
> > drm_syncobj_add_callback_locked(syncobj, cb, func);
> > spin_unlock(>lock);
> > }
> > -EXPORT_SYMBOL(drm_syncobj_add_callback);
> >
> > -/**
> > - * drm_syncobj_add_callback - removes a callback to syncobj::cb_list
> > - * @syncobj: Sync object from which to remove the callback
> > - * @cb: Callback to remove
> > - */
> > void drm_syncobj_remove_callback(struct drm_syncobj *syncobj,
> > struct drm_syncobj_cb *cb)
> > {
> > @@ -150,7 +136,6 @@ void drm_syncobj_remove_callback(struct drm_syncobj
> > *syncobj,
> > list_del_init(>node);
> > spin_unlock(>lock);
> > }
> > -EXPORT_SYMBOL(drm_syncobj_remove_callback);
> >
> > /**
> > * drm_syncobj_replace_fence - replace fence in a sync object.
> > diff --git a/include/drm/drm_syncobj.h b/include/drm/drm_syncobj.h
> > index 3980602472c0..e419c79ba94d 100644
> > --- a/include/drm/drm_syncobj.h
> > +++ b/include/drm/drm_syncobj.h
> > @@ -131,11 +131,6 @@ drm_syncobj_fence_get(struct drm_syncobj *syncobj)
> >
> > struct drm_syncobj *drm_syncobj_find(struct drm_file *file_private,
> > u32 handle);
> > -void drm_syncobj_add_callback(struct drm_syncobj *syncobj,
> > - struct drm_syncobj_cb *cb,
> > - drm_syncobj_func_t func);
> > -void drm_syncobj_remove_callback(struct drm_syncobj *syncobj,
> > -struct drm_syncobj_cb *cb);
> > void drm_syncobj_replace_fence(struct drm_syncobj *syncobj,
> >struct dma_fence *fence);
> > int drm_syncobj_find_fence(struct drm_file *file_private,
> > --
> > 2.18.0
> >
> >
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Possible use_mm() mis-uses
On Wed, Aug 22, 2018 at 11:21 AM Paolo Bonzini wrote: > > Yes, KVM is correct but the i915 bits are at least fishy. It's probably > as simple as adding a mmget/mmput pair respectively in kvmgt_guest_init > and kvmgt_guest_exit, or maybe mmget_not_zero. Definitely mmget_not_zero(). If it was just mmgrab()'ed earlier, the actual page tables might already be gone. Linus ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Possible use_mm() mis-uses
On 22/08/2018 18:44, Linus Torvalds wrote: > An example of something that *isn't* right, is the i915 kvm interface, > which does > > use_mm(kvm->mm); > > on an mm that was initialized in virt/kvm/kvm_main.c using > > mmgrab(current->mm); > kvm->mm = current->mm; > > which is *not* right. Using "mmgrab()" does indeed guarantee the > lifetime of the 'struct mm_struct' itself, but it does *not* guarantee > the lifetime of the page tables. You need to use "mmget()" and > "mmput()", which get the reference to the actual process address > space! > > Now, it is *possible* that the kvm use is correct too, because kvm > does register a mmu_notifier chain, and in theory you can avoid the > proper refcounting by just making sure the mmu "release" notifier > kills any existing uses, but I don't really see kvm doing that. Kvm > does register a release notifier, but that just flushes the shadow > page tables, it doesn't kill any use_mm() use by some i915 use case. Yes, KVM is correct but the i915 bits are at least fishy. It's probably as simple as adding a mmget/mmput pair respectively in kvmgt_guest_init and kvmgt_guest_exit, or maybe mmget_not_zero. Paolo ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Possible use_mm() mis-uses
Adding Felix because the KFD part of amdgpu is actually his responsibility. If I'm not completely mistaken the release callback of the mmu_notifier should take care of that for amdgpu. Regards, Christian. Am 22.08.2018 um 18:44 schrieb Linus Torvalds: Guys and gals, this is a *very* random list of people on the recipients list, but we had a subtle TLB shootdown issue in the VM, and that brought up some issues when people then went through the code more carefully. I think we have a handle on the TLB shootdown bug itself. But when people were discussing all the possible situations, one thing that came up was "use_mm()" that takes a mm, and makes it temporarily the mm for a kernel thread (until "unuse_mm()", duh). And it turns out that some of those uses are definitely wrong, some of them are right, and some of them are suspect or at least so overly complicated that it's hard for the VM people to know if they are ok. Basically, the rule for "use_mm()" is that the mm in question *has* to have a valid page table associated with it over the whole use_mm() -> unuse_mm() sequence. That may sound obvious, and I guess it actually is so obvious that there isn't even a comment about it, but the actual users are showing that it's sadly apparently not so obvious after all. There is one user that uses the "obviously correct" model: the vhost driver does a "mmget()" and "mmput()" pair around its use of it, thanks to vhost_dev_set_owner() doing a dev->mm = get_task_mm(current); to look up the mm, and then the teardown case does a if (dev->mm) mmput(dev->mm); dev->mm = NULL; This is the *right* sequence. A gold star to the vhost people. Sadly, the vhost people are the only ones who seem to get things unquestionably right. And some of those gold star people are also apparently involved in the cases that didn't get things right. An example of something that *isn't* right, is the i915 kvm interface, which does use_mm(kvm->mm); on an mm that was initialized in virt/kvm/kvm_main.c using mmgrab(current->mm); kvm->mm = current->mm; which is *not* right. Using "mmgrab()" does indeed guarantee the lifetime of the 'struct mm_struct' itself, but it does *not* guarantee the lifetime of the page tables. You need to use "mmget()" and "mmput()", which get the reference to the actual process address space! Now, it is *possible* that the kvm use is correct too, because kvm does register a mmu_notifier chain, and in theory you can avoid the proper refcounting by just making sure the mmu "release" notifier kills any existing uses, but I don't really see kvm doing that. Kvm does register a release notifier, but that just flushes the shadow page tables, it doesn't kill any use_mm() use by some i915 use case. So while the vhost use looks right, the kvm/i915 use looks definitely wrong. The other users of "use_mm()" and "unuse_mm()" are less black-and-white right vs wrong.. One of the complex ones is the amdgpu driver. It does a "use_mm(mmptr)" deep deep in the guts of a macro that ends up being used in fa few places, and it's very hard to tell if it's right. It looks almost certainly buggy (there is no mmget/mmput to get the refcount), but there _is_ a "release" mmu_notifier function and that one - unlike the kvm case - looks like it might actually be trying to flush the existing pending users of that mm. But on the whole, I'm suspicious of the amdgpu use. It smells. Jann Horn pointed out that even if it migth be ok due to the mmu_notifier, the comments are garbage: Where "process" in the uniquely-named "struct queue" is a "struct kfd_process"; that struct's definition has this comment in it: /* * Opaque pointer to mm_struct. We don't hold a reference to * it so it should never be dereferenced from here. This is * only used for looking up processes by their mm. */ void *mm; So I think either that comment is wrong, or their code is wrong? so I'm chalking the amdgpu use up in the "broken" column. It's also actually quite hard to synchronze with some other kernel worker thread correctly, so just on general principles, if you use "use_mm()" it really really should be on something that you've properly gotten a mm refcount on with mmget(). Really. Even if you try to synchronize things. The two final cases are two uses in the USB gadget driver. Again, they don't have the proper mmget/mmput, but they may br ok simply because the uses are done for AIO, and the VM teardown is preceded by an AIO teardown, so the proper serialization may come in from that. Anyway, sorry for the long email, and the big list of participants and odd mailing lists, but I'd really like people to look at their "use_mm()" cases, and ask themselves if they have done enough to guarantee that the full mm exists. Again, "mmgrab()" is *not* enough on its own. You need either "mmget()" or some lifetime guarantee. And if
[PATCH v2 1/2] drm/msm/dpu: enable cursor plane on dpu
Reserve DMA pipe for cursor plane and attach it to the
crtc during the initialization.
Changes in V2:
None
Signed-off-by: Sravanthi Kollukuduru
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 5 ++-
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h | 4 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 53 +++---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c| 35 +++--
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 9 +
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h | 4 +-
6 files changed, 55 insertions(+), 55 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index 80cbf75bc2ff..0cd9456a6c4c 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -2082,7 +2082,8 @@ static const struct drm_crtc_helper_funcs
dpu_crtc_helper_funcs = {
};
/* initialize crtc */
-struct drm_crtc *dpu_crtc_init(struct drm_device *dev, struct drm_plane *plane)
+struct drm_crtc *dpu_crtc_init(struct drm_device *dev, struct drm_plane *plane,
+ struct drm_plane *cursor)
{
struct drm_crtc *crtc = NULL;
struct dpu_crtc *dpu_crtc = NULL;
@@ -2119,7 +2120,7 @@ struct drm_crtc *dpu_crtc_init(struct drm_device *dev,
struct drm_plane *plane)
dpu_crtc_frame_event_work);
}
- drm_crtc_init_with_planes(dev, crtc, plane, NULL, _crtc_funcs,
+ drm_crtc_init_with_planes(dev, crtc, plane, cursor, _crtc_funcs,
NULL);
drm_crtc_helper_add(crtc, _crtc_helper_funcs);
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
index e87109e608e9..a89679160237 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
@@ -375,9 +375,11 @@ void dpu_crtc_complete_commit(struct drm_crtc *crtc,
* dpu_crtc_init - create a new crtc object
* @dev: dpu device
* @plane: base plane
+ * @cursor: cursor plane
* @Return: new crtc object or error
*/
-struct drm_crtc *dpu_crtc_init(struct drm_device *dev, struct drm_plane
*plane);
+struct drm_crtc *dpu_crtc_init(struct drm_device *dev, struct drm_plane *plane,
+ struct drm_plane *cursor);
/**
* dpu_crtc_register_custom_event - api for enabling/disabling crtc event
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
index 44ee06398b1d..c04f3f3acae4 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
@@ -29,6 +29,9 @@
BIT(DPU_SSPP_TS_PREFILL) | BIT(DPU_SSPP_TS_PREFILL_REC1) |\
BIT(DPU_SSPP_CDP) | BIT(DPU_SSPP_EXCL_RECT))
+#define DMA_CURSOR_SDM845_MASK \
+ (DMA_SDM845_MASK | BIT(DPU_SSPP_CURSOR))
+
#define MIXER_SDM845_MASK \
(BIT(DPU_MIXER_SOURCESPLIT) | BIT(DPU_DIM_LAYER))
@@ -174,45 +177,35 @@ static const struct dpu_sspp_sub_blks sdm845_dma_sblk_1 =
_DMA_SBLK("9", 2);
static const struct dpu_sspp_sub_blks sdm845_dma_sblk_2 = _DMA_SBLK("10", 3);
static const struct dpu_sspp_sub_blks sdm845_dma_sblk_3 = _DMA_SBLK("11", 4);
-#define SSPP_VIG_BLK(_name, _id, _base, _sblk, _xinid, _clkctrl) \
- { \
- .name = _name, .id = _id, \
- .base = _base, .len = 0x1c8, \
- .features = VIG_SDM845_MASK, \
- .sblk = &_sblk, \
- .xin_id = _xinid, \
- .type = SSPP_TYPE_VIG, \
- .clk_ctrl = _clkctrl \
- }
-
-#define SSPP_DMA_BLK(_name, _id, _base, _sblk, _xinid, _clkctrl) \
+#define SSPP_BLK(_name, _id, _base, _features, \
+ _sblk, _xinid, _type, _clkctrl) \
{ \
.name = _name, .id = _id, \
.base = _base, .len = 0x1c8, \
- .features = DMA_SDM845_MASK, \
+ .features = _features, \
.sblk = &_sblk, \
.xin_id = _xinid, \
- .type = SSPP_TYPE_DMA, \
+ .type = _type, \
.clk_ctrl = _clkctrl \
}
static struct dpu_sspp_cfg sdm845_sspp[] = {
- SSPP_VIG_BLK("sspp_0", SSPP_VIG0, 0x4000,
- sdm845_vig_sblk_0, 0, DPU_CLK_CTRL_VIG0),
- SSPP_VIG_BLK("sspp_1", SSPP_VIG1, 0x6000,
- sdm845_vig_sblk_1, 4, DPU_CLK_CTRL_VIG1),
- SSPP_VIG_BLK("sspp_2", SSPP_VIG2, 0x8000,
- sdm845_vig_sblk_2, 8, DPU_CLK_CTRL_VIG2),
- SSPP_VIG_BLK("sspp_3", SSPP_VIG3, 0xa000,
- sdm845_vig_sblk_3, 12, DPU_CLK_CTRL_VIG3),
- SSPP_DMA_BLK("sspp_8", SSPP_DMA0, 0x24000,
- sdm845_dma_sblk_0, 1, DPU_CLK_CTRL_DMA0),
- SSPP_DMA_BLK("sspp_9", SSPP_DMA1, 0x26000,
- sdm845_dma_sblk_1, 5, DPU_CLK_CTRL_DMA1),
- SSPP_DMA_BLK("sspp_10", SSPP_DMA2, 0x28000,
- sdm845_dma_sblk_2, 9, DPU_CLK_CTRL_CURSOR0),
- SSPP_DMA_BLK("sspp_11", SSPP_DMA3, 0x2a000,
- sdm845_dma_sblk_3, 13, DPU_CLK_CTRL_CURSOR1),
+
[PATCH v2 2/2] drm/msm/dpu: fix for cursor blend issue
The current driver has the opaque blend mode set as the
default causing the black box effect around the cursor.
The fix enables choosing a different blend mode for alpha
enabled formats.
Changes in V2:
- Use drm_get_format_name() in the logs (Sean)
Signed-off-by: Sravanthi Kollukuduru
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 26 +-
1 file changed, 21 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index 0cd9456a6c4c..07c2d15b45f2 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -297,14 +297,29 @@ static void dpu_crtc_destroy(struct drm_crtc *crtc)
}
static void _dpu_crtc_setup_blend_cfg(struct dpu_crtc_mixer *mixer,
- struct dpu_plane_state *pstate)
+ struct dpu_plane_state *pstate, struct dpu_format *format)
{
struct dpu_hw_mixer *lm = mixer->hw_lm;
+ uint32_t blend_op;
+ struct drm_format_name_buf format_name;
/* default to opaque blending */
- lm->ops.setup_blend_config(lm, pstate->stage, 0XFF, 0,
- DPU_BLEND_FG_ALPHA_FG_CONST |
- DPU_BLEND_BG_ALPHA_BG_CONST);
+ blend_op = DPU_BLEND_FG_ALPHA_FG_CONST |
+ DPU_BLEND_BG_ALPHA_BG_CONST;
+
+ if (format->alpha_enable) {
+ /* coverage blending */
+ blend_op = DPU_BLEND_FG_ALPHA_FG_PIXEL |
+ DPU_BLEND_BG_ALPHA_FG_PIXEL |
+ DPU_BLEND_BG_INV_ALPHA;
+ }
+
+ lm->ops.setup_blend_config(lm, pstate->stage,
+ 0xFF, 0, blend_op);
+
+ DPU_DEBUG("format:%s, alpha_en:%u blend_op:0x%x\n",
+ drm_get_format_name(format->base.pixel_format, _name),
+ format->alpha_enable, blend_op);
}
static void _dpu_crtc_program_lm_output_roi(struct drm_crtc *crtc)
@@ -401,7 +416,8 @@ static void _dpu_crtc_blend_setup_mixer(struct drm_crtc
*crtc,
/* blend config update */
for (lm_idx = 0; lm_idx < dpu_crtc->num_mixers; lm_idx++) {
- _dpu_crtc_setup_blend_cfg(mixer + lm_idx, pstate);
+ _dpu_crtc_setup_blend_cfg(mixer + lm_idx,
+ pstate, format);
mixer[lm_idx].flush_mask |= flush_mask;
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 0/2] Enable cursor plane on DPU
s patchset adds the cursor plane support on DPU driver. It also includes the fix for the black box artifacts seen around the cursor when enabled. Changes in V2: - Minor comments in logging in blend config function (Sean) Sravanthi Kollukuduru (2): drm/msm/dpu: enable cursor plane on dpu drm/msm/dpu: fix for cursor blend issue drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 31 +++ drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h | 4 +- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 53 +++--- drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c| 35 +++-- drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 9 + drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h | 4 +- 6 files changed, 76 insertions(+), 60 deletions(-) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107516] Firefox for WebGL fallbacks to swrast_dri.so, not using radeon_si.so
https://bugs.freedesktop.org/show_bug.cgi?id=107516 Michel Dänzer changed: What|Removed |Added Component|DRM/AMDgpu |libdrm -- 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 107516] Firefox for WebGL fallbacks to swrast_dri.so, not using radeon_si.so
https://bugs.freedesktop.org/show_bug.cgi?id=107516 --- Comment #7 from Michel Dänzer --- Emil, as it might take a while for users to get the related Firefox sandbox change, would it be possible for libdrm to fall back to the same method that worked before? -- 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 107516] Firefox for WebGL fallbacks to swrast_dri.so, not using radeon_si.so
https://bugs.freedesktop.org/show_bug.cgi?id=107516 Michel Dänzer changed: What|Removed |Added CC||k...@dev.carbon-project.org --- Comment #6 from Michel Dänzer --- *** Bug 107660 has been marked as a duplicate of this 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
[Bug 107660] [regression] Firefox crashes on any WebGL usage with latest libdrm
https://bugs.freedesktop.org/show_bug.cgi?id=107660 Michel Dänzer changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #1 from Michel Dänzer --- *** This bug has been marked as a duplicate of bug 107516 *** -- 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: [igt-dev] RFC: Migration to Gitlab
On Wed, Aug 22, 2018 at 05:37:22PM +0100, Daniel Stone wrote: > Hi Rodrigo, > > On Wed, 22 Aug 2018 at 17:06, Rodrigo Vivi wrote: > > On Wed, Aug 22, 2018 at 10:19:19AM -0400, Adam Jackson wrote: > > > On Wed, 2018-08-22 at 16:13 +0300, Jani Nikula wrote: > > > > - Sticking to fdo bugzilla and disabling gitlab issues for at least > > > > drm-intel for the time being. Doing that migration in the same go is a > > > > bit much I think. Reassignment across bugzilla and gitlab will be an > > > > issue. > > > > > > Can you elaborate a bit on the issues here? The actual move-the-bugs > > > process has been pretty painless for the parts of xorg we've done so > > > far. > > > > I guess there is nothing against moving the bugs there. The concern is only > > on > > doing everything at once. > > > > I'm in favor of moving gits for now and after we are confident that > > everything is there and working we move the bugs. > > As Daniel alluded to, the only issue I really have is moving _all_ the > kernel repos at once. At the end of the year we'll have easy automatic > scaling thanks to the independent services being separated. As it is, > all the GitLab services (apart from CI runners) run on a single > machine, so we have limited options if it becomes overwhelmed with > load. > > Do you have a particular concern about the repos? no concerns from my side about the repos itself. From my committer perspective on libdrm, mesa the migration was really smooth. > e.g. what would you > check for to make sure things are 'there and working'? more in terms of other committers getting used to it, dim working for most of committers, links in documentations and wikis updated... but no concerns with the infra itself. > > > One question about the bugzilla: > > > > Will all the referrences on all commit messages get outdated after > > bugzilla is dead? > > Or bugzilla will stay up for referrence but closed for interaction? > > or all old closed stuff are always moved and bugzilla.fd.o as well and > > bugzilla.fd.o will be mirroring gitlab? > > When bugs are migrated from Bugzilla to GitLab, only open bugs are > migrated. Closed ones are left in place, as is; open ones have a > comment at the end saying that the bug has moved to GitLab, a URL > linking to the new GitLab issue, and telling them to please chase it > up there. > > Even when we move everyone completely off Bugzilla, we will keep it as > a read-only mirror forever. Even with Phabricator, which very few > people ever used, has had all its bugs and code review captured and > archived, so we can continue to preserve all the old content and > links, without having to run the actual service. Great! Thanks for all clarification, Rodrigo. > > Cheers, > Daniel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH V2 4/4] drm/crc: add pre_crc_read function
On Wed, Aug 22, 2018 at 12:37:05PM +0200, Maarten Lankhorst wrote:
> Op 21-08-18 om 10:38 schreef Mahesh Kumar:
> > This patch implements a callback function which will be called before
> > crc read. In this function driver can implement any preparation work
> > required for successfully reading CRC data.
> >
> > Changes Since V1:
> > - rebase
> >
> > Cc: dri-devel@lists.freedesktop.org
> > Signed-off-by: Mahesh Kumar
> After some discussion with David on whether this can be upstreamed, he NACK'd
> it.
> Because there are no upstream users for this callback, it cannot be included
> upstream.
> It would be removed by the first person to notice there are no in-kernel
> users using it.
It makes sense After I posted the review yesterday I started thinking
exactly
about this case... if would get easily removed in a clean-up for obvious
reasons...
> For the first 3 patches:
> Reviewed-by: Maarten Lankhorst
thanks. pushed all 3 to drm-misc-next.
> > drivers/gpu/drm/drm_debugfs_crc.c | 8
> > include/drm/drm_crtc.h| 14 ++
> > 2 files changed, 22 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_debugfs_crc.c
> > b/drivers/gpu/drm/drm_debugfs_crc.c
> > index 00e743153e94..e303c194c080 100644
> > --- a/drivers/gpu/drm/drm_debugfs_crc.c
> > +++ b/drivers/gpu/drm/drm_debugfs_crc.c
> > @@ -274,6 +274,14 @@ static ssize_t crtc_crc_read(struct file *filep, char
> > __user *user_buf,
> > return 0;
> > }
> >
> > + if (crtc->funcs->pre_crc_read) {
> > + ret = crtc->funcs->pre_crc_read(crtc);
> > + if (ret) {
> > + spin_unlock_irq(>lock);
> > + return ret;
> > + }
> > + }
> > +
> > /* Nothing to read? */
> > while (crtc_crc_data_count(crc) == 0) {
> > if (filep->f_flags & O_NONBLOCK) {
> > diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> > index b21437bc95bf..19c2bf63935e 100644
> > --- a/include/drm/drm_crtc.h
> > +++ b/include/drm/drm_crtc.h
> > @@ -761,6 +761,20 @@ struct drm_crtc_funcs {
> > */
> > int (*verify_crc_source)(struct drm_crtc *crtc, const char *source,
> > size_t *values_cnt);
> > + /**
> > +* @pre_crc_read:
> > +*
> > +* Driver callback for performing any preparation work required by
> > +* driver before reading CRC
> > +*
> > +* This callback is optional if the driver does not support CRC
> > +* generation or no prework is required before reading the crc
> > +*
> > +* RETURNS:
> > +*
> > +* 0 on success or a negative error code on failure.
> > +*/
> > + int (*pre_crc_read)(struct drm_crtc *crtc);
> > /**
> > * @get_crc_sources:
> > *
>
>
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Possible use_mm() mis-uses
Guys and gals, this is a *very* random list of people on the recipients list, but we had a subtle TLB shootdown issue in the VM, and that brought up some issues when people then went through the code more carefully. I think we have a handle on the TLB shootdown bug itself. But when people were discussing all the possible situations, one thing that came up was "use_mm()" that takes a mm, and makes it temporarily the mm for a kernel thread (until "unuse_mm()", duh). And it turns out that some of those uses are definitely wrong, some of them are right, and some of them are suspect or at least so overly complicated that it's hard for the VM people to know if they are ok. Basically, the rule for "use_mm()" is that the mm in question *has* to have a valid page table associated with it over the whole use_mm() -> unuse_mm() sequence. That may sound obvious, and I guess it actually is so obvious that there isn't even a comment about it, but the actual users are showing that it's sadly apparently not so obvious after all. There is one user that uses the "obviously correct" model: the vhost driver does a "mmget()" and "mmput()" pair around its use of it, thanks to vhost_dev_set_owner() doing a dev->mm = get_task_mm(current); to look up the mm, and then the teardown case does a if (dev->mm) mmput(dev->mm); dev->mm = NULL; This is the *right* sequence. A gold star to the vhost people. Sadly, the vhost people are the only ones who seem to get things unquestionably right. And some of those gold star people are also apparently involved in the cases that didn't get things right. An example of something that *isn't* right, is the i915 kvm interface, which does use_mm(kvm->mm); on an mm that was initialized in virt/kvm/kvm_main.c using mmgrab(current->mm); kvm->mm = current->mm; which is *not* right. Using "mmgrab()" does indeed guarantee the lifetime of the 'struct mm_struct' itself, but it does *not* guarantee the lifetime of the page tables. You need to use "mmget()" and "mmput()", which get the reference to the actual process address space! Now, it is *possible* that the kvm use is correct too, because kvm does register a mmu_notifier chain, and in theory you can avoid the proper refcounting by just making sure the mmu "release" notifier kills any existing uses, but I don't really see kvm doing that. Kvm does register a release notifier, but that just flushes the shadow page tables, it doesn't kill any use_mm() use by some i915 use case. So while the vhost use looks right, the kvm/i915 use looks definitely wrong. The other users of "use_mm()" and "unuse_mm()" are less black-and-white right vs wrong.. One of the complex ones is the amdgpu driver. It does a "use_mm(mmptr)" deep deep in the guts of a macro that ends up being used in fa few places, and it's very hard to tell if it's right. It looks almost certainly buggy (there is no mmget/mmput to get the refcount), but there _is_ a "release" mmu_notifier function and that one - unlike the kvm case - looks like it might actually be trying to flush the existing pending users of that mm. But on the whole, I'm suspicious of the amdgpu use. It smells. Jann Horn pointed out that even if it migth be ok due to the mmu_notifier, the comments are garbage: > Where "process" in the uniquely-named "struct queue" is a "struct > kfd_process"; that struct's definition has this comment in it: > >/* > * Opaque pointer to mm_struct. We don't hold a reference to > * it so it should never be dereferenced from here. This is > * only used for looking up processes by their mm. > */ >void *mm; > > So I think either that comment is wrong, or their code is wrong? so I'm chalking the amdgpu use up in the "broken" column. It's also actually quite hard to synchronze with some other kernel worker thread correctly, so just on general principles, if you use "use_mm()" it really really should be on something that you've properly gotten a mm refcount on with mmget(). Really. Even if you try to synchronize things. The two final cases are two uses in the USB gadget driver. Again, they don't have the proper mmget/mmput, but they may br ok simply because the uses are done for AIO, and the VM teardown is preceded by an AIO teardown, so the proper serialization may come in from that. Anyway, sorry for the long email, and the big list of participants and odd mailing lists, but I'd really like people to look at their "use_mm()" cases, and ask themselves if they have done enough to guarantee that the full mm exists. Again, "mmgrab()" is *not* enough on its own. You need either "mmget()" or some lifetime guarantee. And if you do have those lifetime guarantees, it would be really nice to get a good explanatory comment about said lifetime guarantees above the "use_mm()" call. Ok? Note that the lifetime rules are very important, because obviously use_mm() itself is never called
Re: [igt-dev] RFC: Migration to Gitlab
Hi Rodrigo, On Wed, 22 Aug 2018 at 17:06, Rodrigo Vivi wrote: > On Wed, Aug 22, 2018 at 10:19:19AM -0400, Adam Jackson wrote: > > On Wed, 2018-08-22 at 16:13 +0300, Jani Nikula wrote: > > > - Sticking to fdo bugzilla and disabling gitlab issues for at least > > > drm-intel for the time being. Doing that migration in the same go is a > > > bit much I think. Reassignment across bugzilla and gitlab will be an > > > issue. > > > > Can you elaborate a bit on the issues here? The actual move-the-bugs > > process has been pretty painless for the parts of xorg we've done so > > far. > > I guess there is nothing against moving the bugs there. The concern is only on > doing everything at once. > > I'm in favor of moving gits for now and after we are confident that > everything is there and working we move the bugs. As Daniel alluded to, the only issue I really have is moving _all_ the kernel repos at once. At the end of the year we'll have easy automatic scaling thanks to the independent services being separated. As it is, all the GitLab services (apart from CI runners) run on a single machine, so we have limited options if it becomes overwhelmed with load. Do you have a particular concern about the repos? e.g. what would you check for to make sure things are 'there and working'? > One question about the bugzilla: > > Will all the referrences on all commit messages get outdated after > bugzilla is dead? > Or bugzilla will stay up for referrence but closed for interaction? > or all old closed stuff are always moved and bugzilla.fd.o as well and > bugzilla.fd.o will be mirroring gitlab? When bugs are migrated from Bugzilla to GitLab, only open bugs are migrated. Closed ones are left in place, as is; open ones have a comment at the end saying that the bug has moved to GitLab, a URL linking to the new GitLab issue, and telling them to please chase it up there. Even when we move everyone completely off Bugzilla, we will keep it as a read-only mirror forever. Even with Phabricator, which very few people ever used, has had all its bugs and code review captured and archived, so we can continue to preserve all the old content and links, without having to run the actual service. Cheers, Daniel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107660] [regression] Firefox crashes on any WebGL usage with latest libdrm
https://bugs.freedesktop.org/show_bug.cgi?id=107660 Bug ID: 107660 Summary: [regression] Firefox crashes on any WebGL usage with latest libdrm Product: DRI Version: XOrg git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Keywords: regression Severity: normal Priority: medium Component: libdrm Assignee: dri-devel@lists.freedesktop.org Reporter: k...@dev.carbon-project.org CC: emil.l.veli...@gmail.com I recently noticed, that tabs in Firefox (Debian package 61.0.1-1 and 61.0.2 from mozilla.org) started crashing on WebGL usage. The easiest trigger is to just visit https://maps.gogle.com/ Since I was pointed towards bug 107384, comment #6 on IRC by Michel Dänzer and I see the loader errors as he described on IRC, I'm assuming this is related. I can't be 100 % sure, because I'm unable to get a proper backtrace from Firefox (see below). It doesn't seem to be the same issue though, because using a libdrm built from Git (f31fd57c60) doesn't fix the crashes for me. I tried attaching GDB to the content process by launching firefox with: $ MOZ_DEBUG_CHILD_PROCESS=1 firefox -safe-mode and then running # gdb /usr/lib/firefox/firefox $PID where $PID is replaced by the actual PID of the tab process, which firefox prints on the console when started with MOZ_DEBUG_CHILD_PROCESS=1. The attaching seems to run fine, gdb is loading a bunch of debug information for all the libraries and Firefox itself. But when I continue from the (gdb) prompt, I immediately run into an endless stream of SIGSYS errors like > Thread 1 "Web Content" received signal SIGSYS, Bad system call. > 0x7f884b08b397 in __access (file=0x7f88370b3360 > "/usr/share/gtk-3.0/settings.ini", type=type@entry=0) at > ../sysdeps/unix/sysv/linux/access.c:27 > 27 ../sysdeps/unix/sysv/linux/access.c: No such file or directory. Probably the sandbox that prevents this? Sadly I haven't found a way around that yet. (Any pointers welcome. Maybe it's possible to instrument libdrm/radeonsi/… in a way, that helpful information can be dumped somewhere, when the tab crashes.) Without GDB the tab just crashes and offers to be closed or reloaded. In the terminal window where I started Firefox (with a clean profile and in safe mode) I get the following error: > libGL error: MESA-LOADER: failed to retrieve device information > libGL error: unable to load driver: amdgpu_dri.so > libGL error: driver pointer missing > libGL error: failed to load driver: amdgpu > libGL error: MESA-LOADER: failed to retrieve device information > libGL error: unable to load driver: amdgpu_dri.so > libGL error: driver pointer missing > libGL error: failed to load driver: amdgpu > [Parent 20860, Gecko_IOThread] WARNING: pipe error (47): Connection reset by > peer: file > /build/firefox-tG9MzV/firefox-61.0.1/ipc/chromium/src/chrome/common/ipc_channel_posix.cc, > line 353 > [Parent 20860, Gecko_IOThread] WARNING: pipe error: Broken pipe: file > /build/firefox-tG9MzV/firefox-61.0.1/ipc/chromium/src/chrome/common/ipc_channel_posix.cc, > line 709 > > ###!!! [Parent][MessageChannel] Error: > (msgtype=0x160068,name=PBrowser::Msg_SynthMouseMoveEvent) Channel error: > cannot send/recv > > > ###!!! [Parent][MessageChannel] Error: > (msgtype=0x16007F,name=PBrowser::Msg_Destroy) Channel error: cannot send/recv The graphics stack I used (fully updated Debian testing as a base) for testing is: GPU: Hawaii PRO [Radeon R9 290] (ChipID = 0x67b1) Mesa: Git:master/5fab32ddad libdrm: Git:master/f31fd57c60 LLVM: SVN:trunk/r340334 (8.0 devel) X.Org: 2:1.20.0-3 Linux: 4.18.3 Firmware (firmware-amd-graphics): 20180518-1 libclc: Git:master/62a9191b60 DDX (xserver-xorg-video-amdgpu): 18.0.1-1+b1 Let me know, if you need anything else. -- 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: [igt-dev] RFC: Migration to Gitlab
Hi, On Wed, 22 Aug 2018 at 15:44, Daniel Vetter wrote: > On Wed, Aug 22, 2018 at 3:13 PM, Jani Nikula > wrote: > > Just a couple of concerns from drm/i915 perspective for starters: > > > > - Patchwork integration. I think we'll want to keep patchwork for at > > least intel-gfx etc. for the time being. IIUC the one thing we need is > > some server side hook to update patchwork on git push. > > > > - Sticking to fdo bugzilla and disabling gitlab issues for at least > > drm-intel for the time being. Doing that migration in the same go is a > > bit much I think. Reassignment across bugzilla and gitlab will be an > > issue. > > Good points, forgot about both. Patchwork reading the mailing list > should keep working as-is, but the update hook needs looking into. All the hooks are retained. gitlab.fd.o pushes to git.fd.o, and git.fd.o still executes all the old hooks. This includes Patchwork, readthedocs, AppVeyor, and whatever else. > For merge requests I think best approach is to enable them very > selectively at first for testing out, and then making a per-subproject > decision whether they make sense. E.g. I think for maintainer-tools > integrating make check and the doc building into gitlab CI would be > sweet, and worth looking into gitlab merge requests just to automate > that. Again best left out of scope for the initial migration. You don't need MRs to do that. You can build a .gitlab-ci.yml file which will run make check or build the docs or whatever, and have that run on pushes. Anyone can then fork the repo, push their changes to that fork, and see the CI results from there. It's like Travis: the CI configuration is a (mutable) part of the codebase, not a separate 'thing' hanging off a specific repo. So if you write the CI pipeline first, you can have people running CI on push completely independently of switching the workflow to use MRs. Cheers, Daniel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: RFC: Migration to Gitlab
Hi, On Wed, 22 Aug 2018 at 16:02, Emil Velikov wrote: > On 22 August 2018 at 12:44, Daniel Vetter wrote: > > I think it's time to brainstorm a bit about the gitlab migration. Basic > > reasons: > > > > - fd.o admins want to deprecate shell accounts and hand-rolled > > infrastructure, because it's a pain to keep secure > > > > - gitlab will allow us to add committers on our own, greatly > > simplifying that process (and offloading that task from fd.o admins). > > Random thought - I really wish the admins spoke early and louder about issues. > From infra to manpower and adhoc tool maintenance. I thought I mostly had it covered, but fair enough. What knowledge are you missing and how should it best be delivered? One first-order issue is that as documented at https://www.freedesktop.org/wiki/AccountRequests/ creating accounts requires manual admin intervention. You can also search the 'freedesktop.org' product on Bugzilla to see the amount of time we spend shuffling around GPG & SSH keys, which is about the worst possible use of my time. Many other people have had access to drive the ancient shell-script frontend to LDAP before, but for some reason they mostly aren't very enthusiastic about doing it all the time. In the mesa-dev@ thread about Mesa's migration, which is linked from my blog post, I went into quite a lot of detail about why Jenkins was not suitable to roll out across fd.o globally. That knowledge was gained from trial & error, which was a lot of time burnt. The end result is that we don't have any CI, except if people hang Travis/AppVeyor off GitHub mirrors. You've personally seen what's involved in setting up Git repository hooks so we can build docs. We can't give access to let people work on those, without giving them direct access to the literal Git repository itself on disk. The hooks mostly involve bespoke sets of rsync jobs and hand-managed SSH credentials and external services to build docs and so on and so forth. None of this is accessible to a newcomer who wants to make a non-code contribution: you have to find someone with access to the repo to go bash some shell scripts directly and hope you didn't screw it up. None of this is auditable, so if the repo mysteriously gets wiped, then hopefully there are some backups somewhere. But there definitely aren't any logs. Luckily we prevent most people from having access to most repositories via a mandatory 'shell' which only allows people to push Git; this was written by hand by us 12 years ago. What else? Our fork of Patchwork was until recently based on an ancient fork of Django, in a bespoke unreproducible production environment. Bugzilla is patched for spam and templates (making upgrades complex), yet we still have a surprising amount of spam pass through. There's no way to delete spam, but you have to manually move every bug to the 'spam' group, then go through and delete the user which involves copying & pasting the email and a few clicks per user. Mailman is patched to support Recaptcha, bringing more upgrade fun. ikiwiki breaks all the time because it's designed to have the public-access web server on the same host as the writeable Git repositories. Our servers are several years old and approaching life expiry, and we have no more spare disk. You can see in #freedesktop IRC the constant network connectivity issues people have to PSU almost every day. Our attempts to root-cause and solve those have got nowhere. I could go on, but the 'moved elsewhere' list in https://gitlab.freedesktop.org/freedesktop/freedesktop/issues/2 indicates that we do have problems to solve, and that changing peoples' SSH keys for them isn't the best way for us to be spending the extremely limited time that we do have. > > For the full in-depth writeup of everything, see > > > > https://www.fooishbar.org/blog/gitlab-fdo-introduction/ If you haven't seen this, or the post it was linked from, they would be a good start: https://lists.freedesktop.org/archives/freedesktop/2018-July/000370.html There's also the long thread on mesa-dev a long time back which covers a lot of this ground already. > > - Figuring out the actual migration - we've been adding a pile of > > committers since fd.o LDAP was converted to gitlab once back in > > spring. We need to at least figure out how to move the new > > accounts/committers. > > As a observer, allow me to put some ideas. You've mostly covered them > all, my emphasis is to seriously stick with _one_ thing at a time. > Attempting to do multiple things in parallel will end up with > sub-optimal results. > > - (at random point) cleanup the committers list - people who have not > contributed in the last 1 year? libdrm was previously covered under the Mesa ACL. Here are the other committer lists, which you can see via 'getent group' on annarchy or another machine: amdkfd:x:922:fxkuehl,agd5f,deathsimple,danvet,jazhou,jbridgman,hwentland,tstdenis,gitlab-mirror,rui drm-meson:x:936:narmstrong drm:x:940:airlied,danvet
Re: [PATCH] drm/syncobj: Drop add/remove_callback from driver interface
Fine with me.
Reviewed-by: Jason Ekstrand
On Wed, Aug 22, 2018 at 4:29 AM Daniel Vetter
wrote:
> This is used for handling future fences. Currently no driver use
> these, and I think given the new timeline fence proposed by KHR it
> would be better to have a more abstract interface for future fences.
> Could be something simple like a struct dma_future_fence plus a
> function to add a callback or wait for the fence to materialize.
>
> Then syncobj (and anything else really) could grow new functions to
> expose these two drivers. Normal dma_fence would then keep the nice
> guarantee that they will always signal (and through ordering, be
> deadlock free). dma_future_fence would then be the tricky one.
>
> This also fixes sphinx complaining about the kerneldoc.
>
> Cc: Jason Ekstrand
> Cc: Dave Airlie
> Cc: Chris Wilson
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_syncobj.c | 15 ---
> include/drm/drm_syncobj.h | 5 -
> 2 files changed, 20 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
> index adb3cb27d31e..3a8837c49639 100644
> --- a/drivers/gpu/drm/drm_syncobj.c
> +++ b/drivers/gpu/drm/drm_syncobj.c
> @@ -120,14 +120,6 @@ static int
> drm_syncobj_fence_get_or_add_callback(struct drm_syncobj *syncobj,
> return ret;
> }
>
> -/**
> - * drm_syncobj_add_callback - adds a callback to syncobj::cb_list
> - * @syncobj: Sync object to which to add the callback
> - * @cb: Callback to add
> - * @func: Func to use when initializing the drm_syncobj_cb struct
> - *
> - * This adds a callback to be called next time the fence is replaced
> - */
> void drm_syncobj_add_callback(struct drm_syncobj *syncobj,
> struct drm_syncobj_cb *cb,
> drm_syncobj_func_t func)
> @@ -136,13 +128,7 @@ void drm_syncobj_add_callback(struct drm_syncobj
> *syncobj,
> drm_syncobj_add_callback_locked(syncobj, cb, func);
> spin_unlock(>lock);
> }
> -EXPORT_SYMBOL(drm_syncobj_add_callback);
>
> -/**
> - * drm_syncobj_add_callback - removes a callback to syncobj::cb_list
> - * @syncobj: Sync object from which to remove the callback
> - * @cb: Callback to remove
> - */
> void drm_syncobj_remove_callback(struct drm_syncobj *syncobj,
> struct drm_syncobj_cb *cb)
> {
> @@ -150,7 +136,6 @@ void drm_syncobj_remove_callback(struct drm_syncobj
> *syncobj,
> list_del_init(>node);
> spin_unlock(>lock);
> }
> -EXPORT_SYMBOL(drm_syncobj_remove_callback);
>
> /**
> * drm_syncobj_replace_fence - replace fence in a sync object.
> diff --git a/include/drm/drm_syncobj.h b/include/drm/drm_syncobj.h
> index 3980602472c0..e419c79ba94d 100644
> --- a/include/drm/drm_syncobj.h
> +++ b/include/drm/drm_syncobj.h
> @@ -131,11 +131,6 @@ drm_syncobj_fence_get(struct drm_syncobj *syncobj)
>
> struct drm_syncobj *drm_syncobj_find(struct drm_file *file_private,
> u32 handle);
> -void drm_syncobj_add_callback(struct drm_syncobj *syncobj,
> - struct drm_syncobj_cb *cb,
> - drm_syncobj_func_t func);
> -void drm_syncobj_remove_callback(struct drm_syncobj *syncobj,
> -struct drm_syncobj_cb *cb);
> void drm_syncobj_replace_fence(struct drm_syncobj *syncobj,
>struct dma_fence *fence);
> int drm_syncobj_find_fence(struct drm_file *file_private,
> --
> 2.18.0
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/2] drm: convert to SPDX identifiers for Renesas
Hi Morimoto-san, On Wednesday, 22 August 2018 04:56:37 EEST Kuninori Morimoto wrote: > Hi Laurent > > These are not yet appear on Linus tree. > I will re-post it. Thank you, but there was no need to, they're stored safely in my tree :-) I'll send a pull request for v4.20. > Kuninori Morimoto (2): > drm: rcar-du: convert to SPDX identifiers > drm: shmobile: convert to SPDX identifiers > > drivers/gpu/drm/rcar-du/Kconfig| 1 + > drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 6 +- > drivers/gpu/drm/rcar-du/rcar_du_crtc.h | 6 +- > drivers/gpu/drm/rcar-du/rcar_du_drv.c | 6 +- > drivers/gpu/drm/rcar-du/rcar_du_drv.h | 6 +- > drivers/gpu/drm/rcar-du/rcar_du_encoder.c | 6 +- > drivers/gpu/drm/rcar-du/rcar_du_encoder.h | 6 +- > drivers/gpu/drm/rcar-du/rcar_du_group.c| 6 +- > drivers/gpu/drm/rcar-du/rcar_du_group.h| 6 +- > drivers/gpu/drm/rcar-du/rcar_du_kms.c | 6 +- > drivers/gpu/drm/rcar-du/rcar_du_kms.h | 6 +- > drivers/gpu/drm/rcar-du/rcar_du_plane.c| 6 +- > drivers/gpu/drm/rcar-du/rcar_du_plane.h| 6 +- > drivers/gpu/drm/rcar-du/rcar_du_regs.h | 5 + > drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 6 +- > drivers/gpu/drm/rcar-du/rcar_du_vsp.h | 6 +- > drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c | 6 +- > drivers/gpu/drm/rcar-du/rcar_lvds_regs.h | 5 + > drivers/gpu/drm/shmobile/Kconfig | 1 + > drivers/gpu/drm/shmobile/shmob_drm_backlight.c | 6 +- > drivers/gpu/drm/shmobile/shmob_drm_backlight.h | 6 +- > drivers/gpu/drm/shmobile/shmob_drm_crtc.c | 6 +- > drivers/gpu/drm/shmobile/shmob_drm_crtc.h | 6 +- > drivers/gpu/drm/shmobile/shmob_drm_drv.c | 6 +- > drivers/gpu/drm/shmobile/shmob_drm_drv.h | 6 +- > drivers/gpu/drm/shmobile/shmob_drm_kms.c | 6 +- > drivers/gpu/drm/shmobile/shmob_drm_kms.h | 6 +- > drivers/gpu/drm/shmobile/shmob_drm_plane.c | 6 +- > drivers/gpu/drm/shmobile/shmob_drm_plane.h | 6 +- > drivers/gpu/drm/shmobile/shmob_drm_regs.h | 6 +- > 30 files changed, 30 insertions(+), 138 deletions(-) -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [igt-dev] RFC: Migration to Gitlab
On Wed, Aug 22, 2018 at 10:19:19AM -0400, Adam Jackson wrote: > On Wed, 2018-08-22 at 16:13 +0300, Jani Nikula wrote: > > > - Sticking to fdo bugzilla and disabling gitlab issues for at least > > drm-intel for the time being. Doing that migration in the same go is a > > bit much I think. Reassignment across bugzilla and gitlab will be an > > issue. > > Can you elaborate a bit on the issues here? The actual move-the-bugs > process has been pretty painless for the parts of xorg we've done so > far. I guess there is nothing against moving the bugs there. The concern is only on doing everything at once. I'm in favor of moving gits for now and after we are confident that everything is there and working we move the bugs. One question about the bugzilla: Will all the referrences on all commit messages get outdated after bugzilla is dead? Or bugzilla will stay up for referrence but closed for interaction? or all old closed stuff are always moved and bugzilla.fd.o as well and bugzilla.fd.o will be mirroring gitlab? Thanks, Rodrigo. > > - ajax > ___ > dim-tools mailing list > dim-to...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dim-tools ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/fourcc: Add DOC: overview comment
Hi,
On Wed, Aug 22, 2018 at 05:11:55PM +0200, Daniel Vetter wrote:
On Wed, Aug 22, 2018 at 4:59 PM, Eric Engestrom
wrote:
On Tuesday, 2018-08-21 17:44:17 +0100, Brian Starkey wrote:
Hi Matthew,
On Tue, Aug 21, 2018 at 09:26:39AM -0700, Matthew Wilcox wrote:
> On Tue, Aug 21, 2018 at 05:16:11PM +0100, Brian Starkey wrote:
> > There's a number of things which haven't previously been documented
> > around the usage of format modifiers. Capture the current
> > understanding in an overview comment and add it to the rst
> > documentation.
> >
> > Ideally, the generated documentation would also include documentation
> > of all of the #defines, but the kernel-doc system doesn't currently
> > support kernel-doc comments on #define constants.
>
> Can you turn them into enums? This seems to work ok:
>
> -/* color index */
> -#define DRM_FORMAT_C8 fourcc_code('C', '8', ' ', ' ') /* [7:0] C */
> -
> -/* 8 bpp Red */
> -#define DRM_FORMAT_R8 fourcc_code('R', '8', ' ', ' ') /* [7:0] R */
> +enum {
> + /* color index */
> + DRM_FORMAT_C8 = fourcc_code('C', '8', ' ', ' '), /* [7:0] C */
> + /* 8 bpp Red */
> + DRM_FORMAT_R8 = fourcc_code('R', '8', ' ', ' '), /* [7:0] R */
> +};
>
> but I appreciate this is user API and maybe there's some code out there
> that does #ifndef DRM_FORMAT_C8 ...
Thanks for the suggestion, Daniel did mention the same. However,
unfortunately I don't think we can safely change the UAPI header in
this manner.
You could get the best of both worlds by doing both:
enum {
foo = fourcc(...),
bar = fourcc(...),
}
#define foo foo
#define bar bar
It would mean a bit more code though, but that way these would now be
enums (with all the advantages of enums vs plain literals) and still
pass #ifdef checks :)
(BTW, on the "maybe there's some code that does #ifdef": I can tell you
there is indeed, having written this myself for an out-of-tree driver
for customer-modified kernels that may contain additional formats)
Looks reasonable. I'd even put the #define right within each enum line
(as a reminder so people don't forget to add them. Would happily ack a
patch to mass-convert, if that ups the odds of good kerneldoc for all
this.
enum also should support the inline style of kerneldoc (otherwise I
guess we'd need to fix that first, or it just makes no sense at all).
-Daniel
I'm not sure that swapping out explicit 32-bit unsigned integers for
enums (unspecified width, signed integers) is necessarily a good idea,
it seems like Bad Things could happen.
The C spec says:
"the value of an enumeration constant shall be an integer constant
expression that has a value representable as an int"
Which likely gives us 4 bytes to play with on all machines
that run Linux, but if drm_fourcc.h is ever going to be some kind of
standard reference, making it non-portable seems like a fail.
And even if you do have 4 bytes in an enum, signed integers act
differently from unsigned ones, and compilers do love to invoke the UB
clause...
Cheers,
-Brian
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm/malidp: Fix writeback in NV12
When we want to writeback to memory in NV12 format we need to program
the RGB2YUV coefficients. Currently, we don't program the coefficients
and NV12 doesn't work at all.
This patchset fixes that by programming a sane default(bt709, limited
range) as rgb2yuv coefficients.
In the long run, probably we need to think of a way for userspace to
be able to program that, but for now I think this is better than not
working at all or not advertising NV12 as a supported format for
memwrite.
Changes since v1:
- Write the rgb2yuv coefficients only once, since we don't change
them at all, just write them the first time NV12 is programmed,
suggested by Brian Starkey, here [1]
[1] https://lists.freedesktop.org/archives/dri-devel/2018-August/186819.html
Signed-off-by: Alexandru Gheorghe
---
drivers/gpu/drm/arm/malidp_hw.c | 25 +++--
drivers/gpu/drm/arm/malidp_hw.h | 3 ++-
drivers/gpu/drm/arm/malidp_mw.c | 25 +
drivers/gpu/drm/arm/malidp_regs.h | 2 ++
4 files changed, 48 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/arm/malidp_hw.c b/drivers/gpu/drm/arm/malidp_hw.c
index c94a4422e0e9..2781e462c1ed 100644
--- a/drivers/gpu/drm/arm/malidp_hw.c
+++ b/drivers/gpu/drm/arm/malidp_hw.c
@@ -384,7 +384,8 @@ static long malidp500_se_calc_mclk(struct malidp_hw_device
*hwdev,
static int malidp500_enable_memwrite(struct malidp_hw_device *hwdev,
dma_addr_t *addrs, s32 *pitches,
-int num_planes, u16 w, u16 h, u32 fmt_id)
+int num_planes, u16 w, u16 h, u32 fmt_id,
+const s16 *rgb2yuv_coeffs)
{
u32 base = MALIDP500_SE_MEMWRITE_BASE;
u32 de_base = malidp_get_block_base(hwdev, MALIDP_DE_BLOCK);
@@ -416,6 +417,16 @@ static int malidp500_enable_memwrite(struct
malidp_hw_device *hwdev,
malidp_hw_write(hwdev, MALIDP_DE_H_ACTIVE(w) | MALIDP_DE_V_ACTIVE(h),
MALIDP500_SE_MEMWRITE_OUT_SIZE);
+
+ if (rgb2yuv_coeffs) {
+ int i;
+
+ for (i = 0; i < MALIDP_COLORADJ_NUM_COEFFS; i++) {
+ malidp_hw_write(hwdev, rgb2yuv_coeffs[i],
+ MALIDP500_SE_RGB_YUV_COEFFS + i * 4);
+ }
+ }
+
malidp_hw_setbits(hwdev, MALIDP_SE_MEMWRITE_EN, MALIDP500_SE_CONTROL);
return 0;
@@ -658,7 +669,8 @@ static long malidp550_se_calc_mclk(struct malidp_hw_device
*hwdev,
static int malidp550_enable_memwrite(struct malidp_hw_device *hwdev,
dma_addr_t *addrs, s32 *pitches,
-int num_planes, u16 w, u16 h, u32 fmt_id)
+int num_planes, u16 w, u16 h, u32 fmt_id,
+const s16 *rgb2yuv_coeffs)
{
u32 base = MALIDP550_SE_MEMWRITE_BASE;
u32 de_base = malidp_get_block_base(hwdev, MALIDP_DE_BLOCK);
@@ -689,6 +701,15 @@ static int malidp550_enable_memwrite(struct
malidp_hw_device *hwdev,
malidp_hw_setbits(hwdev, MALIDP550_SE_MEMWRITE_ONESHOT |
MALIDP_SE_MEMWRITE_EN,
MALIDP550_SE_CONTROL);
+ if (rgb2yuv_coeffs) {
+ int i;
+
+ for (i = 0; i < MALIDP_COLORADJ_NUM_COEFFS; i++) {
+ malidp_hw_write(hwdev, rgb2yuv_coeffs[i],
+ MALIDP550_SE_RGB_YUV_COEFFS + i * 4);
+ }
+ }
+
return 0;
}
diff --git a/drivers/gpu/drm/arm/malidp_hw.h b/drivers/gpu/drm/arm/malidp_hw.h
index ad2e96915d44..9fc94c08190f 100644
--- a/drivers/gpu/drm/arm/malidp_hw.h
+++ b/drivers/gpu/drm/arm/malidp_hw.h
@@ -191,7 +191,8 @@ struct malidp_hw {
* @param fmt_id - internal format ID of output buffer
*/
int (*enable_memwrite)(struct malidp_hw_device *hwdev, dma_addr_t
*addrs,
- s32 *pitches, int num_planes, u16 w, u16 h, u32
fmt_id);
+ s32 *pitches, int num_planes, u16 w, u16 h, u32
fmt_id,
+ const s16 *rgb2yuv_coeffs);
/*
* Disable the writing to memory of the next frame's content.
diff --git a/drivers/gpu/drm/arm/malidp_mw.c b/drivers/gpu/drm/arm/malidp_mw.c
index cfd718e7e97c..429a11e6473b 100644
--- a/drivers/gpu/drm/arm/malidp_mw.c
+++ b/drivers/gpu/drm/arm/malidp_mw.c
@@ -26,6 +26,8 @@ struct malidp_mw_connector_state {
s32 pitches[2];
u8 format;
u8 n_planes;
+ bool rgb2yuv_initialized;
+ const s16 *rgb2yuv_coeffs;
};
static int malidp_mw_connector_get_modes(struct drm_connector *connector)
@@ -84,7 +86,7 @@ static void malidp_mw_connector_destroy(struct drm_connector
*connector)
static struct drm_connector_state *
malidp_mw_connector_duplicate_state(struct drm_connector *connector)
{
- struct malidp_mw_connector_state
Re: [PATCH] drm/fourcc: Add DOC: overview comment
On Wed, Aug 22, 2018 at 4:59 PM, Eric Engestrom
wrote:
> On Tuesday, 2018-08-21 17:44:17 +0100, Brian Starkey wrote:
>> Hi Matthew,
>>
>> On Tue, Aug 21, 2018 at 09:26:39AM -0700, Matthew Wilcox wrote:
>> > On Tue, Aug 21, 2018 at 05:16:11PM +0100, Brian Starkey wrote:
>> > > There's a number of things which haven't previously been documented
>> > > around the usage of format modifiers. Capture the current
>> > > understanding in an overview comment and add it to the rst
>> > > documentation.
>> > >
>> > > Ideally, the generated documentation would also include documentation
>> > > of all of the #defines, but the kernel-doc system doesn't currently
>> > > support kernel-doc comments on #define constants.
>> >
>> > Can you turn them into enums? This seems to work ok:
>> >
>> > -/* color index */
>> > -#define DRM_FORMAT_C8 fourcc_code('C', '8', ' ', ' ') /* [7:0] C
>> > */
>> > -
>> > -/* 8 bpp Red */
>> > -#define DRM_FORMAT_R8 fourcc_code('R', '8', ' ', ' ') /* [7:0] R
>> > */
>> > +enum {
>> > + /* color index */
>> > + DRM_FORMAT_C8 = fourcc_code('C', '8', ' ', ' '), /* [7:0] C */
>> > + /* 8 bpp Red */
>> > + DRM_FORMAT_R8 = fourcc_code('R', '8', ' ', ' '), /* [7:0] R */
>> > +};
>> >
>> > but I appreciate this is user API and maybe there's some code out there
>> > that does #ifndef DRM_FORMAT_C8 ...
>>
>> Thanks for the suggestion, Daniel did mention the same. However,
>> unfortunately I don't think we can safely change the UAPI header in
>> this manner.
>
> You could get the best of both worlds by doing both:
>
> enum {
> foo = fourcc(...),
> bar = fourcc(...),
> }
> #define foo foo
> #define bar bar
>
> It would mean a bit more code though, but that way these would now be
> enums (with all the advantages of enums vs plain literals) and still
> pass #ifdef checks :)
>
> (BTW, on the "maybe there's some code that does #ifdef": I can tell you
> there is indeed, having written this myself for an out-of-tree driver
> for customer-modified kernels that may contain additional formats)
Looks reasonable. I'd even put the #define right within each enum line
(as a reminder so people don't forget to add them. Would happily ack a
patch to mass-convert, if that ups the odds of good kerneldoc for all
this.
enum also should support the inline style of kerneldoc (otherwise I
guess we'd need to fix that first, or it just makes no sense at all).
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: RFC: Migration to Gitlab
Hi Dan, On 22 August 2018 at 12:44, Daniel Vetter wrote: > Hi all, > > I think it's time to brainstorm a bit about the gitlab migration. Basic > reasons: > > - fd.o admins want to deprecate shell accounts and hand-rolled > infrastructure, because it's a pain to keep secure > > - gitlab will allow us to add committers on our own, greatly > simplifying that process (and offloading that task from fd.o admins). > Random thought - I really wish the admins spoke early and louder about issues. From infra to manpower and adhoc tool maintenance. > There's also some more benefits we might want to reap, like better CI > integration for basic build testing - no more "oops didn't build > drm-misc defconfigs" or "sry, forgot make check in maintainer-tools". > But that's all fully optional. > > For the full in-depth writeup of everything, see > > https://www.fooishbar.org/blog/gitlab-fdo-introduction/ > > I think now is also a good time, with mesa, xorg, wayland/weston and > others moved, to start thinking about how we'll move drm. There's a > few things to figure out though: > > - We probably want to split out maintainer-tools. That would address > the concern that there's 50+ committers to an auto-updating shell > script ... > > - We need to figure out how to handle the ACL trickery around drm-tip in > gitlab. > > - Probably good to stage the migration, with maintainer-tools, igt > leading. That will also make fd.o admins happy, who want to rework > their cloud infrastructure a bit before migrating the big kernel repos > over. > > - Figuring out the actual migration - we've been adding a pile of > committers since fd.o LDAP was converted to gitlab once back in > spring. We need to at least figure out how to move the new > accounts/committers. > As a observer, allow me to put some ideas. You've mostly covered them all, my emphasis is to seriously stick with _one_ thing at a time. Attempting to do multiple things in parallel will end up with sub-optimal results. - (at random point) cleanup the committers list - people who have not contributed in the last 1 year? - setup drm group, copy/migrate accounts - one could even reuse the existing credentials - move git repos to gitlab, the push URL change, cgit mirror preserves the normal fetch ones as well as PW hooks - work out how new accounts are handled - still in bugzilla, otherwise At this stage only workflow change is a) once-off account setup and b) pushURL update As a follow-up one can setup anything fancy. - migrate PW/other hooks - migrate bugs - if applicable - add new hooks - DRM docs, other - etc > - Similar, maintainer-tools needs to move. We probably want to move > all the dim maintained kernel repos in one go, to avoid headaches with > double-accounts needed for committers. > One should be able to create a separate repo for these. And then either: - one by one add the required features into the gitlab MR machinery, - or, wire the execution in pre/post merge stage. IIRC there are some upstream requests about the former. > - CI, linux-next and everyone else should be fine, since the > cgit/non-ssh paths will keep working (they'll be read-only mirrors). > Need to double-check that with everyone. > > - Some organization structure would be good. > > https://cgit.freedesktop.org/drm > > libdrm won't be part of the gitlab drm group because that's already > moved under mesa (and you can't symlink/mulit-home anymore on gitlab): > > https://gitlab.freedesktop.org/mesa/drm > > But there's also drm_hwcomposer, which we might want to migrate into > drm too - gitlab requires a containing group, and > drm_hwcomposer/drm_hwcomposer is a bit silly. > It did strike me a lot when drm_hwcomposer/drm_hwcomposer was introduced. Fortunately moving repos in gitlab is reasonably pain-free HTH Emil ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/fourcc: Add DOC: overview comment
On Tuesday, 2018-08-21 17:44:17 +0100, Brian Starkey wrote:
> Hi Matthew,
>
> On Tue, Aug 21, 2018 at 09:26:39AM -0700, Matthew Wilcox wrote:
> > On Tue, Aug 21, 2018 at 05:16:11PM +0100, Brian Starkey wrote:
> > > There's a number of things which haven't previously been documented
> > > around the usage of format modifiers. Capture the current
> > > understanding in an overview comment and add it to the rst
> > > documentation.
> > >
> > > Ideally, the generated documentation would also include documentation
> > > of all of the #defines, but the kernel-doc system doesn't currently
> > > support kernel-doc comments on #define constants.
> >
> > Can you turn them into enums? This seems to work ok:
> >
> > -/* color index */
> > -#define DRM_FORMAT_C8 fourcc_code('C', '8', ' ', ' ') /* [7:0] C
> > */
> > -
> > -/* 8 bpp Red */
> > -#define DRM_FORMAT_R8 fourcc_code('R', '8', ' ', ' ') /* [7:0] R
> > */
> > +enum {
> > + /* color index */
> > + DRM_FORMAT_C8 = fourcc_code('C', '8', ' ', ' '), /* [7:0] C */
> > + /* 8 bpp Red */
> > + DRM_FORMAT_R8 = fourcc_code('R', '8', ' ', ' '), /* [7:0] R */
> > +};
> >
> > but I appreciate this is user API and maybe there's some code out there
> > that does #ifndef DRM_FORMAT_C8 ...
>
> Thanks for the suggestion, Daniel did mention the same. However,
> unfortunately I don't think we can safely change the UAPI header in
> this manner.
You could get the best of both worlds by doing both:
enum {
foo = fourcc(...),
bar = fourcc(...),
}
#define foo foo
#define bar bar
It would mean a bit more code though, but that way these would now be
enums (with all the advantages of enums vs plain literals) and still
pass #ifdef checks :)
(BTW, on the "maybe there's some code that does #ifdef": I can tell you
there is indeed, having written this myself for an out-of-tree driver
for customer-modified kernels that may contain additional formats)
>
> Cheers,
> -Brian
> ___
> 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: [igt-dev] RFC: Migration to Gitlab
On Wed, Aug 22, 2018 at 3:13 PM, Jani Nikula wrote: > On Wed, 22 Aug 2018, Daniel Vetter wrote: >> Hi all, >> >> I think it's time to brainstorm a bit about the gitlab migration. Basic >> reasons: >> >> - fd.o admins want to deprecate shell accounts and hand-rolled >> infrastructure, because it's a pain to keep secure >> >> - gitlab will allow us to add committers on our own, greatly >> simplifying that process (and offloading that task from fd.o admins). >> >> There's also some more benefits we might want to reap, like better CI >> integration for basic build testing - no more "oops didn't build >> drm-misc defconfigs" or "sry, forgot make check in maintainer-tools". >> But that's all fully optional. >> >> For the full in-depth writeup of everything, see >> >> https://www.fooishbar.org/blog/gitlab-fdo-introduction/ >> >> I think now is also a good time, with mesa, xorg, wayland/weston and >> others moved, to start thinking about how we'll move drm. There's a >> few things to figure out though: >> >> - We probably want to split out maintainer-tools. That would address >> the concern that there's 50+ committers to an auto-updating shell >> script ... >> >> - We need to figure out how to handle the ACL trickery around drm-tip in >> gitlab. >> >> - Probably good to stage the migration, with maintainer-tools, igt >> leading. That will also make fd.o admins happy, who want to rework >> their cloud infrastructure a bit before migrating the big kernel repos >> over. >> >> - Figuring out the actual migration - we've been adding a pile of >> committers since fd.o LDAP was converted to gitlab once back in >> spring. We need to at least figure out how to move the new >> accounts/committers. >> >> - Similar, maintainer-tools needs to move. We probably want to move >> all the dim maintained kernel repos in one go, to avoid headaches with >> double-accounts needed for committers. >> >> - CI, linux-next and everyone else should be fine, since the >> cgit/non-ssh paths will keep working (they'll be read-only mirrors). >> Need to double-check that with everyone. >> >> - Some organization structure would be good. >> >> https://cgit.freedesktop.org/drm >> >> libdrm won't be part of the gitlab drm group because that's already >> moved under mesa (and you can't symlink/mulit-home anymore on gitlab): >> >> https://gitlab.freedesktop.org/mesa/drm >> >> But there's also drm_hwcomposer, which we might want to migrate into >> drm too - gitlab requires a containing group, and >> drm_hwcomposer/drm_hwcomposer is a bit silly. >> >> Note: Access rights can be done at any level in the hierarchy, the >> organization is orthogonal to commit rights. >> >> - Anything else I've forgotten. >> >> A lot of this still needs to be figured out first. As a first step I'm >> looking for volunteers who want to join the fun, besides comments and >> thoughts on the overall topic of course. > > Just a couple of concerns from drm/i915 perspective for starters: > > - Patchwork integration. I think we'll want to keep patchwork for at > least intel-gfx etc. for the time being. IIUC the one thing we need is > some server side hook to update patchwork on git push. > > - Sticking to fdo bugzilla and disabling gitlab issues for at least > drm-intel for the time being. Doing that migration in the same go is a > bit much I think. Reassignment across bugzilla and gitlab will be an > issue. Good points, forgot about both. Patchwork reading the mailing list should keep working as-is, but the update hook needs looking into. Disabling gitlab issues is a non-brainer, same with merge requests. Mesa is already doing that. For bugs I think it's best to entirely leave them out for now, and maybe reconsider when/if mesa has moved. Before that I don't think gitlab issues make any sense at all. For merge requests I think best approach is to enable them very selectively at first for testing out, and then making a per-subproject decision whether they make sense. E.g. I think for maintainer-tools integrating make check and the doc building into gitlab CI would be sweet, and worth looking into gitlab merge requests just to automate that. Again best left out of scope for the initial migration. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 105046] Screen resolution reset to 1368x768 when turning monitor off
https://bugs.freedesktop.org/show_bug.cgi?id=105046 --- Comment #16 from Michael Zapf --- Maybe this is another indication that something goes wrong: (screen at 1920x1200) michael@capella:~> xrandr --verbose | grep EDID -A16 EDID: 0000412f271001010101 0019010380362378eece50a3544c9926 0f5054a56b808140a900a940b300d100 010101010101283c80a070b023403020 36002260211a00fc00565358 2d300a202020202000fd0030 551e4611000a20202020202000ff 00504c4339303134470a202001a6 020334714b010204850610111314151f 38097f070f7f071507503e06c0497f00 5706005f7e01677e00834f66030c 00110080011d8018711c1620582c2500 0644219e011d80d0721c1620102c 25800644219e011d007251d01e20 6e2855000644211e011d00bc52d0 1e20b82855400644211e008f (turn off monitor, turn on again, screen now reset to 1920x1080) michael@capella:~> xrandr --verbose | grep EDID -A16 michael@capella:~> That is, there is no EDID data anymore. --- I was looking for some tool to read the EDID channel, but I was not yet successful. I am using openSUSE. I tried to download and compile read-edid, but I get an error message from cmake about a missing setting of X86_LIBRARY. Then I found a python tool on Github (edid-rw), but I cannot find the smbus python module (not in the repositories). -- 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 102322] System crashes after "[drm] IP block:gmc_v8_0 is hung!" / [drm] IP block:sdma_v3_0 is hung!
https://bugs.freedesktop.org/show_bug.cgi?id=102322 --- Comment #60 from Andrey Grodzovsky --- (In reply to dwagner from comment #58) > Here comes another trace log, with your info2.patch applied. > > Something must have changed since the last test, as it took pretty long this > time to reproduce the crash. Could that have been caused by > https://cgit.freedesktop.org/~agd5f/linux/commit/drivers/gpu/drm/amd/amdgpu/ > nbio_v7_4.c?h=amd-staging-drm- > next=b385925f3922faca7435e50e31380bb2602fd6b8 now being part of the > kernel? Don't think it's related. This code is more related to virtualization. > > However, the latest trace you find attached below is not much different to > the last one, xzcat /tmp/gpu_debug5.txt.xz | grep '^\[' will tell you: > > [ 1510.023112] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring sdma0 > timeout, signaled seq=475104, emitted seq=475106 > [ 1510.023117] [drm] GPU recovery disabled. That just means you are again running with GPU VM update mode set to use SDMA. Which is seen in you dmesg (amdgpu.vm_update_mode=0) , so are again experiencing the original issue of SDMA hang. Please use amdgpu.vm_update_mode=3 to get back to VM_FAULTs issue. > > amdgpu_cs:0-806 [012] 1787.493126: amdgpu_vm_bo_cs: > soffs=1001a0, eoffs=1001b9, flags=70 > amdgpu_cs:0-806 [012] 1787.493127: amdgpu_vm_bo_cs: > soffs=100200, eoffs=1021e0, flags=70 > amdgpu_cs:0-806 [012] 1787.493127: amdgpu_vm_bo_cs: > soffs=102200, eoffs=1041e0, flags=70 > amdgpu_cs:0-806 [012] 1787.493129: amdgpu_vm_bo_cs: > soffs=10c1e0, eoffs=10c2e1, flags=70 > amdgpu_cs:0-806 [012] 1787.493131: drm_sched_job: > entity=406345a7, id=10239, fence=7a120377, ring=gfx, job > count:8, hw job count:0 > > And later in the file you can find: > -- > crash detected! > > executing umr -O halt_waves -wa > No active waves! > > executing umr -O verbose -R gfx[.] > > polaris11.gfx.rptr == 512 > polaris11.gfx.wptr == 512 > polaris11.gfx.drv_wptr == 512 > polaris11.gfx.ring[ 481] == 0x1000... > polaris11.gfx.ring[ 482] == 0x1000... > polaris11.gfx.ring[ 483] == 0x1000... > polaris11.gfx.ring[ 484] == 0x1000... > polaris11.gfx.ring[ 485] == 0x1000... > polaris11.gfx.ring[ 486] == 0x1000... > polaris11.gfx.ring[ 487] == 0x1000... > polaris11.gfx.ring[ 488] == 0x1000... > polaris11.gfx.ring[ 489] == 0x1000... > polaris11.gfx.ring[ 490] == 0x1000... > polaris11.gfx.ring[ 491] == 0x1000... > polaris11.gfx.ring[ 492] == 0x1000... > polaris11.gfx.ring[ 493] == 0x1000... > polaris11.gfx.ring[ 494] == 0x1000... > polaris11.gfx.ring[ 495] == 0x1000... > polaris11.gfx.ring[ 496] == 0x1000... > polaris11.gfx.ring[ 497] == 0x1000... > polaris11.gfx.ring[ 498] == 0x1000... > polaris11.gfx.ring[ 499] == 0x1000... > polaris11.gfx.ring[ 500] == 0x1000... > polaris11.gfx.ring[ 501] == 0x1000... > polaris11.gfx.ring[ 502] == 0x1000... > polaris11.gfx.ring[ 503] == 0x1000... > polaris11.gfx.ring[ 504] == 0x1000... > polaris11.gfx.ring[ 505] == 0x1000... > polaris11.gfx.ring[ 506] == 0x1000... > polaris11.gfx.ring[ 507] == 0x1000... > polaris11.gfx.ring[ 508] == 0x1000... > polaris11.gfx.ring[ 509] == 0x1000... > polaris11.gfx.ring[ 510] == 0x1000... > polaris11.gfx.ring[ 511] == 0x1000... > polaris11.gfx.ring[ 512] == 0xc0032200rwD > > > trying to get ADR from dmesg output for 'umr -O verbose -vm ...' > trying to get VMID from dmesg output for 'umr -O verbose -vm ...' > > done after crash. > --- > > So even without GPU reset, still no "waves". And the error message also does > not state any VM fault address. -- 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: [igt-dev] RFC: Migration to Gitlab
On Wed, 2018-08-22 at 16:13 +0300, Jani Nikula wrote: > - Sticking to fdo bugzilla and disabling gitlab issues for at least > drm-intel for the time being. Doing that migration in the same go is a > bit much I think. Reassignment across bugzilla and gitlab will be an > issue. Can you elaborate a bit on the issues here? The actual move-the-bugs process has been pretty painless for the parts of xorg we've done so far. - ajax ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 4/5] drm: Add support for handling linear tile formats
On Wed, Aug 22, 2018 at 04:45:34PM +0300, Ville Syrjälä wrote:
> On Wed, Aug 22, 2018 at 02:36:06PM +0100, Alexandru-Cosmin Gheorghe wrote:
> > On Wed, Aug 22, 2018 at 04:18:54PM +0300, Ville Syrjälä wrote:
> > > On Tue, Aug 21, 2018 at 07:30:03PM +0100, Alexandru Gheorghe wrote:
> > > > The previous patch added tile_w and tile_h, which represent the
> > > > horizontal and vertical sizes of a tile.
> > > >
> > > > This one uses that to plumb through drm core in order to be able to
> > > > handle linear tile formats without the need for drivers to roll up
> > > > their own implementation.
> > > >
> > > > This patch had been written with Mali-dp X0L2 and X0L0 in mind which
> > > > is a 1 plane YCbCr 420 format with a 2x2 tile, that uses in average 2
> > > > bytes per pixel and where tiles are laid out in a linear manner.
> > > >
> > > > Now what are the restrictions:
> > > >
> > > > 1. Pitch in bytes is expected to cover at least tile_h * width in
> > > > pixels. Due to this the places where the pitch is checked/used need to
> > > > be updated to take into consideration the tile_w, tile_h and
> > > > tile_size.
> > > > tile_size = cpp * tile_w * tile_h
> > > >
> > > > 2. When doing source cropping plane_src_x/y need to be a multiple of
> > > > tile_w/tile_h and we need to take into consideration the tile_w/tile_h
> > > > when computing the start address.
> > > >
> > > > For all non-tiled formats the tile_w and tile_h will be 1, so if I
> > > > didn't miss anything nothing should change.
> > > >
> > > > Regarding multi-planar linear tile formats, I'm not sure how those
> > > > should be handle I kind of assumed that tile_h/tile_w will have to be
> > > > divided by horizontal/subsampling. Anyway, I think it's best to just
> > > > put an warning in there and handle it when someone tries to add
> > > > support for them.
> > > >
> > > > Signed-off-by: Alexandru Gheorghe
> > > > ---
> > > > drivers/gpu/drm/drm_atomic.c | 8 +++
> > > > drivers/gpu/drm/drm_fb_cma_helper.c | 11 -
> > > > drivers/gpu/drm/drm_fourcc.c | 52
> > > > drivers/gpu/drm/drm_framebuffer.c| 19 +--
> > > > drivers/gpu/drm/drm_gem_framebuffer_helper.c | 10 ++--
> > > > include/drm/drm_fourcc.h | 2 +
> > > > 6 files changed, 94 insertions(+), 8 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > > > index 3eb061e11e2e..7a3e893a4cd1 100644
> > > > --- a/drivers/gpu/drm/drm_atomic.c
> > > > +++ b/drivers/gpu/drm/drm_atomic.c
> > > > @@ -1087,6 +1087,14 @@ static int drm_atomic_plane_check(struct
> > > > drm_plane *plane,
> > > > return -ENOSPC;
> > > > }
> > > >
> > > > + /* Make sure source coordinates are a multiple of tile sizes */
> > > > + if ((state->src_x >> 16) % state->fb->format->tile_w ||
> > > > + (state->src_y >> 16) % state->fb->format->tile_h) {
> > > > + DRM_DEBUG_ATOMIC("[PLANE:%d:%s] Source coordinates do
> > > > not meet tile restrictions",
> > > > +plane->base.id, plane->name);
> > > > + return -EINVAL;
> > > > + }
> > >
> > > Feels rather wrong to me to put such hardware specific limitations into
> > > the core.
> >
> > Yeah, the problem is that otherwise drm_fb_cma_get_gem_addr wouldn't
> > work.
>
> If that guy is supposed to give you a tile aligned address then it could
> just do that and leave it up to the driver to deal with the remainder of
> the coordinates?
>
> >
> > An alternative, would be to include it in the driver and put an WARN
> > in drm_fb_cma_get_gem_addr in case someone else uses it with a
> > src_x/src_y tile multiples.
> >
> > What do you think about that ?
> >
> > >
> > > > +
> > > > if (plane_switching_crtc(state->state, plane, state)) {
> > > > DRM_DEBUG_ATOMIC("[PLANE:%d:%s] switching CRTC
> > > > directly\n",
> > > > plane->base.id, plane->name);
> > > > diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c
> > > > b/drivers/gpu/drm/drm_fb_cma_helper.c
> > > > index 47e0e2f6642d..4d8052adce67 100644
> > > > --- a/drivers/gpu/drm/drm_fb_cma_helper.c
> > > > +++ b/drivers/gpu/drm/drm_fb_cma_helper.c
> > > > @@ -87,6 +87,8 @@ dma_addr_t drm_fb_cma_get_gem_addr(struct
> > > > drm_framebuffer *fb,
> > > > struct drm_gem_cma_object *obj;
> > > > dma_addr_t paddr;
> > > > u8 h_div = 1, v_div = 1;
> > > > + u32 tile_w = drm_format_tile_width(fb->format, plane);
> > > > + u32 tile_h = drm_format_tile_height(fb->format, plane);
> > > >
> > > > obj = drm_fb_cma_get_gem_obj(fb, plane);
> > > > if (!obj)
> > > > @@ -99,8 +101,13 @@ dma_addr_t drm_fb_cma_get_gem_addr(struct
> > > > drm_framebuffer *fb,
> > > > v_div = fb->format->vsub;
> > > > }
> > > >
> > > > - paddr +=
Re: [PROTO][PATCH 05/10] drm/bridge: adv7511: Add max-clock, min-vrefresh options
Hi Ulrich, On Wednesday, 22 August 2018 12:13:59 EEST Ulrich Hecht wrote: > On August 21, 2018 at 10:09 AM Laurent Pinchart wrote: > > On Tuesday, 21 August 2018 11:03:45 EEST Ulrich Hecht wrote: > >> On August 20, 2018 at 11:28 AM Laurent Pinchart wrote: > >>> On Tuesday, 14 August 2018 16:49:59 EEST Ulrich Hecht wrote: > From: Koji Matsuoka > > This patch adds the option to specify a maximal clock and a minimal > vertical refresh rate. > >>> > >>> What is this needed for ? > >> > >> Somewhere in the chain there is a component that will not tolerate > >> clocks in excess of 135 MHz; if you don't limit it, the default for a > >> 1920x1200 display is somewhere along 148 MHz, and the HDMI signal > >> output is invalid. > > > > Do you know which component that is ? > > Unfortunately not. It's not the ADV7511, though, that goes up to 225 MHz... After investigation, it turns out that the THC63LVD1024 is the culprit, its datasheet reports a maximum operating frequency of 135 MHz. Do you have any idea what the minimal refresh rate is for ? -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 4/5] drm: Add support for handling linear tile formats
On Wed, Aug 22, 2018 at 02:36:06PM +0100, Alexandru-Cosmin Gheorghe wrote:
> On Wed, Aug 22, 2018 at 04:18:54PM +0300, Ville Syrjälä wrote:
> > On Tue, Aug 21, 2018 at 07:30:03PM +0100, Alexandru Gheorghe wrote:
> > > The previous patch added tile_w and tile_h, which represent the
> > > horizontal and vertical sizes of a tile.
> > >
> > > This one uses that to plumb through drm core in order to be able to
> > > handle linear tile formats without the need for drivers to roll up
> > > their own implementation.
> > >
> > > This patch had been written with Mali-dp X0L2 and X0L0 in mind which
> > > is a 1 plane YCbCr 420 format with a 2x2 tile, that uses in average 2
> > > bytes per pixel and where tiles are laid out in a linear manner.
> > >
> > > Now what are the restrictions:
> > >
> > > 1. Pitch in bytes is expected to cover at least tile_h * width in
> > > pixels. Due to this the places where the pitch is checked/used need to
> > > be updated to take into consideration the tile_w, tile_h and
> > > tile_size.
> > > tile_size = cpp * tile_w * tile_h
> > >
> > > 2. When doing source cropping plane_src_x/y need to be a multiple of
> > > tile_w/tile_h and we need to take into consideration the tile_w/tile_h
> > > when computing the start address.
> > >
> > > For all non-tiled formats the tile_w and tile_h will be 1, so if I
> > > didn't miss anything nothing should change.
> > >
> > > Regarding multi-planar linear tile formats, I'm not sure how those
> > > should be handle I kind of assumed that tile_h/tile_w will have to be
> > > divided by horizontal/subsampling. Anyway, I think it's best to just
> > > put an warning in there and handle it when someone tries to add
> > > support for them.
> > >
> > > Signed-off-by: Alexandru Gheorghe
> > > ---
> > > drivers/gpu/drm/drm_atomic.c | 8 +++
> > > drivers/gpu/drm/drm_fb_cma_helper.c | 11 -
> > > drivers/gpu/drm/drm_fourcc.c | 52
> > > drivers/gpu/drm/drm_framebuffer.c| 19 +--
> > > drivers/gpu/drm/drm_gem_framebuffer_helper.c | 10 ++--
> > > include/drm/drm_fourcc.h | 2 +
> > > 6 files changed, 94 insertions(+), 8 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > > index 3eb061e11e2e..7a3e893a4cd1 100644
> > > --- a/drivers/gpu/drm/drm_atomic.c
> > > +++ b/drivers/gpu/drm/drm_atomic.c
> > > @@ -1087,6 +1087,14 @@ static int drm_atomic_plane_check(struct drm_plane
> > > *plane,
> > > return -ENOSPC;
> > > }
> > >
> > > + /* Make sure source coordinates are a multiple of tile sizes */
> > > + if ((state->src_x >> 16) % state->fb->format->tile_w ||
> > > + (state->src_y >> 16) % state->fb->format->tile_h) {
> > > + DRM_DEBUG_ATOMIC("[PLANE:%d:%s] Source coordinates do not meet
> > > tile restrictions",
> > > + plane->base.id, plane->name);
> > > + return -EINVAL;
> > > + }
> >
> > Feels rather wrong to me to put such hardware specific limitations into
> > the core.
>
> Yeah, the problem is that otherwise drm_fb_cma_get_gem_addr wouldn't
> work.
If that guy is supposed to give you a tile aligned address then it could
just do that and leave it up to the driver to deal with the remainder of
the coordinates?
>
> An alternative, would be to include it in the driver and put an WARN
> in drm_fb_cma_get_gem_addr in case someone else uses it with a
> src_x/src_y tile multiples.
>
> What do you think about that ?
>
> >
> > > +
> > > if (plane_switching_crtc(state->state, plane, state)) {
> > > DRM_DEBUG_ATOMIC("[PLANE:%d:%s] switching CRTC directly\n",
> > >plane->base.id, plane->name);
> > > diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c
> > > b/drivers/gpu/drm/drm_fb_cma_helper.c
> > > index 47e0e2f6642d..4d8052adce67 100644
> > > --- a/drivers/gpu/drm/drm_fb_cma_helper.c
> > > +++ b/drivers/gpu/drm/drm_fb_cma_helper.c
> > > @@ -87,6 +87,8 @@ dma_addr_t drm_fb_cma_get_gem_addr(struct
> > > drm_framebuffer *fb,
> > > struct drm_gem_cma_object *obj;
> > > dma_addr_t paddr;
> > > u8 h_div = 1, v_div = 1;
> > > + u32 tile_w = drm_format_tile_width(fb->format, plane);
> > > + u32 tile_h = drm_format_tile_height(fb->format, plane);
> > >
> > > obj = drm_fb_cma_get_gem_obj(fb, plane);
> > > if (!obj)
> > > @@ -99,8 +101,13 @@ dma_addr_t drm_fb_cma_get_gem_addr(struct
> > > drm_framebuffer *fb,
> > > v_div = fb->format->vsub;
> > > }
> > >
> > > - paddr += (fb->format->cpp[plane] * (state->src_x >> 16)) / h_div;
> > > - paddr += (fb->pitches[plane] * (state->src_y >> 16)) / v_div;
> > > + paddr += (fb->format->cpp[plane] * tile_w * (state->src_x >> 16))
> > > + / h_div;
> > > + /*
> > > + * For tile formats pitches are expected to cover at least
> > > + * width * tile_h pixels
> > > + */
> > > + paddr += ((fb->pitches[plane] / tile_h) * (state->src_y >>
[Bug 107175] [CI][SKL][IOMMU] i915: probe of 0000:00:02.0 failed with error -25
https://bugs.freedesktop.org/show_bug.cgi?id=107175 Lakshmi changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #3 from Lakshmi --- This is not a bug and works as expected. But, igt@drv_selftest@live_guc test is failing that needs fix from guc Dmesg: [ 510.815692] i915: unknown parameter 'enable_guc_loading' ignored [ 510.815695] i915: unknown parameter 'enable_guc_submission' ignored [ 510.815697] Setting dangerous option enable_guc - tainting kernel [ 510.815701] Setting dangerous option live_selftests - tainting kernel [ 510.853939] [drm:intel_guc_send_mmio [i915]] *ERROR* MMIO: GuC action 0x10 failed with error -5 0xf000f000 For this issue there is a separate bug filed. https://bugs.freedesktop.org/show_bug.cgi?id=107258 Closing this as works as expected. -- 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 4/5] drm: Add support for handling linear tile formats
On Wed, Aug 22, 2018 at 04:18:54PM +0300, Ville Syrjälä wrote:
> On Tue, Aug 21, 2018 at 07:30:03PM +0100, Alexandru Gheorghe wrote:
> > The previous patch added tile_w and tile_h, which represent the
> > horizontal and vertical sizes of a tile.
> >
> > This one uses that to plumb through drm core in order to be able to
> > handle linear tile formats without the need for drivers to roll up
> > their own implementation.
> >
> > This patch had been written with Mali-dp X0L2 and X0L0 in mind which
> > is a 1 plane YCbCr 420 format with a 2x2 tile, that uses in average 2
> > bytes per pixel and where tiles are laid out in a linear manner.
> >
> > Now what are the restrictions:
> >
> > 1. Pitch in bytes is expected to cover at least tile_h * width in
> > pixels. Due to this the places where the pitch is checked/used need to
> > be updated to take into consideration the tile_w, tile_h and
> > tile_size.
> > tile_size = cpp * tile_w * tile_h
> >
> > 2. When doing source cropping plane_src_x/y need to be a multiple of
> > tile_w/tile_h and we need to take into consideration the tile_w/tile_h
> > when computing the start address.
> >
> > For all non-tiled formats the tile_w and tile_h will be 1, so if I
> > didn't miss anything nothing should change.
> >
> > Regarding multi-planar linear tile formats, I'm not sure how those
> > should be handle I kind of assumed that tile_h/tile_w will have to be
> > divided by horizontal/subsampling. Anyway, I think it's best to just
> > put an warning in there and handle it when someone tries to add
> > support for them.
> >
> > Signed-off-by: Alexandru Gheorghe
> > ---
> > drivers/gpu/drm/drm_atomic.c | 8 +++
> > drivers/gpu/drm/drm_fb_cma_helper.c | 11 -
> > drivers/gpu/drm/drm_fourcc.c | 52
> > drivers/gpu/drm/drm_framebuffer.c| 19 +--
> > drivers/gpu/drm/drm_gem_framebuffer_helper.c | 10 ++--
> > include/drm/drm_fourcc.h | 2 +
> > 6 files changed, 94 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > index 3eb061e11e2e..7a3e893a4cd1 100644
> > --- a/drivers/gpu/drm/drm_atomic.c
> > +++ b/drivers/gpu/drm/drm_atomic.c
> > @@ -1087,6 +1087,14 @@ static int drm_atomic_plane_check(struct drm_plane
> > *plane,
> > return -ENOSPC;
> > }
> >
> > + /* Make sure source coordinates are a multiple of tile sizes */
> > + if ((state->src_x >> 16) % state->fb->format->tile_w ||
> > + (state->src_y >> 16) % state->fb->format->tile_h) {
> > + DRM_DEBUG_ATOMIC("[PLANE:%d:%s] Source coordinates do not meet
> > tile restrictions",
> > +plane->base.id, plane->name);
> > + return -EINVAL;
> > + }
>
> Feels rather wrong to me to put such hardware specific limitations into
> the core.
Yeah, the problem is that otherwise drm_fb_cma_get_gem_addr wouldn't
work.
An alternative, would be to include it in the driver and put an WARN
in drm_fb_cma_get_gem_addr in case someone else uses it with a
src_x/src_y tile multiples.
What do you think about that ?
>
> > +
> > if (plane_switching_crtc(state->state, plane, state)) {
> > DRM_DEBUG_ATOMIC("[PLANE:%d:%s] switching CRTC directly\n",
> > plane->base.id, plane->name);
> > diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c
> > b/drivers/gpu/drm/drm_fb_cma_helper.c
> > index 47e0e2f6642d..4d8052adce67 100644
> > --- a/drivers/gpu/drm/drm_fb_cma_helper.c
> > +++ b/drivers/gpu/drm/drm_fb_cma_helper.c
> > @@ -87,6 +87,8 @@ dma_addr_t drm_fb_cma_get_gem_addr(struct drm_framebuffer
> > *fb,
> > struct drm_gem_cma_object *obj;
> > dma_addr_t paddr;
> > u8 h_div = 1, v_div = 1;
> > + u32 tile_w = drm_format_tile_width(fb->format, plane);
> > + u32 tile_h = drm_format_tile_height(fb->format, plane);
> >
> > obj = drm_fb_cma_get_gem_obj(fb, plane);
> > if (!obj)
> > @@ -99,8 +101,13 @@ dma_addr_t drm_fb_cma_get_gem_addr(struct
> > drm_framebuffer *fb,
> > v_div = fb->format->vsub;
> > }
> >
> > - paddr += (fb->format->cpp[plane] * (state->src_x >> 16)) / h_div;
> > - paddr += (fb->pitches[plane] * (state->src_y >> 16)) / v_div;
> > + paddr += (fb->format->cpp[plane] * tile_w * (state->src_x >> 16))
> > + / h_div;
> > + /*
> > +* For tile formats pitches are expected to cover at least
> > +* width * tile_h pixels
> > +*/
> > + paddr += ((fb->pitches[plane] / tile_h) * (state->src_y >> 16)) / v_div;
> >
> > return paddr;
> > }
> > diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
> > index f55cd93ba2d0..d6c9c5aa4036 100644
> > --- a/drivers/gpu/drm/drm_fourcc.c
> > +++ b/drivers/gpu/drm/drm_fourcc.c
> > @@ -557,3 +557,55 @@ int drm_format_plane_height(int height, uint32_t
> > format, int plane)
> > return height / info->vsub;
> > }
> >
Re: [PATCH v4 1/2] drm: Add per-plane pixel blend mode property
Op 15-08-18 om 08:35 schreef Lowry Li:
> Pixel blend modes represent the alpha blending equation
> selection, describing how the pixels from the current
> plane are composited with the background.
>
> Adds a pixel_blend_mode to drm_plane_state and a
> blend_mode_property to drm_plane, and related support
> functions.
>
> Defines three blend modes in drm_blend.h.
>
> Changes since v1:
> - Moves the blending equation into the DOC comment
> - Refines the comments of drm_plane_create_blend_mode_property to not
>enumerate the #defines, but instead the string values
> - Uses fg.* instead of pixel.* and plane_alpha instead of plane.alpha
> Changes since v2:
> - Refines the comments of drm_plane_create_blend_mode_property:
> 1) Puts the descriptions (after the ":") on a new line
> 2) Adds explaining why @supported_modes need PREMUL as default
> Changes since v3:
> - Refines drm_plane_create_blend_mode_property(). drm_property_add_enum()
>can calculate the index itself just fine, so no point in having the
>caller pass it in.
> - Since the current DRM assumption is that alpha is premultiplied
>as default, define DRM_MODE_BLEND_PREMULTI as 0 will be better.
> - Refines some comments.
>
> Signed-off-by: Lowry Li
> ---
> drivers/gpu/drm/drm_atomic.c| 4 ++
> drivers/gpu/drm/drm_atomic_helper.c | 1 +
> drivers/gpu/drm/drm_blend.c | 126
>
> include/drm/drm_blend.h | 6 ++
> include/drm/drm_plane.h | 2 +
> 5 files changed, 139 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 3eb061e..d0478ab 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -895,6 +895,8 @@ static int drm_atomic_plane_set_property(struct drm_plane
> *plane,
> state->src_h = val;
> } else if (property == plane->alpha_property) {
> state->alpha = val;
> + } else if (property == plane->blend_mode_property) {
> + state->pixel_blend_mode = val;
> } else if (property == plane->rotation_property) {
> if (!is_power_of_2(val & DRM_MODE_ROTATE_MASK)) {
> DRM_DEBUG_ATOMIC("[PLANE:%d:%s] bad rotation bitmask:
> 0x%llx\n",
> @@ -968,6 +970,8 @@ static int drm_atomic_plane_set_property(struct drm_plane
> *plane,
> *val = state->src_h;
> } else if (property == plane->alpha_property) {
> *val = state->alpha;
> + } else if (property == plane->blend_mode_property) {
> + *val = state->pixel_blend_mode;
> } else if (property == plane->rotation_property) {
> *val = state->rotation;
> } else if (property == plane->zpos_property) {
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 6dd5036..563af09 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -3569,6 +3569,7 @@ void __drm_atomic_helper_plane_reset(struct drm_plane
> *plane,
> /* Reset the alpha value to fully opaque if it matters */
> if (plane->alpha_property)
> state->alpha = plane->alpha_property->values[1];
> + plane->state->pixel_blend_mode = DRM_MODE_BLEND_PREMULTI;
>
> plane->state = state;
> }
> diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
> index a16a74d..24016c9 100644
> --- a/drivers/gpu/drm/drm_blend.c
> +++ b/drivers/gpu/drm/drm_blend.c
> @@ -107,6 +107,52 @@
> * planes. Without this property the primary plane is always below the
> cursor
> * plane, and ordering between all other planes is undefined.
> *
> + * pixel blend mode:
> + * Pixel blend mode is set up with drm_plane_create_blend_mode_property().
> + * It adds a blend mode for alpha blending equation selection, describing
> + * how the pixels from the current plane are composited with the
> + * background.
> + *
> + *Three alpha blending equations are defined:
> + *
> + *"None":
> + *Blend formula that ignores the pixel alpha::
> + *
> + *out.rgb = plane_alpha * fg.rgb +
> + *(1 - plane_alpha) * bg.rgb
> + *
> + *"Pre-multiplied":
> + *Blend formula that assumes the pixel color values
> + *have been already pre-multiplied with the alpha
> + *channel values::
> + *
> + *out.rgb = plane_alpha * fg.rgb +
> + *(1 - (plane_alpha * fg.alpha)) * bg.rgb
> + *
> + *"Coverage":
> + *Blend formula that assumes the pixel color values have not
> + *been pre-multiplied and will do so when blending them to the
> + *background color values::
> + *
> + *out.rgb = plane_alpha * fg.alpha * fg.rgb +
> + *(1 - (plane_alpha * fg.alpha)) * bg.rgb
> + *
> + *Using the
Re: [PATCH v2 4/5] drm: Add support for handling linear tile formats
On Tue, Aug 21, 2018 at 07:30:03PM +0100, Alexandru Gheorghe wrote:
> The previous patch added tile_w and tile_h, which represent the
> horizontal and vertical sizes of a tile.
>
> This one uses that to plumb through drm core in order to be able to
> handle linear tile formats without the need for drivers to roll up
> their own implementation.
>
> This patch had been written with Mali-dp X0L2 and X0L0 in mind which
> is a 1 plane YCbCr 420 format with a 2x2 tile, that uses in average 2
> bytes per pixel and where tiles are laid out in a linear manner.
>
> Now what are the restrictions:
>
> 1. Pitch in bytes is expected to cover at least tile_h * width in
> pixels. Due to this the places where the pitch is checked/used need to
> be updated to take into consideration the tile_w, tile_h and
> tile_size.
> tile_size = cpp * tile_w * tile_h
>
> 2. When doing source cropping plane_src_x/y need to be a multiple of
> tile_w/tile_h and we need to take into consideration the tile_w/tile_h
> when computing the start address.
>
> For all non-tiled formats the tile_w and tile_h will be 1, so if I
> didn't miss anything nothing should change.
>
> Regarding multi-planar linear tile formats, I'm not sure how those
> should be handle I kind of assumed that tile_h/tile_w will have to be
> divided by horizontal/subsampling. Anyway, I think it's best to just
> put an warning in there and handle it when someone tries to add
> support for them.
>
> Signed-off-by: Alexandru Gheorghe
> ---
> drivers/gpu/drm/drm_atomic.c | 8 +++
> drivers/gpu/drm/drm_fb_cma_helper.c | 11 -
> drivers/gpu/drm/drm_fourcc.c | 52
> drivers/gpu/drm/drm_framebuffer.c| 19 +--
> drivers/gpu/drm/drm_gem_framebuffer_helper.c | 10 ++--
> include/drm/drm_fourcc.h | 2 +
> 6 files changed, 94 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 3eb061e11e2e..7a3e893a4cd1 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -1087,6 +1087,14 @@ static int drm_atomic_plane_check(struct drm_plane
> *plane,
> return -ENOSPC;
> }
>
> + /* Make sure source coordinates are a multiple of tile sizes */
> + if ((state->src_x >> 16) % state->fb->format->tile_w ||
> + (state->src_y >> 16) % state->fb->format->tile_h) {
> + DRM_DEBUG_ATOMIC("[PLANE:%d:%s] Source coordinates do not meet
> tile restrictions",
> + plane->base.id, plane->name);
> + return -EINVAL;
> + }
Feels rather wrong to me to put such hardware specific limitations into
the core.
> +
> if (plane_switching_crtc(state->state, plane, state)) {
> DRM_DEBUG_ATOMIC("[PLANE:%d:%s] switching CRTC directly\n",
>plane->base.id, plane->name);
> diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c
> b/drivers/gpu/drm/drm_fb_cma_helper.c
> index 47e0e2f6642d..4d8052adce67 100644
> --- a/drivers/gpu/drm/drm_fb_cma_helper.c
> +++ b/drivers/gpu/drm/drm_fb_cma_helper.c
> @@ -87,6 +87,8 @@ dma_addr_t drm_fb_cma_get_gem_addr(struct drm_framebuffer
> *fb,
> struct drm_gem_cma_object *obj;
> dma_addr_t paddr;
> u8 h_div = 1, v_div = 1;
> + u32 tile_w = drm_format_tile_width(fb->format, plane);
> + u32 tile_h = drm_format_tile_height(fb->format, plane);
>
> obj = drm_fb_cma_get_gem_obj(fb, plane);
> if (!obj)
> @@ -99,8 +101,13 @@ dma_addr_t drm_fb_cma_get_gem_addr(struct drm_framebuffer
> *fb,
> v_div = fb->format->vsub;
> }
>
> - paddr += (fb->format->cpp[plane] * (state->src_x >> 16)) / h_div;
> - paddr += (fb->pitches[plane] * (state->src_y >> 16)) / v_div;
> + paddr += (fb->format->cpp[plane] * tile_w * (state->src_x >> 16))
> + / h_div;
> + /*
> + * For tile formats pitches are expected to cover at least
> + * width * tile_h pixels
> + */
> + paddr += ((fb->pitches[plane] / tile_h) * (state->src_y >> 16)) / v_div;
>
> return paddr;
> }
> diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
> index f55cd93ba2d0..d6c9c5aa4036 100644
> --- a/drivers/gpu/drm/drm_fourcc.c
> +++ b/drivers/gpu/drm/drm_fourcc.c
> @@ -557,3 +557,55 @@ int drm_format_plane_height(int height, uint32_t format,
> int plane)
> return height / info->vsub;
> }
> EXPORT_SYMBOL(drm_format_plane_height);
> +
> +/**
> + * drm_format_tile_width - width of a tile for tile formats, should be 1 for
> all
> + * non-tiled formats.
> + * @format: pixel format
> + * @plane: plane index
> + *
> + * Returns:
> + * The width of a tile, depending on the plane index and horizontal
> sub-sampling
> + */
> +uint32_t drm_format_tile_width(const struct drm_format_info *info, int plane)
> +{
> + WARN_ON(!info->tile_w);
> + if (plane == 0 || info->tile_w
Re: [igt-dev] RFC: Migration to Gitlab
On Wed, 22 Aug 2018, Daniel Vetter wrote: > Hi all, > > I think it's time to brainstorm a bit about the gitlab migration. Basic > reasons: > > - fd.o admins want to deprecate shell accounts and hand-rolled > infrastructure, because it's a pain to keep secure > > - gitlab will allow us to add committers on our own, greatly > simplifying that process (and offloading that task from fd.o admins). > > There's also some more benefits we might want to reap, like better CI > integration for basic build testing - no more "oops didn't build > drm-misc defconfigs" or "sry, forgot make check in maintainer-tools". > But that's all fully optional. > > For the full in-depth writeup of everything, see > > https://www.fooishbar.org/blog/gitlab-fdo-introduction/ > > I think now is also a good time, with mesa, xorg, wayland/weston and > others moved, to start thinking about how we'll move drm. There's a > few things to figure out though: > > - We probably want to split out maintainer-tools. That would address > the concern that there's 50+ committers to an auto-updating shell > script ... > > - We need to figure out how to handle the ACL trickery around drm-tip in > gitlab. > > - Probably good to stage the migration, with maintainer-tools, igt > leading. That will also make fd.o admins happy, who want to rework > their cloud infrastructure a bit before migrating the big kernel repos > over. > > - Figuring out the actual migration - we've been adding a pile of > committers since fd.o LDAP was converted to gitlab once back in > spring. We need to at least figure out how to move the new > accounts/committers. > > - Similar, maintainer-tools needs to move. We probably want to move > all the dim maintained kernel repos in one go, to avoid headaches with > double-accounts needed for committers. > > - CI, linux-next and everyone else should be fine, since the > cgit/non-ssh paths will keep working (they'll be read-only mirrors). > Need to double-check that with everyone. > > - Some organization structure would be good. > > https://cgit.freedesktop.org/drm > > libdrm won't be part of the gitlab drm group because that's already > moved under mesa (and you can't symlink/mulit-home anymore on gitlab): > > https://gitlab.freedesktop.org/mesa/drm > > But there's also drm_hwcomposer, which we might want to migrate into > drm too - gitlab requires a containing group, and > drm_hwcomposer/drm_hwcomposer is a bit silly. > > Note: Access rights can be done at any level in the hierarchy, the > organization is orthogonal to commit rights. > > - Anything else I've forgotten. > > A lot of this still needs to be figured out first. As a first step I'm > looking for volunteers who want to join the fun, besides comments and > thoughts on the overall topic of course. Just a couple of concerns from drm/i915 perspective for starters: - Patchwork integration. I think we'll want to keep patchwork for at least intel-gfx etc. for the time being. IIUC the one thing we need is some server side hook to update patchwork on git push. - Sticking to fdo bugzilla and disabling gitlab issues for at least drm-intel for the time being. Doing that migration in the same go is a bit much I think. Reassignment across bugzilla and gitlab will be an issue. BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [RFC v4 3/8] drm: Add Plane CTM property
On Wed, Aug 22, 2018 at 12:11:42PM +0100, Brian Starkey wrote:
> Hi,
>
> On Wed, Aug 22, 2018 at 12:53:58PM +0300, Ville Syrjälä wrote:
> >On Wed, Aug 22, 2018 at 08:40:19AM +, Lankhorst, Maarten wrote:
> >> fre 2018-08-17 klockan 19:48 +0530 skrev Uma Shankar:
> >> > Add a blob property for plane CSC usage.
> >> >
> >> > v2: Rebase
> >> >
> >> > v3: Fixed Sean, Paul's review comments. Moved the property from
> >> > mode_config to drm_plane. Created a helper function to instantiate
> >> > these properties and removed from drm_mode_create_standard_properties
> >> > Added property documentation as suggested by Daniel, Vetter.
> >> >
> >> > v4: Rebase
> >> >
> >> > Signed-off-by: Uma Shankar
> >> > ---
> >> > Documentation/gpu/drm-kms.rst | 3 +++
> >> > drivers/gpu/drm/drm_atomic.c| 10 ++
> >> > drivers/gpu/drm/drm_atomic_helper.c | 4
> >> > drivers/gpu/drm/drm_plane.c | 12
> >> > include/drm/drm_plane.h | 15 +++
> >> > 5 files changed, 44 insertions(+)
> >> >
> >> > diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-
> >> > kms.rst
> >> > index 8b10b12..16d6d8d 100644
> >> > --- a/Documentation/gpu/drm-kms.rst
> >> > +++ b/Documentation/gpu/drm-kms.rst
> >> > @@ -560,6 +560,9 @@ Plane Color Management Properties
> >> > .. kernel-doc:: drivers/gpu/drm/drm_plane.c
> >> > :doc: degamma_lut_size_property
> >> >
> >> > +.. kernel-doc:: drivers/gpu/drm/drm_plane.c
> >> > + :doc: ctm_property
> >> > +
> >> > Tile Group Property
> >> > ---
> >> >
> >> > diff --git a/drivers/gpu/drm/drm_atomic.c
> >> > b/drivers/gpu/drm/drm_atomic.c
> >> > index f8cad9b..ddda935 100644
> >> > --- a/drivers/gpu/drm/drm_atomic.c
> >> > +++ b/drivers/gpu/drm/drm_atomic.c
> >> > @@ -917,6 +917,14 @@ static int drm_atomic_plane_set_property(struct
> >> > drm_plane *plane,
> >> > );
> >> > state->color_mgmt_changed |= replaced;
> >> > return ret;
> >> > +} else if (property == plane->ctm_property) {
> >> > +ret = drm_atomic_replace_property_blob_from_id(dev,
> >> > +>ctm,
> >> > +val,
> >> > +sizeof(struct
> >> > drm_color_ctm), -1,
> >> > +);
> >> > +state->color_mgmt_changed |= replaced;
> >> > +return ret;
> >> > } else if (plane->funcs->atomic_set_property) {
> >> > return plane->funcs->atomic_set_property(plane,
> >> > state,
> >> > property, val);
> >> > @@ -988,6 +996,8 @@ static int drm_atomic_plane_set_property(struct
> >> > drm_plane *plane,
> >> > } else if (property == plane->degamma_lut_property) {
> >> > *val = (state->degamma_lut) ?
> >> > state->degamma_lut->base.id : 0;
> >> > +} else if (property == plane->ctm_property) {
> >> > +*val = (state->ctm) ? state->ctm->base.id : 0;
> >> > } else if (plane->funcs->atomic_get_property) {
> >> > return plane->funcs->atomic_get_property(plane,
> >> > state, property, val);
> >> > } else {
> >> > diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> >> > b/drivers/gpu/drm/drm_atomic_helper.c
> >> > index 67c5b51..866181f 100644
> >> > --- a/drivers/gpu/drm/drm_atomic_helper.c
> >> > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> >> > @@ -3616,6 +3616,9 @@ void
> >> > __drm_atomic_helper_plane_duplicate_state(struct drm_plane *plane,
> >> >
> >> > if (state->degamma_lut)
> >> > drm_property_blob_get(state->degamma_lut);
> >> > +if (state->ctm)
> >> > +drm_property_blob_get(state->ctm);
> >> > +
> >> > state->color_mgmt_changed = false;
> >> > }
> >> > EXPORT_SYMBOL(__drm_atomic_helper_plane_duplicate_state);
> >> > @@ -3663,6 +3666,7 @@ void
> >> > __drm_atomic_helper_plane_destroy_state(struct drm_plane_state
> >> > *state)
> >> > drm_crtc_commit_put(state->commit);
> >> >
> >> > drm_property_blob_put(state->degamma_lut);
> >> > +drm_property_blob_put(state->ctm);
> >> > }
> >> > EXPORT_SYMBOL(__drm_atomic_helper_plane_destroy_state);
> >> >
> >> > diff --git a/drivers/gpu/drm/drm_plane.c
> >> > b/drivers/gpu/drm/drm_plane.c
> >> > index 03e0560..97520b1 100644
> >> > --- a/drivers/gpu/drm/drm_plane.c
> >> > +++ b/drivers/gpu/drm/drm_plane.c
> >> > @@ -489,6 +489,11 @@ int drm_mode_plane_set_obj_prop(struct drm_plane
> >> > *plane,
> >> > *
> >> > * degamma_lut_size_property:
> >> > * Range Property to indicate size of the plane degamma LUT.
> >> > + *
> >> > + * ctm_property:
> >> > + * Blob property which allows a userspace to provide CTM
> >> > coefficients
> >> > + * to do color space
Re: [PATCH v2 4/5] drm: Add support for handling linear tile formats
On Tue, Aug 21, 2018 at 07:30:03PM +0100, Alexandru Gheorghe wrote:
> The previous patch added tile_w and tile_h, which represent the
> horizontal and vertical sizes of a tile.
>
> This one uses that to plumb through drm core in order to be able to
> handle linear tile formats without the need for drivers to roll up
> their own implementation.
>
> This patch had been written with Mali-dp X0L2 and X0L0 in mind which
> is a 1 plane YCbCr 420 format with a 2x2 tile, that uses in average 2
> bytes per pixel and where tiles are laid out in a linear manner.
>
> Now what are the restrictions:
>
> 1. Pitch in bytes is expected to cover at least tile_h * width in
> pixels.
This reads wrong for the first time reader. Maybe make the 'cpp'
explicit like you do later on?
> Due to this the places where the pitch is checked/used need to
> be updated to take into consideration the tile_w, tile_h and
> tile_size.
> tile_size = cpp * tile_w * tile_h
>
> 2. When doing source cropping plane_src_x/y need to be a multiple of
> tile_w/tile_h and we need to take into consideration the tile_w/tile_h
> when computing the start address.
>
> For all non-tiled formats the tile_w and tile_h will be 1, so if I
> didn't miss anything nothing should change.
>
> Regarding multi-planar linear tile formats, I'm not sure how those
> should be handle I kind of assumed that tile_h/tile_w will have to be
> divided by horizontal/subsampling. Anyway, I think it's best to just
> put an warning in there and handle it when someone tries to add
> support for them.
>
> Signed-off-by: Alexandru Gheorghe
> ---
> drivers/gpu/drm/drm_atomic.c | 8 +++
> drivers/gpu/drm/drm_fb_cma_helper.c | 11 -
> drivers/gpu/drm/drm_fourcc.c | 52
> drivers/gpu/drm/drm_framebuffer.c| 19 +--
> drivers/gpu/drm/drm_gem_framebuffer_helper.c | 10 ++--
> include/drm/drm_fourcc.h | 2 +
> 6 files changed, 94 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 3eb061e11e2e..7a3e893a4cd1 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -1087,6 +1087,14 @@ static int drm_atomic_plane_check(struct drm_plane
> *plane,
> return -ENOSPC;
> }
>
> + /* Make sure source coordinates are a multiple of tile sizes */
> + if ((state->src_x >> 16) % state->fb->format->tile_w ||
> + (state->src_y >> 16) % state->fb->format->tile_h) {
> + DRM_DEBUG_ATOMIC("[PLANE:%d:%s] Source coordinates do not meet
> tile restrictions",
> + plane->base.id, plane->name);
> + return -EINVAL;
> + }
> +
> if (plane_switching_crtc(state->state, plane, state)) {
> DRM_DEBUG_ATOMIC("[PLANE:%d:%s] switching CRTC directly\n",
>plane->base.id, plane->name);
> diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c
> b/drivers/gpu/drm/drm_fb_cma_helper.c
> index 47e0e2f6642d..4d8052adce67 100644
> --- a/drivers/gpu/drm/drm_fb_cma_helper.c
> +++ b/drivers/gpu/drm/drm_fb_cma_helper.c
> @@ -87,6 +87,8 @@ dma_addr_t drm_fb_cma_get_gem_addr(struct drm_framebuffer
> *fb,
> struct drm_gem_cma_object *obj;
> dma_addr_t paddr;
> u8 h_div = 1, v_div = 1;
> + u32 tile_w = drm_format_tile_width(fb->format, plane);
> + u32 tile_h = drm_format_tile_height(fb->format, plane);
>
> obj = drm_fb_cma_get_gem_obj(fb, plane);
> if (!obj)
> @@ -99,8 +101,13 @@ dma_addr_t drm_fb_cma_get_gem_addr(struct drm_framebuffer
> *fb,
> v_div = fb->format->vsub;
> }
>
> - paddr += (fb->format->cpp[plane] * (state->src_x >> 16)) / h_div;
> - paddr += (fb->pitches[plane] * (state->src_y >> 16)) / v_div;
> + paddr += (fb->format->cpp[plane] * tile_w * (state->src_x >> 16))
> + / h_div;
I think you can keep the division by h_div on the same line, you're not
spilling over the limit that much compared to the next line of code.
> + /*
> + * For tile formats pitches are expected to cover at least
> + * width * tile_h pixels
> + */
> + paddr += ((fb->pitches[plane] / tile_h) * (state->src_y >> 16)) / v_div;
>
> return paddr;
> }
> diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
> index f55cd93ba2d0..d6c9c5aa4036 100644
> --- a/drivers/gpu/drm/drm_fourcc.c
> +++ b/drivers/gpu/drm/drm_fourcc.c
> @@ -557,3 +557,55 @@ int drm_format_plane_height(int height, uint32_t format,
> int plane)
> return height / info->vsub;
> }
> EXPORT_SYMBOL(drm_format_plane_height);
> +
> +/**
> + * drm_format_tile_width - width of a tile for tile formats, should be 1 for
> all
> + * non-tiled formats.
> + * @format: pixel format
> + * @plane: plane index
> + *
> + * Returns:
> + * The width of a tile, depending on the plane index and horizontal
>
Re: [Intel-gfx] RFC: Migration to Gitlab
On Wed, Aug 22, 2018 at 01:44:56PM +0200, Daniel Vetter wrote: > Hi all, > > I think it's time to brainstorm a bit about the gitlab migration. Basic > reasons: > > - fd.o admins want to deprecate shell accounts and hand-rolled > infrastructure, because it's a pain to keep secure > > - gitlab will allow us to add committers on our own, greatly > simplifying that process (and offloading that task from fd.o admins). > > There's also some more benefits we might want to reap, like better CI > integration for basic build testing - no more "oops didn't build > drm-misc defconfigs" or "sry, forgot make check in maintainer-tools". > But that's all fully optional. > > For the full in-depth writeup of everything, see > > https://www.fooishbar.org/blog/gitlab-fdo-introduction/ > > I think now is also a good time, with mesa, xorg, wayland/weston and > others moved, to start thinking about how we'll move drm. There's a > few things to figure out though: > > - We probably want to split out maintainer-tools. That would address > the concern that there's 50+ committers to an auto-updating shell > script ... > /me laughs nervously > - We need to figure out how to handle the ACL trickery around drm-tip in > gitlab. > > - Probably good to stage the migration, with maintainer-tools, igt > leading. That will also make fd.o admins happy, who want to rework > their cloud infrastructure a bit before migrating the big kernel repos > over. > > - Figuring out the actual migration - we've been adding a pile of > committers since fd.o LDAP was converted to gitlab once back in > spring. We need to at least figure out how to move the new > accounts/committers. > > - Similar, maintainer-tools needs to move. We probably want to move > all the dim maintained kernel repos in one go, to avoid headaches with > double-accounts needed for committers. > > - CI, linux-next and everyone else should be fine, since the > cgit/non-ssh paths will keep working (they'll be read-only mirrors). > Need to double-check that with everyone. They can also pull the trees from git://gitlab.fd.o/blah as normal, just need to give them new pointers once we're stable. > > - Some organization structure would be good. > > https://cgit.freedesktop.org/drm > > libdrm won't be part of the gitlab drm group because that's already > moved under mesa (and you can't symlink/mulit-home anymore on gitlab): > > https://gitlab.freedesktop.org/mesa/drm > > But there's also drm_hwcomposer, which we might want to migrate into > drm too - gitlab requires a containing group, and > drm_hwcomposer/drm_hwcomposer is a bit silly. This seems fine to me. Our expansion plans likely aren't big enough to warrant a separate group. > > Note: Access rights can be done at any level in the hierarchy, the > organization is orthogonal to commit rights. > > - Anything else I've forgotten. > > A lot of this still needs to be figured out first. As a first step I'm > looking for volunteers who want to join the fun, besides comments and > thoughts on the overall topic of course. I'm pretty keen on getting this done, so I'll volunteer some cycles if there's something that needs doing. Sean > > Cheers, Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch > ___ > Intel-gfx mailing list > intel-...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Sean Paul, Software Engineer, Google / Chromium OS ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/4] drm/fb: Stop leaking physical address
On Wed, Aug 22, 2018 at 10:54:05AM +0200, Daniel Vetter wrote: > For buffer sharing, use dma-buf instead. We can't set smem_start to 0 > unconditionally since that's used by the fbdev mmap default > implementation. And we have plenty of userspace which would like to > keep that working. > > This might break legit userspace - if it does we need to look at a > case-by-cases basis how to handle that. Worst case I expect overrides > for only specific drivers, since anything remotely modern should be > using dma-buf/prime now (which is about 7 years old now for DRM > drivers). > > This issue was uncovered because Noralf's rework to implement a > generic fb_probe also implements it's own fb_mmap callback. Which > means smem_start didn't have to be set anymore, which blew up some > blob in userspace rather badly. > > Cc: Gustavo Padovan > Cc: Maarten Lankhorst > Cc: Sean Paul > Cc: David Airlie > Cc: John Stultz > Cc: Noralf Trønnes > Signed-off-by: Daniel Vetter After clarifying on IRC, I think this makes sense. The chance to break userspace requires a very specific configuration that I don't expect will be common. Acked-by: Sean Paul > --- > drivers/gpu/drm/drm_fb_helper.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c > index 4b0dd20bccb8..bcb78693c4f7 100644 > --- a/drivers/gpu/drm/drm_fb_helper.c > +++ b/drivers/gpu/drm/drm_fb_helper.c > @@ -2673,6 +2673,8 @@ __drm_fb_helper_initial_config_and_unlock(struct > drm_fb_helper *fb_helper, > > info = fb_helper->fbdev; > info->var.pixclock = 0; > + /* don't leak any physical addresses to userspace */ > + info->flags |= FBINFO_HIDE_SMEM_START; > > /* Need to drop locks to avoid recursive deadlock in >* register_framebuffer. This is ok because the only thing left to do is > -- > 2.18.0 > -- Sean Paul, Software Engineer, Google / Chromium OS ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [RFC v4 3/8] drm: Add Plane CTM property
ons 2018-08-22 klockan 12:11 +0100 skrev Brian Starkey:
> Hi,
>
> On Wed, Aug 22, 2018 at 12:53:58PM +0300, Ville Syrjälä wrote:
> > On Wed, Aug 22, 2018 at 08:40:19AM +, Lankhorst, Maarten wrote:
> > > fre 2018-08-17 klockan 19:48 +0530 skrev Uma Shankar:
> > > > Add a blob property for plane CSC usage.
> > > >
> > > > v2: Rebase
> > > >
> > > > v3: Fixed Sean, Paul's review comments. Moved the property from
> > > > mode_config to drm_plane. Created a helper function to
> > > > instantiate
> > > > these properties and removed from
> > > > drm_mode_create_standard_properties
> > > > Added property documentation as suggested by Daniel, Vetter.
> > > >
> > > > v4: Rebase
> > > >
> > > > Signed-off-by: Uma Shankar
> > > > ---
> > > > Documentation/gpu/drm-kms.rst | 3 +++
> > > > drivers/gpu/drm/drm_atomic.c| 10 ++
> > > > drivers/gpu/drm/drm_atomic_helper.c | 4
> > > > drivers/gpu/drm/drm_plane.c | 12
> > > > include/drm/drm_plane.h | 15 +++
> > > > 5 files changed, 44 insertions(+)
> > > >
> > > > diff --git a/Documentation/gpu/drm-kms.rst
> > > > b/Documentation/gpu/drm-
> > > > kms.rst
> > > > index 8b10b12..16d6d8d 100644
> > > > --- a/Documentation/gpu/drm-kms.rst
> > > > +++ b/Documentation/gpu/drm-kms.rst
> > > > @@ -560,6 +560,9 @@ Plane Color Management Properties
> > > > .. kernel-doc:: drivers/gpu/drm/drm_plane.c
> > > > :doc: degamma_lut_size_property
> > > >
> > > > +.. kernel-doc:: drivers/gpu/drm/drm_plane.c
> > > > + :doc: ctm_property
> > > > +
> > > > Tile Group Property
> > > > ---
> > > >
> > > > diff --git a/drivers/gpu/drm/drm_atomic.c
> > > > b/drivers/gpu/drm/drm_atomic.c
> > > > index f8cad9b..ddda935 100644
> > > > --- a/drivers/gpu/drm/drm_atomic.c
> > > > +++ b/drivers/gpu/drm/drm_atomic.c
> > > > @@ -917,6 +917,14 @@ static int
> > > > drm_atomic_plane_set_property(struct
> > > > drm_plane *plane,
> > > > );
> > > > state->color_mgmt_changed |= replaced;
> > > > return ret;
> > > > + } else if (property == plane->ctm_property) {
> > > > + ret =
> > > > drm_atomic_replace_property_blob_from_id(dev,
> > > > + >ctm,
> > > > + val,
> > > > + sizeof(struct
> > > > drm_color_ctm), -1,
> > > > + );
> > > > + state->color_mgmt_changed |= replaced;
> > > > + return ret;
> > > > } else if (plane->funcs->atomic_set_property) {
> > > > return plane->funcs-
> > > > >atomic_set_property(plane,
> > > > state,
> > > > property, val);
> > > > @@ -988,6 +996,8 @@ static int
> > > > drm_atomic_plane_set_property(struct
> > > > drm_plane *plane,
> > > > } else if (property == plane->degamma_lut_property) {
> > > > *val = (state->degamma_lut) ?
> > > > state->degamma_lut->base.id : 0;
> > > > + } else if (property == plane->ctm_property) {
> > > > + *val = (state->ctm) ? state->ctm->base.id : 0;
> > > > } else if (plane->funcs->atomic_get_property) {
> > > > return plane->funcs-
> > > > >atomic_get_property(plane,
> > > > state, property, val);
> > > > } else {
> > > > diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> > > > b/drivers/gpu/drm/drm_atomic_helper.c
> > > > index 67c5b51..866181f 100644
> > > > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > > > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > > > @@ -3616,6 +3616,9 @@ void
> > > > __drm_atomic_helper_plane_duplicate_state(struct drm_plane
> > > > *plane,
> > > >
> > > > if (state->degamma_lut)
> > > > drm_property_blob_get(state->degamma_lut);
> > > > + if (state->ctm)
> > > > + drm_property_blob_get(state->ctm);
> > > > +
> > > > state->color_mgmt_changed = false;
> > > > }
> > > > EXPORT_SYMBOL(__drm_atomic_helper_plane_duplicate_state);
> > > > @@ -3663,6 +3666,7 @@ void
> > > > __drm_atomic_helper_plane_destroy_state(struct drm_plane_state
> > > > *state)
> > > > drm_crtc_commit_put(state->commit);
> > > >
> > > > drm_property_blob_put(state->degamma_lut);
> > > > + drm_property_blob_put(state->ctm);
> > > > }
> > > > EXPORT_SYMBOL(__drm_atomic_helper_plane_destroy_state);
> > > >
> > > > diff --git a/drivers/gpu/drm/drm_plane.c
> > > > b/drivers/gpu/drm/drm_plane.c
> > > > index 03e0560..97520b1 100644
> > > > --- a/drivers/gpu/drm/drm_plane.c
> > > > +++ b/drivers/gpu/drm/drm_plane.c
> > > > @@ -489,6 +489,11 @@ int drm_mode_plane_set_obj_prop(struct
> > > > drm_plane
> > > > *plane,
> > > > *
> > > > * degamma_lut_size_property:
> > > > * Range Property to indicate size of the plane degamma
> > > >
Re: [PATCH v4 1/2] drm: Add per-plane pixel blend mode property
On Wed, Aug 15, 2018 at 02:35:32PM +0800, Lowry Li wrote:
> Pixel blend modes represent the alpha blending equation
> selection, describing how the pixels from the current
> plane are composited with the background.
>
> Adds a pixel_blend_mode to drm_plane_state and a
> blend_mode_property to drm_plane, and related support
> functions.
>
> Defines three blend modes in drm_blend.h.
>
> Changes since v1:
> - Moves the blending equation into the DOC comment
> - Refines the comments of drm_plane_create_blend_mode_property to not
>enumerate the #defines, but instead the string values
> - Uses fg.* instead of pixel.* and plane_alpha instead of plane.alpha
> Changes since v2:
> - Refines the comments of drm_plane_create_blend_mode_property:
> 1) Puts the descriptions (after the ":") on a new line
> 2) Adds explaining why @supported_modes need PREMUL as default
> Changes since v3:
> - Refines drm_plane_create_blend_mode_property(). drm_property_add_enum()
>can calculate the index itself just fine, so no point in having the
>caller pass it in.
> - Since the current DRM assumption is that alpha is premultiplied
>as default, define DRM_MODE_BLEND_PREMULTI as 0 will be better.
> - Refines some comments.
>
> Signed-off-by: Lowry Li
> ---
> drivers/gpu/drm/drm_atomic.c| 4 ++
> drivers/gpu/drm/drm_atomic_helper.c | 1 +
> drivers/gpu/drm/drm_blend.c | 126
>
> include/drm/drm_blend.h | 6 ++
> include/drm/drm_plane.h | 2 +
> 5 files changed, 139 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 3eb061e..d0478ab 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -895,6 +895,8 @@ static int drm_atomic_plane_set_property(struct drm_plane
> *plane,
> state->src_h = val;
> } else if (property == plane->alpha_property) {
> state->alpha = val;
> + } else if (property == plane->blend_mode_property) {
> + state->pixel_blend_mode = val;
> } else if (property == plane->rotation_property) {
> if (!is_power_of_2(val & DRM_MODE_ROTATE_MASK)) {
> DRM_DEBUG_ATOMIC("[PLANE:%d:%s] bad rotation bitmask:
> 0x%llx\n",
> @@ -968,6 +970,8 @@ static int drm_atomic_plane_set_property(struct drm_plane
> *plane,
> *val = state->src_h;
> } else if (property == plane->alpha_property) {
> *val = state->alpha;
> + } else if (property == plane->blend_mode_property) {
> + *val = state->pixel_blend_mode;
> } else if (property == plane->rotation_property) {
> *val = state->rotation;
> } else if (property == plane->zpos_property) {
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 6dd5036..563af09 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -3569,6 +3569,7 @@ void __drm_atomic_helper_plane_reset(struct drm_plane
> *plane,
> /* Reset the alpha value to fully opaque if it matters */
> if (plane->alpha_property)
> state->alpha = plane->alpha_property->values[1];
> + plane->state->pixel_blend_mode = DRM_MODE_BLEND_PREMULTI;
Shouldn't this be state->pixel_blend_mode instead of
plane->state->pixel_blend_mode?
>
> plane->state = state;
> }
/snip
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/3] drm: rcar-du: Write ESCR register per channel
Hi Jacopo, Thank you for the patch. On Wednesday, 22 August 2018 10:21:48 EEST Jacopo Mondi wrote: > The ESCR registers offset definition is confusing, as each channel is > equipped with an ESCR register instance, but the names suggest only ESCR and > ESCR2 are taken into account. > > Rename the offsets to a name that includes the channels they apply to, and > write them to each channel with 'rcar_du_crtc_write()'. > > Cosmetic patch, no functional changes intended. I think patches 2/3 and 3/3 can be squashed together, there's no real reason to keep them separate. I propose updating the commit message to "drm: rcar-du: Write ESCR and OTAR as CRTC registers The ESCR and OTAR registers exist in each DU channel, but at different offsets for odd and even channels. This led to usage of the group register access API to write them, with offsets macros named ESCR/OTAR and ESCR2/OTAR2 for the first and second ESCR/OTAR register in the group respectively. The names are confusing as it suggests that the ESCR/OTAR registers for DU0 and DU2 are taken into account, especially with writes performed to the group register access API. Rename the offsets to ESCR/OTAR02 and ESCR/OTAR13, and use the CRTC register access API to clarify the code. The offsets values are updated accordingly. Cosmetic patch, no functional changes intended." Otherwise the patches look good to me, so Reviewed-by: Laurent Pinchart and applied the squashed version to my tree. > Signed-off-by: Jacopo Mondi > --- > drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 3 +-- > drivers/gpu/drm/rcar-du/rcar_du_regs.h | 4 ++-- > 2 files changed, 3 insertions(+), 4 deletions(-) > > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c > b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c index 5454884..714c1fc 100644 > --- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c > +++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c > @@ -294,8 +294,7 @@ static void rcar_du_crtc_set_display_timing(struct > rcar_du_crtc *rcrtc) } > } > > - rcar_du_group_write(rcrtc->group, rcrtc->index % 2 ? ESCR2 : ESCR, > - escr); > + rcar_du_crtc_write(rcrtc, rcrtc->index % 2 ? ESCR13 : ESCR02, escr); > rcar_du_group_write(rcrtc->group, rcrtc->index % 2 ? OTAR2 : OTAR, 0); > > /* Signal polarities */ > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_regs.h > b/drivers/gpu/drm/rcar-du/rcar_du_regs.h index 9dfd220..ebc4aea 100644 > --- a/drivers/gpu/drm/rcar-du/rcar_du_regs.h > +++ b/drivers/gpu/drm/rcar-du/rcar_du_regs.h > @@ -492,8 +492,8 @@ > * External Synchronization Control Registers > */ > > -#define ESCR 0x1 > -#define ESCR20x31000 > +#define ESCR02 0x1 > +#define ESCR13 0x01000 > #define ESCR_DCLKOINV(1 << 25) > #define ESCR_DCLKSEL_DCLKIN (0 << 20) > #define ESCR_DCLKSEL_CLKS(1 << 20) -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RFC: Migration to Gitlab
Hi all, I think it's time to brainstorm a bit about the gitlab migration. Basic reasons: - fd.o admins want to deprecate shell accounts and hand-rolled infrastructure, because it's a pain to keep secure - gitlab will allow us to add committers on our own, greatly simplifying that process (and offloading that task from fd.o admins). There's also some more benefits we might want to reap, like better CI integration for basic build testing - no more "oops didn't build drm-misc defconfigs" or "sry, forgot make check in maintainer-tools". But that's all fully optional. For the full in-depth writeup of everything, see https://www.fooishbar.org/blog/gitlab-fdo-introduction/ I think now is also a good time, with mesa, xorg, wayland/weston and others moved, to start thinking about how we'll move drm. There's a few things to figure out though: - We probably want to split out maintainer-tools. That would address the concern that there's 50+ committers to an auto-updating shell script ... - We need to figure out how to handle the ACL trickery around drm-tip in gitlab. - Probably good to stage the migration, with maintainer-tools, igt leading. That will also make fd.o admins happy, who want to rework their cloud infrastructure a bit before migrating the big kernel repos over. - Figuring out the actual migration - we've been adding a pile of committers since fd.o LDAP was converted to gitlab once back in spring. We need to at least figure out how to move the new accounts/committers. - Similar, maintainer-tools needs to move. We probably want to move all the dim maintained kernel repos in one go, to avoid headaches with double-accounts needed for committers. - CI, linux-next and everyone else should be fine, since the cgit/non-ssh paths will keep working (they'll be read-only mirrors). Need to double-check that with everyone. - Some organization structure would be good. https://cgit.freedesktop.org/drm libdrm won't be part of the gitlab drm group because that's already moved under mesa (and you can't symlink/mulit-home anymore on gitlab): https://gitlab.freedesktop.org/mesa/drm But there's also drm_hwcomposer, which we might want to migrate into drm too - gitlab requires a containing group, and drm_hwcomposer/drm_hwcomposer is a bit silly. Note: Access rights can be done at any level in the hierarchy, the organization is orthogonal to commit rights. - Anything else I've forgotten. A lot of this still needs to be figured out first. As a first step I'm looking for volunteers who want to join the fun, besides comments and thoughts on the overall topic of course. Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Mesa-dev] [PATCH libdrm] Add basic CONTRIBUTING file
On Wednesday, 2018-08-22 13:10:42 +0200, Daniel Vetter wrote:
> On Wed, Aug 22, 2018 at 1:08 PM, Eric Engestrom
> wrote:
> > On Wednesday, 2018-08-22 12:51:39 +0200, Daniel Vetter wrote:
> >> I picked up a bunch of the pieces from wayland's version:
> >>
> >> https://gitlab.freedesktop.org/wayland/wayland/blob/master/CONTRIBUTING.md
> >>
> >> The weston one is fairly similar. Then I rather massively trimmed it
> >> down since in reality libdrm is a bit a dumping ground with very few
> >> real rules. The commit rights and CoC sections I've copied verbatim
> >> from igt respectively drm-misc. Weston/Wayland only differ in their
> >> pick of how many patches you need (10 instead of 5). I think for
> >> libdrm this is supremely relevant, since most everyone will get their
> >> commit rights by contributing already to the kernel or mesa and having
> >> commit rights there already.
> >>
> >> Anyway, I figured this is good to get the rules documented, even if
> >> there's mostly not many rules.
> >>
> >> Note: This references maintainers in a MAINTAINERS file, which needs
> >> to be created first.
> >>
> >> Note: With the gitlab migration the entire commit rights process is
> >> still a bit up in the air. But gitlab commit rights and roles are
> >> hierarchical, so we can do libdrm-only maintainer/commiter roles
> >> ("Owner" and "Developer" in gitlab-speak). This should avoid
> >> conflating libdrm roles with mesa roles, useful for those pushing to
> >> libdrm as primarily kernel contributors.
> >>
> >> v2: Comments from Emil:
> >> - Recommend subject prefix.
> >> - Fix copypaste fumbles, this isn't igt/wayland ...
> >>
> >> v3: Comments from Marek:
> >> - libdrm moved to mesa, update the document. Atm the entire account
> >> request situation is entirely not clear for gitlab and mesa
> >> projects, so that's a bit up in the air. Also, should probably send
> >> an announcement to dri-devel@, which didn't happen.
> >> - amd folks don't submit their patches to dri-devel, document that.
> >> Probably applies to other drivers too.
> >>
> >> v4: Comments from Rob:
> >> - Also include kernel/userspace in the commit counts criteria, due to
> >> libdrm's special role as a glue library.
> >>
> >> v5: Summarize the irc discussion on gitlab roles in the commit message
> >> a bit.
> >>
> >> v6: Some grammer stuff from Eric.
> >>
> >> Cc: Emil Velikov
> >> Cc: Marek Olšák
> >> Cc: Rob Clark
> >> Cc: Eric Engestrom
> >> Reviewed-by: Rob Clark (v4)
> >> Reviewed-by: Eric Engestrom (v6)
> >> Acked-by: Emil Velikov (v6)
> >> Acked-by: Marek Olšák (v5)
> >> References:
> >> https://gitlab.freedesktop.org/wayland/weston/blob/master/CONTRIBUTING.md
> >> References:
> >> https://01.org/linuxgraphics/gfx-docs/maintainer-tools/drm-misc.html#commit-rights
> >> References:
> >> https://cgit.freedesktop.org/drm/igt-gpu-tools/tree/CONTRIBUTING#n54
> >> Signed-off-by: Daniel Vetter
> >> ---
> >> CONTRIBUTING | 105 +++
> >> 1 file changed, 105 insertions(+)
> >> create mode 100644 CONTRIBUTING
> >>
> >> diff --git a/CONTRIBUTING b/CONTRIBUTING
> >> new file mode 100644
> >> index ..6cd09dd069bb
> >> --- /dev/null
> >> +++ b/CONTRIBUTING
> >> @@ -0,0 +1,105 @@
> >> +Contributing to libdrm
> >> +==
> >> +
> >> +Submitting Patches
> >> +--
> >> +
> >> +Patches should be sent to dri-devel@lists.freedesktop.org, using git
> >> +send-email. For patches only touching driver specific code one of the
> >> driver
> >> +mailing lists (like amd-...@lists.freedesktop.org) is also appropriate.
> >> See git
> >> +documentation for help:
> >> +
> >> +http://git-scm.com/documentation
> >
> > Actually, just thought about something we could add here:
> >
> > "
> > You can set the default address by running:
> > $ git config --local sendemail.to dri-devel@lists.freedesktop.org
> >
> > You can still override it when sending your patch by passing `--to`:
> > $ git send-email -1 --to amd-...@lists.freedesktop.org
>
> Uh, this sounds dangerous. We already have plenty fun when people
> forget --suppress-cc=all when sending around internal patches. And
> then it's usually just individuals, not lists.
>
> This is practically begging for leaks.
Good point, didn't think about that.
>
> > "
> >
> >> +
> >> +Since dri-devel is a very busy mailing list please use
> >> --subject-prefix="PATCH
> >> +libdrm" to make it easier to find libdrm patches. This is best done by
> >> running
> >> +
> >> +git config format.subjectprefix "PATCH libdrm"
> >
> > I would also recommend adding `--local` here to avoid people
> > accidentally running this outside their repo and setting it globally.
>
> Good idea, will fix.
> -Daniel
>
> >
> >> +
> >> +The first line of a commit message should contain a prefix indicating
> >> what part
> >> +is affected by the patch followed by one sentence that describes the
> >> change. For
> >> +examples:
> >> +
>
[Bug 105912] [IGT] gem_exec_reloc@cpu-30 iwlwifi 0000:00:14.3: Scan failed! ret -110 dmesg-warn
https://bugs.freedesktop.org/show_bug.cgi?id=105912 Lakshmi changed: What|Removed |Added Status|RESOLVED|CLOSED -- 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 105912] [IGT] gem_exec_reloc@cpu-30 iwlwifi 0000:00:14.3: Scan failed! ret -110 dmesg-warn
https://bugs.freedesktop.org/show_bug.cgi?id=105912 --- Comment #2 from Lakshmi --- This is not a graphics bug. Tests related to gem_exec_reloc doesn't have any failures in CI. Closing this bug. https://intel-gfx-ci.01.org/tree/drm-tip/igt-shards-all.html. -- 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 1/2] drm: rename null fence to stub fence in syncobj
On Wed, Aug 22, 2018 at 05:56:10PM +0800, zhoucm1 wrote:
>
>
> On 2018年08月22日 17:34, Daniel Vetter wrote:
> > On Wed, Aug 22, 2018 at 04:38:56PM +0800, Chunming Zhou wrote:
> > > stub fence will be used by timeline syncobj as well.
> > >
> > > Change-Id: Ia4252f03c07a8105491d2791dc7c8c6976682285
> > > Signed-off-by: Chunming Zhou
> > > Cc: Jason Ekstrand
> > Please don't expose stuff only used by the drm_syncobj implementation to
> > drivers. Gives us a very unclean driver interface. Imo this should all be
> > left within drm_syncobj.h.
> .c? will fix that.
Yup I meant to leave it all in drm_syncobj.c :-)
-Daniel
> >
> > See also my comments for patch 2, you leak all the implemenation details
> > to drivers. We need to fix that and have a clear interface.
> Yes, I will address them when I do v2.
>
> Thanks,
> David Zhou
> > -Daniel
> >
> > > ---
> > > drivers/gpu/drm/drm_syncobj.c | 28 ++--
> > > include/drm/drm_syncobj.h | 24
> > > 2 files changed, 26 insertions(+), 26 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
> > > index d4f4ce484529..70af32d0def1 100644
> > > --- a/drivers/gpu/drm/drm_syncobj.c
> > > +++ b/drivers/gpu/drm/drm_syncobj.c
> > > @@ -187,39 +187,15 @@ void drm_syncobj_replace_fence(struct drm_syncobj
> > > *syncobj,
> > > }
> > > EXPORT_SYMBOL(drm_syncobj_replace_fence);
> > > -struct drm_syncobj_null_fence {
> > > - struct dma_fence base;
> > > - spinlock_t lock;
> > > -};
> > > -
> > > -static const char *drm_syncobj_null_fence_get_name(struct dma_fence
> > > *fence)
> > > -{
> > > -return "syncobjnull";
> > > -}
> > > -
> > > -static bool drm_syncobj_null_fence_enable_signaling(struct dma_fence
> > > *fence)
> > > -{
> > > -dma_fence_enable_sw_signaling(fence);
> > > -return !dma_fence_is_signaled(fence);
> > > -}
> > > -
> > > -static const struct dma_fence_ops drm_syncobj_null_fence_ops = {
> > > - .get_driver_name = drm_syncobj_null_fence_get_name,
> > > - .get_timeline_name = drm_syncobj_null_fence_get_name,
> > > - .enable_signaling = drm_syncobj_null_fence_enable_signaling,
> > > - .wait = dma_fence_default_wait,
> > > - .release = NULL,
> > > -};
> > > -
> > > static int drm_syncobj_assign_null_handle(struct drm_syncobj *syncobj)
> > > {
> > > - struct drm_syncobj_null_fence *fence;
> > > + struct drm_syncobj_stub_fence *fence;
> > > fence = kzalloc(sizeof(*fence), GFP_KERNEL);
> > > if (fence == NULL)
> > > return -ENOMEM;
> > > spin_lock_init(>lock);
> > > - dma_fence_init(>base, _syncobj_null_fence_ops,
> > > + dma_fence_init(>base, _syncobj_stub_fence_ops,
> > > >lock, 0, 0);
> > > dma_fence_signal(>base);
> > > diff --git a/include/drm/drm_syncobj.h b/include/drm/drm_syncobj.h
> > > index 3980602472c0..b04c492ddbb5 100644
> > > --- a/include/drm/drm_syncobj.h
> > > +++ b/include/drm/drm_syncobj.h
> > > @@ -30,6 +30,30 @@
> > > struct drm_syncobj_cb;
> > > +struct drm_syncobj_stub_fence {
> > > + struct dma_fence base;
> > > + spinlock_t lock;
> > > +};
> > > +
> > > +const char *drm_syncobj_stub_fence_get_name(struct dma_fence *fence)
> > > +{
> > > +return "syncobjstub";
> > > +}
> > > +
> > > +bool drm_syncobj_stub_fence_enable_signaling(struct dma_fence *fence)
> > > +{
> > > +dma_fence_enable_sw_signaling(fence);
> > > +return !dma_fence_is_signaled(fence);
> > > +}
> > > +
> > > +const struct dma_fence_ops drm_syncobj_stub_fence_ops = {
> > > + .get_driver_name = drm_syncobj_stub_fence_get_name,
> > > + .get_timeline_name = drm_syncobj_stub_fence_get_name,
> > > + .enable_signaling = drm_syncobj_stub_fence_enable_signaling,
> > > + .wait = dma_fence_default_wait,
> > > + .release = NULL,
> > > +};
> > > +
> > > /**
> > >* struct drm_syncobj - sync object.
> > >*
> > > --
> > > 2.14.1
> > >
> > > ___
> > > dri-devel mailing list
> > > dri-devel@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [RFC v4 3/8] drm: Add Plane CTM property
Hi,
On Wed, Aug 22, 2018 at 12:53:58PM +0300, Ville Syrjälä wrote:
On Wed, Aug 22, 2018 at 08:40:19AM +, Lankhorst, Maarten wrote:
fre 2018-08-17 klockan 19:48 +0530 skrev Uma Shankar:
> Add a blob property for plane CSC usage.
>
> v2: Rebase
>
> v3: Fixed Sean, Paul's review comments. Moved the property from
> mode_config to drm_plane. Created a helper function to instantiate
> these properties and removed from drm_mode_create_standard_properties
> Added property documentation as suggested by Daniel, Vetter.
>
> v4: Rebase
>
> Signed-off-by: Uma Shankar
> ---
> Documentation/gpu/drm-kms.rst | 3 +++
> drivers/gpu/drm/drm_atomic.c| 10 ++
> drivers/gpu/drm/drm_atomic_helper.c | 4
> drivers/gpu/drm/drm_plane.c | 12
> include/drm/drm_plane.h | 15 +++
> 5 files changed, 44 insertions(+)
>
> diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-
> kms.rst
> index 8b10b12..16d6d8d 100644
> --- a/Documentation/gpu/drm-kms.rst
> +++ b/Documentation/gpu/drm-kms.rst
> @@ -560,6 +560,9 @@ Plane Color Management Properties
> .. kernel-doc:: drivers/gpu/drm/drm_plane.c
> :doc: degamma_lut_size_property
>
> +.. kernel-doc:: drivers/gpu/drm/drm_plane.c
> + :doc: ctm_property
> +
> Tile Group Property
> ---
>
> diff --git a/drivers/gpu/drm/drm_atomic.c
> b/drivers/gpu/drm/drm_atomic.c
> index f8cad9b..ddda935 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -917,6 +917,14 @@ static int drm_atomic_plane_set_property(struct
> drm_plane *plane,
>);
>state->color_mgmt_changed |= replaced;
>return ret;
> + } else if (property == plane->ctm_property) {
> + ret = drm_atomic_replace_property_blob_from_id(dev,
> + >ctm,
> + val,
> + sizeof(struct
> drm_color_ctm), -1,
> + );
> + state->color_mgmt_changed |= replaced;
> + return ret;
>} else if (plane->funcs->atomic_set_property) {
>return plane->funcs->atomic_set_property(plane,
> state,
>property, val);
> @@ -988,6 +996,8 @@ static int drm_atomic_plane_set_property(struct
> drm_plane *plane,
>} else if (property == plane->degamma_lut_property) {
>*val = (state->degamma_lut) ?
>state->degamma_lut->base.id : 0;
> + } else if (property == plane->ctm_property) {
> + *val = (state->ctm) ? state->ctm->base.id : 0;
>} else if (plane->funcs->atomic_get_property) {
>return plane->funcs->atomic_get_property(plane,
> state, property, val);
>} else {
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 67c5b51..866181f 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -3616,6 +3616,9 @@ void
> __drm_atomic_helper_plane_duplicate_state(struct drm_plane *plane,
>
>if (state->degamma_lut)
>drm_property_blob_get(state->degamma_lut);
> + if (state->ctm)
> + drm_property_blob_get(state->ctm);
> +
>state->color_mgmt_changed = false;
> }
> EXPORT_SYMBOL(__drm_atomic_helper_plane_duplicate_state);
> @@ -3663,6 +3666,7 @@ void
> __drm_atomic_helper_plane_destroy_state(struct drm_plane_state
> *state)
>drm_crtc_commit_put(state->commit);
>
>drm_property_blob_put(state->degamma_lut);
> + drm_property_blob_put(state->ctm);
> }
> EXPORT_SYMBOL(__drm_atomic_helper_plane_destroy_state);
>
> diff --git a/drivers/gpu/drm/drm_plane.c
> b/drivers/gpu/drm/drm_plane.c
> index 03e0560..97520b1 100644
> --- a/drivers/gpu/drm/drm_plane.c
> +++ b/drivers/gpu/drm/drm_plane.c
> @@ -489,6 +489,11 @@ int drm_mode_plane_set_obj_prop(struct drm_plane
> *plane,
> *
> * degamma_lut_size_property:
> *Range Property to indicate size of the plane degamma LUT.
> + *
> + * ctm_property:
> + *Blob property which allows a userspace to provide CTM
> coefficients
> + *to do color space conversion or any other enhancement by
> doing a
> + *matrix multiplication using the h/w CTM processing engine
> */
> int drm_plane_color_create_prop(struct drm_device *dev,
>struct drm_plane *plane)
> @@ -509,6 +514,13 @@ int drm_plane_color_create_prop(struct
> drm_device *dev,
>return -ENOMEM;
>plane->degamma_lut_size_property = prop;
>
> + prop = drm_property_create(dev,
> + DRM_MODE_PROP_BLOB,
> + "PLANE_CTM", 0);
> + if (!prop)
> + return -ENOMEM;
> + plane->ctm_property = prop;
> +
>return 0;
> }
> EXPORT_SYMBOL(drm_plane_color_create_prop);
> diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h
> index 28357ac..5143277 100644
> --- a/include/drm/drm_plane.h
> +++
Re: [Mesa-dev] [PATCH libdrm] Add basic CONTRIBUTING file
On Wed, Aug 22, 2018 at 1:08 PM, Eric Engestrom
wrote:
> On Wednesday, 2018-08-22 12:51:39 +0200, Daniel Vetter wrote:
>> I picked up a bunch of the pieces from wayland's version:
>>
>> https://gitlab.freedesktop.org/wayland/wayland/blob/master/CONTRIBUTING.md
>>
>> The weston one is fairly similar. Then I rather massively trimmed it
>> down since in reality libdrm is a bit a dumping ground with very few
>> real rules. The commit rights and CoC sections I've copied verbatim
>> from igt respectively drm-misc. Weston/Wayland only differ in their
>> pick of how many patches you need (10 instead of 5). I think for
>> libdrm this is supremely relevant, since most everyone will get their
>> commit rights by contributing already to the kernel or mesa and having
>> commit rights there already.
>>
>> Anyway, I figured this is good to get the rules documented, even if
>> there's mostly not many rules.
>>
>> Note: This references maintainers in a MAINTAINERS file, which needs
>> to be created first.
>>
>> Note: With the gitlab migration the entire commit rights process is
>> still a bit up in the air. But gitlab commit rights and roles are
>> hierarchical, so we can do libdrm-only maintainer/commiter roles
>> ("Owner" and "Developer" in gitlab-speak). This should avoid
>> conflating libdrm roles with mesa roles, useful for those pushing to
>> libdrm as primarily kernel contributors.
>>
>> v2: Comments from Emil:
>> - Recommend subject prefix.
>> - Fix copypaste fumbles, this isn't igt/wayland ...
>>
>> v3: Comments from Marek:
>> - libdrm moved to mesa, update the document. Atm the entire account
>> request situation is entirely not clear for gitlab and mesa
>> projects, so that's a bit up in the air. Also, should probably send
>> an announcement to dri-devel@, which didn't happen.
>> - amd folks don't submit their patches to dri-devel, document that.
>> Probably applies to other drivers too.
>>
>> v4: Comments from Rob:
>> - Also include kernel/userspace in the commit counts criteria, due to
>> libdrm's special role as a glue library.
>>
>> v5: Summarize the irc discussion on gitlab roles in the commit message
>> a bit.
>>
>> v6: Some grammer stuff from Eric.
>>
>> Cc: Emil Velikov
>> Cc: Marek Olšák
>> Cc: Rob Clark
>> Cc: Eric Engestrom
>> Reviewed-by: Rob Clark (v4)
>> Reviewed-by: Eric Engestrom (v6)
>> Acked-by: Emil Velikov (v6)
>> Acked-by: Marek Olšák (v5)
>> References:
>> https://gitlab.freedesktop.org/wayland/weston/blob/master/CONTRIBUTING.md
>> References:
>> https://01.org/linuxgraphics/gfx-docs/maintainer-tools/drm-misc.html#commit-rights
>> References:
>> https://cgit.freedesktop.org/drm/igt-gpu-tools/tree/CONTRIBUTING#n54
>> Signed-off-by: Daniel Vetter
>> ---
>> CONTRIBUTING | 105 +++
>> 1 file changed, 105 insertions(+)
>> create mode 100644 CONTRIBUTING
>>
>> diff --git a/CONTRIBUTING b/CONTRIBUTING
>> new file mode 100644
>> index ..6cd09dd069bb
>> --- /dev/null
>> +++ b/CONTRIBUTING
>> @@ -0,0 +1,105 @@
>> +Contributing to libdrm
>> +==
>> +
>> +Submitting Patches
>> +--
>> +
>> +Patches should be sent to dri-devel@lists.freedesktop.org, using git
>> +send-email. For patches only touching driver specific code one of the driver
>> +mailing lists (like amd-...@lists.freedesktop.org) is also appropriate. See
>> git
>> +documentation for help:
>> +
>> +http://git-scm.com/documentation
>
> Actually, just thought about something we could add here:
>
> "
> You can set the default address by running:
> $ git config --local sendemail.to dri-devel@lists.freedesktop.org
>
> You can still override it when sending your patch by passing `--to`:
> $ git send-email -1 --to amd-...@lists.freedesktop.org
Uh, this sounds dangerous. We already have plenty fun when people
forget --suppress-cc=all when sending around internal patches. And
then it's usually just individuals, not lists.
This is practically begging for leaks.
> "
>
>> +
>> +Since dri-devel is a very busy mailing list please use
>> --subject-prefix="PATCH
>> +libdrm" to make it easier to find libdrm patches. This is best done by
>> running
>> +
>> +git config format.subjectprefix "PATCH libdrm"
>
> I would also recommend adding `--local` here to avoid people
> accidentally running this outside their repo and setting it globally.
Good idea, will fix.
-Daniel
>
>> +
>> +The first line of a commit message should contain a prefix indicating what
>> part
>> +is affected by the patch followed by one sentence that describes the
>> change. For
>> +examples:
>> +
>> +amdgpu: Use uint32_t i in amdgpu_find_bo_by_cpu_mapping
>> +
>> +The body of the commit message should describe what the patch changes and
>> why,
>> +and also note any particular side effects. For a recommended reading on
>> +writing commit messages, see:
>> +
>> +http://who-t.blogspot.de/2009/12/on-commit-messages.html
>> +
>> +Your patches should also
Re: [Mesa-dev] [PATCH libdrm] Add basic CONTRIBUTING file
On Wed, Aug 22, 2018 at 1:07 PM, Daniel Vetter wrote: > On Wed, Aug 22, 2018 at 12:55 PM, Daniel Stone wrote: >> On Wed, 22 Aug 2018 at 11:51, Daniel Vetter wrote: >>> +See the gitlab project owners for contact details of the libdrm >>> maintainers. >> >> Think this should be 'See MAINTAINERS' ... ? > > Hm right. Originally it was, but then I got a bit confused with how > this should work with gitlab. Having explicit MAINTAINERS is probably > good still. Will fix. On 2nd thought 2 seconds later: Won't fix, since we don't yet have the MAINTAINERS file. Atm the gitlab owners list is about the best thing. Once we have MAINTAINERS (I think Emil volunteered to find volunteers) we can adjust this. -Daniel > >> The rest looks good to me, though I would encourage linking to >> Patchwork so people can find patches from others, as well as making >> sure their own patch hasn't disappeared into the void. >> >> Is there a document somewhere that describes how to use Patchwork & >> git-pw you could link to? > > There's no libdrm pw afaik. It's terribly lossy I think and spread all > over the place, e.g. driver stuff tends to only show up on driver > lists. Given that I'm just trying to describe status quo I don't think > it makes sense to point at patchwork. > -Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Mesa-dev] [PATCH libdrm] Add basic CONTRIBUTING file
On Wednesday, 2018-08-22 12:51:39 +0200, Daniel Vetter wrote:
> I picked up a bunch of the pieces from wayland's version:
>
> https://gitlab.freedesktop.org/wayland/wayland/blob/master/CONTRIBUTING.md
>
> The weston one is fairly similar. Then I rather massively trimmed it
> down since in reality libdrm is a bit a dumping ground with very few
> real rules. The commit rights and CoC sections I've copied verbatim
> from igt respectively drm-misc. Weston/Wayland only differ in their
> pick of how many patches you need (10 instead of 5). I think for
> libdrm this is supremely relevant, since most everyone will get their
> commit rights by contributing already to the kernel or mesa and having
> commit rights there already.
>
> Anyway, I figured this is good to get the rules documented, even if
> there's mostly not many rules.
>
> Note: This references maintainers in a MAINTAINERS file, which needs
> to be created first.
>
> Note: With the gitlab migration the entire commit rights process is
> still a bit up in the air. But gitlab commit rights and roles are
> hierarchical, so we can do libdrm-only maintainer/commiter roles
> ("Owner" and "Developer" in gitlab-speak). This should avoid
> conflating libdrm roles with mesa roles, useful for those pushing to
> libdrm as primarily kernel contributors.
>
> v2: Comments from Emil:
> - Recommend subject prefix.
> - Fix copypaste fumbles, this isn't igt/wayland ...
>
> v3: Comments from Marek:
> - libdrm moved to mesa, update the document. Atm the entire account
> request situation is entirely not clear for gitlab and mesa
> projects, so that's a bit up in the air. Also, should probably send
> an announcement to dri-devel@, which didn't happen.
> - amd folks don't submit their patches to dri-devel, document that.
> Probably applies to other drivers too.
>
> v4: Comments from Rob:
> - Also include kernel/userspace in the commit counts criteria, due to
> libdrm's special role as a glue library.
>
> v5: Summarize the irc discussion on gitlab roles in the commit message
> a bit.
>
> v6: Some grammer stuff from Eric.
>
> Cc: Emil Velikov
> Cc: Marek Olšák
> Cc: Rob Clark
> Cc: Eric Engestrom
> Reviewed-by: Rob Clark (v4)
> Reviewed-by: Eric Engestrom (v6)
> Acked-by: Emil Velikov (v6)
> Acked-by: Marek Olšák (v5)
> References:
> https://gitlab.freedesktop.org/wayland/weston/blob/master/CONTRIBUTING.md
> References:
> https://01.org/linuxgraphics/gfx-docs/maintainer-tools/drm-misc.html#commit-rights
> References:
> https://cgit.freedesktop.org/drm/igt-gpu-tools/tree/CONTRIBUTING#n54
> Signed-off-by: Daniel Vetter
> ---
> CONTRIBUTING | 105 +++
> 1 file changed, 105 insertions(+)
> create mode 100644 CONTRIBUTING
>
> diff --git a/CONTRIBUTING b/CONTRIBUTING
> new file mode 100644
> index ..6cd09dd069bb
> --- /dev/null
> +++ b/CONTRIBUTING
> @@ -0,0 +1,105 @@
> +Contributing to libdrm
> +==
> +
> +Submitting Patches
> +--
> +
> +Patches should be sent to dri-devel@lists.freedesktop.org, using git
> +send-email. For patches only touching driver specific code one of the driver
> +mailing lists (like amd-...@lists.freedesktop.org) is also appropriate. See
> git
> +documentation for help:
> +
> +http://git-scm.com/documentation
Actually, just thought about something we could add here:
"
You can set the default address by running:
$ git config --local sendemail.to dri-devel@lists.freedesktop.org
You can still override it when sending your patch by passing `--to`:
$ git send-email -1 --to amd-...@lists.freedesktop.org
"
> +
> +Since dri-devel is a very busy mailing list please use
> --subject-prefix="PATCH
> +libdrm" to make it easier to find libdrm patches. This is best done by
> running
> +
> +git config format.subjectprefix "PATCH libdrm"
I would also recommend adding `--local` here to avoid people
accidentally running this outside their repo and setting it globally.
> +
> +The first line of a commit message should contain a prefix indicating what
> part
> +is affected by the patch followed by one sentence that describes the change.
> For
> +examples:
> +
> +amdgpu: Use uint32_t i in amdgpu_find_bo_by_cpu_mapping
> +
> +The body of the commit message should describe what the patch changes and
> why,
> +and also note any particular side effects. For a recommended reading on
> +writing commit messages, see:
> +
> +http://who-t.blogspot.de/2009/12/on-commit-messages.html
> +
> +Your patches should also include a Signed-off-by line with your name and
> email
> +address. If you're not the patch's original author, you should also gather
> +S-o-b's by them (and/or whomever gave the patch to you.) The significance of
> +this is that it certifies that you created the patch, that it was created
> under
> +an appropriate open source license, or provided to you under those terms.
> This
> +lets us indicate a chain of responsibility
Re: [Mesa-dev] [PATCH libdrm] Add basic CONTRIBUTING file
On Wed, Aug 22, 2018 at 12:55 PM, Daniel Stone wrote: > On Wed, 22 Aug 2018 at 11:51, Daniel Vetter wrote: >> +See the gitlab project owners for contact details of the libdrm maintainers. > > Think this should be 'See MAINTAINERS' ... ? Hm right. Originally it was, but then I got a bit confused with how this should work with gitlab. Having explicit MAINTAINERS is probably good still. Will fix. > The rest looks good to me, though I would encourage linking to > Patchwork so people can find patches from others, as well as making > sure their own patch hasn't disappeared into the void. > > Is there a document somewhere that describes how to use Patchwork & > git-pw you could link to? There's no libdrm pw afaik. It's terribly lossy I think and spread all over the place, e.g. driver stuff tends to only show up on driver lists. Given that I'm just trying to describe status quo I don't think it makes sense to point at patchwork. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
