Re: [PATCH] nouveau: fix reclocking on nv40
On Friday 16 August 2013 14:57:07 Pali Rohár wrote: > In commit 77145f1cbdf8d28b46ff8070ca749bad821e0774 was > introduced error which cause that reclocking on nv40 not > working anymore. There is missing assigment of return value > from pll_calc to ret. > > Signed-off-by: Pali Rohár > Signed-off-by: Martin Peres > --- > drivers/gpu/drm/nouveau/nv40_pm.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/nouveau/nv40_pm.c > b/drivers/gpu/drm/nouveau/nv40_pm.c index 3af5bcd..625f80d > 100644 > --- a/drivers/gpu/drm/nouveau/nv40_pm.c > +++ b/drivers/gpu/drm/nouveau/nv40_pm.c > @@ -131,7 +131,7 @@ nv40_calc_pll(struct drm_device *dev, u32 > reg, struct nvbios_pll *pll, if (clk < pll->vco1.max_freq) > pll->vco2.max_freq = 0; > > - pclk->pll_calc(pclk, pll, clk, &coef); > + ret = pclk->pll_calc(pclk, pll, clk, &coef); > if (ret == 0) > return -ERANGE; Hello, it is possible to include this patch in 3.11? Or it is too late now and need to wait for 3.12? -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Nouveau] [PATCH] drm/nouveau: fix vblank deadlock
On 08/12/2013 07:50 AM, Maarten Lankhorst wrote:
This fixes a deadlock inversion when vblank is enabled/disabled by drm.
&dev->vblank_time_lock is always taken when the vblank state is toggled,
which caused a deadlock when &event->lock was also taken during
event_get/put.
Solve the race by requiring that lock to change enable/disable state,
and always keeping vblank on the event list. Core drm ignores unwanted
vblanks, so extra calls to drm_handle_vblank are harmless.
I don't feel this is the appropriate solution to the lock inversion
between vblank_time_lock and event->lock.
Preferably drm core should correct the interface layer bug; ie., calling
into a sub-driver holding a lock _and_ requiring the sub-driver to call a
drm helper function which claims the same lock is bad design. The console
lock suffers from the same design flaw and is a constant problem.
Alternatively, the event trigger could be lockless; ie., the event list
could be an RCU list instead. In this way, the event->lock does not need
to be claimed, and thus no lock inversion is possible. The main drawback
here is that currently the event->lock enforces non-overlapping lifetimes
between the event handler and the event. Untangling object lifetimes in
nouveau is a non-trivial exercise.
Regards,
Peter Hurley
Signed-off-by: Maarten Lankhorst
---
diff --git a/drivers/gpu/drm/nouveau/core/core/event.c
b/drivers/gpu/drm/nouveau/core/core/event.c
index 7eb81c1..78bff7c 100644
--- a/drivers/gpu/drm/nouveau/core/core/event.c
+++ b/drivers/gpu/drm/nouveau/core/core/event.c
@@ -23,43 +23,64 @@
#include
#include
-static void
-nouveau_event_put_locked(struct nouveau_event *event, int index,
-struct nouveau_eventh *handler)
-{
- if (!--event->index[index].refs) {
- if (event->disable)
- event->disable(event, index);
- }
- list_del(&handler->head);
-}
-
void
nouveau_event_put(struct nouveau_event *event, int index,
struct nouveau_eventh *handler)
{
unsigned long flags;
+ if (index >= event->index_nr)
+ return;
+
spin_lock_irqsave(&event->lock, flags);
- if (index < event->index_nr)
- nouveau_event_put_locked(event, index, handler);
+ list_del(&handler->head);
+
+ if (event->toggle_lock)
+ spin_lock(event->toggle_lock);
+ nouveau_event_disable_locked(event, index, 1);
+ if (event->toggle_lock)
+ spin_unlock(event->toggle_lock);
+
spin_unlock_irqrestore(&event->lock, flags);
}
void
+nouveau_event_enable_locked(struct nouveau_event *event, int index)
+{
+ if (index >= event->index_nr)
+ return;
+
+ if (!event->index[index].refs++ && event->enable)
+ event->enable(event, index);
+}
+
+void
+nouveau_event_disable_locked(struct nouveau_event *event, int index, int refs)
+{
+ if (index >= event->index_nr)
+ return;
+
+ event->index[index].refs -= refs;
+ if (!event->index[index].refs && event->disable)
+ event->disable(event, index);
+}
+
+void
nouveau_event_get(struct nouveau_event *event, int index,
struct nouveau_eventh *handler)
{
unsigned long flags;
+ if (index >= event->index_nr)
+ return;
+
spin_lock_irqsave(&event->lock, flags);
- if (index < event->index_nr) {
- list_add(&handler->head, &event->index[index].list);
- if (!event->index[index].refs++) {
- if (event->enable)
- event->enable(event, index);
- }
- }
+ list_add(&handler->head, &event->index[index].list);
+ if (event->toggle_lock)
+ spin_lock(event->toggle_lock);
+ nouveau_event_enable_locked(event, index);
+ if (event->toggle_lock)
+ spin_unlock(event->toggle_lock);
spin_unlock_irqrestore(&event->lock, flags);
}
@@ -68,6 +89,7 @@ nouveau_event_trigger(struct nouveau_event *event, int index)
{
struct nouveau_eventh *handler, *temp;
unsigned long flags;
+ int refs = 0;
if (index >= event->index_nr)
return;
@@ -75,9 +97,17 @@ nouveau_event_trigger(struct nouveau_event *event, int index)
spin_lock_irqsave(&event->lock, flags);
list_for_each_entry_safe(handler, temp, &event->index[index].list,
head) {
if (handler->func(handler, index) == NVKM_EVENT_DROP) {
- nouveau_event_put_locked(event, index, handler);
+ list_del(&handler->head);
+ refs++;
}
}
+ if (refs) {
+ if (event->toggle_lock)
+ spin_lock(event->toggle_lock);
+ nouveau_event_disable_locked(event, index, refs);
+ if (event->toggle_lock)
+
[PATCH 1/2] drm/i915: Fix bug while calculating the clock value using do_div in ironlake_crtc_clock_get
We need to round up the values since the comparison in drm_mode_equal might fail if division results in fractional part Signed-off-by: Furquan Shaikh --- drivers/gpu/drm/i915/intel_display.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 0f40f8e..e0069f4 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -7190,7 +7190,11 @@ static void ironlake_crtc_clock_get(struct intel_crtc *crtc, return; clock = ((u64)link_m * (u64)link_freq * (u64)repeat); - do_div(clock, link_n); + /* This is required because the value comes out to be in fraction + (eg. 70699.54). Need to round it up since values are compared in + drm_mode_equal + */ + clock = DIV_ROUND_UP_ULL(clock, link_n); pipe_config->adjusted_mode.clock = clock; } -- 1.8.3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/i915: add fast boot support for Haswell
Enables getting correct mode clock when reading pipe config
This patch has been tested successfully on top of drm-intel-nightly tree
Signed-off-by: Furquan Shaikh
---
drivers/gpu/drm/i915/i915_reg.h | 6
drivers/gpu/drm/i915/intel_ddi.c | 70
drivers/gpu/drm/i915/intel_display.c | 1 +
3 files changed, 77 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 2b96d6b..9511129 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -4970,6 +4970,7 @@
#define SPLL_PLL_NON_SSC (2<<28)
#define SPLL_PLL_FREQ_810MHz (0<<26)
#define SPLL_PLL_FREQ_1350MHz (1<<26)
+#define SPLL_PLL_FREQ_MASK (3<<26)
/* WRPLL */
#define WRPLL_CTL1 0x46040
@@ -4983,6 +4984,10 @@
#define WRPLL_DIVIDER_POST(x) ((x)<<8)
#define WRPLL_DIVIDER_FEEDBACK(x) ((x)<<16)
+#define WRPLL_DIVIDER_REFERENCE_BITS(reg)(reg & 0xff)
+#define WRPLL_DIVIDER_POST_BITS(reg) ((reg >> 8) & 0x3f)
+#define WRPLL_DIVIDER_FEEDBACK_BITS(reg) ((reg >> 16) & 0xff)
+
/* Port clock selection */
#define PORT_CLK_SEL_A 0x46100
#define PORT_CLK_SEL_B 0x46104
@@ -4994,6 +4999,7 @@
#define PORT_CLK_SEL_WRPLL1 (4<<29)
#define PORT_CLK_SEL_WRPLL2 (5<<29)
#define PORT_CLK_SEL_NONE (7<<29)
+#define PORT_CLK_SEL_MASK (7<<29)
/* Transcoder clock selection */
#define TRANS_CLK_SEL_A0x46140
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index b8c096b..a24a375 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1246,6 +1246,74 @@ static void intel_ddi_hot_plug(struct intel_encoder
*intel_encoder)
intel_dp_check_link_status(intel_dp);
}
+static void intel_ddi_get_clock(struct intel_encoder *encoder,
+ struct intel_crtc_config *pipe_config)
+{
+ struct drm_i915_private *dev_priv = encoder->base.dev->dev_private;
+ int port = intel_ddi_get_encoder_port(encoder);
+ u32 temp = I915_READ(PORT_CLK_SEL(port)) & PORT_CLK_SEL_MASK;
+ u8 link_bw;
+
+ if ((temp == PORT_CLK_SEL_LCPLL_810) ||
+ (temp == PORT_CLK_SEL_LCPLL_1350) ||
+ (temp == PORT_CLK_SEL_LCPLL_2700)) {
+
+ switch (temp) {
+ case PORT_CLK_SEL_LCPLL_810:
+ link_bw = DP_LINK_BW_1_62;
+ break;
+ case PORT_CLK_SEL_LCPLL_1350:
+ link_bw = DP_LINK_BW_2_7;
+ break;
+ case PORT_CLK_SEL_LCPLL_2700:
+ link_bw = DP_LINK_BW_5_4;
+ break;
+ }
+ pipe_config->port_clock = drm_dp_bw_code_to_link_rate(link_bw);
+ } else if ((temp == PORT_CLK_SEL_WRPLL1) ||
+ (temp == PORT_CLK_SEL_WRPLL2)) {
+ uint64_t p, n2, r2;
+ u32 val, reg;
+ uint64_t freq2k;
+
+ switch (temp) {
+ case PORT_CLK_SEL_WRPLL1:
+ reg = WRPLL_CTL1;
+ break;
+ case PORT_CLK_SEL_WRPLL2:
+ reg = WRPLL_CTL2;
+ break;
+ }
+ val = I915_READ(reg);
+ r2 = WRPLL_DIVIDER_REFERENCE_BITS(val);
+ p = WRPLL_DIVIDER_POST_BITS(val);
+ n2 = WRPLL_DIVIDER_FEEDBACK_BITS(val);
+
+ freq2k = DIV_ROUND_UP_ULL(LC_FREQ * n2, r2 * p);
+ pipe_config->port_clock = freq2k / 10;
+ } else if (temp == PORT_CLK_SEL_SPLL) {
+ u32 val;
+
+ val = I915_READ(PORT_CLK_SEL_SPLL);
+
+ switch (val & SPLL_PLL_FREQ_MASK) {
+ case SPLL_PLL_FREQ_810MHz:
+ pipe_config->port_clock = 81;
+ break;
+ case SPLL_PLL_FREQ_1350MHz:
+ pipe_config->port_clock = 135;
+ break;
+ default:
+ WARN(1, "Invalid pll freq %d\n",
+val & SPLL_PLL_FREQ_MASK);
+ return;
+ }
+ } else {
+ WARN(1, "Invalid clock selection %d\n", temp);
+ return;
+ }
+}
+
static void intel_ddi_get_config(struct intel_encoder *encoder,
struct intel_crtc_config *pipe_config)
{
@@ -1265,6 +1333,8 @@ static void intel_ddi_get_config(struct intel_encoder
*encoder,
flags |= DRM_MODE_FLAG_NVSYNC;
pipe_config->adjusted_mode.flags |= flags;
+
+ intel_ddi_get_clock(encoder, pipe_config);
}
static void intel_ddi_destroy(struct drm_encoder *encoder)
diff --git a/drivers/gpu/drm/i915/intel_dis
[PULL] drm-intel-next
Hi Dave, New pile of stuff for -next: - Cleanup of the old crtc helper callbacks, all encoders are now converted to the i915 modeset infrastructure. - Massive amount of wm patches from Ville for ilk, snb, ivb, hsw, this is prep work to eventually get things going for nuclear pageflips where we need to adjust watermarks on the fly. - More vm/vma patches from Ben. This refactoring isn't yet fully rolled out, we miss the execbuf conversion and some of the low-level bind/unbind support code. - Convert our hdmi infoframe code to use the new common helper functions (Damien). This contains some bugfixes for the common infoframe helpers. - Some cruft removal from Damien. - Various smaller bits&pieces all over, as usual. Cheers, Daniel The following changes since commit cd234b0bfd5ab012e42274b24aae420fa1823d58: drm/i915: Do not dereference NULL crtc or fb until after checking (2013-08-04 21:13:43 +0200) are available in the git repository at: git://people.freedesktop.org/~danvet/drm-intel tags/drm-intel-next-2013-08-09 for you to fetch changes up to 5c536613d8ebda3da0448550d0a997651a6048e2: drm/i915: Fix FB WM for HSW (2013-08-09 20:27:43 +0200) Ben Widawsky (22): drm/i915/hsw: Change default LLC age to 3 drm/i915: Create an init vm drm/i915: Rework drop caches for checkpatch drm/i915: Make proper functions for VMs drm/i915: Use bound list for inactive shrink drm/i915: Add VM to pin drm/i915: Use ggtt_vm to save some typing drm/i915: Update describe_obj drm/i915: thread address space through execbuf drm/i915: make caching operate on all address spaces drm/i915: BUG_ON put_pages later drm/i915: make reset&hangcheck code VM aware drm/i915: eliminate dead domain clearing on reset drm/i915: Improve VMA comments drm/i915: Rework __i915_gem_shrink drm/i915: plumb VM into bind/unbind code drm/i915: Use new bind/unbind in eviction code drm/i915: turn bound_ggtt checks to bound_any drm/i915: Fix up map and fenceable for VMA drm/i915: mm_list is per VMA drm/i915: Update error capture for VMs drm/i915: Add vma to list at creation Chris Wilson (7): drm/i915: Squelch repeated reasoning for why FBC cannot be activated drm/i915: Use the same pte_encoding for ppgtt as for gtt drm/i915: Tidy the macro casting by using an inline function drm/i915: Acquire dpio_lock for VLV sideband programming in DP/HDMI drm/i915: Rename I915_CACHE_MLC_LLC to L3_LLC for Ivybridge drm/i915: Export intel_framebuffer_fini drm/i915: List objects allocated from stolen memory in debugfs Damien Lespiau (19): video/hdmi: Replace the payload length by their defines video/hdmi: Introduce a generic hdmi_infoframe union video/hdmi: Add a macro to return the size of a full infoframe video/hmdi: Clear the whole incoming buffer, not just the infoframe size drm: Don't generate invalid AVI infoframes for CEA modes drm/i915/hdmi: Change the write_infoframe vfunc to take a buffer and a type drm/i915/hdmi: Port the infoframe code to the common hdmi helpers drm/i915/sdvo: Port the infoframe code to the shared infrastructure drm/i915: Remove the now obsolete infoframe definitions drm: Handle the DBLCLK flag in the common infoframe helper drm: Set aspect ratio fields in the AVI infoframe even for non CEA modes drm/i915/hmdi: Rename set_infoframe() to write_infoframe() drm/i915: Remove stale prototypes drm/i915: Remove i915_gem_object_check_coherency() drm/i915: Fix #endif comment drm/i915: Make i915_hangcheck_elapsed() static drm/i915: Make intel_encoder_dpms() static drm/i915: Remove intel_modeset_disable() drm/i915: Make intel_set_mode() static Dan Carpenter (2): drm/i915: unbreak i915_gem_object_ggtt_unbind() drm/i915: fix a limit check in hsw_compute_wm_results() Daniel Vetter (13): drm/i915/dvo: use intel_encoder to the upcast macro drm/i915/dvo: switch ->mode_fixup to ->compute_config drm/i915: rip out legacy encoder->mode_fixup logic drm/i915/dvo: use native encoder ->mode_set callback drm/i915/sdvo: use intel_encoder for upcast helper drm/i915/tv: Use native encoder->mode_set callback drm/i915/crt: use native encoder->mode_set callback drm/i915/hdmi: use native encoder mode_set callback drm/i915/dp: use native encoder ->mode_set callback drm/i915/lvds: use the native encoder ->mode_set callback drm/i915/ddi: use the native encoder ->mode_set callback drm/i915: rip out legacy encoder->mode_set callback drm/i915: clean up crtc timings computation Imre Deak (1): drm/i915: make user mode sync polarity setting explicit Jani Nikula (3): drm/i915: rearrange vlv dp enable and pre_enable cal
[PATCH 0/2] update pixel format setting to fimd driver
This patch series fix pixel format setting according to drm_framebuffer's pixel_format, and check if a given window supports alpha channel or not. Inki Dae (2): drm/exynos: fix fimd pixel format setting drm/exynos: check a pixel format to a particular window layer drivers/gpu/drm/exynos/exynos_drm_fimd.c | 45 -- 1 files changed, 24 insertions(+), 21 deletions(-) -- 1.7.5.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm/exynos: fix fimd pixel format setting
This patch fixes wrong pixel format setting.
A pixel format is decided according to bpp and depth, or user-requested
format but fimd driver considered only bpp value to decide a proper pixel
format. So this patch makes a proper pixel format to be set according
to drm_framebuffer's pixel_format which is set by addfb with bpp and
depth, or addfb2 with user-requested format.
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 34 +++--
1 files changed, 13 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index b8aa8fe..13d5afb 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -91,6 +91,7 @@ struct fimd_win_data {
unsigned intfb_width;
unsigned intfb_height;
unsigned intbpp;
+ unsigned intpixel_format;
dma_addr_t dma_addr;
unsigned intbuf_offsize;
unsigned intline_size; /* bytes */
@@ -397,6 +398,7 @@ static void fimd_win_mode_set(struct device *dev,
win_data->fb_height = overlay->fb_height;
win_data->dma_addr = overlay->dma_addr[0] + offset;
win_data->bpp = overlay->bpp;
+ win_data->pixel_format = overlay->pixel_format;
win_data->buf_offsize = (overlay->fb_width - overlay->crtc_width) *
(overlay->bpp >> 3);
win_data->line_size = overlay->crtc_width * (overlay->bpp >> 3);
@@ -418,39 +420,29 @@ static void fimd_win_set_pixfmt(struct device *dev,
unsigned int win)
val = WINCONx_ENWIN;
- switch (win_data->bpp) {
- case 1:
- val |= WINCON0_BPPMODE_1BPP;
- val |= WINCONx_BITSWP;
- val |= WINCONx_BURSTLEN_4WORD;
- break;
- case 2:
- val |= WINCON0_BPPMODE_2BPP;
- val |= WINCONx_BITSWP;
- val |= WINCONx_BURSTLEN_8WORD;
- break;
- case 4:
- val |= WINCON0_BPPMODE_4BPP;
- val |= WINCONx_BITSWP;
- val |= WINCONx_BURSTLEN_8WORD;
- break;
- case 8:
+ switch (win_data->pixel_format) {
+ case DRM_FORMAT_C8:
val |= WINCON0_BPPMODE_8BPP_PALETTE;
val |= WINCONx_BURSTLEN_8WORD;
val |= WINCONx_BYTSWP;
break;
- case 16:
+ case DRM_FORMAT_XRGB1555:
+ val |= WINCON0_BPPMODE_16BPP_1555;
+ val |= WINCONx_HAWSWP;
+ val |= WINCONx_BURSTLEN_16WORD;
+ break;
+ case DRM_FORMAT_RGB565:
val |= WINCON0_BPPMODE_16BPP_565;
val |= WINCONx_HAWSWP;
val |= WINCONx_BURSTLEN_16WORD;
break;
- case 24:
+ case DRM_FORMAT_XRGB:
val |= WINCON0_BPPMODE_24BPP_888;
val |= WINCONx_WSWP;
val |= WINCONx_BURSTLEN_16WORD;
break;
- case 32:
- val |= WINCON1_BPPMODE_28BPP_A4888
+ case DRM_FORMAT_ARGB:
+ val |= WINCON1_BPPMODE_25BPP_A1888
| WINCON1_BLD_PIX | WINCON1_ALPHA_SEL;
val |= WINCONx_WSWP;
val |= WINCONx_BURSTLEN_16WORD;
--
1.7.5.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/exynos: check a pixel format to a particular window layer
This patch checks if a requested window supports alpha channel or not.
In case of s3c64xx, window 0 doesn't support alpha channel so if
the request pixel format is ARGB then change it to XRGB.
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 13d5afb..f8889d2 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -66,11 +66,13 @@ struct fimd_driver_data {
unsigned int has_shadowcon:1;
unsigned int has_clksel:1;
+ unsigned int has_limited_fmt:1;
};
static struct fimd_driver_data s3c64xx_fimd_driver_data = {
.timing_base = 0x0,
.has_clksel = 1,
+ .has_limited_fmt = 1,
};
static struct fimd_driver_data exynos4_fimd_driver_data = {
@@ -420,6 +422,15 @@ static void fimd_win_set_pixfmt(struct device *dev,
unsigned int win)
val = WINCONx_ENWIN;
+ /*
+* In case of s3c64xx, window 0 doesn't support alpha channel.
+* So the request format is ARGB then change it to XRGB.
+*/
+ if (ctx->driver_data->has_limited_fmt && !win) {
+ if (win_data->pixel_format == DRM_FORMAT_ARGB)
+ win_data->pixel_format = DRM_FORMAT_XRGB;
+ }
+
switch (win_data->pixel_format) {
case DRM_FORMAT_C8:
val |= WINCON0_BPPMODE_8BPP_PALETTE;
--
1.7.5.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH] drm/radeon: rework to new fence interface
Am 19.08.2013 21:37, schrieb Maarten Lankhorst:
Op 19-08-13 14:35, Christian König schreef:
Am 19.08.2013 12:17, schrieb Maarten Lankhorst:
[SNIP]
@@ -190,25 +225,24 @@ void radeon_fence_process(struct radeon_device *rdev, int
ring)
}
} while (atomic64_xchg(&rdev->fence_drv[ring].last_seq, seq) > seq);
-if (wake) {
+if (wake)
rdev->fence_drv[ring].last_activity = jiffies;
-wake_up_all(&rdev->fence_queue);
-}
+return wake;
}
Very bad idea, when sequence numbers change, you always want to wake up the
whole fence queue here.
Yes, and the callers of this function call wake_up_all or wake_up_all_locked
themselves, based on the return value..
And as I said that's a very bad idea. The fence processing shouldn't be
called with any locks held and should be self responsible for activating
any waiters.
[SNIP]
+/**
+ * radeon_fence_enable_signaling - enable signalling on fence
+ * @fence: fence
+ *
+ * This function is called with fence_queue lock held, and adds a callback
+ * to fence_queue that checks if this fence is signaled, and if so it
+ * signals the fence and removes itself.
+ */
+static bool radeon_fence_enable_signaling(struct fence *f)
+{
+struct radeon_fence *fence = to_radeon_fence(f);
+
+if (atomic64_read(&fence->rdev->fence_drv[fence->ring].last_seq) >=
fence->seq ||
+!fence->rdev->ddev->irq_enabled)
+return false;
+
Do I get that right that you rely on IRQs to be enabled and working here? Cause
that would be a quite bad idea from the conceptual side.
For cross-device synchronization it would be nice to have working irqs, it
allows signalling fences faster,
and it allows for callbacks on completion to be called. For internal usage it's
no more required than it was before.
That's a big NAK.
The fence processing is actually very fine tuned to avoid IRQs and as
far as I can see you just leave them enabled by decrementing the atomic
from IRQ context. Additional to that we need allot of special handling
in case of a hardware lockup here, which isn't done if you abuse the
fence interface like this.
Also your approach of leaking the IRQ context outside of the driver is a
very bad idea from the conceptual side. Please don't modify the fence
interface at all and instead use the wait functions already exposed by
radeon_fence.c. If you need some kind of signaling mechanism then wait
inside a workqueue instead.
Christian.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/3] refactor some ldb related clocks
The ldb_di[0/1]_ipu_div clock dividers in the CSCMR2 register of i.MX53, i.MX6Q and i.MX6DL SoCs can be configured to a 1/3.5 drivider or a 1/7 divider. The common clock framework cannot deal with the two dividers directly even with the divider table which only supports integral dividers. So, the idea is to take the 1/3.5 and 1/7 dividers as separate fixed factor dividers and introduce a new multiplexer clock to be derived from the them. Then, the ldb display clock trees can be setup correctly. This series contains the necessary clock driver changes, dts code changes and imx-drm/ldb driver changes to fullfill the task. Liu Ying (3): ARM: imx6q: refactor some ldb related clocks ARM: dts: imx6q/imx6dl: add necessary clocks for ldb node staging: drm/imx: ldb: correct the ldb di clock trees .../devicetree/bindings/clock/imx6q-clock.txt |6 ++-- arch/arm/boot/dts/imx6dl.dtsi |8 +++-- arch/arm/boot/dts/imx6q.dtsi |8 +++-- arch/arm/mach-imx/clk-imx6q.c | 25 +++-- drivers/staging/imx-drm/imx-ldb.c | 38 +++- 5 files changed, 61 insertions(+), 24 deletions(-) -- 1.7.9.5 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/3] ARM: imx6q: refactor some ldb related clocks
The ldb_di[0/1]_ipu_div dividers may divide their parent clock
frequencies by either 3.5 or 7. The non-integral dividers cannot
be dealt with the common clock framework directly, so they cannot
be registered as common clock dividers. So this patch adds a fixed
factor clock of 1/7 and introduces ldb_di[0/1]_div_sel multiplexers
so that the fixed factor clocks of 1/3.5 and 1/7 can be set to be
the parents of ldb_di[0/1]_div_sel multiplexers. The ldb_di[0/1]_podf
dividers are no longer used then.
Signed-off-by: Liu Ying
---
.../devicetree/bindings/clock/imx6q-clock.txt |6 +++--
arch/arm/mach-imx/clk-imx6q.c | 25
2 files changed, 19 insertions(+), 12 deletions(-)
diff --git a/Documentation/devicetree/bindings/clock/imx6q-clock.txt
b/Documentation/devicetree/bindings/clock/imx6q-clock.txt
index 5a90a72..90e923e 100644
--- a/Documentation/devicetree/bindings/clock/imx6q-clock.txt
+++ b/Documentation/devicetree/bindings/clock/imx6q-clock.txt
@@ -89,8 +89,6 @@ clocks and IDs.
gpu3d_shader74
ipu1_podf 75
ipu2_podf 76
- ldb_di0_podf77
- ldb_di1_podf78
ipu1_di0_pre79
ipu1_di1_pre80
ipu2_di0_pre81
@@ -215,6 +213,10 @@ clocks and IDs.
cko2200
cko 201
vdoa202
+ ldb_di0_div_7 203
+ ldb_di1_div_7 204
+ ldb_di0_div_sel 205
+ ldb_di1_div_sel 206
Examples:
diff --git a/arch/arm/mach-imx/clk-imx6q.c b/arch/arm/mach-imx/clk-imx6q.c
index 9181a24..2b5be96 100644
--- a/arch/arm/mach-imx/clk-imx6q.c
+++ b/arch/arm/mach-imx/clk-imx6q.c
@@ -189,6 +189,8 @@ static const char *gpu3d_core_sels[]= {
"mmdc_ch0_axi", "pll3_usb_otg", "pll2_p
static const char *gpu3d_shader_sels[] = { "mmdc_ch0_axi", "pll3_usb_otg",
"pll2_pfd1_594m", "pll3_pfd0_720m", };
static const char *ipu_sels[] = { "mmdc_ch0_axi", "pll2_pfd2_396m",
"pll3_120m", "pll3_pfd1_540m", };
static const char *ldb_di_sels[] = { "pll5_video_div", "pll2_pfd0_352m",
"pll2_pfd2_396m", "mmdc_ch1_axi", "pll3_usb_otg", };
+static const char *ldb_di0_div_sels[] = { "ldb_di0_div_3_5", "ldb_di0_div_7",
};
+static const char *ldb_di1_div_sels[] = { "ldb_di1_div_3_5", "ldb_di1_div_7",
};
static const char *ipu_di_pre_sels[] = { "mmdc_ch0_axi", "pll3_usb_otg",
"pll5_video_div", "pll2_pfd0_352m", "pll2_pfd2_396m", "pll3_pfd1_540m", };
static const char *ipu1_di0_sels[] = { "ipu1_di0_pre", "dummy", "dummy",
"ldb_di0", "ldb_di1", };
static const char *ipu1_di1_sels[] = { "ipu1_di1_pre", "dummy", "dummy",
"ldb_di0", "ldb_di1", };
@@ -233,11 +235,11 @@ enum mx6q_clks {
periph_clk2, periph2_clk2, ipg, ipg_per, esai_pred, esai_podf,
asrc_pred, asrc_podf, spdif_pred, spdif_podf, can_root, ecspi_root,
gpu2d_core_podf, gpu3d_core_podf, gpu3d_shader, ipu1_podf, ipu2_podf,
- ldb_di0_podf, ldb_di1_podf, ipu1_di0_pre, ipu1_di1_pre, ipu2_di0_pre,
- ipu2_di1_pre, hsi_tx_podf, ssi1_pred, ssi1_podf, ssi2_pred, ssi2_podf,
- ssi3_pred, ssi3_podf, uart_serial_podf, usdhc1_podf, usdhc2_podf,
- usdhc3_podf, usdhc4_podf, enfc_pred, enfc_podf, emi_podf,
- emi_slow_podf, vpu_axi_podf, cko1_podf, axi, mmdc_ch0_axi_podf,
+ ldb_di0_podf_unused, ldb_di1_podf_unused, ipu1_di0_pre, ipu1_di1_pre,
+ ipu2_di0_pre, ipu2_di1_pre, hsi_tx_podf, ssi1_pred, ssi1_podf,
+ ssi2_pred, ssi2_podf, ssi3_pred, ssi3_podf, uart_serial_podf,
+ usdhc1_podf, usdhc2_podf, usdhc3_podf, usdhc4_podf, enfc_pred,
enfc_podf,
+ emi_podf, emi_slow_podf, vpu_axi_podf, cko1_podf, axi,
mmdc_ch0_axi_podf,
mmdc_ch1_axi_podf, arm, ahb, apbh_dma, asrc, can1_ipg, can1_serial,
can2_ipg, can2_serial, ecspi1, ecspi2, ecspi3, ecspi4, ecspi5, enet,
esai, gpt_ipg, gpt_ipg_per, gpu2d_core, gpu3d_core, hdmi_iahb,
@@ -251,7 +253,8 @@ enum mx6q_clks {
ssi2_ipg, ssi3_ipg, rom, usbphy1, usbphy2, ldb_di0_div_3_5,
ldb_di1_div_3_5,
sata_ref, sata_ref_100m, pcie_ref, pcie_ref_125m, enet_ref,
usbphy1_gate,
usbphy2_gate, pll4_post_div, pll5_post_div, pll5_video_div, eim_slow,
- spdif, cko2_sel, cko2_podf, cko2, cko, vdoa, clk_max
+ spdif, cko2_sel, cko2_podf, cko2, cko, vdoa, ldb_di0_div_7,
ldb_di1_div_7,
+ ldb_di0_div_sel, ldb_di1_div_sel, clk_max
};
static struct clk *clk[clk_max];
@@ -387,6 +390,8 @@ static void __init imx6q_clocks_init(struct device_node
*ccm_node)
clk[ipu2_sel] = imx_clk_mux("ipu2_sel", base + 0x3c,
14, 2, ipu_sels, ARRAY_SIZE(ipu_sels));
clk[ldb_di0_sel] = imx_clk_mux_flags("ldb_di0_sel", base + 0x2c,
9, 3, ldb_di_sels, ARRAY_SIZE(ldb_di_sels), CLK_SET_RATE_PARENT);
clk[ldb_di1_sel] = imx_clk_mux_flags("ldb_di1_sel", bas
[PATCH 3/3] staging: drm/imx: ldb: correct the ldb di clock trees
In ldb split mode, the ldb_di[0/1]_ipu_div dividers should
be configured as clock dividers of 1/3.5, while in others
ldb modes of 1/7. This patch gets the di[0/1]_div_3_5,
di[0/1]_div_7 and di[0/1]_div_sel clocks and sets the
di[0/1]_div_3_5 or di[0/1]_div_7 clocks to be the parents of
di[0/1]_div_sel clocks according to the ldb mode. The real
dividers are the two fixed factors bewteen the ldb_di[0/1] and
the pll clocks, so it's unnecessary to set the frequency for
the ldb_di[0/1] clocks again after pll clock frequency is set.
This patch removes the redundant clock frequency setting code
as well.
Signed-off-by: Liu Ying
---
drivers/staging/imx-drm/imx-ldb.c | 38 +
1 file changed, 30 insertions(+), 8 deletions(-)
diff --git a/drivers/staging/imx-drm/imx-ldb.c
b/drivers/staging/imx-drm/imx-ldb.c
index 8af7f3b..7c553b8 100644
--- a/drivers/staging/imx-drm/imx-ldb.c
+++ b/drivers/staging/imx-drm/imx-ldb.c
@@ -81,6 +81,9 @@ struct imx_ldb {
struct clk *clk[2]; /* our own clock */
struct clk *clk_sel[4]; /* parent of display clock */
struct clk *clk_pll[2]; /* upstream clock we can adjust */
+ struct clk *clk_div_3_5[2]; /* fixed factor of 1/3.5 */
+ struct clk *clk_div_7[2]; /* fixed factor of 1/7 */
+ struct clk *clk_div_sel[2]; /* 1/3.5 or 1/7 */
u32 ldb_ctrl;
const struct bus_mux *lvds_mux;
};
@@ -150,6 +153,18 @@ static void imx_ldb_set_clock(struct imx_ldb *ldb, int
mux, int chno,
{
int ret;
+ if (ldb->ldb_ctrl & LDB_SPLIT_MODE_EN) {
+ ret = clk_set_parent(ldb->clk_div_sel[chno],
ldb->clk_div_3_5[chno]);
+ if (ret)
+ dev_err(ldb->dev, "unable to set di%d_div_sel parent
clock "
+ "to di%d_div_3_5\n", chno, chno);
+ } else {
+ ret = clk_set_parent(ldb->clk_div_sel[chno],
ldb->clk_div_7[chno]);
+ if (ret)
+ dev_err(ldb->dev, "unable to set di%d_div_sel parent
clock "
+ "to di%d_div_7\n", chno, chno);
+ }
+
dev_dbg(ldb->dev, "%s: now: %ld want: %ld\n", __func__,
clk_get_rate(ldb->clk_pll[chno]), serial_clk);
clk_set_rate(ldb->clk_pll[chno], serial_clk);
@@ -157,14 +172,6 @@ static void imx_ldb_set_clock(struct imx_ldb *ldb, int
mux, int chno,
dev_dbg(ldb->dev, "%s after: %ld\n", __func__,
clk_get_rate(ldb->clk_pll[chno]));
- dev_dbg(ldb->dev, "%s: now: %ld want: %ld\n", __func__,
- clk_get_rate(ldb->clk[chno]),
- (long int)di_clk);
- clk_set_rate(ldb->clk[chno], di_clk);
-
- dev_dbg(ldb->dev, "%s after: %ld\n", __func__,
- clk_get_rate(ldb->clk[chno]));
-
/* set display clock mux to LDB input clock */
ret = clk_set_parent(ldb->clk_sel[mux], ldb->clk[chno]);
if (ret) {
@@ -362,6 +369,21 @@ static int imx_ldb_get_clk(struct imx_ldb *ldb, int chno)
if (IS_ERR(ldb->clk_pll[chno]))
return PTR_ERR(ldb->clk_pll[chno]);
+ sprintf(clkname, "di%d_div_3_5", chno);
+ ldb->clk_div_3_5[chno] = devm_clk_get(ldb->dev, clkname);
+ if (IS_ERR(ldb->clk_div_3_5[chno]))
+ return PTR_ERR(ldb->clk_div_3_5[chno]);
+
+ sprintf(clkname, "di%d_div_7", chno);
+ ldb->clk_div_7[chno] = devm_clk_get(ldb->dev, clkname);
+ if (IS_ERR(ldb->clk_div_7[chno]))
+ return PTR_ERR(ldb->clk_div_7[chno]);
+
+ sprintf(clkname, "di%d_div_sel", chno);
+ ldb->clk_div_sel[chno] = devm_clk_get(ldb->dev, clkname);
+ if (IS_ERR(ldb->clk_div_sel[chno]))
+ return PTR_ERR(ldb->clk_div_sel[chno]);
+
return 0;
}
--
1.7.9.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/3] ARM: dts: imx6q/imx6dl: add necessary clocks for ldb node
This patch adds di[0/1]_div_3_5, di[0/1]_div_7 and di[0/1]_div_sel
clocks to the ldb nodes so that the ldb driver may use them to
setup the display clock trees.
Signed-off-by: Liu Ying
---
arch/arm/boot/dts/imx6dl.dtsi |8 ++--
arch/arm/boot/dts/imx6q.dtsi |8 ++--
2 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/imx6dl.dtsi b/arch/arm/boot/dts/imx6dl.dtsi
index 9e8ae11..ff0d743 100644
--- a/arch/arm/boot/dts/imx6dl.dtsi
+++ b/arch/arm/boot/dts/imx6dl.dtsi
@@ -75,10 +75,14 @@
&ldb {
clocks = <&clks 33>, <&clks 34>,
<&clks 39>, <&clks 40>,
-<&clks 135>, <&clks 136>;
+<&clks 135>, <&clks 136>,
+<&clks 184>, <&clks 185>, <&clks 203>, <&clks 204>,
+<&clks 205>, <&clks 206>;
clock-names = "di0_pll", "di1_pll",
"di0_sel", "di1_sel",
- "di0", "di1";
+ "di0", "di1",
+ "di0_div_3_5", "di1_div_3_5", "di0_div_7", "di1_div_7",
+ "di0_div_sel", "di1_div_sel";
lvds-channel@0 {
crtcs = <&ipu1 0>, <&ipu1 1>;
diff --git a/arch/arm/boot/dts/imx6q.dtsi b/arch/arm/boot/dts/imx6q.dtsi
index f024ef2..b078a42 100644
--- a/arch/arm/boot/dts/imx6q.dtsi
+++ b/arch/arm/boot/dts/imx6q.dtsi
@@ -146,10 +146,14 @@
&ldb {
clocks = <&clks 33>, <&clks 34>,
<&clks 39>, <&clks 40>, <&clks 41>, <&clks 42>,
-<&clks 135>, <&clks 136>;
+<&clks 135>, <&clks 136>,
+<&clks 184>, <&clks 185>, <&clks 203>, <&clks 204>,
+<&clks 205>, <&clks 206>;
clock-names = "di0_pll", "di1_pll",
"di0_sel", "di1_sel", "di2_sel", "di3_sel",
- "di0", "di1";
+ "di0", "di1",
+ "di0_div_3_5", "di1_div_3_5", "di0_div_7", "di1_div_7",
+ "di0_div_sel", "di1_div_sel";
lvds-channel@0 {
crtcs = <&ipu1 0>, <&ipu1 1>, <&ipu2 0>, <&ipu2 1>;
--
1.7.9.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH] drm/radeon: rework to new fence interface
Op 20-08-13 10:37, Christian König schreef:
> Am 19.08.2013 21:37, schrieb Maarten Lankhorst:
>> Op 19-08-13 14:35, Christian König schreef:
>>> Am 19.08.2013 12:17, schrieb Maarten Lankhorst:
[SNIP]
@@ -190,25 +225,24 @@ void radeon_fence_process(struct radeon_device
*rdev, int ring)
}
} while (atomic64_xchg(&rdev->fence_drv[ring].last_seq, seq) > seq);
-if (wake) {
+if (wake)
rdev->fence_drv[ring].last_activity = jiffies;
-wake_up_all(&rdev->fence_queue);
-}
+return wake;
}
>>> Very bad idea, when sequence numbers change, you always want to wake up the
>>> whole fence queue here.
>> Yes, and the callers of this function call wake_up_all or wake_up_all_locked
>> themselves, based on the return value..
>
> And as I said that's a very bad idea. The fence processing shouldn't be
> called with any locks held and should be self responsible for activating any
> waiters.
The call point (enable_signaling) only needs to know whether its own counter
has passed or not. This prevents the race where the counter
has elapsed, but the irq was not yet enabled.
I don't really care if enable_signaling updates last_seq or not, it only needs
to check if it's own fence has been signaled after enabling sw_irqs.
>>
[SNIP]
+/**
+ * radeon_fence_enable_signaling - enable signalling on fence
+ * @fence: fence
+ *
+ * This function is called with fence_queue lock held, and adds a callback
+ * to fence_queue that checks if this fence is signaled, and if so it
+ * signals the fence and removes itself.
+ */
+static bool radeon_fence_enable_signaling(struct fence *f)
+{
+struct radeon_fence *fence = to_radeon_fence(f);
+
+if (atomic64_read(&fence->rdev->fence_drv[fence->ring].last_seq) >=
fence->seq ||
+!fence->rdev->ddev->irq_enabled)
+return false;
+
>>> Do I get that right that you rely on IRQs to be enabled and working here?
>>> Cause that would be a quite bad idea from the conceptual side.
>> For cross-device synchronization it would be nice to have working irqs, it
>> allows signalling fences faster,
>> and it allows for callbacks on completion to be called. For internal usage
>> it's no more required than it was before.
>
> That's a big NAK.
>
> The fence processing is actually very fine tuned to avoid IRQs and as far as
> I can see you just leave them enabled by decrementing the atomic from IRQ
> context. Additional to that we need allot of special handling in case of a
> hardware lockup here, which isn't done if you abuse the fence interface like
> this.
I think it's not needed to leave the irq enabled, it's a leftover from when I
was debugging the mac and no interrupt occurred at all.
> Also your approach of leaking the IRQ context outside of the driver is a very
> bad idea from the conceptual side. Please don't modify the fence interface at
> all and instead use the wait functions already exposed by radeon_fence.c. If
> you need some kind of signaling mechanism then wait inside a workqueue
> instead.
The fence takes up the role of a single shot workqueue here. Manually resetting
the counter and calling wake_up_all would end up waking all active fences,
there's no special handling needed inside radeon for this.
The fence api does provide a synchronous wait function, but this causes a stall
of whomever waits on it. When I was testing this with intel I used the fence
callback to poke a register in i915, this allowed it to not block until it hits
the wait op in the command stream, and even then only if the callback was not
called first.
It's documented that the callbacks can be called from any context and will be
called with irqs disabled, so nothing scary should be done. The kernel provides
enough debug mechanisms to find any violators.
PROVE_LOCKING and DEBUG_ATOMIC_SLEEP for example.
~Maarten
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] refactor some ldb related clocks
Am Dienstag, den 20.08.2013, 16:38 +0800 schrieb Liu Ying: > The ldb_di[0/1]_ipu_div clock dividers in the CSCMR2 register > of i.MX53, i.MX6Q and i.MX6DL SoCs can be configured to a 1/3.5 > drivider or a 1/7 divider. The common clock framework cannot > deal with the two dividers directly even with the divider table > which only supports integral dividers. So, the idea is to take > the 1/3.5 and 1/7 dividers as separate fixed factor dividers and > introduce a new multiplexer clock to be derived from the them. > Then, the ldb display clock trees can be setup correctly. > This series contains the necessary clock driver changes, dts code > changes and imx-drm/ldb driver changes to fullfill the task. I don't see how this improves the situation. Does this solve any real problem? While I admit to having introduced the combination of 1/3.5 fixed divider and configurable 1/1,1/2 divder clocks to describe this fractional divider for the reasons you state, I think the correct solution would be to improve the table divider to support fractional values and get rid of the virtual ldb_di_div_3_5 clocks, not introduce more virtual clocks. regards Philipp ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH] drm/radeon: rework to new fence interface
Am 20.08.2013 11:36, schrieb Maarten Lankhorst:
[SNIP]
[SNIP]
+/**
+ * radeon_fence_enable_signaling - enable signalling on fence
+ * @fence: fence
+ *
+ * This function is called with fence_queue lock held, and adds a callback
+ * to fence_queue that checks if this fence is signaled, and if so it
+ * signals the fence and removes itself.
+ */
+static bool radeon_fence_enable_signaling(struct fence *f)
+{
+struct radeon_fence *fence = to_radeon_fence(f);
+
+if (atomic64_read(&fence->rdev->fence_drv[fence->ring].last_seq) >=
fence->seq ||
+!fence->rdev->ddev->irq_enabled)
+return false;
+
Do I get that right that you rely on IRQs to be enabled and working here? Cause
that would be a quite bad idea from the conceptual side.
For cross-device synchronization it would be nice to have working irqs, it
allows signalling fences faster,
and it allows for callbacks on completion to be called. For internal usage it's
no more required than it was before.
That's a big NAK.
The fence processing is actually very fine tuned to avoid IRQs and as far as I
can see you just leave them enabled by decrementing the atomic from IRQ
context. Additional to that we need allot of special handling in case of a
hardware lockup here, which isn't done if you abuse the fence interface like
this.
I think it's not needed to leave the irq enabled, it's a leftover from when I
was debugging the mac and no interrupt occurred at all.
Also your approach of leaking the IRQ context outside of the driver is a very
bad idea from the conceptual side. Please don't modify the fence interface at
all and instead use the wait functions already exposed by radeon_fence.c. If
you need some kind of signaling mechanism then wait inside a workqueue instead.
The fence takes up the role of a single shot workqueue here. Manually resetting
the counter and calling wake_up_all would end up waking all active fences,
there's no special handling needed inside radeon for this.
Yeah that's actually the point here, you NEED to activate ALL fences,
otherwise the fence handling inside the driver won't work.
The fence api does provide a synchronous wait function, but this causes a stall
of whomever waits on it.
Which is perfectly fine. What actually is the use case of not stalling a
process who wants to wait for something?
When I was testing this with intel I used the fence callback to poke a register
in i915, this allowed it to not block until it hits the wait op in the command
stream, and even then only if the callback was not called first.
It's documented that the callbacks can be called from any context and will be
called with irqs disabled, so nothing scary should be done. The kernel provides
enough debug mechanisms to find any violators.
PROVE_LOCKING and DEBUG_ATOMIC_SLEEP for example.
No thanks, we even abandoned that concept internal in the driver. Please
use the blocking wait functions instead.
Christian.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] refactor some ldb related clocks
On 08/20/2013 05:43 PM, Philipp Zabel wrote: > Am Dienstag, den 20.08.2013, 16:38 +0800 schrieb Liu Ying: >> The ldb_di[0/1]_ipu_div clock dividers in the CSCMR2 register >> of i.MX53, i.MX6Q and i.MX6DL SoCs can be configured to a 1/3.5 >> drivider or a 1/7 divider. The common clock framework cannot >> deal with the two dividers directly even with the divider table >> which only supports integral dividers. So, the idea is to take >> the 1/3.5 and 1/7 dividers as separate fixed factor dividers and >> introduce a new multiplexer clock to be derived from the them. >> Then, the ldb display clock trees can be setup correctly. >> This series contains the necessary clock driver changes, dts code >> changes and imx-drm/ldb driver changes to fullfill the task. > > I don't see how this improves the situation. Does this solve any real > problem? > I don't see any functional problem without this series. But, it may correct ldb_di[n] clock frequency returned from clk_get_rate() when using 1/7 divider. Furthermore, since this series makes the ldb related clocks from pll to ldb_di[0/1] have the CLK_SET_RATE_PARENT flag set, the imx-drm/ldb driver may set the clocks' frequency more flexibly, i.e., only calling clk_set_rate() for ldb_di[n] clock would be an alternative. > While I admit to having introduced the combination of 1/3.5 fixed > divider and configurable 1/1,1/2 divder clocks to describe this > fractional divider for the reasons you state, I think the correct > solution would be to improve the table divider to support fractional > values and get rid of the virtual ldb_di_div_3_5 clocks, not > introduce more virtual clocks. Yes, it's good to support fractional values for the table divider(not sure if there is any plan for this). I see there is something similar in 'include/linux/sh_clk.h'. > > regards > Philipp > > Regards, Liu Ying ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: add MIPI DSI encoder and connector types
From: Shobhit Kumar
Signed-off-by: Shobhit Kumar
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_crtc.c |2 ++
include/uapi/drm/drm_mode.h |2 ++
2 files changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index a691764..dc279f4 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -209,6 +209,7 @@ static struct drm_conn_prop_enum_list
drm_connector_enum_list[] =
{ DRM_MODE_CONNECTOR_TV, "TV" },
{ DRM_MODE_CONNECTOR_eDP, "eDP" },
{ DRM_MODE_CONNECTOR_VIRTUAL, "Virtual" },
+ { DRM_MODE_CONNECTOR_DSI, "DSI" },
};
static const struct drm_prop_enum_list drm_encoder_enum_list[] =
@@ -218,6 +219,7 @@ static const struct drm_prop_enum_list
drm_encoder_enum_list[] =
{ DRM_MODE_ENCODER_LVDS, "LVDS" },
{ DRM_MODE_ENCODER_TVDAC, "TV" },
{ DRM_MODE_ENCODER_VIRTUAL, "Virtual" },
+ { DRM_MODE_ENCODER_DSI, "DSI" },
};
void drm_connector_ida_init(void)
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index 53db7ce..589114e 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -165,6 +165,7 @@ struct drm_mode_get_plane_res {
#define DRM_MODE_ENCODER_LVDS 3
#define DRM_MODE_ENCODER_TVDAC 4
#define DRM_MODE_ENCODER_VIRTUAL 5
+#define DRM_MODE_ENCODER_DSI 6
struct drm_mode_get_encoder {
__u32 encoder_id;
@@ -203,6 +204,7 @@ struct drm_mode_get_encoder {
#define DRM_MODE_CONNECTOR_TV 13
#define DRM_MODE_CONNECTOR_eDP 14
#define DRM_MODE_CONNECTOR_VIRTUAL 15
+#define DRM_MODE_CONNECTOR_DSI 16
struct drm_mode_get_connector {
--
1.7.9.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/i915: add fast boot support for Haswell
On Tue, Aug 20, 2013 at 3:33 AM, Furquan Shaikh wrote:
> Enables getting correct mode clock when reading pipe config
> This patch has been tested successfully on top of drm-intel-nightly tree
>
> Signed-off-by: Furquan Shaikh
This is missing a hunk to enable the pipe_config consistency checks:
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 7a40427..e8b73ac 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -8416,13 +8416,11 @@ intel_pipe_config_compare(struct drm_device *dev,
#undef PIPE_CONF_CHECK_FLAGS
#undef PIPE_CONF_QUIRK
- if (!IS_HASWELL(dev)) {
- if (!intel_fuzzy_clock_check(current_config, pipe_config)) {
- DRM_ERROR("mismatch in clock (expected %d, found %d)\n",
- current_config->adjusted_mode.clock,
- pipe_config->adjusted_mode.clock);
- return false;
- }
+ if (!intel_fuzzy_clock_check(current_config, pipe_config)) {
+ DRM_ERROR("mismatch in clock (expected %d, found %d)\n",
+ current_config->adjusted_mode.clock,
+ pipe_config->adjusted_mode.clock);
+ return false;
}
return true;
Cheers, Daniel
> ---
> drivers/gpu/drm/i915/i915_reg.h | 6
> drivers/gpu/drm/i915/intel_ddi.c | 70
>
> drivers/gpu/drm/i915/intel_display.c | 1 +
> 3 files changed, 77 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 2b96d6b..9511129 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -4970,6 +4970,7 @@
> #define SPLL_PLL_NON_SSC (2<<28)
> #define SPLL_PLL_FREQ_810MHz (0<<26)
> #define SPLL_PLL_FREQ_1350MHz (1<<26)
> +#define SPLL_PLL_FREQ_MASK (3<<26)
>
> /* WRPLL */
> #define WRPLL_CTL1 0x46040
> @@ -4983,6 +4984,10 @@
> #define WRPLL_DIVIDER_POST(x) ((x)<<8)
> #define WRPLL_DIVIDER_FEEDBACK(x) ((x)<<16)
>
> +#define WRPLL_DIVIDER_REFERENCE_BITS(reg)(reg & 0xff)
> +#define WRPLL_DIVIDER_POST_BITS(reg) ((reg >> 8) & 0x3f)
> +#define WRPLL_DIVIDER_FEEDBACK_BITS(reg) ((reg >> 16) & 0xff)
> +
> /* Port clock selection */
> #define PORT_CLK_SEL_A 0x46100
> #define PORT_CLK_SEL_B 0x46104
> @@ -4994,6 +4999,7 @@
> #define PORT_CLK_SEL_WRPLL1 (4<<29)
> #define PORT_CLK_SEL_WRPLL2 (5<<29)
> #define PORT_CLK_SEL_NONE (7<<29)
> +#define PORT_CLK_SEL_MASK (7<<29)
>
> /* Transcoder clock selection */
> #define TRANS_CLK_SEL_A0x46140
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> b/drivers/gpu/drm/i915/intel_ddi.c
> index b8c096b..a24a375 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -1246,6 +1246,74 @@ static void intel_ddi_hot_plug(struct intel_encoder
> *intel_encoder)
> intel_dp_check_link_status(intel_dp);
> }
>
> +static void intel_ddi_get_clock(struct intel_encoder *encoder,
> + struct intel_crtc_config *pipe_config)
> +{
> + struct drm_i915_private *dev_priv = encoder->base.dev->dev_private;
> + int port = intel_ddi_get_encoder_port(encoder);
> + u32 temp = I915_READ(PORT_CLK_SEL(port)) & PORT_CLK_SEL_MASK;
> + u8 link_bw;
> +
> + if ((temp == PORT_CLK_SEL_LCPLL_810) ||
> + (temp == PORT_CLK_SEL_LCPLL_1350) ||
> + (temp == PORT_CLK_SEL_LCPLL_2700)) {
> +
> + switch (temp) {
> + case PORT_CLK_SEL_LCPLL_810:
> + link_bw = DP_LINK_BW_1_62;
> + break;
> + case PORT_CLK_SEL_LCPLL_1350:
> + link_bw = DP_LINK_BW_2_7;
> + break;
> + case PORT_CLK_SEL_LCPLL_2700:
> + link_bw = DP_LINK_BW_5_4;
> + break;
> + }
> + pipe_config->port_clock =
> drm_dp_bw_code_to_link_rate(link_bw);
> + } else if ((temp == PORT_CLK_SEL_WRPLL1) ||
> + (temp == PORT_CLK_SEL_WRPLL2)) {
> + uint64_t p, n2, r2;
> + u32 val, reg;
> + uint64_t freq2k;
> +
> + switch (temp) {
> + case PORT_CLK_SEL_WRPLL1:
> + reg = WRPLL_CTL1;
> + break;
> + case PORT_CLK_SEL_WRPLL2:
> + reg = WRPLL_CTL2;
> + break;
> + }
> + val = I915_READ(reg);
> + r2 = WRPLL_DIVIDER_REFERENCE_BITS(val);
> + p = WRPLL_DIVIDER_POST_BITS(val);
> + n2 = WRPLL_DIVIDER_FEEDBACK
[Bug 60231] DisplayPort monitor not detected on PowerColor Radeon HD 4850
https://bugzilla.kernel.org/show_bug.cgi?id=60231 Alex Deucher changed: What|Removed |Added CC||alexdeuc...@gmail.com --- Comment #1 from Alex Deucher --- Possibly related to bug 60639. Can you try the patch on that bug? -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH] drm/radeon: rework to new fence interface
Op 20-08-13 11:51, Christian König schreef:
> Am 20.08.2013 11:36, schrieb Maarten Lankhorst:
> [SNIP]
>
>> [SNIP]
>> +/**
>> + * radeon_fence_enable_signaling - enable signalling on fence
>> + * @fence: fence
>> + *
>> + * This function is called with fence_queue lock held, and adds a
>> callback
>> + * to fence_queue that checks if this fence is signaled, and if so it
>> + * signals the fence and removes itself.
>> + */
>> +static bool radeon_fence_enable_signaling(struct fence *f)
>> +{
>> +struct radeon_fence *fence = to_radeon_fence(f);
>> +
>> +if (atomic64_read(&fence->rdev->fence_drv[fence->ring].last_seq) >=
>> fence->seq ||
>> +!fence->rdev->ddev->irq_enabled)
>> +return false;
>> +
> Do I get that right that you rely on IRQs to be enabled and working here?
> Cause that would be a quite bad idea from the conceptual side.
For cross-device synchronization it would be nice to have working irqs, it
allows signalling fences faster,
and it allows for callbacks on completion to be called. For internal usage
it's no more required than it was before.
>>> That's a big NAK.
>>>
>>> The fence processing is actually very fine tuned to avoid IRQs and as far
>>> as I can see you just leave them enabled by decrementing the atomic from
>>> IRQ context. Additional to that we need allot of special handling in case
>>> of a hardware lockup here, which isn't done if you abuse the fence
>>> interface like this.
>> I think it's not needed to leave the irq enabled, it's a leftover from when
>> I was debugging the mac and no interrupt occurred at all.
>>
>>> Also your approach of leaking the IRQ context outside of the driver is a
>>> very bad idea from the conceptual side. Please don't modify the fence
>>> interface at all and instead use the wait functions already exposed by
>>> radeon_fence.c. If you need some kind of signaling mechanism then wait
>>> inside a workqueue instead.
>> The fence takes up the role of a single shot workqueue here. Manually
>> resetting the counter and calling wake_up_all would end up waking all active
>> fences, there's no special handling needed inside radeon for this.
>
> Yeah that's actually the point here, you NEED to activate ALL fences,
> otherwise the fence handling inside the driver won't work.
It's done in a lazy fashion. If there's no need for an activated fence the
interrupt will not be enabled.
>> The fence api does provide a synchronous wait function, but this causes a
>> stall of whomever waits on it.
>
> Which is perfectly fine. What actually is the use case of not stalling a
> process who wants to wait for something?
Does radeon call ttm_bo_wait on all bo's before doing a command submission? No?
Why should other drivers do that..
>> When I was testing this with intel I used the fence callback to poke a
>> register in i915, this allowed it to not block until it hits the wait op in
>> the command stream, and even then only if the callback was not called first.
>>
>> It's documented that the callbacks can be called from any context and will
>> be called with irqs disabled, so nothing scary should be done. The kernel
>> provides enough debug mechanisms to find any violators.
>> PROVE_LOCKING and DEBUG_ATOMIC_SLEEP for example.
>
> No thanks, we even abandoned that concept internal in the driver. Please use
> the blocking wait functions instead.
No, this just stalls all gpu's that share a bo.
The idea is to provide a standardized api so bo's can be synchronized without
stalling. The first step to this is ww_mutex.
If this lock is shared between multiple gpu's the same object can be reserved
between multiple devices without causing
a deadlock with circular dependencies. With some small patches it's possible to
do this already between multiple drivers
that use ttm. ttm_bo_reserve, ttm_bo_unreserve and all the other code dealing
with ttm reservations have been converted
to use ww_mutex locking.
Fencing is the next step. When all buffers are locked a callback should be
added to any previous fence, and a single new fence
signaling completion of the command submission should be placed on all locked
objects. Because the common path is that no
objects are shared, the callback and FIFO stalling will only be needed for
dma-bufs. When all callbacks have fired the FIFO can be
unblocked. This prevents having to sync the gpu to the cpu. If a bo is
submitted to 1 gpu, and then immediately to another it will not
stall unless needed. For example in a optimus configuration an application
could copy a rendered frame from VRAM to a shared
dma-buf (xorg's buffer), then have Xorg copying it again (on intel's gpu) from
the dma-buf to a framebuffer .
~Maarten
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60674] linux 3.10.x RV740 (Radeon HD 4770) display problem
https://bugzilla.kernel.org/show_bug.cgi?id=60674 --- Comment #15 from Alex Deucher --- (In reply to Dave from comment #14) > (In reply to Michel Dänzer from comment #13) > > Michel you could well be 100% right. While the symptoms may be similar, your issue is completely different, and not kernel related. Please open a new bug on https://bugs.freedesktop.org (for the ddx: product xorg, component Driver/Radeon). -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: A gentle scrub
On Mon, Aug 19, 2013 at 7:53 PM, Damien Lespiau wrote: > A small pass on drm headers to remove some stale prototypes/functions/defines > and to make static a few functions. For the series: Reviewed-by: Alex Deucher > > drivers/gpu/drm/drm_crtc.c | 38 > +++-- > drivers/gpu/drm/drm_fb_cma_helper.c | 5 ++--- > drivers/gpu/drm/drm_modes.c | 21 > drivers/gpu/drm/drm_platform.c | 7 +++ > include/drm/drmP.h | 8 > include/drm/drm_crtc.h | 17 - > include/drm/drm_fb_cma_helper.h | 1 - > include/drm/drm_pciids.h| 30 - > 8 files changed, 8 insertions(+), 119 deletions(-) > > -- > Damien > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH] drm/radeon: rework to new fence interface
Am 20.08.2013 15:21, schrieb Maarten Lankhorst:
Op 20-08-13 11:51, Christian König schreef:
Am 20.08.2013 11:36, schrieb Maarten Lankhorst:
[SNIP]
[SNIP]
+/**
+ * radeon_fence_enable_signaling - enable signalling on fence
+ * @fence: fence
+ *
+ * This function is called with fence_queue lock held, and adds a callback
+ * to fence_queue that checks if this fence is signaled, and if so it
+ * signals the fence and removes itself.
+ */
+static bool radeon_fence_enable_signaling(struct fence *f)
+{
+struct radeon_fence *fence = to_radeon_fence(f);
+
+if (atomic64_read(&fence->rdev->fence_drv[fence->ring].last_seq) >=
fence->seq ||
+!fence->rdev->ddev->irq_enabled)
+return false;
+
Do I get that right that you rely on IRQs to be enabled and working here? Cause
that would be a quite bad idea from the conceptual side.
For cross-device synchronization it would be nice to have working irqs, it
allows signalling fences faster,
and it allows for callbacks on completion to be called. For internal usage it's
no more required than it was before.
That's a big NAK.
The fence processing is actually very fine tuned to avoid IRQs and as far as I
can see you just leave them enabled by decrementing the atomic from IRQ
context. Additional to that we need allot of special handling in case of a
hardware lockup here, which isn't done if you abuse the fence interface like
this.
I think it's not needed to leave the irq enabled, it's a leftover from when I
was debugging the mac and no interrupt occurred at all.
Also your approach of leaking the IRQ context outside of the driver is a very
bad idea from the conceptual side. Please don't modify the fence interface at
all and instead use the wait functions already exposed by radeon_fence.c. If
you need some kind of signaling mechanism then wait inside a workqueue instead.
The fence takes up the role of a single shot workqueue here. Manually resetting
the counter and calling wake_up_all would end up waking all active fences,
there's no special handling needed inside radeon for this.
Yeah that's actually the point here, you NEED to activate ALL fences, otherwise
the fence handling inside the driver won't work.
It's done in a lazy fashion. If there's no need for an activated fence the
interrupt will not be enabled.
The fence api does provide a synchronous wait function, but this causes a stall
of whomever waits on it.
Which is perfectly fine. What actually is the use case of not stalling a
process who wants to wait for something?
Does radeon call ttm_bo_wait on all bo's before doing a command submission? No?
Why should other drivers do that..
Sure it does if hardware synchronization isn't supported.
When I was testing this with intel I used the fence callback to poke a register
in i915, this allowed it to not block until it hits the wait op in the command
stream, and even then only if the callback was not called first.
It's documented that the callbacks can be called from any context and will be
called with irqs disabled, so nothing scary should be done. The kernel provides
enough debug mechanisms to find any violators.
PROVE_LOCKING and DEBUG_ATOMIC_SLEEP for example.
No thanks, we even abandoned that concept internal in the driver. Please use
the blocking wait functions instead.
No, this just stalls all gpu's that share a bo.
The idea is to provide a standardized api so bo's can be synchronized without
stalling. The first step to this is ww_mutex.
If this lock is shared between multiple gpu's the same object can be reserved
between multiple devices without causing
a deadlock with circular dependencies. With some small patches it's possible to
do this already between multiple drivers
that use ttm. ttm_bo_reserve, ttm_bo_unreserve and all the other code dealing
with ttm reservations have been converted
to use ww_mutex locking.
Fencing is the next step. When all buffers are locked a callback should be
added to any previous fence, and a single new fence
signaling completion of the command submission should be placed on all locked
objects. Because the common path is that no
objects are shared, the callback and FIFO stalling will only be needed for
dma-bufs. When all callbacks have fired the FIFO can be
unblocked. This prevents having to sync the gpu to the cpu. If a bo is
submitted to 1 gpu, and then immediately to another it will not
stall unless needed. For example in a optimus configuration an application
could copy a rendered frame from VRAM to a shared
dma-buf (xorg's buffer), then have Xorg copying it again (on intel's gpu) from
the dma-buf to a framebuffer .
Yeah, that's the same concept we used to have for multiple rings, to
avoid stalling if a buffer is currently used in a different part of the
GPU than the current command submission wants it to. After allot of
internal discussion we came to the conclusion that it just doesn't worth
the effort.
Have you thought over all the consequences that
[Bug 60523] Radeon DPM not working with 2 monitors attached to Radeon HD5770 (Juniper)
https://bugzilla.kernel.org/show_bug.cgi?id=60523 --- Comment #37 from Alex Deucher --- I was finally able to reproduce this, but only with gcc 4.8. Older versions of gcc work fine. Looks like the gcc bug has struck again. See: https://bugs.freedesktop.org/show_bug.cgi?id=66932 Now to find what other part gcc doesn't like... -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 8/8] drm: Make drm_get_platform_dev() static
On 08/19/2013 04:53 PM, Damien Lespiau wrote:
It's only used in drm_platform.c.
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/drm_platform.c | 7 +++
include/drm/drmP.h | 3 ---
2 files changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/drm_platform.c b/drivers/gpu/drm/drm_platform.c
index b8a282e..400024b 100644
--- a/drivers/gpu/drm/drm_platform.c
+++ b/drivers/gpu/drm/drm_platform.c
@@ -28,7 +28,7 @@
#include
#include
-/**
+/*
* Register.
*
* \param platdev - Platform device struture
Was this change intentional? The rest of the comment is doxygen still.
@@ -39,8 +39,8 @@
* Try and register, if we fail to register, backout previous work.
*/
-int drm_get_platform_dev(struct platform_device *platdev,
-struct drm_driver *driver)
+static int drm_get_platform_dev(struct platform_device *platdev,
+ struct drm_driver *driver)
{
struct drm_device *dev;
int ret;
@@ -107,7 +107,6 @@ err_g1:
mutex_unlock(&drm_global_mutex);
return ret;
}
-EXPORT_SYMBOL(drm_get_platform_dev);
static int drm_platform_get_irq(struct drm_device *dev)
{
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 046a7db..1a7a78f 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -1657,9 +1657,6 @@ extern int drm_pcie_get_speed_cap_mask(struct drm_device
*dev, u32 *speed_mask);
extern int drm_platform_init(struct drm_driver *driver, struct
platform_device *platform_device);
extern void drm_platform_exit(struct drm_driver *driver, struct
platform_device *platform_device);
-extern int drm_get_platform_dev(struct platform_device *pdev,
- struct drm_driver *driver);
-
/* returns true if currently okay to sleep */
static __inline__ bool drm_can_sleep(void)
{
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] ARM: imx6q: refactor some ldb related clocks
On Tue, Aug 20, 2013 at 5:38 AM, Liu Ying wrote: > diff --git a/Documentation/devicetree/bindings/clock/imx6q-clock.txt > b/Documentation/devicetree/bindings/clock/imx6q-clock.txt > index 5a90a72..90e923e 100644 > --- a/Documentation/devicetree/bindings/clock/imx6q-clock.txt > +++ b/Documentation/devicetree/bindings/clock/imx6q-clock.txt > @@ -89,8 +89,6 @@ clocks and IDs. > gpu3d_shader74 > ipu1_podf 75 > ipu2_podf 76 > - ldb_di0_podf77 > - ldb_di1_podf78 > ipu1_di0_pre79 > ipu1_di1_pre80 > ipu2_di0_pre81 This causes a 'hole' in the clock numbering scheme: 74, 75, 76, 79, 80, etc ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60523] Radeon DPM not working with 2 monitors attached to Radeon HD5770 (Juniper)
https://bugzilla.kernel.org/show_bug.cgi?id=60523 --- Comment #38 from Tobias Droste --- I don't want to say that it's not a gcc bug, but I'm using gcc 4.7: gcc version 4.7.2 20130108 [gcc-4_7-branch revision 195012] (SUSE Linux) -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 8/8] drm: Make drm_get_platform_dev() static
On Tue, Aug 20, 2013 at 07:56:42AM -0700, Ian Romanick wrote:
> On 08/19/2013 04:53 PM, Damien Lespiau wrote:
> >It's only used in drm_platform.c.
> >
> >Signed-off-by: Damien Lespiau
> >---
> > drivers/gpu/drm/drm_platform.c | 7 +++
> > include/drm/drmP.h | 3 ---
> > 2 files changed, 3 insertions(+), 7 deletions(-)
> >
> >diff --git a/drivers/gpu/drm/drm_platform.c b/drivers/gpu/drm/drm_platform.c
> >index b8a282e..400024b 100644
> >--- a/drivers/gpu/drm/drm_platform.c
> >+++ b/drivers/gpu/drm/drm_platform.c
> >@@ -28,7 +28,7 @@
> > #include
> > #include
> >
> >-/**
> >+/*
> > * Register.
> > *
> > * \param platdev - Platform device struture
>
> Was this change intentional? The rest of the comment is doxygen still.
It was indeed, just to stop documentation tools from picking up that
symbol that is not exported anymore. The documentation blob still
contains markup to tag the parameters though, might as well leave it
there.
--
Damien
>
> >@@ -39,8 +39,8 @@
> > * Try and register, if we fail to register, backout previous work.
> > */
> >
> >-int drm_get_platform_dev(struct platform_device *platdev,
> >- struct drm_driver *driver)
> >+static int drm_get_platform_dev(struct platform_device *platdev,
> >+struct drm_driver *driver)
> > {
> > struct drm_device *dev;
> > int ret;
> >@@ -107,7 +107,6 @@ err_g1:
> > mutex_unlock(&drm_global_mutex);
> > return ret;
> > }
> >-EXPORT_SYMBOL(drm_get_platform_dev);
> >
> > static int drm_platform_get_irq(struct drm_device *dev)
> > {
> >diff --git a/include/drm/drmP.h b/include/drm/drmP.h
> >index 046a7db..1a7a78f 100644
> >--- a/include/drm/drmP.h
> >+++ b/include/drm/drmP.h
> >@@ -1657,9 +1657,6 @@ extern int drm_pcie_get_speed_cap_mask(struct
> >drm_device *dev, u32 *speed_mask);
> > extern int drm_platform_init(struct drm_driver *driver, struct
> > platform_device *platform_device);
> > extern void drm_platform_exit(struct drm_driver *driver, struct
> > platform_device *platform_device);
> >
> >-extern int drm_get_platform_dev(struct platform_device *pdev,
> >-struct drm_driver *driver);
> >-
> > /* returns true if currently okay to sleep */
> > static __inline__ bool drm_can_sleep(void)
> > {
> >
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 67994] Lockup with UVD and DPM on RV730
https://bugs.freedesktop.org/show_bug.cgi?id=67994 --- Comment #7 from Timothée Ravier --- Created attachment 84347 --> https://bugs.freedesktop.org/attachment.cgi?id=84347&action=edit dmesg log -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 67994] Lockup with UVD and DPM on RV730
https://bugs.freedesktop.org/show_bug.cgi?id=67994 --- Comment #8 from Timothée Ravier --- Look alike bug here: screen goes black and freeze for a while when playing the second video using VDPAU with mplayer. Upon "screen return", the whole display is corrupted and unusable, requiring reboot. Arch Linux testing packages except for the kernel which is custom build. Card: Radeon Mobility 4650 HD Linux kernel: 3.11rc6 (commit: b36f4be, it's called -dirty in the dmesg log but I don't know why, will try to figure that out) Mesa: 9.2.0rc1 OpenGL vendor string: X.Org OpenGL renderer string: Gallium 0.4 on AMD RV730 OpenGL core profile version string: 3.1 (Core Profile) Mesa 9.2.0-rc1 OpenGL core profile shading language version string: 1.40 OpenGL core profile context flags: (none) OpenGL core profile extensions: OpenGL version string: 3.0 Mesa 9.2.0-rc1 OpenGL shading language version string: 1.30 -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60523] Radeon DPM not working with 2 monitors attached to Radeon HD5770 (Juniper)
https://bugzilla.kernel.org/show_bug.cgi?id=60523 --- Comment #39 from Alex Deucher --- Created attachment 107254 --> https://bugzilla.kernel.org/attachment.cgi?id=107254&action=edit fix for 3.11 The attached patch seems to fix it for me. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 67994] Lockup with UVD and DPM on RV730
https://bugs.freedesktop.org/show_bug.cgi?id=67994 --- Comment #9 from Alex Deucher --- You might try this patch: http://people.freedesktop.org/~agd5f/0001-drm-radeon-atombios-fix-variable-sized-arrays-for.patch -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/radeon/atombios: fix variable sized arrays for
Newer versions of gcc seem to wander off into no-man's land
when using variably sized arrays. Atombios tends to do things
like:
struct object {
u8 version;
u8 num_elements;
u32 elements[1]; /* num_elements entries */
};
We then do things like the following in the driver code:
for (i = 0; i < atom_object->num_elements; i++) {
driver_object[i] = atom_object->elements[i];
}
With previous versions of gcc this used to work fine, but with
4.8, it seems to generate code that wanders off into the weeds.
I'm not sure if array[1] is valid or not for variably sized
arrays in the C standard. switching to array[0] seems to avoid
the problem.
Signed-off-by: Alex Deucher
Cc: sta...@vger.kernel.org
---
This patch is against 3.11. I have a different version in my drm-next-3.12-wip
tree for 3.12 due to changes in atombios.h
drivers/gpu/drm/radeon/atombios.h | 100 +++---
1 file changed, 50 insertions(+), 50 deletions(-)
diff --git a/drivers/gpu/drm/radeon/atombios.h
b/drivers/gpu/drm/radeon/atombios.h
index 16b120c..3f1f011 100644
--- a/drivers/gpu/drm/radeon/atombios.h
+++ b/drivers/gpu/drm/radeon/atombios.h
@@ -3592,7 +3592,7 @@ typedef struct _ATOM_FAKE_EDID_PATCH_RECORD
{
UCHAR ucRecordType;
UCHAR ucFakeEDIDLength;
- UCHAR ucFakeEDIDString[1];// This actually has ucFakeEdidLength elements.
+ UCHAR ucFakeEDIDString[0];// This actually has ucFakeEdidLength elements.
} ATOM_FAKE_EDID_PATCH_RECORD;
typedef struct _ATOM_PANEL_RESOLUTION_PATCH_RECORD
@@ -3868,7 +3868,7 @@ typedef struct _ATOM_GPIO_PIN_ASSIGNMENT
typedef struct _ATOM_GPIO_PIN_LUT
{
ATOM_COMMON_TABLE_HEADER sHeader;
- ATOM_GPIO_PIN_ASSIGNMENT asGPIO_Pin[1];
+ ATOM_GPIO_PIN_ASSIGNMENT asGPIO_Pin[0];
}ATOM_GPIO_PIN_LUT;
//
@@ -3995,7 +3995,7 @@ typedef struct _ATOM_DISPLAY_OBJECT_PATH
USHORTusSize;//the size of
ATOM_DISPLAY_OBJECT_PATH
USHORTusConnObjectId;//Connector Object
ID
USHORTusGPUObjectId; //GPU ID
- USHORTusGraphicObjIds[1]; //1st Encoder Obj
source from GPU to last Graphic Obj destinate to connector.
+ USHORTusGraphicObjIds[0]; //1st Encoder Obj
source from GPU to last Graphic Obj destinate to connector.
}ATOM_DISPLAY_OBJECT_PATH;
typedef struct _ATOM_DISPLAY_EXTERNAL_OBJECT_PATH
@@ -4012,7 +4012,7 @@ typedef struct _ATOM_DISPLAY_OBJECT_PATH_TABLE
UCHAR ucNumOfDispPath;
UCHAR ucVersion;
UCHAR ucPadding[2];
- ATOM_DISPLAY_OBJECT_PATHasDispPath[1];
+ ATOM_DISPLAY_OBJECT_PATHasDispPath[0];
}ATOM_DISPLAY_OBJECT_PATH_TABLE;
@@ -4028,15 +4028,15 @@ typedef struct _ATOM_OBJECT_TABLE
//Above 4 object table
{
UCHAR ucNumberOfObjects;
UCHAR ucPadding[3];
- ATOM_OBJECT asObjects[1];
+ ATOM_OBJECT asObjects[0];
}ATOM_OBJECT_TABLE;
typedef struct _ATOM_SRC_DST_TABLE_FOR_ONE_OBJECT
//usSrcDstTableOffset pointing to this structure
{
UCHAR ucNumberOfSrc;
- USHORT usSrcObjectID[1];
+ USHORT usSrcObjectID[0];
UCHAR ucNumberOfDst;
- USHORT usDstObjectID[1];
+ USHORT usDstObjectID[0];
}ATOM_SRC_DST_TABLE_FOR_ONE_OBJECT;
@@ -4208,7 +4208,7 @@ typedef struct _ATOM_CONNECTOR_DEVICE_TAG_RECORD
ATOM_COMMON_RECORD_HEADER sheader;
UCHAR ucNumberOfDevice;
UCHAR ucReserved;
- ATOM_CONNECTOR_DEVICE_TAG asDeviceTag[1]; //This Id is same as
"ATOM_DEVICE_XXX_SUPPORT", 1 is only for allocation
+ ATOM_CONNECTOR_DEVICE_TAG asDeviceTag[0]; //This Id is same as
"ATOM_DEVICE_XXX_SUPPORT", 1 is only for allocation
}ATOM_CONNECTOR_DEVICE_TAG_RECORD;
@@ -4268,7 +4268,7 @@ typedef struct _ATOM_OBJECT_GPIO_CNTL_RECORD
ATOM_COMMON_RECORD_HEADER sheader;
UCHAR ucFlags;// Future expnadibility
UCHAR ucNumberOfPins; // Number of GPIO pins
used to control the object
- ATOM_GPIO_PIN_CONTROL_PAIR asGpio[1]; // the real gpio pin
pair determined by number of pins ucNumberOfPins
+ ATOM_GPIO_PIN_CONTROL_PAIR asGpio[0]; // the real gpio pin
pair determined by number of pins ucNumberOfPins
}ATOM_OBJECT_GPIO_CNTL_RECORD;
//Definitions for GPIO pin state
@@ -4549,7 +4549,7 @@ typedef struct _ATOM_I2C_VOLTAGE_OBJECT_V3
UCHARucVoltageControlAddress;
UCHARucVoltageControlOffset;
ULONGulReserved;
- VOLTAGE_LUT_ENTRY asVolI2cLut[1];// end with 0xff
+ VOLTAGE_LUT_ENTRY asVolI2cLut[0];// end wi
[PATCH] drm/radeon/atombios: fix variable sized arrays for newer gccs (v2)
Newer versions of gcc seem to wander off into no-man's land
when using variably sized arrays. Atombios tends to do things
like:
struct object {
u8 version;
u8 num_elements;
u32 elements[1]; /* num_elements entries */
};
We then do things like the following in the driver code:
for (i = 0; i < atom_object->num_elements; i++) {
driver_object[i] = atom_object->elements[i];
}
With previous versions of gcc this used to work fine, but with
4.7 and 4.8, it seems to generate code that wanders off into the
weeds.
According to:
http://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
The traditional way of handling variably sized arrays (ISO C90)
is to use an array length of 1. Gcc allows you to use an array
length of 0 and newer versions of gcc only seem to do the
right thing when 0 is used.
This is tricky in this case because atombios.h is shared between
multiple components and is used for allocation in the vbios.
v2: update commit message
Signed-off-by: Alex Deucher
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/radeon/atombios.h | 100 +++---
1 file changed, 50 insertions(+), 50 deletions(-)
diff --git a/drivers/gpu/drm/radeon/atombios.h
b/drivers/gpu/drm/radeon/atombios.h
index 16b120c..3f1f011 100644
--- a/drivers/gpu/drm/radeon/atombios.h
+++ b/drivers/gpu/drm/radeon/atombios.h
@@ -3592,7 +3592,7 @@ typedef struct _ATOM_FAKE_EDID_PATCH_RECORD
{
UCHAR ucRecordType;
UCHAR ucFakeEDIDLength;
- UCHAR ucFakeEDIDString[1];// This actually has ucFakeEdidLength elements.
+ UCHAR ucFakeEDIDString[0];// This actually has ucFakeEdidLength elements.
} ATOM_FAKE_EDID_PATCH_RECORD;
typedef struct _ATOM_PANEL_RESOLUTION_PATCH_RECORD
@@ -3868,7 +3868,7 @@ typedef struct _ATOM_GPIO_PIN_ASSIGNMENT
typedef struct _ATOM_GPIO_PIN_LUT
{
ATOM_COMMON_TABLE_HEADER sHeader;
- ATOM_GPIO_PIN_ASSIGNMENT asGPIO_Pin[1];
+ ATOM_GPIO_PIN_ASSIGNMENT asGPIO_Pin[0];
}ATOM_GPIO_PIN_LUT;
//
@@ -3995,7 +3995,7 @@ typedef struct _ATOM_DISPLAY_OBJECT_PATH
USHORTusSize;//the size of
ATOM_DISPLAY_OBJECT_PATH
USHORTusConnObjectId;//Connector Object
ID
USHORTusGPUObjectId; //GPU ID
- USHORTusGraphicObjIds[1]; //1st Encoder Obj
source from GPU to last Graphic Obj destinate to connector.
+ USHORTusGraphicObjIds[0]; //1st Encoder Obj
source from GPU to last Graphic Obj destinate to connector.
}ATOM_DISPLAY_OBJECT_PATH;
typedef struct _ATOM_DISPLAY_EXTERNAL_OBJECT_PATH
@@ -4012,7 +4012,7 @@ typedef struct _ATOM_DISPLAY_OBJECT_PATH_TABLE
UCHAR ucNumOfDispPath;
UCHAR ucVersion;
UCHAR ucPadding[2];
- ATOM_DISPLAY_OBJECT_PATHasDispPath[1];
+ ATOM_DISPLAY_OBJECT_PATHasDispPath[0];
}ATOM_DISPLAY_OBJECT_PATH_TABLE;
@@ -4028,15 +4028,15 @@ typedef struct _ATOM_OBJECT_TABLE
//Above 4 object table
{
UCHAR ucNumberOfObjects;
UCHAR ucPadding[3];
- ATOM_OBJECT asObjects[1];
+ ATOM_OBJECT asObjects[0];
}ATOM_OBJECT_TABLE;
typedef struct _ATOM_SRC_DST_TABLE_FOR_ONE_OBJECT
//usSrcDstTableOffset pointing to this structure
{
UCHAR ucNumberOfSrc;
- USHORT usSrcObjectID[1];
+ USHORT usSrcObjectID[0];
UCHAR ucNumberOfDst;
- USHORT usDstObjectID[1];
+ USHORT usDstObjectID[0];
}ATOM_SRC_DST_TABLE_FOR_ONE_OBJECT;
@@ -4208,7 +4208,7 @@ typedef struct _ATOM_CONNECTOR_DEVICE_TAG_RECORD
ATOM_COMMON_RECORD_HEADER sheader;
UCHAR ucNumberOfDevice;
UCHAR ucReserved;
- ATOM_CONNECTOR_DEVICE_TAG asDeviceTag[1]; //This Id is same as
"ATOM_DEVICE_XXX_SUPPORT", 1 is only for allocation
+ ATOM_CONNECTOR_DEVICE_TAG asDeviceTag[0]; //This Id is same as
"ATOM_DEVICE_XXX_SUPPORT", 1 is only for allocation
}ATOM_CONNECTOR_DEVICE_TAG_RECORD;
@@ -4268,7 +4268,7 @@ typedef struct _ATOM_OBJECT_GPIO_CNTL_RECORD
ATOM_COMMON_RECORD_HEADER sheader;
UCHAR ucFlags;// Future expnadibility
UCHAR ucNumberOfPins; // Number of GPIO pins
used to control the object
- ATOM_GPIO_PIN_CONTROL_PAIR asGpio[1]; // the real gpio pin
pair determined by number of pins ucNumberOfPins
+ ATOM_GPIO_PIN_CONTROL_PAIR asGpio[0]; // the real gpio pin
pair determined by number of pins ucNumberOfPins
}ATOM_OBJECT_GPIO_CNTL_RECORD;
//Definitions for GPIO pin state
@@ -4549,7 +4549,7 @@ typedef struct _ATOM_I2C_VOLTAGE_OBJECT_V3
UCHARucVoltageControlAddress;
UCHAR
[Bug 67994] Lockup with UVD and DPM on RV730
https://bugs.freedesktop.org/show_bug.cgi?id=67994 Timothée Ravier changed: What|Removed |Added Attachment #84347|0 |1 is obsolete|| --- Comment #10 from Timothée Ravier --- Created attachment 84354 --> https://bugs.freedesktop.org/attachment.cgi?id=84354&action=edit New dmesg log with patched kernel This is the new dmesg log. I tried the patch but the bug is still here in my case. However the "Bad LCD record" error is different now and some lines in the end are not in the new log. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/radeon: fix LCD record parsing
If the LCD table contains an EDID record, properly account for the edid size when walking through the records. This should fix error messages about unknown LCD records. Signed-off-by: Alex Deucher Cc: sta...@vger.kernel.org --- drivers/gpu/drm/radeon/radeon_atombios.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/radeon/radeon_atombios.c b/drivers/gpu/drm/radeon/radeon_atombios.c index 4ac5f40..112c963 100644 --- a/drivers/gpu/drm/radeon/radeon_atombios.c +++ b/drivers/gpu/drm/radeon/radeon_atombios.c @@ -1681,7 +1681,9 @@ struct radeon_encoder_atom_dig *radeon_atombios_get_lvds_info(struct kfree(edid); } } - record += sizeof(ATOM_FAKE_EDID_PATCH_RECORD); + record += fake_edid_record->ucFakeEDIDLength ? + fake_edid_record->ucFakeEDIDLength + 2 : + sizeof(ATOM_FAKE_EDID_PATCH_RECORD); break; case LCD_PANEL_RESOLUTION_RECORD_TYPE: panel_res_record = (ATOM_PANEL_RESOLUTION_PATCH_RECORD *)record; -- 1.8.3.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] [RFC PATCH v6] dmabuf-sync: Add a buffer synchronization framework
On Tue, Aug 13, 2013 at 06:19:35PM +0900, Inki Dae wrote: > This patch adds a buffer synchronization framework based on DMA BUF[1] > and and based on ww-mutexes[2] for lock mechanism. > > The purpose of this framework is to provide not only buffer access control > to CPU and DMA but also easy-to-use interfaces for device drivers and > user application. This framework can be used for all dma devices using > system memory as dma buffer, especially for most ARM based SoCs. > > Changelog v6: > - Fix sync lock to multiple reads. > - Add select system call support. > . Wake up poll_wait when a dmabuf is unlocked. > - Remove unnecessary the use of mutex lock. > - Add private backend ops callbacks. > . This ops has one callback for device drivers to clean up their > sync object resource when the sync object is freed. For this, > device drivers should implement the free callback properly. > - Update document file. > > Changelog v5: > - Rmove a dependence on reservation_object: the reservation_object is used > to hook up to ttm and dma-buf for easy sharing of reservations across > devices. However, the dmabuf sync can be used for all dma devices; v4l2 > and drm based drivers, so doesn't need the reservation_object anymore. > With regared to this, it adds 'void *sync' to dma_buf structure. > - All patches are rebased on mainline, Linux v3.10. > > Changelog v4: > - Add user side interface for buffer synchronization mechanism and update > descriptions related to the user side interface. > > Changelog v3: > - remove cache operation relevant codes and update document file. > > Changelog v2: > - use atomic_add_unless to avoid potential bug. > - add a macro for checking valid access type. > - code clean. > > The mechanism of this framework has the following steps, > 1. Register dmabufs to a sync object - A task gets a new sync object and > can add one or more dmabufs that the task wants to access. > This registering should be performed when a device context or an event > context such as a page flip event is created or before CPU accesses a > shared > buffer. > > dma_buf_sync_get(a sync object, a dmabuf); > > 2. Lock a sync object - A task tries to lock all dmabufs added in its own > sync object. Basically, the lock mechanism uses ww-mutex[1] to avoid dead > lock issue and for race condition between CPU and CPU, CPU and DMA, and > DMA > and DMA. Taking a lock means that others cannot access all locked dmabufs > until the task that locked the corresponding dmabufs, unlocks all the > locked > dmabufs. > This locking should be performed before DMA or CPU accesses these dmabufs. > > dma_buf_sync_lock(a sync object); > > 3. Unlock a sync object - The task unlocks all dmabufs added in its own > sync > object. The unlock means that the DMA or CPU accesses to the dmabufs have > been completed so that others may access them. > This unlocking should be performed after DMA or CPU has completed accesses > to the dmabufs. > > dma_buf_sync_unlock(a sync object); > > 4. Unregister one or all dmabufs from a sync object - A task unregisters > the given dmabufs from the sync object. This means that the task dosen't > want to lock the dmabufs. > The unregistering should be performed after DMA or CPU has completed > accesses to the dmabufs or when dma_buf_sync_lock() is failed. > > dma_buf_sync_put(a sync object, a dmabuf); > dma_buf_sync_put_all(a sync object); > > The described steps may be summarized as: > get -> lock -> CPU or DMA access to a buffer/s -> unlock -> put > > This framework includes the following two features. > 1. read (shared) and write (exclusive) locks - A task is required to > declare > the access type when the task tries to register a dmabuf; > READ, WRITE, READ DMA, or WRITE DMA. > > The below is example codes, > struct dmabuf_sync *sync; > > sync = dmabuf_sync_init(...); > ... > > dmabuf_sync_get(sync, dmabuf, DMA_BUF_ACCESS_R); > ... > > And the below can be used as access types: > DMA_BUF_ACCESS_R - CPU will access a buffer for read. > DMA_BUF_ACCESS_W - CPU will access a buffer for read or write. > DMA_BUF_ACCESS_DMA_R - DMA will access a buffer for read > DMA_BUF_ACCESS_DMA_W - DMA will access a buffer for read or > write. > > 2. Mandatory resource releasing - a task cannot hold a lock indefinitely. > A task may never try to unlock a buffer after taking a lock to the buffer. > In this case, a timer handler to the corresponding sync object is called > in five (default) seconds and then the timed-out buffer is unlocked by > work > queue handler to avoid lockups and to enforce resources of the buffer. > > The below is how to use interfaces for device driver: > 1. Allocate an
Re: [PATCH 2/2] drm/i915: add fast boot support for Haswell
Hi
2013/8/19 Furquan Shaikh :
> Enables getting correct mode clock when reading pipe config
> This patch has been tested successfully on top of drm-intel-nightly tree
>
> Signed-off-by: Furquan Shaikh
> ---
> drivers/gpu/drm/i915/i915_reg.h | 6
> drivers/gpu/drm/i915/intel_ddi.c | 70
>
> drivers/gpu/drm/i915/intel_display.c | 1 +
> 3 files changed, 77 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 2b96d6b..9511129 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -4970,6 +4970,7 @@
> #define SPLL_PLL_NON_SSC (2<<28)
> #define SPLL_PLL_FREQ_810MHz (0<<26)
> #define SPLL_PLL_FREQ_1350MHz (1<<26)
> +#define SPLL_PLL_FREQ_MASK (3<<26)
>
> /* WRPLL */
> #define WRPLL_CTL1 0x46040
> @@ -4983,6 +4984,10 @@
> #define WRPLL_DIVIDER_POST(x) ((x)<<8)
> #define WRPLL_DIVIDER_FEEDBACK(x) ((x)<<16)
>
> +#define WRPLL_DIVIDER_REFERENCE_BITS(reg)(reg & 0xff)
> +#define WRPLL_DIVIDER_POST_BITS(reg) ((reg >> 8) & 0x3f)
> +#define WRPLL_DIVIDER_FEEDBACK_BITS(reg) ((reg >> 16) & 0xff)
> +
> /* Port clock selection */
> #define PORT_CLK_SEL_A 0x46100
> #define PORT_CLK_SEL_B 0x46104
> @@ -4994,6 +4999,7 @@
> #define PORT_CLK_SEL_WRPLL1 (4<<29)
> #define PORT_CLK_SEL_WRPLL2 (5<<29)
> #define PORT_CLK_SEL_NONE (7<<29)
> +#define PORT_CLK_SEL_MASK (7<<29)
>
> /* Transcoder clock selection */
> #define TRANS_CLK_SEL_A0x46140
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> b/drivers/gpu/drm/i915/intel_ddi.c
> index b8c096b..a24a375 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -1246,6 +1246,74 @@ static void intel_ddi_hot_plug(struct intel_encoder
> *intel_encoder)
> intel_dp_check_link_status(intel_dp);
> }
>
> +static void intel_ddi_get_clock(struct intel_encoder *encoder,
> + struct intel_crtc_config *pipe_config)
> +{
> + struct drm_i915_private *dev_priv = encoder->base.dev->dev_private;
> + int port = intel_ddi_get_encoder_port(encoder);
> + u32 temp = I915_READ(PORT_CLK_SEL(port)) & PORT_CLK_SEL_MASK;
> + u8 link_bw;
> +
> + if ((temp == PORT_CLK_SEL_LCPLL_810) ||
> + (temp == PORT_CLK_SEL_LCPLL_1350) ||
> + (temp == PORT_CLK_SEL_LCPLL_2700)) {
> +
> + switch (temp) {
> + case PORT_CLK_SEL_LCPLL_810:
> + link_bw = DP_LINK_BW_1_62;
> + break;
> + case PORT_CLK_SEL_LCPLL_1350:
> + link_bw = DP_LINK_BW_2_7;
> + break;
> + case PORT_CLK_SEL_LCPLL_2700:
> + link_bw = DP_LINK_BW_5_4;
> + break;
> + }
> + pipe_config->port_clock =
> drm_dp_bw_code_to_link_rate(link_bw);
drivers/gpu/drm/i915/intel_ddi.c:1275:56: aviso: ‘link_bw’ may be used
uninitialized in this function [-Wmaybe-uninitialized]
Looks like gcc 4.7.3 isn't that smart :( You should probably add a
"default" case with a WARN_ON(1) inside it.
> + } else if ((temp == PORT_CLK_SEL_WRPLL1) ||
> + (temp == PORT_CLK_SEL_WRPLL2)) {
> + uint64_t p, n2, r2;
> + u32 val, reg;
> + uint64_t freq2k;
> +
> + switch (temp) {
> + case PORT_CLK_SEL_WRPLL1:
> + reg = WRPLL_CTL1;
> + break;
> + case PORT_CLK_SEL_WRPLL2:
> + reg = WRPLL_CTL2;
> + break;
> + }
> + val = I915_READ(reg);
drivers/gpu/drm/i915/intel_ddi.c:1290:7: aviso: ‘reg’ may be used
uninitialized in this function [-Wmaybe-uninitialized]
Same thing here.
> + r2 = WRPLL_DIVIDER_REFERENCE_BITS(val);
> + p = WRPLL_DIVIDER_POST_BITS(val);
> + n2 = WRPLL_DIVIDER_FEEDBACK_BITS(val);
> +
> + freq2k = DIV_ROUND_UP_ULL(LC_FREQ * n2, r2 * p);
> + pipe_config->port_clock = freq2k / 10;
If you put the "/ 10" on the line above so it becomes
DIV_ROUND_UP_ULL(LC_FREQ * n2, r2 * p * 10) you'll avoid the rounding
errors of 1 division.
By the way, I applied your patch + Daniel's suggestion on -nightly and
now I see "unclaimed register" errors when booting with HDMI + eDP.
The problem is that we try to read disabled LINK_M/LINK_N registers
due to the power well disabled, so we get the error messages. I also
once saw a "pipe state mismatch" error, but I can't find a way to
reproduce it now. I'm also not sure whether VGA will really work since
we don't touch intel_crt.c (I can't test it for now). When testing the
patches,
[Bug 60775] New: Installing NVIDIA proprietary drivers on kernel 3.10.7-100.fc18.x86_64 errors out . . . can't find kernel source files
https://bugzilla.kernel.org/show_bug.cgi?id=60775 Bug ID: 60775 Summary: Installing NVIDIA proprietary drivers on kernel 3.10.7-100.fc18.x86_64 errors out . . . can't find kernel source files Product: Drivers Version: 2.5 Kernel Version: Linux 3.10.7-100.fc18.x86_64 SMP Hardware: x86-64 OS: Linux Tree: Fedora Status: NEW Severity: high Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-...@kernel-bugs.osdl.org Reporter: letourneau.r...@gmail.com Regression: No Trying to install NVIDIA-Linux-x86_64-319.32.run proprietary drivers on kernel 3.10.7-100.fc18.x86_64 does not work. Error; "The kernel header file '/usr/src/linux/include/linux/version.h' does not exist. The most likely reason for this is that the kernel source files in '/usr/src/linux' have not been configured." All necessary source rpms are installed ; kernel-headers-3.10.7-100.fc18.x86_64 kernel-devel-3.10.7-100.fc18.x86_64 and all dependencies. Also downloaded kernel source rpm and installed but did not resolve issue; yumdownloader --source kernel rpm -ivh kernel-3.10.7-100.fc18.src.rpm Tried solution here; http://moldvan.com/blog/?p=824 Did not resolve issue when linking /usr/include/linux/version.h to /usr/src/kernels/`uname -r`/include/linux/version.h But once linked, this error pops up; "If you are using a Linux 2.6 kernel, please make sure you have configured kernel sources matching your kernel installed on your system. If you specified a separate output directory using either the \”KBUILD_OUTPUT\” or the \”O\” KBUILD parameter, make sure to specify this directory with the SYSOUT environment variable or with the equivalent nvidia-installer command line option. Depending on where and how the kernel sources (or the kernel headers) were installed, you may need to specify their location with the SYSSRC environment variable or the equivalent nvidia-installer command line option." The NVIDIA proprietary driver does successfully build on kernel 3.6.10-4.fc18.x86_64. Tried uninstalling kernel-headers and kernel-devel rpms and re-installing, did not resolve issue. Expected results would be, for the NVIDIA proprietary drivers to find correct kernel sources, and successfully build and install driver module. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60523] Radeon DPM not working with 2 monitors attached to Radeon HD5770 (Juniper)
https://bugzilla.kernel.org/show_bug.cgi?id=60523 --- Comment #40 from queryv...@gmail.com --- (In reply to Alex Deucher from comment #39) > Created attachment 107254 [details] > fix for 3.11 > > The attached patch seems to fix it for me. That doesn't seem to fix it for me (6870). I first tried 3.11-rc6 + drm-next-3.12-wip (ee31b2b), and then 3.11-rc6 + the standalone patch you attached. In the former case, when trying to force a performance level I still got: echo: write error: Invalid argument And the power level still idles at: power level 2sclk: 9 mclk: 105000 vddc: 1175 vddci: 1150 gcc --version gcc (GCC) 4.8.1 20130725 (prerelease) -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60523] Radeon DPM not working with 2 monitors attached to Radeon HD5770 (Juniper)
https://bugzilla.kernel.org/show_bug.cgi?id=60523 --- Comment #41 from Alex Deucher --- Well, it helps a little, but I'm still able to reproduce it eventually even with the patch. The same kernel source is working fine on a fedora 16 system and now exhibits this problem on Fedora 19. So maybe it's not all gcc. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60523] Radeon DPM not working with 2 monitors attached to Radeon HD5770 (Juniper)
https://bugzilla.kernel.org/show_bug.cgi?id=60523 --- Comment #42 from Alex Deucher --- I can reproduce it in Fedora 17 as well (gcc 4.7). So it seems to be something about Fedora 16 (gcc 4.6). -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60775] Installing NVIDIA proprietary drivers on kernel 3.10.7-100.fc18.x86_64 errors out . . . can't find kernel source files
https://bugzilla.kernel.org/show_bug.cgi?id=60775 --- Comment #1 from Ryan Letourneau --- Just tried solution here http://ewaldertl.blogspot.ca/2013/02/update-fedora-18-to-kernel-376-let-fail.html but did not resolve issue -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/radeon/atombios: fix variable sized arrays for newer gccs (v2)
Ignore this patch for now. there are still problems with newer gcc
versions that aren't fixed yet.
Alex
On Tue, Aug 20, 2013 at 1:16 PM, Alex Deucher wrote:
> Newer versions of gcc seem to wander off into no-man's land
> when using variably sized arrays. Atombios tends to do things
> like:
>
> struct object {
> u8 version;
> u8 num_elements;
> u32 elements[1]; /* num_elements entries */
> };
>
> We then do things like the following in the driver code:
>
> for (i = 0; i < atom_object->num_elements; i++) {
> driver_object[i] = atom_object->elements[i];
> }
>
> With previous versions of gcc this used to work fine, but with
> 4.7 and 4.8, it seems to generate code that wanders off into the
> weeds.
>
> According to:
> http://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
> The traditional way of handling variably sized arrays (ISO C90)
> is to use an array length of 1. Gcc allows you to use an array
> length of 0 and newer versions of gcc only seem to do the
> right thing when 0 is used.
>
> This is tricky in this case because atombios.h is shared between
> multiple components and is used for allocation in the vbios.
>
> v2: update commit message
>
> Signed-off-by: Alex Deucher
> Cc: sta...@vger.kernel.org
> ---
> drivers/gpu/drm/radeon/atombios.h | 100
> +++---
> 1 file changed, 50 insertions(+), 50 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/atombios.h
> b/drivers/gpu/drm/radeon/atombios.h
> index 16b120c..3f1f011 100644
> --- a/drivers/gpu/drm/radeon/atombios.h
> +++ b/drivers/gpu/drm/radeon/atombios.h
> @@ -3592,7 +3592,7 @@ typedef struct _ATOM_FAKE_EDID_PATCH_RECORD
> {
>UCHAR ucRecordType;
>UCHAR ucFakeEDIDLength;
> - UCHAR ucFakeEDIDString[1];// This actually has ucFakeEdidLength
> elements.
> + UCHAR ucFakeEDIDString[0];// This actually has ucFakeEdidLength
> elements.
> } ATOM_FAKE_EDID_PATCH_RECORD;
>
> typedef struct _ATOM_PANEL_RESOLUTION_PATCH_RECORD
> @@ -3868,7 +3868,7 @@ typedef struct _ATOM_GPIO_PIN_ASSIGNMENT
> typedef struct _ATOM_GPIO_PIN_LUT
> {
>ATOM_COMMON_TABLE_HEADER sHeader;
> - ATOM_GPIO_PIN_ASSIGNMENT asGPIO_Pin[1];
> + ATOM_GPIO_PIN_ASSIGNMENT asGPIO_Pin[0];
> }ATOM_GPIO_PIN_LUT;
>
>
> //
> @@ -3995,7 +3995,7 @@ typedef struct _ATOM_DISPLAY_OBJECT_PATH
>USHORTusSize;//the size of
> ATOM_DISPLAY_OBJECT_PATH
>USHORTusConnObjectId;//Connector
> Object ID
>USHORTusGPUObjectId; //GPU ID
> - USHORTusGraphicObjIds[1]; //1st Encoder
> Obj source from GPU to last Graphic Obj destinate to connector.
> + USHORTusGraphicObjIds[0]; //1st Encoder
> Obj source from GPU to last Graphic Obj destinate to connector.
> }ATOM_DISPLAY_OBJECT_PATH;
>
> typedef struct _ATOM_DISPLAY_EXTERNAL_OBJECT_PATH
> @@ -4012,7 +4012,7 @@ typedef struct _ATOM_DISPLAY_OBJECT_PATH_TABLE
>UCHAR ucNumOfDispPath;
>UCHAR ucVersion;
>UCHAR ucPadding[2];
> - ATOM_DISPLAY_OBJECT_PATHasDispPath[1];
> + ATOM_DISPLAY_OBJECT_PATHasDispPath[0];
> }ATOM_DISPLAY_OBJECT_PATH_TABLE;
>
>
> @@ -4028,15 +4028,15 @@ typedef struct _ATOM_OBJECT_TABLE
> //Above 4 object table
> {
>UCHAR ucNumberOfObjects;
>UCHAR ucPadding[3];
> - ATOM_OBJECT asObjects[1];
> + ATOM_OBJECT asObjects[0];
> }ATOM_OBJECT_TABLE;
>
> typedef struct _ATOM_SRC_DST_TABLE_FOR_ONE_OBJECT
> //usSrcDstTableOffset pointing to this structure
> {
>UCHAR ucNumberOfSrc;
> - USHORT usSrcObjectID[1];
> + USHORT usSrcObjectID[0];
>UCHAR ucNumberOfDst;
> - USHORT usDstObjectID[1];
> + USHORT usDstObjectID[0];
> }ATOM_SRC_DST_TABLE_FOR_ONE_OBJECT;
>
>
> @@ -4208,7 +4208,7 @@ typedef struct _ATOM_CONNECTOR_DEVICE_TAG_RECORD
>ATOM_COMMON_RECORD_HEADER sheader;
>UCHAR ucNumberOfDevice;
>UCHAR ucReserved;
> - ATOM_CONNECTOR_DEVICE_TAG asDeviceTag[1]; //This Id is same as
> "ATOM_DEVICE_XXX_SUPPORT", 1 is only for allocation
> + ATOM_CONNECTOR_DEVICE_TAG asDeviceTag[0]; //This Id is same as
> "ATOM_DEVICE_XXX_SUPPORT", 1 is only for allocation
> }ATOM_CONNECTOR_DEVICE_TAG_RECORD;
>
>
> @@ -4268,7 +4268,7 @@ typedef struct _ATOM_OBJECT_GPIO_CNTL_RECORD
>ATOM_COMMON_RECORD_HEADER sheader;
>UCHAR ucFlags;// Future expnadibility
>UCHAR ucNumberOfPins; // Number of GPIO pins
> used to control the object
> - ATOM_GPIO_PIN_CONTROL_PAIR asGpio[1];
[Bug 60231] DisplayPort monitor not detected on PowerColor Radeon HD 4850
https://bugzilla.kernel.org/show_bug.cgi?id=60231 prettyvani...@posteo.at changed: What|Removed |Added Attachment #106381|0 |1 is obsolete|| --- Comment #2 from prettyvani...@posteo.at --- Created attachment 107258 --> https://bugzilla.kernel.org/attachment.cgi?id=107258&action=edit dmesg output with dvi and displayport connected (drm.debug=0xE) -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60231] DisplayPort monitor not detected on PowerColor Radeon HD 4850
https://bugzilla.kernel.org/show_bug.cgi?id=60231 --- Comment #3 from prettyvani...@posteo.at --- Created attachment 107259 --> https://bugzilla.kernel.org/attachment.cgi?id=107259&action=edit xrandr --verbose -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60231] DisplayPort monitor not detected on PowerColor Radeon HD 4850
https://bugzilla.kernel.org/show_bug.cgi?id=60231 --- Comment #4 from prettyvani...@posteo.at --- Created attachment 107260 --> https://bugzilla.kernel.org/attachment.cgi?id=107260&action=edit Xorg.0.log -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60231] DisplayPort monitor not detected on PowerColor Radeon HD 4850
https://bugzilla.kernel.org/show_bug.cgi?id=60231 --- Comment #5 from prettyvani...@posteo.at --- I am running a current mainline kernel until dpm stabilises, so I am on 3.11rc6 currently, which has the patch mentioned already applied. Sadly, no change in behaviour. I updated the dmesg output attachment and added xrandr and X.org log output. Anything in particular I should look for to get to the root of the problem? -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 67994] Lockup with UVD and DPM on RV730
https://bugs.freedesktop.org/show_bug.cgi?id=67994 --- Comment #11 from Timothée Ravier --- Created attachment 84362 --> https://bugs.freedesktop.org/attachment.cgi?id=84362&action=edit X server logs Note: if I quickly kill the second mplayer right after the start of the video I can avoid the crash, but UVD won't work anymore and mplayer will permanently end with some errors (if VDPAU is forced): Selected video codec: H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10 (VDPAU acceleration) [libavcodec] Selected audio codec: ATSC A/52A (AC-3) [libavcodec] AUDIO: 48000 Hz, 2 ch, floatle, 384.0 kbit/12.50% (ratio: 48000->384000) AO: [pulse] 48000Hz 2ch floatle (4 bytes per sample) Starting playback... VIDEO: 1280x720 23.976 fps0.0 kbps ( 0.0 kB/s) VO: [vdpau] 1280x720 => 1280x720 H.264 VDPAU acceleration [ vdpau] Failed creating VDPAU decoder: An invalid/unsupported VdpDecoderProfile value was supplied. FATAL: Cannot initialize video driver. VIDEO: 1280x720 23.976 fps0.0 kbps ( 0.0 kB/s) VO: [vdpau] 1280x720 => 1280x720 H.264 VDPAU acceleration [ vdpau] Failed creating VDPAU decoder: An invalid/unsupported VdpDecoderProfile value was supplied. FATAL: Cannot initialize video driver. [h264_vdpau @ 0x7f736c111cc0]decode_slice_header error [h264_vdpau @ 0x7f736c111cc0]no frame! Error while decoding frame! FATAL: Could not initialize video filters (-vf) or video output (-vo). But right after that my X session was killed and the X server kept exiting with bus errors when starting new ones (see attached log). -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/2] update pixel format setting to fimd driver
Hi Inki, On Tuesday 20 of August 2013 14:45:10 Inki Dae wrote: > This patch series fix pixel format setting according to > drm_framebuffer's pixel_format, and check if a given window > supports alpha channel or not. > > Inki Dae (2): > drm/exynos: fix fimd pixel format setting > drm/exynos: check a pixel format to a particular window layer > > drivers/gpu/drm/exynos/exynos_drm_fimd.c | 45 > -- 1 files changed, 24 insertions(+), 21 > deletions(-) For the whole series: Reviewed-by: Tomasz Figa Best regards, Tomasz ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] nouveau: fix reclocking on nv40
On Mon, Aug 19, 2013 at 4:59 PM, Pali Rohár wrote: > On Friday 16 August 2013 14:57:07 Pali Rohár wrote: >> In commit 77145f1cbdf8d28b46ff8070ca749bad821e0774 was >> introduced error which cause that reclocking on nv40 not >> working anymore. There is missing assigment of return value >> from pll_calc to ret. >> >> Signed-off-by: Pali Rohár >> Signed-off-by: Martin Peres >> --- >> drivers/gpu/drm/nouveau/nv40_pm.c |2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/drivers/gpu/drm/nouveau/nv40_pm.c >> b/drivers/gpu/drm/nouveau/nv40_pm.c index 3af5bcd..625f80d >> 100644 >> --- a/drivers/gpu/drm/nouveau/nv40_pm.c >> +++ b/drivers/gpu/drm/nouveau/nv40_pm.c >> @@ -131,7 +131,7 @@ nv40_calc_pll(struct drm_device *dev, u32 >> reg, struct nvbios_pll *pll, if (clk < pll->vco1.max_freq) >> pll->vco2.max_freq = 0; >> >> - pclk->pll_calc(pclk, pll, clk, &coef); >> + ret = pclk->pll_calc(pclk, pll, clk, &coef); >> if (ret == 0) >> return -ERANGE; > > Hello, it is possible to include this patch in 3.11? > Or it is too late now and need to wait for 3.12? I've picked up the patch and will submit it in my next 3.11-fixes pull request. Thanks, Ben. > > -- > Pali Rohár > pali.ro...@gmail.com > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel > ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] ARM: imx6q: refactor some ldb related clocks
On Tue, Aug 20, 2013 at 02:18:27PM -0700, Mike Turquette wrote: > Quoting Fabio Estevam (2013-08-20 08:40:52) > > On Tue, Aug 20, 2013 at 5:38 AM, Liu Ying wrote: > > > > > diff --git a/Documentation/devicetree/bindings/clock/imx6q-clock.txt > > > b/Documentation/devicetree/bindings/clock/imx6q-clock.txt > > > index 5a90a72..90e923e 100644 > > > --- a/Documentation/devicetree/bindings/clock/imx6q-clock.txt > > > +++ b/Documentation/devicetree/bindings/clock/imx6q-clock.txt > > > @@ -89,8 +89,6 @@ clocks and IDs. > > > gpu3d_shader74 > > > ipu1_podf 75 > > > ipu2_podf 76 > > > - ldb_di0_podf77 > > > - ldb_di1_podf78 > > > ipu1_di0_pre79 > > > ipu1_di1_pre80 > > > ipu2_di0_pre81 > > > > This causes a 'hole' in the clock numbering scheme: 74, 75, 76, 79, 80, etc > > How does this fit in with the idea of having a stable binding/ABI? Seems > like changing this would be a bad idea for devices in the field that > have older DTBs. We should be safe since none of existing DTBs refers to the clocks (they are not leaf clocks in the whole clock tree but some interconnection ones). Shawn ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] refactor some ldb related clocks
Hi Ying, On Tue, Aug 20, 2013 at 06:08:48PM +0800, Liu Ying wrote: > > While I admit to having introduced the combination of 1/3.5 fixed > > divider and configurable 1/1,1/2 divder clocks to describe this > > fractional divider for the reasons you state, I think the correct > > solution would be to improve the table divider to support fractional > > values and get rid of the virtual ldb_di_div_3_5 clocks, not > > introduce more virtual clocks. > > Yes, it's good to support fractional values for the table divider(not sure if > there is any plan for this). > I see there is something similar in 'include/linux/sh_clk.h'. Yeah, I agree with Philipp on improving table divider to support fractional values. Would you like to work on that? Shawn ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: Use correct spinlock flavor in drm_vblank_get()
The irq flags state is already established by the outer
spin_lock_irqsave(); re-disabling irqs is redundant.
Signed-off-by: Peter Hurley
---
drivers/gpu/drm/drm_irq.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index f92da0a..c7d4af5 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -952,13 +952,13 @@ static void drm_update_vblank_count(struct drm_device
*dev, int crtc)
*/
int drm_vblank_get(struct drm_device *dev, int crtc)
{
- unsigned long irqflags, irqflags2;
+ unsigned long irqflags;
int ret = 0;
spin_lock_irqsave(&dev->vbl_lock, irqflags);
/* Going from 0->1 means we have to enable interrupts again */
if (atomic_add_return(1, &dev->vblank_refcount[crtc]) == 1) {
- spin_lock_irqsave(&dev->vblank_time_lock, irqflags2);
+ spin_lock(&dev->vblank_time_lock);
if (!dev->vblank_enabled[crtc]) {
/* Enable vblank irqs under vblank_time_lock protection.
* All vblank count & timestamp updates are held off
@@ -976,7 +976,7 @@ int drm_vblank_get(struct drm_device *dev, int crtc)
drm_update_vblank_count(dev, crtc);
}
}
- spin_unlock_irqrestore(&dev->vblank_time_lock, irqflags2);
+ spin_unlock(&dev->vblank_time_lock);
} else {
if (!dev->vblank_enabled[crtc]) {
atomic_dec(&dev->vblank_refcount[crtc]);
--
1.8.1.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] refactor some ldb related clocks
On 08/21/2013 09:59 AM, Shawn Guo wrote: > Hi Ying, > > On Tue, Aug 20, 2013 at 06:08:48PM +0800, Liu Ying wrote: >>> While I admit to having introduced the combination of 1/3.5 fixed >>> divider and configurable 1/1,1/2 divder clocks to describe this >>> fractional divider for the reasons you state, I think the correct >>> solution would be to improve the table divider to support fractional >>> values and get rid of the virtual ldb_di_div_3_5 clocks, not >>> introduce more virtual clocks. >> >> Yes, it's good to support fractional values for the table divider(not sure >> if there is any plan for this). >> I see there is something similar in 'include/linux/sh_clk.h'. > > Yeah, I agree with Philipp on improving table divider to support > fractional values. Would you like to work on that? > > Shawn > I don't have a plan to work on that now. Liu Ying ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] ARM: imx6q: refactor some ldb related clocks
On 08/20/2013 11:40 PM, Fabio Estevam wrote: > On Tue, Aug 20, 2013 at 5:38 AM, Liu Ying wrote: > >> diff --git a/Documentation/devicetree/bindings/clock/imx6q-clock.txt >> b/Documentation/devicetree/bindings/clock/imx6q-clock.txt >> index 5a90a72..90e923e 100644 >> --- a/Documentation/devicetree/bindings/clock/imx6q-clock.txt >> +++ b/Documentation/devicetree/bindings/clock/imx6q-clock.txt >> @@ -89,8 +89,6 @@ clocks and IDs. >> gpu3d_shader74 >> ipu1_podf 75 >> ipu2_podf 76 >> - ldb_di0_podf77 >> - ldb_di1_podf78 >> ipu1_di0_pre79 >> ipu1_di1_pre80 >> ipu2_di0_pre81 > > This causes a 'hole' in the clock numbering scheme: 74, 75, 76, 79, 80, etc > I find there is a 'hole' in Documentation/devicetree/bindings/clock/imx5-clock.txt as well. The 'hole' was taken by tve_di(26) clock before. Is this more acceptable? ldb_di0_podf_unused77 ldb_di1_podf_unused78 Liu Ying ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH/RFC v3 08/19] video: display: Add MIPI DBI bus support
Hi Rob,
On Tuesday 13 August 2013 20:52:15 Rob Clark wrote:
> On Fri, Aug 9, 2013 at 1:14 PM, Laurent Pinchart wrote:
> > MIPI DBI is a configurable-width parallel display bus that transmits
> > commands and data.
> >
> > Add a new DBI Linux bus type that implements the usual bus
> > infrastructure (including devices and drivers (un)registration and
> > matching, and bus configuration and access functions).
> >
> > Signed-off-by: Laurent Pinchart
> > ---
> >
> > drivers/video/display/Kconfig| 8 ++
> > drivers/video/display/Makefile | 1 +
> > drivers/video/display/mipi-dbi-bus.c | 234 ++
> > include/video/display.h | 4 +
> > include/video/mipi-dbi-bus.h | 125 +++
> > 5 files changed, 372 insertions(+)
> > create mode 100644 drivers/video/display/mipi-dbi-bus.c
> > create mode 100644 include/video/mipi-dbi-bus.h
[snip]
> > diff --git a/include/video/mipi-dbi-bus.h b/include/video/mipi-dbi-bus.h
> > new file mode 100644
> > index 000..876b69d
> > --- /dev/null
> > +++ b/include/video/mipi-dbi-bus.h
[snip]
> > +struct mipi_dbi_device {
> > + const char *name;
> > + int id;
> > + struct device dev;
>
> just fwiw, we need the "framework" to be agnostic of the association between
> devices and entities in the framework. Some things that are multiple
> entities may actually map to a single device in hw
I haven't written down that requirement, but I've kept it in mind while
designing CDF. We have similar use cases in V4L2.
> (and possibly visa versa?).
I don't think that would be needed, but if you can think of a use case I'm all
ears.
> Otherwise we end up having to create fake devices in some cases. Really the
> entities, or objects, or whatever you call 'em should just extend some
> kref'd base class. Sort of like how existing kms objects extend
> drm_mode_object.
struct display_entity {
struct list_head list;
struct device *dev;
struct module *owner;
struct kref ref;
char name[32];
struct media_entity entity;
const struct display_entity_ops *ops;
void(*release)(struct display_entity *ent);
};
(from patch 02/19)
> So any 'struct device' moves down into the derived class, not in the base
> class. Configuration data is passed in separate, not grabbed out of dev->
> platform_data, etc. Probably there is room for some helpers to pull stuff
> out of DT/ACPI/whatever.
struct mipi_dbi_device is not a display entity, it's a physical device plugged
on a DBI bus. It's thus similar in purpose to struct pci_device or struct
platform_device. The DBI device driver will then create one or more display
entities depending on its needs.
> > + const struct mipi_dbi_device_id *id_entry;
> > + struct mipi_dbi_bus *bus;
> > +
> > + unsigned int flags;
> > + unsigned int bus_width;
> > + unsigned int data_width;
> > +};
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH/RFC v3 00/19] Common Display Framework
Hi Rob, On Tuesday 13 August 2013 20:43:50 Rob Clark wrote: > On Fri, Aug 9, 2013 at 1:14 PM, Laurent Pinchart wrote: > > Hi everybody, > > > > Here's the third RFC of the Common Display Framework. > > > > I won't repeat all the background information from the versions one and > > two here, you can read it at http://lwn.net/Articles/512363/ and > > http://lwn.net/Articles/526965/. > > > > This RFC isn't final. Given the high interest in CDF and the urgent tasks > > that kept delaying the next version of the patch set, I've decided to > > release v3 before completing all parts of the implementation. Known > > missing items are > > > > - documentation: kerneldoc and this cover letter should provide basic > > information, more extensive documentation will likely make it to v4. > > > > - pipeline configuration and control: generic code to configure and > > control display pipelines (in a nutshell, translating high-level mode > > setting and DPMS calls to low-level entity operations) is missing. Video > > and stream control operations have been carried over from v2, but will > > need to be revised for v4. > > > > - DSI support: I still have no DSI hardware I can easily test the code on. > > tbh, I kinda think that DSI and bridge chips are the things we should focus > on first.. that seems what is most important for current and new hardware. > Back-filling to handle older/simpler panels can be done later. That sounds reasonable (although I still believe DSI is only part of the issue), but I'll need help with that, as the Renesas platforms I work on don't have a DSI bus. > > Special thanks go to > > > > - Renesas for inviting me to LinuxCon Japan 2013 where I had the > > opportunity to validate the CDF v3 concepts with Alexandre Courbot > > (NVidia) and Tomasz Figa (Samsung). > > > > - Tomi Valkeinen (TI) for taking the time to deeply brainstorm v3 with me. > > > > - Linaro for inviting me to Linaro Connect Europe 2013, the discussions we > > had there greatly helped moving CDF forward. > > > > - And of course all the developers who showed interest in CDF and spent > > time sharing ideas, reviewing patches and testing code. > > > > I have to confess I was a bit lost and discouraged after all the CDF- > > related meetings during which we have discussed how to move from v2 to v3. > > With every meeting I was hoping to run the implementation through use > > cases of various interesting parties and narrow down the scope of the huge > > fuzzy beast that CDF was. With every meeting the scope actually broadened, > > with no clear path at sight anywhere. > > > > Earlier this year I was about to drop one of the requirements on which I > > had based CDF v2: sharing drivers between DRM/KMS and V4L2. With only two > > HDMI transmitters as use cases for that feature (with only out-of-tree > > drivers so far), I just thought the involved completely wasn't worth it > > and that I should implement CDF v3 as a DRM/KMS-only helper framework. > > However, a seemingly unrelated discussion with Xilinx developers showed > > me that hybrid SoC-FPGA platforms such as the Xilinx Zynq 7000 have a > > larger library of IP cores that can be used in camera capture pipelines > > and in display pipelines. The two use cases suddenly became tens or even > > hundreds of use cases that I couldn't ignore anymore. > > Hmm, I'm still not really convinced ;-) > > Or maybe, put another way, I still think we should still optimize for the > common case. I mean I'm sure you *can* design hw that has an LVDS->DP bridge > in the capture path, and if you had something like an FPGA where that was > cheap to do maybe you even would (for fun). But if in the real world, there > are only one or two cases of actual hw using the same bridge in a capture > pipeline which is normally used in display pipelines, then duplicating some > small bit of code for that abnormal case if it makes things easier for the > common case, seems like a reasonable trade-off to me. That was my opinion as well until I started working on a Xilinx platform. There's dozens of IP cores there that are used in both capture and display pipelines. Furthermore, FPGA display pipelines being made of individual IP cores, we need a way to write one driver per IP core and make them all interact. The recently proposed drm_bridge is one possible solution to this issue (and to a different but similar issue that trigerred the development of drm_bridge), but it's in my opinion not generic enough. We're facing several problems that are related, it would really be a shame not to solve them with a good enough framework. > I mean, take a DSI panel driver, for example.. anything but a trivial panel > driver, you are going to want to expose some custom properties on the > connector for controlling non-standard features. So you end up with both > cdf_foo for the common part, and drm_foo for gluing in the properties. And > now these two parts which otherwise would b
Re: [PATCH/RFC v3 00/19] Common Display Framework
On Tue, Aug 20, 2013 at 11:24 AM, Laurent Pinchart wrote: > Hi Rob, > > On Tuesday 13 August 2013 20:43:50 Rob Clark wrote: >> On Fri, Aug 9, 2013 at 1:14 PM, Laurent Pinchart wrote: >> > Hi everybody, >> > >> > Here's the third RFC of the Common Display Framework. >> > >> > I won't repeat all the background information from the versions one and >> > two here, you can read it at http://lwn.net/Articles/512363/ and >> > http://lwn.net/Articles/526965/. >> > >> > This RFC isn't final. Given the high interest in CDF and the urgent tasks >> > that kept delaying the next version of the patch set, I've decided to >> > release v3 before completing all parts of the implementation. Known >> > missing items are >> > >> > - documentation: kerneldoc and this cover letter should provide basic >> > information, more extensive documentation will likely make it to v4. >> > >> > - pipeline configuration and control: generic code to configure and >> > control display pipelines (in a nutshell, translating high-level mode >> > setting and DPMS calls to low-level entity operations) is missing. Video >> > and stream control operations have been carried over from v2, but will >> > need to be revised for v4. >> > >> > - DSI support: I still have no DSI hardware I can easily test the code on. >> >> tbh, I kinda think that DSI and bridge chips are the things we should focus >> on first.. that seems what is most important for current and new hardware. >> Back-filling to handle older/simpler panels can be done later. > > That sounds reasonable (although I still believe DSI is only part of the > issue), but I'll need help with that, as the Renesas platforms I work on don't > have a DSI bus. > >> > Special thanks go to >> > >> > - Renesas for inviting me to LinuxCon Japan 2013 where I had the >> > opportunity to validate the CDF v3 concepts with Alexandre Courbot >> > (NVidia) and Tomasz Figa (Samsung). >> > >> > - Tomi Valkeinen (TI) for taking the time to deeply brainstorm v3 with me. >> > >> > - Linaro for inviting me to Linaro Connect Europe 2013, the discussions we >> > had there greatly helped moving CDF forward. >> > >> > - And of course all the developers who showed interest in CDF and spent >> > time sharing ideas, reviewing patches and testing code. >> > >> > I have to confess I was a bit lost and discouraged after all the CDF- >> > related meetings during which we have discussed how to move from v2 to v3. >> > With every meeting I was hoping to run the implementation through use >> > cases of various interesting parties and narrow down the scope of the huge >> > fuzzy beast that CDF was. With every meeting the scope actually broadened, >> > with no clear path at sight anywhere. >> > >> > Earlier this year I was about to drop one of the requirements on which I >> > had based CDF v2: sharing drivers between DRM/KMS and V4L2. With only two >> > HDMI transmitters as use cases for that feature (with only out-of-tree >> > drivers so far), I just thought the involved completely wasn't worth it >> > and that I should implement CDF v3 as a DRM/KMS-only helper framework. >> > However, a seemingly unrelated discussion with Xilinx developers showed >> > me that hybrid SoC-FPGA platforms such as the Xilinx Zynq 7000 have a >> > larger library of IP cores that can be used in camera capture pipelines >> > and in display pipelines. The two use cases suddenly became tens or even >> > hundreds of use cases that I couldn't ignore anymore. >> >> Hmm, I'm still not really convinced ;-) >> >> Or maybe, put another way, I still think we should still optimize for the >> common case. I mean I'm sure you *can* design hw that has an LVDS->DP bridge >> in the capture path, and if you had something like an FPGA where that was >> cheap to do maybe you even would (for fun). But if in the real world, there >> are only one or two cases of actual hw using the same bridge in a capture >> pipeline which is normally used in display pipelines, then duplicating some >> small bit of code for that abnormal case if it makes things easier for the >> common case, seems like a reasonable trade-off to me. > > That was my opinion as well until I started working on a Xilinx platform. > There's dozens of IP cores there that are used in both capture and display > pipelines. or maybe just some helper lib's to handling the register level programming? Anyways, I guess you can call it a "worse is better" thing, but if you can get 90% of the desired effect for 10% of the work, take the simpler solution. I don't think we should make things more layered or more difficult for one exceptional case. > Furthermore, FPGA display pipelines being made of individual IP cores, we need > a way to write one driver per IP core and make them all interact. The recently > proposed drm_bridge is one possible solution to this issue (and to a different > but similar issue that trigerred the development of drm_bridge), but it's in > my opinion not generic enough. We're facin
i915 producing warnings with kernel 3.11-rc5
I see lots of warning like this with 3.11-rc5 on my thinkpad t40. [197481.739272] [drm:intel_pipe_config_compare] *ERROR* mismatch in adjusted_mode.flags (expected 1, found 0) [197481.739283] [ cut here ] [197481.739352] WARNING: CPU: 0 PID: 556 at drivers/gpu/drm/i915/intel_display.c:8286 check_crtc_state+0x5cf/0xa50 [i915]() [197481.739355] pipe state doesn't match! [197481.739358] Modules linked in: fuse ebtable_nat xt_CHECKSUM nf_conntrack_netbios_ns nf_conntrack_broadcast ipt_MASQUERADE ip6table_mangle ip6t_REJECT nf_conntrack_ipv6 bridge nf_defrag_ipv6 stp llc iptable_nat nf_nat_ipv4 nf_nat be2iscsi iscsi_boot_sysfs iptable_mangle bnx2i nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack lockd nf_conntrack sunrpc cnic ebtable_filter uio cxgb4i cxgb4 ebtables ip6table_filter ip6_tables cxgb3i cxgb3 mdio libcxgbi ib_iser rdma_cm ib_addr iw_cm ib_cm ib_sa ib_mad ib_core iscsi_tcp libiscsi_tcp rfcomm libiscsi scsi_transport_iscsi bnep arc4 iwldvm mac80211 btusb snd_hda_codec_hdmi iwlwifi snd_hda_codec_conexant snd_hda_intel snd_hda_codec bluetooth vhost_net cfg80211 tun macvtap macvlan iTCO_wdt uvcvideo iTCO_vendor_support snd_usb_audio vhost snd_usbmidi_lib videobuf2_vmalloc [197481.739440] snd_hwdep kvm_intel videobuf2_memops videobuf2_core videodev snd_rawmidi thinkpad_acpi e1000e kvm snd_seq rfkill i2c_i801 snd_seq_device snd_pcm snd_page_alloc snd_timer pcspkr lpc_ich mfd_core snd ptp tpm_tis pps_core wmi soundcore tpm tpm_bios binfmt_misc uinput i915 firewire_ohci firewire_core crc_itu_t i2c_algo_bit drm_kms_helper sdhci_pci sdhci drm mmc_core i2c_core video [197481.739492] CPU: 0 PID: 556 Comm: X Tainted: GW3.11.0-rc5-mst #253 [197481.739497] Hardware name: LENOVO 4243BQ9/4243BQ9, BIOS 8AET57WW (1.37 ) 04/05/2012 [197481.739501] 205e 88020be47828 81672e9d 88020be47868 [197481.739509] 8105c52c 88021270fc70 88021241d000 [197481.739516] 0001 88021270fc78 88021270f800 88020be47948 [197481.739523] Call Trace: [197481.739537] [] dump_stack+0x6a/0x7d [197481.739547] [] warn_slowpath_common+0x8c/0xc0 [197481.739555] [] warn_slowpath_fmt+0x6e/0x70 [197481.739589] [] ? i915_read32+0x75/0x130 [i915] [197481.739617] [] ? i915_read32+0x75/0x130 [i915] [197481.739657] [] ? intel_lvds_get_config+0x45/0xb0 [i915] [197481.739692] [] check_crtc_state+0x5cf/0xa50 [i915] [197481.739730] [] intel_modeset_check_state+0x2e5/0x7c0 [i915] [197481.739758] [] ? i915_write32+0xdb/0x140 [i915] [197481.739792] [] intel_crt_dpms+0x8c/0xd0 [i915] [197481.739826] [] drm_mode_obj_set_property_ioctl+0x393/0x3b0 [drm] [197481.739854] [] drm_mode_connector_property_set_ioctl+0x32/0x40 [drm] [197481.739880] [] drm_ioctl+0x3da/0x660 [drm] [197481.739893] [] ? __free_pages+0x45/0x50 [197481.739923] [] ? drm_mode_obj_set_property_ioctl+0x3b0/0x3b0 [drm] [197481.739933] [] ? file_has_perm+0xaa/0xb0 [197481.739977] [] i915_compat_ioctl+0x45/0x50 [i915] [197481.739985] [] compat_sys_ioctl+0x106/0x13a0 [197481.739994] [] ? file_sb_list_del+0x49/0x50 [197481.740001] [] ? task_work_add+0x55/0x70 [197481.740008] [] ? fput+0x75/0xb0 [197481.740017] [] ? __audit_syscall_exit+0x23b/0x2e0 [197481.740027] [] sysenter_dispatch+0x7/0x21 [197481.740031] ---[ end trace 60b3bfa00b791b28 ]--- The graphics card is: 00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09) Anyone interested in debugging the source of these warnings? -- MST ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] ARM: imx6q: refactor some ldb related clocks
Quoting Fabio Estevam (2013-08-20 08:40:52) > On Tue, Aug 20, 2013 at 5:38 AM, Liu Ying wrote: > > > diff --git a/Documentation/devicetree/bindings/clock/imx6q-clock.txt > > b/Documentation/devicetree/bindings/clock/imx6q-clock.txt > > index 5a90a72..90e923e 100644 > > --- a/Documentation/devicetree/bindings/clock/imx6q-clock.txt > > +++ b/Documentation/devicetree/bindings/clock/imx6q-clock.txt > > @@ -89,8 +89,6 @@ clocks and IDs. > > gpu3d_shader74 > > ipu1_podf 75 > > ipu2_podf 76 > > - ldb_di0_podf77 > > - ldb_di1_podf78 > > ipu1_di0_pre79 > > ipu1_di1_pre80 > > ipu2_di0_pre81 > > This causes a 'hole' in the clock numbering scheme: 74, 75, 76, 79, 80, etc How does this fit in with the idea of having a stable binding/ABI? Seems like changing this would be a bad idea for devices in the field that have older DTBs. Regards, Mike > > ___ > linux-arm-kernel mailing list > linux-arm-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH/RFC v3 06/19] video: display: OF support
Hi Philipp,
On Tuesday 13 August 2013 16:37:07 Philipp Zabel wrote:
> Hi Laurent,
>
> thanks for this update. I'm very happy about the move to the display entity
> model, given that the i.MX6 IPU has both drm/display and v4l2/capture ports
> in a single device - this will allow to use a unified device tree binding
> scheme.
Thanks for the support :-)
> I'm still trying to see how this all fits together, so far I have only one
> comment, below.
>
> Am Freitag, den 09.08.2013, 19:14 +0200 schrieb Laurent Pinchart:
> [...]
>
> > +static int display_of_parse_dt(struct display_entity_notifier *notifier,
> > + struct list_head *entities,
> > + struct device_node *node)
> > +{
> > + struct display_entity_of *entity;
> > + struct device_node *remote;
> > + struct device_node *ep = NULL;
> > + struct device_node *next;
> > + unsigned int num_entities = 0;
> > + int ret = 0;
> > +
> > + /* Walk the device tree and build a list of nodes. */
> > + dev_dbg(notifier->dev, "parsing node %s\n", node->full_name);
> > +
> > + while (1) {
> > + next = display_of_get_next_endpoint(node, ep);
> > + if (next == NULL)
> > + break;
> > +
> > + of_node_put(ep);
> > + ep = next;
> > +
> > + dev_dbg(notifier->dev, "handling endpoint %s\n", ep->full_name);
> > +
> > + remote = display_of_get_remote_port_parent(ep);
> > + if (remote == NULL)
> > + continue;
> > +
> > + /* Skip entities that we have already processed. */
> > + if (display_of_find_entity(entities, remote) || remote == node)
> > {
> > + dev_dbg(notifier->dev,
> > + "entity %s already in list, skipping\n",
> > + remote->full_name);
> > + continue;
> > + }
>
> device tree nodes with status = "disabled" should be skipped here:
>
> if (!of_device_is_available(remote)) {
> dev_dbg(notifier->dev,
> "entity %s is disabled, skipping\n",
> remote->full_name);
> continue;
> }
>
> Otherwise the completion notification will never be delivered if there
> are any disabled entities in the graph.
That's a good point, but if a device is disabled, why would it be in the DT
graph in the first place ? Do you have a use case for this ?
> > + entity = kzalloc(sizeof(*entity), GFP_KERNEL);
> > + if (entity == NULL) {
> > + of_node_put(remote);
> > + ret = -ENOMEM;
> > + break;
> > + }
> > +
> > + dev_dbg(notifier->dev, "adding remote entity %s to list\n",
> > + remote->full_name);
> > +
> > + entity->node = remote;
> > + list_add_tail(&entity->list, entities);
> > + num_entities++;
> > + }
> > +
> > + of_node_put(ep);
> > +
> > + if (ret < 0)
> > + return ret;
> > +
> > + return num_entities;
> > +}
>
> [...]
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
A gentle scrub
A small pass on drm headers to remove some stale prototypes/functions/defines and to make static a few functions. drivers/gpu/drm/drm_crtc.c | 38 +++-- drivers/gpu/drm/drm_fb_cma_helper.c | 5 ++--- drivers/gpu/drm/drm_modes.c | 21 drivers/gpu/drm/drm_platform.c | 7 +++ include/drm/drmP.h | 8 include/drm/drm_crtc.h | 17 - include/drm/drm_fb_cma_helper.h | 1 - include/drm/drm_pciids.h| 30 - 8 files changed, 8 insertions(+), 119 deletions(-) -- Damien
[PATCH 1/8] drm: Remove stale prototypes
A few prototypes have been left in the headers, their function friends long gone. Signed-off-by: Damien Lespiau --- include/drm/drmP.h | 5 - include/drm/drm_crtc.h | 11 --- 2 files changed, 16 deletions(-) diff --git a/include/drm/drmP.h b/include/drm/drmP.h index 39911dc..046a7db 100644 --- a/include/drm/drmP.h +++ b/include/drm/drmP.h @@ -1371,7 +1371,6 @@ extern int drm_irq_uninstall(struct drm_device *dev); extern int drm_vblank_init(struct drm_device *dev, int num_crtcs); extern int drm_wait_vblank(struct drm_device *dev, void *data, struct drm_file *filp); -extern int drm_vblank_wait(struct drm_device *dev, unsigned int *vbl_seq); extern u32 drm_vblank_count(struct drm_device *dev, int crtc); extern u32 drm_vblank_count_and_time(struct drm_device *dev, int crtc, struct timeval *vblanktime); @@ -1491,10 +1490,6 @@ void drm_prime_destroy_file_private(struct drm_prime_file_private *prime_fpriv); int drm_prime_lookup_buf_handle(struct drm_prime_file_private *prime_fpriv, struct dma_buf *dma_buf, uint32_t *handle); void drm_prime_remove_buf_handle(struct drm_prime_file_private *prime_fpriv, struct dma_buf *dma_buf); -int drm_prime_add_dma_buf(struct drm_device *dev, struct drm_gem_object *obj); -int drm_prime_lookup_obj(struct drm_device *dev, struct dma_buf *buf, -struct drm_gem_object **obj); - #if DRM_DEBUG_CODE extern int drm_vma_info(struct seq_file *m, void *data); #endif diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h index 45f1332..eb40a96 100644 --- a/include/drm/drm_crtc.h +++ b/include/drm/drm_crtc.h @@ -948,9 +948,6 @@ extern int drm_object_property_set_value(struct drm_mode_object *obj, extern int drm_object_property_get_value(struct drm_mode_object *obj, struct drm_property *property, uint64_t *value); -extern struct drm_display_mode *drm_crtc_mode_create(struct drm_device *dev); -extern void drm_framebuffer_set_object(struct drm_device *dev, - unsigned long handle); extern int drm_framebuffer_init(struct drm_device *dev, struct drm_framebuffer *fb, const struct drm_framebuffer_funcs *funcs); @@ -961,10 +958,6 @@ extern void drm_framebuffer_reference(struct drm_framebuffer *fb); extern void drm_framebuffer_remove(struct drm_framebuffer *fb); extern void drm_framebuffer_cleanup(struct drm_framebuffer *fb); extern void drm_framebuffer_unregister_private(struct drm_framebuffer *fb); -extern int drmfb_probe(struct drm_device *dev, struct drm_crtc *crtc); -extern int drmfb_remove(struct drm_device *dev, struct drm_framebuffer *fb); -extern void drm_crtc_probe_connector_modes(struct drm_device *dev, int maxX, int maxY); -extern bool drm_crtc_in_use(struct drm_crtc *crtc); extern void drm_object_attach_property(struct drm_mode_object *obj, struct drm_property *property, @@ -1039,10 +1032,6 @@ extern int drm_mode_getblob_ioctl(struct drm_device *dev, void *data, struct drm_file *file_priv); extern int drm_mode_connector_property_set_ioctl(struct drm_device *dev, void *data, struct drm_file *file_priv); -extern int drm_mode_hotplug_ioctl(struct drm_device *dev, - void *data, struct drm_file *file_priv); -extern int drm_mode_replacefb(struct drm_device *dev, - void *data, struct drm_file *file_priv); extern int drm_mode_getencoder(struct drm_device *dev, void *data, struct drm_file *file_priv); extern int drm_mode_gamma_get_ioctl(struct drm_device *dev, -- 1.8.3.1
[PATCH 2/8] drm: Remove drm_mode_create_dithering_property()
This was last used by nouveau, replaced by a driver-specific property
in:
commit de69185573586302ada2e59ba41835df36986277
Author: Ben Skeggs
Date: Mon Oct 17 12:23:41 2011 +1000
drm/nouveau: improve dithering properties, and implement proper auto mode
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/drm_crtc.c | 31 ---
include/drm/drm_crtc.h | 1 -
2 files changed, 32 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index a691764..ffb791f 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -125,13 +125,6 @@ static const struct drm_prop_enum_list
drm_scaling_mode_enum_list[] =
{ DRM_MODE_SCALE_ASPECT, "Full aspect" },
};
-static const struct drm_prop_enum_list drm_dithering_mode_enum_list[] =
-{
- { DRM_MODE_DITHERING_OFF, "Off" },
- { DRM_MODE_DITHERING_ON, "On" },
- { DRM_MODE_DITHERING_AUTO, "Automatic" },
-};
-
/*
* Non-global properties, but "required" for certain connectors.
*/
@@ -1161,30 +1154,6 @@ int drm_mode_create_scaling_mode_property(struct
drm_device *dev)
EXPORT_SYMBOL(drm_mode_create_scaling_mode_property);
/**
- * drm_mode_create_dithering_property - create dithering property
- * @dev: DRM device
- *
- * Called by a driver the first time it's needed, must be attached to desired
- * connectors.
- */
-int drm_mode_create_dithering_property(struct drm_device *dev)
-{
- struct drm_property *dithering_mode;
-
- if (dev->mode_config.dithering_mode_property)
- return 0;
-
- dithering_mode =
- drm_property_create_enum(dev, 0, "dithering",
- drm_dithering_mode_enum_list,
- ARRAY_SIZE(drm_dithering_mode_enum_list));
- dev->mode_config.dithering_mode_property = dithering_mode;
-
- return 0;
-}
-EXPORT_SYMBOL(drm_mode_create_dithering_property);
-
-/**
* drm_mode_create_dirty_property - create dirty property
* @dev: DRM device
*
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index eb40a96..781988f 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -982,7 +982,6 @@ extern int drm_mode_create_dvi_i_properties(struct
drm_device *dev);
extern int drm_mode_create_tv_properties(struct drm_device *dev, int
num_formats,
char *formats[]);
extern int drm_mode_create_scaling_mode_property(struct drm_device *dev);
-extern int drm_mode_create_dithering_property(struct drm_device *dev);
extern int drm_mode_create_dirty_info_property(struct drm_device *dev);
extern const char *drm_get_encoder_name(const struct drm_encoder *encoder);
--
1.8.3.1
[PATCH 3/8] drm: Remove drm_mode_list_concat()
The last user was removed in
commit 575dc34ee0de867ba83abf25998e0963bff451fa
Author: Dave Airlie
Date: Mon Sep 7 18:43:26 2009 +1000
drm/kms: remove old std mode fallback code.
The new code adds modes in the helper, which makes more sense
I disliked the non-driver code adding modes.
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/drm_modes.c | 21 -
include/drm/drm_crtc.h | 2 --
2 files changed, 23 deletions(-)
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 504a602..fc2adb6 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -596,27 +596,6 @@ void drm_mode_set_name(struct drm_display_mode *mode)
EXPORT_SYMBOL(drm_mode_set_name);
/**
- * drm_mode_list_concat - move modes from one list to another
- * @head: source list
- * @new: dst list
- *
- * LOCKING:
- * Caller must ensure both lists are locked.
- *
- * Move all the modes from @head to @new.
- */
-void drm_mode_list_concat(struct list_head *head, struct list_head *new)
-{
-
- struct list_head *entry, *tmp;
-
- list_for_each_safe(entry, tmp, head) {
- list_move_tail(entry, new);
- }
-}
-EXPORT_SYMBOL(drm_mode_list_concat);
-
-/**
* drm_mode_width - get the width of a mode
* @mode: mode
*
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 781988f..39d84dc 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -927,8 +927,6 @@ extern int drm_mode_height(const struct drm_display_mode
*mode);
/* for us by fb module */
extern struct drm_display_mode *drm_mode_create(struct drm_device *dev);
extern void drm_mode_destroy(struct drm_device *dev, struct drm_display_mode
*mode);
-extern void drm_mode_list_concat(struct list_head *head,
-struct list_head *new);
extern void drm_mode_validate_size(struct drm_device *dev,
struct list_head *mode_list,
int maxX, int maxY, int maxPitch);
--
1.8.3.1
[PATCH 4/8] drm: Make drm_mode_remove() static
It's only used in drm_crtc.c.
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/drm_crtc.c | 7 +++
include/drm/drm_crtc.h | 1 -
2 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index ffb791f..54b4169 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -686,20 +686,19 @@ void drm_mode_probed_add(struct drm_connector *connector,
}
EXPORT_SYMBOL(drm_mode_probed_add);
-/**
+/*
* drm_mode_remove - remove and free a mode
* @connector: connector list to modify
* @mode: mode to remove
*
* Remove @mode from @connector's mode list, then free it.
*/
-void drm_mode_remove(struct drm_connector *connector,
-struct drm_display_mode *mode)
+static void drm_mode_remove(struct drm_connector *connector,
+ struct drm_display_mode *mode)
{
list_del(&mode->head);
drm_mode_destroy(connector->dev, mode);
}
-EXPORT_SYMBOL(drm_mode_remove);
/**
* drm_connector_init - Init a preallocated connector
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 39d84dc..014e491 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -910,7 +910,6 @@ extern struct edid *drm_get_edid(struct drm_connector
*connector,
struct i2c_adapter *adapter);
extern int drm_add_edid_modes(struct drm_connector *connector, struct edid
*edid);
extern void drm_mode_probed_add(struct drm_connector *connector, struct
drm_display_mode *mode);
-extern void drm_mode_remove(struct drm_connector *connector, struct
drm_display_mode *mode);
extern void drm_mode_copy(struct drm_display_mode *dst, const struct
drm_display_mode *src);
extern struct drm_display_mode *drm_mode_duplicate(struct drm_device *dev,
const struct
drm_display_mode *mode);
--
1.8.3.1
[PATCH 5/8] drm: Remove 2 unused defines
These were introduced in the very first DRM commit:
commit f453ba0460742ad027ae0c4c7d61e62817b3e7ef
Author: Dave Airlie
Date: Fri Nov 7 14:05:41 2008 -0800
DRM: add mode setting support
Add mode setting support to the DRM layer.
But are unused.
Signed-off-by: Damien Lespiau
---
include/drm/drm_crtc.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 014e491..0a9f73e 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -494,8 +494,6 @@ struct drm_encoder_funcs {
void (*destroy)(struct drm_encoder *encoder);
};
-#define DRM_CONNECTOR_MAX_UMODES 16
-#define DRM_CONNECTOR_LEN 32
#define DRM_CONNECTOR_MAX_ENCODER 3
/**
--
1.8.3.1
[PATCH 6/8] drm: Make drm_fb_cma_describe() static
This function is only used in drm_fb_cma_helper.c.
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/drm_fb_cma_helper.c | 5 ++---
include/drm/drm_fb_cma_helper.h | 1 -
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c
b/drivers/gpu/drm/drm_fb_cma_helper.c
index c385cc5..61b5a47 100644
--- a/drivers/gpu/drm/drm_fb_cma_helper.c
+++ b/drivers/gpu/drm/drm_fb_cma_helper.c
@@ -181,11 +181,11 @@ struct drm_gem_cma_object *drm_fb_cma_get_gem_obj(struct
drm_framebuffer *fb,
EXPORT_SYMBOL_GPL(drm_fb_cma_get_gem_obj);
#ifdef CONFIG_DEBUG_FS
-/**
+/*
* drm_fb_cma_describe() - Helper to dump information about a single
* CMA framebuffer object
*/
-void drm_fb_cma_describe(struct drm_framebuffer *fb, struct seq_file *m)
+static void drm_fb_cma_describe(struct drm_framebuffer *fb, struct seq_file *m)
{
struct drm_fb_cma *fb_cma = to_fb_cma(fb);
int i, n = drm_format_num_planes(fb->pixel_format);
@@ -199,7 +199,6 @@ void drm_fb_cma_describe(struct drm_framebuffer *fb, struct
seq_file *m)
drm_gem_cma_describe(fb_cma->obj[i], m);
}
}
-EXPORT_SYMBOL_GPL(drm_fb_cma_describe);
/**
* drm_fb_cma_debugfs_show() - Helper to list CMA framebuffer objects
diff --git a/include/drm/drm_fb_cma_helper.h b/include/drm/drm_fb_cma_helper.h
index 4a3fc24..c54cf3d 100644
--- a/include/drm/drm_fb_cma_helper.h
+++ b/include/drm/drm_fb_cma_helper.h
@@ -24,7 +24,6 @@ struct drm_gem_cma_object *drm_fb_cma_get_gem_obj(struct
drm_framebuffer *fb,
unsigned int plane);
#ifdef CONFIG_DEBUG_FS
-void drm_fb_cma_describe(struct drm_framebuffer *fb, struct seq_file *m);
int drm_fb_cma_debugfs_show(struct seq_file *m, void *arg);
#endif
--
1.8.3.1
[PATCH 7/8] drm: Remove unused PCI ids
Signed-off-by: Damien Lespiau
---
include/drm/drm_pciids.h | 30 --
1 file changed, 30 deletions(-)
diff --git a/include/drm/drm_pciids.h b/include/drm/drm_pciids.h
index 34efaf6..0a85e5c 100644
--- a/include/drm/drm_pciids.h
+++ b/include/drm/drm_pciids.h
@@ -690,29 +690,6 @@
{0x102b, 0x2527, PCI_ANY_ID, PCI_ANY_ID, 0, 0, MGA_CARD_TYPE_G550}, \
{0, 0, 0}
-#define mach64_PCI_IDS \
- {0x1002, 0x4749, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, \
- {0x1002, 0x4750, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, \
- {0x1002, 0x4751, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, \
- {0x1002, 0x4742, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, \
- {0x1002, 0x4744, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, \
- {0x1002, 0x4c49, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, \
- {0x1002, 0x4c50, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, \
- {0x1002, 0x4c51, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, \
- {0x1002, 0x4c42, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, \
- {0x1002, 0x4c44, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, \
- {0x1002, 0x474c, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, \
- {0x1002, 0x474f, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, \
- {0x1002, 0x4752, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, \
- {0x1002, 0x4753, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, \
- {0x1002, 0x474d, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, \
- {0x1002, 0x474e, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, \
- {0x1002, 0x4c52, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, \
- {0x1002, 0x4c53, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, \
- {0x1002, 0x4c4d, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, \
- {0x1002, 0x4c4e, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, \
- {0, 0, 0}
-
#define sisdrv_PCI_IDS \
{0x1039, 0x0300, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, \
{0x1039, 0x5300, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, \
@@ -752,10 +729,6 @@
{0x8086, 0x1132, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, \
{0, 0, 0}
-#define gamma_PCI_IDS \
- {0x3d3d, 0x0008, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, \
- {0, 0, 0}
-
#define savage_PCI_IDS \
{0x5333, 0x8a20, PCI_ANY_ID, PCI_ANY_ID, 0, 0, S3_SAVAGE3D}, \
{0x5333, 0x8a21, PCI_ANY_ID, PCI_ANY_ID, 0, 0, S3_SAVAGE3D}, \
@@ -781,6 +754,3 @@
{0x5333, 0x8d03, PCI_ANY_ID, PCI_ANY_ID, 0, 0, S3_PROSAVAGEDDR}, \
{0x5333, 0x8d04, PCI_ANY_ID, PCI_ANY_ID, 0, 0, S3_PROSAVAGEDDR}, \
{0, 0, 0}
-
-#define ffb_PCI_IDS \
- {0, 0, 0}
--
1.8.3.1
[PATCH 8/8] drm: Make drm_get_platform_dev() static
It's only used in drm_platform.c.
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/drm_platform.c | 7 +++
include/drm/drmP.h | 3 ---
2 files changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/drm_platform.c b/drivers/gpu/drm/drm_platform.c
index b8a282e..400024b 100644
--- a/drivers/gpu/drm/drm_platform.c
+++ b/drivers/gpu/drm/drm_platform.c
@@ -28,7 +28,7 @@
#include
#include
-/**
+/*
* Register.
*
* \param platdev - Platform device struture
@@ -39,8 +39,8 @@
* Try and register, if we fail to register, backout previous work.
*/
-int drm_get_platform_dev(struct platform_device *platdev,
-struct drm_driver *driver)
+static int drm_get_platform_dev(struct platform_device *platdev,
+ struct drm_driver *driver)
{
struct drm_device *dev;
int ret;
@@ -107,7 +107,6 @@ err_g1:
mutex_unlock(&drm_global_mutex);
return ret;
}
-EXPORT_SYMBOL(drm_get_platform_dev);
static int drm_platform_get_irq(struct drm_device *dev)
{
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 046a7db..1a7a78f 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -1657,9 +1657,6 @@ extern int drm_pcie_get_speed_cap_mask(struct drm_device
*dev, u32 *speed_mask);
extern int drm_platform_init(struct drm_driver *driver, struct platform_device
*platform_device);
extern void drm_platform_exit(struct drm_driver *driver, struct
platform_device *platform_device);
-extern int drm_get_platform_dev(struct platform_device *pdev,
- struct drm_driver *driver);
-
/* returns true if currently okay to sleep */
static __inline__ bool drm_can_sleep(void)
{
--
1.8.3.1
[Bug 60674] linux 3.10.x RV740 (Radeon HD 4770) display problem
https://bugzilla.kernel.org/show_bug.cgi?id=60674 --- Comment #14 from Dave --- (In reply to Michel D?nzer from comment #13) Michel you could well be 100% right. I'll simply add, RV350 failures should emit X log outputs, not X crashes or worse, hardware/driver/kernel crashes. Code should fail gracefully. We see screenshots like others here, whatever our issue. People reporting use glamor. I got here googling for it. The patch offered struck me as specific to one Radeon GPU. Logic which needs patching for one GPU may need it for others. If not then such specificity needs more code comments, perhaps. I'm unaquainted with the code base. Thanks. -- You are receiving this mail because: You are watching the assignee of the bug.
[PULL] drm-intel-next
Hi Dave, New pile of stuff for -next: - Cleanup of the old crtc helper callbacks, all encoders are now converted to the i915 modeset infrastructure. - Massive amount of wm patches from Ville for ilk, snb, ivb, hsw, this is prep work to eventually get things going for nuclear pageflips where we need to adjust watermarks on the fly. - More vm/vma patches from Ben. This refactoring isn't yet fully rolled out, we miss the execbuf conversion and some of the low-level bind/unbind support code. - Convert our hdmi infoframe code to use the new common helper functions (Damien). This contains some bugfixes for the common infoframe helpers. - Some cruft removal from Damien. - Various smaller bits&pieces all over, as usual. Cheers, Daniel The following changes since commit cd234b0bfd5ab012e42274b24aae420fa1823d58: drm/i915: Do not dereference NULL crtc or fb until after checking (2013-08-04 21:13:43 +0200) are available in the git repository at: git://people.freedesktop.org/~danvet/drm-intel tags/drm-intel-next-2013-08-09 for you to fetch changes up to 5c536613d8ebda3da0448550d0a997651a6048e2: drm/i915: Fix FB WM for HSW (2013-08-09 20:27:43 +0200) Ben Widawsky (22): drm/i915/hsw: Change default LLC age to 3 drm/i915: Create an init vm drm/i915: Rework drop caches for checkpatch drm/i915: Make proper functions for VMs drm/i915: Use bound list for inactive shrink drm/i915: Add VM to pin drm/i915: Use ggtt_vm to save some typing drm/i915: Update describe_obj drm/i915: thread address space through execbuf drm/i915: make caching operate on all address spaces drm/i915: BUG_ON put_pages later drm/i915: make reset&hangcheck code VM aware drm/i915: eliminate dead domain clearing on reset drm/i915: Improve VMA comments drm/i915: Rework __i915_gem_shrink drm/i915: plumb VM into bind/unbind code drm/i915: Use new bind/unbind in eviction code drm/i915: turn bound_ggtt checks to bound_any drm/i915: Fix up map and fenceable for VMA drm/i915: mm_list is per VMA drm/i915: Update error capture for VMs drm/i915: Add vma to list at creation Chris Wilson (7): drm/i915: Squelch repeated reasoning for why FBC cannot be activated drm/i915: Use the same pte_encoding for ppgtt as for gtt drm/i915: Tidy the macro casting by using an inline function drm/i915: Acquire dpio_lock for VLV sideband programming in DP/HDMI drm/i915: Rename I915_CACHE_MLC_LLC to L3_LLC for Ivybridge drm/i915: Export intel_framebuffer_fini drm/i915: List objects allocated from stolen memory in debugfs Damien Lespiau (19): video/hdmi: Replace the payload length by their defines video/hdmi: Introduce a generic hdmi_infoframe union video/hdmi: Add a macro to return the size of a full infoframe video/hmdi: Clear the whole incoming buffer, not just the infoframe size drm: Don't generate invalid AVI infoframes for CEA modes drm/i915/hdmi: Change the write_infoframe vfunc to take a buffer and a type drm/i915/hdmi: Port the infoframe code to the common hdmi helpers drm/i915/sdvo: Port the infoframe code to the shared infrastructure drm/i915: Remove the now obsolete infoframe definitions drm: Handle the DBLCLK flag in the common infoframe helper drm: Set aspect ratio fields in the AVI infoframe even for non CEA modes drm/i915/hmdi: Rename set_infoframe() to write_infoframe() drm/i915: Remove stale prototypes drm/i915: Remove i915_gem_object_check_coherency() drm/i915: Fix #endif comment drm/i915: Make i915_hangcheck_elapsed() static drm/i915: Make intel_encoder_dpms() static drm/i915: Remove intel_modeset_disable() drm/i915: Make intel_set_mode() static Dan Carpenter (2): drm/i915: unbreak i915_gem_object_ggtt_unbind() drm/i915: fix a limit check in hsw_compute_wm_results() Daniel Vetter (13): drm/i915/dvo: use intel_encoder to the upcast macro drm/i915/dvo: switch ->mode_fixup to ->compute_config drm/i915: rip out legacy encoder->mode_fixup logic drm/i915/dvo: use native encoder ->mode_set callback drm/i915/sdvo: use intel_encoder for upcast helper drm/i915/tv: Use native encoder->mode_set callback drm/i915/crt: use native encoder->mode_set callback drm/i915/hdmi: use native encoder mode_set callback drm/i915/dp: use native encoder ->mode_set callback drm/i915/lvds: use the native encoder ->mode_set callback drm/i915/ddi: use the native encoder ->mode_set callback drm/i915: rip out legacy encoder->mode_set callback drm/i915: clean up crtc timings computation Imre Deak (1): drm/i915: make user mode sync polarity setting explicit Jani Nikula (3): drm/i915: rearrange vlv dp enable and pre_enable cal
[PATCH 0/2] update pixel format setting to fimd driver
This patch series fix pixel format setting according to drm_framebuffer's pixel_format, and check if a given window supports alpha channel or not. Inki Dae (2): drm/exynos: fix fimd pixel format setting drm/exynos: check a pixel format to a particular window layer drivers/gpu/drm/exynos/exynos_drm_fimd.c | 45 -- 1 files changed, 24 insertions(+), 21 deletions(-) -- 1.7.5.4
[PATCH 2/2] drm/exynos: check a pixel format to a particular window layer
This patch checks if a requested window supports alpha channel or not.
In case of s3c64xx, window 0 doesn't support alpha channel so if
the request pixel format is ARGB then change it to XRGB.
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 13d5afb..f8889d2 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -66,11 +66,13 @@ struct fimd_driver_data {
unsigned int has_shadowcon:1;
unsigned int has_clksel:1;
+ unsigned int has_limited_fmt:1;
};
static struct fimd_driver_data s3c64xx_fimd_driver_data = {
.timing_base = 0x0,
.has_clksel = 1,
+ .has_limited_fmt = 1,
};
static struct fimd_driver_data exynos4_fimd_driver_data = {
@@ -420,6 +422,15 @@ static void fimd_win_set_pixfmt(struct device *dev,
unsigned int win)
val = WINCONx_ENWIN;
+ /*
+* In case of s3c64xx, window 0 doesn't support alpha channel.
+* So the request format is ARGB then change it to XRGB.
+*/
+ if (ctx->driver_data->has_limited_fmt && !win) {
+ if (win_data->pixel_format == DRM_FORMAT_ARGB)
+ win_data->pixel_format = DRM_FORMAT_XRGB;
+ }
+
switch (win_data->pixel_format) {
case DRM_FORMAT_C8:
val |= WINCON0_BPPMODE_8BPP_PALETTE;
--
1.7.5.4
[PATCH 1/2] drm/exynos: fix fimd pixel format setting
This patch fixes wrong pixel format setting.
A pixel format is decided according to bpp and depth, or user-requested
format but fimd driver considered only bpp value to decide a proper pixel
format. So this patch makes a proper pixel format to be set according
to drm_framebuffer's pixel_format which is set by addfb with bpp and
depth, or addfb2 with user-requested format.
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 34 +++--
1 files changed, 13 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index b8aa8fe..13d5afb 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -91,6 +91,7 @@ struct fimd_win_data {
unsigned intfb_width;
unsigned intfb_height;
unsigned intbpp;
+ unsigned intpixel_format;
dma_addr_t dma_addr;
unsigned intbuf_offsize;
unsigned intline_size; /* bytes */
@@ -397,6 +398,7 @@ static void fimd_win_mode_set(struct device *dev,
win_data->fb_height = overlay->fb_height;
win_data->dma_addr = overlay->dma_addr[0] + offset;
win_data->bpp = overlay->bpp;
+ win_data->pixel_format = overlay->pixel_format;
win_data->buf_offsize = (overlay->fb_width - overlay->crtc_width) *
(overlay->bpp >> 3);
win_data->line_size = overlay->crtc_width * (overlay->bpp >> 3);
@@ -418,39 +420,29 @@ static void fimd_win_set_pixfmt(struct device *dev,
unsigned int win)
val = WINCONx_ENWIN;
- switch (win_data->bpp) {
- case 1:
- val |= WINCON0_BPPMODE_1BPP;
- val |= WINCONx_BITSWP;
- val |= WINCONx_BURSTLEN_4WORD;
- break;
- case 2:
- val |= WINCON0_BPPMODE_2BPP;
- val |= WINCONx_BITSWP;
- val |= WINCONx_BURSTLEN_8WORD;
- break;
- case 4:
- val |= WINCON0_BPPMODE_4BPP;
- val |= WINCONx_BITSWP;
- val |= WINCONx_BURSTLEN_8WORD;
- break;
- case 8:
+ switch (win_data->pixel_format) {
+ case DRM_FORMAT_C8:
val |= WINCON0_BPPMODE_8BPP_PALETTE;
val |= WINCONx_BURSTLEN_8WORD;
val |= WINCONx_BYTSWP;
break;
- case 16:
+ case DRM_FORMAT_XRGB1555:
+ val |= WINCON0_BPPMODE_16BPP_1555;
+ val |= WINCONx_HAWSWP;
+ val |= WINCONx_BURSTLEN_16WORD;
+ break;
+ case DRM_FORMAT_RGB565:
val |= WINCON0_BPPMODE_16BPP_565;
val |= WINCONx_HAWSWP;
val |= WINCONx_BURSTLEN_16WORD;
break;
- case 24:
+ case DRM_FORMAT_XRGB:
val |= WINCON0_BPPMODE_24BPP_888;
val |= WINCONx_WSWP;
val |= WINCONx_BURSTLEN_16WORD;
break;
- case 32:
- val |= WINCON1_BPPMODE_28BPP_A4888
+ case DRM_FORMAT_ARGB:
+ val |= WINCON1_BPPMODE_25BPP_A1888
| WINCON1_BLD_PIX | WINCON1_ALPHA_SEL;
val |= WINCONx_WSWP;
val |= WINCONx_BURSTLEN_16WORD;
--
1.7.5.4
[RFC PATCH] drm/radeon: rework to new fence interface
Am 19.08.2013 21:37, schrieb Maarten Lankhorst:
> Op 19-08-13 14:35, Christian K?nig schreef:
>> Am 19.08.2013 12:17, schrieb Maarten Lankhorst:
>>> [SNIP]
>>> @@ -190,25 +225,24 @@ void radeon_fence_process(struct radeon_device *rdev,
>>> int ring)
>>>}
>>>} while (atomic64_xchg(&rdev->fence_drv[ring].last_seq, seq) > seq);
>>>-if (wake) {
>>> +if (wake)
>>>rdev->fence_drv[ring].last_activity = jiffies;
>>> -wake_up_all(&rdev->fence_queue);
>>> -}
>>> +return wake;
>>>}
>> Very bad idea, when sequence numbers change, you always want to wake up the
>> whole fence queue here.
> Yes, and the callers of this function call wake_up_all or wake_up_all_locked
> themselves, based on the return value..
And as I said that's a very bad idea. The fence processing shouldn't be
called with any locks held and should be self responsible for activating
any waiters.
>
>>> [SNIP]
>>> +/**
>>> + * radeon_fence_enable_signaling - enable signalling on fence
>>> + * @fence: fence
>>> + *
>>> + * This function is called with fence_queue lock held, and adds a callback
>>> + * to fence_queue that checks if this fence is signaled, and if so it
>>> + * signals the fence and removes itself.
>>> + */
>>> +static bool radeon_fence_enable_signaling(struct fence *f)
>>> +{
>>> +struct radeon_fence *fence = to_radeon_fence(f);
>>> +
>>> +if (atomic64_read(&fence->rdev->fence_drv[fence->ring].last_seq) >=
>>> fence->seq ||
>>> +!fence->rdev->ddev->irq_enabled)
>>> +return false;
>>> +
>> Do I get that right that you rely on IRQs to be enabled and working here?
>> Cause that would be a quite bad idea from the conceptual side.
> For cross-device synchronization it would be nice to have working irqs, it
> allows signalling fences faster,
> and it allows for callbacks on completion to be called. For internal usage
> it's no more required than it was before.
That's a big NAK.
The fence processing is actually very fine tuned to avoid IRQs and as
far as I can see you just leave them enabled by decrementing the atomic
from IRQ context. Additional to that we need allot of special handling
in case of a hardware lockup here, which isn't done if you abuse the
fence interface like this.
Also your approach of leaking the IRQ context outside of the driver is a
very bad idea from the conceptual side. Please don't modify the fence
interface at all and instead use the wait functions already exposed by
radeon_fence.c. If you need some kind of signaling mechanism then wait
inside a workqueue instead.
Christian.
[PATCH 0/3] refactor some ldb related clocks
The ldb_di[0/1]_ipu_div clock dividers in the CSCMR2 register of i.MX53, i.MX6Q and i.MX6DL SoCs can be configured to a 1/3.5 drivider or a 1/7 divider. The common clock framework cannot deal with the two dividers directly even with the divider table which only supports integral dividers. So, the idea is to take the 1/3.5 and 1/7 dividers as separate fixed factor dividers and introduce a new multiplexer clock to be derived from the them. Then, the ldb display clock trees can be setup correctly. This series contains the necessary clock driver changes, dts code changes and imx-drm/ldb driver changes to fullfill the task. Liu Ying (3): ARM: imx6q: refactor some ldb related clocks ARM: dts: imx6q/imx6dl: add necessary clocks for ldb node staging: drm/imx: ldb: correct the ldb di clock trees .../devicetree/bindings/clock/imx6q-clock.txt |6 ++-- arch/arm/boot/dts/imx6dl.dtsi |8 +++-- arch/arm/boot/dts/imx6q.dtsi |8 +++-- arch/arm/mach-imx/clk-imx6q.c | 25 +++-- drivers/staging/imx-drm/imx-ldb.c | 38 +++- 5 files changed, 61 insertions(+), 24 deletions(-) -- 1.7.9.5
[PATCH 1/3] ARM: imx6q: refactor some ldb related clocks
The ldb_di[0/1]_ipu_div dividers may divide their parent clock
frequencies by either 3.5 or 7. The non-integral dividers cannot
be dealt with the common clock framework directly, so they cannot
be registered as common clock dividers. So this patch adds a fixed
factor clock of 1/7 and introduces ldb_di[0/1]_div_sel multiplexers
so that the fixed factor clocks of 1/3.5 and 1/7 can be set to be
the parents of ldb_di[0/1]_div_sel multiplexers. The ldb_di[0/1]_podf
dividers are no longer used then.
Signed-off-by: Liu Ying
---
.../devicetree/bindings/clock/imx6q-clock.txt |6 +++--
arch/arm/mach-imx/clk-imx6q.c | 25
2 files changed, 19 insertions(+), 12 deletions(-)
diff --git a/Documentation/devicetree/bindings/clock/imx6q-clock.txt
b/Documentation/devicetree/bindings/clock/imx6q-clock.txt
index 5a90a72..90e923e 100644
--- a/Documentation/devicetree/bindings/clock/imx6q-clock.txt
+++ b/Documentation/devicetree/bindings/clock/imx6q-clock.txt
@@ -89,8 +89,6 @@ clocks and IDs.
gpu3d_shader74
ipu1_podf 75
ipu2_podf 76
- ldb_di0_podf77
- ldb_di1_podf78
ipu1_di0_pre79
ipu1_di1_pre80
ipu2_di0_pre81
@@ -215,6 +213,10 @@ clocks and IDs.
cko2200
cko 201
vdoa202
+ ldb_di0_div_7 203
+ ldb_di1_div_7 204
+ ldb_di0_div_sel 205
+ ldb_di1_div_sel 206
Examples:
diff --git a/arch/arm/mach-imx/clk-imx6q.c b/arch/arm/mach-imx/clk-imx6q.c
index 9181a24..2b5be96 100644
--- a/arch/arm/mach-imx/clk-imx6q.c
+++ b/arch/arm/mach-imx/clk-imx6q.c
@@ -189,6 +189,8 @@ static const char *gpu3d_core_sels[]= {
"mmdc_ch0_axi", "pll3_usb_otg", "pll2_p
static const char *gpu3d_shader_sels[] = { "mmdc_ch0_axi", "pll3_usb_otg",
"pll2_pfd1_594m", "pll3_pfd0_720m", };
static const char *ipu_sels[] = { "mmdc_ch0_axi", "pll2_pfd2_396m",
"pll3_120m", "pll3_pfd1_540m", };
static const char *ldb_di_sels[] = { "pll5_video_div", "pll2_pfd0_352m",
"pll2_pfd2_396m", "mmdc_ch1_axi", "pll3_usb_otg", };
+static const char *ldb_di0_div_sels[] = { "ldb_di0_div_3_5", "ldb_di0_div_7",
};
+static const char *ldb_di1_div_sels[] = { "ldb_di1_div_3_5", "ldb_di1_div_7",
};
static const char *ipu_di_pre_sels[] = { "mmdc_ch0_axi", "pll3_usb_otg",
"pll5_video_div", "pll2_pfd0_352m", "pll2_pfd2_396m", "pll3_pfd1_540m", };
static const char *ipu1_di0_sels[] = { "ipu1_di0_pre", "dummy", "dummy",
"ldb_di0", "ldb_di1", };
static const char *ipu1_di1_sels[] = { "ipu1_di1_pre", "dummy", "dummy",
"ldb_di0", "ldb_di1", };
@@ -233,11 +235,11 @@ enum mx6q_clks {
periph_clk2, periph2_clk2, ipg, ipg_per, esai_pred, esai_podf,
asrc_pred, asrc_podf, spdif_pred, spdif_podf, can_root, ecspi_root,
gpu2d_core_podf, gpu3d_core_podf, gpu3d_shader, ipu1_podf, ipu2_podf,
- ldb_di0_podf, ldb_di1_podf, ipu1_di0_pre, ipu1_di1_pre, ipu2_di0_pre,
- ipu2_di1_pre, hsi_tx_podf, ssi1_pred, ssi1_podf, ssi2_pred, ssi2_podf,
- ssi3_pred, ssi3_podf, uart_serial_podf, usdhc1_podf, usdhc2_podf,
- usdhc3_podf, usdhc4_podf, enfc_pred, enfc_podf, emi_podf,
- emi_slow_podf, vpu_axi_podf, cko1_podf, axi, mmdc_ch0_axi_podf,
+ ldb_di0_podf_unused, ldb_di1_podf_unused, ipu1_di0_pre, ipu1_di1_pre,
+ ipu2_di0_pre, ipu2_di1_pre, hsi_tx_podf, ssi1_pred, ssi1_podf,
+ ssi2_pred, ssi2_podf, ssi3_pred, ssi3_podf, uart_serial_podf,
+ usdhc1_podf, usdhc2_podf, usdhc3_podf, usdhc4_podf, enfc_pred,
enfc_podf,
+ emi_podf, emi_slow_podf, vpu_axi_podf, cko1_podf, axi,
mmdc_ch0_axi_podf,
mmdc_ch1_axi_podf, arm, ahb, apbh_dma, asrc, can1_ipg, can1_serial,
can2_ipg, can2_serial, ecspi1, ecspi2, ecspi3, ecspi4, ecspi5, enet,
esai, gpt_ipg, gpt_ipg_per, gpu2d_core, gpu3d_core, hdmi_iahb,
@@ -251,7 +253,8 @@ enum mx6q_clks {
ssi2_ipg, ssi3_ipg, rom, usbphy1, usbphy2, ldb_di0_div_3_5,
ldb_di1_div_3_5,
sata_ref, sata_ref_100m, pcie_ref, pcie_ref_125m, enet_ref,
usbphy1_gate,
usbphy2_gate, pll4_post_div, pll5_post_div, pll5_video_div, eim_slow,
- spdif, cko2_sel, cko2_podf, cko2, cko, vdoa, clk_max
+ spdif, cko2_sel, cko2_podf, cko2, cko, vdoa, ldb_di0_div_7,
ldb_di1_div_7,
+ ldb_di0_div_sel, ldb_di1_div_sel, clk_max
};
static struct clk *clk[clk_max];
@@ -387,6 +390,8 @@ static void __init imx6q_clocks_init(struct device_node
*ccm_node)
clk[ipu2_sel] = imx_clk_mux("ipu2_sel", base + 0x3c,
14, 2, ipu_sels, ARRAY_SIZE(ipu_sels));
clk[ldb_di0_sel] = imx_clk_mux_flags("ldb_di0_sel", base + 0x2c,
9, 3, ldb_di_sels, ARRAY_SIZE(ldb_di_sels), CLK_SET_RATE_PARENT);
clk[ldb_di1_sel] = imx_clk_mux_flags("ldb_di1_sel", base +
[PATCH 2/3] ARM: dts: imx6q/imx6dl: add necessary clocks for ldb node
This patch adds di[0/1]_div_3_5, di[0/1]_div_7 and di[0/1]_div_sel
clocks to the ldb nodes so that the ldb driver may use them to
setup the display clock trees.
Signed-off-by: Liu Ying
---
arch/arm/boot/dts/imx6dl.dtsi |8 ++--
arch/arm/boot/dts/imx6q.dtsi |8 ++--
2 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/imx6dl.dtsi b/arch/arm/boot/dts/imx6dl.dtsi
index 9e8ae11..ff0d743 100644
--- a/arch/arm/boot/dts/imx6dl.dtsi
+++ b/arch/arm/boot/dts/imx6dl.dtsi
@@ -75,10 +75,14 @@
&ldb {
clocks = <&clks 33>, <&clks 34>,
<&clks 39>, <&clks 40>,
-<&clks 135>, <&clks 136>;
+<&clks 135>, <&clks 136>,
+<&clks 184>, <&clks 185>, <&clks 203>, <&clks 204>,
+<&clks 205>, <&clks 206>;
clock-names = "di0_pll", "di1_pll",
"di0_sel", "di1_sel",
- "di0", "di1";
+ "di0", "di1",
+ "di0_div_3_5", "di1_div_3_5", "di0_div_7", "di1_div_7",
+ "di0_div_sel", "di1_div_sel";
lvds-channel at 0 {
crtcs = <&ipu1 0>, <&ipu1 1>;
diff --git a/arch/arm/boot/dts/imx6q.dtsi b/arch/arm/boot/dts/imx6q.dtsi
index f024ef2..b078a42 100644
--- a/arch/arm/boot/dts/imx6q.dtsi
+++ b/arch/arm/boot/dts/imx6q.dtsi
@@ -146,10 +146,14 @@
&ldb {
clocks = <&clks 33>, <&clks 34>,
<&clks 39>, <&clks 40>, <&clks 41>, <&clks 42>,
-<&clks 135>, <&clks 136>;
+<&clks 135>, <&clks 136>,
+<&clks 184>, <&clks 185>, <&clks 203>, <&clks 204>,
+<&clks 205>, <&clks 206>;
clock-names = "di0_pll", "di1_pll",
"di0_sel", "di1_sel", "di2_sel", "di3_sel",
- "di0", "di1";
+ "di0", "di1",
+ "di0_div_3_5", "di1_div_3_5", "di0_div_7", "di1_div_7",
+ "di0_div_sel", "di1_div_sel";
lvds-channel at 0 {
crtcs = <&ipu1 0>, <&ipu1 1>, <&ipu2 0>, <&ipu2 1>;
--
1.7.9.5
[PATCH 3/3] staging: drm/imx: ldb: correct the ldb di clock trees
In ldb split mode, the ldb_di[0/1]_ipu_div dividers should
be configured as clock dividers of 1/3.5, while in others
ldb modes of 1/7. This patch gets the di[0/1]_div_3_5,
di[0/1]_div_7 and di[0/1]_div_sel clocks and sets the
di[0/1]_div_3_5 or di[0/1]_div_7 clocks to be the parents of
di[0/1]_div_sel clocks according to the ldb mode. The real
dividers are the two fixed factors bewteen the ldb_di[0/1] and
the pll clocks, so it's unnecessary to set the frequency for
the ldb_di[0/1] clocks again after pll clock frequency is set.
This patch removes the redundant clock frequency setting code
as well.
Signed-off-by: Liu Ying
---
drivers/staging/imx-drm/imx-ldb.c | 38 +
1 file changed, 30 insertions(+), 8 deletions(-)
diff --git a/drivers/staging/imx-drm/imx-ldb.c
b/drivers/staging/imx-drm/imx-ldb.c
index 8af7f3b..7c553b8 100644
--- a/drivers/staging/imx-drm/imx-ldb.c
+++ b/drivers/staging/imx-drm/imx-ldb.c
@@ -81,6 +81,9 @@ struct imx_ldb {
struct clk *clk[2]; /* our own clock */
struct clk *clk_sel[4]; /* parent of display clock */
struct clk *clk_pll[2]; /* upstream clock we can adjust */
+ struct clk *clk_div_3_5[2]; /* fixed factor of 1/3.5 */
+ struct clk *clk_div_7[2]; /* fixed factor of 1/7 */
+ struct clk *clk_div_sel[2]; /* 1/3.5 or 1/7 */
u32 ldb_ctrl;
const struct bus_mux *lvds_mux;
};
@@ -150,6 +153,18 @@ static void imx_ldb_set_clock(struct imx_ldb *ldb, int
mux, int chno,
{
int ret;
+ if (ldb->ldb_ctrl & LDB_SPLIT_MODE_EN) {
+ ret = clk_set_parent(ldb->clk_div_sel[chno],
ldb->clk_div_3_5[chno]);
+ if (ret)
+ dev_err(ldb->dev, "unable to set di%d_div_sel parent
clock "
+ "to di%d_div_3_5\n", chno, chno);
+ } else {
+ ret = clk_set_parent(ldb->clk_div_sel[chno],
ldb->clk_div_7[chno]);
+ if (ret)
+ dev_err(ldb->dev, "unable to set di%d_div_sel parent
clock "
+ "to di%d_div_7\n", chno, chno);
+ }
+
dev_dbg(ldb->dev, "%s: now: %ld want: %ld\n", __func__,
clk_get_rate(ldb->clk_pll[chno]), serial_clk);
clk_set_rate(ldb->clk_pll[chno], serial_clk);
@@ -157,14 +172,6 @@ static void imx_ldb_set_clock(struct imx_ldb *ldb, int
mux, int chno,
dev_dbg(ldb->dev, "%s after: %ld\n", __func__,
clk_get_rate(ldb->clk_pll[chno]));
- dev_dbg(ldb->dev, "%s: now: %ld want: %ld\n", __func__,
- clk_get_rate(ldb->clk[chno]),
- (long int)di_clk);
- clk_set_rate(ldb->clk[chno], di_clk);
-
- dev_dbg(ldb->dev, "%s after: %ld\n", __func__,
- clk_get_rate(ldb->clk[chno]));
-
/* set display clock mux to LDB input clock */
ret = clk_set_parent(ldb->clk_sel[mux], ldb->clk[chno]);
if (ret) {
@@ -362,6 +369,21 @@ static int imx_ldb_get_clk(struct imx_ldb *ldb, int chno)
if (IS_ERR(ldb->clk_pll[chno]))
return PTR_ERR(ldb->clk_pll[chno]);
+ sprintf(clkname, "di%d_div_3_5", chno);
+ ldb->clk_div_3_5[chno] = devm_clk_get(ldb->dev, clkname);
+ if (IS_ERR(ldb->clk_div_3_5[chno]))
+ return PTR_ERR(ldb->clk_div_3_5[chno]);
+
+ sprintf(clkname, "di%d_div_7", chno);
+ ldb->clk_div_7[chno] = devm_clk_get(ldb->dev, clkname);
+ if (IS_ERR(ldb->clk_div_7[chno]))
+ return PTR_ERR(ldb->clk_div_7[chno]);
+
+ sprintf(clkname, "di%d_div_sel", chno);
+ ldb->clk_div_sel[chno] = devm_clk_get(ldb->dev, clkname);
+ if (IS_ERR(ldb->clk_div_sel[chno]))
+ return PTR_ERR(ldb->clk_div_sel[chno]);
+
return 0;
}
--
1.7.9.5
[RFC PATCH] drm/radeon: rework to new fence interface
Op 20-08-13 10:37, Christian K?nig schreef:
> Am 19.08.2013 21:37, schrieb Maarten Lankhorst:
>> Op 19-08-13 14:35, Christian K?nig schreef:
>>> Am 19.08.2013 12:17, schrieb Maarten Lankhorst:
[SNIP]
@@ -190,25 +225,24 @@ void radeon_fence_process(struct radeon_device
*rdev, int ring)
}
} while (atomic64_xchg(&rdev->fence_drv[ring].last_seq, seq) > seq);
-if (wake) {
+if (wake)
rdev->fence_drv[ring].last_activity = jiffies;
-wake_up_all(&rdev->fence_queue);
-}
+return wake;
}
>>> Very bad idea, when sequence numbers change, you always want to wake up the
>>> whole fence queue here.
>> Yes, and the callers of this function call wake_up_all or wake_up_all_locked
>> themselves, based on the return value..
>
> And as I said that's a very bad idea. The fence processing shouldn't be
> called with any locks held and should be self responsible for activating any
> waiters.
The call point (enable_signaling) only needs to know whether its own counter
has passed or not. This prevents the race where the counter
has elapsed, but the irq was not yet enabled.
I don't really care if enable_signaling updates last_seq or not, it only needs
to check if it's own fence has been signaled after enabling sw_irqs.
>>
[SNIP]
+/**
+ * radeon_fence_enable_signaling - enable signalling on fence
+ * @fence: fence
+ *
+ * This function is called with fence_queue lock held, and adds a callback
+ * to fence_queue that checks if this fence is signaled, and if so it
+ * signals the fence and removes itself.
+ */
+static bool radeon_fence_enable_signaling(struct fence *f)
+{
+struct radeon_fence *fence = to_radeon_fence(f);
+
+if (atomic64_read(&fence->rdev->fence_drv[fence->ring].last_seq) >=
fence->seq ||
+!fence->rdev->ddev->irq_enabled)
+return false;
+
>>> Do I get that right that you rely on IRQs to be enabled and working here?
>>> Cause that would be a quite bad idea from the conceptual side.
>> For cross-device synchronization it would be nice to have working irqs, it
>> allows signalling fences faster,
>> and it allows for callbacks on completion to be called. For internal usage
>> it's no more required than it was before.
>
> That's a big NAK.
>
> The fence processing is actually very fine tuned to avoid IRQs and as far as
> I can see you just leave them enabled by decrementing the atomic from IRQ
> context. Additional to that we need allot of special handling in case of a
> hardware lockup here, which isn't done if you abuse the fence interface like
> this.
I think it's not needed to leave the irq enabled, it's a leftover from when I
was debugging the mac and no interrupt occurred at all.
> Also your approach of leaking the IRQ context outside of the driver is a very
> bad idea from the conceptual side. Please don't modify the fence interface at
> all and instead use the wait functions already exposed by radeon_fence.c. If
> you need some kind of signaling mechanism then wait inside a workqueue
> instead.
The fence takes up the role of a single shot workqueue here. Manually resetting
the counter and calling wake_up_all would end up waking all active fences,
there's no special handling needed inside radeon for this.
The fence api does provide a synchronous wait function, but this causes a stall
of whomever waits on it. When I was testing this with intel I used the fence
callback to poke a register in i915, this allowed it to not block until it hits
the wait op in the command stream, and even then only if the callback was not
called first.
It's documented that the callbacks can be called from any context and will be
called with irqs disabled, so nothing scary should be done. The kernel provides
enough debug mechanisms to find any violators.
PROVE_LOCKING and DEBUG_ATOMIC_SLEEP for example.
~Maarten
[PATCH 0/3] refactor some ldb related clocks
Am Dienstag, den 20.08.2013, 16:38 +0800 schrieb Liu Ying: > The ldb_di[0/1]_ipu_div clock dividers in the CSCMR2 register > of i.MX53, i.MX6Q and i.MX6DL SoCs can be configured to a 1/3.5 > drivider or a 1/7 divider. The common clock framework cannot > deal with the two dividers directly even with the divider table > which only supports integral dividers. So, the idea is to take > the 1/3.5 and 1/7 dividers as separate fixed factor dividers and > introduce a new multiplexer clock to be derived from the them. > Then, the ldb display clock trees can be setup correctly. > This series contains the necessary clock driver changes, dts code > changes and imx-drm/ldb driver changes to fullfill the task. I don't see how this improves the situation. Does this solve any real problem? While I admit to having introduced the combination of 1/3.5 fixed divider and configurable 1/1,1/2 divder clocks to describe this fractional divider for the reasons you state, I think the correct solution would be to improve the table divider to support fractional values and get rid of the virtual ldb_di_div_3_5 clocks, not introduce more virtual clocks. regards Philipp
[RFC PATCH] drm/radeon: rework to new fence interface
Am 20.08.2013 11:36, schrieb Maarten Lankhorst:
[SNIP]
> [SNIP]
> +/**
> + * radeon_fence_enable_signaling - enable signalling on fence
> + * @fence: fence
> + *
> + * This function is called with fence_queue lock held, and adds a
> callback
> + * to fence_queue that checks if this fence is signaled, and if so it
> + * signals the fence and removes itself.
> + */
> +static bool radeon_fence_enable_signaling(struct fence *f)
> +{
> +struct radeon_fence *fence = to_radeon_fence(f);
> +
> +if (atomic64_read(&fence->rdev->fence_drv[fence->ring].last_seq) >=
> fence->seq ||
> +!fence->rdev->ddev->irq_enabled)
> +return false;
> +
Do I get that right that you rely on IRQs to be enabled and working here?
Cause that would be a quite bad idea from the conceptual side.
>>> For cross-device synchronization it would be nice to have working irqs, it
>>> allows signalling fences faster,
>>> and it allows for callbacks on completion to be called. For internal usage
>>> it's no more required than it was before.
>> That's a big NAK.
>>
>> The fence processing is actually very fine tuned to avoid IRQs and as far as
>> I can see you just leave them enabled by decrementing the atomic from IRQ
>> context. Additional to that we need allot of special handling in case of a
>> hardware lockup here, which isn't done if you abuse the fence interface like
>> this.
> I think it's not needed to leave the irq enabled, it's a leftover from when I
> was debugging the mac and no interrupt occurred at all.
>
>> Also your approach of leaking the IRQ context outside of the driver is a
>> very bad idea from the conceptual side. Please don't modify the fence
>> interface at all and instead use the wait functions already exposed by
>> radeon_fence.c. If you need some kind of signaling mechanism then wait
>> inside a workqueue instead.
> The fence takes up the role of a single shot workqueue here. Manually
> resetting the counter and calling wake_up_all would end up waking all active
> fences, there's no special handling needed inside radeon for this.
Yeah that's actually the point here, you NEED to activate ALL fences,
otherwise the fence handling inside the driver won't work.
> The fence api does provide a synchronous wait function, but this causes a
> stall of whomever waits on it.
Which is perfectly fine. What actually is the use case of not stalling a
process who wants to wait for something?
> When I was testing this with intel I used the fence callback to poke a
> register in i915, this allowed it to not block until it hits the wait op in
> the command stream, and even then only if the callback was not called first.
>
> It's documented that the callbacks can be called from any context and will be
> called with irqs disabled, so nothing scary should be done. The kernel
> provides enough debug mechanisms to find any violators.
> PROVE_LOCKING and DEBUG_ATOMIC_SLEEP for example.
No thanks, we even abandoned that concept internal in the driver. Please
use the blocking wait functions instead.
Christian.
[PATCH 0/3] refactor some ldb related clocks
On 08/20/2013 05:43 PM, Philipp Zabel wrote: > Am Dienstag, den 20.08.2013, 16:38 +0800 schrieb Liu Ying: >> The ldb_di[0/1]_ipu_div clock dividers in the CSCMR2 register >> of i.MX53, i.MX6Q and i.MX6DL SoCs can be configured to a 1/3.5 >> drivider or a 1/7 divider. The common clock framework cannot >> deal with the two dividers directly even with the divider table >> which only supports integral dividers. So, the idea is to take >> the 1/3.5 and 1/7 dividers as separate fixed factor dividers and >> introduce a new multiplexer clock to be derived from the them. >> Then, the ldb display clock trees can be setup correctly. >> This series contains the necessary clock driver changes, dts code >> changes and imx-drm/ldb driver changes to fullfill the task. > > I don't see how this improves the situation. Does this solve any real > problem? > I don't see any functional problem without this series. But, it may correct ldb_di[n] clock frequency returned from clk_get_rate() when using 1/7 divider. Furthermore, since this series makes the ldb related clocks from pll to ldb_di[0/1] have the CLK_SET_RATE_PARENT flag set, the imx-drm/ldb driver may set the clocks' frequency more flexibly, i.e., only calling clk_set_rate() for ldb_di[n] clock would be an alternative. > While I admit to having introduced the combination of 1/3.5 fixed > divider and configurable 1/1,1/2 divder clocks to describe this > fractional divider for the reasons you state, I think the correct > solution would be to improve the table divider to support fractional > values and get rid of the virtual ldb_di_div_3_5 clocks, not > introduce more virtual clocks. Yes, it's good to support fractional values for the table divider(not sure if there is any plan for this). I see there is something similar in 'include/linux/sh_clk.h'. > > regards > Philipp > > Regards, Liu Ying
[PATCH] drm: add MIPI DSI encoder and connector types
From: Shobhit Kumar
Signed-off-by: Shobhit Kumar
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_crtc.c |2 ++
include/uapi/drm/drm_mode.h |2 ++
2 files changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index a691764..dc279f4 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -209,6 +209,7 @@ static struct drm_conn_prop_enum_list
drm_connector_enum_list[] =
{ DRM_MODE_CONNECTOR_TV, "TV" },
{ DRM_MODE_CONNECTOR_eDP, "eDP" },
{ DRM_MODE_CONNECTOR_VIRTUAL, "Virtual" },
+ { DRM_MODE_CONNECTOR_DSI, "DSI" },
};
static const struct drm_prop_enum_list drm_encoder_enum_list[] =
@@ -218,6 +219,7 @@ static const struct drm_prop_enum_list
drm_encoder_enum_list[] =
{ DRM_MODE_ENCODER_LVDS, "LVDS" },
{ DRM_MODE_ENCODER_TVDAC, "TV" },
{ DRM_MODE_ENCODER_VIRTUAL, "Virtual" },
+ { DRM_MODE_ENCODER_DSI, "DSI" },
};
void drm_connector_ida_init(void)
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index 53db7ce..589114e 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -165,6 +165,7 @@ struct drm_mode_get_plane_res {
#define DRM_MODE_ENCODER_LVDS 3
#define DRM_MODE_ENCODER_TVDAC 4
#define DRM_MODE_ENCODER_VIRTUAL 5
+#define DRM_MODE_ENCODER_DSI 6
struct drm_mode_get_encoder {
__u32 encoder_id;
@@ -203,6 +204,7 @@ struct drm_mode_get_encoder {
#define DRM_MODE_CONNECTOR_TV 13
#define DRM_MODE_CONNECTOR_eDP 14
#define DRM_MODE_CONNECTOR_VIRTUAL 15
+#define DRM_MODE_CONNECTOR_DSI 16
struct drm_mode_get_connector {
--
1.7.9.5
[PATCH 2/2] drm/i915: add fast boot support for Haswell
On Tue, Aug 20, 2013 at 3:33 AM, Furquan Shaikh wrote:
> Enables getting correct mode clock when reading pipe config
> This patch has been tested successfully on top of drm-intel-nightly tree
>
> Signed-off-by: Furquan Shaikh
This is missing a hunk to enable the pipe_config consistency checks:
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 7a40427..e8b73ac 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -8416,13 +8416,11 @@ intel_pipe_config_compare(struct drm_device *dev,
#undef PIPE_CONF_CHECK_FLAGS
#undef PIPE_CONF_QUIRK
- if (!IS_HASWELL(dev)) {
- if (!intel_fuzzy_clock_check(current_config, pipe_config)) {
- DRM_ERROR("mismatch in clock (expected %d, found %d)\n",
- current_config->adjusted_mode.clock,
- pipe_config->adjusted_mode.clock);
- return false;
- }
+ if (!intel_fuzzy_clock_check(current_config, pipe_config)) {
+ DRM_ERROR("mismatch in clock (expected %d, found %d)\n",
+ current_config->adjusted_mode.clock,
+ pipe_config->adjusted_mode.clock);
+ return false;
}
return true;
Cheers, Daniel
> ---
> drivers/gpu/drm/i915/i915_reg.h | 6
> drivers/gpu/drm/i915/intel_ddi.c | 70
>
> drivers/gpu/drm/i915/intel_display.c | 1 +
> 3 files changed, 77 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 2b96d6b..9511129 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -4970,6 +4970,7 @@
> #define SPLL_PLL_NON_SSC (2<<28)
> #define SPLL_PLL_FREQ_810MHz (0<<26)
> #define SPLL_PLL_FREQ_1350MHz (1<<26)
> +#define SPLL_PLL_FREQ_MASK (3<<26)
>
> /* WRPLL */
> #define WRPLL_CTL1 0x46040
> @@ -4983,6 +4984,10 @@
> #define WRPLL_DIVIDER_POST(x) ((x)<<8)
> #define WRPLL_DIVIDER_FEEDBACK(x) ((x)<<16)
>
> +#define WRPLL_DIVIDER_REFERENCE_BITS(reg)(reg & 0xff)
> +#define WRPLL_DIVIDER_POST_BITS(reg) ((reg >> 8) & 0x3f)
> +#define WRPLL_DIVIDER_FEEDBACK_BITS(reg) ((reg >> 16) & 0xff)
> +
> /* Port clock selection */
> #define PORT_CLK_SEL_A 0x46100
> #define PORT_CLK_SEL_B 0x46104
> @@ -4994,6 +4999,7 @@
> #define PORT_CLK_SEL_WRPLL1 (4<<29)
> #define PORT_CLK_SEL_WRPLL2 (5<<29)
> #define PORT_CLK_SEL_NONE (7<<29)
> +#define PORT_CLK_SEL_MASK (7<<29)
>
> /* Transcoder clock selection */
> #define TRANS_CLK_SEL_A0x46140
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> b/drivers/gpu/drm/i915/intel_ddi.c
> index b8c096b..a24a375 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -1246,6 +1246,74 @@ static void intel_ddi_hot_plug(struct intel_encoder
> *intel_encoder)
> intel_dp_check_link_status(intel_dp);
> }
>
> +static void intel_ddi_get_clock(struct intel_encoder *encoder,
> + struct intel_crtc_config *pipe_config)
> +{
> + struct drm_i915_private *dev_priv = encoder->base.dev->dev_private;
> + int port = intel_ddi_get_encoder_port(encoder);
> + u32 temp = I915_READ(PORT_CLK_SEL(port)) & PORT_CLK_SEL_MASK;
> + u8 link_bw;
> +
> + if ((temp == PORT_CLK_SEL_LCPLL_810) ||
> + (temp == PORT_CLK_SEL_LCPLL_1350) ||
> + (temp == PORT_CLK_SEL_LCPLL_2700)) {
> +
> + switch (temp) {
> + case PORT_CLK_SEL_LCPLL_810:
> + link_bw = DP_LINK_BW_1_62;
> + break;
> + case PORT_CLK_SEL_LCPLL_1350:
> + link_bw = DP_LINK_BW_2_7;
> + break;
> + case PORT_CLK_SEL_LCPLL_2700:
> + link_bw = DP_LINK_BW_5_4;
> + break;
> + }
> + pipe_config->port_clock =
> drm_dp_bw_code_to_link_rate(link_bw);
> + } else if ((temp == PORT_CLK_SEL_WRPLL1) ||
> + (temp == PORT_CLK_SEL_WRPLL2)) {
> + uint64_t p, n2, r2;
> + u32 val, reg;
> + uint64_t freq2k;
> +
> + switch (temp) {
> + case PORT_CLK_SEL_WRPLL1:
> + reg = WRPLL_CTL1;
> + break;
> + case PORT_CLK_SEL_WRPLL2:
> + reg = WRPLL_CTL2;
> + break;
> + }
> + val = I915_READ(reg);
> + r2 = WRPLL_DIVIDER_REFERENCE_BITS(val);
> + p = WRPLL_DIVIDER_POST_BITS(val);
> + n2 = WRPLL_DIVIDER_FEEDBACK
[Bug 60231] DisplayPort monitor not detected on PowerColor Radeon HD 4850
https://bugzilla.kernel.org/show_bug.cgi?id=60231 Alex Deucher changed: What|Removed |Added CC||alexdeucher at gmail.com --- Comment #1 from Alex Deucher --- Possibly related to bug 60639. Can you try the patch on that bug? -- You are receiving this mail because: You are watching the assignee of the bug.
[RFC PATCH] drm/radeon: rework to new fence interface
Op 20-08-13 11:51, Christian K?nig schreef:
> Am 20.08.2013 11:36, schrieb Maarten Lankhorst:
> [SNIP]
>
>> [SNIP]
>> +/**
>> + * radeon_fence_enable_signaling - enable signalling on fence
>> + * @fence: fence
>> + *
>> + * This function is called with fence_queue lock held, and adds a
>> callback
>> + * to fence_queue that checks if this fence is signaled, and if so it
>> + * signals the fence and removes itself.
>> + */
>> +static bool radeon_fence_enable_signaling(struct fence *f)
>> +{
>> +struct radeon_fence *fence = to_radeon_fence(f);
>> +
>> +if (atomic64_read(&fence->rdev->fence_drv[fence->ring].last_seq) >=
>> fence->seq ||
>> +!fence->rdev->ddev->irq_enabled)
>> +return false;
>> +
> Do I get that right that you rely on IRQs to be enabled and working here?
> Cause that would be a quite bad idea from the conceptual side.
For cross-device synchronization it would be nice to have working irqs, it
allows signalling fences faster,
and it allows for callbacks on completion to be called. For internal usage
it's no more required than it was before.
>>> That's a big NAK.
>>>
>>> The fence processing is actually very fine tuned to avoid IRQs and as far
>>> as I can see you just leave them enabled by decrementing the atomic from
>>> IRQ context. Additional to that we need allot of special handling in case
>>> of a hardware lockup here, which isn't done if you abuse the fence
>>> interface like this.
>> I think it's not needed to leave the irq enabled, it's a leftover from when
>> I was debugging the mac and no interrupt occurred at all.
>>
>>> Also your approach of leaking the IRQ context outside of the driver is a
>>> very bad idea from the conceptual side. Please don't modify the fence
>>> interface at all and instead use the wait functions already exposed by
>>> radeon_fence.c. If you need some kind of signaling mechanism then wait
>>> inside a workqueue instead.
>> The fence takes up the role of a single shot workqueue here. Manually
>> resetting the counter and calling wake_up_all would end up waking all active
>> fences, there's no special handling needed inside radeon for this.
>
> Yeah that's actually the point here, you NEED to activate ALL fences,
> otherwise the fence handling inside the driver won't work.
It's done in a lazy fashion. If there's no need for an activated fence the
interrupt will not be enabled.
>> The fence api does provide a synchronous wait function, but this causes a
>> stall of whomever waits on it.
>
> Which is perfectly fine. What actually is the use case of not stalling a
> process who wants to wait for something?
Does radeon call ttm_bo_wait on all bo's before doing a command submission? No?
Why should other drivers do that..
>> When I was testing this with intel I used the fence callback to poke a
>> register in i915, this allowed it to not block until it hits the wait op in
>> the command stream, and even then only if the callback was not called first.
>>
>> It's documented that the callbacks can be called from any context and will
>> be called with irqs disabled, so nothing scary should be done. The kernel
>> provides enough debug mechanisms to find any violators.
>> PROVE_LOCKING and DEBUG_ATOMIC_SLEEP for example.
>
> No thanks, we even abandoned that concept internal in the driver. Please use
> the blocking wait functions instead.
No, this just stalls all gpu's that share a bo.
The idea is to provide a standardized api so bo's can be synchronized without
stalling. The first step to this is ww_mutex.
If this lock is shared between multiple gpu's the same object can be reserved
between multiple devices without causing
a deadlock with circular dependencies. With some small patches it's possible to
do this already between multiple drivers
that use ttm. ttm_bo_reserve, ttm_bo_unreserve and all the other code dealing
with ttm reservations have been converted
to use ww_mutex locking.
Fencing is the next step. When all buffers are locked a callback should be
added to any previous fence, and a single new fence
signaling completion of the command submission should be placed on all locked
objects. Because the common path is that no
objects are shared, the callback and FIFO stalling will only be needed for
dma-bufs. When all callbacks have fired the FIFO can be
unblocked. This prevents having to sync the gpu to the cpu. If a bo is
submitted to 1 gpu, and then immediately to another it will not
stall unless needed. For example in a optimus configuration an application
could copy a rendered frame from VRAM to a shared
dma-buf (xorg's buffer), then have Xorg copying it again (on intel's gpu) from
the dma-buf to a framebuffer .
~Maarten
[Bug 60674] linux 3.10.x RV740 (Radeon HD 4770) display problem
https://bugzilla.kernel.org/show_bug.cgi?id=60674 --- Comment #15 from Alex Deucher --- (In reply to Dave from comment #14) > (In reply to Michel D?nzer from comment #13) > > Michel you could well be 100% right. While the symptoms may be similar, your issue is completely different, and not kernel related. Please open a new bug on https://bugs.freedesktop.org (for the ddx: product xorg, component Driver/Radeon). -- You are receiving this mail because: You are watching the assignee of the bug.
A gentle scrub
On Mon, Aug 19, 2013 at 7:53 PM, Damien Lespiau wrote: > A small pass on drm headers to remove some stale prototypes/functions/defines > and to make static a few functions. For the series: Reviewed-by: Alex Deucher > > drivers/gpu/drm/drm_crtc.c | 38 > +++-- > drivers/gpu/drm/drm_fb_cma_helper.c | 5 ++--- > drivers/gpu/drm/drm_modes.c | 21 > drivers/gpu/drm/drm_platform.c | 7 +++ > include/drm/drmP.h | 8 > include/drm/drm_crtc.h | 17 - > include/drm/drm_fb_cma_helper.h | 1 - > include/drm/drm_pciids.h| 30 - > 8 files changed, 8 insertions(+), 119 deletions(-) > > -- > Damien > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC PATCH] drm/radeon: rework to new fence interface
Am 20.08.2013 15:21, schrieb Maarten Lankhorst:
> Op 20-08-13 11:51, Christian K?nig schreef:
>> Am 20.08.2013 11:36, schrieb Maarten Lankhorst:
>> [SNIP]
>>
>>> [SNIP]
>>> +/**
>>> + * radeon_fence_enable_signaling - enable signalling on fence
>>> + * @fence: fence
>>> + *
>>> + * This function is called with fence_queue lock held, and adds a
>>> callback
>>> + * to fence_queue that checks if this fence is signaled, and if so it
>>> + * signals the fence and removes itself.
>>> + */
>>> +static bool radeon_fence_enable_signaling(struct fence *f)
>>> +{
>>> +struct radeon_fence *fence = to_radeon_fence(f);
>>> +
>>> +if (atomic64_read(&fence->rdev->fence_drv[fence->ring].last_seq)
>>> >= fence->seq ||
>>> +!fence->rdev->ddev->irq_enabled)
>>> +return false;
>>> +
>> Do I get that right that you rely on IRQs to be enabled and working
>> here? Cause that would be a quite bad idea from the conceptual side.
> For cross-device synchronization it would be nice to have working irqs,
> it allows signalling fences faster,
> and it allows for callbacks on completion to be called. For internal
> usage it's no more required than it was before.
That's a big NAK.
The fence processing is actually very fine tuned to avoid IRQs and as far
as I can see you just leave them enabled by decrementing the atomic from
IRQ context. Additional to that we need allot of special handling in case
of a hardware lockup here, which isn't done if you abuse the fence
interface like this.
>>> I think it's not needed to leave the irq enabled, it's a leftover from when
>>> I was debugging the mac and no interrupt occurred at all.
>>>
Also your approach of leaking the IRQ context outside of the driver is a
very bad idea from the conceptual side. Please don't modify the fence
interface at all and instead use the wait functions already exposed by
radeon_fence.c. If you need some kind of signaling mechanism then wait
inside a workqueue instead.
>>> The fence takes up the role of a single shot workqueue here. Manually
>>> resetting the counter and calling wake_up_all would end up waking all
>>> active fences, there's no special handling needed inside radeon for this.
>> Yeah that's actually the point here, you NEED to activate ALL fences,
>> otherwise the fence handling inside the driver won't work.
> It's done in a lazy fashion. If there's no need for an activated fence the
> interrupt will not be enabled.
>>> The fence api does provide a synchronous wait function, but this causes a
>>> stall of whomever waits on it.
>> Which is perfectly fine. What actually is the use case of not stalling a
>> process who wants to wait for something?
> Does radeon call ttm_bo_wait on all bo's before doing a command submission?
> No? Why should other drivers do that..
Sure it does if hardware synchronization isn't supported.
>>> When I was testing this with intel I used the fence callback to poke a
>>> register in i915, this allowed it to not block until it hits the wait op in
>>> the command stream, and even then only if the callback was not called first.
>>>
>>> It's documented that the callbacks can be called from any context and will
>>> be called with irqs disabled, so nothing scary should be done. The kernel
>>> provides enough debug mechanisms to find any violators.
>>> PROVE_LOCKING and DEBUG_ATOMIC_SLEEP for example.
>> No thanks, we even abandoned that concept internal in the driver. Please use
>> the blocking wait functions instead.
> No, this just stalls all gpu's that share a bo.
>
> The idea is to provide a standardized api so bo's can be synchronized without
> stalling. The first step to this is ww_mutex.
> If this lock is shared between multiple gpu's the same object can be reserved
> between multiple devices without causing
> a deadlock with circular dependencies. With some small patches it's possible
> to do this already between multiple drivers
> that use ttm. ttm_bo_reserve, ttm_bo_unreserve and all the other code dealing
> with ttm reservations have been converted
> to use ww_mutex locking.
>
> Fencing is the next step. When all buffers are locked a callback should be
> added to any previous fence, and a single new fence
> signaling completion of the command submission should be placed on all locked
> objects. Because the common path is that no
> objects are shared, the callback and FIFO stalling will only be needed for
> dma-bufs. When all callbacks have fired the FIFO can be
> unblocked. This prevents having to sync the gpu to the cpu. If a bo is
> submitted to 1 gpu, and then immediately to another it will not
> stall unless needed. For example in a optimus configuration an application
> could copy a rendered frame from VRAM to a shared
> dma-buf (xorg's buffer), then have Xorg copying it again (on intel's gpu)
> from the d
[Bug 60523] Radeon DPM not working with 2 monitors attached to Radeon HD5770 (Juniper)
https://bugzilla.kernel.org/show_bug.cgi?id=60523 --- Comment #37 from Alex Deucher --- I was finally able to reproduce this, but only with gcc 4.8. Older versions of gcc work fine. Looks like the gcc bug has struck again. See: https://bugs.freedesktop.org/show_bug.cgi?id=66932 Now to find what other part gcc doesn't like... -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH 8/8] drm: Make drm_get_platform_dev() static
On 08/19/2013 04:53 PM, Damien Lespiau wrote:
> It's only used in drm_platform.c.
>
> Signed-off-by: Damien Lespiau
> ---
> drivers/gpu/drm/drm_platform.c | 7 +++
> include/drm/drmP.h | 3 ---
> 2 files changed, 3 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_platform.c b/drivers/gpu/drm/drm_platform.c
> index b8a282e..400024b 100644
> --- a/drivers/gpu/drm/drm_platform.c
> +++ b/drivers/gpu/drm/drm_platform.c
> @@ -28,7 +28,7 @@
> #include
> #include
>
> -/**
> +/*
>* Register.
>*
>* \param platdev - Platform device struture
Was this change intentional? The rest of the comment is doxygen still.
> @@ -39,8 +39,8 @@
>* Try and register, if we fail to register, backout previous work.
>*/
>
> -int drm_get_platform_dev(struct platform_device *platdev,
> - struct drm_driver *driver)
> +static int drm_get_platform_dev(struct platform_device *platdev,
> + struct drm_driver *driver)
> {
> struct drm_device *dev;
> int ret;
> @@ -107,7 +107,6 @@ err_g1:
> mutex_unlock(&drm_global_mutex);
> return ret;
> }
> -EXPORT_SYMBOL(drm_get_platform_dev);
>
> static int drm_platform_get_irq(struct drm_device *dev)
> {
> diff --git a/include/drm/drmP.h b/include/drm/drmP.h
> index 046a7db..1a7a78f 100644
> --- a/include/drm/drmP.h
> +++ b/include/drm/drmP.h
> @@ -1657,9 +1657,6 @@ extern int drm_pcie_get_speed_cap_mask(struct
> drm_device *dev, u32 *speed_mask);
> extern int drm_platform_init(struct drm_driver *driver, struct
> platform_device *platform_device);
> extern void drm_platform_exit(struct drm_driver *driver, struct
> platform_device *platform_device);
>
> -extern int drm_get_platform_dev(struct platform_device *pdev,
> - struct drm_driver *driver);
> -
> /* returns true if currently okay to sleep */
> static __inline__ bool drm_can_sleep(void)
> {
>
[PATCH 1/3] ARM: imx6q: refactor some ldb related clocks
On Tue, Aug 20, 2013 at 5:38 AM, Liu Ying wrote: > diff --git a/Documentation/devicetree/bindings/clock/imx6q-clock.txt > b/Documentation/devicetree/bindings/clock/imx6q-clock.txt > index 5a90a72..90e923e 100644 > --- a/Documentation/devicetree/bindings/clock/imx6q-clock.txt > +++ b/Documentation/devicetree/bindings/clock/imx6q-clock.txt > @@ -89,8 +89,6 @@ clocks and IDs. > gpu3d_shader74 > ipu1_podf 75 > ipu2_podf 76 > - ldb_di0_podf77 > - ldb_di1_podf78 > ipu1_di0_pre79 > ipu1_di1_pre80 > ipu2_di0_pre81 This causes a 'hole' in the clock numbering scheme: 74, 75, 76, 79, 80, etc
[Bug 60523] Radeon DPM not working with 2 monitors attached to Radeon HD5770 (Juniper)
https://bugzilla.kernel.org/show_bug.cgi?id=60523 --- Comment #38 from Tobias Droste --- I don't want to say that it's not a gcc bug, but I'm using gcc 4.7: gcc version 4.7.2 20130108 [gcc-4_7-branch revision 195012] (SUSE Linux) -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH 8/8] drm: Make drm_get_platform_dev() static
On Tue, Aug 20, 2013 at 07:56:42AM -0700, Ian Romanick wrote:
> On 08/19/2013 04:53 PM, Damien Lespiau wrote:
> >It's only used in drm_platform.c.
> >
> >Signed-off-by: Damien Lespiau
> >---
> > drivers/gpu/drm/drm_platform.c | 7 +++
> > include/drm/drmP.h | 3 ---
> > 2 files changed, 3 insertions(+), 7 deletions(-)
> >
> >diff --git a/drivers/gpu/drm/drm_platform.c b/drivers/gpu/drm/drm_platform.c
> >index b8a282e..400024b 100644
> >--- a/drivers/gpu/drm/drm_platform.c
> >+++ b/drivers/gpu/drm/drm_platform.c
> >@@ -28,7 +28,7 @@
> > #include
> > #include
> >
> >-/**
> >+/*
> > * Register.
> > *
> > * \param platdev - Platform device struture
>
> Was this change intentional? The rest of the comment is doxygen still.
It was indeed, just to stop documentation tools from picking up that
symbol that is not exported anymore. The documentation blob still
contains markup to tag the parameters though, might as well leave it
there.
--
Damien
>
> >@@ -39,8 +39,8 @@
> > * Try and register, if we fail to register, backout previous work.
> > */
> >
> >-int drm_get_platform_dev(struct platform_device *platdev,
> >- struct drm_driver *driver)
> >+static int drm_get_platform_dev(struct platform_device *platdev,
> >+struct drm_driver *driver)
> > {
> > struct drm_device *dev;
> > int ret;
> >@@ -107,7 +107,6 @@ err_g1:
> > mutex_unlock(&drm_global_mutex);
> > return ret;
> > }
> >-EXPORT_SYMBOL(drm_get_platform_dev);
> >
> > static int drm_platform_get_irq(struct drm_device *dev)
> > {
> >diff --git a/include/drm/drmP.h b/include/drm/drmP.h
> >index 046a7db..1a7a78f 100644
> >--- a/include/drm/drmP.h
> >+++ b/include/drm/drmP.h
> >@@ -1657,9 +1657,6 @@ extern int drm_pcie_get_speed_cap_mask(struct
> >drm_device *dev, u32 *speed_mask);
> > extern int drm_platform_init(struct drm_driver *driver, struct
> > platform_device *platform_device);
> > extern void drm_platform_exit(struct drm_driver *driver, struct
> > platform_device *platform_device);
> >
> >-extern int drm_get_platform_dev(struct platform_device *pdev,
> >-struct drm_driver *driver);
> >-
> > /* returns true if currently okay to sleep */
> > static __inline__ bool drm_can_sleep(void)
> > {
> >
>
[Bug 67994] Lockup with UVD and DPM on RV730
https://bugs.freedesktop.org/show_bug.cgi?id=67994 --- Comment #7 from Timoth?e Ravier --- Created attachment 84347 --> https://bugs.freedesktop.org/attachment.cgi?id=84347&action=edit dmesg log -- 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/20130820/7579641f/attachment-0001.html>
[Bug 67994] Lockup with UVD and DPM on RV730
https://bugs.freedesktop.org/show_bug.cgi?id=67994 --- Comment #8 from Timoth?e Ravier --- Look alike bug here: screen goes black and freeze for a while when playing the second video using VDPAU with mplayer. Upon "screen return", the whole display is corrupted and unusable, requiring reboot. Arch Linux testing packages except for the kernel which is custom build. Card: Radeon Mobility 4650 HD Linux kernel: 3.11rc6 (commit: b36f4be, it's called -dirty in the dmesg log but I don't know why, will try to figure that out) Mesa: 9.2.0rc1 OpenGL vendor string: X.Org OpenGL renderer string: Gallium 0.4 on AMD RV730 OpenGL core profile version string: 3.1 (Core Profile) Mesa 9.2.0-rc1 OpenGL core profile shading language version string: 1.40 OpenGL core profile context flags: (none) OpenGL core profile extensions: OpenGL version string: 3.0 Mesa 9.2.0-rc1 OpenGL shading language version string: 1.30 -- 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/20130820/8622e425/attachment.html>
