[Bug 71285] Xonotic LLVM ERROR
https://bugs.freedesktop.org/show_bug.cgi?id=71285 --- Comment #5 from darkbasic --- The problem is only with the "offset mapping" effect enabled. Radeonsi (HD 7950) + LLVM 3.4 git + mesa 10.1 git + linux 3.13 -- 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/20131118/3b36a255/attachment.html>
[Bug 71697] [radeonsi] gtkperf hangs the system
https://bugs.freedesktop.org/show_bug.cgi?id=71697 --- Comment #6 from Thue Janus Kristensen --- > So slow that it doesn't even switch to a virtual terminal with CTRL+ALT+F1? I could switch to a virtual terminal on my system. But X11 itself was frozen for a good while. -- 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/20131118/f0b7a8f7/attachment.html>
[Bug 71285] Xonotic LLVM ERROR
https://bugs.freedesktop.org/show_bug.cgi?id=71285 --- Comment #6 from Rafael Castillo --- confirmed offset mapping is the culprit -- 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/20131118/c6077170/attachment.html>
[Bug 71516] [SOLVED] RV350 Radeon 9550 - no Unity 3D hardware support in Ubuntu 13.10, extremely slow
https://bugs.freedesktop.org/show_bug.cgi?id=71516 Michel D?nzer changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |NOTOURBUG --- Comment #19 from Michel D?nzer --- I think you need to work this out downstream with Ubuntu. -- 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/20131118/af56e1c1/attachment.html>
[Bug 71239] Metro Last Light quits(?) on r600g
https://bugs.freedesktop.org/show_bug.cgi?id=71239 --- Comment #14 from Tapani P?lli --- I've been testing this with Mesa master (2cfbf84) on IVB ultrabook. There's quite a lot of rendering artifacts here and there, my findings so far: 1. all lighting and shadows are missing making the game look terrible 2. a flash of 'outside world' visible in the metro tunnel when game menu comes up 3. text/graphics missing from game menus 4. sudden graphics glitches, looks like parts of low resolution fbo rendered on top of scene now and then when moving the camera 5. flashes of objects rendered with solid red color (just when they become visible for the first time?) Following errors seen on console: Mesa: User error: GL_INVALID_ENUM in glTexParameter(pname=GL_TEXTURE_LOD_BIAS) will continue investigation on what's wrong -- 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/20131118/c20ce164/attachment.html>
[Bug 69675] audio broken in 24Hz/24p since 3.11 (regression)
https://bugs.freedesktop.org/show_bug.cgi?id=69675 --- Comment #52 from Pierre Ossman --- (In reply to comment #51) > Sorry, to warm up this thread. I have also seen that 24p playback is now > "working" again. If one measure the audio vs the video clock. One is approx > 10ms behind per 6 seconds, which is compensated by "Duplicating package" or > "resampling" if your player supports this. 10 ms per 6 seconds sounds very close to the 24 vs 24/1.001 difference (which is 10 ms per 10 seconds). Assuming you've gotten the correct mode configured, that would mean the audio clock in the card is misconfigured. The rounding error on the pixel clock is several magnitudes smaller, so it doesn't sound like that. You should be able to tell which clock is off if you measure both against the CPU clock. > I tried to play with register 0x05b4 and 0x05b8 but could not find a ratio > so that the drops would stop. Not sure if this is related to the original > problem though. Probably not. If I've understood things correctly, then the ACR is fairly independent from the more actual audio handling. So a new bug entry is probably in order. -- 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/20131118/b3ece3f5/attachment-0001.html>
[Bug 71723] New: [GLSL] Sampler arrays indexed with non-constant expressions
https://bugs.freedesktop.org/show_bug.cgi?id=71723 Priority: medium Bug ID: 71723 Assignee: dri-devel at lists.freedesktop.org Summary: [GLSL] Sampler arrays indexed with non-constant expressions Severity: normal Classification: Unclassified OS: Linux (All) Reporter: vluchits at gmail.com Hardware: x86-64 (AMD64) Status: NEW Version: 9.2 Component: Drivers/DRI/Radeon Product: Mesa Created attachment 89383 --> https://bugs.freedesktop.org/attachment.cgi?id=89383&action=edit Test vertex shader Hello, in my opinion GLSL compiler in mesa is too restrictive when it comes to sampler arrays. The attached vertex shader can not be compiled due to the "sampler arrays indexed with non-constant expressions is forbidden in GLSL 1.30 and later": Lines 159-136 of src/glsl/ast_array_index.cpp say: * This restriction was added in GLSL 1.30. Shaders using earlier version * of the language should not be rejected by the compiler front-end for * using this construct. This allows useful things such as using a loop * counter as the index to an array of samplers. If the loop in unrolled, * the code should compile correctly. Instead, emit a warning. If compiler actually attempted to unroll the loop above, it would notice that the code does compile correctly in that case. Instead it just emits and error and, in my opinion, contradicts the comment above by not allowing the aforementioned "useful thing". Can the compiler be changed to _first_ attempt to unroll the loop and then check for sampler array indices being constants? -- 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/20131118/798dd658/attachment.html>
[PATCH 2/2] drm/radeon/cik: Add macrotile mode array query
From: Michel D?nzer
Signed-off-by: Michel D?nzer
---
drivers/gpu/drm/radeon/cik.c| 3 +++
drivers/gpu/drm/radeon/radeon.h | 1 +
drivers/gpu/drm/radeon/radeon_drv.c | 3 ++-
drivers/gpu/drm/radeon/radeon_kms.c | 9 +
include/uapi/drm/radeon_drm.h | 2 ++
5 files changed, 17 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
index ae92aa0..8e440a4 100644
--- a/drivers/gpu/drm/radeon/cik.c
+++ b/drivers/gpu/drm/radeon/cik.c
@@ -2427,6 +2427,7 @@ static void cik_tiling_mode_table_init(struct
radeon_device *rdev)
gb_tile_moden = 0;
break;
}
+ rdev->config.cik.macrotile_mode_array[reg_offset] =
gb_tile_moden;
WREG32(GB_MACROTILE_MODE0 + (reg_offset * 4),
gb_tile_moden);
}
} else if (num_pipe_configs == 4) {
@@ -2773,6 +2774,7 @@ static void cik_tiling_mode_table_init(struct
radeon_device *rdev)
gb_tile_moden = 0;
break;
}
+ rdev->config.cik.macrotile_mode_array[reg_offset] =
gb_tile_moden;
WREG32(GB_MACROTILE_MODE0 + (reg_offset * 4),
gb_tile_moden);
}
} else if (num_pipe_configs == 2) {
@@ -2990,6 +2992,7 @@ static void cik_tiling_mode_table_init(struct
radeon_device *rdev)
gb_tile_moden = 0;
break;
}
+ rdev->config.cik.macrotile_mode_array[reg_offset] =
gb_tile_moden;
WREG32(GB_MACROTILE_MODE0 + (reg_offset * 4),
gb_tile_moden);
}
} else
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index b9ee992..8bdfc88 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -1979,6 +1979,7 @@ struct cik_asic {
unsigned tile_config;
uint32_t tile_mode_array[32];
+ uint32_t macrotile_mode_array[16];
};
union radeon_asic_config {
diff --git a/drivers/gpu/drm/radeon/radeon_drv.c
b/drivers/gpu/drm/radeon/radeon_drv.c
index 1aee322..9f5ff28 100644
--- a/drivers/gpu/drm/radeon/radeon_drv.c
+++ b/drivers/gpu/drm/radeon/radeon_drv.c
@@ -76,9 +76,10 @@
* 2.32.0 - new info request for rings working
* 2.33.0 - Add SI tiling mode array query
* 2.34.0 - Add CIK tiling mode array query
+ * 2.35.0 - Add CIK macrotile mode array query
*/
#define KMS_DRIVER_MAJOR 2
-#define KMS_DRIVER_MINOR 34
+#define KMS_DRIVER_MINOR 35
#define KMS_DRIVER_PATCHLEVEL 0
int radeon_driver_load_kms(struct drm_device *dev, unsigned long flags);
int radeon_driver_unload_kms(struct drm_device *dev);
diff --git a/drivers/gpu/drm/radeon/radeon_kms.c
b/drivers/gpu/drm/radeon/radeon_kms.c
index fa42c81..55d0b47 100644
--- a/drivers/gpu/drm/radeon/radeon_kms.c
+++ b/drivers/gpu/drm/radeon/radeon_kms.c
@@ -449,6 +449,15 @@ int radeon_info_ioctl(struct drm_device *dev, void *data,
struct drm_file *filp)
return -EINVAL;
}
break;
+ case RADEON_INFO_CIK_MACROTILE_MODE_ARRAY:
+ if (rdev->family >= CHIP_BONAIRE) {
+ value = rdev->config.cik.macrotile_mode_array;
+ value_size = sizeof(uint32_t)*16;
+ } else {
+ DRM_DEBUG_KMS("macrotile mode array is cik+ only!\n");
+ return -EINVAL;
+ }
+ break;
case RADEON_INFO_SI_CP_DMA_COMPUTE:
*value = 1;
break;
diff --git a/include/uapi/drm/radeon_drm.h b/include/uapi/drm/radeon_drm.h
index 46d41e8..2f3f7ea 100644
--- a/include/uapi/drm/radeon_drm.h
+++ b/include/uapi/drm/radeon_drm.h
@@ -981,6 +981,8 @@ struct drm_radeon_cs {
#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 {
--
1.8.4.3
[PATCH 1/2] drm/radeon/cik: Return backend map information to userspace
From: Michel D?nzer Signed-off-by: Michel D?nzer --- drivers/gpu/drm/radeon/radeon_kms.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/radeon/radeon_kms.c b/drivers/gpu/drm/radeon/radeon_kms.c index bb87105..fa42c81 100644 --- a/drivers/gpu/drm/radeon/radeon_kms.c +++ b/drivers/gpu/drm/radeon/radeon_kms.c @@ -340,7 +340,7 @@ int radeon_info_ioctl(struct drm_device *dev, void *data, struct drm_file *filp) break; case RADEON_INFO_BACKEND_MAP: if (rdev->family >= CHIP_BONAIRE) - return -EINVAL; + *value = rdev->config.cik.backend_map; else if (rdev->family >= CHIP_TAHITI) *value = rdev->config.si.backend_map; else if (rdev->family >= CHIP_CAYMAN) -- 1.8.4.3
[PATCH 1/2] radeon: fix mipmap level 0 and 1 alignment for SI and CIK
On Fre, 2013-11-15 at 18:55 +0100, Marek Ol??k wrote: > From: Michel D?nzer > > Signed-off-by: Marek Ol??k [...] > @@ -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; This hunk should be in patch 2. Other than that, the series is Reviewed-and-Tested-by: Michel D?nzer However, patch 2 also depends on the corresponding kernel support, which I just submitted. Thanks for ironing out the kinks of this, Marek! -- Earthling Michel D?nzer| http://www.amd.com Libre software enthusiast |Mesa and X developer
[Bug 65141] New: Blank screen after resume with radeon driver
https://bugzilla.kernel.org/show_bug.cgi?id=65141 Bug ID: 65141 Summary: Blank screen after resume with radeon driver Product: Drivers Version: 2.5 Kernel Version: 3.7,3.11,3.12 Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri at kernel-bugs.osdl.org Reporter: tiwai at suse.de Regression: No Created attachment 115031 --> https://bugzilla.kernel.org/attachment.cgi?id=115031&action=edit dmesg output with drm.debug=0x0e Reported at openSUSE bugzilla https://bugzilla.novell.com/show_bug.cgi?id=841822 The original bug report: Toshiba P775D-S7230 AMD APU A4, resume from suspend leaves screen "black". WHen I compiled and installed the proprietary AMD driver (13.8B2), it works fine. Same behavior on 12.3 as well. Reproducible: Always Steps to Reproduce: 1. Make sure AMD FOSS driver is loaded 2. Suspend (to ram or disk) 3. Resume 4. Screen is blank, machine is "resumed" Actual Results: The machine appears to be in a working state, but the screen is black Expected Results: Full function resume from suspend with video Compiling and installing the AMD proprietary driver (13.8B2) works. === The problem is seen without X, too. Reproduced on (openSUSE) 12.3 means that kernel 3.7 had already the problem. openSUSE 13.1 uses 3.11.x kernel, and the reporter tested 3.12 kernel, too. The full dmesg with drm.debug=0x0e after S4 resume is attached. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 65141] Blank screen after resume with radeon driver
https://bugzilla.kernel.org/show_bug.cgi?id=65141 Takashi Iwai changed: What|Removed |Added URL||https://bugzilla.novell.com ||/show_bug.cgi?id=841822 -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH] drm: Don't split up debug output
On Sun, Nov 17, 2013 at 10:25:02PM +0100, Daniel Vetter wrote:
> Otherwise we risk that the 2nd part of the line ends up on a line of
> it's own, which means a kernel dmesg line without a log level. This
> then upsets the dmesg checker in piglit.
>
> Only really happens in some of the truly nasty igt testcases which
> race cache dropping (through debugfs) with other gem operations.
>
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_stub.c | 12 +---
> 1 file changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_stub.c b/drivers/gpu/drm/drm_stub.c
> index f53d5246979c..74e0357c1c38 100644
> --- a/drivers/gpu/drm/drm_stub.c
> +++ b/drivers/gpu/drm/drm_stub.c
> @@ -99,13 +99,19 @@ void drm_ut_debug_printk(unsigned int request_level,
>const char *function_name,
>const char *format, ...)
> {
> + struct va_format vaf;
> va_list args;
>
> if (drm_debug & request_level) {
> - if (function_name)
> - printk(KERN_DEBUG "[%s:%s], ", prefix, function_name);
> va_start(args, format);
> - vprintk(format, args);
> + vaf.fmt = format;
> + vaf.va = &args;
> +
> + if (function_name)
> + printk(KERN_DEBUG "[%s:%s], %pV", prefix,
> +function_name, &vaf);
> + else
> + printk(KERN_DEBUG "%pV", &vaf);
> va_end(args);
> }
> }
According to Documentation/printk-formats.txt, usage of %pV is not
recommended unless the format string and va_list can be properly
verified for correctness.
I guess we leave it up to the compiler to do that verification using the
__printf() annotation, so I think it should be fine to use it here:
Reviewed-by: Thierry Reding
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131118/41a49856/attachment-0001.pgp>
[PATCH 0/5] R-Car DU fixes and support for R8A7791
Hi Simon, On Monday 18 November 2013 17:23:11 Simon Horman wrote: > Hi Laurent, > > I am wondering if you have any patches to wire up this driver > for the Koelsch board so that I might test it. Here you go. git://linuxtv.org/pinchartl/fbdev.git drm/du/koelsch Only the LVDS output is currently supported. > On Wed, Nov 13, 2013 at 02:52:10PM +0100, Laurent Pinchart wrote: > > Hello, > > > > This patch series adds support for the DU found in the R8A7791 SoC. It > > starts by a cleanup patch (1/5), a bug fix (2/5), two preparation patches > > (3/5 and 4/5) and finally adds support for the R8A7791 DU (5/5). > > > > Patch 2/5 is a candidate for stable kernels. There's no rush to get this > > upstreamed in v3.13, v3.14 is fine. > > > > The series is based on top of the latest drm-next branch. > > > > Laurent Pinchart (5): > > drm/rcar-du: Don't cast crtc to rcrtc twice in the same function > > drm/rcar-du: Update plane pitch in .mode_set_base() operation > > drm/rcar-du: Split features and quirks > > drm/rcar-du: Add LVDS_LANES quirk > > drm/rcar-du: Add support for the r8a7791 DU > > > > drivers/gpu/drm/rcar-du/rcar_du_crtc.c| 3 +-- > > drivers/gpu/drm/rcar-du/rcar_du_drv.c | 24 ++-- > > drivers/gpu/drm/rcar-du/rcar_du_drv.h | 14 -- > > drivers/gpu/drm/rcar-du/rcar_du_kms.c | 4 ++-- > > drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c | 15 ++- > > drivers/gpu/drm/rcar-du/rcar_du_plane.c | 21 +++-- > > 6 files changed, 58 insertions(+), 23 deletions(-) -- Regards, Laurent Pinchart
[PATCH v3 1/7] drm: Add DSI bus infrastructure
On Thu, Nov 14, 2013 at 03:04:19PM +, Bert Kenward wrote:
> On 11/14/2013 14:16, Andrzej Hajda wrote:
> > On 11/13/2013 10:38 PM, Thierry Reding wrote:
> > > Furthermore I think if we kept the transfer function proposed
> > > in my patch should make it easier to address Bert's comments from your
> > > posting.
> > I am not sure which part of Barts comment you are addressing.
> > Anyway I also prefer passing struct and returning ssize_t.
> > I am not sure about splitting type and channel but this seems to be a
> > minor detail.
>
> Most of the comments I made about Andrzej's patch from last month
> apply here, and would result in extensions to struct dsi_msg. Some
> means of choosing whether the transfer should be in HS or LP mode is
> necessary. For video mode panels some means of specifying a period
> (VFP, VBP, etc) for sending the transfer is needed. Perhaps struct
> dsi_msg should include:
>
> #define DSI_WINDOW_VFP (1 << 0)
> #define DSI_WINDOW_ACT (1 << 1)
> #define DSI_WINDOW_VBP (1 << 2)
> #define DSI_WINDOW_VSY (1 << 3)
>
> /**
> * struct dsi_msg - DSI command message
> * @channel: virtual channel to send the message to
> * @type: data ID of the message
> * @lp_mode: send in LP mode if non-zero
Perhaps a flags field would be more flexible here. I can easily imagine
other I can imagine that other flags may be needed eventually.
> * @window: video period when transfer is allowed - bitmask of DSI_WINDOW_*
I'm not sure if this is the right interface. What will happen for
instance if the hardware doesn't support any of the bits in that mask?
Perhaps a slightly better approach might be to expose the capabilities
of the DSI host, so that the DSI core knows up front which windows can
be used.
> * @tx_len: length of transmission buffer
> * @tx: transmission buffer
> * @rx_len: length of reception buffer
> * @rx: reception buffer
> */
> struct dsi_msg {
> u8 channel;
> u8 type;
> u8 lp_mode;
> u8 window;
>
> size_t tx_len;
> void *tx;
>
> size_t rx_len;
> void *rx;
> };
>
> The ability to specify synchronisation with a tearing effect control
> signal for a command mode panel is obviously important. It's somewhat
> analogous to the "window" option for video mode.
>
> They're little used, but a mechanism for sending triggers should be
> included. They're probably sufficiently different that it should be a
> different op.
I agree. While I currently have no use-case where this is required, I
think having a struct dsi_msg makes it easier to extend the featureset
on an as-needed basis.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131118/94e107dd/attachment.pgp>
[Bug 69675] audio broken in 24Hz/24p since 3.11 (regression)
https://bugs.freedesktop.org/show_bug.cgi?id=69675 --- Comment #53 from Rainer Hochecker --- We did measure system clock against refresh rate. When running at 50hz or 60hz, refresh rate seems to be fast whereas when running at 24 is is behind. Means that not only 24hz is affected but all refresh rates. -- 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/20131118/510216fe/attachment.html>
[PATCH] drm/ttm: Don't move non-existing data
- Original Message -
> If ttm_bo_move_memcpy was instructed to move a non-populated ttm to
> io memory, it would first populate the ttm, then move the data and then
> destroy the ttm. That's stupid. However, some drivers might have relied on
> this to clear io memory from old stuff. So instead of a NOP, which would
> be the most efficient, just clear the destination.
>
> Signed-off-by: Thomas Hellstrom
Reviewed-by: Jakob Bornecrantz
Cheers, Jakob.
> ---
> drivers/gpu/drm/ttm/ttm_bo_util.c |7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
> b/drivers/gpu/drm/ttm/ttm_bo_util.c
> index 4834c46..15b86a9 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo_util.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
> @@ -350,10 +350,13 @@ int ttm_bo_move_memcpy(struct ttm_buffer_object *bo,
> goto out2;
>
> /*
> - * Move nonexistent data. NOP.
> + * Don't move nonexistent data. Clear destination instead.
>*/
> - if (old_iomap == NULL && ttm == NULL)
> + if (old_iomap == NULL &&
> + (ttm == NULL || ttm->state == tt_unpopulated)) {
> + memset_io(new_iomap, 0, new_mem->num_pages*PAGE_SIZE);
> goto out2;
> + }
>
> /*
>* TTM might be null for moves within the same region.
> --
> 1.7.10.4
>
[Bug 71488] RadeonSI :Regression: Massive Desktop corruption observed on starting the X server
https://bugs.freedesktop.org/show_bug.cgi?id=71488 --- Comment #7 from samit vats --- Here are the regression details Pass : xf86-video-ati-0c921edf(31st Oct) Fail : xf86-video-ati-e4cd0f43(4th Nov) with Mesa-10.0.0-devel(git-6c6f4aa) -- 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/20131118/c643902b/attachment.html>
[PATCH v3 1/7] drm: Add DSI bus infrastructure
On 11/18/2013 11:22, Thierry Reding wrote: > On Thu, Nov 14, 2013 at 03:04:19PM +, Bert Kenward wrote: > > #define DSI_WINDOW_VFP (1 << 0) > > #define DSI_WINDOW_ACT (1 << 1) > > #define DSI_WINDOW_VBP (1 << 2) > > #define DSI_WINDOW_VSY (1 << 3) > > > > /** > > * struct dsi_msg - DSI command message > > * @channel: virtual channel to send the message to > > * @type: data ID of the message > > * @lp_mode: send in LP mode if non-zero > > Perhaps a flags field would be more flexible here. I can easily imagine > other I can imagine that other flags may be needed eventually. Agreed. "TE synchronised" would be one such extra flag, for supporting command mode updates. > > * @window: video period when transfer is allowed - bitmask of > DSI_WINDOW_* > > I'm not sure if this is the right interface. What will happen for > instance if the hardware doesn't support any of the bits in that mask? > Perhaps a slightly better approach might be to expose the capabilities > of the DSI host, so that the DSI core knows up front which windows can > be used. Exposing the capabilities seems like the smart thing to do, certainly - but you'd still need a way to specify which of those capabilities you want to use for each transfer. I'd suggest that hardware would ignore bits that it couldn't support - in the limit, hardware that has no way to choose when to send a command during video would ignore this completely. I realise that could well cause confusion when trying to work out why a particularly display is misbehaving when you think you're sending commands at the right time. Bert. -- Bert Kenward Software Engineer Broadcom Mobile Platform Solutions Cambridge, UK
[PATCH v3 1/7] drm: Add DSI bus infrastructure
On Mon, Nov 18, 2013 at 11:59:23AM +, Bert Kenward wrote: > On 11/18/2013 11:22, Thierry Reding wrote: > > On Thu, Nov 14, 2013 at 03:04:19PM +, Bert Kenward wrote: > > > #define DSI_WINDOW_VFP (1 << 0) > > > #define DSI_WINDOW_ACT (1 << 1) > > > #define DSI_WINDOW_VBP (1 << 2) > > > #define DSI_WINDOW_VSY (1 << 3) > > > > > > /** > > > * struct dsi_msg - DSI command message > > > * @channel: virtual channel to send the message to > > > * @type: data ID of the message > > > * @lp_mode: send in LP mode if non-zero > > > > Perhaps a flags field would be more flexible here. I can easily imagine > > other I can imagine that other flags may be needed eventually. > > Agreed. "TE synchronised" would be one such extra flag, for supporting > command mode updates. > > > > * @window: video period when transfer is allowed - bitmask of > > DSI_WINDOW_* > > > > I'm not sure if this is the right interface. What will happen for > > instance if the hardware doesn't support any of the bits in that mask? > > Perhaps a slightly better approach might be to expose the capabilities > > of the DSI host, so that the DSI core knows up front which windows can > > be used. > > Exposing the capabilities seems like the smart thing to do, certainly > - but you'd still need a way to specify which of those capabilities > you want to use for each transfer. Yes. I think we'll still need to have that. It's just that for some transfers it doesn't matter during which window they are executed. Although I guess in those cases the caller could just specify all bits to signal that it doesn't care. > I'd suggest that hardware would ignore bits that it couldn't support - > in the limit, hardware that has no way to choose when to send a > command during video would ignore this completely. I realise that > could well cause confusion when trying to work out why a particularly > display is misbehaving when you think you're sending commands at the > right time. I think at the very least if there's no match between the requested set of windows and the ones that a particular DSI host supports, then the driver should report an error. The reason why I thought that exposing the capabilities might be useful is that the caller could be smart about how to transfer a message, or perhaps use different messages to the same effect. But perhaps that's not even possible and maybe not worth considering. A smart thing to do in my opinion will be to not try to overengineer this from the beginning. That's why I'm thinking of splitting out the whose dsi_msg support in a first step, so that the bus infrastructure can be merged without having discussed all possible cases. And even so dsi_msg doesn't have to be perfect from the start. It's an in-kernel API, therefore can change easily if needed. The less we require of it now the easier it will be to extend when the need arises. Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131118/ccbecb2d/attachment-0001.pgp>
[Bug 71723] Sampler arrays indexed with non-constant expressions
https://bugs.freedesktop.org/show_bug.cgi?id=71723 Victor Luchits changed: What|Removed |Added Assignee|dri-devel at lists.freedesktop |idr at freedesktop.org |.org| QA Contact||intel-3d-bugs at lists.freedes ||ktop.org Summary|[GLSL] Sampler arrays |Sampler arrays indexed with |indexed with non-constant |non-constant expressions |expressions | Component|Drivers/DRI/Radeon |glsl-compiler -- 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/20131118/d541f6a9/attachment.html>
[PATCH v3 1/7] drm: Add DSI bus infrastructure
On Thu, Nov 14, 2013 at 03:15:57PM +0100, Andrzej Hajda wrote: > Hi Thierry, > > On 11/13/2013 10:38 PM, Thierry Reding wrote: > > On Tue, Nov 12, 2013 at 03:14:22PM +0100, Andrzej Hajda wrote: > >> Hi Thierry, > >> > >> I have already sent patch with DSI bus implementation [1]. > >> It was posted as the first step of CDF implementation attempt, > >> but in fact it do not depend on CDF. > >> > >> [1] > >> http://www.mail-archive.com/dri-devel at > >> lists.freedesktop.org/msg45252.html > > Seems like that patchset was never merged. I guess probably because it > > was posted as part of CDF work. > > > > Do you have any plans on continuing work on that?If not I could extract > > the DSI bus patch from the series, it's largely similar to the patch I > > proposed here, and rework it somewhat. > I will soon sent new patch with the current version of the bus. > It could be a better base to your rework. Any estimate on when this will be? I want to get started on this as soon as possible so we can get this in good shape for 3.14. I suspect that if I start based on the current patch, I won't have to redo everything when updating for the next version. Quite a bit should remain similar, right? > > I'd very much like to avoid > > putting the code in drivers/video, though, since that's considered > > obsolete. > I have followed convention proposed by Laurent in his DBI bus. > It seems to me OK - DSI bus is more related to video than to drm. > I know that drivers/video is mostly occupied by FB drivers, > but according to Kconfig it is not only for FB. > Of course this is only my suggestion. I've had an IRC discussion with Dave and Rob (added on Cc), and they both agreed that implementing it as part of DRM would be preferred. The reason, as I've said before, is primarily that drivers/video is considered obsolete and new drivers and features should be implemented within the context of DRM/KMS. Additionally this has the benefit of being able to reuse the native DRM data structures and types, as well as helper functions, without having to go through an extra layer of compatibility. > > Furthermore I think if we kept the transfer function proposed > > in my patch should make it easier to address Bert's comments from your > > posting. > I am not sure which part of Barts comment you are addressing. > Anyway I also prefer passing struct and returning ssize_t. > I am not sure about splitting type and channel but this seems to be a > minor detail. I find that to be a perfectly natural split. A DSI peripheral will have an associated virtual channel number anyway, and having a separate field will allow drivers to just copy that field into the dsi_msg's equivalent. The alternative would be to require each driver to properly encode the channel and data type. Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131118/4647e53c/attachment.pgp>
[Mesa-dev] rules for merging patches to libdrm
On Sat, Nov 09, 2013 at 01:26:24PM -0800, Ian Romanick wrote: > On 11/09/2013 12:11 AM, Dave Airlie wrote: > >>> How does this interact with the rule that kernel interfaces require an > >>> open source userspace? Is "here are the mesa/libdrm patches that use > >>> it" sufficient to get the kernel interface merged? > >> > >> That's my understanding: open source userspace needs to exist, but it > >> doesn't need to be merged upstream yet. > > > > Having an opensource userspace and having it committed to a final repo > > are different things, as Daniel said patches on the mesa-list were > > sufficient, they're was no hurry to merge them considering a kernel > > release with the code wasn't close, esp with a 3 month release window > > if the kernel merge window is close to that anyways. > > > >>> libdrm is easy to change and its releases are cheap. What problem does > >>> committing code that uses an in-progress kernel interface to libdrm > >>> cause? I guess I'm not understanding something. > >> > > > > Releases are cheap, but ABI breaks aren't so you can't just go release > > a libdrm with an ABI for mesa then decide later it was a bad plan. > > > >> Introducing new kernel API usually involves assigning numbers for things > >> - a new ioctl number, new #defines for bitfield members, and so on. > >> > >> Multiple patches can be in flight at the same time. For example, Abdiel > >> and I both defined execbuf2 flags: > >> > >> #define I915_EXEC_RS (1 << 13) (Abdiel's code) > >> #define I915_EXEC_OA (1 << 13) (my code) > >> > >> These obviously conflict. One of the two will land, and the second > >> patch author will need to switch to (1 << 14) and resubmit. > >> > >> If we both decide to push to libdrm, we might get the order backwards, > >> or maybe one series won't get pushed at all (in this case, I'm planning > >> to drop my patch). Waiting until one lands in the kernel avoids that > >> problem. Normally, I believe we copy the kernel headers to userspace > >> and fix them up a bit. > >> > >> Dave may have other reasons; this is just the one I thought of. > > > > But mostly this, we've been stung by this exact thing happening > > before, and we made the process to stop it from happening again. > > Then in all honestly, commits to libdrm should be controlled by either a > single person or a small cabal... just like the kernel and the xserver. > We're clearly in an uncomfortable middle area where we have a stringent > set of restrictions but no way to actually enforce them. That doesn't sound like a bad idea at all. It obviously causes more work for whoever will be the gatekeeper(s). It seems to me that libdrm is currently more of a free-for-all type of project, and whoever merges some new feature required for a particular X or Mesa driver cuts a new release so that the version number can be used to track the dependency. I wonder if perhaps tying the libdrm releases more tightly to Linux kernel releases would help. Since there already is a requirement for new kernel APIs to be merged before the libdrm equivalent can be merged, then having both release cycles in lockstep makes some sense. Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131118/d3912c84/attachment.pgp>
[PATCH 1/2] drm/dp: add eDP 1.2 display control DPCD register definitions
On Fri, Nov 15, 2013 at 03:01:50PM +0200, Jani Nikula wrote: > Preparing for the future eDP panels. > > Signed-off-by: Jani Nikula > --- > include/drm/drm_dp_helper.h | 29 + > 1 file changed, 29 insertions(+) Reviewed-by: Thierry Reding -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131118/e18e0f22/attachment.pgp>
[Bug 71681] some artefacts on X1250 with desktop elements drawn badly and screen blinks
https://bugs.freedesktop.org/show_bug.cgi?id=71681 --- Comment #6 from Dmytro --- hi there. i haven't"bisect" anything yet but found one more similar case: http://askubuntu.com/questions/366596/unity-desktop-displays-strange-lines -- 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/20131118/031f29cc/attachment.html>
[Bug 71681] some artefacts on X1250 with desktop elements drawn badly and screen blinks
https://bugs.freedesktop.org/show_bug.cgi?id=71681 --- Comment #7 from Dmytro --- meybe it helps but this was the same behavior and picture with Ubuntu 12.04 LTS and Ubuntu 13.10 freshly installed from LiveCD. The only difference was that blinking screen on video played and scrolling was persistent in 12.04 and appears in 13.10 only after system wakes up from "suspend" mode -- 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/20131118/59d34eb2/attachment-0001.html>
[PATCH 1/2] drm/radeon/cik: Return backend map information to userspace
On Mon, Nov 18, 2013 at 4:25 AM, Michel D?nzer wrote: > From: Michel D?nzer > > Signed-off-by: Michel D?nzer Both patches applied to my tree. Thanks! Alex > --- > drivers/gpu/drm/radeon/radeon_kms.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/radeon/radeon_kms.c > b/drivers/gpu/drm/radeon/radeon_kms.c > index bb87105..fa42c81 100644 > --- a/drivers/gpu/drm/radeon/radeon_kms.c > +++ b/drivers/gpu/drm/radeon/radeon_kms.c > @@ -340,7 +340,7 @@ int radeon_info_ioctl(struct drm_device *dev, void *data, > struct drm_file *filp) > break; > case RADEON_INFO_BACKEND_MAP: > if (rdev->family >= CHIP_BONAIRE) > - return -EINVAL; > + *value = rdev->config.cik.backend_map; > else if (rdev->family >= CHIP_TAHITI) > *value = rdev->config.si.backend_map; > else if (rdev->family >= CHIP_CAYMAN) > -- > 1.8.4.3 > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/i915/dp: check eDP display control capability registers
On Fri, Nov 15, 2013 at 03:01:51PM +0200, Jani Nikula wrote:
> 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(+)
I have a few general comments below, but this patch itself look fine,
so:
Reviewed-by: Thierry Reding
> 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] &
I think a lot of eDP utility code could be made reusable across drivers.
We could probably do that by having each driver expose a drm_edp object
of some sort.
Actually, the same would be true of DP in general. Accessing the DPCD is
something that's driver specific, but once you know how to do that a lot
of code can be made generic. I think a struct drm_dp could look like
this:
struct drm_dp;
struct drm_dpcd_ops {
ssize_t (*read)(struct drm_dp *dp, unsigned int offset,
void *buffer, size_t size);
ssize_t (*write)(struct drm_dp *dp, unsigned int offset,
const void *buffer, size_t size);
};
struct drm_dp {
const struct drm_dpcd_ops *dpcd;
};
Perhaps that could even be extended with functionality to implement link
training in a generic way. There are already quite a few helpers to help
with that in drivers/gpu/drm/drm_dp_helper.c, but they assume that the
DPCD will be handed to them as a large buffer and therefore cannot write
DPCD registers.
I suppose one could argue that it would be introducing a mid-layer, but
that layer would be really thin in my opinion. And it would allow a lot
of the algorithms to be written only once instead of multiple times.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131118/e9a02036/attachment.pgp>
[PATCH] radeon: don't overallocate stencil by 4 on SI and CIK
From: Michel D?nzer Signed-off-by: Marek Ol??k --- radeon/radeon_surface.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/radeon/radeon_surface.c b/radeon/radeon_surface.c index 927a21e..cd5cbd6 100644 --- a/radeon/radeon_surface.c +++ b/radeon/radeon_surface.c @@ -1435,16 +1435,17 @@ static void si_surf_minify(struct radeon_surface *surf, */ if (level == 0 && surf->last_level == 0) /* Non-mipmap pitch padded to slice alignment */ +/* Using just bpe here breaks stencil blitting; surf->bpe works. */ xalign = MAX2(xalign, slice_align / surf->bpe); else if (surflevel->mode == RADEON_SURF_MODE_LINEAR_ALIGNED) /* Small rows evenly distributed across slice */ -xalign = MAX2(xalign, slice_align / surf->bpe / surflevel->nblk_y); +xalign = MAX2(xalign, slice_align / bpe / surflevel->nblk_y); surflevel->nblk_x = ALIGN(surflevel->nblk_x, xalign); surflevel->nblk_z = ALIGN(surflevel->nblk_z, zalign); surflevel->offset = offset; -surflevel->pitch_bytes = surflevel->nblk_x * surf->bpe * surf->nsamples; +surflevel->pitch_bytes = surflevel->nblk_x * bpe * surf->nsamples; surflevel->slice_size = ALIGN(surflevel->pitch_bytes * surflevel->nblk_y, slice_align); surf->bo_size = offset + surflevel->slice_size * surflevel->nblk_z * surf->array_size; -- 1.8.3.2
[PATCH] drm/ttm: Remove set_need_resched from the ttm fault handler
On Thu, Nov 14, 2013 at 7:49 PM, Thomas Hellstrom
wrote:
> Addresses
> "[BUG] completely bonkers use of set_need_resched + VM_FAULT_NOPAGE".
>
> In the first occurence it was used to try to be nice while releasing the
> mmap_sem and retrying the fault to work around a locking inversion.
> The second occurence was never used.
>
> There has been some discussion whether we should change the locking order to
> mmap_sem -> bo_reserve. This patch doesn't address that issue, and leaves
> that locking order undefined. The solution that we release the mmap_sem if
> tryreserve fails and wait for the buffer to become unreserved is something
> we want in any case, and follows how the core vm system waits for pages
> to be come unlocked while releasing the mmap_sem.
>
> The code also outlines what needs to be changed if we want to establish the
> locking order as mmap_sem -> bo::reserve.
>
> One slight issue that remains with this code is that the fault handler might
> be prone to starvation if another thread countinously reserves the buffer.
> IMO that usage pattern is highly unlikely.
>
> Signed-off-by: Thomas Hellstrom
Reviewed-by: Jakob Bornecrantz
> ---
> drivers/gpu/drm/ttm/ttm_bo.c| 35 ++-
> drivers/gpu/drm/ttm/ttm_bo_vm.c | 26 --
> include/drm/ttm/ttm_bo_api.h|4 +++-
> 3 files changed, 57 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
> index 8d5a646..07e02c4 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> @@ -151,7 +151,7 @@ static void ttm_bo_release_list(struct kref *list_kref)
> atomic_dec(&bo->glob->bo_count);
> if (bo->resv == &bo->ttm_resv)
> reservation_object_fini(&bo->ttm_resv);
> -
> + mutex_destroy(&bo->wu_mutex);
> if (bo->destroy)
> bo->destroy(bo);
> else {
> @@ -1123,6 +1123,7 @@ int ttm_bo_init(struct ttm_bo_device *bdev,
> INIT_LIST_HEAD(&bo->ddestroy);
> INIT_LIST_HEAD(&bo->swap);
> INIT_LIST_HEAD(&bo->io_reserve_lru);
> + mutex_init(&bo->wu_mutex);
> bo->bdev = bdev;
> bo->glob = bdev->glob;
> bo->type = type;
> @@ -1704,3 +1705,35 @@ void ttm_bo_swapout_all(struct ttm_bo_device *bdev)
> ;
> }
> EXPORT_SYMBOL(ttm_bo_swapout_all);
> +
> +/**
> + * ttm_bo_wait_unreserved - interruptible wait for a buffer object to become
> + * unreserved
> + *
> + * @bo: Pointer to buffer
> + */
> +int ttm_bo_wait_unreserved(struct ttm_buffer_object *bo)
> +{
> + int ret;
> +
> + /*
> +* In the absense of a wait_unlocked API,
> +* Use the bo::wu_mutex to avoid triggering livelocks due to
> +* concurrent use of this function. Note that this use of
> +* bo::wu_mutex can go away if we change locking order to
> +* mmap_sem -> bo::reserve.
> +*/
> + ret = mutex_lock_interruptible(&bo->wu_mutex);
> + if (unlikely(ret != 0))
> + return -ERESTARTSYS;
> + if (!ww_mutex_is_locked(&bo->resv->lock))
> + goto out_unlock;
> + ret = ttm_bo_reserve_nolru(bo, true, false, false, NULL);
> + if (unlikely(ret != 0))
> + goto out_unlock;
> + ww_mutex_unlock(&bo->resv->lock);
> +
> +out_unlock:
> + mutex_unlock(&bo->wu_mutex);
> + return ret;
> +}
> diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
> index ac617f3..b249ab9 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
> @@ -107,13 +107,28 @@ static int ttm_bo_vm_fault(struct vm_area_struct *vma,
> struct vm_fault *vmf)
> /*
> * Work around locking order reversal in fault / nopfn
> * between mmap_sem and bo_reserve: Perform a trylock operation
> -* for reserve, and if it fails, retry the fault after scheduling.
> +* for reserve, and if it fails, retry the fault after waiting
> +* for the buffer to become unreserved.
> */
> -
> - ret = ttm_bo_reserve(bo, true, true, false, 0);
> + ret = ttm_bo_reserve(bo, true, true, false, NULL);
> if (unlikely(ret != 0)) {
> - if (ret == -EBUSY)
> - set_need_resched();
> + if (ret != -EBUSY)
> + return VM_FAULT_NOPAGE;
> +
> + if (vmf->flags & FAULT_FLAG_ALLOW_RETRY) {
> + if (!(vmf->flags & FAULT_FLAG_RETRY_NOWAIT)) {
> + up_read(&vma->vm_mm->mmap_sem);
> + (void) ttm_bo_wait_unreserved(bo);
> + }
> +
> + return VM_FAULT_RETRY;
> + }
> +
> + /*
> +* If we'd want to change locking order to
> +* mmap_sem -> bo::reserve, we'd use a blocking reserve here
> +* in
[PATCH 2/2] drm/i915/dp: check eDP display control capability registers
On Mon, Nov 18, 2013 at 9:27 AM, Thierry Reding
wrote:
> On Fri, Nov 15, 2013 at 03:01:51PM +0200, Jani Nikula wrote:
>> 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(+)
>
> I have a few general comments below, but this patch itself look fine,
> so:
>
> Reviewed-by: Thierry Reding
>
>> 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] &
>
> I think a lot of eDP utility code could be made reusable across drivers.
> We could probably do that by having each driver expose a drm_edp object
> of some sort.
>
> Actually, the same would be true of DP in general. Accessing the DPCD is
> something that's driver specific, but once you know how to do that a lot
> of code can be made generic. I think a struct drm_dp could look like
> this:
>
> struct drm_dp;
>
> struct drm_dpcd_ops {
> ssize_t (*read)(struct drm_dp *dp, unsigned int offset,
> void *buffer, size_t size);
> ssize_t (*write)(struct drm_dp *dp, unsigned int offset,
> const void *buffer, size_t size);
> };
>
> struct drm_dp {
> const struct drm_dpcd_ops *dpcd;
> };
>
> Perhaps that could even be extended with functionality to implement link
> training in a generic way. There are already quite a few helpers to help
> with that in drivers/gpu/drm/drm_dp_helper.c, but they assume that the
> DPCD will be handed to them as a large buffer and therefore cannot write
> DPCD registers.
>
> I suppose one could argue that it would be introducing a mid-layer, but
> that layer would be really thin in my opinion. And it would allow a lot
> of the algorithms to be written only once instead of multiple times.
I think it could probably be made to work. The tricky part would be
hw specific ordering in the training sequence. At the very minimum,
you need driver callbacks to set up the source side:
set_training_pattern()
set_vs_emph()
And probably some flags to indicate whether the the hw supports
specific features like training pattern 3.
Alex
[Mesa-dev] rules for merging patches to libdrm
On Mon, Nov 18, 2013 at 8:29 AM, Thierry Reding wrote: > On Sat, Nov 09, 2013 at 01:26:24PM -0800, Ian Romanick wrote: >> On 11/09/2013 12:11 AM, Dave Airlie wrote: >> >>> How does this interact with the rule that kernel interfaces require an >> >>> open source userspace? Is "here are the mesa/libdrm patches that use >> >>> it" sufficient to get the kernel interface merged? >> >> >> >> That's my understanding: open source userspace needs to exist, but it >> >> doesn't need to be merged upstream yet. >> > >> > Having an opensource userspace and having it committed to a final repo >> > are different things, as Daniel said patches on the mesa-list were >> > sufficient, they're was no hurry to merge them considering a kernel >> > release with the code wasn't close, esp with a 3 month release window >> > if the kernel merge window is close to that anyways. >> > >> >>> libdrm is easy to change and its releases are cheap. What problem does >> >>> committing code that uses an in-progress kernel interface to libdrm >> >>> cause? I guess I'm not understanding something. >> >> >> > >> > Releases are cheap, but ABI breaks aren't so you can't just go release >> > a libdrm with an ABI for mesa then decide later it was a bad plan. >> > >> >> Introducing new kernel API usually involves assigning numbers for things >> >> - a new ioctl number, new #defines for bitfield members, and so on. >> >> >> >> Multiple patches can be in flight at the same time. For example, Abdiel >> >> and I both defined execbuf2 flags: >> >> >> >> #define I915_EXEC_RS (1 << 13) (Abdiel's code) >> >> #define I915_EXEC_OA (1 << 13) (my code) >> >> >> >> These obviously conflict. One of the two will land, and the second >> >> patch author will need to switch to (1 << 14) and resubmit. >> >> >> >> If we both decide to push to libdrm, we might get the order backwards, >> >> or maybe one series won't get pushed at all (in this case, I'm planning >> >> to drop my patch). Waiting until one lands in the kernel avoids that >> >> problem. Normally, I believe we copy the kernel headers to userspace >> >> and fix them up a bit. >> >> >> >> Dave may have other reasons; this is just the one I thought of. >> > >> > But mostly this, we've been stung by this exact thing happening >> > before, and we made the process to stop it from happening again. >> >> Then in all honestly, commits to libdrm should be controlled by either a >> single person or a small cabal... just like the kernel and the xserver. >> We're clearly in an uncomfortable middle area where we have a stringent >> set of restrictions but no way to actually enforce them. > > That doesn't sound like a bad idea at all. It obviously causes more work > for whoever will be the gatekeeper(s). > > It seems to me that libdrm is currently more of a free-for-all type of > project, and whoever merges some new feature required for a particular X > or Mesa driver cuts a new release so that the version number can be used > to track the dependency. > > I wonder if perhaps tying the libdrm releases more tightly to Linux > kernel releases would help. Since there already is a requirement for new > kernel APIs to be merged before the libdrm equivalent can be merged, > then having both release cycles in lockstep makes some sense. Not sure about strictly tying it to kernel releases would be ideal. Not *everything* in libdrm is about new kernel APIs. It tends to be the place for things needed both by xorg ddx and mesa driver, which I suppose is why it ends up a bit of a free-for-all. Maybe limiting who does releases would be sufficient. Unless there is someone with enough free time and energy to volunteer to be libdrm maintainer. But tbh I don't think it has been too much of a problem in the past. I'm not sure if I actually read somewhere the rule about not updating kernel headers until the interface is locked in (ie. drm-next), but it seemed like common sense to me. Could be enough just to document this a bit more explicitly. BR, -R > Thierry > > ___ > mesa-dev mailing list > mesa-dev at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev >
[Mesa-dev] rules for merging patches to libdrm
ey support. Micro version numbers could be used in intermediate releases. > Maybe limiting who does releases would be sufficient. Unless there is > someone with enough free time and energy to volunteer to be libdrm > maintainer. > > But tbh I don't think it has been too much of a problem in the past. > I'm not sure if I actually read somewhere the rule about not updating > kernel headers until the interface is locked in (ie. drm-next), but it > seemed like common sense to me. Could be enough just to document this > a bit more explicitly. It's not something I feel very strongly about. People seemed unhappy about the current state of affairs, so I thought I'd dump a few ideas. =) Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131118/436769ea/attachment.pgp>
[PATCH 2/2] drm/i915/dp: check eDP display control capability registers
On Mon, Nov 18, 2013 at 10:09:56AM -0500, Alex Deucher wrote:
> On Mon, Nov 18, 2013 at 9:27 AM, Thierry Reding
> wrote:
> > On Fri, Nov 15, 2013 at 03:01:51PM +0200, Jani Nikula wrote:
> >> 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(+)
> >
> > I have a few general comments below, but this patch itself look fine,
> > so:
> >
> > Reviewed-by: Thierry Reding
> >
> >> 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] &
> >
> > I think a lot of eDP utility code could be made reusable across drivers.
> > We could probably do that by having each driver expose a drm_edp object
> > of some sort.
> >
> > Actually, the same would be true of DP in general. Accessing the DPCD is
> > something that's driver specific, but once you know how to do that a lot
> > of code can be made generic. I think a struct drm_dp could look like
> > this:
> >
> > struct drm_dp;
> >
> > struct drm_dpcd_ops {
> > ssize_t (*read)(struct drm_dp *dp, unsigned int offset,
> > void *buffer, size_t size);
> > ssize_t (*write)(struct drm_dp *dp, unsigned int offset,
> > const void *buffer, size_t size);
> > };
> >
> > struct drm_dp {
> > const struct drm_dpcd_ops *dpcd;
> > };
> >
> > Perhaps that could even be extended with functionality to implement link
> > training in a generic way. There are already quite a few helpers to help
> > with that in drivers/gpu/drm/drm_dp_helper.c, but they assume that the
> > DPCD will be handed to them as a large buffer and therefore cannot write
> > DPCD registers.
> >
> > I suppose one could argue that it would be introducing a mid-layer, but
> > that layer would be really thin in my opinion. And it would allow a lot
> > of the algorithms to be written only once instead of multiple times.
>
> I think it could probably be made to work. The tricky part would be
> hw specific ordering in the training sequence. At the very minimum,
> you need driver callbacks to set up the source side:
>
> set_training_pattern()
> set_vs_emph()
>
> And probably some flags to indicate whether the the hw supports
> specific features like training pattern 3.
Yes, something along those lines was what I had in mind as well. I know
that many people are unhappy about introducing this kind of mid-layer,
but quite frankly, doing this in generic code must have been one of the
primary reasons why VESA specified it that way.
The alternative will be to repeat more or less the same code in all the
drivers. I don't think that's a very nice alternative.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131118/63483040/attachment.pgp>
[Bug 53471] Radeon card occasionally locks when enabling KMS.
https://bugzilla.kernel.org/show_bug.cgi?id=53471 Alan changed: What|Removed |Added CC||alan at lxorguk.ukuu.org.uk Component|Video(AGP) |Video(DRI - non Intel) Assignee|airlied at linux.ie|drivers_video-dri at kernel-bu ||gs.osdl.org -- You are receiving this mail because: You are watching the assignee of the bug.
[Intel-gfx] [PATCH 2/2] drm/i915/dp: check eDP display control capability registers
On Mon, Nov 18, 2013 at 04:26:17PM +0100, Thierry Reding wrote:
> On Mon, Nov 18, 2013 at 10:09:56AM -0500, Alex Deucher wrote:
> > On Mon, Nov 18, 2013 at 9:27 AM, Thierry Reding
> > wrote:
> > > On Fri, Nov 15, 2013 at 03:01:51PM +0200, Jani Nikula wrote:
> > >> 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(+)
> > >
> > > I have a few general comments below, but this patch itself look fine,
> > > so:
> > >
> > > Reviewed-by: Thierry Reding
> > >
> > >> 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] &
> > >
> > > I think a lot of eDP utility code could be made reusable across drivers.
> > > We could probably do that by having each driver expose a drm_edp object
> > > of some sort.
> > >
> > > Actually, the same would be true of DP in general. Accessing the DPCD is
> > > something that's driver specific, but once you know how to do that a lot
> > > of code can be made generic. I think a struct drm_dp could look like
> > > this:
> > >
> > > struct drm_dp;
> > >
> > > struct drm_dpcd_ops {
> > > ssize_t (*read)(struct drm_dp *dp, unsigned int offset,
> > > void *buffer, size_t size);
> > > ssize_t (*write)(struct drm_dp *dp, unsigned int offset,
> > > const void *buffer, size_t size);
> > > };
> > >
> > > struct drm_dp {
> > > const struct drm_dpcd_ops *dpcd;
> > > };
> > >
> > > Perhaps that could even be extended with functionality to implement link
> > > training in a generic way. There are already quite a few helpers to help
> > > with that in drivers/gpu/drm/drm_dp_helper.c, but they assume that the
> > > DPCD will be handed to them as a large buffer and therefore cannot write
> > > DPCD registers.
> > >
> > > I suppose one could argue that it would be introducing a mid-layer, but
> > > that layer would be really thin in my opinion. And it would allow a lot
> > > of the algorithms to be written only once instead of multiple times.
> >
> > I think it could probably be made to work. The tricky part would be
> > hw specific ordering in the training sequence. At the very minimum,
> > you need driver callbacks to set up the source side:
> >
> > set_training_pattern()
> > set_vs_emph()
> >
> > And probably some flags to indicate whether the the hw supports
> > specific features like training pattern 3.
>
> Yes, something along those lines was what I had in mind as well. I know
> that many people are unhappy about introducing this kind of mid-layer,
> but quite frankly, doing this in generic code must have been one of the
> primary reasons why VESA specified it that way.
>
> The alternative will be to repeat more or less the same code in all the
> drivers. I don't think that's a very nice alternative.
My plan (which is still somewhere on the todo but hasn't otherwise
materilized) was to extract the dp aux handling code first. There's a lot
of common code we could extract for i2c-over-dp-aux, handling branch
devices and other stuff. Once we have that we can spill tons of little
helper functions all over the place to decode interesting sink properties.
Then hopefully we could tackle more hairy stuff like the probing. As Alex
said we seem to need quite some flexibility in that
[Mesa-dev] rules for merging patches to libdrm
On Mon, Nov 18, 2013 at 10:23 AM, Thierry Reding wrote: > On Mon, Nov 18, 2013 at 10:17:47AM -0500, Rob Clark wrote: >> On Mon, Nov 18, 2013 at 8:29 AM, Thierry Reding >> wrote: >> > On Sat, Nov 09, 2013 at 01:26:24PM -0800, Ian Romanick wrote: >> >> On 11/09/2013 12:11 AM, Dave Airlie wrote: >> >> >>> How does this interact with the rule that kernel interfaces require an >> >> >>> open source userspace? Is "here are the mesa/libdrm patches that use >> >> >>> it" sufficient to get the kernel interface merged? >> >> >> >> >> >> That's my understanding: open source userspace needs to exist, but it >> >> >> doesn't need to be merged upstream yet. >> >> > >> >> > Having an opensource userspace and having it committed to a final repo >> >> > are different things, as Daniel said patches on the mesa-list were >> >> > sufficient, they're was no hurry to merge them considering a kernel >> >> > release with the code wasn't close, esp with a 3 month release window >> >> > if the kernel merge window is close to that anyways. >> >> > >> >> >>> libdrm is easy to change and its releases are cheap. What problem does >> >> >>> committing code that uses an in-progress kernel interface to libdrm >> >> >>> cause? I guess I'm not understanding something. >> >> >> >> >> > >> >> > Releases are cheap, but ABI breaks aren't so you can't just go release >> >> > a libdrm with an ABI for mesa then decide later it was a bad plan. >> >> > >> >> >> Introducing new kernel API usually involves assigning numbers for >> >> >> things >> >> >> - a new ioctl number, new #defines for bitfield members, and so on. >> >> >> >> >> >> Multiple patches can be in flight at the same time. For example, >> >> >> Abdiel >> >> >> and I both defined execbuf2 flags: >> >> >> >> >> >> #define I915_EXEC_RS (1 << 13) (Abdiel's code) >> >> >> #define I915_EXEC_OA (1 << 13) (my code) >> >> >> >> >> >> These obviously conflict. One of the two will land, and the second >> >> >> patch author will need to switch to (1 << 14) and resubmit. >> >> >> >> >> >> If we both decide to push to libdrm, we might get the order backwards, >> >> >> or maybe one series won't get pushed at all (in this case, I'm planning >> >> >> to drop my patch). Waiting until one lands in the kernel avoids that >> >> >> problem. Normally, I believe we copy the kernel headers to userspace >> >> >> and fix them up a bit. >> >> >> >> >> >> Dave may have other reasons; this is just the one I thought of. >> >> > >> >> > But mostly this, we've been stung by this exact thing happening >> >> > before, and we made the process to stop it from happening again. >> >> >> >> Then in all honestly, commits to libdrm should be controlled by either a >> >> single person or a small cabal... just like the kernel and the xserver. >> >> We're clearly in an uncomfortable middle area where we have a stringent >> >> set of restrictions but no way to actually enforce them. >> > >> > That doesn't sound like a bad idea at all. It obviously causes more work >> > for whoever will be the gatekeeper(s). >> > >> > It seems to me that libdrm is currently more of a free-for-all type of >> > project, and whoever merges some new feature required for a particular X >> > or Mesa driver cuts a new release so that the version number can be used >> > to track the dependency. >> > >> > I wonder if perhaps tying the libdrm releases more tightly to Linux >> > kernel releases would help. Since there already is a requirement for new >> > kernel APIs to be merged before the libdrm equivalent can be merged, >> > then having both release cycles in lockstep makes some sense. >> >> Not sure about strictly tying it to kernel releases would be ideal. >> Not *everything* in libdrm is about new kernel APIs. It tends to be >> the place for things needed both by xorg ddx and mesa driver, which I >> suppose is why it ends up a bit of a free-for-all. > > I didn't mean that every release would need to be tied to the Linux > kernel. But whenever a new Linux kernel release was made, relevant > changes from the public headers could be pulled into libdrm and a > release be made. I could even imagine a matching of version numbers. > libdrm releases could be numbered using the same major and minor as > Linux kernels that they support. Micro version numbers could be used > in intermediate releases. maybe an update-kernel-headers.sh script to grab the headers from drm-next and update libdrm wouldn't be a bad idea? >> Maybe limiting who does releases would be sufficient. Unless there is >> someone with enough free time and energy to volunteer to be libdrm >> maintainer. >> >> But tbh I don't think it has been too much of a problem in the past. >> I'm not sure if I actually read somewhere the rule about not updating >> kernel headers until the interface is locked in (ie. drm-next), but it >> seemed like common sense to me. Could be enough just to document this >> a bit more explicitly. > > It's not something I feel very strongly about. People
[Bug 53111] vgaswitcheroo not working anymore
https://bugzilla.kernel.org/show_bug.cgi?id=53111 Alan changed: What|Removed |Added Status|NEW |RESOLVED CC||alan at lxorguk.ukuu.org.uk Resolution|--- |CODE_FIX -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 53111] vgaswitcheroo not working anymore
https://bugzilla.kernel.org/show_bug.cgi?id=53111 Alan changed: What|Removed |Added Status|RESOLVED|CLOSED -- You are receiving this mail because: You are watching the assignee of the bug.
[RFC v2 PATCH] mipi-dsi-bus: add MIPI DSI bus support
MIPI DSI bus allows to model DSI hosts
and DSI devices using Linux bus.
Signed-off-by: Andrzej Hajda
Signed-off-by: Kyungmin Park
---
Hi,
This is my implementation of mipi dsi bus.
The first time it was posted as a part of CDF infrastructure [1],
but if it can be merged independently I will be glad.
I have not addressed yet Bert's comments, but I think it should
be easy, once we have agreement how to implement it.
There are also working drivers which uses this bus:
- Exynos DSI master,
- s6e8aa0 panel.
I will post them later.
[1] http://www.mail-archive.com/dri-devel at lists.freedesktop.org/msg45252.html
Changes:
v2:
- set_power callback removed (its role is passed to RUNTIME_PM),
- changed transfer ops parameters to struct,
- changed source location,
- minor fixes
Regards
Andrzej
---
drivers/gpu/drm/Kconfig| 4 +
drivers/gpu/drm/Makefile | 2 +
drivers/gpu/drm/drm_mipi_dsi.c | 344 +
include/drm/drm_mipi_dsi.h | 154 ++
4 files changed, 504 insertions(+)
create mode 100644 drivers/gpu/drm/drm_mipi_dsi.c
create mode 100644 include/drm/drm_mipi_dsi.h
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index f864275..58a603d 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -20,6 +20,10 @@ menuconfig DRM
details. You should also select and configure AGP
(/dev/agpgart) support if it is available for your platform.
+config DRM_MIPI_DSI
+ tristate
+ default y
+
config DRM_USB
tristate
depends on DRM
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index cc08b84..6bab99c 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -19,6 +19,7 @@ drm-$(CONFIG_COMPAT) += drm_ioc32.o
drm-$(CONFIG_DRM_GEM_CMA_HELPER) += drm_gem_cma_helper.o
drm-$(CONFIG_PCI) += ati_pcigart.o
+drm-mipi-dsi-y := drm_mipi_dsi.o
drm-usb-y := drm_usb.o
drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o
@@ -31,6 +32,7 @@ obj-$(CONFIG_DRM_KMS_HELPER) += drm_kms_helper.o
CFLAGS_drm_trace_points.o := -I$(src)
obj-$(CONFIG_DRM) += drm.o
+obj-$(CONFIG_DRM_MIPI_DSI) += drm_mipi_dsi.o
obj-$(CONFIG_DRM_USB) += drm_usb.o
obj-$(CONFIG_DRM_TTM) += ttm/
obj-$(CONFIG_DRM_TDFX) += tdfx/
diff --git a/drivers/gpu/drm/drm_mipi_dsi.c b/drivers/gpu/drm/drm_mipi_dsi.c
new file mode 100644
index 000..ead35da
--- /dev/null
+++ b/drivers/gpu/drm/drm_mipi_dsi.c
@@ -0,0 +1,344 @@
+/*
+ * MIPI DSI Bus
+ *
+ * Copyright (C) 2012, Samsung Electronics, Co., Ltd.
+ * Andrzej Hajda
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/*
-
+ * Bus operations
+ */
+
+int mipi_dsi_init(struct mipi_dsi_device *dev)
+{
+ const struct mipi_dsi_bus_ops *ops = dev->bus->ops;
+
+ if (!ops->init)
+ return -ENOSYS;
+
+ return ops->init(dev->bus, dev);
+}
+EXPORT_SYMBOL_GPL(mipi_dsi_init);
+
+int mipi_dsi_set_stream(struct mipi_dsi_device *dev, bool on)
+{
+ const struct mipi_dsi_bus_ops *ops = dev->bus->ops;
+
+ if (!ops->set_stream)
+ return -ENOSYS;
+
+ return ops->set_stream(dev->bus, dev, on);
+}
+EXPORT_SYMBOL_GPL(mipi_dsi_set_stream);
+
+int mipi_dsi_dcs_write(struct mipi_dsi_device *dev, int channel, const u8
*data,
+ size_t len)
+{
+ const struct mipi_dsi_bus_ops *ops = dev->bus->ops;
+ struct mipi_dsi_msg msg = {
+ .channel = channel,
+ .tx_buf = data,
+ .tx_len = len
+ };
+
+ if (!ops->transfer)
+ return -ENOSYS;
+
+ switch (len) {
+ case 0:
+ return -EINVAL;
+ case 1:
+ msg.type = MIPI_DSI_DCS_SHORT_WRITE;
+ break;
+ case 2:
+ msg.type = MIPI_DSI_DCS_SHORT_WRITE_PARAM;
+ break;
+ default:
+ msg.type = MIPI_DSI_DCS_LONG_WRITE;
+ }
+
+ return ops->transfer(dev->bus, dev, &msg);
+}
+EXPORT_SYMBOL_GPL(mipi_dsi_dcs_write);
+
+ssize_t mipi_dsi_dcs_read(struct mipi_dsi_device *dev, int channel, u8 cmd,
+ u8 *data, size_t len)
+{
+ const struct mipi_dsi_bus_ops *ops = dev->bus->ops;
+ struct mipi_dsi_msg msg = {
+ .channel = channel,
+ .type = MIPI_DSI_DCS_READ,
+ .tx_buf = &cmd,
+ .tx_len = 1,
+ .rx_buf = data,
+ .rx_len = len
+ };
+
+ if (!ops->transfer)
+ return -ENOSYS;
+
+ return ops->transfer(dev->bus, dev, &msg);
+}
+EXPORT_SYMBOL_GPL(mip
[Bug 53471] Radeon card occasionally locks when enabling KMS.
https://bugzilla.kernel.org/show_bug.cgi?id=53471 Alex Deucher changed: What|Removed |Added CC||alexdeucher at gmail.com --- Comment #2 from Alex Deucher --- The failing log show GPU resets, so I suspect some combination of userspace drivers is causing the GPU to hang. Is this still an issue with a newer kernel or userspace stack? -- You are receiving this mail because: You are watching the assignee of the bug.
[Mesa-dev] rules for merging patches to libdrm
op 09-11-13 22:26, Ian Romanick schreef: > On 11/09/2013 12:11 AM, Dave Airlie wrote: How does this interact with the rule that kernel interfaces require an open source userspace? Is "here are the mesa/libdrm patches that use it" sufficient to get the kernel interface merged? >>> That's my understanding: open source userspace needs to exist, but it >>> doesn't need to be merged upstream yet. >> Having an opensource userspace and having it committed to a final repo >> are different things, as Daniel said patches on the mesa-list were >> sufficient, they're was no hurry to merge them considering a kernel >> release with the code wasn't close, esp with a 3 month release window >> if the kernel merge window is close to that anyways. >> libdrm is easy to change and its releases are cheap. What problem does committing code that uses an in-progress kernel interface to libdrm cause? I guess I'm not understanding something. >> Releases are cheap, but ABI breaks aren't so you can't just go release >> a libdrm with an ABI for mesa then decide later it was a bad plan. >> >>> Introducing new kernel API usually involves assigning numbers for things >>> - a new ioctl number, new #defines for bitfield members, and so on. >>> >>> Multiple patches can be in flight at the same time. For example, Abdiel >>> and I both defined execbuf2 flags: >>> >>> #define I915_EXEC_RS (1 << 13) (Abdiel's code) >>> #define I915_EXEC_OA (1 << 13) (my code) >>> >>> These obviously conflict. One of the two will land, and the second >>> patch author will need to switch to (1 << 14) and resubmit. >>> >>> If we both decide to push to libdrm, we might get the order backwards, >>> or maybe one series won't get pushed at all (in this case, I'm planning >>> to drop my patch). Waiting until one lands in the kernel avoids that >>> problem. Normally, I believe we copy the kernel headers to userspace >>> and fix them up a bit. >>> >>> Dave may have other reasons; this is just the one I thought of. >> But mostly this, we've been stung by this exact thing happening >> before, and we made the process to stop it from happening again. > Then in all honestly, commits to libdrm should be controlled by either a > single person or a small cabal... just like the kernel and the xserver. > We're clearly in an uncomfortable middle area where we have a stringent > set of restrictions but no way to actually enforce them. Most of libdrm is hardware specific, so by necessity it is developed like that. I don't think robclark will touch libdrm/intel for example. I do not think explicit control is needed, just be more careful and don't cause unnecessary headaches by committing code to libdrm before it's in a upstream kernel. Preferably wait until it appears in torvalds/linux.git, but it seems airlied has a lower standard. :) Sometimes software bugs might warrant a release too, so this middle area is needed. ~Maarten
[Intel-gfx] [PATCH 2/2] drm/i915/dp: check eDP display control capability registers
> > > > that layer would be really thin in my opinion. And it would allow a lot > > > > of the algorithms to be written only once instead of multiple times. > > > > > > I think it could probably be made to work. The tricky part would be > > > hw specific ordering in the training sequence. At the very minimum, > > > you need driver callbacks to set up the source side: > > > > > > set_training_pattern() > > > set_vs_emph() > > > > > > And probably some flags to indicate whether the the hw supports > > > specific features like training pattern 3. > > > > Yes, something along those lines was what I had in mind as well. I know > > that many people are unhappy about introducing this kind of mid-layer, > > but quite frankly, doing this in generic code must have been one of the > > primary reasons why VESA specified it that way. > > > > The alternative will be to repeat more or less the same code in all the > > drivers. I don't think that's a very nice alternative. > > My plan (which is still somewhere on the todo but hasn't otherwise > materilized) was to extract the dp aux handling code first. There's a lot > of common code we could extract for i2c-over-dp-aux, handling branch > devices and other stuff. Once we have that we can spill tons of little > helper functions all over the place to decode interesting sink properties. Quite a bit of that has already been done in the DP helpers. It should be easy to extend that as we go along. > Then hopefully we could tackle more hairy stuff like the probing. As Alex > said we seem to need quite some flexibility in that area (e.g. not all hw > supports per-lane training values), hence why I'd aim for lower-hanging > fruit first. That also means we'll have to duplicate the training in every new driver. I was half expecting to be required to come up with the generic code again, but if everyone is okay with this I won't bother with it for now. > Note that there's already a bit of abstraction for i2c over dp aux, but > imo that's at the wrong level. At least reading through i915, gma500 and > radeon code there's a lot more we could share with just a dp aux helper > library (which then implements useful stuff on top of it). I have some difficulty envisioning how the helper code can work without some sort of driver-specific ops implementation. Currently the helpers only use a snapshot of the DPCD to extract information. Eventually we'll be bound to modify the DPCD, so some method of writing it back (or a subset of it) will be needed. Otherwise the scope of the helper library will be somewhat limited. Once we have the callbacks, the current helpers could be reworked to not use a buffer, but rather an "AUX channel object" and access the registers directly. If there are concerns about performance, it could possibly be implemented as a sort of cache, too. That would make it fast to query the status. I don't think it'll be worth the added complexity, though. Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131118/9fc2248c/attachment.pgp>
[Intel-gfx] [PATCH 2/2] drm/i915/dp: check eDP display control capability registers
On Mon, Nov 18, 2013 at 5:31 PM, Thierry Reding wrote: >> Note that there's already a bit of abstraction for i2c over dp aux, but >> imo that's at the wrong level. At least reading through i915, gma500 and >> radeon code there's a lot more we could share with just a dp aux helper >> library (which then implements useful stuff on top of it). > > I have some difficulty envisioning how the helper code can work without > some sort of driver-specific ops implementation. Currently the helpers > only use a snapshot of the DPCD to extract information. Eventually we'll > be bound to modify the DPCD, so some method of writing it back (or a > subset of it) will be needed. Otherwise the scope of the helper library > will be somewhat limited. > > Once we have the callbacks, the current helpers could be reworked to not > use a buffer, but rather an "AUX channel object" and access the > registers directly. If there are concerns about performance, it could > possibly be implemented as a sort of cache, too. That would make it fast > to query the status. I don't think it'll be worth the added complexity, > though. Oh, my idea is that the dp aux driver callback would at the level of the intel_dp_aux_ch function in i915/intel_dp.c (gma500 and radeon have something very similar). That alone would allow us to share a considerable amount of code. Should have been a bit clearer, I've discussed this in a bit more detail with Alex many moons ago ... -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[Mesa-dev] rules for merging patches to libdrm
On Mon, Nov 18, 2013 at 05:30:34PM +0100, Maarten Lankhorst wrote: > op 09-11-13 22:26, Ian Romanick schreef: > > On 11/09/2013 12:11 AM, Dave Airlie wrote: > >>>> How does this interact with the rule that kernel interfaces require an > >>>> open source userspace? Is "here are the mesa/libdrm patches that use > >>>> it" sufficient to get the kernel interface merged? > >>> That's my understanding: open source userspace needs to exist, but it > >>> doesn't need to be merged upstream yet. > >> Having an opensource userspace and having it committed to a final repo > >> are different things, as Daniel said patches on the mesa-list were > >> sufficient, they're was no hurry to merge them considering a kernel > >> release with the code wasn't close, esp with a 3 month release window > >> if the kernel merge window is close to that anyways. > >> > >>>> libdrm is easy to change and its releases are cheap. What problem does > >>>> committing code that uses an in-progress kernel interface to libdrm > >>>> cause? I guess I'm not understanding something. > >> Releases are cheap, but ABI breaks aren't so you can't just go release > >> a libdrm with an ABI for mesa then decide later it was a bad plan. > >> > >>> Introducing new kernel API usually involves assigning numbers for things > >>> - a new ioctl number, new #defines for bitfield members, and so on. > >>> > >>> Multiple patches can be in flight at the same time. For example, Abdiel > >>> and I both defined execbuf2 flags: > >>> > >>> #define I915_EXEC_RS (1 << 13) (Abdiel's code) > >>> #define I915_EXEC_OA (1 << 13) (my code) > >>> > >>> These obviously conflict. One of the two will land, and the second > >>> patch author will need to switch to (1 << 14) and resubmit. > >>> > >>> If we both decide to push to libdrm, we might get the order backwards, > >>> or maybe one series won't get pushed at all (in this case, I'm planning > >>> to drop my patch). Waiting until one lands in the kernel avoids that > >>> problem. Normally, I believe we copy the kernel headers to userspace > >>> and fix them up a bit. > >>> > >>> Dave may have other reasons; this is just the one I thought of. > >> But mostly this, we've been stung by this exact thing happening > >> before, and we made the process to stop it from happening again. > > Then in all honestly, commits to libdrm should be controlled by either a > > single person or a small cabal... just like the kernel and the xserver. > > We're clearly in an uncomfortable middle area where we have a stringent > > set of restrictions but no way to actually enforce them. > > Most of libdrm is hardware specific, so by necessity it is developed like > that. Most of the Linux kernel is hardware specific, yet it is developed differently. > I don't think robclark will touch libdrm/intel for example. Certainly a subtree-oriented development model could work well for libdrm. What I mean is that not a single person (or even a set of people) would need to pick patches from a mailing list, but driver maintainers could have separate trees which can be merged into the upstream tree. That could potentially lower the workload on the libdrm maintainer(s). > I do not think explicit control is needed, just be more careful and don't > cause > unnecessary headaches by committing code to libdrm before it's in a upstream > kernel. > Preferably wait until it appears in torvalds/linux.git, but it seems airlied > has a > lower standard. :) > > Sometimes software bugs might warrant a release too, so this middle area is > needed. Having a different development model doesn't exclude the possibility for bugfix releases. Neither does explicit control of what patches are merged. Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131118/1db723ca/attachment.pgp>
[Mesa-dev] rules for merging patches to libdrm
to Linux > >> > kernel releases would help. Since there already is a requirement for new > >> > kernel APIs to be merged before the libdrm equivalent can be merged, > >> > then having both release cycles in lockstep makes some sense. > >> > >> Not sure about strictly tying it to kernel releases would be ideal. > >> Not *everything* in libdrm is about new kernel APIs. It tends to be > >> the place for things needed both by xorg ddx and mesa driver, which I > >> suppose is why it ends up a bit of a free-for-all. > > > > I didn't mean that every release would need to be tied to the Linux > > kernel. But whenever a new Linux kernel release was made, relevant > > changes from the public headers could be pulled into libdrm and a > > release be made. I could even imagine a matching of version numbers. > > libdrm releases could be numbered using the same major and minor as > > Linux kernels that they support. Micro version numbers could be used > > in intermediate releases. > > maybe an update-kernel-headers.sh script to grab the headers from > drm-next and update libdrm wouldn't be a bad idea? Perhaps. But I think it could even be a manual step. It's not something that one person should be doing alone, but rather something that driver maintainers should be doing, since they know best what will be needed in a new version of libdrm. Like I mentioned in another subthread, I think a subtree-oriented model could work well. Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131118/5df0bde5/attachment-0001.pgp>
[PATCH v3 1/7] drm: Add DSI bus infrastructure
On 11/18/2013 01:57 PM, Thierry Reding wrote: > On Thu, Nov 14, 2013 at 03:15:57PM +0100, Andrzej Hajda wrote: >> Hi Thierry, >> >> On 11/13/2013 10:38 PM, Thierry Reding wrote: >>> On Tue, Nov 12, 2013 at 03:14:22PM +0100, Andrzej Hajda wrote: Hi Thierry, I have already sent patch with DSI bus implementation [1]. It was posted as the first step of CDF implementation attempt, but in fact it do not depend on CDF. [1] http://www.mail-archive.com/dri-devel at lists.freedesktop.org/msg45252.html >>> Seems like that patchset was never merged. I guess probably because it >>> was posted as part of CDF work. >>> >>> Do you have any plans on continuing work on that?If not I could extract >>> the DSI bus patch from the series, it's largely similar to the patch I >>> proposed here, and rework it somewhat. >> I will soon sent new patch with the current version of the bus. >> It could be a better base to your rework. > Any estimate on when this will be? I want to get started on this as soon > as possible so we can get this in good shape for 3.14. I suspect that if > I start based on the current patch, I won't have to redo everything when > updating for the next version. Quite a bit should remain similar, right? Patch sent. > >>> I'd very much like to avoid >>> putting the code in drivers/video, though, since that's considered >>> obsolete. >> I have followed convention proposed by Laurent in his DBI bus. >> It seems to me OK - DSI bus is more related to video than to drm. >> I know that drivers/video is mostly occupied by FB drivers, >> but according to Kconfig it is not only for FB. >> Of course this is only my suggestion. > I've had an IRC discussion with Dave and Rob (added on Cc), and they > both agreed that implementing it as part of DRM would be preferred. > > The reason, as I've said before, is primarily that drivers/video is > considered obsolete and new drivers and features should be implemented > within the context of DRM/KMS. Additionally this has the benefit of > being able to reuse the native DRM data structures and types, as well as > helper functions, without having to go through an extra layer of > compatibility. > >>> Furthermore I think if we kept the transfer function proposed >>> in my patch should make it easier to address Bert's comments from your >>> posting. >> I am not sure which part of Barts comment you are addressing. >> Anyway I also prefer passing struct and returning ssize_t. >> I am not sure about splitting type and channel but this seems to be a >> minor detail. > I find that to be a perfectly natural split. A DSI peripheral will have > an associated virtual channel number anyway, and having a separate field > will allow drivers to just copy that field into the dsi_msg's > equivalent. > > The alternative would be to require each driver to properly encode the > channel and data type. Other alternatives: - use helpers functions to call transfer op, encoding could be done by them, - fill channel by DSI master, based on DSI slave(seems to be little over-engineering) But I see no big difference between them. Regards Andrzej > > Thierry
[Bug 68503] Graphical glitches in Serious Sam 3 when SB is enabled
https://bugs.freedesktop.org/show_bug.cgi?id=68503 --- Comment #16 from kwahoo2 at wp.pl --- Vadim, Grigori, thank you. Mainline Mesa works fine now. -- 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/20131118/5142c525/attachment.html>
[Mesa-dev] rules for merging patches to libdrm
On Mon, Nov 18, 2013 at 05:41:50PM +0100, Thierry Reding wrote: > On Mon, Nov 18, 2013 at 11:21:36AM -0500, Rob Clark wrote: > > On Mon, Nov 18, 2013 at 10:23 AM, Thierry Reding > > wrote: > > > On Mon, Nov 18, 2013 at 10:17:47AM -0500, Rob Clark wrote: > > >> On Mon, Nov 18, 2013 at 8:29 AM, Thierry Reding > > >> wrote: > > >> > On Sat, Nov 09, 2013 at 01:26:24PM -0800, Ian Romanick wrote: > > >> >> On 11/09/2013 12:11 AM, Dave Airlie wrote: > > >> >> >>> How does this interact with the rule that kernel interfaces > > >> >> >>> require an > > >> >> >>> open source userspace? Is "here are the mesa/libdrm patches that > > >> >> >>> use > > >> >> >>> it" sufficient to get the kernel interface merged? > > >> >> >> > > >> >> >> That's my understanding: open source userspace needs to exist, but > > >> >> >> it > > >> >> >> doesn't need to be merged upstream yet. > > >> >> > > > >> >> > Having an opensource userspace and having it committed to a final > > >> >> > repo > > >> >> > are different things, as Daniel said patches on the mesa-list were > > >> >> > sufficient, they're was no hurry to merge them considering a kernel > > >> >> > release with the code wasn't close, esp with a 3 month release > > >> >> > window > > >> >> > if the kernel merge window is close to that anyways. > > >> >> > > > >> >> >>> libdrm is easy to change and its releases are cheap. What problem > > >> >> >>> does > > >> >> >>> committing code that uses an in-progress kernel interface to > > >> >> >>> libdrm > > >> >> >>> cause? I guess I'm not understanding something. > > >> >> >> > > >> >> > > > >> >> > Releases are cheap, but ABI breaks aren't so you can't just go > > >> >> > release > > >> >> > a libdrm with an ABI for mesa then decide later it was a bad plan. > > >> >> > > > >> >> >> Introducing new kernel API usually involves assigning numbers for > > >> >> >> things > > >> >> >> - a new ioctl number, new #defines for bitfield members, and so on. > > >> >> >> > > >> >> >> Multiple patches can be in flight at the same time. For example, > > >> >> >> Abdiel > > >> >> >> and I both defined execbuf2 flags: > > >> >> >> > > >> >> >> #define I915_EXEC_RS (1 << 13) (Abdiel's code) > > >> >> >> #define I915_EXEC_OA (1 << 13) (my code) > > >> >> >> > > >> >> >> These obviously conflict. One of the two will land, and the second > > >> >> >> patch author will need to switch to (1 << 14) and resubmit. > > >> >> >> > > >> >> >> If we both decide to push to libdrm, we might get the order > > >> >> >> backwards, > > >> >> >> or maybe one series won't get pushed at all (in this case, I'm > > >> >> >> planning > > >> >> >> to drop my patch). Waiting until one lands in the kernel avoids > > >> >> >> that > > >> >> >> problem. Normally, I believe we copy the kernel headers to > > >> >> >> userspace > > >> >> >> and fix them up a bit. > > >> >> >> > > >> >> >> Dave may have other reasons; this is just the one I thought of. > > >> >> > > > >> >> > But mostly this, we've been stung by this exact thing happening > > >> >> > before, and we made the process to stop it from happening again. > > >> >> > > >> >> Then in all honestly, commits to libdrm should be controlled by > > >> >> either a > > >> >> single person or a small cabal... just like the kernel and the > > >> >> xserver. > > >> >> We're clearly in an uncomfortable middle area where we have a > > >> >> stringent > > >> >> set of restrictions but no way to actually enforce them. > > >> > > > >> > That doesn't sound like a bad idea at all. It obviously causes more > > >> > work > > >> > for whoever will be the gatekeeper(s). > > >> > > > >> > It seems to me that libdrm is currently more of a free-for-all type of > > >> > project, and whoever merges some new feature required for a particular > > >> > X > > >> > or Mesa driver cuts a new release so that the version number can be > > >> > used > > >> > to track the dependency. > > >> > > > >> > I wonder if perhaps tying the libdrm releases more tightly to Linux > > >> > kernel releases would help. Since there already is a requirement for > > >> > new > > >> > kernel APIs to be merged before the libdrm equivalent can be merged, > > >> > then having both release cycles in lockstep makes some sense. > > >> > > >> Not sure about strictly tying it to kernel releases would be ideal. > > >> Not *everything* in libdrm is about new kernel APIs. It tends to be > > >> the place for things needed both by xorg ddx and mesa driver, which I > > >> suppose is why it ends up a bit of a free-for-all. > > > > > > I didn't mean that every release would need to be tied to the Linux > > > kernel. But whenever a new Linux kernel release was made, relevant > > > changes from the public headers could be pulled into libdrm and a > > > release be made. I could even imagine a matching of version numbers. > > > libdrm releases could be numbered using the same major and minor as > > > Linux kernels that they support. Micro version numbers could
[Bug 71753] New: Radeon Audio clock running wrong speed
https://bugs.freedesktop.org/show_bug.cgi?id=71753 Priority: medium Bug ID: 71753 Assignee: dri-devel at lists.freedesktop.org Summary: Radeon Audio clock running wrong speed Severity: normal Classification: Unclassified OS: Linux (All) Reporter: fritsch at xbmc.org Hardware: Other Status: NEW Version: XOrg CVS Component: DRM/Radeon Product: DRI When syncing radeon audio to a systemclock one realizes that it goes wrong approximately 10ms per 6 seconds. For example with 60hz and 50hz the audio clock is 10ms / 6 seconds too fast, which causes great issues, when watching e.g. LiveTV. When displaying at 24hz the audio clock is approximately 10ms / 6 seconds too slow, which can be workarounded by doubling packages. You can only realize this problem, if you don't use any resample algorithms to make audio fit. Some output from an xbmc.log: Configuration: 50hz no sync playback to display. Kernel 3.12 (Pierre Ossmann patch applied) with mesa git 19:46:13 T:139718574470912 DEBUG: CDVDPlayerAudio:: Discontinuity2 - was:62710358734.243919, should be:62710332298.764549, error:-26435.479370 19:46:16 T:139718574470912 DEBUG: CDVDPlayerAudio:: Discontinuity2 - was:62712528103.582550, should be:62712508710.849106, error:-19392.733447 19:46:17 T:139718566078208 DEBUG: CPullupCorrection: detected pattern of length 1: 4.00, frameduration: 4.00 19:46:22 T:139718574470912 DEBUG: CDVDPlayerAudio:: Discontinuity2 - was:62718996472.639107, should be:62719007584.295349, error:1.656243 19:46:28 T:139718574470912 DEBUG: CDVDPlayerAudio:: Discontinuity2 - was:62725295876.976349, should be:62725306470.191048, error:10593.214698 19:46:35 T:139718574470912 DEBUG: CDVDPlayerAudio:: Discontinuity2 - was:62731698477.715050, should be:62731709235.032417, error:10757.317365 19:46:38 T:139719056176896 DEBUG: Thread JobWorker 139719056176896 terminating (autodelete) 19:46:41 T:139718574470912 DEBUG: CDVDPlayerAudio:: Discontinuity2 - was:62738297284.064415, should be:62738308465.384331, error:11181.319916 19:46:48 T:139718574470912 DEBUG: CDVDPlayerAudio:: Discontinuity2 - was:62744796455.484329, should be:62744807397.750954, error:10942.266624 -- 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/20131118/2316fbb7/attachment.html>
[Bug 71753] Radeon Audio clock running wrong speed
https://bugs.freedesktop.org/show_bug.cgi?id=71753 --- Comment #1 from Peter Fr?hberger --- Created attachment 89423 --> https://bugs.freedesktop.org/attachment.cgi?id=89423&action=edit xrandr output -- 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/20131118/4411faa0/attachment-0001.html>
[Bug 71753] Radeon Audio clock running wrong speed
https://bugs.freedesktop.org/show_bug.cgi?id=71753 --- Comment #2 from Peter Fr?hberger --- Created attachment 89424 --> https://bugs.freedesktop.org/attachment.cgi?id=89424&action=edit dmesg output -- 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/20131118/8c4a3ca6/attachment.html>
[Bug 71753] Radeon Audio clock running wrong speed
https://bugs.freedesktop.org/show_bug.cgi?id=71753 --- Comment #3 from Peter Fr?hberger --- Created attachment 89425 --> https://bugs.freedesktop.org/attachment.cgi?id=89425&action=edit glxinfo -- 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/20131118/0239973d/attachment.html>
[Bug 52171] [gallium/r600/clover] Simple benchmarks failed to run
https://bugs.freedesktop.org/show_bug.cgi?id=52171 Tom Stellard changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Tom Stellard --- Fixed in mesa master by a84dd2398f75c672293122408828ac66bb7052a0 -- 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/20131118/4987a921/attachment.html>
[Bug 64226] python-opencl package generate segmentation fault at pipe_r600.so
https://bugs.freedesktop.org/show_bug.cgi?id=64226 --- Comment #3 from Tom Stellard --- Fixed in mesa master by 1b9511d7ce70a9f9cadd0c03bd0c916b88b6dd43 -- 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/20131118/dea78b5f/attachment.html>
[Bug 64226] python-opencl package generate segmentation fault at pipe_r600.so
https://bugs.freedesktop.org/show_bug.cgi?id=64226 Tom Stellard 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/20131118/e8cda89d/attachment.html>
[Mesa-dev] [PATCH] Don't use libudev for glx/dri3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/17/2013 06:43 PM, Keith Packard wrote: > Emil Velikov writes: > >> On 18/11/13 01:08, Keith Packard wrote: >>> libudev doesn't have a stable API/ABI, and if the application >>> wants to use one version, we'd best not load another into >>> libGL. >>> >>> Signed-off-by: Keith Packard --- >>> >> Hi Keith, >> >> Firstly, I would like to apologise for the rather daft >> questions. >> >> With that said, looking through your patch I've noticed that >> (most of) your int functions are returning 0 or failure and 1 on >> success. Were those functions meant to return boolean/bool? > > Sure, but I was too lazy to figure out which kind of bool belongs > in that part of mesa... For future reference... for things not accesible to the application or some other library (with its own boolean type), the answer is always bool from stdbool.h. > ___ dri-devel mailing > list dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) iEYEARECAAYFAlKKjbcACgkQX1gOwKyEAw9O8gCeM1SQmZcOSaSxJy5yT42ItxQU 1UUAoI9Gl1ah9P1/0AG+huawKAPzF9V9 =d3i2 -END PGP SIGNATURE-
[Bug 53471] Radeon card occasionally locks when enabling KMS.
https://bugzilla.kernel.org/show_bug.cgi?id=53471 --- Comment #3 from Chris Rankin --- This particular intermittent problem hasn't occurred again, but I can't claim to know whether it has been fixed. -- 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
Hi, On Fri, Nov 15, 2013 at 9:47 PM, Mark Rutland wrote: > 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. > Agreed, i have removed this field and now use the pixel clock to update the required values. >> + b) "config: config" specifies the phy configuration settings, >> + wher 'N' denotes the number of iteration. > > The number of iteration? Corrected in next patch set. > >> + "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. Have updated in next patch set, hope its understandable. > >> + 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? > Agreed, have made the change in next patch set. > Thanks, > Mark. Thanks, Shirish S
[Mesa-dev] [PATCH] Don't use libudev for glx/dri3
On 18/11/13 01:08, Keith Packard wrote:
> libudev doesn't have a stable API/ABI, and if the application wants to use one
> version, we'd best not load another into libGL.
>
> Signed-off-by: Keith Packard
> ---
>
Hi Keith,
Firstly, I would like to apologise for the rather daft questions.
With that said, looking through your patch I've noticed that (most of)
your int functions are returning 0 or failure and 1 on success. Were
those functions meant to return boolean/bool?
After a quick look at the dri3 and dri2 code base I've noticed that
there are a lot of cases where the function returns True/False, wrapped
as int.
I'm assuming that there is some reason behind these. Do you have some
references were I can look a bit more on the subject ?
Cheers,
Emil
> Sorry for the patch spam; I hadn't rebased in a while and there was a
> configure.ac conflict. Here's a version which should apply cleanly to master.
>
> configure.ac | 8
> src/glx/dri3_common.c | 104
> +++---
> 2 files changed, 90 insertions(+), 22 deletions(-)
>
> diff --git a/configure.ac b/configure.ac
> index fb16338..656d9d0 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -821,9 +821,6 @@ xyesno)
> PKG_CHECK_MODULES([DRI2PROTO], [dri2proto >= $DRI2PROTO_REQUIRED])
> GL_PC_REQ_PRIV="$GL_PC_REQ_PRIV libdrm >= $LIBDRM_REQUIRED"
> if test x"$enable_dri3" = xyes; then
> -if test x"$have_libudev" != xyes; then
> - AC_MSG_ERROR([DRI3 requires libudev >= $LIBUDEV_REQUIRED])
> -fi
> PKG_CHECK_MODULES([DRI3PROTO], [dri3proto >=
> $DRI3PROTO_REQUIRED])
> PKG_CHECK_MODULES([PRESENTPROTO], [presentproto >=
> $PRESENTPROTO_REQUIRED])
> fi
> @@ -847,11 +844,6 @@ xyesno)
> X11_INCLUDES="$X11_INCLUDES $DRIGL_CFLAGS"
> GL_LIB_DEPS="$DRIGL_LIBS"
>
> -if test x"$enable_dri3$have_libudev" = xyesyes; then
> -X11_INCLUDES="$X11_INCLUDES $LIBUDEV_CFLAGS"
> -GL_LIB_DEPS="$GL_LIB_DEPS $LIBUDEV_LIBS"
> -fi
> -
> # need DRM libs, $PTHREAD_LIBS, etc.
> GL_LIB_DEPS="$GL_LIB_DEPS $LIBDRM_LIBS -lm $PTHREAD_LIBS $DLOPEN_LIBS"
> GL_PC_LIB_PRIV="-lm $PTHREAD_LIBS $DLOPEN_LIBS"
> diff --git a/src/glx/dri3_common.c b/src/glx/dri3_common.c
> index c758f96..7330d79 100644
> --- a/src/glx/dri3_common.c
> +++ b/src/glx/dri3_common.c
> @@ -72,22 +72,41 @@
> #include "dri3_priv.h"
>
> #define DRIVER_MAP_DRI3_ONLY
> +
> #include "pci_ids/pci_id_driver_map.h"
>
> +static dev_t
> +dri3_rdev_from_fd(int fd)
> +{
> + struct stat buf;
> +
> + if (fstat(fd, &buf) < 0) {
> + ErrorMessageF("DRI3: failed to stat fd %d", fd);
> + return 0;
> + }
> + return buf.st_rdev;
> +}
> +
> +/*
> + * There are multiple udev library versions, and they aren't polite about
> + * symbols, so just avoid using it until some glorious future when the udev
> + * developers figure out how to not break things
> + */
> +
> +#define USE_UDEV 0
> +#if USE_UDEV
> #include
>
> static struct udev_device *
> dri3_udev_device_new_from_fd(struct udev *udev, int fd)
> {
> struct udev_device *device;
> - struct stat buf;
> + dev_t rdev = dri3_rdev_from_fd(fd);
>
> - if (fstat(fd, &buf) < 0) {
> - ErrorMessageF("DRI3: failed to stat fd %d", fd);
> + if (rdev == 0)
>return NULL;
> - }
>
> - device = udev_device_new_from_devnum(udev, 'c', buf.st_rdev);
> + device = udev_device_new_from_devnum(udev, 'c', rdev);
> if (device == NULL) {
>ErrorMessageF("DRI3: could not create udev device for fd %d", fd);
>return NULL;
> @@ -96,19 +115,20 @@ dri3_udev_device_new_from_fd(struct udev *udev, int fd)
> return device;
> }
>
> -char *
> -dri3_get_driver_for_fd(int fd)
> +static int
> +dri3_get_pci_id_from_fd(int fd, int *vendorp, int *chipp)
> {
> struct udev *udev;
> struct udev_device *device, *parent;
> const char *pci_id;
> - char *driver = NULL;
> - int vendor_id, chip_id, i, j;
> + int ret = 0;
>
> udev = udev_new();
> + if (!udev)
> + goto no_udev;
> device = dri3_udev_device_new_from_fd(udev, fd);
> if (device == NULL)
> - return NULL;
> + goto no_dev;
>
> parent = udev_device_get_parent(device);
> if (parent == NULL) {
> @@ -118,10 +138,69 @@ dri3_get_driver_for_fd(int fd)
>
> pci_id = udev_device_get_property_value(parent, "PCI_ID");
> if (pci_id == NULL ||
> - sscanf(pci_id, "%x:%x", &vendor_id, &chip_id) != 2) {
> + sscanf(pci_id, "%x:%x", vendorp, chipp) != 2) {
>ErrorMessageF("DRI3: malformed or no PCI ID");
>goto out;
> }
> + ret = 1;
> +
> +out:
> + udev_device_unref(device);
> +no_dev:
> + udev_unref(udev);
> +no_udev:
> + return ret;
> +}
> +#else
> +
> +#define SYS_PATH_MAX256
> +
> +static int
> +dri3_read_hex(dev_t rdev, char *entry, int *value)
> +{
> + char path[SYS_PATH_MAX];
> + FILE
[PATCH 0/4] Add dt support for exynos hdmiphy settings
For various revisions of a chipset if the signal pattern is changed for every revision, then the phy setting need to be updated correspondingly by measuring the signal. For getting correct signals the clock level and data de-emphasis levels needs to be adjusted. Since only these 2 values matter,we can move the same to dt, wherein we can have different dt files for every revision. This is an initial patchset towards achieving the same for exynos 5250 and can be later extended to future chipsets. V2: replaced moving of entire phy config structure with only required and justifiable conf registers. V3: Incorporated Mark Rutland's comments. V4: Rebased and included cros5250-common.dtsi. V5: removed nr-configs feild and also the constraint of having the exact number of configs in the dt file as in the driver, the programmer can add only the pixel clock that needs to be updated. Shirish S (4): ARM: dts: smdk5250: Add hdmi phy settings ARM: dts: arndale: Add hdmi phy settings ARM: exynos: dts: cros5250: Add hdmi phy settings drm: exynos: hdmi: Add dt support for hdmiphy settings .../devicetree/bindings/video/exynos_hdmi.txt | 33 + arch/arm/boot/dts/cros5250-common.dtsi | 75 +++ arch/arm/boot/dts/exynos5250-arndale.dts | 75 +++ arch/arm/boot/dts/exynos5250-smdk5250.dts | 75 +++ drivers/gpu/drm/exynos/exynos_hdmi.c | 77 +++- 5 files changed, 331 insertions(+), 4 deletions(-) -- 1.7.9.5
[PATCH 1/4] ARM: dts: smdk5250: Add hdmi phy settings
This patch moves the hdmi phy setting to smdk5250
dts,as its more of a per board configuration and
also shall be easier for supporting future chipsets.
Signed-off-by: Shirish S
---
arch/arm/boot/dts/exynos5250-smdk5250.dts | 75 +
1 file changed, 75 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts
b/arch/arm/boot/dts/exynos5250-smdk5250.dts
index 2538b32..e1f4e08 100644
--- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
+++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
@@ -220,6 +220,81 @@
hdmi {
hpd-gpio = <&gpx3 7 0>;
+ hdmiphy-configs {
+ /*
+ * Eye diagram test passed for:
+ * Data de-emphasis: -0.7dB & Data Level: 880mV
+ * i.e., 0010 0110 = 0x26
+ * and Clock level of 515mV and diff 1030mV
+ * i.e., 0x66
+ */
+ nr-configs = <13>;
+ config0: config0 {
+ pixel-clock = <2520>;
+ config-de-emphasis-level = /bits/ 8 <0x26>;
+ config-clock-level = /bits/ 8 < 0x66>;
+ };
+ config1: config1 {
+ pixel-clock = <2700>;
+ config-de-emphasis-level = /bits/ 8 <0x26>;
+ config-clock-level = /bits/ 8 < 0x66>;
+ };
+ config2: config2 {
+ pixel-clock = <27027000>;
+ config-de-emphasis-level = /bits/ 8 <0x26>;
+ config-clock-level = /bits/ 8 < 0x66>;
+ };
+ config3: config3 {
+ pixel-clock = <3600>;
+ config-de-emphasis-level = /bits/ 8 <0x26>;
+ config-clock-level = /bits/ 8 < 0x66>;
+ };
+ config4: config4 {
+ pixel-clock = <4000>;
+ config-de-emphasis-level = /bits/ 8 <0x26>;
+ config-clock-level = /bits/ 8 < 0x66>;
+ };
+ config5: config5 {
+ pixel-clock = <6500>;
+ config-de-emphasis-level = /bits/ 8 <0x26>;
+ config-clock-level = /bits/ 8 < 0x66>;
+ };
+ config6: config6 {
+ pixel-clock = <74176000>;
+ config-de-emphasis-level = /bits/ 8 <0x26>;
+ config-clock-level = /bits/ 8 < 0x66>;
+ };
+ config7: config7 {
+ pixel-clock = <7425>;
+ config-de-emphasis-level = /bits/ 8 <0x26>;
+ config-clock-level = /bits/ 8 < 0x66>;
+ };
+ config8: config8 {
+ pixel-clock = <8350>;
+ config-de-emphasis-level = /bits/ 8 <0x26>;
+ config-clock-level = /bits/ 8 < 0x66>;
+ };
+ config9: config9 {
+ pixel-clock = <10650>;
+ config-de-emphasis-level = /bits/ 8 <0x26>;
+ config-clock-level = /bits/ 8 < 0x66>;
+ };
+ config10: config10 {
+ pixel-clock = <10800>;
+ config-de-emphasis-level = /bits/ 8 <0x26>;
+ config-clock-level = /bits/ 8 < 0x66>;
+ };
+ config11: config11 {
+ pixel-clock = <14625>;
+ config-de-emphasis-level = /bits/ 8 <0x26>;
+ config-clock-level = /bits/ 8 < 0x66>;
+ };
+ config12: config12 {
+ pixel-clock = <14850>;
+ config-de-emphasis-level = /bits/ 8 <0x26>;
+ config-clock-level = /bits/ 8 < 0x66>;
+ };
+ };
};
codec at 1100 {
--
1.7.9.5
[PATCH 2/4] ARM: dts: arndale: Add hdmi phy settings
This patch moves the hdmi phy setting to arndale dts,
as its more of a per board configuration and also
shall be easier for supporting future chipsets.
Signed-off-by: Shirish S
---
arch/arm/boot/dts/exynos5250-arndale.dts | 75 ++
1 file changed, 75 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5250-arndale.dts
b/arch/arm/boot/dts/exynos5250-arndale.dts
index cee55fa..c771ba3 100644
--- a/arch/arm/boot/dts/exynos5250-arndale.dts
+++ b/arch/arm/boot/dts/exynos5250-arndale.dts
@@ -475,6 +475,81 @@
vdd_osc-supply = <&ldo10_reg>;
vdd_pll-supply = <&ldo8_reg>;
vdd-supply = <&ldo8_reg>;
+ hdmiphy-configs {
+ /*
+ * Eye diagram test passed for:
+ * Data de-emphasis: -0.7dB & Data Level: 880mV
+ * i.e., 0010 0110 = 0x26
+ * and Clock level of 515mV and diff 1030mV
+ * i.e., 0x66
+ */
+ nr-configs = <13>;
+ config0: config0 {
+ pixel-clock = <2520>;
+ config-de-emphasis-level = /bits/ 8 <0x26>;
+ config-clock-level = /bits/ 8 < 0x66>;
+ };
+ config1: config1 {
+ pixel-clock = <2700>;
+ config-de-emphasis-level = /bits/ 8 <0x26>;
+ config-clock-level = /bits/ 8 < 0x66>;
+ };
+ config2: config2 {
+ pixel-clock = <27027000>;
+ config-de-emphasis-level = /bits/ 8 <0x26>;
+ config-clock-level = /bits/ 8 < 0x66>;
+ };
+ config3: config3 {
+ pixel-clock = <3600>;
+ config-de-emphasis-level = /bits/ 8 <0x26>;
+ config-clock-level = /bits/ 8 < 0x66>;
+ };
+ config4: config4 {
+ pixel-clock = <4000>;
+ config-de-emphasis-level = /bits/ 8 <0x26>;
+ config-clock-level = /bits/ 8 < 0x66>;
+ };
+ config5: config5 {
+ pixel-clock = <6500>;
+ config-de-emphasis-level = /bits/ 8 <0x26>;
+ config-clock-level = /bits/ 8 < 0x66>;
+ };
+ config6: config6 {
+ pixel-clock = <74176000>;
+ config-de-emphasis-level = /bits/ 8 <0x26>;
+ config-clock-level = /bits/ 8 < 0x66>;
+ };
+ config7: config7 {
+ pixel-clock = <7425>;
+ config-de-emphasis-level = /bits/ 8 <0x26>;
+ config-clock-level = /bits/ 8 < 0x66>;
+ };
+ config8: config8 {
+ pixel-clock = <8350>;
+ config-de-emphasis-level = /bits/ 8 <0x26>;
+ config-clock-level = /bits/ 8 < 0x66>;
+ };
+ config9: config9 {
+ pixel-clock = <10650>;
+ config-de-emphasis-level = /bits/ 8 <0x26>;
+ config-clock-level = /bits/ 8 < 0x66>;
+ };
+ config10: config10 {
+ pixel-clock = <10800>;
+ config-de-emphasis-level = /bits/ 8 <0x26>;
+ config-clock-level = /bits/ 8 < 0x66>;
+ };
+ config11: config11 {
+ pixel-clock = <14625>;
+ config-de-emphasis-level = /bits/ 8 <0x26>;
+ config-clock-level = /bits/ 8 < 0x66>;
+ };
+ config12: config12 {
+ pixel-clock = <14850>;
+ config-de-emphasis-level = /bits/ 8 <0x26>;
+ config-clock-level = /bits/ 8 < 0x66>;
+ };
+ };
};
regulators {
--
1.7.9.5
[PATCH 3/4] ARM: exynos: dts: cros5250: Add hdmi phy settings
This patch moves the hdmi phy setting to arndale dts,
as its more of a per board configuration and also
shall be easier for supporting future chipsets.
Signed-off-by: Shirish S
---
arch/arm/boot/dts/cros5250-common.dtsi | 75
1 file changed, 75 insertions(+)
diff --git a/arch/arm/boot/dts/cros5250-common.dtsi
b/arch/arm/boot/dts/cros5250-common.dtsi
index dc259e8b..3cd1779 100644
--- a/arch/arm/boot/dts/cros5250-common.dtsi
+++ b/arch/arm/boot/dts/cros5250-common.dtsi
@@ -301,6 +301,81 @@
hdmi {
hpd-gpio = <&gpx3 7 0>;
+ hdmiphy-configs {
+ /*
+ * Eye diagram test passed for:
+ * Data de-emphasis: -0.7dB & Data Level: 880mV
+ * i.e., 0010 0110 = 0x26
+ * and Clock level of 515mV and diff 1030mV
+ * i.e., 0x66
+ */
+ nr-configs = <13>;
+ config0: config0 {
+ pixel-clock = <2520>;
+ config-de-emphasis-level = /bits/ 8 <0x26>;
+ config-clock-level = /bits/ 8 < 0x66>;
+ };
+ config1: config1 {
+ pixel-clock = <2700>;
+ config-de-emphasis-level = /bits/ 8 <0x26>;
+ config-clock-level = /bits/ 8 < 0x66>;
+ };
+ config2: config2 {
+ pixel-clock = <27027000>;
+ config-de-emphasis-level = /bits/ 8 <0x26>;
+ config-clock-level = /bits/ 8 < 0x66>;
+ };
+ config3: config3 {
+ pixel-clock = <3600>;
+ config-de-emphasis-level = /bits/ 8 <0x26>;
+ config-clock-level = /bits/ 8 < 0x66>;
+ };
+ config4: config4 {
+ pixel-clock = <4000>;
+ config-de-emphasis-level = /bits/ 8 <0x26>;
+ config-clock-level = /bits/ 8 < 0x66>;
+ };
+ config5: config5 {
+ pixel-clock = <6500>;
+ config-de-emphasis-level = /bits/ 8 <0x26>;
+ config-clock-level = /bits/ 8 < 0x66>;
+ };
+ config6: config6 {
+ pixel-clock = <74176000>;
+ config-de-emphasis-level = /bits/ 8 <0x26>;
+ config-clock-level = /bits/ 8 < 0x66>;
+ };
+ config7: config7 {
+ pixel-clock = <7425>;
+ config-de-emphasis-level = /bits/ 8 <0x26>;
+ config-clock-level = /bits/ 8 < 0x66>;
+ };
+ config8: config8 {
+ pixel-clock = <8350>;
+ config-de-emphasis-level = /bits/ 8 <0x26>;
+ config-clock-level = /bits/ 8 < 0x66>;
+ };
+ config9: config9 {
+ pixel-clock = <10650>;
+ config-de-emphasis-level = /bits/ 8 <0x26>;
+ config-clock-level = /bits/ 8 < 0x66>;
+ };
+ config10: config10 {
+ pixel-clock = <10800>;
+ config-de-emphasis-level = /bits/ 8 <0x26>;
+ config-clock-level = /bits/ 8 < 0x66>;
+ };
+ config11: config11 {
+ pixel-clock = <14625>;
+ config-de-emphasis-level = /bits/ 8 <0x26>;
+ config-clock-level = /bits/ 8 < 0x66>;
+ };
+ config12: config12 {
+ pixel-clock = <14850>;
+ config-de-emphasis-level = /bits/ 8 <0x26>;
+ config-clock-level = /bits/ 8 < 0x66>;
+ };
+ };
};
gpio-keys {
--
1.7.9.5
[PATCH 2/4] ARM: dts: arndale: Add hdmi phy settings
This patch moves the hdmi phy setting to arndale dts,
as its more of a per board configuration and also
shall be easier for supporting future chipsets.
Signed-off-by: Shirish S
---
arch/arm/boot/dts/exynos5250-arndale.dts | 74 ++
1 file changed, 74 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5250-arndale.dts
b/arch/arm/boot/dts/exynos5250-arndale.dts
index cee55fa..48b00f7 100644
--- a/arch/arm/boot/dts/exynos5250-arndale.dts
+++ b/arch/arm/boot/dts/exynos5250-arndale.dts
@@ -475,6 +475,80 @@
vdd_osc-supply = <&ldo10_reg>;
vdd_pll-supply = <&ldo8_reg>;
vdd-supply = <&ldo8_reg>;
+ hdmiphy-configs {
+ /*
+ * Eye diagram test passed for:
+ * Data de-emphasis: -0.7dB & Data Level: 880mV
+ * i.e., 0010 0110 = 0x26
+ * and Clock level of 515mV and diff 1030mV
+ * i.e., 0x66
+ */
+ config0: config0 {
+ pixel-clock = <2520>;
+ config-de-emphasis-level = /bits/ 8 <0x26>;
+ config-clock-level = /bits/ 8 < 0x66>;
+ };
+ config1: config1 {
+ pixel-clock = <2700>;
+ config-de-emphasis-level = /bits/ 8 <0x26>;
+ config-clock-level = /bits/ 8 < 0x66>;
+ };
+ config2: config2 {
+ pixel-clock = <27027000>;
+ config-de-emphasis-level = /bits/ 8 <0x26>;
+ config-clock-level = /bits/ 8 < 0x66>;
+ };
+ config3: config3 {
+ pixel-clock = <3600>;
+ config-de-emphasis-level = /bits/ 8 <0x26>;
+ config-clock-level = /bits/ 8 < 0x66>;
+ };
+ config4: config4 {
+ pixel-clock = <4000>;
+ config-de-emphasis-level = /bits/ 8 <0x26>;
+ config-clock-level = /bits/ 8 < 0x66>;
+ };
+ config5: config5 {
+ pixel-clock = <6500>;
+ config-de-emphasis-level = /bits/ 8 <0x26>;
+ config-clock-level = /bits/ 8 < 0x66>;
+ };
+ config6: config6 {
+ pixel-clock = <74176000>;
+ config-de-emphasis-level = /bits/ 8 <0x26>;
+ config-clock-level = /bits/ 8 < 0x66>;
+ };
+ config7: config7 {
+ pixel-clock = <7425>;
+ config-de-emphasis-level = /bits/ 8 <0x26>;
+ config-clock-level = /bits/ 8 < 0x66>;
+ };
+ config8: config8 {
+ pixel-clock = <8350>;
+ config-de-emphasis-level = /bits/ 8 <0x26>;
+ config-clock-level = /bits/ 8 < 0x66>;
+ };
+ config9: config9 {
+ pixel-clock = <10650>;
+ config-de-emphasis-level = /bits/ 8 <0x26>;
+ config-clock-level = /bits/ 8 < 0x66>;
+ };
+ config10: config10 {
+ pixel-clock = <10800>;
+ config-de-emphasis-level = /bits/ 8 <0x26>;
+ config-clock-level = /bits/ 8 < 0x66>;
+ };
+ config11: config11 {
+ pixel-clock = <14625>;
+ config-de-emphasis-level = /bits/ 8 <0x26>;
+ config-clock-level = /bits/ 8 < 0x66>;
+ };
+ config12: config12 {
+ pixel-clock = <14850>;
+ config-de-emphasis-level = /bits/ 8 <0x26>;
+ config-clock-level = /bits/ 8 < 0x66>;
+ };
+ };
};
regulators {
--
1.7.9.5
[PATCH 4/4] drm: exynos: hdmi: Add dt support for hdmiphy settings
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 | 33 +
drivers/gpu/drm/exynos/exynos_hdmi.c | 77 +++-
2 files changed, 106 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
index 323983b..1021c74 100644
--- a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
+++ b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
@@ -13,6 +13,31 @@ 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.
+ b) "config: config" specifies the phy configuration settings,
+ where 'N' denotes the number of configuration, since every
+ pixel clock can have its unique configuration.
+ "pixel-clock" specifies the pixel clock
+ "conifig-de-emphasis-level" provides fine control of TMDS data
+pre emphasis, below shown is example for
+ data de-emphasis register at address 0x145D0040.
+ hdmiphy at 38[16] for bits[3:0] permitted values are in
+ the range of 760 mVdiff to 1400 mVdiff at 20mVdiff
+ increments for every LSB
+ hdmiphy at 38[16] for bits[7:4] permitted values are in
+ the range of 0dB to -7.45dB at increments of -0.45dB
+ for every LSB.
+ "config-clock-level" provides fine control of TMDS data
+ amplitude for each channel,
+ for example if 0x145D005C is the address of clock level
+ register then,
+ hdmiphy at 38[23] for bits [1:0] permitted values are in
+ the range of 0 mVdiff & 60 mVdiff for each channel at
+ increments 20 mVdiff of amplitude levels for every LSB,
+ hdmiphy at 38[23] for bits [7:3] permitted values are in
+ the range of 790 and 1430 mV at 20mV increments for
+ every LSB.
Example:
hdmi {
@@ -20,4 +45,12 @@ Example:
reg = <0x1453 0x10>;
interrupts = <0 95 0>;
hpd-gpio = <&gpx3 7 1>;
+ hdmiphy-configs {
+ nr-configs = <1>;
+ config0: config0 {
+ pixel-clock = <2520>;
+ config-de-emphasis-level = /bits/ 8 <0x26>;
+ config-clock-level = /bits/ 8 < 0x66>;
+ };
+ }
};
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 32ce9a6..5f599e3 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -197,6 +197,9 @@ struct hdmi_context {
struct hdmi_resources res;
+ struct hdmiphy_config *confs;
+ int nr_confs;
+
int hpd_gpio;
enum hdmi_type type;
@@ -256,7 +259,7 @@ static const struct hdmiphy_config hdmiphy_v13_configs[] = {
},
};
-static const struct hdmiphy_config hdmiphy_v14_configs[] = {
+static struct hdmiphy_config hdmiphy_v14_configs[] = {
{
.pixel_clock = 2520,
.conf = {
@@ -785,8 +788,8 @@ static int hdmi_find_phy_conf(struct hdmi_context *hdata,
u32 pixel_clock)
confs = hdmiphy_v13_configs;
count = ARRAY_SIZE(hdmiphy_v13_configs);
} else if (hdata->type == HDMI_TYPE14) {
- confs = hdmiphy_v14_configs;
- count = ARRAY_SIZE(hdmiphy_v14_configs);
+ confs = hdata->confs;
+ count = hdata->nr_confs;
} else
return -EINVAL;
@@ -1415,7 +1418,7 @@ static void hdmiphy_conf_apply(struct hdmi_context *hdata)
if (hdata->type == HDMI_TYPE13)
hdmiphy_data = hdmiphy_v13_configs[i].conf;
else
- hdmiphy_data = hdmiphy_v14_configs[i].conf;
+ hdmiphy_data = hdata->confs[i].conf;
memcpy(buffer, hdmiphy_data, 32);
ret = i2c_master_send(hdata->hdmiphy_port, buffer, 32);
@@ -1894,6 +1897,63 @@ fail:
return -ENODEV;
}
+static int drm_hdmi_dt_parse_phy_conf(struct platform_device *pdev,
+ struct hdmi_context *hdata)
+{
+ struct device *dev = &pdev->dev;
+ struct device_node *dev_np = dev->of_node;
+ struct device_node *ph
[PATCH 00/31] ARM: tegra: use common reset and DMA bindings
On 15.11.2013 22:53, Stephen Warren wrote: > 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) Overall, a good change. For host1x part: Acked-By: Terje Bergstrom This patch does not change the behavior, but we have in original code the problem that we don't flush the MC queue when resetting an engine. This can cause some memory writes to not hit memory. There was an earlier discussion on that, but we seem to have lost track of the issue. Terje
[PATCH 0/5] R-Car DU fixes and support for R8A7791
Hi Laurent, I am wondering if you have any patches to wire up this driver for the Koelsch board so that I might test it. On Wed, Nov 13, 2013 at 02:52:10PM +0100, Laurent Pinchart wrote: > Hello, > > This patch series adds support for the DU found in the R8A7791 SoC. It starts > by a cleanup patch (1/5), a bug fix (2/5), two preparation patches (3/5 and > 4/5) and finally adds support for the R8A7791 DU (5/5). > > Patch 2/5 is a candidate for stable kernels. There's no rush to get this > upstreamed in v3.13, v3.14 is fine. > > The series is based on top of the latest drm-next branch. > > Laurent Pinchart (5): > drm/rcar-du: Don't cast crtc to rcrtc twice in the same function > drm/rcar-du: Update plane pitch in .mode_set_base() operation > drm/rcar-du: Split features and quirks > drm/rcar-du: Add LVDS_LANES quirk > drm/rcar-du: Add support for the r8a7791 DU > > drivers/gpu/drm/rcar-du/rcar_du_crtc.c| 3 +-- > drivers/gpu/drm/rcar-du/rcar_du_drv.c | 24 ++-- > drivers/gpu/drm/rcar-du/rcar_du_drv.h | 14 -- > drivers/gpu/drm/rcar-du/rcar_du_kms.c | 4 ++-- > drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c | 15 ++- > drivers/gpu/drm/rcar-du/rcar_du_plane.c | 21 +++-- > 6 files changed, 58 insertions(+), 23 deletions(-) > > -- > Regards, > > Laurent Pinchart > > -- > To unsubscribe from this list: send the line "unsubscribe linux-sh" in > the body of a message to majordomo at vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >
DRM_TEGRA not buildable as a module
On Mon, Nov 18, 2013 at 4:10 AM, Thierry Reding wrote: > On Sat, Nov 16, 2013 at 03:25:09PM +0100, Josh Boyer wrote: >> Hi All, >> >> The commit below seems to have made the Tegra DRM driver a bool option >> instead of tristate: >> >> commit dee8268f8fb218c9e9b604a40f7dbdd395e910f9 >> Author: Thierry Reding >> Date: Wed Oct 9 10:32:49 2013 +0200 >> >> drm/tegra: Move driver to DRM tree >> >> In order to make subsystem-wide changes easier, move the Tegra DRM >> driver back into the DRM tree. >> >> Signed-off-by: Thierry Reding >> >> That means you can't build the driver as a module. Was this intended? >> The changelog doesn't mention anything about that and the existing >> help text on the option seems to imply it should be buildable as a >> module. > > This was intended yes. And it wasn't really a change at all, since prior > to the commit you mention above the DRM driver was always built into the > host1x driver. That's why I didn't think it necessary to mention it in > the commit message. > > I have some patches queued for 3.14 to enable the driver to be built as > a module. There are some dependencies such as symbols that need to be > exported so that the modules can be linked, so it'll require some amount > of coordination to make that work out within one release cycle, but I'm > hopeful that we can do it. OK. Thanks for the detailed reply. josh
[PATCH 0/4] Add dt support for exynos hdmiphy settings
For various revisions of a chipset if the signal pattern is changed for every revision, then the phy setting need to be updated correspondingly by measuring the signal. For getting correct signals the clock level and data de-emphasis levels needs to be adjusted. Since only these 2 values matter,we can move the same to dt, wherein we can have different dt files for every revision. This is an initial patchset towards achieving the same for exynos 5250 and can be later extended to future chipsets. V2: replaced moving of entire phy config structure with only required and justifiable conf registers. V3: Incorporated Mark Rutland's comments. V4: Rebased and included cros5250-common.dtsi. V5: removed nr-configs feild and also the constraint of having the exact number of configs in the dt file as in the driver, the programmer can add only the pixel clock that needs to be updated. V6: removed nr-configs form the dtsi files. Shirish S (4): ARM: dts: smdk5250: Add hdmi phy settings ARM: dts: arndale: Add hdmi phy settings ARM: exynos: dts: cros5250: Add hdmi phy settings drm: exynos: hdmi: Add dt support for hdmiphy settings .../devicetree/bindings/video/exynos_hdmi.txt | 33 + arch/arm/boot/dts/cros5250-common.dtsi | 74 +++ arch/arm/boot/dts/exynos5250-arndale.dts | 74 +++ arch/arm/boot/dts/exynos5250-smdk5250.dts | 74 +++ drivers/gpu/drm/exynos/exynos_hdmi.c | 77 +++- 5 files changed, 328 insertions(+), 4 deletions(-) -- 1.7.9.5
[PATCH 4/4] drm: exynos: hdmi: Add dt support for hdmiphy settings
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 | 33 +
drivers/gpu/drm/exynos/exynos_hdmi.c | 77 +++-
2 files changed, 106 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
index 323983b..1021c74 100644
--- a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
+++ b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
@@ -13,6 +13,31 @@ 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.
+ b) "config: config" specifies the phy configuration settings,
+ where 'N' denotes the number of configuration, since every
+ pixel clock can have its unique configuration.
+ "pixel-clock" specifies the pixel clock
+ "conifig-de-emphasis-level" provides fine control of TMDS data
+pre emphasis, below shown is example for
+ data de-emphasis register at address 0x145D0040.
+ hdmiphy at 38[16] for bits[3:0] permitted values are in
+ the range of 760 mVdiff to 1400 mVdiff at 20mVdiff
+ increments for every LSB
+ hdmiphy at 38[16] for bits[7:4] permitted values are in
+ the range of 0dB to -7.45dB at increments of -0.45dB
+ for every LSB.
+ "config-clock-level" provides fine control of TMDS data
+ amplitude for each channel,
+ for example if 0x145D005C is the address of clock level
+ register then,
+ hdmiphy at 38[23] for bits [1:0] permitted values are in
+ the range of 0 mVdiff & 60 mVdiff for each channel at
+ increments 20 mVdiff of amplitude levels for every LSB,
+ hdmiphy at 38[23] for bits [7:3] permitted values are in
+ the range of 790 and 1430 mV at 20mV increments for
+ every LSB.
Example:
hdmi {
@@ -20,4 +45,12 @@ Example:
reg = <0x1453 0x10>;
interrupts = <0 95 0>;
hpd-gpio = <&gpx3 7 1>;
+ hdmiphy-configs {
+ nr-configs = <1>;
+ config0: config0 {
+ pixel-clock = <2520>;
+ config-de-emphasis-level = /bits/ 8 <0x26>;
+ config-clock-level = /bits/ 8 < 0x66>;
+ };
+ }
};
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 32ce9a6..5f599e3 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -197,6 +197,9 @@ struct hdmi_context {
struct hdmi_resources res;
+ struct hdmiphy_config *confs;
+ int nr_confs;
+
int hpd_gpio;
enum hdmi_type type;
@@ -256,7 +259,7 @@ static const struct hdmiphy_config hdmiphy_v13_configs[] = {
},
};
-static const struct hdmiphy_config hdmiphy_v14_configs[] = {
+static struct hdmiphy_config hdmiphy_v14_configs[] = {
{
.pixel_clock = 2520,
.conf = {
@@ -785,8 +788,8 @@ static int hdmi_find_phy_conf(struct hdmi_context *hdata,
u32 pixel_clock)
confs = hdmiphy_v13_configs;
count = ARRAY_SIZE(hdmiphy_v13_configs);
} else if (hdata->type == HDMI_TYPE14) {
- confs = hdmiphy_v14_configs;
- count = ARRAY_SIZE(hdmiphy_v14_configs);
+ confs = hdata->confs;
+ count = hdata->nr_confs;
} else
return -EINVAL;
@@ -1415,7 +1418,7 @@ static void hdmiphy_conf_apply(struct hdmi_context *hdata)
if (hdata->type == HDMI_TYPE13)
hdmiphy_data = hdmiphy_v13_configs[i].conf;
else
- hdmiphy_data = hdmiphy_v14_configs[i].conf;
+ hdmiphy_data = hdata->confs[i].conf;
memcpy(buffer, hdmiphy_data, 32);
ret = i2c_master_send(hdata->hdmiphy_port, buffer, 32);
@@ -1894,6 +1897,63 @@ fail:
return -ENODEV;
}
+static int drm_hdmi_dt_parse_phy_conf(struct platform_device *pdev,
+ struct hdmi_context *hdata)
+{
+ struct device *dev = &pdev->dev;
+ struct device_node *dev_np = dev->of_node;
+ struct device_node *ph
[PATCH 1/4] ARM: dts: smdk5250: Add hdmi phy settings
This patch moves the hdmi phy setting to smdk5250
dts,as its more of a per board configuration and
also shall be easier for supporting future chipsets.
Signed-off-by: Shirish S
---
arch/arm/boot/dts/exynos5250-smdk5250.dts | 74 +
1 file changed, 74 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts
b/arch/arm/boot/dts/exynos5250-smdk5250.dts
index 2538b32..96e2cad 100644
--- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
+++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
@@ -220,6 +220,80 @@
hdmi {
hpd-gpio = <&gpx3 7 0>;
+ hdmiphy-configs {
+ /*
+ * Eye diagram test passed for:
+ * Data de-emphasis: -0.7dB & Data Level: 880mV
+ * i.e., 0010 0110 = 0x26
+ * and Clock level of 515mV and diff 1030mV
+ * i.e., 0x66
+ */
+ config0: config0 {
+ pixel-clock = <2520>;
+ config-de-emphasis-level = /bits/ 8 <0x26>;
+ config-clock-level = /bits/ 8 < 0x66>;
+ };
+ config1: config1 {
+ pixel-clock = <2700>;
+ config-de-emphasis-level = /bits/ 8 <0x26>;
+ config-clock-level = /bits/ 8 < 0x66>;
+ };
+ config2: config2 {
+ pixel-clock = <27027000>;
+ config-de-emphasis-level = /bits/ 8 <0x26>;
+ config-clock-level = /bits/ 8 < 0x66>;
+ };
+ config3: config3 {
+ pixel-clock = <3600>;
+ config-de-emphasis-level = /bits/ 8 <0x26>;
+ config-clock-level = /bits/ 8 < 0x66>;
+ };
+ config4: config4 {
+ pixel-clock = <4000>;
+ config-de-emphasis-level = /bits/ 8 <0x26>;
+ config-clock-level = /bits/ 8 < 0x66>;
+ };
+ config5: config5 {
+ pixel-clock = <6500>;
+ config-de-emphasis-level = /bits/ 8 <0x26>;
+ config-clock-level = /bits/ 8 < 0x66>;
+ };
+ config6: config6 {
+ pixel-clock = <74176000>;
+ config-de-emphasis-level = /bits/ 8 <0x26>;
+ config-clock-level = /bits/ 8 < 0x66>;
+ };
+ config7: config7 {
+ pixel-clock = <7425>;
+ config-de-emphasis-level = /bits/ 8 <0x26>;
+ config-clock-level = /bits/ 8 < 0x66>;
+ };
+ config8: config8 {
+ pixel-clock = <8350>;
+ config-de-emphasis-level = /bits/ 8 <0x26>;
+ config-clock-level = /bits/ 8 < 0x66>;
+ };
+ config9: config9 {
+ pixel-clock = <10650>;
+ config-de-emphasis-level = /bits/ 8 <0x26>;
+ config-clock-level = /bits/ 8 < 0x66>;
+ };
+ config10: config10 {
+ pixel-clock = <10800>;
+ config-de-emphasis-level = /bits/ 8 <0x26>;
+ config-clock-level = /bits/ 8 < 0x66>;
+ };
+ config11: config11 {
+ pixel-clock = <14625>;
+ config-de-emphasis-level = /bits/ 8 <0x26>;
+ config-clock-level = /bits/ 8 < 0x66>;
+ };
+ config12: config12 {
+ pixel-clock = <14850>;
+ config-de-emphasis-level = /bits/ 8 <0x26>;
+ config-clock-level = /bits/ 8 < 0x66>;
+ };
+ };
};
codec at 1100 {
--
1.7.9.5
[PATCH 3/4] ARM: exynos: dts: cros5250: Add hdmi phy settings
This patch moves the hdmi phy setting to arndale dts,
as its more of a per board configuration and also
shall be easier for supporting future chipsets.
Signed-off-by: Shirish S
---
arch/arm/boot/dts/cros5250-common.dtsi | 74
1 file changed, 74 insertions(+)
diff --git a/arch/arm/boot/dts/cros5250-common.dtsi
b/arch/arm/boot/dts/cros5250-common.dtsi
index dc259e8b..77408c6 100644
--- a/arch/arm/boot/dts/cros5250-common.dtsi
+++ b/arch/arm/boot/dts/cros5250-common.dtsi
@@ -301,6 +301,80 @@
hdmi {
hpd-gpio = <&gpx3 7 0>;
+ hdmiphy-configs {
+ /*
+ * Eye diagram test passed for:
+ * Data de-emphasis: -0.7dB & Data Level: 880mV
+ * i.e., 0010 0110 = 0x26
+ * and Clock level of 515mV and diff 1030mV
+ * i.e., 0x66
+ */
+ config0: config0 {
+ pixel-clock = <2520>;
+ config-de-emphasis-level = /bits/ 8 <0x26>;
+ config-clock-level = /bits/ 8 < 0x66>;
+ };
+ config1: config1 {
+ pixel-clock = <2700>;
+ config-de-emphasis-level = /bits/ 8 <0x26>;
+ config-clock-level = /bits/ 8 < 0x66>;
+ };
+ config2: config2 {
+ pixel-clock = <27027000>;
+ config-de-emphasis-level = /bits/ 8 <0x26>;
+ config-clock-level = /bits/ 8 < 0x66>;
+ };
+ config3: config3 {
+ pixel-clock = <3600>;
+ config-de-emphasis-level = /bits/ 8 <0x26>;
+ config-clock-level = /bits/ 8 < 0x66>;
+ };
+ config4: config4 {
+ pixel-clock = <4000>;
+ config-de-emphasis-level = /bits/ 8 <0x26>;
+ config-clock-level = /bits/ 8 < 0x66>;
+ };
+ config5: config5 {
+ pixel-clock = <6500>;
+ config-de-emphasis-level = /bits/ 8 <0x26>;
+ config-clock-level = /bits/ 8 < 0x66>;
+ };
+ config6: config6 {
+ pixel-clock = <74176000>;
+ config-de-emphasis-level = /bits/ 8 <0x26>;
+ config-clock-level = /bits/ 8 < 0x66>;
+ };
+ config7: config7 {
+ pixel-clock = <7425>;
+ config-de-emphasis-level = /bits/ 8 <0x26>;
+ config-clock-level = /bits/ 8 < 0x66>;
+ };
+ config8: config8 {
+ pixel-clock = <8350>;
+ config-de-emphasis-level = /bits/ 8 <0x26>;
+ config-clock-level = /bits/ 8 < 0x66>;
+ };
+ config9: config9 {
+ pixel-clock = <10650>;
+ config-de-emphasis-level = /bits/ 8 <0x26>;
+ config-clock-level = /bits/ 8 < 0x66>;
+ };
+ config10: config10 {
+ pixel-clock = <10800>;
+ config-de-emphasis-level = /bits/ 8 <0x26>;
+ config-clock-level = /bits/ 8 < 0x66>;
+ };
+ config11: config11 {
+ pixel-clock = <14625>;
+ config-de-emphasis-level = /bits/ 8 <0x26>;
+ config-clock-level = /bits/ 8 < 0x66>;
+ };
+ config12: config12 {
+ pixel-clock = <14850>;
+ config-de-emphasis-level = /bits/ 8 <0x26>;
+ config-clock-level = /bits/ 8 < 0x66>;
+ };
+ };
};
gpio-keys {
--
1.7.9.5
DRM_TEGRA not buildable as a module
On Sat, Nov 16, 2013 at 03:25:09PM +0100, Josh Boyer wrote: > Hi All, > > The commit below seems to have made the Tegra DRM driver a bool option > instead of tristate: > > commit dee8268f8fb218c9e9b604a40f7dbdd395e910f9 > Author: Thierry Reding > Date: Wed Oct 9 10:32:49 2013 +0200 > > drm/tegra: Move driver to DRM tree > > In order to make subsystem-wide changes easier, move the Tegra DRM > driver back into the DRM tree. > > Signed-off-by: Thierry Reding > > That means you can't build the driver as a module. Was this intended? > The changelog doesn't mention anything about that and the existing > help text on the option seems to imply it should be buildable as a > module. This was intended yes. And it wasn't really a change at all, since prior to the commit you mention above the DRM driver was always built into the host1x driver. That's why I didn't think it necessary to mention it in the commit message. I have some patches queued for 3.14 to enable the driver to be built as a module. There are some dependencies such as symbols that need to be exported so that the modules can be linked, so it'll require some amount of coordination to make that work out within one release cycle, but I'm hopeful that we can do it. Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131118/1ba23072/attachment.pgp>
[Mesa-dev] [PATCH] Don't use libudev for glx/dri3
On 18/11/13 01:08, Keith Packard wrote:
> libudev doesn't have a stable API/ABI, and if the application wants to use one
> version, we'd best not load another into libGL.
>
> Signed-off-by: Keith Packard
> ---
>
Hi Keith,
Did you had the chance to look at src/gallium/targets/egl-static/egl.c?
It has a different implementation of drm_fd_get_pci_id, whenever udev is
not available.
AFAICS it goes back to the kernel via the relevant ioctl to retrieve the
deviceid/chipid. Currently all but nouveau provide such information. I'm
thinking that this approach might be more reasonable for those concerned
with portability of the udev bits (think on *BSD).
I'm not nitpicking, just thought you might find this interesting.
Cheers,
Emil
> Sorry for the patch spam; I hadn't rebased in a while and there was a
> configure.ac conflict. Here's a version which should apply cleanly to master.
>
> configure.ac | 8
> src/glx/dri3_common.c | 104
> +++---
> 2 files changed, 90 insertions(+), 22 deletions(-)
>
> diff --git a/configure.ac b/configure.ac
> index fb16338..656d9d0 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -821,9 +821,6 @@ xyesno)
> PKG_CHECK_MODULES([DRI2PROTO], [dri2proto >= $DRI2PROTO_REQUIRED])
> GL_PC_REQ_PRIV="$GL_PC_REQ_PRIV libdrm >= $LIBDRM_REQUIRED"
> if test x"$enable_dri3" = xyes; then
> -if test x"$have_libudev" != xyes; then
> - AC_MSG_ERROR([DRI3 requires libudev >= $LIBUDEV_REQUIRED])
> -fi
> PKG_CHECK_MODULES([DRI3PROTO], [dri3proto >=
> $DRI3PROTO_REQUIRED])
> PKG_CHECK_MODULES([PRESENTPROTO], [presentproto >=
> $PRESENTPROTO_REQUIRED])
> fi
> @@ -847,11 +844,6 @@ xyesno)
> X11_INCLUDES="$X11_INCLUDES $DRIGL_CFLAGS"
> GL_LIB_DEPS="$DRIGL_LIBS"
>
> -if test x"$enable_dri3$have_libudev" = xyesyes; then
> -X11_INCLUDES="$X11_INCLUDES $LIBUDEV_CFLAGS"
> -GL_LIB_DEPS="$GL_LIB_DEPS $LIBUDEV_LIBS"
> -fi
> -
> # need DRM libs, $PTHREAD_LIBS, etc.
> GL_LIB_DEPS="$GL_LIB_DEPS $LIBDRM_LIBS -lm $PTHREAD_LIBS $DLOPEN_LIBS"
> GL_PC_LIB_PRIV="-lm $PTHREAD_LIBS $DLOPEN_LIBS"
> diff --git a/src/glx/dri3_common.c b/src/glx/dri3_common.c
> index c758f96..7330d79 100644
> --- a/src/glx/dri3_common.c
> +++ b/src/glx/dri3_common.c
> @@ -72,22 +72,41 @@
> #include "dri3_priv.h"
>
> #define DRIVER_MAP_DRI3_ONLY
> +
> #include "pci_ids/pci_id_driver_map.h"
>
> +static dev_t
> +dri3_rdev_from_fd(int fd)
> +{
> + struct stat buf;
> +
> + if (fstat(fd, &buf) < 0) {
> + ErrorMessageF("DRI3: failed to stat fd %d", fd);
> + return 0;
> + }
> + return buf.st_rdev;
> +}
> +
> +/*
> + * There are multiple udev library versions, and they aren't polite about
> + * symbols, so just avoid using it until some glorious future when the udev
> + * developers figure out how to not break things
> + */
> +
> +#define USE_UDEV 0
> +#if USE_UDEV
> #include
>
> static struct udev_device *
> dri3_udev_device_new_from_fd(struct udev *udev, int fd)
> {
> struct udev_device *device;
> - struct stat buf;
> + dev_t rdev = dri3_rdev_from_fd(fd);
>
> - if (fstat(fd, &buf) < 0) {
> - ErrorMessageF("DRI3: failed to stat fd %d", fd);
> + if (rdev == 0)
>return NULL;
> - }
>
> - device = udev_device_new_from_devnum(udev, 'c', buf.st_rdev);
> + device = udev_device_new_from_devnum(udev, 'c', rdev);
> if (device == NULL) {
>ErrorMessageF("DRI3: could not create udev device for fd %d", fd);
>return NULL;
> @@ -96,19 +115,20 @@ dri3_udev_device_new_from_fd(struct udev *udev, int fd)
> return device;
> }
>
> -char *
> -dri3_get_driver_for_fd(int fd)
> +static int
> +dri3_get_pci_id_from_fd(int fd, int *vendorp, int *chipp)
> {
> struct udev *udev;
> struct udev_device *device, *parent;
> const char *pci_id;
> - char *driver = NULL;
> - int vendor_id, chip_id, i, j;
> + int ret = 0;
>
> udev = udev_new();
> + if (!udev)
> + goto no_udev;
> device = dri3_udev_device_new_from_fd(udev, fd);
> if (device == NULL)
> - return NULL;
> + goto no_dev;
>
> parent = udev_device_get_parent(device);
> if (parent == NULL) {
> @@ -118,10 +138,69 @@ dri3_get_driver_for_fd(int fd)
>
> pci_id = udev_device_get_property_value(parent, "PCI_ID");
> if (pci_id == NULL ||
> - sscanf(pci_id, "%x:%x", &vendor_id, &chip_id) != 2) {
> + sscanf(pci_id, "%x:%x", vendorp, chipp) != 2) {
>ErrorMessageF("DRI3: malformed or no PCI ID");
>goto out;
> }
> + ret = 1;
> +
> +out:
> + udev_device_unref(device);
> +no_dev:
> + udev_unref(udev);
> +no_udev:
> + return ret;
> +}
> +#else
> +
> +#define SYS_PATH_MAX256
> +
> +static int
> +dri3_read_hex(dev_t rdev, char *entry, int *value)
> +{
> + char path[SYS_PATH_MAX];
> + FILE *f;
> + int
[Mesa-dev] [PATCH] Don't use libudev for glx/dri3
Emil Velikov writes: > On 18/11/13 01:08, Keith Packard wrote: >> libudev doesn't have a stable API/ABI, and if the application wants to use >> one >> version, we'd best not load another into libGL. >> >> Signed-off-by: Keith Packard >> --- >> > Hi Keith, > > Did you had the chance to look at src/gallium/targets/egl-static/egl.c? > It has a different implementation of drm_fd_get_pci_id, whenever udev is > not available. Yeah, it's ugly in a different way from the udev technique... > AFAICS it goes back to the kernel via the relevant ioctl to retrieve the > deviceid/chipid. Currently all but nouveau provide such information. I'm > thinking that this approach might be more reasonable for those concerned > with portability of the udev bits (think on *BSD). I'd encourage some kind of standard IOCTL from DRM that returns the PCI-ID of the underlying device, rather than relying on the level of kludge present in either the udev (or my fake udev) method or the non-udev path in the egl code... > I'm not nitpicking, just thought you might find this interesting. Definitely interesting; it's almost what we want -- the kernel knows the information, there just isn't a clean way of getting it (and no way at all for some devices). -- keith.packard at intel.com -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131118/bed4ee40/attachment-0001.pgp>
