[Bug 101714] Complete System Freeze (displaycore staging 4.11)
https://bugs.freedesktop.org/show_bug.cgi?id=101714 Matt changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Matt --- this has been resolved in later iterations of DC -- 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
[v4] drm: Add DPCD definitions for DP 1.4 FEC feature
Forward Error Correction is supported on DP 1.4. This patch adds corresponding DPCD register definitions. v2: Add dri-devel mailing list to the CC list(Jani) v3: Change names, add missing masks (Manasi) v4: Add missing shifts to mask (Manasi) Cc: dri-devel@lists.freedesktop.org Cc: Ville Syrjala Cc: Jani Nikula Cc: Manasi Navare Signed-off-by: Anusha Srivatsa Reviewed-by: Manasi Navare --- include/drm/drm_dp_helper.h | 30 ++ 1 file changed, 30 insertions(+) diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h index da58a42..592e371 100644 --- a/include/drm/drm_dp_helper.h +++ b/include/drm/drm_dp_helper.h @@ -284,6 +284,36 @@ # define DP_DSC_BITS_PER_PIXEL_1_2 0x3 # define DP_DSC_BITS_PER_PIXEL_10x4 +/* DP Forward error Correction Registers */ +#define DP_FEC_CAPABILITY 0x090 +# define DP_FEC_CAPABLE(1 << 0) +# define DP_FEC_UNCORR_BLK_ERROR_COUNT_CAP (1 << 1) +# define DP_FEC_CORR_BLK_ERROR_COUNT_CAP(1 << 2) +# define DP_FEC_BIT_ERROR_COUNT_CAP(1 << 3) + +#define DP_FEC_CONFIGURATION 0x120 +# define DP_FEC_READY (1 << 0) +# define DP_FEC_ERR_COUNT_DIS (0 << 1) +# define DP_FEC_UNCORR_BLK_ERROR_COUNT (1 << 1) +# define DP_FEC_CORR_BLK_ERROR_COUNT (2 << 1) +# define DP_FEC_BIT_ERROR_COUNT(3 << 1) +# define DP_FEC_ERR_COUNT_SEL_MASK (0xff << 4) +# define DP_FEC_LANE_0_SELECT (0 << 4) +# define DP_FEC_LANE_1_SELECT (1 << 4) +# define DP_FEC_LANE_2_SELECT (2 << 4) +# define DP_FEC_LANE_3_SELECT (3 << 4) + +#define DP_FEC_STATUS 0x280 +# define DP_FEC_DECODE_EN_DETECTED (1 << 0) +# define DP_FEC_DECODE_DIS_DETECTED(1 << 1) + +#define DP_FEC_ERROR_COUNT_LSB 0x0281 + +#define DP_FEC_ERROR_COUNT_MSB 0x0282 +# define DP_FEC_ERROR_COUNT_MASK 0x7F +# define DP_FEC_ERR_COUNT_SHIFT8 +# define DP_FEC_ERR_COUNT_VALID(1 << 7) + #define DP_PSR_SUPPORT 0x070 /* XXX 1.2? */ # define DP_PSR_IS_SUPPORTED1 # define DP_PSR2_IS_SUPPORTED 2 /* eDP 1.4 */ -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Add DPCD definitions for DP 1.4 FEC feature
On Fri, Dec 22, 2017 at 02:02:50PM -0800, Anusha Srivatsa wrote: > Forward Error Correction is supported on DP 1.4. > This patch adds corresponding DPCD register definitions. > > v2: Add dri-devel mailing list to the CC list(Jani) > > v3: Change names, add missing masks (Manasi) > > Cc: dri-devel@lists.freedesktop.org > Cc: Ville Syrjala > Cc: Jani Nikula > Cc: Manasi Navare > Signed-off-by: Anusha Srivatsa > --- > include/drm/drm_dp_helper.h | 30 ++ > 1 file changed, 30 insertions(+) > > diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h > index da58a42..4f75034 100644 > --- a/include/drm/drm_dp_helper.h > +++ b/include/drm/drm_dp_helper.h > @@ -284,6 +284,36 @@ > # define DP_DSC_BITS_PER_PIXEL_1_2 0x3 > # define DP_DSC_BITS_PER_PIXEL_10x4 > > +/* DP Forward error Correction Registers */ > +#define DP_FEC_CAPABILITY0x090 > +# define DP_FEC_CAPABLE (1 << 0) > +# define DP_FEC_UNCORR_BLK_ERROR_COUNT_CAP (1 << 1) > +# define DP_FEC_CORR_BLK_ERROR_COUNT_CAP(1 << 2) > +# define DP_FEC_BIT_ERROR_COUNT_CAP (1 << 3) > + > +#define DP_FEC_CONFIGURATION 0x120 > +# define DP_FEC_READY(1 << 0) > +# define DP_FEC_ERR_COUNT_DIS(0 << 1) > +# define DP_FEC_UNCORR_BLK_ERROR_COUNT (1 << 1) > +# define DP_FEC_CORR_BLK_ERROR_COUNT (2 << 1) > +# define DP_FEC_BIT_ERROR_COUNT (3 << 1) > +# define DP_FEC_ERR_COUNT_SEL_MASK (0xFF) This mask should be with a proper shift to obtain only the ERR_COUNT_SEL bits. It should be (0xff << 4). See all other mask defines. After that change, Reviewed-by: Manasi Navare Manasi > +# define DP_FEC_LANE_0_SELECT(0 << 4) > +# define DP_FEC_LANE_1_SELECT(1 << 4) > +# define DP_FEC_LANE_2_SELECT(2 << 4) > +# define DP_FEC_LANE_3_SELECT(3 << 4) > + > +#define DP_FEC_STATUS0x280 > +# define DP_FEC_DECODE_EN_DETECTED (1 << 0) > +# define DP_FEC_DECODE_DIS_DETECTED (1 << 1) > + > +#define DP_FEC_ERROR_COUNT_LSB 0x0281 > + > +#define DP_FEC_ERROR_COUNT_MSB 0x0282 > +# define DP_FEC_ERROR_COUNT_MASK 0x7F > +# define DP_FEC_ERR_COUNT_SHIFT 8 > +# define DP_FEC_ERR_COUNT_VALID (1 << 7) > + > #define DP_PSR_SUPPORT 0x070 /* XXX 1.2? */ > # define DP_PSR_IS_SUPPORTED1 > # define DP_PSR2_IS_SUPPORTED2 /* eDP 1.4 */ > -- > 2.7.4 > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] drm-intel-next
Hi Dave, This is our last round for 4.16. Initially I was planning to send next week, but I realized that I will be also out on Wednesday. We also already received GVT pull today and all CI rounds after that, and with all changes below, are running well. So here it goes drm-intel-next-2017-12-22: - Allow internal page allocation to fail (Chris) - More improvements on logs, dumps, and trace (Chris, Michal) - Coffee Lake important fix for stolen memory (Lucas) - Continue to make GPU reset more robust as well improving selftest coverage for it (Chris) - Unifying debugfs return codes (Michal) - Using existing helper for testing obj pages (Matthew) - Organize and improve gem_request tracepoints (Lionel) - Protect DDI port to DPLL map from theoretical race (Rodrigo) - ... and consequently fixing the indentation on this DDI clk selection function (Chris) - ... and consequently properly serializing non-blocking modesets (Ville) - Add support for horizontal plane flipping on Cannonlake (Joonas) - Two Cannonlake Workarounds for better stability (Rafael) - Fix mess around PSR registers (DK) - More Coffee Lake PCI IDs (Rodrigo) - Remove CSS modifiers on pipe C of Geminilake (Krisman) - Disable all planes for load detection (Ville) - Reorg on i915 display headers (Michal) - Avoid enabling movntdqa optimization on hypervisor guest (Changbin) GVT: - more mmio switch optimization (Weinan) - cleanup i915_reg_t vs. offset usage (Zhenyu) - move write protect handler out of mmio handler (Zhenyu) Happy Holidays! Thanks, Rodrigo. The following changes since commit ee5b5bf351ec8cd8f11c631cb76b30f602e866ee: drm/i915: Update DRIVER_DATE to 20171214 (2017-12-14 12:10:02 -0800) are available in the git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-2017-12-22 for you to fetch changes up to cfe4982ca488016d697cf0769ae70c9a78060c0d: drm/i915: Update DRIVER_DATE to 20171222 (2017-12-22 11:41:50 -0800) - Allow internal page allocation to fail (Chris) - More improvements on logs, dumps, and trace (Chris, Michal) - Coffee Lake important fix for stolen memory (Lucas) - Continue to make GPU reset more robust as well improving selftest coverage for it (Chris) - Unifying debugfs return codes (Michal) - Using existing helper for testing obj pages (Matthew) - Organize and improve gem_request tracepoints (Lionel) - Protect DDI port to DPLL map from theoretical race (Rodrigo) - ... and consequently fixing the indentation on this DDI clk selection function (Chris) - ... and consequently properly serializing non-blocking modesets (Ville) - Add support for horizontal plane flipping on Cannonlake (Joonas) - Two Cannonlake Workarounds for better stability (Rafael) - Fix mess around PSR registers (DK) - More Coffee Lake PCI IDs (Rodrigo) - Remove CSS modifiers on pipe C of Geminilake (Krisman) - Disable all planes for load detection (Ville) - Reorg on i915 display headers (Michal) - Avoid enabling movntdqa optimization on hypervisor guest (Changbin) GVT: - more mmio switch optimization (Weinan) - cleanup i915_reg_t vs. offset usage (Zhenyu) - move write protect handler out of mmio handler (Zhenyu) Changbin Du (1): drm/i915: Do not enable movntdqa optimization in hypervisor guest Chris Wilson (17): drm/i915: Allow internal page allocations to fail drm/i915/lpe: Remove double-encapsulation of info string drm/i915: Skip an engine reset if it recovered before our preparations drm/i915: Restore the kernel context after a GPU reset on an idle engine drm/i915: Re-enable GGTT earlier after GPU reset drm/i915: Show IPEIR and IPEHR in the engine dump drm/i915/selftests: Fix up igt_reset_engine drm/i915: Add a strong mb to resetting the has-CS-interrupt bit drm/i915: Fix indentation for intel_ddi_clk_select drm/i915: Show if we consider the engine is idle in the GPU error state drm/i915: Remove pointer indirection for hangcheck_state local drm/i915: Avoid context dereference inside execlists_submission_tasklet drm/i915: Tidy up GEM_TRACE around execlists drm/i915: Show FBC worker status in debugfs drm/i915/execlists: Show preemption progress in GEM_TRACE drm/i915: Assert that the request is on the execution queue before being removed drm/i915: Show HWSP in intel_engine_dump() Dhinakaran Pandiyan (1): drm/i915/psr: Fix register name mess up. Gabriel Krisman Bertazi (1): i915: Reject CCS modifiers for pipe C on Geminilake Joonas Lahtinen (1): drm/i915/cnl: Add support for horizontal plane flipping Lionel Landwerlin (2): drm/i915: reorder field in gem_request tracepoints drm/i915/trace: add hw_id to gem requests trace points Lucas De Marchi (1): x86/gpu: add CFL to early quirks Matthew Auld (1): drm/i915: prefer
RE: drm/ast: Linux 4.14 AST DRM driver might not load gamma table [patch proposed]
Spoke too soon. Original patch worked better (adding call to DPMS ON event in commit call-back. Disregard the latest I sent. Apologies. > -Original Message- > From: Carroll, Lewis > Sent: Thursday, December 21, 2017 3:58 PM > To: dri-devel@lists.freedesktop.org > Cc: Wentland, Harry ; 'Daniel Vetter' > ; Daenzer, Michel > Subject: RE: drm/ast: Linux 4.14 AST DRM driver might not load gamma table > [patch proposed] > > > -Original Message- > > From: daniel.vet...@ffwll.ch [mailto:daniel.vet...@ffwll.ch] On Behalf Of > > Daniel Vetter > > Sent: Thursday, December 21, 2017 3:31 PM > > To: Carroll, Lewis ; Daenzer, Michel > > > > Cc: Wentland, Harry ; dri- > > de...@lists.freedesktop.org > > Subject: Re: drm/ast: Linux 4.14 AST DRM driver might not load gamma > table > > [patch proposed] > > > > Fyi Michel, we've discussed similar issues for radeon/amdgpu on irc. > > > > On Thu, Dec 21, 2017 at 4:21 PM, Carroll, Lewis > > wrote: > > >> -Original Message- > > >> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel > > >> Vetter > > >> Sent: Thursday, December 21, 2017 5:07 AM > > >> To: Carroll, Lewis > > >> Cc: Wentland, Harry ; dri- > > >> de...@lists.freedesktop.org > > >> Subject: Re: drm/ast: Linux 4.14 AST DRM driver might not load gamma > > table > > >> [patch proposed] > > >> > > >> On Thu, Dec 21, 2017 at 12:00:39AM +, Carroll, Lewis wrote: > > >> > The discussion sounds similar as well - related to load_lut() not being > > called. > > >> > > > >> > Perhaps after the drm-next-4.14 merge, whatever call stack used to > > cause > > >> > load_lut to always get called is now gone. Even if > > FB_VISUAL_TRUECOLOR > > >> > doesn't support a clut, some hardware may still need a default gamma > > lut > > >> > loaded (appears to be the case with the AST2500). Perhaps checking > for > > >> > that profile and loading the default LUT prepared by > > >> > drm_mode_crtc_set_gamma_size when FB_VISUAL_TRUECOLOR...? > > >> > > >> Yeah drivers should load that somehow. Unfortunately I'm going on > > >> vacations now, so I'm not going to fix anything anytime soon. Might be > > >> good to ping Peter Rosin, he did all the fbdev emulation gamma > handling > > >> rework (which is the patch that removed the superflously-looking call to > > >> ->load_lut that some drivers relied on to have a consistent lut state). > > >> -Daniel > > > > > > Enjoy the holidays. > > > > > > Wonder if it would be better to just call load_lut after > > > drm_mode_crtc_set_gamma_size instead of adding a potentially > > > unnecessary DPMS ON event to the commit call-back as I did...? Or call > > > load_lut in the commit callback instead of the DPMS ON call...? > > > > > > The first approach (calling load_lut after set_gamma_size) also works on > > > two test systems. > > > > Yeah, I think that's the cleanest approach. The underlying issue is > > that a bunch of drivers are not making sure that on driver-load they > > have a consistent sw/hw state for the gamma ramp. As long as you had > > fbcon enabled the strange ->load_lut call (which isn't really > > necessary for drivers that got this right) papered over these issues. > > > > So a call to you driver's load_lut right affter > > drm_mode_crtc_set_gamma_size should fix this correctly. a-b:me if you > > submit that patch. > > Reworked patch attached, commit message changed to summarize the > Above discussion. > > > > > /me off for real now > > > > 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
[PATCH] drm: Add DPCD definitions for DP 1.4 FEC feature
Forward Error Correction is supported on DP 1.4. This patch adds corresponding DPCD register definitions. v2: Add dri-devel mailing list to the CC list(Jani) v3: Change names, add missing masks (Manasi) Cc: dri-devel@lists.freedesktop.org Cc: Ville Syrjala Cc: Jani Nikula Cc: Manasi Navare Signed-off-by: Anusha Srivatsa --- include/drm/drm_dp_helper.h | 30 ++ 1 file changed, 30 insertions(+) diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h index da58a42..4f75034 100644 --- a/include/drm/drm_dp_helper.h +++ b/include/drm/drm_dp_helper.h @@ -284,6 +284,36 @@ # define DP_DSC_BITS_PER_PIXEL_1_2 0x3 # define DP_DSC_BITS_PER_PIXEL_10x4 +/* DP Forward error Correction Registers */ +#define DP_FEC_CAPABILITY 0x090 +# define DP_FEC_CAPABLE(1 << 0) +# define DP_FEC_UNCORR_BLK_ERROR_COUNT_CAP (1 << 1) +# define DP_FEC_CORR_BLK_ERROR_COUNT_CAP(1 << 2) +# define DP_FEC_BIT_ERROR_COUNT_CAP(1 << 3) + +#define DP_FEC_CONFIGURATION 0x120 +# define DP_FEC_READY (1 << 0) +# define DP_FEC_ERR_COUNT_DIS (0 << 1) +# define DP_FEC_UNCORR_BLK_ERROR_COUNT (1 << 1) +# define DP_FEC_CORR_BLK_ERROR_COUNT (2 << 1) +# define DP_FEC_BIT_ERROR_COUNT(3 << 1) +# define DP_FEC_ERR_COUNT_SEL_MASK (0xFF) +# define DP_FEC_LANE_0_SELECT (0 << 4) +# define DP_FEC_LANE_1_SELECT (1 << 4) +# define DP_FEC_LANE_2_SELECT (2 << 4) +# define DP_FEC_LANE_3_SELECT (3 << 4) + +#define DP_FEC_STATUS 0x280 +# define DP_FEC_DECODE_EN_DETECTED (1 << 0) +# define DP_FEC_DECODE_DIS_DETECTED(1 << 1) + +#define DP_FEC_ERROR_COUNT_LSB 0x0281 + +#define DP_FEC_ERROR_COUNT_MSB 0x0282 +# define DP_FEC_ERROR_COUNT_MASK 0x7F +# define DP_FEC_ERR_COUNT_SHIFT8 +# define DP_FEC_ERR_COUNT_VALID(1 << 7) + #define DP_PSR_SUPPORT 0x070 /* XXX 1.2? */ # define DP_PSR_IS_SUPPORTED1 # define DP_PSR2_IS_SUPPORTED 2 /* eDP 1.4 */ -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/vc4: Add a mechanism to easily extend CL submissions
On Fri, 22 Dec 2017 12:53:36 -0800
Eric Anholt wrote:
> Boris Brezillon writes:
>
> > The number of attributes/objects you can pass to the
> > DRM_IOCTL_VC4_SUBMIT_CL ioctl is limited by the drm_vc4_submit_cl struct
> > size.
> >
> > Add a mechanism to easily pass extra attributes when submitting a CL to
> > the V3D engine.
> >
> > Signed-off-by: Boris Brezillon
> > ---
>
> > diff --git a/include/uapi/drm/vc4_drm.h b/include/uapi/drm/vc4_drm.h
> > index 52263b575bdc..ddcaa72da82a 100644
> > --- a/include/uapi/drm/vc4_drm.h
> > +++ b/include/uapi/drm/vc4_drm.h
> > @@ -70,6 +70,50 @@ struct drm_vc4_submit_rcl_surface {
> > };
> >
> > /**
> > + * @VC4_BIN_CL_CHUNK: binner CL chunk
> > + */
> > +enum {
> > + VC4_BIN_CL_CHUNK,
> > +};
> > +
> > +/**
> > + * struct drm_vc4_submit_cl_chunk - dummy chunk
> > + * @type: extension type
> > + * @pad: unused, should be set to zero
> > + *
> > + * Meant to be used for chunks that do not require extra parameters.
> > + */
> > +struct drm_vc4_submit_cl_dummy_chunk {
> > + __u32 type;
> > + __u32 pad[3];
> > +};
> > +
> > +/**
> > + * struct drm_vc4_submit_cl_bin_chunk - binner CL chunk
> > + *
> > + * @type: extention type, should be set to %VC4_BIN_CL_CHUNK
> > + * @size: size in bytes of the binner CL
> > + * @ptr: userspace pointer to the binner CL
> > + */
> > +struct drm_vc4_submit_cl_bin_chunk {
> > + __u32 type;
> > + __u32 size;
> > + __u64 ptr;
> > +};
> > +
> > +/**
> > + * union drm_vc4_submit_cl_chunk - CL chunk
> > + *
> > + * CL chunks allow us to easily extend the set of arguments one can pass
> > + * to the submit CL ioctl without having to add new ioctls/struct everytime
> > + * we run out of free fields in the drm_vc4_submit_cl struct.
> > + */
> > +union drm_vc4_submit_cl_chunk {
> > + struct drm_vc4_submit_cl_dummy_chunk dummy;
> > + struct drm_vc4_submit_cl_bin_chunk bin;
> > +};
> > +
> > +/**
> > * struct drm_vc4_submit_cl - ioctl argument for submitting commands to
> > the 3D
> > * engine.
> > *
> > @@ -83,14 +127,23 @@ struct drm_vc4_submit_rcl_surface {
> > * BO.
> > */
> > struct drm_vc4_submit_cl {
> > - /* Pointer to the binner command list.
> > -*
> > -* This is the first set of commands executed, which runs the
> > -* coordinate shader to determine where primitives land on the screen,
> > -* then writes out the state updates and draw calls necessary per tile
> > -* to the tile allocation BO.
> > -*/
> > - __u64 bin_cl;
> > + union {
> > + /* Pointer to the binner command list.
> > +*
> > +* This is the first set of commands executed, which runs the
> > +* coordinate shader to determine where primitives land on
> > +* the screen, then writes out the state updates and draw calls
> > +* necessary per tile to the tile allocation BO.
> > +*/
> > + __u64 bin_cl;
> > +
> > + /* Pointer to an array of CL chunks.
> > +*
> > +* This is now the preferred way of passing optional attributes
> > +* when submitting a job.
> > +*/
> > + __u64 cl_chunks;
> > + };
> >
> > /* Pointer to the shader records.
> > *
> > @@ -120,8 +173,14 @@ struct drm_vc4_submit_cl {
> > __u64 uniforms;
> > __u64 bo_handles;
> >
> > - /* Size in bytes of the binner command list. */
> > - __u32 bin_cl_size;
> > + union {
> > + /* Size in bytes of the binner command list. */
> > + __u32 bin_cl_size;
> > +
> > + /* Number of entries in the CL extension array. */
> > + __u32 num_cl_chunks;
> > + };
> > +
> > /* Size in bytes of the set of shader records. */
> > __u32 shader_rec_size;
> > /* Number of shader records.
> > @@ -167,6 +226,7 @@ struct drm_vc4_submit_cl {
> > #define VC4_SUBMIT_CL_FIXED_RCL_ORDER (1 << 1)
> > #define VC4_SUBMIT_CL_RCL_ORDER_INCREASING_X (1 << 2)
> > #define VC4_SUBMIT_CL_RCL_ORDER_INCREASING_Y (1 << 3)
> > +#define VC4_SUBMIT_CL_EXTENDED (1 << 4)
> > __u32 flags;
> >
> > /* Returned value of the seqno of this render job (for the
> > @@ -308,6 +368,7 @@ struct drm_vc4_get_hang_state {
> > #define DRM_VC4_PARAM_SUPPORTS_THREADED_FS 5
> > #define DRM_VC4_PARAM_SUPPORTS_FIXED_RCL_ORDER 6
> > #define DRM_VC4_PARAM_SUPPORTS_MADVISE 7
> > +#define DRM_VC4_PARAM_SUPPORTS_EXTENDED_CL 8
> >
> > struct drm_vc4_get_param {
> > __u32 param;
> > --
> > 2.11.0
>
> The vivante folks just extended their batch submit for performance
> monitors, and I was surprised to see that they actually extended their
> struct (without even a flag indicating that userspace was submitting an
> extended struct), which I thought we couldn't do. Apparently 6 years
> ago(!) the DRM core support was changed so that the driver always gets
> an ioctl arg of the size it
Re: [PATCH 1/2] drm/vc4: Add a mechanism to easily extend CL submissions
Boris Brezillon writes:
> The number of attributes/objects you can pass to the
> DRM_IOCTL_VC4_SUBMIT_CL ioctl is limited by the drm_vc4_submit_cl struct
> size.
>
> Add a mechanism to easily pass extra attributes when submitting a CL to
> the V3D engine.
>
> Signed-off-by: Boris Brezillon
> ---
> diff --git a/include/uapi/drm/vc4_drm.h b/include/uapi/drm/vc4_drm.h
> index 52263b575bdc..ddcaa72da82a 100644
> --- a/include/uapi/drm/vc4_drm.h
> +++ b/include/uapi/drm/vc4_drm.h
> @@ -70,6 +70,50 @@ struct drm_vc4_submit_rcl_surface {
> };
>
> /**
> + * @VC4_BIN_CL_CHUNK: binner CL chunk
> + */
> +enum {
> + VC4_BIN_CL_CHUNK,
> +};
> +
> +/**
> + * struct drm_vc4_submit_cl_chunk - dummy chunk
> + * @type: extension type
> + * @pad: unused, should be set to zero
> + *
> + * Meant to be used for chunks that do not require extra parameters.
> + */
> +struct drm_vc4_submit_cl_dummy_chunk {
> + __u32 type;
> + __u32 pad[3];
> +};
> +
> +/**
> + * struct drm_vc4_submit_cl_bin_chunk - binner CL chunk
> + *
> + * @type: extention type, should be set to %VC4_BIN_CL_CHUNK
> + * @size: size in bytes of the binner CL
> + * @ptr: userspace pointer to the binner CL
> + */
> +struct drm_vc4_submit_cl_bin_chunk {
> + __u32 type;
> + __u32 size;
> + __u64 ptr;
> +};
> +
> +/**
> + * union drm_vc4_submit_cl_chunk - CL chunk
> + *
> + * CL chunks allow us to easily extend the set of arguments one can pass
> + * to the submit CL ioctl without having to add new ioctls/struct everytime
> + * we run out of free fields in the drm_vc4_submit_cl struct.
> + */
> +union drm_vc4_submit_cl_chunk {
> + struct drm_vc4_submit_cl_dummy_chunk dummy;
> + struct drm_vc4_submit_cl_bin_chunk bin;
> +};
> +
> +/**
> * struct drm_vc4_submit_cl - ioctl argument for submitting commands to the
> 3D
> * engine.
> *
> @@ -83,14 +127,23 @@ struct drm_vc4_submit_rcl_surface {
> * BO.
> */
> struct drm_vc4_submit_cl {
> - /* Pointer to the binner command list.
> - *
> - * This is the first set of commands executed, which runs the
> - * coordinate shader to determine where primitives land on the screen,
> - * then writes out the state updates and draw calls necessary per tile
> - * to the tile allocation BO.
> - */
> - __u64 bin_cl;
> + union {
> + /* Pointer to the binner command list.
> + *
> + * This is the first set of commands executed, which runs the
> + * coordinate shader to determine where primitives land on
> + * the screen, then writes out the state updates and draw calls
> + * necessary per tile to the tile allocation BO.
> + */
> + __u64 bin_cl;
> +
> + /* Pointer to an array of CL chunks.
> + *
> + * This is now the preferred way of passing optional attributes
> + * when submitting a job.
> + */
> + __u64 cl_chunks;
> + };
>
> /* Pointer to the shader records.
>*
> @@ -120,8 +173,14 @@ struct drm_vc4_submit_cl {
> __u64 uniforms;
> __u64 bo_handles;
>
> - /* Size in bytes of the binner command list. */
> - __u32 bin_cl_size;
> + union {
> + /* Size in bytes of the binner command list. */
> + __u32 bin_cl_size;
> +
> + /* Number of entries in the CL extension array. */
> + __u32 num_cl_chunks;
> + };
> +
> /* Size in bytes of the set of shader records. */
> __u32 shader_rec_size;
> /* Number of shader records.
> @@ -167,6 +226,7 @@ struct drm_vc4_submit_cl {
> #define VC4_SUBMIT_CL_FIXED_RCL_ORDER(1 << 1)
> #define VC4_SUBMIT_CL_RCL_ORDER_INCREASING_X (1 << 2)
> #define VC4_SUBMIT_CL_RCL_ORDER_INCREASING_Y (1 << 3)
> +#define VC4_SUBMIT_CL_EXTENDED (1 << 4)
> __u32 flags;
>
> /* Returned value of the seqno of this render job (for the
> @@ -308,6 +368,7 @@ struct drm_vc4_get_hang_state {
> #define DRM_VC4_PARAM_SUPPORTS_THREADED_FS 5
> #define DRM_VC4_PARAM_SUPPORTS_FIXED_RCL_ORDER 6
> #define DRM_VC4_PARAM_SUPPORTS_MADVISE 7
> +#define DRM_VC4_PARAM_SUPPORTS_EXTENDED_CL 8
>
> struct drm_vc4_get_param {
> __u32 param;
> --
> 2.11.0
The vivante folks just extended their batch submit for performance
monitors, and I was surprised to see that they actually extended their
struct (without even a flag indicating that userspace was submitting an
extended struct), which I thought we couldn't do. Apparently 6 years
ago(!) the DRM core support was changed so that the driver always gets
an ioctl arg of the size it requested, and if userspace submitted
shorter then only the shorter amount is copied in/out and the rest is
zero-padded.
That means we could avoid this union stuff and even the whole idea of
chunks, and just have a single extra id for the perf
[PATCH 7/8] drm: Check that the plane supports the request format+modifier combo
From: Ville Syrjälä
Currently we only check that the plane supports the pixel format of the
fb we're about to feed to it. Extend it to check also the modifier, and
more specifically that the combination of the format and modifier is
supported.
Cc: dri-devel@lists.freedesktop.org
Cc: Ben Widawsky
Cc: Jason Ekstrand
Cc: Daniel Stone
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_atomic.c| 10 ++
drivers/gpu/drm/drm_crtc.c | 10 ++
drivers/gpu/drm/drm_crtc_internal.h | 4 ++--
drivers/gpu/drm/drm_plane.c | 33 ++---
4 files changed, 40 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index b76d49218cf1..6e5c3ea1e43b 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -882,12 +882,14 @@ static int drm_atomic_plane_check(struct drm_plane *plane,
}
/* Check whether this plane supports the fb pixel format. */
- ret = drm_plane_check_pixel_format(plane, state->fb->format->format);
+ ret = drm_plane_check_pixel_format(plane, state->fb->format->format,
+ state->fb->modifier);
if (ret) {
struct drm_format_name_buf format_name;
- DRM_DEBUG_ATOMIC("Invalid pixel format %s\n",
-drm_get_format_name(state->fb->format->format,
-&format_name));
+ DRM_DEBUG_ATOMIC("Invalid pixel format %s, modifier 0x%llx\n",
+drm_get_format_name(state->fb->format->format,
+&format_name),
+state->fb->modifier);
return ret;
}
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index f0556e654116..816c30a0f030 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -625,12 +625,14 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
*/
if (!crtc->primary->format_default) {
ret = drm_plane_check_pixel_format(crtc->primary,
- fb->format->format);
+ fb->format->format,
+ fb->modifier);
if (ret) {
struct drm_format_name_buf format_name;
- DRM_DEBUG_KMS("Invalid pixel format %s\n",
-
drm_get_format_name(fb->format->format,
-
&format_name));
+ DRM_DEBUG_KMS("Invalid pixel format %s,
modifier 0x%llx\n",
+
drm_get_format_name(fb->format->format,
+ &format_name),
+ fb->modifier);
goto out;
}
}
diff --git a/drivers/gpu/drm/drm_crtc_internal.h
b/drivers/gpu/drm/drm_crtc_internal.h
index af00f42ba269..860968a64ae7 100644
--- a/drivers/gpu/drm/drm_crtc_internal.h
+++ b/drivers/gpu/drm/drm_crtc_internal.h
@@ -196,8 +196,8 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
/* drm_plane.c */
int drm_plane_register_all(struct drm_device *dev);
void drm_plane_unregister_all(struct drm_device *dev);
-int drm_plane_check_pixel_format(const struct drm_plane *plane,
-u32 format);
+int drm_plane_check_pixel_format(struct drm_plane *plane,
+u32 format, u64 modifier);
/* drm_bridge.c */
void drm_bridge_detach(struct drm_bridge *bridge);
diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index 2c90519576a3..8ac19379fe99 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -545,16 +545,33 @@ int drm_mode_getplane(struct drm_device *dev, void *data,
return 0;
}
-int drm_plane_check_pixel_format(const struct drm_plane *plane, u32 format)
+int drm_plane_check_pixel_format(struct drm_plane *plane,
+u32 format, u64 modifier)
{
unsigned int i;
for (i = 0; i < plane->format_count; i++) {
if (format == plane->format_types[i])
- return 0;
+ break;
+ }
+ if (i == plane->format_count)
+ return -EINVAL;
+
+ if (!plane->modifier_count)
+ return 0;
+
+ for (i = 0; i < plane->modifier_count; i++) {
+ if (modifier == plane->modifiers[i])
+ break;
}
+ if (i == plane->modifier_count)
+ return -EINVAL;
- return -E
Re: [PATCH] drm/ttm: fix double lock on glob->lru_lock
NAK, ttm_bo_cleanup_refs() is dropping the lock.
Your backtrace is cause by an issue I've fixed this morning on
amd-staging-drm-next.
Regards,
Christian.
Am 22.12.2017 um 19:03 schrieb Colin King:
From: Colin Ian King
Lock glob->lru_lock is locked before the while loop and also
locked again at the end of the while loop; it appears that the
lock at the end of the while loop is a double lock that should
be removed. CoverityScan picked this up with the introduction
of the referenced commit inthe Fixes tag, however, it may have
existed before this. I've not been able to test this, but it
does look incorrect to me.
Detected by CoverityScan, CID#1268846 ("Double lock")
Fixes: 827ed2b06b05 ("drm/ttm: use try_lock in ttm_bo_delayed_delete again")
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/ttm/ttm_bo.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 60bb5c12b568..fb8d13a4bc94 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -595,7 +595,6 @@ static bool ttm_bo_delayed_delete(struct ttm_bo_device
*bdev, bool remove_all)
}
kref_put(&bo->list_kref, ttm_bo_release_list);
- spin_lock(&glob->lru_lock);
}
list_splice_tail(&removed, &bdev->ddestroy);
empty = list_empty(&bdev->ddestroy);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Mesa-dev] [ANNOUNCE] Wayland/Weston/Mesa HDR support (proof of concept)
On Thu, Dec 21, 2017 at 6:21 AM, Ville Syrjälä wrote: > Here's a quick proof of concept implementation of HDR support > for Wayland/Weston/Mesa. > > I'm not posting this as patches right now because I'm not sure > that would do much good given how rough this is. But here are > all the repos/branches: > git://github.com/vsyrjala/wayland.git hdr_poc > git://github.com/vsyrjala/wayland-protocols.git hdr_poc > git://github.com/vsyrjala/weston.git hdr_poc > git://github.com/vsyrjala/mesa.git hdr_poc > git://github.com/vsyrjala/linux.git hdr_poc > > The kernel HDR bits were partially done by Uma Shankar, the rest > I hacked together myself. Hi Ville, This looks really interesting, thanks for the heads up. Kristian > As far as Wayland protocol goes I'm adding three new > extensions (should probably just have one with several requests?): > - zwp_colorspace_v1 - Specify the primaries/whitepoint chromacities > and transfer function for a surface > - zwp_ycbcr_encoding_v1 - Specify the encoding for YCbCr surfaces > - zwp_hdr_metadata_v1 - Allow the client to pass HDR metadata to > the compositor > Note that I've not given any thought to how the compositor might > advertize its capabilities. > > I also hacked in a bunch of 10bpc+ YCbCr support to the protocol and > Weston so that I can actually get some HDR video onto the screen. > > On the Mesa side I've crudely implementated the following egl/vk > extesions: > - EXT_gl_colorspace_* > - EXT_surface_SMPTE2086_metadata > - EXT_surface_CTA861_3_metadata > (sidenote: these egl extension don't seem to match CTA-861.3 nicely >when it comes to the min/max luminance stuff) > - VK_EXT_hdr_metadata > > VK_EXT_hdr_metadata I plugged in for anv only, but the implementation > is in the common wayland wsi code. Note that I haven't actually tested > the vulkan stuff at all because I don't talk Vulkan (at least not yet). > > Also note that I've not connected up the HDR metadata pipeline > properly. The client can provide the metadata, but the compositor > doesn't actually pass it on to the display. For the time being the > HDR metadata that gets passed to the display is partially specified > in weston.ini and partially just hardocded (see > libweston/compositor-drm.c). > > The Weston implementation involves a bunch of shaders and matrices to > do the ycbcr->rgb, "degamma", csc for each surface, blend it all as > linear RGB into an fp16 fbo, and finally blit that out to the final > framebuffer while applying the ST2084 PQ transfer function in the > process. > > The reason for the fp16 fbo is that we store the full 1 nits of > linear RGB. That needs plenty of precisions in the low end so your > regular 10bpc fb doesn't seem to cut it. And also the display gamma LUT > doesn't have enough input precision for it either. Sadly there's no > fixed function hardware in the GPU to do the ST2084 PQ when blending. > When the output is not HDR I do skip the fp16 fbo step and use the > gamma LUT in the display engine instead. > > Another approach to the precisions problem might be to not store the > entire 1 nits of linear, and just cut off the super bright stuff > (your display can't show it anyway). But I've not really bothered to > figure out how low in nits we'd have to go here, probably too low. > Maybe blending as sRGB and the doing sRGB->PQ with the gamma LUT might > help a little bit? > > Ideally we would bypass this all for a single fullscreen HDR surface > and just pass the PQ encoded data directly through. But I've not > implemented that. In fact I even disable the buffer_age damage stuff > when using the fp16 fbo, so we'll recompose the entire screen every > time. Yeah, I'm lazy. > > Another thought that occurred to me was that it shouldn't be too hard > to make Weston do some tone mapping when there's a HDR client and no > HDR screen. To that end I included the ACES colorspaces in my > colorspace list, but I didn't actually look into plugging the ACES tone > mapping curve into the shaders. Might be a fun excercise, even though > the practical applications might be close to nil. Probably better to > not advertize HDR/wide gamuts when we can't actually output the stuff, > and instead let the client do its own tone mapping. > > OK, so what can you do with this? I've included a few test clients: > - simple-colorspace > Just a copy of simple-egl but it uses the egl extension to specify > the colorspace, and produces ST2084 PQ encoded data when asked > - simple-hdr-video > Uses ffmpeg to decode video into shm buffers, and sets the > colorspace/ycbcr encoding etc. appropriately. Ie. this one can > actually output HDR video > > Here's a weston.ini snippet that gets you outputting HDR: > [core] > gbm-format=xrgb2101010 > > [output] > name=HDMI-A-2 > colorspace=BT.2020 > gamma=ST2084 > max_sdr_nits=100 > > Hardware wise you'll need a HDR capable display obviously, and > you'll need an Intel Geminilake GPU. Older Intel platforms don't > support the HDR infoframe
[PATCH] drm/ttm: fix double lock on glob->lru_lock
From: Colin Ian King
Lock glob->lru_lock is locked before the while loop and also
locked again at the end of the while loop; it appears that the
lock at the end of the while loop is a double lock that should
be removed. CoverityScan picked this up with the introduction
of the referenced commit inthe Fixes tag, however, it may have
existed before this. I've not been able to test this, but it
does look incorrect to me.
Detected by CoverityScan, CID#1268846 ("Double lock")
Fixes: 827ed2b06b05 ("drm/ttm: use try_lock in ttm_bo_delayed_delete again")
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/ttm/ttm_bo.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 60bb5c12b568..fb8d13a4bc94 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -595,7 +595,6 @@ static bool ttm_bo_delayed_delete(struct ttm_bo_device
*bdev, bool remove_all)
}
kref_put(&bo->list_kref, ttm_bo_release_list);
- spin_lock(&glob->lru_lock);
}
list_splice_tail(&removed, &bdev->ddestroy);
empty = list_empty(&bdev->ddestroy);
--
2.14.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Initial release of AMD Open Source Driver for Vulkan
Hi
No I'm not using ICC however that section prevents you using Clang, it
basically says if not GCC then assumes Intel's compiler
Cheers
Mike
On Fri, 22 Dec 2017, 3:04 pm Mao, David, wrote:
> Hi Lothian,
> Thanks for testing out out driver!
> Officially we recommend you to stick to GCC5 for now, however, we do have
> a fix for the constexpr issue mentioned below that just didn’t make it to
> this first release.
> According to your diff, are you using ICC?
> Could you let us know the compiler version as well as your distro?
>
> Thanks.
> Best Regards,
> David
>
>
> On Dec 22, 2017, at 9:48 PM, Mike Lothian wrote:
>
> Congratulations on getting this out the door
>
> It didn't compile for me without these changes:
>
> In pal:
>
> diff --git a/src/util/math.cpp b/src/util/math.cpp
> index 46e9ede..3af4259 100644
> --- a/src/util/math.cpp
> +++ b/src/util/math.cpp
> @@ -54,7 +54,7 @@ static uint32 Float32ToFloatN(float f, const
> NBitFloatInfo& info);
> static float FloatNToFloat32(uint32 fBits, const NBitFloatInfo& info);
>
> // Initialize the descriptors for various N-bit floating point
> representations:
> -static constexpr NBitFloatInfo Float16Info =
> +static NBitFloatInfo Float16Info =
> {
> 16, // numBits
> 10, //
> numFracBits
> @@ -72,7 +72,7 @@ static constexpr NBitFloatInfo Float16Info =
> (23 - 10),//
> fracBitsDiff
> };
>
> -static constexpr NBitFloatInfo Float11Info =
> +static NBitFloatInfo Float11Info =
> {
> 11, // numBits
> 6,//
> numFracBits
> @@ -90,7 +90,7 @@ static constexpr NBitFloatInfo Float11Info =
> 23 - 6, //
> fracBitsDiff
> };
>
> -static constexpr NBitFloatInfo Float10Info =
> +static NBitFloatInfo Float10Info =
> {
> 10, // numBits
> 5,//
> numFracBits
>
> In xgl:
>
> diff --git a/icd/CMakeLists.txt b/icd/CMakeLists.txt
> index 4e4d669..5006184 100644
> --- a/icd/CMakeLists.txt
> +++ b/icd/CMakeLists.txt
> @@ -503,16 +503,16 @@ if (UNIX)
>
> target_link_libraries(xgl PRIVATE c stdc++ ${CMAKE_DL_LIBS} pthread)
>
> -if(NOT ICD_USE_GCC)
> -message(WARNING "Intel ICC untested in CMake.")
> -target_link_libraries(xgl PRIVATE -fabi-version=0 -static-intel)
> -endif()
> +#if(NOT ICD_USE_GCC)
> +#message(WARNING "Intel ICC untested in CMake.")
> +#target_link_libraries(xgl PRIVATE -fabi-version=0 -static-intel)
> +#endif()
>
> if(CMAKE_BUILD_TYPE_RELEASE)
> if("${CMAKE_CXX_COMPILER_ID}" STREQUAL "GNU")
> execute_process(COMMAND ${CMAKE_C_COMPILER} -dumpversion
> OUTPUT_VARIABLE GCC_VERSION)
> if (GCC_VERSION VERSION_GREATER 5.3 OR GCC_VERSION
> VERSION_EQUAL 5.3)
> -target_link_libraries(xgl PRIVATE -flto=4
> -fuse-linker-plugin -Wno-odr)
> +target_link_libraries(xgl PRIVATE -Wno-odr)
> message(WARNING "LTO enabled for Linking")
> endif()
> endif()
> @@ -530,17 +530,17 @@ if (UNIX)
>
> # CMAKE-TODO: What is whole-archive used for?
> #target_link_libraries(xgl -Wl,--whole-archive ${ICD_LIBS}
> -Wl,--no-whole-archive)
> -if(CMAKE_BUILD_TYPE_RELEASE)
> -execute_process(COMMAND ${CMAKE_C_COMPILER} -dumpversion
> OUTPUT_VARIABLE GCC_VERSION)
> -if (GCC_VERSION VERSION_GREATER 5.3 OR GCC_VERSION VERSION_EQUAL
> 5.3)
> -target_link_libraries(xgl PRIVATE -Wl,--whole-archive
> ${PROJECT_BINARY_DIR}/pal/src/libpal.a -Wl,--no-whole-archive)
> -target_link_libraries(xgl PUBLIC -Wl,--whole-archive
> ${PROJECT_BINARY_DIR}/pal/metrohash/libmetrohash.a -Wl,--no-whole-archive)
> -target_link_libraries(xgl PUBLIC -Wl,--whole-archive
> ${PROJECT_BINARY_DIR}/pal/gpuopen/libgpuopen.a -Wl,--no-whole-archive)
> -target_link_libraries(xgl PUBLIC -Wl,--whole-archive
> ${PROJECT_BINARY_DIR}/pal/vam/libvam.a -Wl,--no-whole-archive)
> -target_link_libraries(xgl PUBLIC -Wl,--whole-archive
> ${PROJECT_BINARY_DIR}/pal/addrlib/libaddrlib.a -Wl,--no-whole-archive)
> -target_link_libraries(xgl PUBLIC -Wl,--whole-archive
> ${PROJECT_BINARY_DIR}/pal/jemalloc/libjemalloc.a -Wl,--no-whole-archive)
> -endif()
> -endif()
> +#if(CMAKE_BUILD_TYPE_RELEASE)
> +#execute_process(COMMAND ${CMAKE_C_COMPILER} -dumpversion
> OUTPUT_VARIABLE GCC_VERSION)
> +#if (GCC_VERSION VERSION_GREATER 5.3 OR GCC_VERSION VERSION_EQUAL
> 5.3)
> +#target_link_libraries(xgl PRIVATE -Wl,--whole-archive
> ${PROJECT_BINARY_DIR}/pal/src/libpal.a -Wl,--no-whole-archive)
> +#
Re: [Bug 198123] Console is the wrong color at boot with radeon 6670
On 2017-12-19 11:48 AM, Michel Dänzer wrote:
> On 2017-12-18 02:50 PM, Peter Rosin wrote:
>> On 2017-12-18 12:37, Michel Dänzer wrote:
>>>
>>> Following up by e-mail, since I can't find Peter Rosin in the kernel
>>> bugzilla.
>>>
>>>
>>> On 2017-12-16 02:41 AM, bugzilla-dae...@bugzilla.kernel.org wrote:
https://bugzilla.kernel.org/show_bug.cgi?id=198123
--- Comment #8 from Deposite Pirate (dpir...@metalpunks.info) ---
Ok, I went through all the git bisect process. Here are the results:
[...]
b8e2b0199cc377617dc238f5106352c06dcd3fa2 is the first bad commit
commit b8e2b0199cc377617dc238f5106352c06dcd3fa2
Author: Peter Rosin
Date: Tue Jul 4 12:36:57 2017 +0200
drm/fb-helper: factor out pseudo-palette
The pseudo-palette has nothing to do with the crtc, so move it
out of the crtc loop and update the palette once, then break out
early.
Signed-off-by: Peter Rosin
Signed-off-by: Daniel Vetter
Link:
http://patchwork.freedesktop.org/patch/msgid/1499164632-5582-2-git-send-email-p...@axentia.se
:04 04 a8c2650554e199fee994ac63c2700c73ba2ecffe
7f72ed414efadd77ef1d718e7477475c4ba1127d M drivers
>>>
>>> My guess would be this is because fb_helper->funcs->gamma_set is no
>>> longer called from drm_fb_helper_setcmap in the FB_VISUAL_TRUECOLOR case
>>> (was previously called via setcolreg).
>>
>> No, that's not right, fb_helper->funcs->gamma_set() wasn't called for the
>> FB_VISUAL_TRUECOLOR case before the commit either.
>>
>> However, crtc_funcs->load_lut() was called, but that operation is now
>> gone in a later cleanup. However#2, that ->load_lut() did not use anything
>> that was provided in the call to drm_fb_helper_setcmap, since the load_lut
>> implementations generally didn't look at the pseudo_palette variable. So,
>> the now-missing ->load_lut() call probably just reloaded the clut?
>
> Makes sense.
"Deposite Pirate", do the attached (only compile tested) patches work?
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
From f683369b876b5198b0099d66ad83997455d9040f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Michel=20D=C3=A4nzer?=
Date: Fri, 22 Dec 2017 16:27:09 +0100
Subject: [PATCH 1/2] drm/radeon: Call radeon_crtc_load_lut from
radeon_crtc_init
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Cc: sta...@vger.kernel.org
Fixes: b8e2b0199cc3 "drm/fb-helper: factor out pseudo-palette"
Signed-off-by: Michel Dänzer
---
drivers/gpu/drm/radeon/radeon_display.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/radeon/radeon_display.c b/drivers/gpu/drm/radeon/radeon_display.c
index ddfe91efa61e..d403be4afd24 100644
--- a/drivers/gpu/drm/radeon/radeon_display.c
+++ b/drivers/gpu/drm/radeon/radeon_display.c
@@ -707,6 +707,8 @@ static void radeon_crtc_init(struct drm_device *dev, int index)
radeon_atombios_init_crtc(dev, radeon_crtc);
else
radeon_legacy_init_crtc(dev, radeon_crtc);
+
+ radeon_crtc_load_lut(&radeon_crtc->base);
}
static const char *encoder_names[38] = {
--
2.15.1
From e071d7293a30bf84677c15a30d91872b7439ce70 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Michel=20D=C3=A4nzer?=
Date: Fri, 22 Dec 2017 16:31:54 +0100
Subject: [PATCH 2/2] drm/radeon: Remove unused lut_r/g/b arrays
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Signed-off-by: Michel Dänzer
---
drivers/gpu/drm/radeon/radeon_display.c | 7 ---
drivers/gpu/drm/radeon/radeon_mode.h| 1 -
2 files changed, 8 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_display.c b/drivers/gpu/drm/radeon/radeon_display.c
index d403be4afd24..0519c6162381 100644
--- a/drivers/gpu/drm/radeon/radeon_display.c
+++ b/drivers/gpu/drm/radeon/radeon_display.c
@@ -668,7 +668,6 @@ static void radeon_crtc_init(struct drm_device *dev, int index)
{
struct radeon_device *rdev = dev->dev_private;
struct radeon_crtc *radeon_crtc;
- int i;
radeon_crtc = kzalloc(sizeof(struct radeon_crtc) + (RADEONFB_CONN_LIMIT * sizeof(struct drm_connector *)), GFP_KERNEL);
if (radeon_crtc == NULL)
@@ -697,12 +696,6 @@ static void radeon_crtc_init(struct drm_device *dev, int index)
radeon_crtc->mode_set.num_connectors = 0;
#endif
- for (i = 0; i < 256; i++) {
- radeon_crtc->lut_r[i] = i << 2;
- radeon_crtc->lut_g[i] = i << 2;
- radeon_crtc->lut_b[i] = i << 2;
- }
-
if (rdev->is_atom_bios && (ASIC_IS_AVIVO(rdev) || radeon_r4xx_atom))
radeon_atombios_init_crtc(dev, radeon_crtc);
else
diff --git a/drivers/gpu/drm/radeon/radeon_mode.h b/drivers/gpu/drm/radeon/radeon_mode.h
index ca0a7ed28c9b..9b1fe25f624a 100644
--- a/drivers/gpu/drm/radeon/radeon_mode.h
+++ b/drivers/gpu/drm/radeon/radeon_mode.h
@@ -328,7 +328,6 @@ enum radeon_flip_status {
struct radeon_crtc {
struct drm_c
[Bug 104371] [amdgpu] Kernel oops on shutdown: unable to handle kernel paging request at virtual address
https://bugs.freedesktop.org/show_bug.cgi?id=104371 Bug ID: 104371 Summary: [amdgpu] Kernel oops on shutdown: unable to handle kernel paging request at virtual address Product: DRI Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: ates.e...@gmail.com Created attachment 136367 --> https://bugs.freedesktop.org/attachment.cgi?id=136367&action=edit dmesg I have a notebook with AMD RX500 GPU, and the amdgpu kernel module in 4.13.16 linux kernel version sometimes causes hang at shutdown. I think the hang is more likely to happen the longer I've kept my laptop on, especially if I connect/disconnect external monitors. I can attach additional information as requested. So far I've blacklisted the amdgpu module and haven't encountered any hangs on shutdown. -- 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/blend: Account also the primary plane of the crtc for normalized_zpos
Hi, On 2017-12-22 12:12, Ville Syrjälä wrote: > On Fri, Dec 22, 2017 at 11:16:47AM +0200, Tomi Valkeinen wrote: >> On 21/12/17 17:12, Ville Syrjälä wrote: >> If the userspace knows this, then it knows which primary plane is for which crtc, right? And if it doesn't know this, then the userspace cannot associate any plane to any crtc (except what it configures itself). So... If using legacy modesetting (and non-universal planes), there's no problem, primary planes are fixed and at low zpos. If using atomic modesetting and universal planes, there's really no (default) association between planes and crtcs, and "primary plane" doesn't have much meaning. Is that correct? If so... Then I guess the atomic modesetting client essentially randomly picks which plane it uses as a "root plane" (if it even needs such), and which planes as overlay planes? If that's the case, then this patch doesn't quite fix the issue... >>> >>> I'm not sure anyone has really thought how userspace would/should assign >>> planes to crtcs. My only idea so far has been the crtc and their >>> preferred primary planes should be registered in the same order. But >>> someone should then also implement that same policy in userspace when >>> it's trying to figure out which plane to use. There are other >>> heuristics it should probably use, like preferring to pick a primary >>> plane for any fullscreen surface. >>> >>> I guess from functional point of view it shouldn't matter which plane >>> you pick as long as the plane's user visible capabilities are >>> sufficient. But there might be user invisible power saving features and >>> whatnot that only work with specific planes. So from that point of view >>> maybe the order in which the planes get registered is important. Or we >>> could maybe come up with some kind of plane usage hints in the uapi >>> which could help userspace decide? >> >> I was thinking about this, and... maybe there isn't even any problem (at >> least for OMAP). So lets say we set the default plane zpos to the plane >> index, and that the primary planes are reserved first (i.e. have lower >> zpos than overlay planes). >> >> We have three different cases: >> >> Legacy modesetting: No problems, primary plane is always at the bottom. >> If the userspace uses 2+ overlay planes, it can expect the zpos to be >> based on the plane id, or it can set the zpos. >> >> Atomic+Universal, the application uses one primary plane, and zero or >> more overlay planes: No problems here, the situation is the same as for >> legacy. >> >> Atomic+Universal, the application uses more than one primary plane, and >> zero or more overlay planes: in this case the app _has_ to manage zpos, >> because using two primary planes in a single screen, and expecting it to >> work by default, doesn't make sense. >> >> If the above "rules" are valid, then there's no need for this patch. >> >> But one question I don't have a good answer is that why would we want to >> normalize the zpos, instead of returning an error? If the above rules >> are valid, I think returning an error is better than normalizing and >> hiding the bad configuration. > > IIRC I argued against the normalization, but some people really > wanted it for whatever reason. OK, please ignore this series, I'll send a patch instead next year. - Péter Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Initial release of AMD Open Source Driver for Vulkan
Hi Lothian,
Thanks for testing out out driver!
Officially we recommend you to stick to GCC5 for now, however, we do have a fix
for the constexpr issue mentioned below that just didn’t make it to this first
release.
According to your diff, are you using ICC?
Could you let us know the compiler version as well as your distro?
Thanks.
Best Regards,
David
On Dec 22, 2017, at 9:48 PM, Mike Lothian
mailto:m...@fireburn.co.uk>> wrote:
Congratulations on getting this out the door
It didn't compile for me without these changes:
In pal:
diff --git a/src/util/math.cpp b/src/util/math.cpp
index 46e9ede..3af4259 100644
--- a/src/util/math.cpp
+++ b/src/util/math.cpp
@@ -54,7 +54,7 @@ static uint32 Float32ToFloatN(float f, const NBitFloatInfo&
info);
static float FloatNToFloat32(uint32 fBits, const NBitFloatInfo& info);
// Initialize the descriptors for various N-bit floating point representations:
-static constexpr NBitFloatInfo Float16Info =
+static NBitFloatInfo Float16Info =
{
16, // numBits
10, // numFracBits
@@ -72,7 +72,7 @@ static constexpr NBitFloatInfo Float16Info =
(23 - 10),// fracBitsDiff
};
-static constexpr NBitFloatInfo Float11Info =
+static NBitFloatInfo Float11Info =
{
11, // numBits
6,// numFracBits
@@ -90,7 +90,7 @@ static constexpr NBitFloatInfo Float11Info =
23 - 6, // fracBitsDiff
};
-static constexpr NBitFloatInfo Float10Info =
+static NBitFloatInfo Float10Info =
{
10, // numBits
5,// numFracBits
In xgl:
diff --git a/icd/CMakeLists.txt b/icd/CMakeLists.txt
index 4e4d669..5006184 100644
--- a/icd/CMakeLists.txt
+++ b/icd/CMakeLists.txt
@@ -503,16 +503,16 @@ if (UNIX)
target_link_libraries(xgl PRIVATE c stdc++ ${CMAKE_DL_LIBS} pthread)
-if(NOT ICD_USE_GCC)
-message(WARNING "Intel ICC untested in CMake.")
-target_link_libraries(xgl PRIVATE -fabi-version=0 -static-intel)
-endif()
+#if(NOT ICD_USE_GCC)
+#message(WARNING "Intel ICC untested in CMake.")
+#target_link_libraries(xgl PRIVATE -fabi-version=0 -static-intel)
+#endif()
if(CMAKE_BUILD_TYPE_RELEASE)
if("${CMAKE_CXX_COMPILER_ID}" STREQUAL "GNU")
execute_process(COMMAND ${CMAKE_C_COMPILER} -dumpversion
OUTPUT_VARIABLE GCC_VERSION)
if (GCC_VERSION VERSION_GREATER 5.3 OR GCC_VERSION VERSION_EQUAL
5.3)
-target_link_libraries(xgl PRIVATE -flto=4 -fuse-linker-plugin
-Wno-odr)
+target_link_libraries(xgl PRIVATE -Wno-odr)
message(WARNING "LTO enabled for Linking")
endif()
endif()
@@ -530,17 +530,17 @@ if (UNIX)
# CMAKE-TODO: What is whole-archive used for?
#target_link_libraries(xgl -Wl,--whole-archive ${ICD_LIBS}
-Wl,--no-whole-archive)
-if(CMAKE_BUILD_TYPE_RELEASE)
-execute_process(COMMAND ${CMAKE_C_COMPILER} -dumpversion
OUTPUT_VARIABLE GCC_VERSION)
-if (GCC_VERSION VERSION_GREATER 5.3 OR GCC_VERSION VERSION_EQUAL 5.3)
-target_link_libraries(xgl PRIVATE -Wl,--whole-archive
${PROJECT_BINARY_DIR}/pal/src/libpal.a -Wl,--no-whole-archive)
-target_link_libraries(xgl PUBLIC -Wl,--whole-archive
${PROJECT_BINARY_DIR}/pal/metrohash/libmetrohash.a -Wl,--no-whole-archive)
-target_link_libraries(xgl PUBLIC -Wl,--whole-archive
${PROJECT_BINARY_DIR}/pal/gpuopen/libgpuopen.a -Wl,--no-whole-archive)
-target_link_libraries(xgl PUBLIC -Wl,--whole-archive
${PROJECT_BINARY_DIR}/pal/vam/libvam.a -Wl,--no-whole-archive)
-target_link_libraries(xgl PUBLIC -Wl,--whole-archive
${PROJECT_BINARY_DIR}/pal/addrlib/libaddrlib.a -Wl,--no-whole-archive)
-target_link_libraries(xgl PUBLIC -Wl,--whole-archive
${PROJECT_BINARY_DIR}/pal/jemalloc/libjemalloc.a -Wl,--no-whole-archive)
-endif()
-endif()
+#if(CMAKE_BUILD_TYPE_RELEASE)
+#execute_process(COMMAND ${CMAKE_C_COMPILER} -dumpversion
OUTPUT_VARIABLE GCC_VERSION)
+#if (GCC_VERSION VERSION_GREATER 5.3 OR GCC_VERSION VERSION_EQUAL 5.3)
+#target_link_libraries(xgl PRIVATE -Wl,--whole-archive
${PROJECT_BINARY_DIR}/pal/src/libpal.a -Wl,--no-whole-archive)
+#target_link_libraries(xgl PUBLIC -Wl,--whole-archive
${PROJECT_BINARY_DIR}/pal/metrohash/libmetrohash.a -Wl,--no-whole-archive)
+#target_link_libraries(xgl PUBLIC -Wl,--whole-archive
${PROJECT_BINARY_DIR}/pal/gpuopen/libgpuopen.a -Wl,--no-whole-archive)
+#target_link_libraries(xgl PUBLIC -Wl,--whole-archive
${PROJECT_BINARY_DIR}/pal/vam/libvam.a -Wl
[Bug 104143] r600/sb: clobbers gl_Position -> gl_FragCoord
https://bugs.freedesktop.org/show_bug.cgi?id=104143 --- Comment #10 from Emil Velikov --- Gert, should we close this considering the patch (fix?) has landed? -- 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: Initial release of AMD Open Source Driver for Vulkan
Congratulations on getting this out the door
It didn't compile for me without these changes:
In pal:
diff --git a/src/util/math.cpp b/src/util/math.cpp
index 46e9ede..3af4259 100644
--- a/src/util/math.cpp
+++ b/src/util/math.cpp
@@ -54,7 +54,7 @@ static uint32 Float32ToFloatN(float f, const
NBitFloatInfo& info);
static float FloatNToFloat32(uint32 fBits, const NBitFloatInfo& info);
// Initialize the descriptors for various N-bit floating point
representations:
-static constexpr NBitFloatInfo Float16Info =
+static NBitFloatInfo Float16Info =
{
16, // numBits
10, //
numFracBits
@@ -72,7 +72,7 @@ static constexpr NBitFloatInfo Float16Info =
(23 - 10),//
fracBitsDiff
};
-static constexpr NBitFloatInfo Float11Info =
+static NBitFloatInfo Float11Info =
{
11, // numBits
6,//
numFracBits
@@ -90,7 +90,7 @@ static constexpr NBitFloatInfo Float11Info =
23 - 6, //
fracBitsDiff
};
-static constexpr NBitFloatInfo Float10Info =
+static NBitFloatInfo Float10Info =
{
10, // numBits
5,//
numFracBits
In xgl:
diff --git a/icd/CMakeLists.txt b/icd/CMakeLists.txt
index 4e4d669..5006184 100644
--- a/icd/CMakeLists.txt
+++ b/icd/CMakeLists.txt
@@ -503,16 +503,16 @@ if (UNIX)
target_link_libraries(xgl PRIVATE c stdc++ ${CMAKE_DL_LIBS} pthread)
-if(NOT ICD_USE_GCC)
-message(WARNING "Intel ICC untested in CMake.")
-target_link_libraries(xgl PRIVATE -fabi-version=0 -static-intel)
-endif()
+#if(NOT ICD_USE_GCC)
+#message(WARNING "Intel ICC untested in CMake.")
+#target_link_libraries(xgl PRIVATE -fabi-version=0 -static-intel)
+#endif()
if(CMAKE_BUILD_TYPE_RELEASE)
if("${CMAKE_CXX_COMPILER_ID}" STREQUAL "GNU")
execute_process(COMMAND ${CMAKE_C_COMPILER} -dumpversion
OUTPUT_VARIABLE GCC_VERSION)
if (GCC_VERSION VERSION_GREATER 5.3 OR GCC_VERSION
VERSION_EQUAL 5.3)
-target_link_libraries(xgl PRIVATE -flto=4
-fuse-linker-plugin -Wno-odr)
+target_link_libraries(xgl PRIVATE -Wno-odr)
message(WARNING "LTO enabled for Linking")
endif()
endif()
@@ -530,17 +530,17 @@ if (UNIX)
# CMAKE-TODO: What is whole-archive used for?
#target_link_libraries(xgl -Wl,--whole-archive ${ICD_LIBS}
-Wl,--no-whole-archive)
-if(CMAKE_BUILD_TYPE_RELEASE)
-execute_process(COMMAND ${CMAKE_C_COMPILER} -dumpversion
OUTPUT_VARIABLE GCC_VERSION)
-if (GCC_VERSION VERSION_GREATER 5.3 OR GCC_VERSION VERSION_EQUAL
5.3)
-target_link_libraries(xgl PRIVATE -Wl,--whole-archive
${PROJECT_BINARY_DIR}/pal/src/libpal.a -Wl,--no-whole-archive)
-target_link_libraries(xgl PUBLIC -Wl,--whole-archive
${PROJECT_BINARY_DIR}/pal/metrohash/libmetrohash.a -Wl,--no-whole-archive)
-target_link_libraries(xgl PUBLIC -Wl,--whole-archive
${PROJECT_BINARY_DIR}/pal/gpuopen/libgpuopen.a -Wl,--no-whole-archive)
-target_link_libraries(xgl PUBLIC -Wl,--whole-archive
${PROJECT_BINARY_DIR}/pal/vam/libvam.a -Wl,--no-whole-archive)
-target_link_libraries(xgl PUBLIC -Wl,--whole-archive
${PROJECT_BINARY_DIR}/pal/addrlib/libaddrlib.a -Wl,--no-whole-archive)
-target_link_libraries(xgl PUBLIC -Wl,--whole-archive
${PROJECT_BINARY_DIR}/pal/jemalloc/libjemalloc.a -Wl,--no-whole-archive)
-endif()
-endif()
+#if(CMAKE_BUILD_TYPE_RELEASE)
+#execute_process(COMMAND ${CMAKE_C_COMPILER} -dumpversion
OUTPUT_VARIABLE GCC_VERSION)
+#if (GCC_VERSION VERSION_GREATER 5.3 OR GCC_VERSION VERSION_EQUAL
5.3)
+#target_link_libraries(xgl PRIVATE -Wl,--whole-archive
${PROJECT_BINARY_DIR}/pal/src/libpal.a -Wl,--no-whole-archive)
+#target_link_libraries(xgl PUBLIC -Wl,--whole-archive
${PROJECT_BINARY_DIR}/pal/metrohash/libmetrohash.a -Wl,--no-whole-archive)
+#target_link_libraries(xgl PUBLIC -Wl,--whole-archive
${PROJECT_BINARY_DIR}/pal/gpuopen/libgpuopen.a -Wl,--no-whole-archive)
+#target_link_libraries(xgl PUBLIC -Wl,--whole-archive
${PROJECT_BINARY_DIR}/pal/vam/libvam.a -Wl,--no-whole-archive)
+#target_link_libraries(xgl PUBLIC -Wl,--whole-archive
${PROJECT_BINARY_DIR}/pal/addrlib/libaddrlib.a -Wl,--no-whole-archive)
+#target_link_libraries(xgl PUBLIC -Wl,--whole-archive
${PROJECT_BINARY_DIR}/pal/jemalloc/libjemalloc.a -Wl,--no-whole-archive)
+#endif()
+#endif()
#${ICD_TARGET}.so${SO_VERSION_NUMBER} : ${filter-out -Wl%,$(LLLIBS})
diff --git a/icd/api/llpc/util/llpcDebug.cpp
b/
[Bug 101900] No HDMI HBR audio on Polaris (no TrueHD, no Atmos, no Neo:X, no HD Master audio) and static noise in sound when LPCM
https://bugs.freedesktop.org/show_bug.cgi?id=101900 --- Comment #18 from Direx --- (In reply to Michel Dänzer from comment #17) > FWIW, according to comments on https://lwn.net/Articles/740916/: > > * HDMI sinks complying with the relevant specs only accept Dolby TrueHD with > HDCP enabled. > * There are buggy HDMI sinks which only play some other "high quality" bit > streams with HDCP enabled. The article does not say anything at all about HBR audio. Just one comment and I also doubt that this is true. Where is that spec? I have tested quite a few GPUs (Intel with i915, Nvidia, r600) and all of them had proper HDMI audio/HBR support, which was completely unrelated to HDCP. Even on Windows HBR audio does not have anything to do with HDCP. I am not using HDCP there either and my RX480 properly passes all audio formats to my AVR on Windows. >From this bug report it looks like AMD has completely given up on HTPC people and leaves this area entirely to Intel. -- 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
Initial release of AMD Open Source Driver for Vulkan
We are pleased to announce the initial release of AMD Open Source Driver for Vulkan. The AMD Open Source Driver for Vulkan is an open-source Vulkan driver for Radeon graphics adapters on Linux. It is built on top of AMD's Platform Abstraction Library (PAL), a shared component that is designed to encapsulate certain hardware and OS-specific programming details for many of AMD's 3D and compute drivers. Leveraging PAL can help provide a consistent experience across platforms, including support for recently released GPUs and compatibility with AMD developer tools. The driver uses the LLVM-Based Pipeline Compiler (LLPC) library to compile shaders that compose a particular VkPipeline object. LLPC builds on LLVM's existing shader compilation infrastructure for AMD GPUs to generate code objects compatible with PAL's pipeline ABI. The AMD Open Source Driver for Vulkan is designed to support the following features: - Vulkan 1.0 - More than 30 extensions - Radeon GPUProfiler tracing - Built-in debug and profiling tools - Mid-command buffer preemption and SR-IOV virtualization The following features and improvements are planned in future releases: - Upcoming versions of the Vulkan API - Hardware performance counter collection through RenderDoc - LLPC optimizations to improve GPU-limited performance and compile time - Optimizations to improve CPU-limited performance Please refer to the README file under https://github.com/GPUOpen-Drivers/AMDVLK for more information. Looking forward to hearing your feedback. Thanks, The AMD driver team for Vulkan ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 102233] OpenCL segmentation fault on AMD Radeon (Kaveri+R7) with memtestCL
https://bugs.freedesktop.org/show_bug.cgi?id=102233 --- Comment #3 from Jan Vesely --- (In reply to Senad from comment #0) > I get 100% crashes with YACMiner (crypto mining software). please report a separate bug for YACMiner -- 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 102233] OpenCL segmentation fault on AMD Radeon (Kaveri+R7) with memtestCL
https://bugs.freedesktop.org/show_bug.cgi?id=102233 --- Comment #2 from Jan Vesely --- Can you try initializing the num_gpu, num_cpu, num_accel variables? clGetDeviceIDs returns CL_DEVICE_NOT_FOUND error if there are no devices matching the requested type. This does not set num_devices output parameter to 0. Unless the variables are initialized to 0, the loop on line 135 accesses devids array out of bounds. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 02/12] drm/panel: lvds: Add support for the power-supply property
Hi Maxime,
Thank you for the patch.
On Thursday, 21 December 2017 13:02:28 EET Maxime Ripard wrote:
> A significant number of panels need to power up a regulator in order to
> operate properly. Add support for the power-supply property to enable and
> disable such a regulator whenever needed.
>
> Reviewed-by: Chen-Yu Tsai
> Signed-off-by: Maxime Ripard
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/panel/panel-lvds.c | 23 +++
> 1 file changed, 23 insertions(+)
>
> diff --git a/drivers/gpu/drm/panel/panel-lvds.c
> b/drivers/gpu/drm/panel/panel-lvds.c index e2d57c01200b..57e38a9e7ab4
> 100644
> --- a/drivers/gpu/drm/panel/panel-lvds.c
> +++ b/drivers/gpu/drm/panel/panel-lvds.c
> @@ -17,6 +17,7 @@
> #include
> #include
> #include
> +#include
> #include
>
> #include
> @@ -39,6 +40,7 @@ struct panel_lvds {
> bool data_mirror;
>
> struct backlight_device *backlight;
> + struct regulator *supply;
>
> struct gpio_desc *enable_gpio;
> struct gpio_desc *reset_gpio;
> @@ -69,6 +71,9 @@ static int panel_lvds_unprepare(struct drm_panel *panel)
> if (lvds->enable_gpio)
> gpiod_set_value_cansleep(lvds->enable_gpio, 0);
>
> + if (lvds->supply)
> + regulator_disable(lvds->supply);
> +
> return 0;
> }
>
> @@ -76,6 +81,17 @@ static int panel_lvds_prepare(struct drm_panel *panel)
> {
> struct panel_lvds *lvds = to_panel_lvds(panel);
>
> + if (lvds->supply) {
> + int err;
> +
> + err = regulator_enable(lvds->supply);
> + if (err < 0) {
> + dev_err(lvds->dev, "failed to enable supply: %d\n",
> + err);
> + return err;
> + }
> + }
> +
> if (lvds->enable_gpio)
> gpiod_set_value_cansleep(lvds->enable_gpio, 1);
>
> @@ -196,6 +212,13 @@ static int panel_lvds_probe(struct platform_device
> *pdev) if (ret < 0)
> return ret;
>
> + lvds->supply = devm_regulator_get_optional(lvds->dev, "power");
> + if (IS_ERR(lvds->supply)) {
> + ret = PTR_ERR(lvds->supply);
> + dev_err(lvds->dev, "failed to request regulator: %d\n", ret);
> + return ret;
> + }
> +
> /* Get GPIOs and backlight controller. */
> lvds->enable_gpio = devm_gpiod_get_optional(lvds->dev, "enable",
>GPIOD_OUT_LOW);
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 01/12] dt-bindings: panel: lvds: Document power-supply property
Hi Maxime, Thank you for the patch. On Thursday, 21 December 2017 13:02:27 EET Maxime Ripard wrote: > The power-supply property is used by a vast majority of panels, including > panel-simple. Let's document it as a common property > > Reviewed-by: Rob Herring > Signed-off-by: Maxime Ripard > --- > Documentation/devicetree/bindings/display/panel/panel-common.txt | 6 ++ > Documentation/devicetree/bindings/display/panel/panel-lvds.txt | 1 + > Documentation/devicetree/bindings/display/panel/simple-panel.txt | 2 +- 3 > files changed, 8 insertions(+), 1 deletion(-) > > diff --git > a/Documentation/devicetree/bindings/display/panel/panel-common.txt > b/Documentation/devicetree/bindings/display/panel/panel-common.txt index > ec52c472c845..125ea68052af 100644 > --- a/Documentation/devicetree/bindings/display/panel/panel-common.txt > +++ b/Documentation/devicetree/bindings/display/panel/panel-common.txt > @@ -78,6 +78,12 @@ used for panels that implement compatible control > signals. while active. Active high reset signals can be supported by > inverting the GPIO specifier polarity flag. > > +Power > +- > + > +- power-supply: many display panels need an additional power supply in > + order to be fully powered-up. For such panels, power-supply contains > + a phandle to the regulator powering the panel. I think we should give more details here about the limitations of this property. How about the following explanation ? - power-supply: display panels require power to be supplied. While several panels need more than one power supply with panel-specific constraints governing the order and timings of the power supplies, in many cases a single power supply is sufficient, either because the panel has a single power rail, or because all its power rails can be driven by the same supply. In that case the power-supply property specifies the supply powering the panel as a phandle to a regulator. > Backlight > - > diff --git a/Documentation/devicetree/bindings/display/panel/panel-lvds.txt > b/Documentation/devicetree/bindings/display/panel/panel-lvds.txt index > b938269f841e..250850a2150b 100644 > --- a/Documentation/devicetree/bindings/display/panel/panel-lvds.txt > +++ b/Documentation/devicetree/bindings/display/panel/panel-lvds.txt > @@ -32,6 +32,7 @@ Optional properties: > - label: See panel-common.txt. > - gpios: See panel-common.txt. > - backlight: See panel-common.txt. > +- power-supply: See panel-common.txt. > - data-mirror: If set, reverse the bit order described in the data mappings > below on all data lanes, transmitting bits for slots 6 to 0 instead of 0 to > 6. > diff --git > a/Documentation/devicetree/bindings/display/panel/simple-panel.txt > b/Documentation/devicetree/bindings/display/panel/simple-panel.txt index > 1341bbf4aa3d..16d8ff088b7d 100644 > --- a/Documentation/devicetree/bindings/display/panel/simple-panel.txt > +++ b/Documentation/devicetree/bindings/display/panel/simple-panel.txt > @@ -1,7 +1,7 @@ > Simple display panel > > Required properties: > -- power-supply: regulator to provide the supply voltage > +- power-supply: See panel-common.txt > > Optional properties: > - ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/1] drm: Add dirty_rects atomic blob property for drm_plane
Thanks Ville and Daniel for for your response.
I will try to come back with something later.
thanks
Lukasz
On 21/12/2017 14:10, Daniel Vetter wrote:
On Thu, Dec 21, 2017 at 02:46:55PM +0200, Ville Syrjälä wrote:
> On Thu, Dec 21, 2017 at 12:10:08PM +0100, Lukasz Spintzyk wrote:
> > Change-Id: I63dce004f8d3c5dc6a7c71070f1fab0707286ea5
> > Signed-off-by: Lukasz Spintzyk
> > ---
> > drivers/gpu/drm/drm_atomic.c | 10 ++
> > drivers/gpu/drm/drm_mode_config.c | 6 ++
> > drivers/gpu/drm/drm_plane.c | 1 +
> > include/drm/drm_mode_config.h | 5 +
> > include/drm/drm_plane.h | 3 +++
> > 5 files changed, 25 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic.c
b/drivers/gpu/drm/drm_atomic.c
> > index b76d49218cf1..cd3b4ed7b04c 100644
> > --- a/drivers/gpu/drm/drm_atomic.c
> > +++ b/drivers/gpu/drm/drm_atomic.c
> > @@ -759,6 +759,14 @@ static int
drm_atomic_plane_set_property(struct drm_plane *plane,
> > state->rotation = val;
> > } else if (property == plane->zpos_property) {
> > state->zpos = val;
> > + } else if (property == config->dirty_rects_property) {
> > + bool replaced = false;
> > + int ret = drm_atomic_replace_property_blob_from_id(dev,
> > + &state->dirty_blob,
> > + val,
> > + -1,
> > + &replaced);
> > + return ret;
> > } else if (plane->funcs->atomic_set_property) {
> > return plane->funcs->atomic_set_property(plane, state,
> > property, val);
> > @@ -818,6 +826,8 @@ drm_atomic_plane_get_property(struct drm_plane
*plane,
> > *val = state->rotation;
> > } else if (property == plane->zpos_property) {
> > *val = state->zpos;
> > + } else if (property == config->dirty_rects_property) {
> > + *val = (state->dirty_blob) ? state->dirty_blob->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_mode_config.c
b/drivers/gpu/drm/drm_mode_config.c
> > index bc5c46306b3d..d5f1021c6ece 100644
> > --- a/drivers/gpu/drm/drm_mode_config.c
> > +++ b/drivers/gpu/drm/drm_mode_config.c
> > @@ -293,6 +293,12 @@ static int
drm_mode_create_standard_properties(struct drm_device *dev)
> > return -ENOMEM;
> > dev->mode_config.prop_crtc_id = prop;
> >
> > + prop = drm_property_create(dev, DRM_MODE_PROP_BLOB,
> > + "DIRTY_RECTS", 0);
> > + if (!prop)
> > + return -ENOMEM;
> > + dev->mode_config.dirty_rects_property = prop;
> > +
> > prop = drm_property_create_bool(dev, DRM_MODE_PROP_ATOMIC,
> > "ACTIVE");
> > if (!prop)
> > diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
> > index 37a93cdffb4a..add110f025e5 100644
> > --- a/drivers/gpu/drm/drm_plane.c
> > +++ b/drivers/gpu/drm/drm_plane.c
> > @@ -258,6 +258,7 @@ int drm_universal_plane_init(struct drm_device
*dev, struct drm_plane *plane,
> > drm_object_attach_property(&plane->base, config->prop_src_y, 0);
> > drm_object_attach_property(&plane->base, config->prop_src_w, 0);
> > drm_object_attach_property(&plane->base, config->prop_src_h, 0);
> > + drm_object_attach_property(&plane->base,
config->dirty_rects_property, 0);
> > }
> >
> > if (config->allow_fb_modifiers)
> > diff --git a/include/drm/drm_mode_config.h
b/include/drm/drm_mode_config.h
> > index e5f3b43014e1..65f64eb04c0c 100644
> > --- a/include/drm/drm_mode_config.h
> > +++ b/include/drm/drm_mode_config.h
> > @@ -599,6 +599,11 @@ struct drm_mode_config {
> > * &drm_crtc.
> > */
> > struct drm_property *prop_crtc_id;
> > + /**
> > + * @dirty_rects_property: Optional plane property to mark damaged
> > + * regions on the plane framebuffer.
>
> What exactly would the blob contain?
>
> The comment seems to be implying these are in fb coordiantes as
> opposed to plane crtc coordinates? Not sure which would be more
> convenient. At least if they're fb coordinates then you probably
> want some helpers to translate/rotate/scale those rects to the
> crtc coordinates. Actual use depends on the driver/hw I suppose.
Yeah I think we also should add a decoded state to the drm_plane_state,
which has the full structure and all the details.
Ok.
Initially for model I was thinking to take struct drm_drawable_info with
simple c style array of struct drm_clip_rect *rects in it.
Do you think that something more complex will be needed?
And when we discussed this iirc we've identified a clear need for at least
some drivers to deal in crtc dirty rectangles. I think the initial core
support should include a helper which takes an atomic update for a given
crtc, and converts all the plane dirty rectangles into crtc rectangles.
Including any full-plane or full-crtc upgrades needed due to e.g.
reposition, changed gamma, changed blendign/zpos or anything else really
that would affect the entire plane respectively crtc. That would also
provide a really good model for what damage actually means.
Ok.
Plus ofc we need userspace for this, preferrably as a patch to something
generic like weston or xfree86-video-modesetting. And an example kernel
im
Re: [PATCH 1/2] drm/blend: Account also the primary plane of the crtc for normalized_zpos
On Fri, Dec 22, 2017 at 11:16:47AM +0200, Tomi Valkeinen wrote: > On 21/12/17 17:12, Ville Syrjälä wrote: > > >> If the userspace knows this, then it knows which primary plane is for > >> which crtc, right? > >> > >> And if it doesn't know this, then the userspace cannot associate any > >> plane to any crtc (except what it configures itself). > >> > >> So... If using legacy modesetting (and non-universal planes), there's no > >> problem, primary planes are fixed and at low zpos. If using atomic > >> modesetting and universal planes, there's really no (default) > >> association between planes and crtcs, and "primary plane" doesn't have > >> much meaning. Is that correct? > >> > >> If so... Then I guess the atomic modesetting client essentially randomly > >> picks which plane it uses as a "root plane" (if it even needs such), and > >> which planes as overlay planes? If that's the case, then this patch > >> doesn't quite fix the issue... > > > > I'm not sure anyone has really thought how userspace would/should assign > > planes to crtcs. My only idea so far has been the crtc and their > > preferred primary planes should be registered in the same order. But > > someone should then also implement that same policy in userspace when > > it's trying to figure out which plane to use. There are other > > heuristics it should probably use, like preferring to pick a primary > > plane for any fullscreen surface. > > > > I guess from functional point of view it shouldn't matter which plane > > you pick as long as the plane's user visible capabilities are > > sufficient. But there might be user invisible power saving features and > > whatnot that only work with specific planes. So from that point of view > > maybe the order in which the planes get registered is important. Or we > > could maybe come up with some kind of plane usage hints in the uapi > > which could help userspace decide? > > I was thinking about this, and... maybe there isn't even any problem (at > least for OMAP). So lets say we set the default plane zpos to the plane > index, and that the primary planes are reserved first (i.e. have lower > zpos than overlay planes). > > We have three different cases: > > Legacy modesetting: No problems, primary plane is always at the bottom. > If the userspace uses 2+ overlay planes, it can expect the zpos to be > based on the plane id, or it can set the zpos. > > Atomic+Universal, the application uses one primary plane, and zero or > more overlay planes: No problems here, the situation is the same as for > legacy. > > Atomic+Universal, the application uses more than one primary plane, and > zero or more overlay planes: in this case the app _has_ to manage zpos, > because using two primary planes in a single screen, and expecting it to > work by default, doesn't make sense. > > If the above "rules" are valid, then there's no need for this patch. > > But one question I don't have a good answer is that why would we want to > normalize the zpos, instead of returning an error? If the above rules > are valid, I think returning an error is better than normalizing and > hiding the bad configuration. IIRC I argued against the normalization, but some people really wanted it for whatever reason. -- Ville Syrjälä Intel OTC ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm/msm: Fix NULL deref in adreno_load_gpu
The msm/kms driver should work even if there is no GPU device specified
in DT. Currently, we get a NULL dereference crash in adreno_load_gpu
since the driver assumes that priv->gpu_pdev is non-NULL.
Perform an additional check on priv->gpu_pdev before trying to retrieve
the msm_gpu pointer from it.
v2: Incorporate Jordan's comments:
- Simplify the check to share the same error message.
- Use dev_err_once() to avoid an error message every time we open the
drm device fd.
Fixes: eec874ce5ff1 (drm/msm/adreno: load gpu at probe/bind time)
Signed-off-by: Archit Taneja
---
drivers/gpu/drm/msm/adreno/adreno_device.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c
b/drivers/gpu/drm/msm/adreno/adreno_device.c
index 05022ea2a007..bfb3d689f47d 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_device.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_device.c
@@ -125,11 +125,14 @@ struct msm_gpu *adreno_load_gpu(struct drm_device *dev)
{
struct msm_drm_private *priv = dev->dev_private;
struct platform_device *pdev = priv->gpu_pdev;
- struct msm_gpu *gpu = platform_get_drvdata(priv->gpu_pdev);
+ struct msm_gpu *gpu = NULL;
int ret;
+ if (pdev)
+ gpu = platform_get_drvdata(pdev);
+
if (!gpu) {
- dev_err(dev->dev, "no adreno device\n");
+ dev_err_once(dev->dev, "no GPU device was found\n");
return NULL;
}
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] drm-intel-fixes
Hi Dave, just flushing my queue of a couple of late arrivals before xmas. Pull and send on at your leisure. Happy holidays, Jani. The following changes since commit a4ffdc2b6726958c07d535318400124e3a3bc19b: drm/i915: Protect DDI port to DPLL map from theoretical race. (2017-12-19 14:59:53 +0200) are available in the git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2017-12-22-1 for you to fetch changes up to 8bc0d7ac934b6f2d0dc8f38a3104d281c9db1e98: i915: Reject CCS modifiers for pipe C on Geminilake (2017-12-21 19:51:03 +0200) GLK pipe C related fix, and a gvt fix. Gabriel Krisman Bertazi (1): i915: Reject CCS modifiers for pipe C on Geminilake Jani Nikula (1): Merge tag 'gvt-fixes-2017-12-21' of https://github.com/intel/gvt-linux into drm-intel-fixes Xiaolin Zhang (1): drm/i915/gvt: Fix pipe A enable as default for vgpu drivers/gpu/drm/i915/gvt/display.c | 5 +++-- drivers/gpu/drm/i915/intel_display.c | 2 +- 2 files changed, 4 insertions(+), 3 deletions(-) -- Jani Nikula, Intel Open Source Technology Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Problem rebuilding tip
Quoting Linus Walleij (2017-12-22 08:35:42) > I haven't even touched drm_syncobj.c so this conflict doesn't appear > to be mine. The conflict looks complex too. > > I guess someone else is busy fixing this up elsewhere in the world so > I just defer for a while and try rebuilding tip later. A function disappeared on one branch and some kerneldoc appeared another branch. Resolved. -Chris ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 101900] No HDMI HBR audio on Polaris (no TrueHD, no Atmos, no Neo:X, no HD Master audio) and static noise in sound when LPCM
https://bugs.freedesktop.org/show_bug.cgi?id=101900 --- Comment #17 from Michel Dänzer --- FWIW, according to comments on https://lwn.net/Articles/740916/: * HDMI sinks complying with the relevant specs only accept Dolby TrueHD with HDCP enabled. * There are buggy HDMI sinks which only play some other "high quality" bit streams with HDCP enabled. -- 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 104082] amdgpu 0000:07:00.0: swiotlb buffer is full (sz: 2097152 bytes)
https://bugs.freedesktop.org/show_bug.cgi?id=104082 --- Comment #2 from coolo...@gmail.com --- Created attachment 136362 --> https://bugs.freedesktop.org/attachment.cgi?id=136362&action=edit dmesg -- 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 104082] amdgpu 0000:07:00.0: swiotlb buffer is full (sz: 2097152 bytes)
https://bugs.freedesktop.org/show_bug.cgi?id=104082 --- Comment #1 from coolo...@gmail.com --- also getting the same issue with my vega 56, linux 4.15, mesa-git -- 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/blend: Account also the primary plane of the crtc for normalized_zpos
On 21/12/17 17:12, Ville Syrjälä wrote: If the userspace knows this, then it knows which primary plane is for which crtc, right? And if it doesn't know this, then the userspace cannot associate any plane to any crtc (except what it configures itself). So... If using legacy modesetting (and non-universal planes), there's no problem, primary planes are fixed and at low zpos. If using atomic modesetting and universal planes, there's really no (default) association between planes and crtcs, and "primary plane" doesn't have much meaning. Is that correct? If so... Then I guess the atomic modesetting client essentially randomly picks which plane it uses as a "root plane" (if it even needs such), and which planes as overlay planes? If that's the case, then this patch doesn't quite fix the issue... I'm not sure anyone has really thought how userspace would/should assign planes to crtcs. My only idea so far has been the crtc and their preferred primary planes should be registered in the same order. But someone should then also implement that same policy in userspace when it's trying to figure out which plane to use. There are other heuristics it should probably use, like preferring to pick a primary plane for any fullscreen surface. I guess from functional point of view it shouldn't matter which plane you pick as long as the plane's user visible capabilities are sufficient. But there might be user invisible power saving features and whatnot that only work with specific planes. So from that point of view maybe the order in which the planes get registered is important. Or we could maybe come up with some kind of plane usage hints in the uapi which could help userspace decide? I was thinking about this, and... maybe there isn't even any problem (at least for OMAP). So lets say we set the default plane zpos to the plane index, and that the primary planes are reserved first (i.e. have lower zpos than overlay planes). We have three different cases: Legacy modesetting: No problems, primary plane is always at the bottom. If the userspace uses 2+ overlay planes, it can expect the zpos to be based on the plane id, or it can set the zpos. Atomic+Universal, the application uses one primary plane, and zero or more overlay planes: No problems here, the situation is the same as for legacy. Atomic+Universal, the application uses more than one primary plane, and zero or more overlay planes: in this case the app _has_ to manage zpos, because using two primary planes in a single screen, and expecting it to work by default, doesn't make sense. If the above "rules" are valid, then there's no need for this patch. But one question I don't have a good answer is that why would we want to normalize the zpos, instead of returning an error? If the above rules are valid, I think returning an error is better than normalizing and hiding the bad configuration. Tomi -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Problem rebuilding tip
I merged a new panel driver to drm-misc, which shouldn't conflict with anything, however I get this on tip: Ändringar att checka in: ny fil: Documentation/devicetree/bindings/display/panel/ilitek,ili9322.txt ändrad:Documentation/gpu/drm-kms-helpers.rst ändrad:Documentation/gpu/drm-kms.rst ändrad:Documentation/gpu/todo.rst ändrad:drivers/gpu/drm/drm_atomic.c ändrad:drivers/gpu/drm/drm_edid.c ändrad:drivers/gpu/drm/drm_fb_helper.c ändrad:drivers/gpu/drm/drm_framebuffer.c ändrad:drivers/gpu/drm/panel/Kconfig ändrad:drivers/gpu/drm/panel/Makefile ny fil:drivers/gpu/drm/panel/panel-ilitek-ili9322.c ändrad:drivers/gpu/drm/stm/dw_mipi_dsi-stm.c ändrad:drivers/gpu/drm/stm/ltdc.c ändrad:include/drm/drm_atomic.h ändrad:include/drm/drm_fb_helper.h ändrad:include/drm/drm_framebuffer.h ändrad:include/drm/drm_mode_config.h ändrad:include/drm/drm_print.h ändrad:include/drm/drm_syncobj.h Ej sammanslagna sökvägar: (använd "git add ..." för att ange lösning) ändrat av bägge:drivers/gpu/drm/drm_syncobj.c (OK sorry for the Swedish) I haven't even touched drm_syncobj.c so this conflict doesn't appear to be mine. The conflict looks complex too. I guess someone else is busy fixing this up elsewhere in the world so I just defer for a while and try rebuilding tip later. I hope the problem is not on my side, I did dim update-branches and all other steps in the process slavishly and was hoping rerere would handle this smoothly if the conflict was someone elses. Yours, Linus Walleij ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/tegra: dc: Implement legacy blending
On 21.12.2017 17:03, Thierry Reding wrote:
> From: Thierry Reding
>
> This implements alpha blending on legacy display controllers (Tegra20,
> Tegra30 and Tegra114). While it's theoretically possible to support the
> zpos property to enable userspace to specify the Z-order of each plane
> individually, this is not currently supported and the same fixed Z-
> order as previously defined is used.
>
> Reverts commit 71835caa00e8 ("drm/tegra: fb: Force alpha formats") since
> the opaque formats are now supported.
>
> Reported-by: Dmitry Osipenko
> Fixes: 7772fdaef939 ("drm/tegra: Support ARGB and ABGR formats")
> Signed-off-by: Thierry Reding
> ---
> Changes in v2:
> - properly implement blending if windows have different pixel formats
>
> drivers/gpu/drm/tegra/dc.c| 81 +
> drivers/gpu/drm/tegra/dc.h| 12
> drivers/gpu/drm/tegra/fb.c| 12
> drivers/gpu/drm/tegra/plane.c | 138
> ++
> drivers/gpu/drm/tegra/plane.h | 8 +++
> 5 files changed, 226 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
> index 2a0c1e93f82e..4507063029e0 100644
> --- a/drivers/gpu/drm/tegra/dc.c
> +++ b/drivers/gpu/drm/tegra/dc.c
> @@ -154,30 +154,53 @@ static inline u32 compute_initial_dda(unsigned int in)
>
> static void tegra_plane_setup_blending_legacy(struct tegra_plane *plane)
> {
> + u32 background[3] = {
> + BLEND_WEIGHT1(0) | BLEND_WEIGHT0(0) | BLEND_COLOR_KEY_NONE,
> + BLEND_WEIGHT1(0) | BLEND_WEIGHT0(0) | BLEND_COLOR_KEY_NONE,
> + BLEND_WEIGHT1(0) | BLEND_WEIGHT0(0) | BLEND_COLOR_KEY_NONE,
> + };
> + u32 foreground = BLEND_WEIGHT1(255) | BLEND_WEIGHT0(255) |
> + BLEND_COLOR_KEY_NONE;
> + u32 blendnokey = BLEND_WEIGHT1(255) | BLEND_WEIGHT0(255);
> + struct tegra_plane_state *state;
> + unsigned int i;
> +
> + state = to_tegra_plane_state(plane->base.state);
> +
> + /* alpha contribution is 1 minus sum of overlapping windows */
> + for (i = 0; i < 3; i++) {
> + if (state->dependent[i])
> + background[i] |= BLEND_CONTROL_DEPENDENT;
> + }
> +
> + /* enable alpha blending if pixel format has an alpha component */
> + if (!state->opaque)
> + foreground |= BLEND_CONTROL_ALPHA;
> +
> /*
>* Disable blending and assume Window A is the bottom-most window,
>* Window C is the top-most window and Window B is in the middle.
>*/
> - tegra_plane_writel(plane, 0x00, DC_WIN_BLEND_NOKEY);
> - tegra_plane_writel(plane, 0x00, DC_WIN_BLEND_1WIN);
> + tegra_plane_writel(plane, blendnokey, DC_WIN_BLEND_NOKEY);
> + tegra_plane_writel(plane, foreground, DC_WIN_BLEND_1WIN);
>
> switch (plane->index) {
> case 0:
> - tegra_plane_writel(plane, 0x00, DC_WIN_BLEND_2WIN_X);
> - tegra_plane_writel(plane, 0x00, DC_WIN_BLEND_2WIN_Y);
> - tegra_plane_writel(plane, 0x00, DC_WIN_BLEND_3WIN_XY);
> + tegra_plane_writel(plane, background[0], DC_WIN_BLEND_2WIN_X);
> + tegra_plane_writel(plane, background[1], DC_WIN_BLEND_2WIN_Y);
> + tegra_plane_writel(plane, background[2], DC_WIN_BLEND_3WIN_XY);
> break;
>
> case 1:
> - tegra_plane_writel(plane, 0x00, DC_WIN_BLEND_2WIN_X);
> - tegra_plane_writel(plane, 0x00, DC_WIN_BLEND_2WIN_Y);
> - tegra_plane_writel(plane, 0x00, DC_WIN_BLEND_3WIN_XY);
> + tegra_plane_writel(plane, foreground, DC_WIN_BLEND_2WIN_X);
> + tegra_plane_writel(plane, background[1], DC_WIN_BLEND_2WIN_Y);
> + tegra_plane_writel(plane, background[2], DC_WIN_BLEND_3WIN_XY);
> break;
>
> case 2:
> - tegra_plane_writel(plane, 0x00, DC_WIN_BLEND_2WIN_X);
> - tegra_plane_writel(plane, 0x00, DC_WIN_BLEND_2WIN_Y);
> - tegra_plane_writel(plane, 0x00, DC_WIN_BLEND_3WIN_XY);
> + tegra_plane_writel(plane, foreground, DC_WIN_BLEND_2WIN_X);
> + tegra_plane_writel(plane, foreground, DC_WIN_BLEND_2WIN_Y);
> + tegra_plane_writel(plane, foreground, DC_WIN_BLEND_3WIN_XY);
> break;
> }
> }
> @@ -353,6 +376,11 @@ static const u32 tegra20_primary_formats[] = {
> DRM_FORMAT_RGBA5551,
> DRM_FORMAT_ABGR,
> DRM_FORMAT_ARGB,
> + /* non-native formats */
> + DRM_FORMAT_XRGB1555,
> + DRM_FORMAT_RGBX5551,
> + DRM_FORMAT_XBGR,
> + DRM_FORMAT_XRGB,
> };
>
> static const u32 tegra114_primary_formats[] = {
> @@ -409,18 +437,40 @@ static int tegra_plane_atomic_check(struct drm_plane
> *plane,
> struct tegra_bo_tiling *tiling = &plane_state->tiling;
> struct tegra_plane *tegra = to_tegra_plane(plane);
> struct tegra_dc *dc = to_tegra_dc(
Re: [PATCH v2] drm/tegra: dc: Implement legacy blending
On 21.12.2017 22:13, Dmitry Osipenko wrote:
> On 21.12.2017 21:46, Dmitry Osipenko wrote:
>> On 21.12.2017 17:03, Thierry Reding wrote:
>>> From: Thierry Reding
>>>
>>> This implements alpha blending on legacy display controllers (Tegra20,
>>> Tegra30 and Tegra114). While it's theoretically possible to support the
>>> zpos property to enable userspace to specify the Z-order of each plane
>>> individually, this is not currently supported and the same fixed Z-
>>> order as previously defined is used.
>>>
>>> Reverts commit 71835caa00e8 ("drm/tegra: fb: Force alpha formats") since
>>> the opaque formats are now supported.
>>>
>>> Reported-by: Dmitry Osipenko
>>> Fixes: 7772fdaef939 ("drm/tegra: Support ARGB and ABGR formats")
>>> Signed-off-by: Thierry Reding
>>> ---
>
> [snip]
>
>>> +
>>> +void tegra_plane_check_dependent(struct tegra_plane *tegra,
>>> +struct tegra_plane_state *state)
>>> +{
>>> + struct drm_plane_state *old, *new;
>>> + struct drm_plane *plane;
>>> + unsigned int zpos[2];
>>> + unsigned int i;
>>> +
>>> + for (i = 0; i < 3; i++)
>>> + state->dependent[i] = false;
>>> +
>>> + for (i = 0; i < 2; i++)
>>> + zpos[i] = 0;
>>> +
>>> + for_each_oldnew_plane_in_state(state->base.state, plane, old, new, i) {
>>
>> Somehow this works when 2 windows are blended (primary plane + cursor). But
>> unfortunately this doesn't work at all in a case when 3 windows blended
>> (primary
>> + video overlay + cursor), for some reason there is only one plane in the
>> state
>> here, so blending dependency tracking doesn't work at all. I'll continue to
>> look
>> into it, but for now I don't know why it doesn't work as expected. If you
>> have
>> any idea, please tell.
>
> Actually, I think this code only works when all planes are updated in a single
> commit. We need to handle cases when only some of the active planes are
> adjusting the state.
>
> [snip]
>
I've moved blending state to CRTC and now seems it is really working correctly.
I tried to run kms-planes-blend on my Intel desktop, but it crashes my machine
and so can't compare the result of the test, it looks correct though. Video
overlay + mouse cursor now working fine.
I've amended your patch, see it below.
---
From e5264125fb81757999f6b11fec0e7cfffb2ca6d6 Mon Sep 17 00:00:00 2001
From: Thierry Reding
Date: Wed, 20 Dec 2017 09:39:14 +0100
Subject: [PATCH] drm/tegra: dc: Implement legacy blending
This implements alpha blending on legacy display controllers (Tegra20,
Tegra30 and Tegra114). While it's theoretically possible to support the
zpos property to enable userspace to specify the Z-order of each plane
individually, this is not currently supported and the same fixed Z-
order as previously defined is used.
Reverts commit 71835caa00e8 ("drm/tegra: fb: Force alpha formats") since
the opaque formats are now supported.
Reported-by: Dmitry Osipenko
Fixes: 7772fdaef939 ("drm/tegra: Support ARGB and ABGR formats")
Signed-off-by: Thierry Reding
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/tegra/dc.c| 90 ++
drivers/gpu/drm/tegra/dc.h| 21 ++
drivers/gpu/drm/tegra/fb.c| 12
drivers/gpu/drm/tegra/plane.c | 145 ++
drivers/gpu/drm/tegra/plane.h | 4 ++
5 files changed, 233 insertions(+), 39 deletions(-)
diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
index 2a0c1e93f82e..fb7c0d211ac0 100644
--- a/drivers/gpu/drm/tegra/dc.c
+++ b/drivers/gpu/drm/tegra/dc.c
@@ -154,32 +154,12 @@ static inline u32 compute_initial_dda(unsigned int in)
static void tegra_plane_setup_blending_legacy(struct tegra_plane *plane)
{
- /*
-* Disable blending and assume Window A is the bottom-most window,
-* Window C is the top-most window and Window B is in the middle.
-*/
- tegra_plane_writel(plane, 0x00, DC_WIN_BLEND_NOKEY);
- tegra_plane_writel(plane, 0x00, DC_WIN_BLEND_1WIN);
-
- switch (plane->index) {
- case 0:
- tegra_plane_writel(plane, 0x00, DC_WIN_BLEND_2WIN_X);
- tegra_plane_writel(plane, 0x00, DC_WIN_BLEND_2WIN_Y);
- tegra_plane_writel(plane, 0x00, DC_WIN_BLEND_3WIN_XY);
- break;
-
- case 1:
- tegra_plane_writel(plane, 0x00, DC_WIN_BLEND_2WIN_X);
- tegra_plane_writel(plane, 0x00, DC_WIN_BLEND_2WIN_Y);
- tegra_plane_writel(plane, 0x00, DC_WIN_BLEND_3WIN_XY);
- break;
+ u32 foreground = BLEND_WEIGHT1(255) | BLEND_WEIGHT0(255) |
+BLEND_COLOR_KEY_NONE;
+ u32 blendnokey = BLEND_WEIGHT1(255) | BLEND_WEIGHT0(255);
- case 2:
- tegra_plane_writel(plane, 0x00, DC_WIN_BLEND_2WIN_X);
- tegra_plane_writel(plane, 0x00, DC_WIN_BLEND_2WIN_Y);
- tegra_plane_writel(plan
[PATCH v3] Fix loading of module radeonfb on PowerMac
When the linux kernel is build with (typical kernel ship with Debian
installer):
CONFIG_FB_OF=y
CONFIG_VT_HW_CONSOLE_BINDING=y
CONFIG_FB_RADEON=m
The offb driver takes precedence over module radeonfb. It is then
impossible to load the module, error reported is:
[ 96.551486] radeonfb :00:10.0: enabling device (0006 -> 0007)
[ 96.551526] radeonfb :00:10.0: BAR 0: can't reserve [mem
0x9800-0x9fff pref]
[ 96.551531] radeonfb (:00:10.0): cannot request region 0.
[ 96.551545] radeonfb: probe of :00:10.0 failed with error -16
This patch reproduce the behavior of the module radeon, so as to make it
possible to load radeonfb when offb is first loaded.
It should be noticed that `offb_destroy` is never called which explain the
need to skip error detection on the radeon side.
Signed-off-by: Mathieu Malaterre
Link: https://bugs.debian.org/826629#57
Link: https://bugzilla.kernel.org/show_bug.cgi?id=119741
Suggested-by: Lennart Sorensen
---
v2: Only fails when CONFIG_PCC is not set
v3: Only fails when CONFIG_FB_OF is not set, CONFIG_PCC was too broad. Since
the conflicts in region is due to OFfb explicitly refers to it.
drivers/video/fbdev/aty/radeon_base.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/drivers/video/fbdev/aty/radeon_base.c
b/drivers/video/fbdev/aty/radeon_base.c
index 4d77daeecf99..221879196531 100644
--- a/drivers/video/fbdev/aty/radeon_base.c
+++ b/drivers/video/fbdev/aty/radeon_base.c
@@ -2259,6 +2259,22 @@ static const struct bin_attribute edid2_attr = {
.read = radeon_show_edid2,
};
+static int radeon_kick_out_firmware_fb(struct pci_dev *pdev)
+{
+ struct apertures_struct *ap;
+
+ ap = alloc_apertures(1);
+ if (!ap)
+ return -ENOMEM;
+
+ ap->ranges[0].base = pci_resource_start(pdev, 0);
+ ap->ranges[0].size = pci_resource_len(pdev, 0);
+
+ remove_conflicting_framebuffers(ap, KBUILD_MODNAME, false);
+ kfree(ap);
+
+ return 0;
+}
static int radeonfb_pci_register(struct pci_dev *pdev,
const struct pci_device_id *ent)
@@ -2312,19 +2328,27 @@ static int radeonfb_pci_register(struct pci_dev *pdev,
rinfo->fb_base_phys = pci_resource_start (pdev, 0);
rinfo->mmio_base_phys = pci_resource_start (pdev, 2);
+ ret = radeon_kick_out_firmware_fb(pdev);
+ if (ret)
+ return ret;
+
/* request the mem regions */
ret = pci_request_region(pdev, 0, "radeonfb framebuffer");
if (ret < 0) {
+#ifndef CONFIG_FB_OF
printk( KERN_ERR "radeonfb (%s): cannot request region 0.\n",
pci_name(rinfo->pdev));
goto err_release_fb;
+#endif
}
ret = pci_request_region(pdev, 2, "radeonfb mmio");
if (ret < 0) {
+#ifndef CONFIG_FB_OF
printk( KERN_ERR "radeonfb (%s): cannot request region 2.\n",
pci_name(rinfo->pdev));
goto err_release_pci0;
+#endif
}
/* map the regions */
@@ -2509,10 +2533,12 @@ static int radeonfb_pci_register(struct pci_dev *pdev,
iounmap(rinfo->mmio_base);
err_release_pci2:
pci_release_region(pdev, 2);
+#ifndef CONFIG_FB_OF
err_release_pci0:
pci_release_region(pdev, 0);
err_release_fb:
framebuffer_release(info);
+#endif
err_disable:
err_out:
return ret;
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/tegra: dc: Implement legacy blending
On 21.12.2017 21:46, Dmitry Osipenko wrote:
> On 21.12.2017 17:03, Thierry Reding wrote:
>> From: Thierry Reding
>>
>> This implements alpha blending on legacy display controllers (Tegra20,
>> Tegra30 and Tegra114). While it's theoretically possible to support the
>> zpos property to enable userspace to specify the Z-order of each plane
>> individually, this is not currently supported and the same fixed Z-
>> order as previously defined is used.
>>
>> Reverts commit 71835caa00e8 ("drm/tegra: fb: Force alpha formats") since
>> the opaque formats are now supported.
>>
>> Reported-by: Dmitry Osipenko
>> Fixes: 7772fdaef939 ("drm/tegra: Support ARGB and ABGR formats")
>> Signed-off-by: Thierry Reding
>> ---
[snip]
>> +
>> +void tegra_plane_check_dependent(struct tegra_plane *tegra,
>> + struct tegra_plane_state *state)
>> +{
>> +struct drm_plane_state *old, *new;
>> +struct drm_plane *plane;
>> +unsigned int zpos[2];
>> +unsigned int i;
>> +
>> +for (i = 0; i < 3; i++)
>> +state->dependent[i] = false;
>> +
>> +for (i = 0; i < 2; i++)
>> +zpos[i] = 0;
>> +
>> +for_each_oldnew_plane_in_state(state->base.state, plane, old, new, i) {
>
> Somehow this works when 2 windows are blended (primary plane + cursor). But
> unfortunately this doesn't work at all in a case when 3 windows blended
> (primary
> + video overlay + cursor), for some reason there is only one plane in the
> state
> here, so blending dependency tracking doesn't work at all. I'll continue to
> look
> into it, but for now I don't know why it doesn't work as expected. If you have
> any idea, please tell.
Actually, I think this code only works when all planes are updated in a single
commit. We need to handle cases when only some of the active planes are
adjusting the state.
[snip]
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
