[Bug 64781] RV630 bad video playback (too fast) when HDMI audio output is enabled
https://bugzilla.kernel.org/show_bug.cgi?id=64781 --- Comment #6 from Giannis --- and why before 3.10-RC1 kernel, audio was fine? -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 64781] RV630 bad video playback (too fast) when HDMI audio output is enabled
https://bugzilla.kernel.org/show_bug.cgi?id=64781 Raymond changed: What|Removed |Added CC||superquad.vortex2 at gmail.com --- Comment #5 from Raymond --- seem only support 48000Hz Codec: ATI R6xx HDMI Address: 0 AFG Function Id: 0x1 (unsol 0) Vendor Id: 0x1002aa01 Subsystem Id: 0x00aa0100 Revision Id: 0x10 No Modem Function Group found Default PCM: rates [0x40]: 48000 bits [0x2]: 16 formats [0x1]: PCM -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 64781] RV630 bad video playback (too fast) when HDMI audio output is enabled
https://bugzilla.kernel.org/show_bug.cgi?id=64781 --- Comment #4 from Giannis --- Can I do something else to help? -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 71516] RV350 Radeon 9550 - no Unity 3D hardware support in Ubuntu 13.10, extremely slow
https://bugs.freedesktop.org/show_bug.cgi?id=71516 --- Comment #16 from Elven Decker --- Progress!! Starting from the login screen, I press control-alt F2 to bring up a command line. Then I run startx. I don't get a window manager, but I can find my way to xterm and then work from the command line after X starts. glxgears looks normal - smooth and as quickly as I believe the 9550 can go. :) Opening firefox, CNN and youtube videos play smoothly. >From your comments, I believe I have sidestepped lightdm. I opened synaptic and reinstalled lightdm and associated programs. I then minimized synaptic and now I know what the display manager does. That's OK, I'll be rebooting anyway. Next steps? I believe there is /usr/lib and an /etc folders. Can I clean them out and do another re-install? Will the config files get regenerated? Thanks -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131115/729c690d/attachment.html>
[PATCH v3 19/32] drm/exynos: Use mode_set to configure fimd
Hi Sean, Tomasz,
On Mon, Nov 11, 2013 at 6:03 AM, Tomasz Figa wrote:
> Hi Sean,
>
> On Tuesday 29 of October 2013 12:13:05 Sean Paul wrote:
>> This patch uses the mode passed into mode_set to configure fimd instead
>> of directly using the panel from context. This will allow us to move
>> the exynos_drm_display implementation from fimd into the DP driver
>> where it belongs.
>
> Remember that DP is not the only possible way to connect a display driven
> by FIMD. You also have the direct (RGB and i80) and DSI interfaces.
>
> Also, please see my comments inline.
>
>>
>> Signed-off-by: Sean Paul
>> ---
>>
>> Changes in v2: None
>> Changes in v3: None
>>
>> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 159
>> ++-
>> 1 file changed, 91 insertions(+), 68 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> index d2b8ccb..f69d6e5 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> @@ -104,6 +104,20 @@ struct fimd_win_data {
>> boolresume;
>> };
>>
>> +struct fimd_mode_data {
>> + unsignedvtotal;
>
> For consistency with rest of the code, unsigned int would prefered.
>
> However, I'm not sure what is this struct for, since it does not store
> neither raw register values (1 needs to be subtracted from them) nor
> any values hard to compute at commit time (maybe except clkdiv, but still
> how often commit would be called?).
>
>> + unsignedvdisplay;
>> + unsignedvsync_len;
>> + unsignedvbpd;
>> + unsignedvfpd;
>> + unsignedhtotal;
>> + unsignedhdisplay;
>> + unsignedhsync_len;
>> + unsignedhbpd;
>> + unsignedhfpd;
>> + u32 clkdiv;
>> +};
>> +
>> struct fimd_context {
>> struct device *dev;
>> struct drm_device *drm_dev;
>> @@ -112,8 +126,8 @@ struct fimd_context {
>> struct clk *bus_clk;
>> struct clk *lcd_clk;
>> void __iomem*regs;
>> + struct fimd_mode_data mode;
>> struct fimd_win_datawin_data[WINDOWS_NR];
>> - unsigned intclkdiv;
>> unsigned intdefault_win;
>> unsigned long irq_flags;
>> u32 vidcon0;
>> @@ -560,11 +574,56 @@ static void fimd_dpms(struct exynos_drm_manager *mgr,
>> int mode)
>> mutex_unlock(&ctx->lock);
>> }
>>
>> +static u32 fimd_calc_clkdiv(struct fimd_context *ctx,
>> + const struct drm_display_mode *mode)
>> +{
>> + unsigned long ideal_clk = mode->htotal * mode->vtotal * mode->vrefresh;
>> + u32 clkdiv;
>> +
>> + /* Find the clock divider value that gets us closest to ideal_clk */
>> + clkdiv = DIV_ROUND_CLOSEST(clk_get_rate(ctx->lcd_clk), ideal_clk);
>
> This is a functional change unrelated to $subject. Before this patch,
> DIV_ROUND_UP() had been used.
>
>> +
>> + return (clkdiv < 0x100) ? clkdiv : 0xff;
>> +}
>> +
>> +static bool fimd_mode_fixup(struct exynos_drm_manager *mgr,
>> + const struct drm_display_mode *mode,
>> + struct drm_display_mode *adjusted_mode)
>> +{
>> + if (adjusted_mode->vrefresh == 0)
>> + adjusted_mode->vrefresh = FIMD_DEFAULT_FRAMERATE;
The actual pixel clock will be clk_get_rate(ctx->lcd_clk) / clkdiv.
Should we also be adjusting the "clock" field of adjusted_mode here?
>> +
>> + return true;
>> +}
>> +
>> +static void fimd_mode_set(struct exynos_drm_manager *mgr,
>> + const struct drm_display_mode *in_mode)
>> +{
>> + struct fimd_context *ctx = mgr->ctx;
>> + struct fimd_mode_data *mode = &ctx->mode;
>> + int hblank, vblank;
>> +
>> + vblank = in_mode->crtc_vblank_end - in_mode->crtc_vblank_start;
>> + mode->vtotal = in_mode->crtc_vtotal;
>> + mode->vdisplay = in_mode->crtc_vdisplay;
>> + mode->vsync_len = in_mode->crtc_vsync_end - in_mode->crtc_vsync_start;
>> + mode->vbpd = (vblank - mode->vsync_len) / 2;
>> + mode->vfpd = vblank - mode->vsync_len - mode->vbpd;
>> +
>> + hblank = in_mode->crtc_hblank_end - in_mode->crtc_hblank_start;
>> + mode->htotal = in_mode->crtc_htotal;
>> + mode->hdisplay = in_mode->crtc_hdisplay;
>> + mode->hsync_len = in_mode->crtc_hsync_end - in_mode->crtc_hsync_start;
>> + mode->hbpd = (hblank - mode->hsync_len) / 2;
>> + mode->hfpd = hblank - mode->hsync_len - mode->hbpd;
>> +
>> + mode->clkdiv = fimd_calc_clkdiv(ctx, in_mode);
>
> What about simply copying contents of in_mode to driver context
> and then calculating clkdiv at commit time? You could get rid
> of the fimd_mode_data struct and most of this function.
[PATCH v3 19/32] drm/exynos: Use mode_set to configure fimd
vsync_end - > in_mode->crtc_vsync_start; > > + mode->vbpd = (vblank - mode->vsync_len) / 2; > > + mode->vfpd = vblank - mode->vsync_len - mode->vbpd; > > + > > + hblank = in_mode->crtc_hblank_end - in_mode->crtc_hblank_start; > > + mode->htotal = in_mode->crtc_htotal; > > + mode->hdisplay = in_mode->crtc_hdisplay; > > + mode->hsync_len = in_mode->crtc_hsync_end - > in_mode->crtc_hsync_start; > > + mode->hbpd = (hblank - mode->hsync_len) / 2; > > + mode->hfpd = hblank - mode->hsync_len - mode->hbpd; > > + > > + mode->clkdiv = fimd_calc_clkdiv(ctx, in_mode); > > What about simply copying contents of in_mode to driver context > and then calculating clkdiv at commit time? You could get rid > of the fimd_mode_data struct and most of this function. > > Otherwise, the patch looks fine. > > Best regards, > Tomasz > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel > -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131115/a0b458c8/attachment-0001.html>
[PATCH freedesk/drm-nouveau-next] drm: remove unused variable
/git/linux/drivers/gpu/drm/nouveau/core/subdev/mc/base.c: In function 'nouveau_mc_intr': /git/linux/drivers/gpu/drm/nouveau/core/subdev/mc/base.c:43:25: warning: unused variable 'device' [-Wunused-variable] Signed-off-by: Wanlong Gao --- drivers/gpu/drm/nouveau/core/subdev/mc/base.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/core/subdev/mc/base.c b/drivers/gpu/drm/nouveau/core/subdev/mc/base.c index bc19aa4..b4b9943 100644 --- a/drivers/gpu/drm/nouveau/core/subdev/mc/base.c +++ b/drivers/gpu/drm/nouveau/core/subdev/mc/base.c @@ -40,7 +40,6 @@ nouveau_mc_intr(int irq, void *arg) struct nouveau_mc *pmc = arg; const struct nouveau_mc_oclass *oclass = (void *)nv_object(pmc)->oclass; const struct nouveau_mc_intr *map = oclass->intr; - struct nouveau_device *device = nv_device(pmc); struct nouveau_subdev *unit; u32 intr; -- 1.8.5.rc1.17.g0ecd94d
[ANNOUNCE] libdrm 2.4.48
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 A new version of libdrm has been released. The main motivation for this release is the addition of the reset status query ioctl for the Intel kernel module. Access to this ioctl will be necessary for Mesa 10.0. Alex Deucher (2): radeon: add hawaii chip family radeon: add hawaii pci ids Ben Widawsky (2): intel/bdw: Add broadwell chipset IDs intel/bdw: Handle gen8 bufmgr_init Damien Lespiau (2): intel/bdw: Add gen8 to the decode init intel/bdw: Update MI_BATCH_BUFFER_START for aub dumps Dave Airlie (1): Revert "intel: Add support for GPU reset status query ioctl" Ian Romanick (3): intel: Add support for GPU reset status query ioctl intel: Add support for GPU reset status query ioctl libdrm: bump to 2.4.48 Keith Packard (1): Add DRM_MODE_PAGE_FLIP_ASYNC define Kenneth Graunke (3): intel: Add the Gen6+ version of MI_REPORT_PERF_COUNT to intel_decode.c. intel: Add MI_LOAD_REGISTER_MEM to intel_decode.c. intel/bdw/aub: Update AUB trace block writes for 48-bit addressing. Maarten Lankhorst (1): nouveau: prevent undefined behavior in nouveau_pushbuf_reloc with gcc-4.8 git tag: libdrm-2.4.48 http://dri.freedesktop.org/libdrm/libdrm-2.4.48.tar.bz2 MD5: 68a30979f09715f50d8363de5eb66b38 libdrm-2.4.48.tar.bz2 SHA1: 3151c197005ac465a571f05ab2b668782760b491 libdrm-2.4.48.tar.bz2 SHA256: f9bb0bbed8f0ac69de3e7c935afe632274a2aa9f1341102b485b123e57a44c9e libdrm-2.4.48.tar.bz2 http://dri.freedesktop.org/libdrm/libdrm-2.4.48.tar.gz MD5: 7d6e782a31c226f8539edad2d2fa0d69 libdrm-2.4.48.tar.gz SHA1: a2ed2529c7ed09789f8567edff81869279e88f4a libdrm-2.4.48.tar.gz SHA256: e6a0b408f5b143683d38ae8373f5adcc9bbee2e4858d9b390e80915524a03129 libdrm-2.4.48.tar.gz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) iEYEARECAAYFAlKG7xEACgkQX1gOwKyEAw/mngCfbHBikoz0DDYL4xbMxQLwAaHp YuwAn0xxOi1CphbmbDTokmfe3OhPZ9x/ =bGml -END PGP SIGNATURE-
[Bug 64226] python-opencl package generate segmentation fault at pipe_r600.so
https://bugs.freedesktop.org/show_bug.cgi?id=64226 --- Comment #2 from Tom Stellard --- Created attachment 89283 --> https://bugs.freedesktop.org/attachment.cgi?id=89283&action=edit Fix This patch should fix the crash. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131115/67232265/attachment.html>
[Bug 71647] radeonsi purple tinted colors
https://bugs.freedesktop.org/show_bug.cgi?id=71647 Tom changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131115/b1b9d376/attachment.html>
[Bug 71647] radeonsi purple tinted colors
https://bugs.freedesktop.org/show_bug.cgi?id=71647 --- Comment #3 from Tom --- (In reply to comment #2) > Can you bisect this? It's possible that this commit is responsible: > > R600/SI: Prefer SALU instructions for bit shift operations > > All shift operations will be selected as SALU instructions and then > if necessary lowered to VALU instructions in the SIFixSGPRCopies pass. > > This allows us to do more operations on the SALU which will improve > performance and is also required for implementing private memory > using indirect addressing, since the private memory pointers must stay > in the scalar registers. > > This patch includes some fixes from Matt Arsenault. > > git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk at 194625 > 91177308-0d34-0410-b5e6-96231b3b80d8 After update to the latest git version everything returned to normal. Thanks. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131115/0b94b7f5/attachment.html>
[PATCH] intel: Add support for GPU reset status query ioctl
On Fri, Nov 15, 2013 at 10:41:57AM -0800, Ian Romanick wrote:
> From: Ian Romanick
>
> I would have just used the drmIoctl interface directly in Mesa, but the
> ioctl needs some data from the drm_intel_context that is not exposed
> outside libdrm.
>
> This ioctl is in the drm-intel-next tree as b635991.
>
> v2: Update based on Mika's kernel work.
>
> v3: Fix compile failures from last-minute typos. Sigh.
>
> v4: Import the actual changes from the kernel i915_drm.h. Only comments
> on some fields of drm_i915_reset_stats differed. There are still some
> deltas between the kernel i915_drm.h and the one in libdrm, but those
> can be resolved in other patches.
>
> Signed-off-by: Ian Romanick
> Reviewed-by: Kenneth Graunke [v3]
> Cc: Mika Kuoppala
> Cc: Daniel Vetter
Looks good to me.
Reviewed-by: Damien Lespiau
> ---
> include/drm/i915_drm.h | 19 +++
> intel/intel_bufmgr.h | 5 +
> intel/intel_bufmgr_gem.c | 34 ++
> 3 files changed, 58 insertions(+)
>
> diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
> index aa983f3..c1914d6 100644
> --- a/include/drm/i915_drm.h
> +++ b/include/drm/i915_drm.h
> @@ -198,6 +198,7 @@ typedef struct _drm_i915_sarea {
> #define DRM_I915_GEM_SET_CACHEING0x2f
> #define DRM_I915_GEM_GET_CACHEING0x30
> #define DRM_I915_REG_READ0x31
> +#define DRM_I915_GET_RESET_STATS 0x32
>
> #define DRM_IOCTL_I915_INIT DRM_IOW( DRM_COMMAND_BASE +
> DRM_I915_INIT, drm_i915_init_t)
> #define DRM_IOCTL_I915_FLUSH DRM_IO ( DRM_COMMAND_BASE +
> DRM_I915_FLUSH)
> @@ -247,6 +248,7 @@ typedef struct _drm_i915_sarea {
> #define DRM_IOCTL_I915_GEM_CONTEXT_CREATEDRM_IOWR (DRM_COMMAND_BASE +
> DRM_I915_GEM_CONTEXT_CREATE, struct drm_i915_gem_context_create)
> #define DRM_IOCTL_I915_GEM_CONTEXT_DESTROY DRM_IOW (DRM_COMMAND_BASE +
> DRM_I915_GEM_CONTEXT_DESTROY, struct drm_i915_gem_context_destroy)
> #define DRM_IOCTL_I915_REG_READ DRM_IOWR
> (DRM_COMMAND_BASE + DRM_I915_REG_READ, struct drm_i915_reg_read)
> +#define DRM_IOCTL_I915_GET_RESET_STATS DRM_IOWR
> (DRM_COMMAND_BASE + DRM_I915_GET_RESET_STATS, struct drm_i915_reset_stats)
>
> /* Allow drivers to submit batchbuffers directly to hardware, relying
> * on the security mechanisms provided by hardware.
> @@ -943,4 +945,21 @@ struct drm_i915_reg_read {
> __u64 offset;
> __u64 val; /* Return value */
> };
> +
> +struct drm_i915_reset_stats {
> + __u32 ctx_id;
> + __u32 flags;
> +
> + /* All resets since boot/module reload, for all contexts */
> + __u32 reset_count;
> +
> + /* Number of batches lost when active in GPU, for this context */
> + __u32 batch_active;
> +
> + /* Number of batches lost pending for execution, for this context */
> + __u32 batch_pending;
> +
> + __u32 pad;
> +};
> +
> #endif /* _I915_DRM_H_ */
> diff --git a/intel/intel_bufmgr.h b/intel/intel_bufmgr.h
> index 7b28a70..34a5750 100644
> --- a/intel/intel_bufmgr.h
> +++ b/intel/intel_bufmgr.h
> @@ -249,6 +249,11 @@ int drm_intel_reg_read(drm_intel_bufmgr *bufmgr,
> uint32_t offset,
> uint64_t *result);
>
> +int drm_intel_get_reset_stats(drm_intel_context *ctx,
> + uint32_t *reset_count,
> + uint32_t *active,
> + uint32_t *pending);
> +
> /** @{ Compatibility defines to keep old code building despite the symbol
> rename
> * from dri_* to drm_intel_*
> */
> diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
> index dbadc52..0b9252e 100644
> --- a/intel/intel_bufmgr_gem.c
> +++ b/intel/intel_bufmgr_gem.c
> @@ -3029,6 +3029,40 @@ drm_intel_gem_context_get_hw_context_id(const
> drm_intel_context *ctx)
> }
>
> int
> +drm_intel_get_reset_stats(drm_intel_context *ctx,
> + uint32_t *reset_count,
> + uint32_t *active,
> + uint32_t *pending)
> +{
> + drm_intel_bufmgr_gem *bufmgr_gem;
> + struct drm_i915_reset_stats stats;
> + int ret;
> +
> + if (ctx == NULL)
> + return -EINVAL;
> +
> + VG_CLEAR(stats);
> +
> + bufmgr_gem = (drm_intel_bufmgr_gem *)ctx->bufmgr;
> + stats.ctx_id = ctx->ctx_id;
> + ret = drmIoctl(bufmgr_gem->fd,
> +DRM_IOCTL_I915_GET_RESET_STATS,
> +&stats);
> + if (ret == 0) {
> + if (reset_count != NULL)
> + *reset_count = stats.reset_count;
> +
> + if (active != NULL)
> + *active = stats.batch_active;
> +
> + if (pending != NULL)
> + *pending = stats.batch_pending;
> + }
> +
> + return ret;
> +}
> +
> +int
> drm_intel_reg_read(drm_intel_bufmgr *bufmgr,
> uint32_t offset,
> uint64_t *r
[PATCH 2/2] radeon: implement 2D tiling for CIK
From: Michel D?nzer
Bug fixes and simplification by Marek.
We have to use the tile index of 0 for non-MSAA depth-stencil after all.
Signed-off-by: Marek Ol??k
---
include/drm/radeon_drm.h | 11 +
radeon/radeon_surface.c | 620 ++-
radeon/radeon_surface.h | 1 +
3 files changed, 623 insertions(+), 9 deletions(-)
diff --git a/include/drm/radeon_drm.h b/include/drm/radeon_drm.h
index d1bebf5..96ea555 100644
--- a/include/drm/radeon_drm.h
+++ b/include/drm/radeon_drm.h
@@ -979,6 +979,10 @@ struct drm_radeon_cs {
#define RADEON_INFO_RING_WORKING 0x15
/* SI tile mode array */
#define RADEON_INFO_SI_TILE_MODE_ARRAY 0x16
+/* query if CP DMA is supported on the compute ring */
+#define RADEON_INFO_SI_CP_DMA_COMPUTE 0x17
+/* CIK macrotile mode array */
+#define RADEON_INFO_CIK_MACROTILE_MODE_ARRAY 0x18
struct drm_radeon_info {
uint32_trequest;
@@ -1004,6 +1008,13 @@ struct drm_radeon_info {
#define SI_TILE_MODE_DEPTH_STENCIL_2D_4AA 3
#define SI_TILE_MODE_DEPTH_STENCIL_2D_8AA 2
+#define CIK_TILE_MODE_COLOR_2D 14
+#define CIK_TILE_MODE_COLOR_2D_SCANOUT 10
+#define CIK_TILE_MODE_DEPTH_STENCIL_2D_TILESPLIT_64 0
+#define CIK_TILE_MODE_DEPTH_STENCIL_2D_TILESPLIT_128 1
+#define CIK_TILE_MODE_DEPTH_STENCIL_2D_TILESPLIT_256 2
+#define CIK_TILE_MODE_DEPTH_STENCIL_2D_TILESPLIT_512 3
+#define CIK_TILE_MODE_DEPTH_STENCIL_2D_TILESPLIT_ROW_SIZE 4
#define CIK_TILE_MODE_DEPTH_STENCIL_1D 5
#endif
diff --git a/radeon/radeon_surface.c b/radeon/radeon_surface.c
index 56e2e4a..927a21e 100644
--- a/radeon/radeon_surface.c
+++ b/radeon/radeon_surface.c
@@ -26,6 +26,8 @@
* Authors:
* J?r?me Glisse
*/
+#include
+#include
#include
#include
#include
@@ -95,6 +97,8 @@ struct radeon_hw_info {
unsignedallow_2d;
/* apply to si */
uint32_ttile_mode_array[32];
+/* apply to cik */
+uint32_tmacrotile_mode_array[16];
};
struct radeon_surface_manager {
@@ -1382,16 +1386,10 @@ static int si_surface_sanity(struct
radeon_surface_manager *surf_man,
break;
case RADEON_SURF_MODE_1D:
if (surf->flags & RADEON_SURF_SBUFFER) {
-if (surf_man->family >= CHIP_BONAIRE)
-*stencil_tile_mode = CIK_TILE_MODE_DEPTH_STENCIL_1D;
-else
-*stencil_tile_mode = SI_TILE_MODE_DEPTH_STENCIL_1D;
+*stencil_tile_mode = SI_TILE_MODE_DEPTH_STENCIL_1D;
}
if (surf->flags & RADEON_SURF_ZBUFFER) {
-if (surf_man->family >= CHIP_BONAIRE)
-*tile_mode = CIK_TILE_MODE_DEPTH_STENCIL_1D;
-else
-*tile_mode = SI_TILE_MODE_DEPTH_STENCIL_1D;
+*tile_mode = SI_TILE_MODE_DEPTH_STENCIL_1D;
} else if (surf->flags & RADEON_SURF_SCANOUT) {
*tile_mode = SI_TILE_MODE_COLOR_1D_SCANOUT;
} else {
@@ -1788,6 +1786,604 @@ static int si_surface_best(struct
radeon_surface_manager *surf_man,
/* ===
+ * Sea Islands family
+ */
+#define CIK__GB_TILE_MODE__PIPE_CONFIG(x)(((x) >> 6) & 0x1f)
+#define CIK__PIPE_CONFIG__ADDR_SURF_P2 0
+#define CIK__PIPE_CONFIG__ADDR_SURF_P4_8x16 4
+#define CIK__PIPE_CONFIG__ADDR_SURF_P4_16x16 5
+#define CIK__PIPE_CONFIG__ADDR_SURF_P4_16x32 6
+#define CIK__PIPE_CONFIG__ADDR_SURF_P4_32x32 7
+#define CIK__PIPE_CONFIG__ADDR_SURF_P8_16x16_8x168
+#define CIK__PIPE_CONFIG__ADDR_SURF_P8_16x32_8x169
+#define CIK__PIPE_CONFIG__ADDR_SURF_P8_32x32_8x1610
+#define CIK__PIPE_CONFIG__ADDR_SURF_P8_16x32_16x16 11
+#define CIK__PIPE_CONFIG__ADDR_SURF_P8_32x32_16x16 12
+#define CIK__PIPE_CONFIG__ADDR_SURF_P8_32x32_16x32 13
+#define CIK__PIPE_CONFIG__ADDR_SURF_P8_32x64_32x32 14
+#define CIK__GB_TILE_MODE__TILE_SPLIT(x) (((x) >> 11) & 0x7)
+#define CIK__TILE_SPLIT__64B 0
+#define CIK__TILE_SPLIT__128B1
+#define CIK__TILE_SPLIT__256B2
+#define CIK__TILE_SPLIT__512B3
+#define CIK__TILE_SPLIT__1024B 4
+#define CIK__TILE_SPLIT__2048B 5
+#define CIK__TILE_SPLIT__4096B 6
+#define CIK__GB_TILE_MODE__SAMPLE_SPLIT(x) (((x) >> 25) & 0x3)
+#define CIK__SAMPLE_SPLIT__1 0
+#define CIK__SAMPLE_SPLIT__2 1
+#define CIK__SAMPLE_SPLIT__4 2
+#define CIK__SAMPLE_SPLIT__8 3
+#define CIK__GB_MACROTILE_MODE__BANK_WIDTH(x)((x) & 0x3)
+#define CIK__BANK_WIDTH__1 0
+#define CIK__BANK_WIDTH__2
[PATCH 1/2] radeon: fix mipmap level 0 and 1 alignment for SI and CIK
From: Michel D?nzer
Signed-off-by: Marek Ol??k
---
radeon/radeon_surface.c | 27 +--
1 file changed, 13 insertions(+), 14 deletions(-)
diff --git a/radeon/radeon_surface.c b/radeon/radeon_surface.c
index d5c45c4..56e2e4a 100644
--- a/radeon/radeon_surface.c
+++ b/radeon/radeon_surface.c
@@ -1540,6 +1540,7 @@ static int si_surface_init_1d(struct
radeon_surface_manager *surf_man,
uint64_t offset, unsigned start_level)
{
uint32_t xalign, yalign, zalign, slice_align;
+unsigned alignment = MAX2(256, surf_man->hw_info.group_bytes);
unsigned i;
/* compute alignment */
@@ -1551,11 +1552,11 @@ static int si_surface_init_1d(struct
radeon_surface_manager *surf_man,
xalign = MAX2((bpe == 1) ? 64 : 32, xalign);
}
-if (!start_level) {
-surf->bo_alignment = MAX2(256, surf_man->hw_info.group_bytes);
+if (start_level <= 1) {
+surf->bo_alignment = MAX2(surf->bo_alignment, alignment);
if (offset) {
-offset = ALIGN(offset, surf->bo_alignment);
+offset = ALIGN(offset, alignment);
}
}
@@ -1566,7 +1567,7 @@ static int si_surface_init_1d(struct
radeon_surface_manager *surf_man,
/* level0 and first mipmap need to have alignment */
offset = surf->bo_size;
if ((i == 0)) {
-offset = ALIGN(offset, surf->bo_alignment);
+offset = ALIGN(offset, alignment);
}
if (surf->flags & RADEON_SURF_HAS_TILE_MODE_INDEX) {
if (surf->level == level) {
@@ -1608,6 +1609,7 @@ static int si_surface_init_2d(struct
radeon_surface_manager *surf_man,
uint64_t offset,
unsigned start_level)
{
+uint64_t aligned_offset = offset;
unsigned tilew, tileh, tileb;
unsigned mtilew, mtileh, mtileb;
unsigned slice_pt;
@@ -1631,19 +1633,19 @@ static int si_surface_init_2d(struct
radeon_surface_manager *surf_man,
/* macro tile bytes */
mtileb = (mtilew / tilew) * (mtileh / tileh) * tileb;
-if (!start_level) {
+if (start_level <= 1) {
unsigned alignment = MAX2(256, mtileb);
surf->bo_alignment = MAX2(surf->bo_alignment, alignment);
-if (offset) {
-offset = ALIGN(offset, alignment);
+if (aligned_offset) {
+aligned_offset = ALIGN(aligned_offset, alignment);
}
}
/* build mipmap tree */
for (i = start_level; i <= surf->last_level; i++) {
level[i].mode = RADEON_SURF_MODE_2D;
-si_surf_minify_2d(surf, level+i, bpe, i, slice_pt, mtilew, mtileh, 1,
mtileb, offset);
+si_surf_minify_2d(surf, level+i, bpe, i, slice_pt, mtilew, mtileh, 1,
mtileb, aligned_offset);
if (level[i].mode == RADEON_SURF_MODE_1D) {
switch (tile_mode) {
case SI_TILE_MODE_COLOR_2D_8BPP:
@@ -1657,10 +1659,7 @@ static int si_surface_init_2d(struct
radeon_surface_manager *surf_man,
tile_mode = SI_TILE_MODE_COLOR_1D_SCANOUT;
break;
case SI_TILE_MODE_DEPTH_STENCIL_2D:
-if (surf_man->family >= CHIP_BONAIRE)
-tile_mode = CIK_TILE_MODE_DEPTH_STENCIL_1D;
-else
-tile_mode = SI_TILE_MODE_DEPTH_STENCIL_1D;
+tile_mode = SI_TILE_MODE_DEPTH_STENCIL_1D;
break;
default:
return -EINVAL;
@@ -1668,9 +1667,9 @@ static int si_surface_init_2d(struct
radeon_surface_manager *surf_man,
return si_surface_init_1d(surf_man, surf, level, bpe, tile_mode,
offset, i);
}
/* level0 and first mipmap need to have alignment */
-offset = surf->bo_size;
+aligned_offset = surf->bo_size;
if ((i == 0)) {
-offset = ALIGN(offset, surf->bo_alignment);
+aligned_offset = ALIGN(aligned_offset, surf->bo_alignment);
}
if (surf->flags & RADEON_SURF_HAS_TILE_MODE_INDEX) {
if (surf->level == level) {
--
1.8.3.2
[Bug 24611] KMS: Plugging in only S-video locks up machine
https://bugs.freedesktop.org/show_bug.cgi?id=24611 Alex Deucher changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131115/c5b182e6/attachment.html>
[Bug 71647] radeonsi purple tinted colors
https://bugs.freedesktop.org/show_bug.cgi?id=71647 --- Comment #2 from Tom Stellard --- Can you bisect this? It's possible that this commit is responsible: R600/SI: Prefer SALU instructions for bit shift operations All shift operations will be selected as SALU instructions and then if necessary lowered to VALU instructions in the SIFixSGPRCopies pass. This allows us to do more operations on the SALU which will improve performance and is also required for implementing private memory using indirect addressing, since the private memory pointers must stay in the scalar registers. This patch includes some fixes from Matt Arsenault. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk at 194625 91177308-0d34-0410-b5e6-96231b3b80d8 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131115/6d9d62e8/attachment.html>
[Bug 71647] radeonsi purple tinted colors
https://bugs.freedesktop.org/show_bug.cgi?id=71647 Nils Larsson changed: What|Removed |Added Attachment #89277|text/plain |image/png mime type|| -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131115/8a913c19/attachment.html>
[Bug 71647] radeonsi purple tinted colors
https://bugs.freedesktop.org/show_bug.cgi?id=71647 --- Comment #1 from Nils Larsson --- Created attachment 89277 --> https://bugs.freedesktop.org/attachment.cgi?id=89277&action=edit Screenshot of KDE with purple colors. I get this too. Git version from today(15/11) of libdrm, mesa, xorg-server, glamor and xf86-video-ati. Kernel is 3.12.0. Hardware is Radeon HD 7850. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131115/ce28110e/attachment-0001.html>
possible regression Radeon RV280 (R3xx/R4xx ?) card freeze, re-apply old patch ?
On Fre, 2013-11-15 at 08:49 +0100, Jochen Rollwagen wrote: > I think there are two issues here: the first is the missing alignment > workaround, since i'll be upgrading to 3.4.69 anyway i'll insert some > diagnostic messages in radeon_device.c and see what happens. Yes, please do that before speculating more about the problem. > But i'm pretty certain now that this isn't the cause for the lockups. > They are probably (quite certainly) caused by the dynamic > binding/unbinding of AGP memory which the Uninorth chipset used in > 32-bit powermacs obviously doesn't support. "doesn't support" is too strong; it's working fine on this PowerBook5,8. But the older the revision of UniNorth, the more quirks. > All it supports seems to be statically allocating a 256 MB contigouous > non-cacheable AGP aperture and using that (since the chipset doesn't > do any address mapping via the GART as indicated in the OpenBSD code). It does address mapping for the GPU, that's the whole point of the GART. What UniNorth doesn't do in contrast to most AGP bridges is provide a linear aperture to the CPU as well. But that shouldn't be an issue per se. > So to get AGP mode working again on those machines one would have to > disable the dynamic memory stuff. Question: Would that require changes > in the driver only or also in the DRM ? It's not really possible with radeon KMS. -- Earthling Michel D?nzer| http://www.amd.com Libre software enthusiast |Mesa and X developer
[PATCH 16/51] DMA-API: ppc: vio.c: replace dma_set_mask()+dma_set_coherent_mask() with new helper
Hi, On 09/19/2013 11:41 PM, Russell King wrote: > Replace the following sequence: > > dma_set_mask(dev, mask); > dma_set_coherent_mask(dev, mask); > > with a call to the new helper dma_set_mask_and_coherent(). > > Signed-off-by: Russell King > --- > arch/powerpc/kernel/vio.c |3 +-- > 1 files changed, 1 insertions(+), 2 deletions(-) > > diff --git a/arch/powerpc/kernel/vio.c b/arch/powerpc/kernel/vio.c > index 78a3506..96b6c97 100644 > --- a/arch/powerpc/kernel/vio.c > +++ b/arch/powerpc/kernel/vio.c > @@ -1413,8 +1413,7 @@ struct vio_dev *vio_register_device_node(struct > device_node *of_node) > > /* needed to ensure proper operation of coherent allocations >* later, in case driver doesn't set it explicitly */ > - dma_set_mask(&viodev->dev, DMA_BIT_MASK(64)); > - dma_set_coherent_mask(&viodev->dev, DMA_BIT_MASK(64)); > + dma_set_mask_and_coherent(&viodev->dev, DMA_BIT_MASK(64)); > } > > /* register with generic device framework */ > The new helper routine dma_set_mask_and_coherent() breaks the initialization of the pseries vio devices which do not have an initial dev->dma_mask. I think we need to use dma_coerce_mask_and_coherent() instead. Signed-off-by: C?dric Le Goater --- arch/powerpc/kernel/vio.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/powerpc/kernel/vio.c b/arch/powerpc/kernel/vio.c index e7d0c88f..76a6482 100644 --- a/arch/powerpc/kernel/vio.c +++ b/arch/powerpc/kernel/vio.c @@ -1419,7 +1419,7 @@ struct vio_dev *vio_register_device_node(struct device_node *of_node) /* needed to ensure proper operation of coherent allocations * later, in case driver doesn't set it explicitly */ - dma_set_mask_and_coherent(&viodev->dev, DMA_BIT_MASK(64)); + dma_coerce_mask_and_coherent(&viodev->dev, DMA_BIT_MASK(64)); } /* register with generic device framework */ -- 1.7.10.4
[Bug 24611] KMS: Plugging in only S-video locks up machine
https://bugs.freedesktop.org/show_bug.cgi?id=24611 --- Comment #17 from Pierre Ossman --- You can probably close this bug as I have no intention of ever using S-video ever again. :) -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131115/990e162f/attachment.html>
[Bug 31682] Radeon console output very slow with kms
https://bugzilla.kernel.org/show_bug.cgi?id=31682 --- Comment #7 from Alan --- You only need to use the GART trick if you might not have enough memory to allocate twice the memory needed for the framebuffer. If you can afford the memory then allocate two copies and write each text blit into both. Then just change the start of the scan out as needed. It's even faster than the GMA500 GART trick! Alan -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH 4/4] drm: exynos: hdmi: Add dt support for hdmiphy settings
On Tue, Oct 29, 2013 at 08:12:32AM +, Shirish S wrote: > This patch adds dt support to hdmiphy config settings > as it is board specific and depends on the signal pattern > of board. > > Signed-off-by: Shirish S > --- > .../devicetree/bindings/video/exynos_hdmi.txt | 34 + > drivers/gpu/drm/exynos/exynos_hdmi.c | 79 > +++- > 2 files changed, 109 insertions(+), 4 deletions(-) > > diff --git a/Documentation/devicetree/bindings/video/exynos_hdmi.txt > b/Documentation/devicetree/bindings/video/exynos_hdmi.txt > index 323983b..c685c90 100644 > --- a/Documentation/devicetree/bindings/video/exynos_hdmi.txt > +++ b/Documentation/devicetree/bindings/video/exynos_hdmi.txt > @@ -13,6 +13,32 @@ Required properties: > b) pin number within the gpio controller. > c) optional flags and pull up/down. > > +- hdmiphy-configs: following information about the hdmiphy config settings. > +a) "nr-configs" specifies the number of pixel clocks supported. I really don't see why this is necessary. It's redundant, and it's easy for the driver to derive this from the number of config nodes, which it can count. > + b) "config: config" specifies the phy configuration settings, > + wher 'N' denotes the number of iteration. The number of iteration? > + "pixel-clock" specifies the pixel clock > + "conifig-de-emphasis-level" specifies the 8 bit configuration > + of Data De-emphasis levels,below shown is example for > + data de-emphasis register at address 0x145D0040. > + hdmiphy at 38[16] for bits[3:0] permitted values: > + means 760 mVdiff && means 1400 mVdiff > + 1LSB corresponds to 20mVdiff > + hdmiphy at 38[16] for bits[7:4] permitted values: > + 0dB > + 0001-0.25dB > + 0010-0.7dB > + 0011-1.15dB > + -7.45dB > + "config-clock-level" specifies the 8 bit configuration for > + the corresponding clock level, for example if 0x145D005C > + is the address of clock level register. I don't understand what this intended to mean. > + hdmiphy at 38[23] for bits [1:0] permitted values: > + 00 means 0 mVdiff && 11 means 60 mVdiff > + hdmiphy at 38[23] for bits [7:3] permitted values: > + 0 is 790 mVdiff > + 1 is 1430 mVdiff > + 1LSB corresponds to 20mVdiff That last line was confusing. Why not state that this is a value between 790 and 1430 mV in 20mV increments? Thanks, Mark.
[pull] radeon fixes 3.13
Hi Dave, Some fixes for radeon for 3.13. Mostly CI stability fixes. I think I've tracked down the stability problems with dpm on Trinity/Richland, so I'm going to enable that by default now. The following changes since commit a3483353ca4e6dbeef2ed62ebed01af109b5b27a: drm: check for !kdev in drm_unplug_minor() (2013-11-15 20:49:02 +1000) are available in the git repository at: git://people.freedesktop.org/~agd5f/linux drm-next-3.13 for you to fetch changes up to 3a118989d58ca9b99f56f16a6fccbe34a9d8047e: drm/radeon: enable DPM by default in TN asics (2013-11-15 15:57:38 -0500) Alex Deucher (4): drm/radeon: cypress_dpm: Fix unused variable warning when CONFIG_ACPI=n drm/radeon/vm: don't attempt to update ptes if ib allocation fails drm/radeon: adjust TN dpm parameters for stability (v2) drm/radeon: enable DPM by default in TN asics Andrew Lewycky (1): drm/radeon: use a single doorbell for cik kms compute Christian K?nig (3): drm/radeon: add semaphore trace point drm/radeon: allow semaphore emission to fail drm/radeon: disable CIK CP semaphores for now Fabio Estevam (1): drm: radeon: ni_dpm: Fix unused variable warning when CONFIG_ACPI=n Jerome Glisse (2): radeon/i2c: do not count reg index in number of i2c byte we are writing. radeon: workaround pinning failure on low ram gpu drivers/gpu/drm/radeon/atombios_i2c.c | 6 +- drivers/gpu/drm/radeon/cik.c| 54 ++-- drivers/gpu/drm/radeon/cik_sdma.c | 13 ++- drivers/gpu/drm/radeon/cypress_dpm.c| 2 + drivers/gpu/drm/radeon/evergreen_dma.c | 9 +- drivers/gpu/drm/radeon/ni_dpm.c | 2 +- drivers/gpu/drm/radeon/r100.c | 3 +- drivers/gpu/drm/radeon/r600.c | 13 ++- drivers/gpu/drm/radeon/r600_dma.c | 13 ++- drivers/gpu/drm/radeon/radeon.h | 37 drivers/gpu/drm/radeon/radeon_asic.h| 18 ++-- drivers/gpu/drm/radeon/radeon_cs.c | 9 +- drivers/gpu/drm/radeon/radeon_device.c | 47 +- drivers/gpu/drm/radeon/radeon_fence.c | 30 +++ drivers/gpu/drm/radeon/radeon_gart.c| 6 +- drivers/gpu/drm/radeon/radeon_legacy_crtc.c | 28 ++ drivers/gpu/drm/radeon/radeon_pm.c | 2 +- drivers/gpu/drm/radeon/radeon_ring.c| 46 +++--- drivers/gpu/drm/radeon/radeon_semaphore.c | 129 +--- drivers/gpu/drm/radeon/radeon_trace.h | 36 drivers/gpu/drm/radeon/rv770_dma.c | 9 +- drivers/gpu/drm/radeon/si_dma.c | 9 +- drivers/gpu/drm/radeon/trinity_dpm.c| 6 +- drivers/gpu/drm/radeon/uvd_v1_0.c | 4 +- drivers/gpu/drm/radeon/uvd_v3_1.c | 4 +- 25 files changed, 324 insertions(+), 211 deletions(-)
[RESEND PATCH] drm/radeon: Don't limit fb console on 32M cards to 8 bpp
The comment suggests that intention was to limit 16M cards to save memory while code did something a bit different. 32bpp is a lot more useful with today's apps, such as Weston's fbdev backend and 32M cards are probably hardly used in apps where dedicating a bit more to pinned console would matter. Signed-off-by: Lubomir Rintel --- drivers/gpu/drm/radeon/radeon_fb.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_fb.c b/drivers/gpu/drm/radeon/radeon_fb.c index 665ced3..cef3bc7 100644 --- a/drivers/gpu/drm/radeon/radeon_fb.c +++ b/drivers/gpu/drm/radeon/radeon_fb.c @@ -344,7 +344,7 @@ int radeon_fbdev_init(struct radeon_device *rdev) int ret; /* select 8 bpp console on RN50 or 16MB cards */ - if (ASIC_IS_RN50(rdev) || rdev->mc.real_vram_size <= (32*1024*1024)) + if (ASIC_IS_RN50(rdev) || rdev->mc.real_vram_size <= (16*1024*1024)) bpp_sel = 8; rfbdev = kzalloc(sizeof(struct radeon_fbdev), GFP_KERNEL); -- 1.7.1
[Bug 31682] Radeon console output very slow with kms
https://bugzilla.kernel.org/show_bug.cgi?id=31682 J?r?me Glisse changed: What|Removed |Added CC||glisse at freedesktop.org --- Comment #6 from J?r?me Glisse --- We can not do the GART trick on radeon, radeon is using dedicated VRAM and not scaning out from system memory mapped through a gart. (Well we could do GART trick on newer GPU that has virtual address space where we can remap the VRAM with a GART but anybody with such a GPU that is using fbdev as others more serious personal issues) -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH 2/2] drm/i915/dp: check eDP display control capability registers
Debug print the capabilities, and flag an error if the panel does not
support adjusting backlight through the BL_PWM_DIM pin, requiring
backlight control through DPCD.
I haven't seen such panels yet, but it's a matter of time. Give
ourselves a reminder when we need to fix this for real.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dp.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index cbf33be..ea4f3d1 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -2816,6 +2816,20 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
dev_priv->psr.sink_support = true;
DRM_DEBUG_KMS("Detected EDP PSR Panel.\n");
}
+
+ if (intel_dp->dpcd[DP_EDP_CONFIGURATION_CAP] &
+ DP_DPCD_DISPLAY_CONTROL_CAP) {
+ u8 ctrl[4] = { 0 };
+
+ intel_dp_aux_native_read(intel_dp, DP_EDP_REV,
+ctrl, sizeof(ctrl));
+ DRM_DEBUG_KMS("eDP DPCD CTRL %02x %02x %02x %02x\n",
+ ctrl[0], ctrl[1], ctrl[2], ctrl[3]);
+
+ /* We don't support DPCD backlight control yet. */
+ if (ctrl[0] && (ctrl[1] & 1) && !(ctrl[2] & 1))
+ DRM_ERROR("eDP AUX backlight control only\n");
+ }
}
if (!(intel_dp->dpcd[DP_DOWNSTREAMPORT_PRESENT] &
--
1.7.9.5
[PATCH 1/2] drm/dp: add eDP 1.2 display control DPCD register definitions
Preparing for the future eDP panels. Signed-off-by: Jani Nikula --- include/drm/drm_dp_helper.h | 29 + 1 file changed, 29 insertions(+) diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h index a92c375..e2dbde6 100644 --- a/include/drm/drm_dp_helper.h +++ b/include/drm/drm_dp_helper.h @@ -100,6 +100,9 @@ # define DP_I2C_SPEED_1M 0x20 #define DP_EDP_CONFIGURATION_CAP0x00d /* XXX 1.2? */ +# define DP_ALTERNATE_SCRAMBLER_RESET_CAP (1 << 0) +# define DP_FRAMING_CHANGE_CAP (1 << 1) +# define DP_DPCD_DISPLAY_CONTROL_CAP(1 << 3) /* eDP 1.2 */ #define DP_TRAINING_AUX_RD_INTERVAL 0x00e /* XXX 1.2? */ /* Multiple stream transport */ @@ -291,6 +294,32 @@ # define DP_SET_POWER_D00x1 # define DP_SET_POWER_D30x2 +#define DP_EDP_REV 0x700 /* eDP 1.2 */ + +#define DP_EDP_GENERAL_CAPABILITY_REGISTER_1 0x701 +#define DP_EDP_BACKLIGHT_ADJUSTMENT_CAPABILITY_REGISTER0x702 +#define DP_EDP_GENERAL_CAPABILITY_REGISTER_2 0x703 + +#define DP_EDP_DISPLAY_CONTROL_REGISTER 0x720 +#define DP_EDP_BACKLIGHT_MODE_SET_REGISTER 0x721 +#define DP_EDP_BACKLIGHT_BRIGHTNESS_MSB 0x722 +#define DP_EDP_BACKLIGHT_BRIGHTNESS_LSB 0x723 +#define DP_EDP_PWMGEN_BIT_COUNT 0x724 +#define DP_EDP_PWMGEN_BIT_COUNT_CAP_MIN 0x725 +#define DP_EDP_PWMGEN_BIT_COUNT_CAP_MAX 0x726 +#define DP_EDP_BACKLIGHT_CONTROL_STATUS 0x727 +#define DP_EDP_BACKLIGHT_FREQ_SET 0x728 + +#define DP_EDP_BACKLIGHT_FREQ_CAP_MIN_MSB 0x72a +#define DP_EDP_BACKLIGHT_FREQ_CAP_MIN_MID 0x72b +#define DP_EDP_BACKLIGHT_FREQ_CAP_MIN_LSB 0x72c +#define DP_EDP_BACKLIGHT_FREQ_CAP_MAX_MSB 0x72d +#define DP_EDP_BACKLIGHT_FREQ_CAP_MAX_MID 0x72e +#define DP_EDP_BACKLIGHT_FREQ_CAP_MAX_LSB 0x72f + +#define DP_EDP_DBC_MINIMUM_BRIGHTNESS_SET 0x732 +#define DP_EDP_DBC_MAXIMUM_BRIGHTNESS_SET 0x733 + #define DP_PSR_ERROR_STATUS 0x2006 /* XXX 1.2? */ # define DP_PSR_LINK_CRC_ERROR (1 << 0) # define DP_PSR_RFB_STORAGE_ERROR (1 << 1) -- 1.7.9.5
[Bug 71647] radeonsi purple tinted colors
https://bugs.freedesktop.org/show_bug.cgi?id=71647 Tom changed: What|Removed |Added Attachment #89275|text/plain |image/jpeg mime type|| -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131115/24b8ba83/attachment.html>
[Bug 71647] New: radeonsi purple tinted colors
https://bugs.freedesktop.org/show_bug.cgi?id=71647 Priority: medium Bug ID: 71647 Assignee: dri-devel at lists.freedesktop.org Summary: radeonsi purple tinted colors Severity: normal Classification: Unclassified OS: All Reporter: neatnoise at gmail.com Hardware: Other Status: NEW Version: git Component: Drivers/Gallium/radeonsi Product: Mesa Created attachment 89275 --> https://bugs.freedesktop.org/attachment.cgi?id=89275&action=edit screenshot Hello, I can see purple tinted desktop since I think yesterday or 2 days ago. Packages which I've updated: media-libs/mesa git sys-devel/llvm git x11-libs/libdrm git x11-libs/glamor git x11-drivers/xf86-video-ati git x11-base/xorg-server 1.14.3 Linux Kernel: linux-next -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131115/99de5c9c/attachment.html>
[PATCH 10/31] ARM: tegra: pass reset to tegra_powergate_sequence_power_up()
On Fri, Nov 15, 2013 at 1:54 PM, Stephen Warren
wrote:
> From: Stephen Warren
>
> Tegra's clock driver now provides an implementation of the common
> reset API (include/linux/reset.h). Use this instead of the old Tegra-
> specific API; that will soon be removed.
>
> Cc: treding at nvidia.com
> Cc: pdeschrijver at nvidia.com
> Cc: linux-tegra at vger.kernel.org
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: Bjorn Helgaas
> Cc: linux-pci at vger.kernel.org
> Cc: Terje Bergstr?m
> Cc: David Airlie
> Cc: dri-devel at lists.freedesktop.org
> Signed-off-by: Stephen Warren
Acked-by: Bjorn Helgaas
> ---
> This patch is part of a series with strong internal depdendencies. I'm
> looking for an ack so that I can take the entire series through the Tegra
> and arm-soc trees. The series will be part of a stable branch that can be
> merged into other subsystems if needed to avoid/resolve dependencies.
> ---
> arch/arm/mach-tegra/powergate.c | 8 +---
> drivers/gpu/drm/tegra/gr3d.c| 6 --
> drivers/pci/host/pci-tegra.c| 3 ++-
> include/linux/tegra-powergate.h | 4 +++-
> 4 files changed, 14 insertions(+), 7 deletions(-)
>
> diff --git a/arch/arm/mach-tegra/powergate.c b/arch/arm/mach-tegra/powergate.c
> index 85d28e756bb7..f6f5b54ff95e 100644
> --- a/arch/arm/mach-tegra/powergate.c
> +++ b/arch/arm/mach-tegra/powergate.c
> @@ -25,6 +25,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -144,11 +145,12 @@ int tegra_powergate_remove_clamping(int id)
> }
>
> /* Must be called with clk disabled, and returns with clk enabled */
> -int tegra_powergate_sequence_power_up(int id, struct clk *clk)
> +int tegra_powergate_sequence_power_up(int id, struct clk *clk,
> + struct reset_control *rst)
> {
> int ret;
>
> - tegra_periph_reset_assert(clk);
> + reset_control_assert(rst);
>
> ret = tegra_powergate_power_on(id);
> if (ret)
> @@ -165,7 +167,7 @@ int tegra_powergate_sequence_power_up(int id, struct clk
> *clk)
> goto err_clamp;
>
> udelay(10);
> - tegra_periph_reset_deassert(clk);
> + reset_control_deassert(rst);
>
> return 0;
>
> diff --git a/drivers/gpu/drm/tegra/gr3d.c b/drivers/gpu/drm/tegra/gr3d.c
> index f629e38b00e4..0cbb24b1ae04 100644
> --- a/drivers/gpu/drm/tegra/gr3d.c
> +++ b/drivers/gpu/drm/tegra/gr3d.c
> @@ -279,7 +279,8 @@ static int gr3d_probe(struct platform_device *pdev)
> }
> }
>
> - err = tegra_powergate_sequence_power_up(TEGRA_POWERGATE_3D,
> gr3d->clk);
> + err = tegra_powergate_sequence_power_up(TEGRA_POWERGATE_3D, gr3d->clk,
> + gr3d->rst);
> if (err < 0) {
> dev_err(&pdev->dev, "failed to power up 3D unit\n");
> return err;
> @@ -287,7 +288,8 @@ static int gr3d_probe(struct platform_device *pdev)
>
> if (gr3d->clk_secondary) {
> err = tegra_powergate_sequence_power_up(TEGRA_POWERGATE_3D1,
> - gr3d->clk_secondary);
> + gr3d->clk_secondary,
> + gr3d->rst_secondary);
> if (err < 0) {
> dev_err(&pdev->dev,
> "failed to power up secondary 3D unit\n");
> diff --git a/drivers/pci/host/pci-tegra.c b/drivers/pci/host/pci-tegra.c
> index 174a5bc2d993..aace19edc469 100644
> --- a/drivers/pci/host/pci-tegra.c
> +++ b/drivers/pci/host/pci-tegra.c
> @@ -956,7 +956,8 @@ static int tegra_pcie_power_on(struct tegra_pcie *pcie)
> }
>
> err = tegra_powergate_sequence_power_up(TEGRA_POWERGATE_PCIE,
> - pcie->pex_clk);
> + pcie->pex_clk,
> + pcie->pex_rst);
> if (err) {
> dev_err(pcie->dev, "powerup sequence failed: %d\n", err);
> return err;
> diff --git a/include/linux/tegra-powergate.h b/include/linux/tegra-powergate.h
> index c98cfa406952..b5ad64aca071 100644
> --- a/include/linux/tegra-powergate.h
> +++ b/include/linux/tegra-powergate.h
> @@ -19,6 +19,7 @@
> #define _MACH_TEGRA_POWERGATE_H_
>
> struct clk;
> +struct reset_control;
>
> #define TEGRA_POWERGATE_CPU0
> #define TEGRA_POWERGATE_3D 1
> @@ -51,6 +52,7 @@ int tegra_powergate_power_off(int id);
> int tegra_powergate_remove_clamping(int id);
>
> /* Must be called with clk disabled, and returns with clk enabled */
> -int tegra_powergate_sequence_power_up(int id, struct clk *clk);
> +int tegra_powergate_sequence_power_up(int id, struct clk *clk,
> + struct reset_control *rst);
>
> #endif /* _MACH_TEGRA_POWERGATE_H_ */
> --
> 1.8.1.5
>
[PATCH v2] ACPI / video: Add systems that should favor native backlight interface
Some system's ACPI video backlight control interface is broken and the
native backlight control interface should be used by default. This patch
sets the use_native_backlight parameter to true for those systems so
that video backlight control interface will not be created. To be
specific, the ThinkPad T430s/X230, Lenovo Yoga 13, Dell Inspiron 7520
and Acer Aspire 5733Z are added here, if they appear in some other DMI
table before, they are removed from there.
Note that the user specified kernel cmdline option will always have the
highest priority, i.e. if use_native_backlight=0 is specified and the
system is in the DMI table, the video module will not skip registering
backlight interface for it.
Thinkpad T430s:
Reported-by: Theodore Tso
Reported-and-tested-by: Peter Weber
Reference: https://bugzilla.kernel.org/show_bug.cgi?id=51231
Thinkpad X230:
Reported-and-tested-by: Igor Gnatenko
Reference: https://bugzilla.kernel.org/show_bug.cgi?id=51231
Lenovo Yoga 13:
Reported-by: Lennart Poettering
Reported-and-tested-by: Kevin Smith
Reference: https://bugzilla.kernel.org/show_bug.cgi?id=63811
Dell Inspiron 7520:
Reported-by: Rinat Ibragimov
Acer Aspire 5733Z:
Reported-by:
Reference: https://bugzilla.kernel.org/show_bug.cgi?id=62941
Signed-off-by: Aaron Lu
---
v2:
Add Acer Aspire 5733Z, see bug #62941;
Remove Inspiron 7520 from acpi_osi_dmi_table and Yoga 13 from
video_detect_dmi_table.
Based on top of Rafael's linux-next branch + the following patch:
[PATCH] ACPI / video: clean up DMI table for initial black screen problem
http://marc.info/?l=linux-acpi&m=138448583006432&w=2
drivers/acpi/blacklist.c| 8 --
drivers/acpi/video.c| 65 +
drivers/acpi/video_detect.c | 8 --
3 files changed, 60 insertions(+), 21 deletions(-)
diff --git a/drivers/acpi/blacklist.c b/drivers/acpi/blacklist.c
index 078c4f7fe2dd..2b6a76b6d59a 100644
--- a/drivers/acpi/blacklist.c
+++ b/drivers/acpi/blacklist.c
@@ -261,14 +261,6 @@ static struct dmi_system_id acpi_osi_dmi_table[]
__initdata = {
},
{
.callback = dmi_disable_osi_win8,
- .ident = "Dell Inspiron 15R SE",
- .matches = {
-DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
-DMI_MATCH(DMI_PRODUCT_NAME, "Inspiron 7520"),
- },
- },
- {
- .callback = dmi_disable_osi_win8,
.ident = "ThinkPad Edge E530",
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
diff --git a/drivers/acpi/video.c b/drivers/acpi/video.c
index 4ccb89e5c4ad..49abe0348b03 100644
--- a/drivers/acpi/video.c
+++ b/drivers/acpi/video.c
@@ -89,11 +89,12 @@ static bool use_bios_initial_backlight = 1;
module_param(use_bios_initial_backlight, bool, 0644);
/*
- * For Windows 8 systems: if set ture and the GPU driver has
- * registered a backlight interface, skip registering ACPI video's.
+ * For Windows 8 systems: used to decide if video module
+ * should skip registering backlight interface of its own.
*/
-static bool use_native_backlight = false;
-module_param(use_native_backlight, bool, 0644);
+static int use_native_backlight_param = -1;
+module_param_named(use_native_backlight, use_native_backlight_param, int,
0444);
+static bool use_native_backlight_dmi = false;
static int register_count;
static struct mutex video_list_lock;
@@ -239,9 +240,17 @@ static int acpi_video_get_next_level(struct
acpi_video_device *device,
static int acpi_video_switch_brightness(struct acpi_video_device *device,
int event);
+static bool acpi_video_use_native_backlight(void)
+{
+ if (use_native_backlight_param != -1)
+ return !!use_native_backlight_param;
+ else
+ return use_native_backlight_dmi;
+}
+
static bool acpi_video_verify_backlight_support(void)
{
- if (acpi_osi_is_win8() && use_native_backlight &&
+ if (acpi_osi_is_win8() && acpi_video_use_native_backlight() &&
backlight_device_registered(BACKLIGHT_RAW))
return false;
return acpi_video_backlight_support();
@@ -412,6 +421,12 @@ static int video_ignore_initial_backlight(const struct
dmi_system_id *d)
return 0;
}
+static int __init video_set_use_native_backlight(const struct dmi_system_id *d)
+{
+ use_native_backlight_dmi = true;
+ return 0;
+}
+
static struct dmi_system_id video_dmi_table[] __initdata = {
/*
* Broken _BQC workaround
http://bugzilla.kernel.org/show_bug.cgi?id=13121
@@ -456,6 +471,46 @@ static struct dmi_system_id video_dmi_table[] __initdata =
{
DMI_MATCH(DMI_PRODUCT_NAME, "Aspire 7720"),
},
},
+ {
+.callback = video_set_use_native_backlight,
+.ident = "ThinkPad T430s",
+.matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+ DMI_MATCH(DMI_PRODUCT_VERSION, "ThinkPad T430s"),
+
[PATCH 2/2] radeon: implement 2D tiling for CIK
On Fri, Nov 15, 2013 at 12:55 PM, Marek Ol??k wrote:
> From: Michel D?nzer
>
> Bug fixes and simplification by Marek.
> We have to use the tile index of 0 for non-MSAA depth-stencil after all.
>
> Signed-off-by: Marek Ol??k
> ---
> include/drm/radeon_drm.h | 11 +
> radeon/radeon_surface.c | 620
> ++-
> radeon/radeon_surface.h | 1 +
> 3 files changed, 623 insertions(+), 9 deletions(-)
>
> diff --git a/include/drm/radeon_drm.h b/include/drm/radeon_drm.h
> index d1bebf5..96ea555 100644
> --- a/include/drm/radeon_drm.h
> +++ b/include/drm/radeon_drm.h
> @@ -979,6 +979,10 @@ struct drm_radeon_cs {
> #define RADEON_INFO_RING_WORKING 0x15
> /* SI tile mode array */
> #define RADEON_INFO_SI_TILE_MODE_ARRAY 0x16
> +/* query if CP DMA is supported on the compute ring */
> +#define RADEON_INFO_SI_CP_DMA_COMPUTE 0x17
> +/* CIK macrotile mode array */
> +#define RADEON_INFO_CIK_MACROTILE_MODE_ARRAY 0x18
>
> struct drm_radeon_info {
> uint32_trequest;
> @@ -1004,6 +1008,13 @@ struct drm_radeon_info {
> #define SI_TILE_MODE_DEPTH_STENCIL_2D_4AA 3
> #define SI_TILE_MODE_DEPTH_STENCIL_2D_8AA 2
>
> +#define CIK_TILE_MODE_COLOR_2D 14
> +#define CIK_TILE_MODE_COLOR_2D_SCANOUT 10
> +#define CIK_TILE_MODE_DEPTH_STENCIL_2D_TILESPLIT_64 0
> +#define CIK_TILE_MODE_DEPTH_STENCIL_2D_TILESPLIT_128 1
> +#define CIK_TILE_MODE_DEPTH_STENCIL_2D_TILESPLIT_256 2
> +#define CIK_TILE_MODE_DEPTH_STENCIL_2D_TILESPLIT_512 3
> +#define CIK_TILE_MODE_DEPTH_STENCIL_2D_TILESPLIT_ROW_SIZE 4
> #define CIK_TILE_MODE_DEPTH_STENCIL_1D 5
>
> #endif
> diff --git a/radeon/radeon_surface.c b/radeon/radeon_surface.c
> index 56e2e4a..927a21e 100644
> --- a/radeon/radeon_surface.c
> +++ b/radeon/radeon_surface.c
> @@ -26,6 +26,8 @@
> * Authors:
> * J?r?me Glisse
> */
> +#include
> +#include
> #include
> #include
> #include
> @@ -95,6 +97,8 @@ struct radeon_hw_info {
> unsignedallow_2d;
> /* apply to si */
> uint32_ttile_mode_array[32];
> +/* apply to cik */
> +uint32_tmacrotile_mode_array[16];
> };
>
> struct radeon_surface_manager {
> @@ -1382,16 +1386,10 @@ static int si_surface_sanity(struct
> radeon_surface_manager *surf_man,
> break;
> case RADEON_SURF_MODE_1D:
> if (surf->flags & RADEON_SURF_SBUFFER) {
> -if (surf_man->family >= CHIP_BONAIRE)
> -*stencil_tile_mode = CIK_TILE_MODE_DEPTH_STENCIL_1D;
> -else
> -*stencil_tile_mode = SI_TILE_MODE_DEPTH_STENCIL_1D;
> +*stencil_tile_mode = SI_TILE_MODE_DEPTH_STENCIL_1D;
> }
> if (surf->flags & RADEON_SURF_ZBUFFER) {
> -if (surf_man->family >= CHIP_BONAIRE)
> -*tile_mode = CIK_TILE_MODE_DEPTH_STENCIL_1D;
> -else
> -*tile_mode = SI_TILE_MODE_DEPTH_STENCIL_1D;
> +*tile_mode = SI_TILE_MODE_DEPTH_STENCIL_1D;
> } else if (surf->flags & RADEON_SURF_SCANOUT) {
> *tile_mode = SI_TILE_MODE_COLOR_1D_SCANOUT;
> } else {
> @@ -1788,6 +1786,604 @@ static int si_surface_best(struct
> radeon_surface_manager *surf_man,
>
>
> /*
> ===
> + * Sea Islands family
> + */
> +#define CIK__GB_TILE_MODE__PIPE_CONFIG(x)(((x) >> 6) & 0x1f)
> +#define CIK__PIPE_CONFIG__ADDR_SURF_P2 0
> +#define CIK__PIPE_CONFIG__ADDR_SURF_P4_8x16 4
> +#define CIK__PIPE_CONFIG__ADDR_SURF_P4_16x16 5
> +#define CIK__PIPE_CONFIG__ADDR_SURF_P4_16x32 6
> +#define CIK__PIPE_CONFIG__ADDR_SURF_P4_32x32 7
> +#define CIK__PIPE_CONFIG__ADDR_SURF_P8_16x16_8x168
> +#define CIK__PIPE_CONFIG__ADDR_SURF_P8_16x32_8x169
> +#define CIK__PIPE_CONFIG__ADDR_SURF_P8_32x32_8x1610
> +#define CIK__PIPE_CONFIG__ADDR_SURF_P8_16x32_16x16 11
> +#define CIK__PIPE_CONFIG__ADDR_SURF_P8_32x32_16x16 12
> +#define CIK__PIPE_CONFIG__ADDR_SURF_P8_32x32_16x32 13
> +#define CIK__PIPE_CONFIG__ADDR_SURF_P8_32x64_32x32 14
Hawaii adds 2 P16 pipe formats:
#define ADDR_SURF_P16_32X32_8X16 0x10
#define ADDR_SURF_P16_32X32_16X160x11
Might be worth handling them in this patch or a follow up patch so we
don't forget. Other than that both patches are:
Reviewed-by: Alex Deucher
[PATCH] drm: edid: enable probing and listing of non rb modes
On Fri, 2013-11-15 at 10:38 +0530, Shirish S wrote:
> The current solution checks for the existing RB mode,
> if available in the edid block returns by adding it,
> but does not populate the connector with the modes
> of same resolution but which are non-rb modes.
>
> As a result the probing and listing of non-rb modes can't
> be made, in case the rb mode's pixel clock is not
> supported but non-rb mode is supported.
This is... almost okay.
So the EDID 1.4 spec says that for modes in standard descriptors:
a) if there's a match in DMT, use DMT
b) if there's a range descriptor and it says GTF, use GTF
c) if there's a range descriptor and it says CVT, use CVT
d) if there's no range descriptor, use CVT
But case d) is clearly insane if the sink is EDID 1.3, CVT wasn't a
standard when 1.3 was defined, so the sink may not in fact support CVT
timings. Hence the logic in standard_timing_level().
The other thing the spec says is that if you're using CVT for standard
descriptors that you should use normal blanking instead of reduced.
This is... problematic. If we see 1920x1200 at 60 in a standard descriptor
we almost certainly _don't_ mean normal blanking, because that won't fit
on single-link DVI. And if both the source and the sink support reduced
blanking we should probably prefer it, it's marginally less power
consumption on digital links and marginally better picture quality on
analog links.
So probably what we should do instead is:
- if drm_monitor_supports_rb(), add both normal and reduced blanking
timings for either the DMT or CVT path
- extend drm_connector to also have rb-allowed to match interlace and
doublescan
- fix up all the drivers to indicate rb-allowed (except whatever broken
thing it is you're trying to work around here)
- fix drm_mode_validate_flag and callers to filter out rb modes as
appropriate
Also: CVT dates to 2003. EDID 1.4 was 2006. Any hardware being made in
2013 that can't generate RB timings is going out of its way to be
broken. You should really demand better from your hardware.
> 1. adds "rb" suffix to rb modes.
No. The userspace convention is:
dmt:~% cvt -r 1920 1080
# 1920x1080 59.93 Hz (CVT 2.07M9-R) hsync: 66.59 kHz; pclk: 138.50 MHz
Modeline "1920x1080R" 138.50 1920 1968 2000 2080 1080 1083 1088 +hsync
-vsync
drm_mode_parse_command_line_for_connector() expects the same thing.
Let's be consistent.
> @@ -1621,19 +1621,20 @@ drm_mode_std(struct drm_connector *connector, struct
> edid *edid,
> mode->hdisplay = 1366;
> mode->hsync_start = mode->hsync_start - 1;
> mode->hsync_end = mode->hsync_end - 1;
> - return mode;
> + goto done;
> }
>
> /* check whether it can be found in default mode table */
> if (drm_monitor_supports_rb(edid)) {
> mode = drm_mode_find_dmt(dev, hsize, vsize, vrefresh_rate,
>true);
> - if (mode)
> - return mode;
> + if (mode) {
> + drm_mode_probed_add(connector, mode);
> + modes++;
> + }
> }
> mode = drm_mode_find_dmt(dev, hsize, vsize, vrefresh_rate, false);
> - if (mode)
> - return mode;
> + goto done;
>
> /* okay, generate it */
> switch (timing_level) {
Unconditional "goto done" that skips all the logic for generating modes
not in the dmt list? This breaks everything _but_ case a) above, so eg.
1600x900 at 60 would no longer be generated.
- ajax
[PATCH 10/31] ARM: tegra: pass reset to tegra_powergate_sequence_power_up()
From: Stephen Warren
Tegra's clock driver now provides an implementation of the common
reset API (include/linux/reset.h). Use this instead of the old Tegra-
specific API; that will soon be removed.
Cc: treding at nvidia.com
Cc: pdeschrijver at nvidia.com
Cc: linux-tegra at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org
Cc: Bjorn Helgaas
Cc: linux-pci at vger.kernel.org
Cc: Terje Bergstr?m
Cc: David Airlie
Cc: dri-devel at lists.freedesktop.org
Signed-off-by: Stephen Warren
---
This patch is part of a series with strong internal depdendencies. I'm
looking for an ack so that I can take the entire series through the Tegra
and arm-soc trees. The series will be part of a stable branch that can be
merged into other subsystems if needed to avoid/resolve dependencies.
---
arch/arm/mach-tegra/powergate.c | 8 +---
drivers/gpu/drm/tegra/gr3d.c| 6 --
drivers/pci/host/pci-tegra.c| 3 ++-
include/linux/tegra-powergate.h | 4 +++-
4 files changed, 14 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-tegra/powergate.c b/arch/arm/mach-tegra/powergate.c
index 85d28e756bb7..f6f5b54ff95e 100644
--- a/arch/arm/mach-tegra/powergate.c
+++ b/arch/arm/mach-tegra/powergate.c
@@ -25,6 +25,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -144,11 +145,12 @@ int tegra_powergate_remove_clamping(int id)
}
/* Must be called with clk disabled, and returns with clk enabled */
-int tegra_powergate_sequence_power_up(int id, struct clk *clk)
+int tegra_powergate_sequence_power_up(int id, struct clk *clk,
+ struct reset_control *rst)
{
int ret;
- tegra_periph_reset_assert(clk);
+ reset_control_assert(rst);
ret = tegra_powergate_power_on(id);
if (ret)
@@ -165,7 +167,7 @@ int tegra_powergate_sequence_power_up(int id, struct clk
*clk)
goto err_clamp;
udelay(10);
- tegra_periph_reset_deassert(clk);
+ reset_control_deassert(rst);
return 0;
diff --git a/drivers/gpu/drm/tegra/gr3d.c b/drivers/gpu/drm/tegra/gr3d.c
index f629e38b00e4..0cbb24b1ae04 100644
--- a/drivers/gpu/drm/tegra/gr3d.c
+++ b/drivers/gpu/drm/tegra/gr3d.c
@@ -279,7 +279,8 @@ static int gr3d_probe(struct platform_device *pdev)
}
}
- err = tegra_powergate_sequence_power_up(TEGRA_POWERGATE_3D, gr3d->clk);
+ err = tegra_powergate_sequence_power_up(TEGRA_POWERGATE_3D, gr3d->clk,
+ gr3d->rst);
if (err < 0) {
dev_err(&pdev->dev, "failed to power up 3D unit\n");
return err;
@@ -287,7 +288,8 @@ static int gr3d_probe(struct platform_device *pdev)
if (gr3d->clk_secondary) {
err = tegra_powergate_sequence_power_up(TEGRA_POWERGATE_3D1,
- gr3d->clk_secondary);
+ gr3d->clk_secondary,
+ gr3d->rst_secondary);
if (err < 0) {
dev_err(&pdev->dev,
"failed to power up secondary 3D unit\n");
diff --git a/drivers/pci/host/pci-tegra.c b/drivers/pci/host/pci-tegra.c
index 174a5bc2d993..aace19edc469 100644
--- a/drivers/pci/host/pci-tegra.c
+++ b/drivers/pci/host/pci-tegra.c
@@ -956,7 +956,8 @@ static int tegra_pcie_power_on(struct tegra_pcie *pcie)
}
err = tegra_powergate_sequence_power_up(TEGRA_POWERGATE_PCIE,
- pcie->pex_clk);
+ pcie->pex_clk,
+ pcie->pex_rst);
if (err) {
dev_err(pcie->dev, "powerup sequence failed: %d\n", err);
return err;
diff --git a/include/linux/tegra-powergate.h b/include/linux/tegra-powergate.h
index c98cfa406952..b5ad64aca071 100644
--- a/include/linux/tegra-powergate.h
+++ b/include/linux/tegra-powergate.h
@@ -19,6 +19,7 @@
#define _MACH_TEGRA_POWERGATE_H_
struct clk;
+struct reset_control;
#define TEGRA_POWERGATE_CPU0
#define TEGRA_POWERGATE_3D 1
@@ -51,6 +52,7 @@ int tegra_powergate_power_off(int id);
int tegra_powergate_remove_clamping(int id);
/* Must be called with clk disabled, and returns with clk enabled */
-int tegra_powergate_sequence_power_up(int id, struct clk *clk);
+int tegra_powergate_sequence_power_up(int id, struct clk *clk,
+ struct reset_control *rst);
#endif /* _MACH_TEGRA_POWERGATE_H_ */
--
1.8.1.5
[PATCH 09/31] drm/tegra: use reset framework
From: Stephen Warren
Tegra's clock driver now provides an implementation of the common
reset API (include/linux/reset.h). Use this instead of the old Tegra-
specific API; that will soon be removed.
Cc: treding at nvidia.com
Cc: pdeschrijver at nvidia.com
Cc: linux-tegra at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org
Cc: Terje Bergstr?m
Cc: David Airlie
Cc: dri-devel at lists.freedesktop.org
Signed-off-by: Stephen Warren
---
This patch is part of a series with strong internal depdendencies. I'm
looking for an ack so that I can take the entire series through the Tegra
and arm-soc trees. The series will be part of a stable branch that can be
merged into other subsystems if needed to avoid/resolve dependencies.
---
drivers/gpu/drm/tegra/Kconfig | 1 +
drivers/gpu/drm/tegra/dc.c| 9 -
drivers/gpu/drm/tegra/drm.h | 3 +++
drivers/gpu/drm/tegra/gr3d.c | 16
drivers/gpu/drm/tegra/hdmi.c | 14 +++---
5 files changed, 39 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/tegra/Kconfig b/drivers/gpu/drm/tegra/Kconfig
index 8961ba6a34b8..8db9b3bce001 100644
--- a/drivers/gpu/drm/tegra/Kconfig
+++ b/drivers/gpu/drm/tegra/Kconfig
@@ -2,6 +2,7 @@ config DRM_TEGRA
bool "NVIDIA Tegra DRM"
depends on ARCH_TEGRA || ARCH_MULTIPLATFORM
depends on DRM
+ depends on RESET_CONTROLLER
select TEGRA_HOST1X
select DRM_KMS_HELPER
select DRM_KMS_FB_HELPER
diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
index ae1cb31ead7e..c3be92879bea 100644
--- a/drivers/gpu/drm/tegra/dc.c
+++ b/drivers/gpu/drm/tegra/dc.c
@@ -10,6 +10,7 @@
#include
#include
#include
+#include
#include "dc.h"
#include "drm.h"
@@ -712,7 +713,7 @@ static void tegra_crtc_prepare(struct drm_crtc *crtc)
unsigned long value;
/* hardware initialization */
- tegra_periph_reset_deassert(dc->clk);
+ reset_control_deassert(dc->rst);
usleep_range(1, 2);
if (dc->pipe)
@@ -1187,6 +1188,12 @@ static int tegra_dc_probe(struct platform_device *pdev)
return PTR_ERR(dc->clk);
}
+ dc->rst = devm_reset_control_get(&pdev->dev, "dc");
+ if (IS_ERR(dc->rst)) {
+ dev_err(&pdev->dev, "failed to get reset\n");
+ return PTR_ERR(dc->rst);
+ }
+
err = clk_prepare_enable(dc->clk);
if (err < 0)
return err;
diff --git a/drivers/gpu/drm/tegra/drm.h b/drivers/gpu/drm/tegra/drm.h
index fdfe259ed7f8..f717c18b28c2 100644
--- a/drivers/gpu/drm/tegra/drm.h
+++ b/drivers/gpu/drm/tegra/drm.h
@@ -19,6 +19,8 @@
#include
#include
+struct reset_control;
+
struct tegra_fb {
struct drm_framebuffer base;
struct tegra_bo **planes;
@@ -93,6 +95,7 @@ struct tegra_dc {
int pipe;
struct clk *clk;
+ struct reset_control *rst;
void __iomem *regs;
int irq;
diff --git a/drivers/gpu/drm/tegra/gr3d.c b/drivers/gpu/drm/tegra/gr3d.c
index 4cec8f526af7..f629e38b00e4 100644
--- a/drivers/gpu/drm/tegra/gr3d.c
+++ b/drivers/gpu/drm/tegra/gr3d.c
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
#include
#include "drm.h"
@@ -22,6 +23,8 @@ struct gr3d {
struct host1x_channel *channel;
struct clk *clk_secondary;
struct clk *clk;
+ struct reset_control *rst_secondary;
+ struct reset_control *rst;
DECLARE_BITMAP(addr_regs, GR3D_NUM_REGS);
};
@@ -255,12 +258,25 @@ static int gr3d_probe(struct platform_device *pdev)
return PTR_ERR(gr3d->clk);
}
+ gr3d->rst = devm_reset_control_get(&pdev->dev, "3d");
+ if (IS_ERR(gr3d->rst)) {
+ dev_err(&pdev->dev, "cannot get reset\n");
+ return PTR_ERR(gr3d->rst);
+ }
+
if (of_device_is_compatible(np, "nvidia,tegra30-gr3d")) {
gr3d->clk_secondary = devm_clk_get(&pdev->dev, "3d2");
if (IS_ERR(gr3d->clk)) {
dev_err(&pdev->dev, "cannot get secondary clock\n");
return PTR_ERR(gr3d->clk);
}
+
+ gr3d->rst_secondary = devm_reset_control_get(&pdev->dev,
+ "3d2");
+ if (IS_ERR(gr3d->rst_secondary)) {
+ dev_err(&pdev->dev, "cannot get secondary reset\n");
+ return PTR_ERR(gr3d->rst_secondary);
+ }
}
err = tegra_powergate_sequence_power_up(TEGRA_POWERGATE_3D, gr3d->clk);
diff --git a/drivers/gpu/drm/tegra/hdmi.c b/drivers/gpu/drm/tegra/hdmi.c
index 0cd9bc2056e8..f3aad49633d6 100644
--- a/drivers/gpu/drm/tegra/hdmi.c
+++ b/drivers/gpu/drm/tegra/hdmi.c
@@ -12,6 +12,7 @@
#include
#include
#include
+#include
#include "hdmi.h"
#include "drm.h"
@@ -49,6 +50,7 @@ struct tegra_hdmi {
struct clk *clk_parent;
struct clk *clk;
+ s
[PATCH 00/31] ARM: tegra: use common reset and DMA bindings
From: Stephen Warren This series implements a common reset framework driver for Tegra, and updates all relevant Tegra drivers to use it. It also removes the custom DMA bindings and replaced them with the standard DMA DT bindings. Historically, the Tegra clock driver has exported a custom API for module reset. This series removes that API, and transitions DT and drivers to the new reset framework. The custom API used a "struct clk" to identify which module to reset, and consequently some DT bindings and drivers required clocks to be provided where they really needed just a reset identifier instead. Due to this known deficiency, I have always considered most Tegra bindings to be unstable. This series removes this excuse for instability, although I still consider some Tegra bindings unstable due to the need to convert to the common DMA bindings. Historically, Tegra DMA channels have been represented in DT using a custom nvidia,dma-request-selector property. Now that standard DMA DT bindings exist, convert all Tegra bindings, DTs, and drivers to use the standard instead. This series makes a DT-ABI-incompatible change to: - Require reset specifiers in DT where relevant. - Require standard DMA specifiers. - Remove clock specifiers from DT where they were only needed for reset. - Remove legacy DMA specifier properties. I anticipate merging this whole series into the Tegra and arm-soc trees as its own branch, due to internal dependencies. This branch will be stable and can then be merged into any other subsystem trees should any conflicts arise. This series depends on Peter's Tegra clock driver rework, available at git://nv-tegra.nvidia.com/user/pdeschrijver/linux tegra-clk-tegra124-0 (or whatever version of that gets included in 3.14) Cc: ac100 at lists.launchpad.net Cc: Alan Stern Cc: alsa-devel at alsa-project.org Cc: Bjorn Helgaas Cc: Dan Williams Cc: David Airlie Cc: devel at driverdev.osuosl.org Cc: devicetree at vger.kernel.org Cc: Dmitry Torokhov Cc: Dmitry Torokhov Cc: dri-devel at lists.freedesktop.org Cc: Greg Kroah-Hartman Cc: Ian Campbell Cc: Julian Andres Klode Cc: Liam Girdwood Cc: linux-arm-kernel at lists.infradead.org Cc: linux-i2c at vger.kernel.org Cc: linux-input at vger.kernel.org Cc: linux-pci at vger.kernel.org Cc: linux-serial at vger.kernel.org Cc: linux-spi at vger.kernel.org Cc: linux-tegra at vger.kernel.org Cc: linux-usb at vger.kernel.org Cc: Marc Dietrich Cc: Mark Brown Cc: Mark Rutland Cc: Mike Turquette Cc: Pawel Moll Cc: pdeschrijver at nvidia.com Cc: Rob Herring Cc: Terje Bergstr?m Cc: treding at nvidia.com Cc: Wolfram Sang Stephen Warren (31): ARM: tegra: add missing clock documentation to DT bindings ARM: tegra: document reset properties in DT bindings ARM: tegra: document use of standard DMA DT bindings ARM: tegra: update DT files to add reset properties ARM: tegra: update DT files to add DMA properties ARM: tegra: select the reset framework clk: tegra: implement a reset driver pci: tegra: use reset framework drm/tegra: use reset framework ARM: tegra: pass reset to tegra_powergate_sequence_power_up() dma: add channel request API that supports deferred probe dma: tegra: use reset framework dma: tegra: register as an OF DMA controller ASoC: dmaengine: support deferred probe for DMA channels ASoC: dmaengine: add custom DMA config to snd_dmaengine_pcm_config ASoC: tegra: use reset framework ASoC: tegra: call pm_runtime APIs around register accesses ASoC: tegra: allocate AHUB FIFO during probe() not startup() ASoC: tegra: convert to standard DMA DT bindings i2c: tegra: use reset framework staging: nvec: use reset framework spi: tegra: use reset framework spi: tegra: convert to standard DMA DT bindings serial: tegra: use reset framework serial: tegra: convert to standard DMA DT bindings Input: tegra-kbc - use reset framework USB: EHCI: tegra: use reset framework ARM: tegra: remove legacy clock entries from DT ARM: tegra: remove legacy DMA entries from DT clk: tegra: remove legacy reset APIs clk: tegra: remove bogus PCIE_XCLK .../bindings/arm/tegra/nvidia,tegra20-pmc.txt | 1 + .../bindings/clock/nvidia,tegra114-car.txt | 4 + .../bindings/clock/nvidia,tegra124-car.txt | 4 + .../bindings/clock/nvidia,tegra20-car.txt | 4 + .../bindings/clock/nvidia,tegra30-car.txt | 4 + .../devicetree/bindings/dma/tegra20-apbdma.txt | 9 ++ .../bindings/gpu/nvidia,tegra20-host1x.txt | 124 +++ .../devicetree/bindings/i2c/nvidia,tegra20-i2c.txt | 27 +++- .../bindings/input/nvidia,tegra20-kbc.txt | 9 ++ .../bindings/mmc/nvidia,tegra20-sdhci.txt | 9 ++ .../devicetree/bindings/nvec/nvidia,nvec.txt | 12 ++ .../bindings/pci/nvidia,tegra20-pcie.txt | 28 ++-- .../devicetree/bindings/pwm/nvidia,tegra20-pwm.txt | 9 ++ .../devicetree/bindings/rtc/nvidia,tegra20-rtc.txt | 3 + .../bindings/seria
[Bug 71516] RV350 Radeon 9550 - no Unity 3D hardware support in Ubuntu 13.10, extremely slow
https://bugs.freedesktop.org/show_bug.cgi?id=71516 --- Comment #15 from Elven Decker --- I uploaded the lightdm log from an attempted login when I had stopped the ALWAYS_SOFTWARE flag from getting set. Thanks for staying with this one. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131115/982c11d2/attachment.html>
[Bug 71516] RV350 Radeon 9550 - no Unity 3D hardware support in Ubuntu 13.10, extremely slow
https://bugs.freedesktop.org/show_bug.cgi?id=71516 --- Comment #14 from Elven Decker --- Created attachment 89261 --> https://bugs.freedesktop.org/attachment.cgi?id=89261&action=edit lightm log file without ALWAYS_SOFTWARE flag set (login fails) -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131115/23fd6bc3/attachment.html>
[PATCH 2/2] drm/vmwgfx: Fix false lockdep warning
On 11/15/2013 10:29 AM, Daniel Vetter wrote: > On Fri, Nov 15, 2013 at 12:24:32AM -0800, Thomas Hellstrom wrote: >> A lockdep warning is hit when evicting surfaces and reserving the backup >> buffer. Since this buffer can only be reserved by the process holding the >> surface reservation or by the buffer eviction processes that use tryreserve, >> there is no real deadlock here, but there's no other way to silence lockdep >> than to use a tryreserve. This means the reservation might fail if the buffer >> is about to be evicted or swapped out, but we now have code in place to >> handle that reasonably well. >> >> Signed-off-by: Thomas Hellstrom > Hm, for similar cases where there's an additional hirarchy imposed onto > the locking order lockdep supports subclases. Block devices use that to > nest partitions within the overall block device. > > Have you looked into wiring this up for ww_mutexes, i.e. fix lockdep > instaed of working around it in the code? I'm thinking of a > ww_mutex_lock_nested similar to mutex_lock_nested. > > Cheers, Daniel > Yeah, I've thought of that, and that would definitely come in handy for upcoming page-table-bos where reservation should not fail, and where I need to play other tricks, and I might have a chance to look at that before merging that code. However in this particular case I'm not sure it will work, because the same buffers can be reserved at different nesting levels either as part of command submission or as part of eviction. In the block device analogy, a mutex could be taken both as a device mutex or a partition mutex. I haven't looked into the lock_nested semantics close enough to figure out whether that would work or confuse lockdep beyond recovery :). In any case, this needs a quick workaround for now. /Thomas
[Bug 71516] RV350 Radeon 9550 - no Unity 3D hardware support in Ubuntu 13.10, extremely slow
https://bugs.freedesktop.org/show_bug.cgi?id=71516 --- Comment #13 from Elven Decker --- unset LIBGL_ALWAYS_SOFTWARE; /usr/lib/nux/unity_support_test -p yields: unset LIBGL_ALWAYS_SOFTWARE; /usr/lib/nux/unity_support_test -p OpenGL vendor string: X.Org R300 Project OpenGL renderer string: Gallium 0.4 on ATI RV350 OpenGL version string: 2.1 Mesa 9.2.1 Not software rendered:yes Not blacklisted: yes GLX fbconfig: yes GLX texture from pixmap: yes GL npot or rect textures: yes GL vertex program:yes GL fragment program: yes GL vertex buffer object: yes GL framebuffer object:yes GL version is 1.4+: yes Unity 3D supported: yes *** I assume (don't know how to test and gdm is not installed) lightdm is my display manager, I reinstalled lightdm but no change. Logs look ok, I am going to restart without software rendering (so X fails and I get kicked back to login screen) and check those logs. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131115/1779fb14/attachment.html>
[PULL] bdw-fixes for 3.13
Hi Dave, As promised bdw fixes come separate for now. Just a few minior things. Cheers, Daniel The following changes since commit ad40f83f5a89f6d723fd4db424b531f8dd7d3b49: Merge branch 'drm-next-3.13' of git://people.freedesktop.org/~agd5f/linux into drm-next (2013-11-14 09:53:15 +1000) are available in the git repository at: git://people.freedesktop.org/~danvet/drm-intel bdw-fixes for you to fetch changes up to 596cc11e7a4a89bf6c45f955402d0bd0c7d51f13: drm/i915/bdw: PIPE_[BC] I[ME]R moved to powerwell (2013-11-14 09:33:12 +0100) Ben Widawsky (7): drm/i915/bdw: Add BDW to ULT macro drm/i915/bdw: GEN8 backlight support drm/i915/bdw: Do gen6 style reset for gen8 drm/i915/bdw: Free correct number of ppgtt pages drm/i915/bdw: Add comment about gen8 HWS PGA drm/i915/bdw: Limit GTT to 2GB drm/i915/bdw: PIPE_[BC] I[ME]R moved to powerwell drivers/gpu/drm/i915/i915_drv.h | 7 ++- drivers/gpu/drm/i915/i915_gem_gtt.c | 9 +++-- drivers/gpu/drm/i915/intel_panel.c | 26 +++--- drivers/gpu/drm/i915/intel_pm.c | 18 +- drivers/gpu/drm/i915/intel_ringbuffer.c | 1 + drivers/gpu/drm/i915/intel_uncore.c | 1 + 6 files changed, 55 insertions(+), 7 deletions(-) -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[git pull] drm regression fix
Forgot this one liner was necessary to fix module reload issues introduced earlier in the pull Thanks, Dave. The following changes since commit 0846c728e20a0cd1e43fb75a3015f3b176a26466: Merge branch 'drm-nouveau-next' of git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-next (2013-11-15 12:24:40 +1000) are available in the git repository at: git://people.freedesktop.org/~airlied/linux drm-next for you to fetch changes up to a3483353ca4e6dbeef2ed62ebed01af109b5b27a: drm: check for !kdev in drm_unplug_minor() (2013-11-15 20:49:02 +1000) David Herrmann (1): drm: check for !kdev in drm_unplug_minor() drivers/gpu/drm/drm_stub.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
[PATCH] intel: Add support for GPU reset status query ioctl
From: Ian Romanick
I would have just used the drmIoctl interface directly in Mesa, but the
ioctl needs some data from the drm_intel_context that is not exposed
outside libdrm.
This ioctl is in the drm-intel-next tree as b635991.
v2: Update based on Mika's kernel work.
v3: Fix compile failures from last-minute typos. Sigh.
v4: Import the actual changes from the kernel i915_drm.h. Only comments
on some fields of drm_i915_reset_stats differed. There are still some
deltas between the kernel i915_drm.h and the one in libdrm, but those
can be resolved in other patches.
Signed-off-by: Ian Romanick
Reviewed-by: Kenneth Graunke [v3]
Cc: Mika Kuoppala
Cc: Daniel Vetter
---
include/drm/i915_drm.h | 19 +++
intel/intel_bufmgr.h | 5 +
intel/intel_bufmgr_gem.c | 34 ++
3 files changed, 58 insertions(+)
diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
index aa983f3..c1914d6 100644
--- a/include/drm/i915_drm.h
+++ b/include/drm/i915_drm.h
@@ -198,6 +198,7 @@ typedef struct _drm_i915_sarea {
#define DRM_I915_GEM_SET_CACHEING 0x2f
#define DRM_I915_GEM_GET_CACHEING 0x30
#define DRM_I915_REG_READ 0x31
+#define DRM_I915_GET_RESET_STATS 0x32
#define DRM_IOCTL_I915_INITDRM_IOW( DRM_COMMAND_BASE +
DRM_I915_INIT, drm_i915_init_t)
#define DRM_IOCTL_I915_FLUSH DRM_IO ( DRM_COMMAND_BASE +
DRM_I915_FLUSH)
@@ -247,6 +248,7 @@ typedef struct _drm_i915_sarea {
#define DRM_IOCTL_I915_GEM_CONTEXT_CREATE DRM_IOWR (DRM_COMMAND_BASE +
DRM_I915_GEM_CONTEXT_CREATE, struct drm_i915_gem_context_create)
#define DRM_IOCTL_I915_GEM_CONTEXT_DESTROY DRM_IOW (DRM_COMMAND_BASE +
DRM_I915_GEM_CONTEXT_DESTROY, struct drm_i915_gem_context_destroy)
#define DRM_IOCTL_I915_REG_READDRM_IOWR
(DRM_COMMAND_BASE + DRM_I915_REG_READ, struct drm_i915_reg_read)
+#define DRM_IOCTL_I915_GET_RESET_STATS DRM_IOWR (DRM_COMMAND_BASE +
DRM_I915_GET_RESET_STATS, struct drm_i915_reset_stats)
/* Allow drivers to submit batchbuffers directly to hardware, relying
* on the security mechanisms provided by hardware.
@@ -943,4 +945,21 @@ struct drm_i915_reg_read {
__u64 offset;
__u64 val; /* Return value */
};
+
+struct drm_i915_reset_stats {
+ __u32 ctx_id;
+ __u32 flags;
+
+ /* All resets since boot/module reload, for all contexts */
+ __u32 reset_count;
+
+ /* Number of batches lost when active in GPU, for this context */
+ __u32 batch_active;
+
+ /* Number of batches lost pending for execution, for this context */
+ __u32 batch_pending;
+
+ __u32 pad;
+};
+
#endif /* _I915_DRM_H_ */
diff --git a/intel/intel_bufmgr.h b/intel/intel_bufmgr.h
index 7b28a70..34a5750 100644
--- a/intel/intel_bufmgr.h
+++ b/intel/intel_bufmgr.h
@@ -249,6 +249,11 @@ int drm_intel_reg_read(drm_intel_bufmgr *bufmgr,
uint32_t offset,
uint64_t *result);
+int drm_intel_get_reset_stats(drm_intel_context *ctx,
+ uint32_t *reset_count,
+ uint32_t *active,
+ uint32_t *pending);
+
/** @{ Compatibility defines to keep old code building despite the symbol
rename
* from dri_* to drm_intel_*
*/
diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
index dbadc52..0b9252e 100644
--- a/intel/intel_bufmgr_gem.c
+++ b/intel/intel_bufmgr_gem.c
@@ -3029,6 +3029,40 @@ drm_intel_gem_context_get_hw_context_id(const
drm_intel_context *ctx)
}
int
+drm_intel_get_reset_stats(drm_intel_context *ctx,
+ uint32_t *reset_count,
+ uint32_t *active,
+ uint32_t *pending)
+{
+ drm_intel_bufmgr_gem *bufmgr_gem;
+ struct drm_i915_reset_stats stats;
+ int ret;
+
+ if (ctx == NULL)
+ return -EINVAL;
+
+ VG_CLEAR(stats);
+
+ bufmgr_gem = (drm_intel_bufmgr_gem *)ctx->bufmgr;
+ stats.ctx_id = ctx->ctx_id;
+ ret = drmIoctl(bufmgr_gem->fd,
+ DRM_IOCTL_I915_GET_RESET_STATS,
+ &stats);
+ if (ret == 0) {
+ if (reset_count != NULL)
+ *reset_count = stats.reset_count;
+
+ if (active != NULL)
+ *active = stats.batch_active;
+
+ if (pending != NULL)
+ *pending = stats.batch_pending;
+ }
+
+ return ret;
+}
+
+int
drm_intel_reg_read(drm_intel_bufmgr *bufmgr,
uint32_t offset,
uint64_t *result)
--
1.8.1.4
[PATCH] drm: edid: enable probing and listing of non rb modes
The current solution checks for the existing RB mode,
if available in the edid block returns by adding it,
but does not populate the connector with the modes
of same resolution but which are non-rb modes.
As a result the probing and listing of non-rb modes can't
be made, in case the rb mode's pixel clock is not
supported but non-rb mode is supported.
This patch does 2 things:
1. adds "rb" suffix to rb modes.
2. changes the drm_mode_std mode selection to collect
all the supported modes and not just one mode.
Signed-off-by: Shirish S
---
drivers/gpu/drm/drm_edid.c | 74 +---
1 file changed, 36 insertions(+), 38 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 830f750..3276761 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -184,7 +184,7 @@ static const struct drm_display_mode drm_dmt_modes[] = {
896, 1048, 0, 600, 601, 604, 631, 0,
DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC) },
/* 800x600 at 120Hz RB */
- { DRM_MODE("800x600", DRM_MODE_TYPE_DRIVER, 73250, 800, 848,
+ { DRM_MODE("800x600rb", DRM_MODE_TYPE_DRIVER, 73250, 800, 848,
880, 960, 0, 600, 603, 607, 636, 0,
DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC) },
/* 848x480 at 60Hz */
@@ -213,7 +213,7 @@ static const struct drm_display_mode drm_dmt_modes[] = {
1168, 1376, 0, 768, 769, 772, 808, 0,
DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC) },
/* 1024x768 at 120Hz RB */
- { DRM_MODE("1024x768", DRM_MODE_TYPE_DRIVER, 115500, 1024, 1072,
+ { DRM_MODE("1024x768rb", DRM_MODE_TYPE_DRIVER, 115500, 1024, 1072,
1104, 1184, 0, 768, 771, 775, 813, 0,
DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC) },
/* 1152x864 at 75Hz */
@@ -221,7 +221,7 @@ static const struct drm_display_mode drm_dmt_modes[] = {
1344, 1600, 0, 864, 865, 868, 900, 0,
DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC) },
/* 1280x768 at 60Hz RB */
- { DRM_MODE("1280x768", DRM_MODE_TYPE_DRIVER, 68250, 1280, 1328,
+ { DRM_MODE("1280x768rb", DRM_MODE_TYPE_DRIVER, 68250, 1280, 1328,
1360, 1440, 0, 768, 771, 778, 790, 0,
DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC) },
/* 1280x768 at 60Hz */
@@ -237,11 +237,11 @@ static const struct drm_display_mode drm_dmt_modes[] = {
1496, 1712, 0, 768, 771, 778, 809, 0,
DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_PVSYNC) },
/* 1280x768 at 120Hz RB */
- { DRM_MODE("1280x768", DRM_MODE_TYPE_DRIVER, 140250, 1280, 1328,
+ { DRM_MODE("1280x768rb", DRM_MODE_TYPE_DRIVER, 140250, 1280, 1328,
1360, 1440, 0, 768, 771, 778, 813, 0,
DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC) },
/* 1280x800 at 60Hz RB */
- { DRM_MODE("1280x800", DRM_MODE_TYPE_DRIVER, 71000, 1280, 1328,
+ { DRM_MODE("1280x800rb", DRM_MODE_TYPE_DRIVER, 71000, 1280, 1328,
1360, 1440, 0, 800, 803, 809, 823, 0,
DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC) },
/* 1280x800 at 60Hz */
@@ -257,7 +257,7 @@ static const struct drm_display_mode drm_dmt_modes[] = {
1496, 1712, 0, 800, 803, 809, 843, 0,
DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_PVSYNC) },
/* 1280x800 at 120Hz RB */
- { DRM_MODE("1280x800", DRM_MODE_TYPE_DRIVER, 146250, 1280, 1328,
+ { DRM_MODE("1280x800rb", DRM_MODE_TYPE_DRIVER, 146250, 1280, 1328,
1360, 1440, 0, 800, 803, 809, 847, 0,
DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC) },
/* 1280x960 at 60Hz */
@@ -269,7 +269,7 @@ static const struct drm_display_mode drm_dmt_modes[] = {
1504, 1728, 0, 960, 961, 964, 1011, 0,
DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC) },
/* 1280x960 at 120Hz RB */
- { DRM_MODE("1280x960", DRM_MODE_TYPE_DRIVER, 175500, 1280, 1328,
+ { DRM_MODE("1280x960rb", DRM_MODE_TYPE_DRIVER, 175500, 1280, 1328,
1360, 1440, 0, 960, 963, 967, 1017, 0,
DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC) },
/* 1280x1024 at 60Hz */
@@ -285,7 +285,7 @@ static const struct drm_display_mode drm_dmt_modes[] = {
1504, 1728, 0, 1024, 1025, 1028, 1072, 0,
DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC) },
/* 1280x1024 at 120Hz RB */
- { DRM_MODE("1280x1024", DRM_MODE_TYPE_DRIVER, 187250, 1280, 1328,
+ { DRM_MODE("1280x1024rb", DRM_MODE_TYPE_DRIVER, 187250, 1280, 1328,
1360, 1440, 0, 1024, 1027, 1034, 1084, 0,
DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC) },
/* 1360x768 at 60Hz */
@@ -293,11 +293,11 @@ static const struct drm_display_mode drm_dmt_modes[] =
[PATCH] Enable probing of non-rb modes
With the current implementation of collecting edid modes, in case rb mode exists for a non rb mode of same resolution and vrefresh, the non-rb mode is never fed to display controller to be probed, as a result we lose on using the non-rb mode, if the display controller does not support rb mode but supports non-rb. For instance in case of 1680x1050 at 60Hz: with monitor whose EDID supports RB, if connected to display controller does not support 1680x1050 at 60Hz RB but it supports 1680x1050 at 60Hz, with the current implementation the non-rb mode 1680x1050 at 60Hz is not listed in connectors probed modes and hence on running xrandr is not listed. Shirish S (1): drm: edid: enable probing and listing of non rb modes drivers/gpu/drm/drm_edid.c | 74 +--- 1 file changed, 36 insertions(+), 38 deletions(-) -- 1.7.9.5
[PATCH 2/2] drm/vmwgfx: Fix false lockdep warning
On Fri, Nov 15, 2013 at 12:24:32AM -0800, Thomas Hellstrom wrote:
> A lockdep warning is hit when evicting surfaces and reserving the backup
> buffer. Since this buffer can only be reserved by the process holding the
> surface reservation or by the buffer eviction processes that use tryreserve,
> there is no real deadlock here, but there's no other way to silence lockdep
> than to use a tryreserve. This means the reservation might fail if the buffer
> is about to be evicted or swapped out, but we now have code in place to
> handle that reasonably well.
>
> Signed-off-by: Thomas Hellstrom
Hm, for similar cases where there's an additional hirarchy imposed onto
the locking order lockdep supports subclases. Block devices use that to
nest partitions within the overall block device.
Have you looked into wiring this up for ww_mutexes, i.e. fix lockdep
instaed of working around it in the code? I'm thinking of a
ww_mutex_lock_nested similar to mutex_lock_nested.
Cheers, Daniel
> ---
> drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 16 +++-
> 1 file changed, 7 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
> index 0e67cf4..4ea0be2 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
> @@ -992,7 +992,6 @@ void vmw_resource_unreserve(struct vmw_resource *res,
> */
> static int
> vmw_resource_check_buffer(struct vmw_resource *res,
> - struct ww_acquire_ctx *ticket,
> bool interruptible,
> struct ttm_validate_buffer *val_buf)
> {
> @@ -1009,7 +1008,7 @@ vmw_resource_check_buffer(struct vmw_resource *res,
> INIT_LIST_HEAD(&val_list);
> val_buf->bo = ttm_bo_reference(&res->backup->base);
> list_add_tail(&val_buf->head, &val_list);
> - ret = ttm_eu_reserve_buffers(ticket, &val_list);
> + ret = ttm_eu_reserve_buffers(NULL, &val_list);
> if (unlikely(ret != 0))
> goto out_no_reserve;
>
> @@ -1027,12 +1026,13 @@ vmw_resource_check_buffer(struct vmw_resource *res,
> return 0;
>
> out_no_validate:
> - ttm_eu_backoff_reservation(ticket, &val_list);
> + ttm_eu_backoff_reservation(NULL, &val_list);
> out_no_reserve:
> ttm_bo_unref(&val_buf->bo);
> if (backup_dirty)
> vmw_dmabuf_unreference(&res->backup);
>
> + DRM_INFO("Check buffer ret %d\n", ret);
> return ret;
> }
>
> @@ -1072,8 +1072,7 @@ int vmw_resource_reserve(struct vmw_resource *res, bool
> no_backup)
> * @val_buf:Backup buffer information.
> */
> static void
> -vmw_resource_backoff_reservation(struct ww_acquire_ctx *ticket,
> - struct ttm_validate_buffer *val_buf)
> +vmw_resource_backoff_reservation(struct ttm_validate_buffer *val_buf)
> {
> struct list_head val_list;
>
> @@ -1082,7 +1081,7 @@ vmw_resource_backoff_reservation(struct ww_acquire_ctx
> *ticket,
>
> INIT_LIST_HEAD(&val_list);
> list_add_tail(&val_buf->head, &val_list);
> - ttm_eu_backoff_reservation(ticket, &val_list);
> + ttm_eu_backoff_reservation(NULL, &val_list);
> ttm_bo_unref(&val_buf->bo);
> }
>
> @@ -1096,13 +1095,12 @@ int vmw_resource_do_evict(struct vmw_resource *res)
> {
> struct ttm_validate_buffer val_buf;
> const struct vmw_res_func *func = res->func;
> - struct ww_acquire_ctx ticket;
> int ret;
>
> BUG_ON(!func->may_evict);
>
> val_buf.bo = NULL;
> - ret = vmw_resource_check_buffer(res, &ticket, true, &val_buf);
> + ret = vmw_resource_check_buffer(res, true, &val_buf);
> if (unlikely(ret != 0))
> return ret;
>
> @@ -1117,7 +1115,7 @@ int vmw_resource_do_evict(struct vmw_resource *res)
> res->backup_dirty = true;
> res->res_dirty = false;
> out_no_unbind:
> - vmw_resource_backoff_reservation(&ticket, &val_buf);
> + vmw_resource_backoff_reservation(&val_buf);
>
> return ret;
> }
> --
> 1.7.10.4
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH] i915: Use 120MHz LVDS SSC clock for gen5/gen6/gen7
On Fri, Nov 15, 2013 at 12:39:32AM +0100, Daniel Vetter wrote: > On Thu, Nov 14, 2013 at 05:40:36PM -0200, Rodrigo Vivi wrote: > > On Thu, Nov 14, 2013 at 09:36:10AM -0800, Olof Johansson wrote: > > > On Thu, Nov 14, 2013 at 8:53 AM, Rodrigo Vivi > > > wrote: > > > > On Wed, Nov 13, 2013 at 05:59:43PM -0800, Olof Johansson wrote: > > > >> From: Duncan Laurie > > > >> > > > >> We had been using a DMI table workaround to select the right > > > >> frequency for devices, but this is fragile and must be updated > > > >> with every new platform. > > > >> > > > >> Instead the default case when VBT is missing is changed to use > > > >> 120MHz clock for LVDS SSC for these generations. > > > >> > > > >> The docs for 2010-Core, SandyBridge, and IvyBridge all indicate > > > >> that the reference frequency for LVDS is 120MHz: > > > >> > > > >> "2010 Core" > > > >> http://intellinuxgraphics.org/IHD_OS_Vol3_Part3r2.pdf > > > >> page 38 > > > >> Reference Frequency: 120MHz for CRT and LVDS. 100MHz for the FDI. > > > >> > > > >> "2011 SandyBridge" > > > >> http://intellinuxgraphics.org/documentation/SNB/IHD_OS_Vol3_Part3.pdf > > > >> page 33 > > > >> Reference Frequency: 120MHz for CRT, HDMI, LVDS. 100MHz for the FDI. > > > >> > > > >> "2012 IvyBridge" > > > >> http://intellinuxgraphics.org/documentation/IVB/IHD_OS_Vol3_Part4.pdf > > > >> page 27 > > > >> Reference Frequency: 120 MHz for CRT, HDMI, LVDS, 100MHz for the FDI. > > > > > > > > Checked. You are right. > > > > And actually true even for HSW and BDW. 120 is the default and 100 is > > > > for test mode. > > > > > > Yeah, the patch predates HSW/BDW, so it was not mentioned. > > > > > > >> Signed-off-by: Duncan Laurie > > > >> [olof: Fixup for recent base, switched from if/else to single call] > > > >> Signed-off-by: Olof Johansson > > > >> --- > > > >> > > > >> Daniel, > > > >> > > > >> This applies on top of -next, which I'm presuming is close to your > > > >> for-3.13 base right now. It'd be good to see this go in since it's > > > >> needed > > > >> to boot on Chromebooks (with developer mode off), and is thus blocking > > > >> testing next/mainline on a regular basis here. > > > >> > > > >> Thanks! > > > >> > > > >> -Olof > > > >> > > > >> drivers/gpu/drm/i915/intel_bios.c | 7 ++- > > > >> 1 file changed, 6 insertions(+), 1 deletion(-) > > > >> > > > >> diff --git a/drivers/gpu/drm/i915/intel_bios.c > > > >> b/drivers/gpu/drm/i915/intel_bios.c > > > >> index 6dd622d733b9..e4fba39631a5 100644 > > > >> --- a/drivers/gpu/drm/i915/intel_bios.c > > > >> +++ b/drivers/gpu/drm/i915/intel_bios.c > > > >> @@ -790,7 +790,12 @@ init_vbt_defaults(struct drm_i915_private > > > >> *dev_priv) > > > >> > > > >> /* Default to using SSC */ > > > >> dev_priv->vbt.lvds_use_ssc = 1; > > > >> - dev_priv->vbt.lvds_ssc_freq = intel_bios_ssc_frequency(dev, 1); > > > >> + /* > > > >> + * Core/SandyBridge/IvyBridge use alternative (120MHz) reference > > > >> + * clock for LVDS. > > > >> + */ > > > >> + dev_priv->vbt.lvds_ssc_freq = intel_bios_ssc_frequency(dev, > > > >> + !HAS_PCH_SPLIT(dev)); > > > > > > > > I'm just not convinced this is the right way to fix this here. > > > > Mainly because for most of platforms the alternate is 100 and default > > > > is 120. > > > > The ideal in my opinion should be to invert the alternate inside > > > > ssc_freqeuncy function and use the exception, that is probably > > > > IS_PINEVIEW(dev)... > > > > > > > > Not sure though... just a guess since this alternate was implemented > > > > for pineview... > > > > > > Seeing the history of some of this code (changes, followed by reverts, > > > etc), I wanted to stay conservative with what we know works from a few > > > years in the field by now. > > > > Stay conservative is good, but what I don't like is just the inverted > > logic... or maybe just the "alternate" name. > > > > > The vbt defaults are only used by > > > Chromebooks, as far as I know, so it's not a code path shared with > > > other platforms today. > > > > Are you sure? I don't know who is really setting vbt or going to defaults, > > but it is possible to have any one using it right now... anyway another > > reason to stay conservative... > > > > > Also, the ssc_freq bit from the vbios table is > > > passed into this function, so I don't think there's much point in > > > reversing the logic in there just for one of the two code paths. > > > > yeah, maybe just the name alternate is killing me here... > > > > > > > > Finally, from elsewhere in the same file: > > > > > > /* > > > * The genX designation typically refers to the render engine, so render > > > * capability related checks should use IS_GEN, while display and other > > > checks > > > * have their own (e.g. HAS_PCH_SPLIT for ILK+ display, IS_foo for > > > particular > > > * chips, etc.). > > > */ > > > > with this I agree.. > > > > > > > > Since this is display and not rendering rela
randconfig build error with next-20131115, in drivers/gpu/drm/nouveau
Building with the attached random configuration file, drivers/gpu/drm/nouveau/nouveau_hwmon.c: In function ?nouveau_hwmon_init?: drivers/gpu/drm/nouveau/nouveau_hwmon.c:633:2: error: ?hwmon? undeclared (first use in this function) hwmon->hwmon = NULL; ^ drivers/gpu/drm/nouveau/nouveau_hwmon.c:633:2: note: each undeclared identifier is reported only once for each function it appears in make[4]: *** [drivers/gpu/drm/nouveau/nouveau_hwmon.o] Error 1 -- next part -- # # Automatically generated file; DO NOT EDIT. # Linux/x86 3.12.0 Kernel Configuration # # CONFIG_64BIT is not set CONFIG_X86_32=y CONFIG_X86=y CONFIG_INSTRUCTION_DECODER=y CONFIG_OUTPUT_FORMAT="elf32-i386" CONFIG_ARCH_DEFCONFIG="arch/x86/configs/i386_defconfig" CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_MMU=y CONFIG_NEED_DMA_MAP_STATE=y CONFIG_NEED_SG_DMA_LENGTH=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_ARCH_HAS_CPU_RELAX=y CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y CONFIG_ARCH_HAS_CPU_AUTOPROBE=y CONFIG_HAVE_SETUP_PER_CPU_AREA=y CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y CONFIG_ARCH_HIBERNATION_POSSIBLE=y CONFIG_ARCH_SUSPEND_POSSIBLE=y CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y CONFIG_ARCH_WANT_GENERAL_HUGETLB=y # CONFIG_ZONE_DMA32 is not set # CONFIG_AUDIT_ARCH is not set CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-ecx -fcall-saved-edx" CONFIG_ARCH_SUPPORTS_UPROBES=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" CONFIG_CONSTRUCTORS=y CONFIG_IRQ_WORK=y CONFIG_BUILDTIME_EXTABLE_SORT=y # # General setup # CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_CROSS_COMPILE="" CONFIG_COMPILE_TEST=y CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=y CONFIG_HAVE_KERNEL_GZIP=y CONFIG_HAVE_KERNEL_BZIP2=y CONFIG_HAVE_KERNEL_LZMA=y CONFIG_HAVE_KERNEL_XZ=y CONFIG_HAVE_KERNEL_LZO=y CONFIG_HAVE_KERNEL_LZ4=y # CONFIG_KERNEL_UNCOMPRESSED is not set CONFIG_KERNEL_GZIP=y # CONFIG_KERNEL_BZIP2 is not set # CONFIG_KERNEL_LZMA is not set # CONFIG_KERNEL_XZ is not set # CONFIG_KERNEL_LZO is not set # CONFIG_KERNEL_LZ4 is not set CONFIG_DEFAULT_HOSTNAME="(none)" CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_POSIX_MQUEUE=y CONFIG_FHANDLE=y CONFIG_AUDIT=y CONFIG_AUDITSYSCALL=y CONFIG_AUDIT_WATCH=y CONFIG_AUDIT_TREE=y # # IRQ subsystem # CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_IRQ_SHOW=y CONFIG_GENERIC_IRQ_CHIP=y CONFIG_IRQ_DOMAIN=y # CONFIG_IRQ_DOMAIN_DEBUG is not set CONFIG_IRQ_FORCED_THREADING=y CONFIG_SPARSE_IRQ=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_KTIME_SCALAR=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BUILD=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y CONFIG_GENERIC_CMOS_UPDATE=y # # Timers subsystem # CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ_COMMON=y # CONFIG_HZ_PERIODIC is not set CONFIG_NO_HZ_IDLE=y CONFIG_NO_HZ=y # CONFIG_HIGH_RES_TIMERS is not set # # CPU/Task time and stats accounting # CONFIG_TICK_CPU_ACCOUNTING=y # CONFIG_IRQ_TIME_ACCOUNTING is not set CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y # CONFIG_TASKSTATS is not set # # RCU Subsystem # CONFIG_TINY_RCU=y # CONFIG_PREEMPT_RCU is not set # CONFIG_RCU_STALL_COMMON is not set # CONFIG_TREE_RCU_TRACE is not set # CONFIG_IKCONFIG is not set CONFIG_LOG_BUF_SHIFT=17 CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y CONFIG_ARCH_SUPPORTS_NUMA_BALANCING=y CONFIG_ARCH_WANTS_PROT_NUMA_PROT_NONE=y CONFIG_CGROUPS=y # CONFIG_CGROUP_DEBUG is not set CONFIG_CGROUP_FREEZER=y # CONFIG_CGROUP_DEVICE is not set # CONFIG_CPUSETS is not set CONFIG_CGROUP_CPUACCT=y # CONFIG_RESOURCE_COUNTERS is not set CONFIG_CGROUP_PERF=y CONFIG_CGROUP_SCHED=y CONFIG_FAIR_GROUP_SCHED=y CONFIG_CFS_BANDWIDTH=y CONFIG_RT_GROUP_SCHED=y # CONFIG_BLK_CGROUP is not set CONFIG_CHECKPOINT_RESTORE=y CONFIG_NAMESPACES=y # CONFIG_UTS_NS is not set # CONFIG_IPC_NS is not set # CONFIG_USER_NS is not set # CONFIG_PID_NS is not set CONFIG_NET_NS=y # CONFIG_UIDGID_STRICT_TYPE_CHECKS is not set CONFIG_SCHED_AUTOGROUP=y CONFIG_SYSFS_DEPRECATED=y # CONFIG_SYSFS_DEPRECATED_V2 is not set CONFIG_RELAY=y # CONFIG_BLK_DEV_INITRD is not set # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_ANON_INODES=y CONFIG_HAVE_UID16=y CONFIG_SYSCTL_EXCEPTION_TRACE=y CONFIG_HAVE_PCSPKR_PLATFORM=y CONFIG_EXPERT=y # CONFIG_UID16 is not set CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y CONFIG_PRINTK=y CONFIG_BUG=y # CONFIG_PCSPKR_PLATFORM is not set # CONFIG_BASE_FULL is not set # CONFIG_FUTEX is not set CONFIG_EPOLL=y # CONFIG_SIGNALFD is not set # CONFIG_TIMERFD is not set CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_AIO=y # CONFIG_PCI_QUIRKS is not set # CONFIG_EMBEDDED is not set CONFIG_HAVE_PERF_EVENTS=y # # Kernel Performance Events And Counters # CONFIG_PERF_EVENTS=y # CONFIG_DEBUG_PERF_USE_VMALLOC is not set CONFIG_VM_EVENT
[Bug 71543] [mesa] Source-based games segfault
https://bugs.freedesktop.org/show_bug.cgi?id=71543 Nikolay Amiantov changed: What|Removed |Added Hardware|x86 (IA32) |x86-64 (AMD64) Assignee|dri-devel at lists.freedesktop |mesa-dev at lists.freedesktop. |.org|org Summary|[r600] Source-based games |[mesa] Source-based games |segfault|segfault Component|Drivers/DRI/R600|Mesa core --- Comment #3 from Nikolay Amiantov --- I've just checked this on Intel (I have hybrid graphics) with same results. I don't really know where non card-specifin bugs should go, sending it to Mesa core... Oh, and I'm using x86_64 system with 32-bit libs for games. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131115/81675e4c/attachment.html>
possible regression Radeon RV280 (R3xx/R4xx ?) card freeze, re-apply old patch ?
I think there are two issues here: the first is the missing alignment workaround, since i'll be upgrading to 3.4.69 anyway i'll insert some diagnostic messages in radeon_device.c and see what happens. But i'm pretty certain now that this isn't the cause for the lockups. They are probably (quite certainly) caused by the dynamic binding/unbinding of AGP memory which the Uninorth chipset used in 32-bit powermacs obviously doesn't support. All it supports seems to be statically allocating a 256 MB contigouous non-cacheable AGP aperture and using that (since the chipset doesn't do any address mapping via the GART as indicated in the OpenBSD code). So to get AGP mode working again on those machines one would have to disable the dynamic memory stuff. Question: Would that require changes in the driver only or also in the DRM ? Cheers Jochen Am 14.11.2013 02:37, schrieb Michel D?nzer: > On Mit, 2013-11-13 at 19:07 +0100, Jochen Rollwagen wrote: >> I started investigating the problem because AGP mode used to work with >> the UMS drivers (although I now understand they didn?t really use AGP >> memory) > They used AGP memory but didn't dynamically bind memory to the AGP > aperture or unbind it from there. > > >> and in the second patch I mentioned below Benjamin Herrenschmidt >> stated that ?there's a chip errata (for the pre-R600 chips). On those >> chips, the aperture must be aligned to the aperture size (that is >> FB_START in MC_FB_LOCATION must be aligned to the aperture size).? >> Since that workaround/patch definitely isn?t in the current DRM code >> any more (probably got lost in the transition to KMS) my idea was to >> re-apply the three-line workaround/patch (which should be quite >> trivial given the comment in radeon_vram_location in the drm kernel >> code). > So, have you verified that the aperture is not aligned to its size for > you? If it's not, does aligning it help stability with AGP? > >
[Bug 71543] [r600] Source-based games segfault
https://bugs.freedesktop.org/show_bug.cgi?id=71543 Nikolay Amiantov changed: What|Removed |Added Hardware|Other |x86 (IA32) OS|All |Linux (All) Version|unspecified |git -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131115/c1876690/attachment.html>
[Bug 71543] [r600] Source-based games segfault
https://bugs.freedesktop.org/show_bug.cgi?id=71543 --- Comment #2 from Nikolay Amiantov --- I've got stack trace: Program received signal SIGSEGV, Segmentation fault. 0x45b2e4a8 in udev_list_entry_get_next () from /usr/lib32/libudev.so.1 (gdb) bt #0 0x45b2e4a8 in udev_list_entry_get_next () from /usr/lib32/libudev.so.1 #1 0x45b33b8b in udev_monitor_filter_update () from /usr/lib32/libudev.so.1 #2 0xf788213e in udev_monitor_enable_receiving () from /home/abbradar/.steam/steam/SteamApps/common/GarrysMod/bin/libudev.so.0 #3 0xf795d7df in ?? () from /home/abbradar/.steam/steam/SteamApps/common/GarrysMod/bin/libSDL2-2.0.so.0 #4 0xf7948ae7 in ?? () from /home/abbradar/.steam/steam/SteamApps/common/GarrysMod/bin/libSDL2-2.0.so.0 #5 0xf78bf874 in SDL_InitSubSystem () from /home/abbradar/.steam/steam/SteamApps/common/GarrysMod/bin/libSDL2-2.0.so.0 #6 0xf789244f in ?? () from /home/abbradar/.local/share/Steam/SteamApps/common/GarrysMod/bin/inputsystem.so #7 0xf7890410 in ?? () from /home/abbradar/.local/share/Steam/SteamApps/common/GarrysMod/bin/inputsystem.so #8 0xf7f9bb36 in ?? () from bin/launcher.so #9 0xf7f9bc12 in ?? () from bin/launcher.so #10 0xf7f9be98 in ?? () from bin/launcher.so #11 0xf7f9beb0 in ?? () from bin/launcher.so #12 0xf7f83bbd in LauncherMain () from bin/launcher.so #13 0x080484d4 in main () (gdb) That's quite strange, no Mesa calls at all, yet new Mesa definitely breaks things... -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131115/aa3bc2e9/attachment-0001.html>
[Bug 69723] Computer freezes with kernel 3.11.0 / 3.12-rc1 (with bug 68235's patches applied) when dpm=1 on r600g (Cayman)
https://bugs.freedesktop.org/show_bug.cgi?id=69723 --- Comment #32 from Alexandre Demers --- Created attachment 89246 --> https://bugs.freedesktop.org/attachment.cgi?id=89246&action=edit journalctl from last couple of boot/hang cycles This could be interesting: I've been bisecting. The first usable kernel on Cayman with dpm was between 3.11-rc1 and 3.11-rc2. Before that, the system was unusable (major corruption). So, with patches from related bug, I was able to start a session and run applications until it hanged. On Nov 15 00:19:51, I was booting with a safe kernel (before dpm was enabled, a144acb). On Nov 15 00:36:23, I booted with the kernel exhibiting a desired behavior. Logged, ran tasks, hanged on Nov 15 00:41:03. Segfault in libLLVM-3.3.so and possible recursive locking detected, followed by DEADLOCK. However, I was unable to get the same result in the following boot. Then switch to 3.12-rc7 to send journal. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131115/24945daa/attachment.html>
[Bug 69689] FBO with GL_RGBA16F texture format silent drawing corruption
https://bugs.freedesktop.org/show_bug.cgi?id=69689 Johannes Jordan changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #11 from Johannes Jordan --- Thank you for your time, I very much appreciate your detailed comment. I made my code compliant and now it works as expected. I had made a different mistake when I tried with the same format for the blit target. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131115/fffee7a4/attachment.html>
[git pull] drm pull for 3.13-rc1
Hi Linus, This is a combo of -next and some -fixes that came in in the intervening time, Highlights: new drivers: ARM Armada driver for Marvell Armada 510 SOCs Intel: Broadwell initial support under a default off switch, Stereo/3D HDMI mode support Valleyview improvements Displayport improvements Haswell fixes initial mipi dsi panel support CRC support for debugging build with CONFIG_FB=n Radeon: enable DPM on a number of GPUs by default secondary GPU powerdown support enable HDMI audio by default Hawaii support nouveau: dynamic pm code infrastructure reworked, does nothing major yet GK208 modesetting support MSI fixes, on by default again PMPEG improvements pageflipping fixes GMA500: minnowboard SDVO support vmware: misc fixes msm: prime, plane and rendernodes support tegra: rearchitected to put the drm driver into the drm subsystem. HDMI and gr2d support for tegra 114 SoC qxl: oops fix, and multi-head fixes drm core: sysfs lifetime fixes client capability ioctl further cleanups to device midlayer more vblank timestamp fixes The following changes since commit 5e01dc7b26d9f24f39abace5da98ccbd6a5ceb52: Linux 3.12 (2013-11-03 15:41:51 -0800) are available in the git repository at: git://people.freedesktop.org/~airlied/linux drm-next for you to fetch changes up to 0846c728e20a0cd1e43fb75a3015f3b176a26466: Merge branch 'drm-nouveau-next' of git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-next (2013-11-15 12:24:40 +1000) Alex Deucher (43): drm/edid: catch kmalloc failure in drm_edid_to_speaker_allocation drm/radeon: Add support for programming the FMT blocks drm/radeon: add a connector property for dither drm/radeon: enable hdmi audio by default drm/radeon: plug in blit copy routine for SI drm/radeon: implement blit copy callback for CIK drm/radeon/si: tell dpm there is a display connected drm/radeon/atom: don't call [EN|DIS]ABLE_OUTPUT on DCE3.x drm/radeon/atom: don't call [EN|DIS]ABLE_OUTPUT on DCE4.x drm/radeon/audio: break out of loops once we match connector drm/radeon/audio: write audio/video latency info for DCE4/5 drm/radeon/audio: write audio/video latency info for DCE6/8 drm/radeon/dpm: only print dpm debugging messages when radeon_dpm=1 drm/radeon: enable DPM by default on SUMO/PALM APUs drm/radeon: enable DPM by default on SI asics drm/radeon: enable DPM by default on BTC asics drm/radeon: enable DPM by default on evergreen asics drm/radeon: enable DPM by default on r7xx asics drm/radeon: disable force performance state when thermal state is active drm/radeon/dpm: retain user selected performance level across state changes drm/radeon: fix endian handling in rlc buffer setup drm/radeon/si: fix define for MC_SEQ_TRAIN_WAKEUP_CNTL drm/radeon/dpm: fix typo in setting smc flag drm/radeon: don't share PPLLs on DCE4.1 drm/radeon: use HDP_MEM_COHERENCY_FLUSH_CNTL for sdma as well drm/radeon: fix-up some float to fixed conversion thinkos drm/radeon: add Hawaii chip family drm/radeon: update cik_gpu_init() for hawaii drm/radeon: minor updates to cik.c for hawaii drm/radeon: update cik_tiling_mode_table_init() for hawaii drm/radeon: add golden register settings for hawaii drm/radeon: update rb setup for hawaii drm/radeon: update firmware loading for hawaii drm/radeon/cik: add hawaii UVD support drm/radeon: add hawaii dpm support drm/radeon: update cik_get_csb_buffer for hawaii drm/radeon: atombios.h updates for hawaii drm/radeon: modesetting updates for hawaii drm/radeon: fill in radeon_asic_init for hawaii drm/radeon: add pci ids for hawaii drm/radeon: fix mismerge of drm-next with 3.12 Revert "drm/radeon/audio: don't set speaker allocation on DCE4+" drm/edid: compare actual vrefresh for all modes for quirks Anssi Hannula (1): drm/radeon/audio: fix missing multichannel PCM SAD in some cases Art Runyan (1): drm/i915/bdw: Add BDW DDI buffer translation values Artem Bityutskiy (1): drm/i915: preserve dispaly init order on ByT Arto Merilainen (4): gpu: host1x: Add 'flags' field to syncpt request gpu: host1x: Add syncpoint base support drm/tegra: Deliver syncpoint base to user space drm/tegra: Reserve base for gr2d Ben Hutchings (2): drm: Do not include page offset in argument to virt_to_page() drm: Pass pointers to virt_to_page() Ben Skeggs (66): drm/nv50-/sw: share engine/channel struct definitions between implementations drm/nv50-/sw: make vblank tracking data private to the implementations drm/nouveau/sw: prepare for the sharing of
[Bug 71516] RV350 Radeon 9550 - no Unity 3D hardware support in Ubuntu 13.10, extremely slow
https://bugs.freedesktop.org/show_bug.cgi?id=71516 --- Comment #12 from Michel D?nzer --- (In reply to comment #11) > X won't start without LIBGL_ALWAYS_SOFTWARE set. Log file is Xort.0.log.sav > above. That doesn't show any problem. Maybe check the display manager (lightdm?) log files to see if the X server stderr contains more information. Meanwhile, you could let it set LIBGL_ALWAYS_SOFTWARE to get into X, then run unity_support_test something like this: ( unset LIBGL_ALWAYS_SOFTWARE; /usr/lib/nux/unity_support_test -p ) > Radeon 9600 vs. 9550? Just two different marketing names for the same hardware. > Not sure anybody needs to run Xorg -configure anymore, [...] Nobody does. It's been deprecated and barely working for a long time. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131115/36428b32/attachment.html>
[Bug 71516] RV350 Radeon 9550 - no Unity 3D hardware support in Ubuntu 13.10, extremely slow
https://bugs.freedesktop.org/show_bug.cgi?id=71516 --- Comment #11 from Elven Decker --- X won't start without LIBGL_ALWAYS_SOFTWARE set. Log file is Xort.0.log.sav above. I notice that Xorg.0.log and lspci identify my card in different ways? Radeon 9600 vs. 9550? >From Xorg.0.log (--) RADEON(0): Chipset: "ATI Radeon 9600 AS (AGP)" (ChipID = 0x4153) lspci -nn | grep VGA 01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] RV350 [Radeon 9550] [1002:4153] *** Another thought... Not sure anybody needs to run Xorg -configure anymore, but I tried it to see if I could learn anything and got the message "Number of created screens does not match number of detected devices". The configure process noted three screens and three monitors, I believe my card supports my monitor and an external TV. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131115/789855fa/attachment.html>
[Bug 71516] RV350 Radeon 9550 - no Unity 3D hardware support in Ubuntu 13.10, extremely slow
https://bugs.freedesktop.org/show_bug.cgi?id=71516 --- Comment #10 from Michel D?nzer --- (In reply to comment #9) > log file without ALWAYS_SOFTWARE flag set. Thanks, but LIBGL_ALWAYS_SOFTWARE only affects libGL, not the X server. We need to see the output of unity_support_test without it set. Does Unity work if you hack the script not to set LIBGL_ALWAYS_SOFTWARE? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131115/0b588b14/attachment.html>
[Bug 71516] RV350 Radeon 9550 - no Unity 3D hardware support in Ubuntu 13.10, extremely slow
https://bugs.freedesktop.org/show_bug.cgi?id=71516 --- Comment #9 from Elven Decker --- Created attachment 89244 --> https://bugs.freedesktop.org/attachment.cgi?id=89244&action=edit log file without ALWAYS_SOFTWARE flag set. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131115/c4dc6ccc/attachment.html>
[Bug 69689] FBO with GL_RGBA16F texture format silent drawing corruption
https://bugs.freedesktop.org/show_bug.cgi?id=69689 --- Comment #10 from Grigori Goronzy --- This does not work because glBlitFramebuffer fails, since it is trying to blit between FBOs with different pixel formats. This isn't allowed, check for instance the OpenGL 3.3 core specification, section 4.3.2 or the EXT_framebuffer_multisample specification. They unambiguously state that read and draw framebuffer must have the same pixel format for blits that involve multisample framebuffers. As far as I can see, this is not a problem with Mesa, but rather with your OpenGL compliance. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131115/85ee9947/attachment.html>
[PATCH] i915: Use 120MHz LVDS SSC clock for gen5/gen6/gen7
On Thu, Nov 14, 2013 at 05:40:36PM -0200, Rodrigo Vivi wrote: > On Thu, Nov 14, 2013 at 09:36:10AM -0800, Olof Johansson wrote: > > On Thu, Nov 14, 2013 at 8:53 AM, Rodrigo Vivi > > wrote: > > > On Wed, Nov 13, 2013 at 05:59:43PM -0800, Olof Johansson wrote: > > >> From: Duncan Laurie > > >> > > >> We had been using a DMI table workaround to select the right > > >> frequency for devices, but this is fragile and must be updated > > >> with every new platform. > > >> > > >> Instead the default case when VBT is missing is changed to use > > >> 120MHz clock for LVDS SSC for these generations. > > >> > > >> The docs for 2010-Core, SandyBridge, and IvyBridge all indicate > > >> that the reference frequency for LVDS is 120MHz: > > >> > > >> "2010 Core" > > >> http://intellinuxgraphics.org/IHD_OS_Vol3_Part3r2.pdf > > >> page 38 > > >> Reference Frequency: 120MHz for CRT and LVDS. 100MHz for the FDI. > > >> > > >> "2011 SandyBridge" > > >> http://intellinuxgraphics.org/documentation/SNB/IHD_OS_Vol3_Part3.pdf > > >> page 33 > > >> Reference Frequency: 120MHz for CRT, HDMI, LVDS. 100MHz for the FDI. > > >> > > >> "2012 IvyBridge" > > >> http://intellinuxgraphics.org/documentation/IVB/IHD_OS_Vol3_Part4.pdf > > >> page 27 > > >> Reference Frequency: 120 MHz for CRT, HDMI, LVDS, 100MHz for the FDI. > > > > > > Checked. You are right. > > > And actually true even for HSW and BDW. 120 is the default and 100 is for > > > test mode. > > > > Yeah, the patch predates HSW/BDW, so it was not mentioned. > > > > >> Signed-off-by: Duncan Laurie > > >> [olof: Fixup for recent base, switched from if/else to single call] > > >> Signed-off-by: Olof Johansson > > >> --- > > >> > > >> Daniel, > > >> > > >> This applies on top of -next, which I'm presuming is close to your > > >> for-3.13 base right now. It'd be good to see this go in since it's needed > > >> to boot on Chromebooks (with developer mode off), and is thus blocking > > >> testing next/mainline on a regular basis here. > > >> > > >> Thanks! > > >> > > >> -Olof > > >> > > >> drivers/gpu/drm/i915/intel_bios.c | 7 ++- > > >> 1 file changed, 6 insertions(+), 1 deletion(-) > > >> > > >> diff --git a/drivers/gpu/drm/i915/intel_bios.c > > >> b/drivers/gpu/drm/i915/intel_bios.c > > >> index 6dd622d733b9..e4fba39631a5 100644 > > >> --- a/drivers/gpu/drm/i915/intel_bios.c > > >> +++ b/drivers/gpu/drm/i915/intel_bios.c > > >> @@ -790,7 +790,12 @@ init_vbt_defaults(struct drm_i915_private *dev_priv) > > >> > > >> /* Default to using SSC */ > > >> dev_priv->vbt.lvds_use_ssc = 1; > > >> - dev_priv->vbt.lvds_ssc_freq = intel_bios_ssc_frequency(dev, 1); > > >> + /* > > >> + * Core/SandyBridge/IvyBridge use alternative (120MHz) reference > > >> + * clock for LVDS. > > >> + */ > > >> + dev_priv->vbt.lvds_ssc_freq = intel_bios_ssc_frequency(dev, > > >> + !HAS_PCH_SPLIT(dev)); > > > > > > I'm just not convinced this is the right way to fix this here. > > > Mainly because for most of platforms the alternate is 100 and default is > > > 120. > > > The ideal in my opinion should be to invert the alternate inside > > > ssc_freqeuncy function and use the exception, that is probably > > > IS_PINEVIEW(dev)... > > > > > > Not sure though... just a guess since this alternate was implemented for > > > pineview... > > > > Seeing the history of some of this code (changes, followed by reverts, > > etc), I wanted to stay conservative with what we know works from a few > > years in the field by now. > > Stay conservative is good, but what I don't like is just the inverted > logic... or maybe just the "alternate" name. > > > The vbt defaults are only used by > > Chromebooks, as far as I know, so it's not a code path shared with > > other platforms today. > > Are you sure? I don't know who is really setting vbt or going to defaults, > but it is possible to have any one using it right now... anyway another > reason to stay conservative... > > > Also, the ssc_freq bit from the vbios table is > > passed into this function, so I don't think there's much point in > > reversing the logic in there just for one of the two code paths. > > yeah, maybe just the name alternate is killing me here... > > > > > Finally, from elsewhere in the same file: > > > > /* > > * The genX designation typically refers to the render engine, so render > > * capability related checks should use IS_GEN, while display and other > > checks > > * have their own (e.g. HAS_PCH_SPLIT for ILK+ display, IS_foo for > > particular > > * chips, etc.). > > */ > > with this I agree.. > > > > > Since this is display and not rendering related, that seems like the > > right thing to base it on instead of generation tests. > > > > I'm open for suggestions on improvements though, of course. > > I don't have a real suggestion here... only bikesheds... maybe on the > alternate name ;) > > But either way, it seems to work and right since default is 120 for tho
[PATCH 2/2] drm/vmwgfx: Fix false lockdep warning
A lockdep warning is hit when evicting surfaces and reserving the backup
buffer. Since this buffer can only be reserved by the process holding the
surface reservation or by the buffer eviction processes that use tryreserve,
there is no real deadlock here, but there's no other way to silence lockdep
than to use a tryreserve. This means the reservation might fail if the buffer
is about to be evicted or swapped out, but we now have code in place to
handle that reasonably well.
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 16 +++-
1 file changed, 7 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
index 0e67cf4..4ea0be2 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
@@ -992,7 +992,6 @@ void vmw_resource_unreserve(struct vmw_resource *res,
*/
static int
vmw_resource_check_buffer(struct vmw_resource *res,
- struct ww_acquire_ctx *ticket,
bool interruptible,
struct ttm_validate_buffer *val_buf)
{
@@ -1009,7 +1008,7 @@ vmw_resource_check_buffer(struct vmw_resource *res,
INIT_LIST_HEAD(&val_list);
val_buf->bo = ttm_bo_reference(&res->backup->base);
list_add_tail(&val_buf->head, &val_list);
- ret = ttm_eu_reserve_buffers(ticket, &val_list);
+ ret = ttm_eu_reserve_buffers(NULL, &val_list);
if (unlikely(ret != 0))
goto out_no_reserve;
@@ -1027,12 +1026,13 @@ vmw_resource_check_buffer(struct vmw_resource *res,
return 0;
out_no_validate:
- ttm_eu_backoff_reservation(ticket, &val_list);
+ ttm_eu_backoff_reservation(NULL, &val_list);
out_no_reserve:
ttm_bo_unref(&val_buf->bo);
if (backup_dirty)
vmw_dmabuf_unreference(&res->backup);
+ DRM_INFO("Check buffer ret %d\n", ret);
return ret;
}
@@ -1072,8 +1072,7 @@ int vmw_resource_reserve(struct vmw_resource *res, bool
no_backup)
* @val_buf:Backup buffer information.
*/
static void
-vmw_resource_backoff_reservation(struct ww_acquire_ctx *ticket,
-struct ttm_validate_buffer *val_buf)
+vmw_resource_backoff_reservation(struct ttm_validate_buffer *val_buf)
{
struct list_head val_list;
@@ -1082,7 +1081,7 @@ vmw_resource_backoff_reservation(struct ww_acquire_ctx
*ticket,
INIT_LIST_HEAD(&val_list);
list_add_tail(&val_buf->head, &val_list);
- ttm_eu_backoff_reservation(ticket, &val_list);
+ ttm_eu_backoff_reservation(NULL, &val_list);
ttm_bo_unref(&val_buf->bo);
}
@@ -1096,13 +1095,12 @@ int vmw_resource_do_evict(struct vmw_resource *res)
{
struct ttm_validate_buffer val_buf;
const struct vmw_res_func *func = res->func;
- struct ww_acquire_ctx ticket;
int ret;
BUG_ON(!func->may_evict);
val_buf.bo = NULL;
- ret = vmw_resource_check_buffer(res, &ticket, true, &val_buf);
+ ret = vmw_resource_check_buffer(res, true, &val_buf);
if (unlikely(ret != 0))
return ret;
@@ -1117,7 +1115,7 @@ int vmw_resource_do_evict(struct vmw_resource *res)
res->backup_dirty = true;
res->res_dirty = false;
out_no_unbind:
- vmw_resource_backoff_reservation(&ticket, &val_buf);
+ vmw_resource_backoff_reservation(&val_buf);
return ret;
}
--
1.7.10.4
[PATCH 1/2] drm/ttm: Allow execbuf util reserves without ticket
If no reservation ticket is given to the execbuf reservation utilities,
try reservation with non-blocking semantics.
This is intended for eviction paths that use the execbuf reservation
utilities for convenience rather than for deadlock avoidance.
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/ttm/ttm_execbuf_util.c | 32 +++-
include/drm/ttm/ttm_execbuf_util.h |3 ++-
2 files changed, 21 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_execbuf_util.c
b/drivers/gpu/drm/ttm/ttm_execbuf_util.c
index 6c91178..479e941 100644
--- a/drivers/gpu/drm/ttm/ttm_execbuf_util.c
+++ b/drivers/gpu/drm/ttm/ttm_execbuf_util.c
@@ -32,8 +32,7 @@
#include
#include
-static void ttm_eu_backoff_reservation_locked(struct list_head *list,
- struct ww_acquire_ctx *ticket)
+static void ttm_eu_backoff_reservation_locked(struct list_head *list)
{
struct ttm_validate_buffer *entry;
@@ -93,8 +92,9 @@ void ttm_eu_backoff_reservation(struct ww_acquire_ctx *ticket,
entry = list_first_entry(list, struct ttm_validate_buffer, head);
glob = entry->bo->glob;
spin_lock(&glob->lru_lock);
- ttm_eu_backoff_reservation_locked(list, ticket);
- ww_acquire_fini(ticket);
+ ttm_eu_backoff_reservation_locked(list);
+ if (ticket)
+ ww_acquire_fini(ticket);
spin_unlock(&glob->lru_lock);
}
EXPORT_SYMBOL(ttm_eu_backoff_reservation);
@@ -130,7 +130,8 @@ int ttm_eu_reserve_buffers(struct ww_acquire_ctx *ticket,
entry = list_first_entry(list, struct ttm_validate_buffer, head);
glob = entry->bo->glob;
- ww_acquire_init(ticket, &reservation_ww_class);
+ if (ticket)
+ ww_acquire_init(ticket, &reservation_ww_class);
retry:
list_for_each_entry(entry, list, head) {
struct ttm_buffer_object *bo = entry->bo;
@@ -139,16 +140,17 @@ retry:
if (entry->reserved)
continue;
-
- ret = ttm_bo_reserve_nolru(bo, true, false, true, ticket);
+ ret = ttm_bo_reserve_nolru(bo, true, (ticket == NULL), true,
+ ticket);
if (ret == -EDEADLK) {
/* uh oh, we lost out, drop every reservation and try
* to only reserve this buffer, then start over if
* this succeeds.
*/
+ BUG_ON(ticket == NULL);
spin_lock(&glob->lru_lock);
- ttm_eu_backoff_reservation_locked(list, ticket);
+ ttm_eu_backoff_reservation_locked(list);
spin_unlock(&glob->lru_lock);
ttm_eu_list_ref_sub(list);
ret = ww_mutex_lock_slow_interruptible(&bo->resv->lock,
@@ -175,7 +177,8 @@ retry:
}
}
- ww_acquire_done(ticket);
+ if (ticket)
+ ww_acquire_done(ticket);
spin_lock(&glob->lru_lock);
ttm_eu_del_from_lru_locked(list);
spin_unlock(&glob->lru_lock);
@@ -184,12 +187,14 @@ retry:
err:
spin_lock(&glob->lru_lock);
- ttm_eu_backoff_reservation_locked(list, ticket);
+ ttm_eu_backoff_reservation_locked(list);
spin_unlock(&glob->lru_lock);
ttm_eu_list_ref_sub(list);
err_fini:
- ww_acquire_done(ticket);
- ww_acquire_fini(ticket);
+ if (ticket) {
+ ww_acquire_done(ticket);
+ ww_acquire_fini(ticket);
+ }
return ret;
}
EXPORT_SYMBOL(ttm_eu_reserve_buffers);
@@ -224,7 +229,8 @@ void ttm_eu_fence_buffer_objects(struct ww_acquire_ctx
*ticket,
}
spin_unlock(&bdev->fence_lock);
spin_unlock(&glob->lru_lock);
- ww_acquire_fini(ticket);
+ if (ticket)
+ ww_acquire_fini(ticket);
list_for_each_entry(entry, list, head) {
if (entry->old_sync_obj)
diff --git a/include/drm/ttm/ttm_execbuf_util.h
b/include/drm/ttm/ttm_execbuf_util.h
index ec8a1d3..16db7d0 100644
--- a/include/drm/ttm/ttm_execbuf_util.h
+++ b/include/drm/ttm/ttm_execbuf_util.h
@@ -70,7 +70,8 @@ extern void ttm_eu_backoff_reservation(struct ww_acquire_ctx
*ticket,
/**
* function ttm_eu_reserve_buffers
*
- * @ticket: [out] ww_acquire_ctx returned by call.
+ * @ticket: [out] ww_acquire_ctx filled in by call, or NULL if only
+ * non-blocking reserves should be tried.
* @list:thread private list of ttm_validate_buffer structs.
*
* Tries to reserve bos pointed to by the list entries for validation.
--
1.7.10.4
[PATCH 0/2] Fix a false lockdep warning on vmwgfx
The commit "drm/ttm: make ttm reservation calls behave like reservation calls" introduced a false lockdep warning on vmwgfx that hit on surface eviction, due to a recursive reservation. The fix silences the warning by using a tryreserve, which is not optimal, but will do for now
