Commit f5d9b7f0f9 (fix r600_enable_sclk_control()) causes kexec issues

2013-07-30 Thread Markus Trippelsdorf 
On 2013.07.30 at 20:46 +0200, Markus Trippelsdorf wrote:
> On 2013.07.30 at 10:53 -0400, Alex Deucher wrote:
> > On Tue, Jul 30, 2013 at 7:27 AM, Markus Trippelsdorf
> >  wrote:
> > > On 2013.07.29 at 15:53 -0400, Alex Deucher wrote:
> > >> On Mon, Jul 29, 2013 at 2:10 PM, Eric W. Biederman
> > >>  wrote:
> > >> > Alex Deucher  writes:
> > >> >
> > >> >> On Mon, Jul 29, 2013 at 11:50 AM, Eric W. Biederman
> > >> >>  wrote:
> > >> >>>
> > >> >>>
> > >> >>> Alex Deucher  wrote:
> > >> On Mon, Jul 29, 2013 at 10:09 AM, Markus Trippelsdorf
> > >>  wrote:
> > >> > On 2013.07.29 at 09:58 -0400, Alex Deucher wrote:
> > >> >> On Mon, Jul 29, 2013 at 3:51 AM, Markus Trippelsdorf
> > >> >>  wrote:
> > >> >> > On my test machine Xorg doesn't start anymore when I kexec into 
> > >> >> > a
> > >> >> > 3.11.0-rc3 kernel.
> > >> >>
> > >> >> With kexec, dpm doesn't get torn down properly which can result 
> > >> >> in a
> > >> >> bad hardware state when the driver loads again.  Does the attached
> > >> >> patch help?  It attempts to disable dpm at startup in case it 
> > >> >> wasn't
> > >> >> torn down properly previously.
> > >> >
> > >> > dpm initialization now works, but unfortunately GPU acceleration
> > >> still gets
> > >> > disabled:
> > >> 
> > >> Stupid kexec complicates things.  We need to make sure dpm is torn
> > >> down before we init the rest of the GPU, but dpm needs get 
> > >> initialized
> > >> later in the init process since it depends on certain other state 
> > >> from
> > >> the driver.  I need to think about this for a bit.  I'm not sure of a
> > >> good way to handle this.
> > >> >>>
> > >> >>> You might just want to implement a shutdown method that cleans 
> > >> >>> things up properly.   At least as a first pass until you worry about 
> > >> >>> things like kexec on panic.
> > >> >>>
> > >> >>> Or can you not shutdown the graphics stack on reboot because of the 
> > >> >>> need to display the kernels shutdown progress?
> > >> >>
> > >> >> Does kexec actually call this shutdown method?  The driver implements
> > >> >> appropriate clean-up measures if it's shutdown properly.
> > >> >
> > >> > Absoltuely.  All parts of the reboot path call ->shutdown.  Including
> > >> > kexec.
> > >> >
> > >> > You don't get a device remove/hotunplug but unless this is a kexec on
> > >> > panic ->shutdown is most definitely called.  Now I am talking about the
> > >> > device layer/pci layer shutdown method I don't know how gpu drivers are
> > >> > wired up.  GPU land was a little strange last I looked.  Hopefully it
> > >> > isn't so strange that there is a method named shutdown that is not 
> > >> > wired
> > >> > up.
> > >>
> > >> It doesn't look like the drm infrastructure has a shutdown callback.
> > >> The drm drivers register a drm_driver callback struct that includes an
> > >> unload callback which takes care of all the device teardown (if you
> > >> unload the module for example).  I don't know that it actually gets
> > >> called at kexec time however.  I don't know enough about how kexec
> > >> works.
> > >
> > > BTW there is r100_restore_sanity() in drm/radeon/r100.c that explicitly
> > > handles the kexec case during init. So maybe an r600_restore_sanity()
> > > function is needed?
> > >
> > > (One of the advantages of using kexec (besides the much quicker boot
> > > time) is that the monitor is not switched off and then on during boot.
> > > I guess that advantage would be lost if the unload callback would be
> > > called.)
> > 
> > r100_restore_sanity() is basically a set of hacks (that gets called at
> > driver startup) to work around the fact that with kexec the drm driver
> > is not torn down correctly.  So we could add a bunch more asic
> > specific tear down sequences to deal with dpm (and all the other
> > engines on the GPU that may potentially cause problems if they are not
> > torn down properly), but that will just turn into a mess.  All of
> > these hacks also add latency to the driver load.  I think the best
> > solution would probably be to figure how to hook up the drm unload
> > callback to the shutdown method that kexec uses.
> 
> FYI the following (ugly) hack works for me. 

No. It still fails, although much more infrequently (~ on every 6-8 boot).

I begin to wonder if:
 [drm:r600_dma_ring_test] *ERROR* radeon: ring 3 test failed (0xCAFEDEAD) 
is an simple initialization bug that doesn't directly depend on kexec at
all.

-- 
Markus

[PATCH 3/3] drm/gma500: Rename psb_intel_encoder to gma_encoder

2013-07-30 Thread Patrik Jakobsson 
The psb_intel_encoder is generic and should be named appropriately

Signed-off-by: Patrik Jakobsson 
---
 drivers/gpu/drm/gma500/cdv_intel_crt.c   |  31 ---
 drivers/gpu/drm/gma500/cdv_intel_display.c   |  10 +--
 drivers/gpu/drm/gma500/cdv_intel_dp.c| 130 +--
 drivers/gpu/drm/gma500/cdv_intel_hdmi.c  |  66 ++
 drivers/gpu/drm/gma500/cdv_intel_lvds.c  |  50 +--
 drivers/gpu/drm/gma500/framebuffer.c |   7 +-
 drivers/gpu/drm/gma500/gma_display.c |  13 ++-
 drivers/gpu/drm/gma500/mdfld_dsi_output.h|   8 +-
 drivers/gpu/drm/gma500/mdfld_intel_display.c |   8 +-
 drivers/gpu/drm/gma500/oaktrail_crtc.c   |   8 +-
 drivers/gpu/drm/gma500/oaktrail_hdmi.c   |  14 +--
 drivers/gpu/drm/gma500/oaktrail_lvds.c   |  37 
 drivers/gpu/drm/gma500/psb_drv.c |   6 +-
 drivers/gpu/drm/gma500/psb_intel_display.c   |  10 +--
 drivers/gpu/drm/gma500/psb_intel_drv.h   |  14 +--
 drivers/gpu/drm/gma500/psb_intel_lvds.c  |  49 +-
 drivers/gpu/drm/gma500/psb_intel_sdvo.c  |  20 ++---
 17 files changed, 226 insertions(+), 255 deletions(-)

diff --git a/drivers/gpu/drm/gma500/cdv_intel_crt.c 
b/drivers/gpu/drm/gma500/cdv_intel_crt.c
index b2661f3..661af49 100644
--- a/drivers/gpu/drm/gma500/cdv_intel_crt.c
+++ b/drivers/gpu/drm/gma500/cdv_intel_crt.c
@@ -196,10 +196,9 @@ static enum drm_connector_status cdv_intel_crt_detect(

 static void cdv_intel_crt_destroy(struct drm_connector *connector)
 {
-   struct psb_intel_encoder *psb_intel_encoder =
-   gma_attached_encoder(connector);
+   struct gma_encoder *gma_encoder = gma_attached_encoder(connector);

-   psb_intel_i2c_destroy(psb_intel_encoder->ddc_bus);
+   psb_intel_i2c_destroy(gma_encoder->ddc_bus);
drm_sysfs_connector_remove(connector);
drm_connector_cleanup(connector);
kfree(connector);
@@ -207,9 +206,9 @@ static void cdv_intel_crt_destroy(struct drm_connector 
*connector)

 static int cdv_intel_crt_get_modes(struct drm_connector *connector)
 {
-   struct psb_intel_encoder *psb_intel_encoder =
-   gma_attached_encoder(connector);
-   return psb_intel_ddc_get_modes(connector, 
_intel_encoder->ddc_bus->adapter);
+   struct gma_encoder *gma_encoder = gma_attached_encoder(connector);
+   return psb_intel_ddc_get_modes(connector,
+  _encoder->ddc_bus->adapter);
 }

 static int cdv_intel_crt_set_property(struct drm_connector *connector,
@@ -260,14 +259,14 @@ void cdv_intel_crt_init(struct drm_device *dev,
 {

struct gma_connector *gma_connector;
-   struct psb_intel_encoder *psb_intel_encoder;
+   struct gma_encoder *gma_encoder;
struct drm_connector *connector;
struct drm_encoder *encoder;

u32 i2c_reg;

-   psb_intel_encoder = kzalloc(sizeof(struct psb_intel_encoder), 
GFP_KERNEL);
-   if (!psb_intel_encoder)
+   gma_encoder = kzalloc(sizeof(struct gma_encoder), GFP_KERNEL);
+   if (!gma_encoder)
return;

gma_connector = kzalloc(sizeof(struct gma_connector), GFP_KERNEL);
@@ -279,11 +278,11 @@ void cdv_intel_crt_init(struct drm_device *dev,
drm_connector_init(dev, connector,
_intel_crt_connector_funcs, DRM_MODE_CONNECTOR_VGA);

-   encoder = _intel_encoder->base;
+   encoder = _encoder->base;
drm_encoder_init(dev, encoder,
_intel_crt_enc_funcs, DRM_MODE_ENCODER_DAC);

-   gma_connector_attach_encoder(gma_connector, psb_intel_encoder);
+   gma_connector_attach_encoder(gma_connector, gma_encoder);

/* Set up the DDC bus. */
i2c_reg = GPIOA;
@@ -292,15 +291,15 @@ void cdv_intel_crt_init(struct drm_device *dev,
if (dev_priv->crt_ddc_bus != 0)
i2c_reg = dev_priv->crt_ddc_bus;
}*/
-   psb_intel_encoder->ddc_bus = psb_intel_i2c_create(dev,
+   gma_encoder->ddc_bus = psb_intel_i2c_create(dev,
  i2c_reg, "CRTDDC_A");
-   if (!psb_intel_encoder->ddc_bus) {
+   if (!gma_encoder->ddc_bus) {
dev_printk(KERN_ERR, >pdev->dev, "DDC bus registration "
   "failed.\n");
goto failed_ddc;
}

-   psb_intel_encoder->type = INTEL_OUTPUT_ANALOG;
+   gma_encoder->type = INTEL_OUTPUT_ANALOG;
/*
psb_intel_output->clone_mask = (1 << INTEL_ANALOG_CLONE_BIT);
psb_intel_output->crtc_mask = (1 << 0) | (1 << 1);
@@ -316,10 +315,10 @@ void cdv_intel_crt_init(struct drm_device *dev,

return;
 failed_ddc:
-   drm_encoder_cleanup(_intel_encoder->base);
+   drm_encoder_cleanup(_encoder->base);
drm_connector_cleanup(_connector->base);
kfree(gma_connector);
 failed_connector:
-   kfree(psb_intel_encoder);
+   kfree(gma_encoder);

[PATCH 2/3] drm/gma500: Rename psb_intel_connector to gma_connector

2013-07-30 Thread Patrik Jakobsson 
The psb_intel_connector is generic and should be named appropriately

Signed-off-by: Patrik Jakobsson 
---
 drivers/gpu/drm/gma500/cdv_intel_crt.c | 14 +++---
 drivers/gpu/drm/gma500/cdv_intel_dp.c  | 16 
 drivers/gpu/drm/gma500/cdv_intel_hdmi.c| 12 ++--
 drivers/gpu/drm/gma500/cdv_intel_lvds.c| 12 ++--
 drivers/gpu/drm/gma500/framebuffer.c   |  2 +-
 drivers/gpu/drm/gma500/framebuffer.h   |  2 +-
 drivers/gpu/drm/gma500/gma_display.c   |  2 +-
 drivers/gpu/drm/gma500/mdfld_dsi_output.h  |  8 
 drivers/gpu/drm/gma500/oaktrail_hdmi.c | 10 +-
 drivers/gpu/drm/gma500/oaktrail_lvds.c | 12 ++--
 drivers/gpu/drm/gma500/psb_intel_display.c |  2 +-
 drivers/gpu/drm/gma500/psb_intel_drv.h | 10 +-
 drivers/gpu/drm/gma500/psb_intel_lvds.c| 15 +++
 drivers/gpu/drm/gma500/psb_intel_sdvo.c| 12 ++--
 14 files changed, 64 insertions(+), 65 deletions(-)

diff --git a/drivers/gpu/drm/gma500/cdv_intel_crt.c 
b/drivers/gpu/drm/gma500/cdv_intel_crt.c
index 79ad196..b2661f3 100644
--- a/drivers/gpu/drm/gma500/cdv_intel_crt.c
+++ b/drivers/gpu/drm/gma500/cdv_intel_crt.c
@@ -259,7 +259,7 @@ void cdv_intel_crt_init(struct drm_device *dev,
struct psb_intel_mode_device *mode_dev)
 {

-   struct psb_intel_connector *psb_intel_connector;
+   struct gma_connector *gma_connector;
struct psb_intel_encoder *psb_intel_encoder;
struct drm_connector *connector;
struct drm_encoder *encoder;
@@ -270,11 +270,11 @@ void cdv_intel_crt_init(struct drm_device *dev,
if (!psb_intel_encoder)
return;

-   psb_intel_connector = kzalloc(sizeof(struct psb_intel_connector), 
GFP_KERNEL);
-   if (!psb_intel_connector)
+   gma_connector = kzalloc(sizeof(struct gma_connector), GFP_KERNEL);
+   if (!gma_connector)
goto failed_connector;

-   connector = _intel_connector->base;
+   connector = _connector->base;
connector->polled = DRM_CONNECTOR_POLL_HPD;
drm_connector_init(dev, connector,
_intel_crt_connector_funcs, DRM_MODE_CONNECTOR_VGA);
@@ -283,7 +283,7 @@ void cdv_intel_crt_init(struct drm_device *dev,
drm_encoder_init(dev, encoder,
_intel_crt_enc_funcs, DRM_MODE_ENCODER_DAC);

-   gma_connector_attach_encoder(psb_intel_connector, psb_intel_encoder);
+   gma_connector_attach_encoder(gma_connector, psb_intel_encoder);

/* Set up the DDC bus. */
i2c_reg = GPIOA;
@@ -317,8 +317,8 @@ void cdv_intel_crt_init(struct drm_device *dev,
return;
 failed_ddc:
drm_encoder_cleanup(_intel_encoder->base);
-   drm_connector_cleanup(_intel_connector->base);
-   kfree(psb_intel_connector);
+   drm_connector_cleanup(_connector->base);
+   kfree(gma_connector);
 failed_connector:
kfree(psb_intel_encoder);
return;
diff --git a/drivers/gpu/drm/gma500/cdv_intel_dp.c 
b/drivers/gpu/drm/gma500/cdv_intel_dp.c
index a90adf6..55de663 100644
--- a/drivers/gpu/drm/gma500/cdv_intel_dp.c
+++ b/drivers/gpu/drm/gma500/cdv_intel_dp.c
@@ -648,7 +648,7 @@ cdv_intel_dp_i2c_aux_ch(struct i2c_adapter *adapter, int 
mode,
 }

 static int
-cdv_intel_dp_i2c_init(struct psb_intel_connector *connector, struct 
psb_intel_encoder *encoder, const char *name)
+cdv_intel_dp_i2c_init(struct gma_connector *connector, struct 
psb_intel_encoder *encoder, const char *name)
 {
struct cdv_intel_dp *intel_dp = encoder->dev_priv;
int ret;
@@ -1803,7 +1803,7 @@ void
 cdv_intel_dp_init(struct drm_device *dev, struct psb_intel_mode_device 
*mode_dev, int output_reg)
 {
struct psb_intel_encoder *psb_intel_encoder;
-   struct psb_intel_connector *psb_intel_connector;
+   struct gma_connector *gma_connector;
struct drm_connector *connector;
struct drm_encoder *encoder;
struct cdv_intel_dp *intel_dp;
@@ -1813,8 +1813,8 @@ cdv_intel_dp_init(struct drm_device *dev, struct 
psb_intel_mode_device *mode_dev
psb_intel_encoder = kzalloc(sizeof(struct psb_intel_encoder), 
GFP_KERNEL);
if (!psb_intel_encoder)
return;
-psb_intel_connector = kzalloc(sizeof(struct psb_intel_connector), 
GFP_KERNEL);
-if (!psb_intel_connector)
+gma_connector = kzalloc(sizeof(struct gma_connector), GFP_KERNEL);
+if (!gma_connector)
 goto err_connector;
intel_dp = kzalloc(sizeof(struct cdv_intel_dp), GFP_KERNEL);
if (!intel_dp)
@@ -1823,13 +1823,13 @@ cdv_intel_dp_init(struct drm_device *dev, struct 
psb_intel_mode_device *mode_dev
if ((output_reg == DP_C) && cdv_intel_dpc_is_edp(dev))
type = DRM_MODE_CONNECTOR_eDP;

-   connector = _intel_connector->base;
+   connector = _connector->base;
encoder = _intel_encoder->base;

drm_connector_init(dev, connector,

[PATCH 1/3] drm/gma500: Rename psb_intel_crtc to gma_crtc

2013-07-30 Thread Patrik Jakobsson 
The psb_intel_crtc is generic and should be named appropriately

Signed-off-by: Patrik Jakobsson 
---
 drivers/gpu/drm/gma500/cdv_intel_crt.c   |   7 +-
 drivers/gpu/drm/gma500/cdv_intel_display.c   |  28 +++
 drivers/gpu/drm/gma500/cdv_intel_dp.c|  10 +--
 drivers/gpu/drm/gma500/cdv_intel_hdmi.c  |   6 +-
 drivers/gpu/drm/gma500/cdv_intel_lvds.c  |   8 +-
 drivers/gpu/drm/gma500/framebuffer.c |  16 ++--
 drivers/gpu/drm/gma500/gma_display.c | 105 +--
 drivers/gpu/drm/gma500/mdfld_dsi_output.c|  15 ++--
 drivers/gpu/drm/gma500/mdfld_intel_display.c |  16 ++--
 drivers/gpu/drm/gma500/oaktrail_crtc.c   |  16 ++--
 drivers/gpu/drm/gma500/psb_drv.c |   6 +-
 drivers/gpu/drm/gma500/psb_intel_display.c   |  98 -
 drivers/gpu/drm/gma500/psb_intel_drv.h   |   6 +-
 drivers/gpu/drm/gma500/psb_intel_lvds.c  |  10 +--
 drivers/gpu/drm/gma500/psb_intel_sdvo.c  |   4 +-
 15 files changed, 170 insertions(+), 181 deletions(-)

diff --git a/drivers/gpu/drm/gma500/cdv_intel_crt.c 
b/drivers/gpu/drm/gma500/cdv_intel_crt.c
index 0cfcb26..79ad196 100644
--- a/drivers/gpu/drm/gma500/cdv_intel_crt.c
+++ b/drivers/gpu/drm/gma500/cdv_intel_crt.c
@@ -95,13 +95,12 @@ static void cdv_intel_crt_mode_set(struct drm_encoder 
*encoder,

struct drm_device *dev = encoder->dev;
struct drm_crtc *crtc = encoder->crtc;
-   struct psb_intel_crtc *psb_intel_crtc =
-   to_psb_intel_crtc(crtc);
+   struct gma_crtc *gma_crtc = to_gma_crtc(crtc);
int dpll_md_reg;
u32 adpa, dpll_md;
u32 adpa_reg;

-   if (psb_intel_crtc->pipe == 0)
+   if (gma_crtc->pipe == 0)
dpll_md_reg = DPLL_A_MD;
else
dpll_md_reg = DPLL_B_MD;
@@ -124,7 +123,7 @@ static void cdv_intel_crt_mode_set(struct drm_encoder 
*encoder,
if (adjusted_mode->flags & DRM_MODE_FLAG_PVSYNC)
adpa |= ADPA_VSYNC_ACTIVE_HIGH;

-   if (psb_intel_crtc->pipe == 0)
+   if (gma_crtc->pipe == 0)
adpa |= ADPA_PIPE_A_SELECT;
else
adpa |= ADPA_PIPE_B_SELECT;
diff --git a/drivers/gpu/drm/gma500/cdv_intel_display.c 
b/drivers/gpu/drm/gma500/cdv_intel_display.c
index 6bca1fe..e18c3b9 100644
--- a/drivers/gpu/drm/gma500/cdv_intel_display.c
+++ b/drivers/gpu/drm/gma500/cdv_intel_display.c
@@ -222,8 +222,8 @@ static int
 cdv_dpll_set_clock_cdv(struct drm_device *dev, struct drm_crtc *crtc,
   struct gma_clock_t *clock, bool is_lvds, u32 ddi_select)
 {
-   struct psb_intel_crtc *psb_crtc = to_psb_intel_crtc(crtc);
-   int pipe = psb_crtc->pipe;
+   struct gma_crtc *gma_crtc = to_gma_crtc(crtc);
+   int pipe = gma_crtc->pipe;
u32 m, n_vco, p;
int ret = 0;
int dpll_reg = (pipe == 0) ? DPLL_A : DPLL_B;
@@ -458,12 +458,12 @@ static bool cdv_intel_pipe_enabled(struct drm_device 
*dev, int pipe)
 {
struct drm_crtc *crtc;
struct drm_psb_private *dev_priv = dev->dev_private;
-   struct psb_intel_crtc *psb_intel_crtc = NULL;
+   struct gma_crtc *gma_crtc = NULL;

crtc = dev_priv->pipe_to_crtc_mapping[pipe];
-   psb_intel_crtc = to_psb_intel_crtc(crtc);
+   gma_crtc = to_gma_crtc(crtc);

-   if (crtc->fb == NULL || !psb_intel_crtc->active)
+   if (crtc->fb == NULL || !gma_crtc->active)
return false;
return true;
 }
@@ -489,11 +489,11 @@ static bool cdv_intel_single_pipe_active (struct 
drm_device *dev)

 static bool is_pipeb_lvds(struct drm_device *dev, struct drm_crtc *crtc)
 {
-   struct psb_intel_crtc *psb_intel_crtc = to_psb_intel_crtc(crtc);
+   struct gma_crtc *gma_crtc = to_gma_crtc(crtc);
struct drm_mode_config *mode_config = >mode_config;
struct drm_connector *connector;

-   if (psb_intel_crtc->pipe != 1)
+   if (gma_crtc->pipe != 1)
return false;

list_for_each_entry(connector, _config->connector_list, head) {
@@ -616,8 +616,8 @@ static int cdv_intel_crtc_mode_set(struct drm_crtc *crtc,
 {
struct drm_device *dev = crtc->dev;
struct drm_psb_private *dev_priv = dev->dev_private;
-   struct psb_intel_crtc *psb_intel_crtc = to_psb_intel_crtc(crtc);
-   int pipe = psb_intel_crtc->pipe;
+   struct gma_crtc *gma_crtc = to_gma_crtc(crtc);
+   int pipe = gma_crtc->pipe;
const struct psb_offset *map = _priv->regmap[pipe];
int refclk;
struct gma_clock_t clock;
@@ -693,7 +693,7 @@ static int cdv_intel_crtc_mode_set(struct drm_crtc *crtc,

drm_mode_debug_printmodeline(adjusted_mode);

-   limit = psb_intel_crtc->clock_funcs->limit(crtc, refclk);
+   limit = gma_crtc->clock_funcs->limit(crtc, refclk);

ok = limit->find_pll(limit, crtc, adjusted_mode->clock, refclk,
 );
@@ -883,8 +883,8 @@ static int

[Bug 60523] Lockup with radeon DPM on Radeon HD5770 (Juniper)

2013-07-30 Thread bugzilla-dae...@bugzilla.kernel.org 
https://bugzilla.kernel.org/show_bug.cgi?id=60523

--- Comment #11 from Tobias Droste  ---
Interesting fact #3:

it's also working if I only attach 1 monitor!

So it looks like power state 1, 2 and 4 are working correctly and power state 3
(no uvd and two monitors attached) is broken.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 60523] Lockup with radeon DPM on Radeon HD5770 (Juniper)

2013-07-30 Thread bugzilla-dae...@bugzilla.kernel.org 
https://bugzilla.kernel.org/show_bug.cgi?id=60523

--- Comment #10 from Tobias Droste  ---
Interesting fact #2:

# echo low > power_dpm_force_performance_level

works with UVD running!

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 60523] Lockup with radeon DPM on Radeon HD5770 (Juniper)

2013-07-30 Thread bugzilla-dae...@bugzilla.kernel.org 
https://bugzilla.kernel.org/show_bug.cgi?id=60523

--- Comment #9 from Tobias Droste  ---
No.

It seems to work good as soon as the power state switches to a state with UVD
(jumping from 0 to 2 based on load). But without UVD running it stays on power
level 2 as soon as it lands there.

So it goes (ps = power state, pl = power level):

ps(non-uvd) pl2 -> ps(uvd) pl2 -> ps(uvd) pl0 -> ps(uvd) pl1 -> ps(uvd) pl0 ->
ps(non-uvd) pl0

it stays at this until something is rendering in 3D and goes to pl2. 

But when the 3D rendering stops it doesn't go back to pl0 or pl1. So it really
seems like it's stuck there in this power state.

and this is still happening:
# echo low > power_dpm_force_performance_level
bash: echo: write error: Invalid argument

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 64695] Enabling both MLAA and MLAA color 2D crashes Gnome Shell on Cayman (6950)

2013-07-30 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=64695

--- Comment #7 from Marek Ol??k  ---
This bug should be fixed with latest Mesa git now. Please confirm.

-- 
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/20130730/3ee17d89/attachment-0001.html>

[Bug 66963] r600: linux 3.11RC isn't booting with radeon.dpm=1 option in grub

2013-07-30 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=66963

--- Comment #32 from Sergey  ---
Here are some testing results:
bug66963-no-voltage.diff - hangs 5 of 5 times
bug66963-no-cg.diff - hangs 5 of 5 times
bug66963-no-gen2.diff - hangs 5 of 5 times

bug66963-no-ss.diff
hanged 4 times, then 2 normal boots, 2 hangs, 1 boot with Xorg delays, 1 boot
with garbage for Xorq (tty console was fine), 1 hang
Very inconsistent.

Also retried all 4 together:
Boots OK most of the time, though I get 2 hangs and 1 Xorg big delays in
between ~10 successful tries. Specially if reset is used instead of shutdown,
but sometimes it happens after shutdown too.

Will continue trying other combinations.

-- 
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/20130730/674bf9f4/attachment.html>

[Bug 57875] Second Life viewer bad rendering with git-ec83535

2013-07-30 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=57875

Marek Ol??k  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #33 from Marek Ol??k  ---
I reverted the problematic commit:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=4dfe1a0df56d084b6a29fe423afe0535abec29e9

Closing.

-- 
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/20130730/6a213193/attachment.html>

Commit f5d9b7f0f9 (fix r600_enable_sclk_control()) causes kexec issues

2013-07-30 Thread Markus Trippelsdorf 
On 2013.07.30 at 10:53 -0400, Alex Deucher wrote:
> On Tue, Jul 30, 2013 at 7:27 AM, Markus Trippelsdorf
>  wrote:
> > On 2013.07.29 at 15:53 -0400, Alex Deucher wrote:
> >> On Mon, Jul 29, 2013 at 2:10 PM, Eric W. Biederman
> >>  wrote:
> >> > Alex Deucher  writes:
> >> >
> >> >> On Mon, Jul 29, 2013 at 11:50 AM, Eric W. Biederman
> >> >>  wrote:
> >> >>>
> >> >>>
> >> >>> Alex Deucher  wrote:
> >> On Mon, Jul 29, 2013 at 10:09 AM, Markus Trippelsdorf
> >>  wrote:
> >> > On 2013.07.29 at 09:58 -0400, Alex Deucher wrote:
> >> >> On Mon, Jul 29, 2013 at 3:51 AM, Markus Trippelsdorf
> >> >>  wrote:
> >> >> > On my test machine Xorg doesn't start anymore when I kexec into a
> >> >> > 3.11.0-rc3 kernel.
> >> >>
> >> >> With kexec, dpm doesn't get torn down properly which can result in a
> >> >> bad hardware state when the driver loads again.  Does the attached
> >> >> patch help?  It attempts to disable dpm at startup in case it wasn't
> >> >> torn down properly previously.
> >> >
> >> > dpm initialization now works, but unfortunately GPU acceleration
> >> still gets
> >> > disabled:
> >> 
> >> Stupid kexec complicates things.  We need to make sure dpm is torn
> >> down before we init the rest of the GPU, but dpm needs get initialized
> >> later in the init process since it depends on certain other state from
> >> the driver.  I need to think about this for a bit.  I'm not sure of a
> >> good way to handle this.
> >> >>>
> >> >>> You might just want to implement a shutdown method that cleans things 
> >> >>> up properly.   At least as a first pass until you worry about things 
> >> >>> like kexec on panic.
> >> >>>
> >> >>> Or can you not shutdown the graphics stack on reboot because of the 
> >> >>> need to display the kernels shutdown progress?
> >> >>
> >> >> Does kexec actually call this shutdown method?  The driver implements
> >> >> appropriate clean-up measures if it's shutdown properly.
> >> >
> >> > Absoltuely.  All parts of the reboot path call ->shutdown.  Including
> >> > kexec.
> >> >
> >> > You don't get a device remove/hotunplug but unless this is a kexec on
> >> > panic ->shutdown is most definitely called.  Now I am talking about the
> >> > device layer/pci layer shutdown method I don't know how gpu drivers are
> >> > wired up.  GPU land was a little strange last I looked.  Hopefully it
> >> > isn't so strange that there is a method named shutdown that is not wired
> >> > up.
> >>
> >> It doesn't look like the drm infrastructure has a shutdown callback.
> >> The drm drivers register a drm_driver callback struct that includes an
> >> unload callback which takes care of all the device teardown (if you
> >> unload the module for example).  I don't know that it actually gets
> >> called at kexec time however.  I don't know enough about how kexec
> >> works.
> >
> > BTW there is r100_restore_sanity() in drm/radeon/r100.c that explicitly
> > handles the kexec case during init. So maybe an r600_restore_sanity()
> > function is needed?
> >
> > (One of the advantages of using kexec (besides the much quicker boot
> > time) is that the monitor is not switched off and then on during boot.
> > I guess that advantage would be lost if the unload callback would be
> > called.)
> 
> r100_restore_sanity() is basically a set of hacks (that gets called at
> driver startup) to work around the fact that with kexec the drm driver
> is not torn down correctly.  So we could add a bunch more asic
> specific tear down sequences to deal with dpm (and all the other
> engines on the GPU that may potentially cause problems if they are not
> torn down properly), but that will just turn into a mess.  All of
> these hacks also add latency to the driver load.  I think the best
> solution would probably be to figure how to hook up the drm unload
> callback to the shutdown method that kexec uses.

FYI the following (ugly) hack works for me. 
(If I don't comment out radeon_fbdev_fini(rdev) kexec will hang.)

diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
index 75349cd..13e2988 100644
--- a/drivers/gpu/drm/radeon/r100.c
+++ b/drivers/gpu/drm/radeon/r100.c
@@ -3947,20 +3947,6 @@ void r100_fini(struct radeon_device *rdev)
  */
 void r100_restore_sanity(struct radeon_device *rdev)
 {
-   u32 tmp;
-
-   tmp = RREG32(RADEON_CP_CSQ_CNTL);
-   if (tmp) {
-   WREG32(RADEON_CP_CSQ_CNTL, 0);
-   }
-   tmp = RREG32(RADEON_CP_RB_CNTL);
-   if (tmp) {
-   WREG32(RADEON_CP_RB_CNTL, 0);
-   }
-   tmp = RREG32(RADEON_SCRATCH_UMSK);
-   if (tmp) {
-   WREG32(RADEON_SCRATCH_UMSK, 0);
-   }
 }

 int r100_init(struct radeon_device *rdev)
diff --git a/drivers/gpu/drm/radeon/radeon_display.c 
b/drivers/gpu/drm/radeon/radeon_display.c
index c2b67b4..79b38e2 100644
--- a/drivers/gpu/drm/radeon/radeon_display.c
+++ b/drivers/gpu/drm/radeon/radeon_display.c
@@ -1405,7

[Bug 59322] r300g MSAA breaks Half-Life 2 in Wine

2013-07-30 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=59322

Marek Ol??k  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #12 from Marek Ol??k  ---
Fixed by
http://cgit.freedesktop.org/mesa/mesa/commit/?id=1302c66896e6fbdb4eeb086d41901ddaeb89513f
Closing.

-- 
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/20130730/40cb8c64/attachment.html>

[PATCH 1/2] drm/i915: Add async page flip support for IVB

2013-07-30 Thread Ville Syrjälä 
On Thu, Jul 25, 2013 at 03:15:14PM -0700, Keith Packard wrote:
> This adds the necesary register defines for async page flipping
> through the command ring, and then hooks those up for Ivybridge (gen7)
> page flipping.

Maybe mention hsw in the patch subject/description too.

> 
> Signed-off-by: Keith Packard 
> ---
>  drivers/gpu/drm/i915/i915_reg.h  |  6 ++
>  drivers/gpu/drm/i915/intel_display.c | 37 
> 
>  2 files changed, 39 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index dc3d6a7..029cfb0 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -209,6 +209,7 @@
>  #define MI_LOAD_SCAN_LINES_INCL MI_INSTR(0x12, 0)
>  #define MI_DISPLAY_FLIP  MI_INSTR(0x14, 2)
>  #define MI_DISPLAY_FLIP_I915 MI_INSTR(0x14, 1)
> +#define   MI_DISPLAY_FLIP_ASYNC_INDICATOR(1 << 22)
>  #define   MI_DISPLAY_FLIP_PLANE(n) ((n) << 20)
>  /* IVB has funny definitions for which plane to flip. */
>  #define   MI_DISPLAY_FLIP_IVB_PLANE_A  (0 << 19)
> @@ -217,6 +218,11 @@
>  #define   MI_DISPLAY_FLIP_IVB_SPRITE_B (3 << 19)
>  #define   MI_DISPLAY_FLIP_IVB_PLANE_C  (4 << 19)
>  #define   MI_DISPLAY_FLIP_IVB_SPRITE_C (5 << 19)
> +/* These go in the bottom of the base address value */
> +#define   MI_DISPLAY_FLIP_TYPE_SYNC(0 << 0)
> +#define   MI_DISPLAY_FLIP_TYPE_ASYNC   (1 << 0)
> +#define   MI_DISPLAY_FLIP_TYPE_STEREO  (2 << 0)
> +#define   MI_DISPLAY_FLIP_TYPE_SYNCHRONOUS   (0 << 0)

Duplicated bit.

>  #define MI_ARB_ON_OFFMI_INSTR(0x08, 0)
>  #define   MI_ARB_ENABLE  (1<<0)
>  #define   MI_ARB_DISABLE (0<<0)
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index bdb8854..166aa2c 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -1833,8 +1833,10 @@ intel_pin_and_fence_fb_obj(struct drm_device *dev,
>   alignment = 64 * 1024;
>   break;
>   case I915_TILING_X:
> - /* pin() will align the object as required by fence */
> - alignment = 0;
> + /* Async page flipping requires X tiling and 32kB alignment, so 
> just
> +  * make all X tiled frame buffers aligned for that
> +  */
> + alignment = 32 * 1024;

You could limit this to gens for which you implemented async flips.

gen2/3 seem to require a 256KB alignment for async flips.

>   break;
>   case I915_TILING_Y:
>   /* Despite that we check this in framebuffer_init userspace can
> @@ -7514,6 +7516,8 @@ static int intel_gen7_queue_flip(struct drm_device *dev,
>   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
>   struct intel_ring_buffer *ring = _priv->ring[BCS];
>   uint32_t plane_bit = 0;
> + uint32_t cmd;
> + uint32_t base;
>   int ret;
>  
>   ret = intel_pin_and_fence_fb_obj(dev, obj, ring);
> @@ -7536,13 +7540,21 @@ static int intel_gen7_queue_flip(struct drm_device 
> *dev,
>   goto err_unpin;
>   }
>  
> + cmd = MI_DISPLAY_FLIP_I915 | plane_bit;
> + base = i915_gem_obj_ggtt_offset(obj) + intel_crtc->dspaddr_offset;
> +
> + if (flags & DRM_MODE_PAGE_FLIP_ASYNC) {
> + cmd |= MI_DISPLAY_FLIP_ASYNC_INDICATOR;
> + base |= MI_DISPLAY_FLIP_TYPE_ASYNC;
> + }
> +
>   ret = intel_ring_begin(ring, 4);
>   if (ret)
>   goto err_unpin;
>  
> - intel_ring_emit(ring, MI_DISPLAY_FLIP_I915 | plane_bit);
> + intel_ring_emit(ring, cmd);
>   intel_ring_emit(ring, (fb->pitches[0] | obj->tiling_mode));
> - intel_ring_emit(ring, i915_gem_obj_ggtt_offset(obj) + 
> intel_crtc->dspaddr_offset);
> + intel_ring_emit(ring, base);
>   intel_ring_emit(ring, (MI_NOOP));
>  
>   intel_mark_page_flip_active(intel_crtc);
> @@ -7591,6 +7603,19 @@ static int intel_crtc_page_flip(struct drm_crtc *crtc,
>fb->pitches[0] != crtc->fb->pitches[0]))
>   return -EINVAL;
>  
> + /* Check tiling restrictions specific to asynchronous flips
> +  */
> + if (page_flip_flags & DRM_MODE_PAGE_FLIP_ASYNC) {
> +
> + /* New FB must be X tiled */
> + if (obj->tiling_mode != I915_TILING_X)
> + return -EINVAL;
> +
> + /* Current FB must be X tiled */
> + if (to_intel_framebuffer(old_fb)->obj->tiling_mode != 
> I915_TILING_X)
> + return -EINVAL;
> + }
> +
>   work = kzalloc(sizeof *work, GFP_KERNEL);
>   if (work == NULL)
>   return -ENOMEM;
> @@ -9705,6 +9730,10 @@ void intel_modeset_init(struct drm_device *dev)
>   dev->mode_config.max_width = 8192;
>   dev->mode_config.max_height = 8192;
>   }
> +
> + if (IS_GEN7(dev))
> + dev->mode_config.async_page_flip =

[Bug 66963] r600: linux 3.11RC isn't booting with radeon.dpm=1 option in grub

2013-07-30 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=66963

--- Comment #31 from Alex Deucher  ---
please make sure to cold reset between attempts.

-- 
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/20130730/77c0d62c/attachment.html>

[Bug 66963] r600: linux 3.11RC isn't booting with radeon.dpm=1 option in grub

2013-07-30 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=66963

--- Comment #30 from Alex Deucher  ---
Created attachment 83327
  --> https://bugs.freedesktop.org/attachment.cgi?id=83327=edit
disable dynamic pcie gen2

-- 
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/20130730/75717b7f/attachment.html>

[Bug 66963] r600: linux 3.11RC isn't booting with radeon.dpm=1 option in grub

2013-07-30 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=66963

--- Comment #29 from Alex Deucher  ---
Created attachment 83326
  --> https://bugs.freedesktop.org/attachment.cgi?id=83326=edit
disable dynamic spread spectrum

-- 
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/20130730/13386ed7/attachment.html>

[Bug 66963] r600: linux 3.11RC isn't booting with radeon.dpm=1 option in grub

2013-07-30 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=66963

--- Comment #28 from Alex Deucher  ---
Created attachment 83325
  --> https://bugs.freedesktop.org/attachment.cgi?id=83325=edit
disable clockgating

-- 
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/20130730/89f28900/attachment.html>

[Bug 66963] r600: linux 3.11RC isn't booting with radeon.dpm=1 option in grub

2013-07-30 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=66963

--- Comment #27 from Alex Deucher  ---
Created attachment 83324
  --> https://bugs.freedesktop.org/attachment.cgi?id=83324=edit
disable voltage control

The following 4 patches disable specific dpm features:

bug66963-no-voltage.diff - disables automatic voltage control
bug66963-no-cg.diff - disables clockgating
bug66963-no-ss.diff - disables dynamic spread spectrum
bug66963-no-gen2.diff - disables dynamic pcie gen2 selection

Please let me know what patch or combination of patches fixes the issues.

-- 
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/20130730/54218df6/attachment.html>

[Intel-gfx] [PATCH 2/2] drm/i915: Add async page flip support for SNB

2013-07-30 Thread Ville Syrjälä 
On Thu, Jul 25, 2013 at 03:15:15PM -0700, Keith Packard wrote:
> Just copies the IVB code
> 
> Signed-off-by: Keith Packard 
> ---
>  drivers/gpu/drm/i915/intel_display.c | 17 +
>  1 file changed, 13 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 166aa2c..4a118c3 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -7465,20 +7465,29 @@ static int intel_gen6_queue_flip(struct drm_device 
> *dev,
>   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
>   struct intel_ring_buffer *ring = _priv->ring[RCS];
>   uint32_t pf, pipesrc;
> + uint32_t cmd;
> + uint32_t base;
>   int ret;
>  
>   ret = intel_pin_and_fence_fb_obj(dev, obj, ring);
>   if (ret)
>   goto err;
>  
> + cmd = MI_DISPLAY_FLIP | MI_DISPLAY_FLIP_PLANE(intel_crtc->plane);
> + base = i915_gem_obj_ggtt_offset(obj) + intel_crtc->dspaddr_offset;
> +
> + if (flags & DRM_MODE_PAGE_FLIP_ASYNC) {
> + cmd |= MI_DISPLAY_FLIP_ASYNC_INDICATOR;
> + base |= MI_DISPLAY_FLIP_TYPE_ASYNC;
> + }
> +
>   ret = intel_ring_begin(ring, 4);
>   if (ret)
>   goto err_unpin;
>  
> - intel_ring_emit(ring, MI_DISPLAY_FLIP |
> - MI_DISPLAY_FLIP_PLANE(intel_crtc->plane));
> + intel_ring_emit(ring, cmd);
>   intel_ring_emit(ring, fb->pitches[0] | obj->tiling_mode);
> - intel_ring_emit(ring, i915_gem_obj_ggtt_offset(obj) + 
> intel_crtc->dspaddr_offset);
> + intel_ring_emit(ring, base);
>  
>   /* Contrary to the suggestions in the documentation,
>* "Enable Panel Fitter" does not seem to be required when page

This PF flip stuff is a bit of a mystery. I'm not sure it exists on SNB
anymore. Some of the docs say that it's MBZ for SNB/IVB. Gen4/5 docs
say that DW3 must not be sent w/ async flips, and some SNB+ docs say
that it must not be sent with either sync or async flips.

Did you test this patch on actual hardware, and if so did it work as
expected? :)

I guess one would need to perform some empirical testing to figure out
what DW3 actually does.

> @@ -9731,7 +9740,7 @@ void intel_modeset_init(struct drm_device *dev)
>   dev->mode_config.max_height = 8192;
>   }
>  
> - if (IS_GEN7(dev))
> + if (IS_GEN6(dev) || IS_GEN7(dev))
>   dev->mode_config.async_page_flip = true;
>  
>   dev->mode_config.fb_base = dev_priv->gtt.mappable_base;
> -- 
> 1.8.3.2
> 
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Ville Syrj?l?
Intel OTC

[Bug 66963] r600: linux 3.11RC isn't booting with radeon.dpm=1 option in grub

2013-07-30 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=66963

--- Comment #26 from Sergey  ---
Created attachment 83321
  --> https://bugs.freedesktop.org/attachment.cgi?id=83321=edit
dmesg for patches from comment 23 and 24

Here are results:

With patch from comment 23: 1 hang in 5 boots, good work (no delays in Xorg).
Hang was on first try after hot reset, and was never seen afterwards.

With patch from comment 24: 2 hang in 4 boots, huge delays in Xorg (same as was
before)

With patch from comment 25: never got booted after 10 iterations. (behavior
might be similar as it was without this patch, but less luck during testing)

-- 
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/20130730/3c7f04fd/attachment.html>

[Bug 60523] Lockup with radeon DPM on Radeon HD5770 (Juniper)

2013-07-30 Thread bugzilla-dae...@bugzilla.kernel.org 
https://bugzilla.kernel.org/show_bug.cgi?id=60523

--- Comment #8 from Alex Deucher  ---
Does this patch help?

diff --git a/drivers/gpu/drm/radeon/cypress_dpm.c
b/drivers/gpu/drm/radeon/cypress_dpm.c
index 9bcdd17..1acbddb 100644
--- a/drivers/gpu/drm/radeon/cypress_dpm.c
+++ b/drivers/gpu/drm/radeon/cypress_dpm.c
@@ -2113,7 +2113,7 @@ int cypress_dpm_init(struct radeon_device *rdev)
(rdev->family == CHIP_HEMLOCK))
pi->gfx_clock_gating = false;
else
-   pi->gfx_clock_gating = true;
+   pi->gfx_clock_gating = false;//true;

pi->mg_clock_gating = true;
pi->mgcgtssm = true;

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 60523] Lockup with radeon DPM on Radeon HD5770 (Juniper)

2013-07-30 Thread bugzilla-dae...@bugzilla.kernel.org 
https://bugzilla.kernel.org/show_bug.cgi?id=60523

--- Comment #7 from Tobias Droste  ---
Created attachment 107045
  --> https://bugzilla.kernel.org/attachment.cgi?id=107045=edit
dmesg | grep -iE "drm|radeon|power|uvd"

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 60523] Lockup with radeon DPM on Radeon HD5770 (Juniper)

2013-07-30 Thread bugzilla-dae...@bugzilla.kernel.org 
https://bugzilla.kernel.org/show_bug.cgi?id=60523

--- Comment #6 from Alex Deucher  ---
Please attach your dmesg output with the latest drm bits.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 67187] Radeon HD6950: UVD not responding, trying to reset the VCPU

2013-07-30 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=67187

--- Comment #7 from Harald Judt  ---
Further tests show:

* the 0xCAFEDEAD seems to have been a one-time error that usually does not
occur
* in case of problems, "UVD not responding" does not always appear and is
successfully initialized, but the ring 5 error usually does
  radeon :01:00.0: GPU lockup (waiting for 0x0008 last fence id
0x0006)
  [drm:r600_uvd_ib_test] *ERROR* radeon: fence wait failed (-35).
  [drm:radeon_ib_ring_tests] *ERROR* radeon: failed testing IB on ring 5 (-35).
* it does not always hang when suspending, yet resume might still fail
* enabling pm_async makes suspend/resume fail sometimes with "uvd not
responding", while the process appears to be quite stable with pm_async
deactivated (may only be harder to reproduce, still needs more testing)
* hibernate/resume will fail with pm_async deactivated sometimes, and pretty
reliably with pm_async enabled

Pretty weird...

-- 
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/20130730/6e80b784/attachment.html>

[pull] radeon drm-fixes-3.11

2013-07-30 Thread alexdeuc...@gmail.com 
From: Alex Deucher 

Hi Dave,

A few more fixes for radeon on top of the ones I sent yesterday.
- more fixes for SI dpm
- fix DP on some rv6xx boards

The following changes since commit 63f22d0e98cf74adf4ecfb25099607239b00c751:

  drm/radeon/dpm: fix and enable reclocking on SI (2013-07-29 18:14:42 -0400)

are available in the git repository at:
  git://people.freedesktop.org/~agd5f/linux drm-fixes-3.11

Alex Deucher (4):
  drm/radeon/atom: initialize more atom interpretor elements to 0
  drm: fix 64 bit drm fixed point helpers
  drm/radeon/dpm: fix calculations in 
si_calculate_leakage_for_v_and_t_formula
  drm/radeon/dpm: re-enable cac control on SI

 drivers/gpu/drm/radeon/atom.c   |5 +
 drivers/gpu/drm/radeon/si_dpm.c |   11 ++-
 include/drm/drm_fixed.h |   14 +++---
 3 files changed, 18 insertions(+), 12 deletions(-)

[Bug 60523] Lockup with radeon DPM on Radeon HD5770 (Juniper)

2013-07-30 Thread bugzilla-dae...@bugzilla.kernel.org 
https://bugzilla.kernel.org/show_bug.cgi?id=60523

Tobias Droste  changed:

   What|Removed |Added

 Kernel Version|3.10-drm-next-3.11  |drm-fixes-3.11

--- Comment #5 from Tobias Droste  ---
In case you are wondering if this was somehow fixed with your latest patches:
It wasn't ;-)

Good news is: 
No lockups!

Bad news: 
It's still not automatically switching power levels.
The only way to get it into a lower power level is to run a small video with a
player using UVD. After closing the player the power level goes to 0. But as
soon as something needs some more power the level goes back to 2 and stays
there, even when the load is low again.

and this is still happening:
# echo low > power_dpm_force_performance_level
bash: echo: write error: Invalid argument

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 67550] Radeon+Intel GPU with HDMI audio on Intel

2013-07-30 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=67550

--- Comment #4 from Christian K?nig  ---
(In reply to comment #0)

> #2, without xorg.conf
> The receiver sends its own EDID block, so I can extend via xrandr without
> turning on the projector.
> But the projector is turned off in most cases, so is there a way to disable
> a display output but keep the HDMI audio output? (as a workaround for #1)

Nope, unfortunately not. It's by HDMI design, the audio signal is mixed into
the vertical and horizontal blank periods of the video signal -> so if you
don't have a video signal you don't have audio also.

As a workaround you could try to setup a second X server or framebuffer or
something like that (kms console?) on the HDMI output to just get a video
signal on it.

-- 
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/20130730/7b90490d/attachment.html>

[Bug 66942] Cayman HD 6950 hangs at start when loading kernel 3.11.0-rc1 or drm-next

2013-07-30 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=66942

--- Comment #21 from Alexandre Demers  ---
(In reply to comment #18)
> (In reply to comment #17)
> > Alex, is there a chance for me to reverse some commits prior to 69e0b57 to
> > find which one or which feature is hanging my computer? Any approach I
> > should try?
> 
> I'm not really sure what would have broken your system.  I also don't really
> see how 69e0b57 could have broken anything since nothing changes with that
> as long as dpm is disabled.  Do you still have the issue if you reset your
> tree to the commit prior to 69e0b57?  Do you still get hangs if you disable
> radeon (e.g., add radeon.modeset=0 to your kernel command line in grub)?

I'll have to test when I'll get home, but I rebuilt a rc3 yesterday night and I
made sure to make it clean. I'll see if this helps. I'll also go back just
prior to 69e0b57 if it doesn't help. Finally, I'll play with the init and
disable some options just in case. Who knows what might help.

-- 
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/20130730/bbc59272/attachment-0001.html>

[PATCH 3/3] drm: Remove drm_mode_validate_clocks

2013-07-30 Thread Stéphane Marchesin 
Signed-off-by: St?phane Marchesin 
---
 drivers/gpu/drm/drm_modes.c | 37 -
 include/drm/drm_crtc.h  |  3 ---
 2 files changed, 40 deletions(-)

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index a6729bf..504a602 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -923,43 +923,6 @@ void drm_mode_validate_size(struct drm_device *dev,
 EXPORT_SYMBOL(drm_mode_validate_size);

 /**
- * drm_mode_validate_clocks - validate modes against clock limits
- * @dev: DRM device
- * @mode_list: list of modes to check
- * @min: minimum clock rate array
- * @max: maximum clock rate array
- * @n_ranges: number of clock ranges (size of arrays)
- *
- * LOCKING:
- * Caller must hold a lock protecting @mode_list.
- *
- * Some code may need to check a mode list against the clock limits of the
- * device in question.  This function walks the mode list, testing to make
- * sure each mode falls within a given range (defined by @min and @max
- * arrays) and sets @mode->status as needed.
- */
-void drm_mode_validate_clocks(struct drm_device *dev,
- struct list_head *mode_list,
- int *min, int *max, int n_ranges)
-{
-   struct drm_display_mode *mode;
-   int i;
-
-   list_for_each_entry(mode, mode_list, head) {
-   bool good = false;
-   for (i = 0; i < n_ranges; i++) {
-   if (mode->clock >= min[i] && mode->clock <= max[i]) {
-   good = true;
-   break;
-   }
-   }
-   if (!good)
-   mode->status = MODE_CLOCK_RANGE;
-   }
-}
-EXPORT_SYMBOL(drm_mode_validate_clocks);
-
-/**
  * drm_mode_prune_invalid - remove invalid modes from mode list
  * @dev: DRM device
  * @mode_list: list of modes to check
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index fa12a2f..32e0820 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -930,9 +930,6 @@ extern void drm_mode_list_concat(struct list_head *head,
 extern void drm_mode_validate_size(struct drm_device *dev,
   struct list_head *mode_list,
   int maxX, int maxY, int maxPitch);
-extern void drm_mode_validate_clocks(struct drm_device *dev,
-struct list_head *mode_list,
-int *min, int *max, int n_ranges);
 extern void drm_mode_prune_invalid(struct drm_device *dev,
   struct list_head *mode_list, bool verbose);
 extern void drm_mode_sort(struct list_head *mode_list);
-- 
1.8.3

[PATCH 2/3] drm/i915: Remove useless define

2013-07-30 Thread Stéphane Marchesin 
Signed-off-by: St?phane Marchesin 
---
 drivers/gpu/drm/i915/intel_display.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 5fb3058..37b33c9 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -54,7 +54,6 @@ typedef struct {
int p2_slow, p2_fast;
 } intel_p2_t;

-#define INTEL_P2_NUM 2
 typedef struct intel_limit intel_limit_t;
 struct intel_limit {
intel_range_t   dot, vco, n, m, m1, m2, p, p1;
-- 
1.8.3

[PATCH 1/3] drm/gma500: Remove useless define

2013-07-30 Thread Stéphane Marchesin 
Signed-off-by: St?phane Marchesin 
---
 drivers/gpu/drm/gma500/cdv_intel_display.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/gma500/cdv_intel_display.c 
b/drivers/gpu/drm/gma500/cdv_intel_display.c
index 82430ad..d691a3a 100644
--- a/drivers/gpu/drm/gma500/cdv_intel_display.c
+++ b/drivers/gpu/drm/gma500/cdv_intel_display.c
@@ -52,8 +52,6 @@ struct cdv_intel_clock_t {
int p;
 };

-#define INTEL_P2_NUM 2
-
 struct cdv_intel_limit_t {
struct cdv_intel_range_t dot, vco, n, m, m1, m2, p, p1;
struct cdv_intel_p2_t p2;
-- 
1.8.3

[Bug 66942] Cayman HD 6950 hangs at start when loading kernel 3.11.0-rc1 or drm-next

2013-07-30 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=66942

--- Comment #20 from Alexandre Demers  ---
(In reply to comment #19)
> Does booting a recent 3.11rc kernel with radeon.aspm=0 help?

No, still hangs at the same point.

-- 
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/20130730/fd6600c9/attachment.html>

[Bug 67550] Radeon+Intel GPU with HDMI audio on Intel

2013-07-30 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=67550

--- Comment #3 from Andre Heider  ---
Created attachment 83314
  --> https://bugs.freedesktop.org/attachment.cgi?id=83314=edit
xorg log with xorg.conf

-- 
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/20130730/987c16f1/attachment.html>

[Bug 67550] Radeon+Intel GPU with HDMI audio on Intel

2013-07-30 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=67550

--- Comment #2 from Andre Heider  ---
Created attachment 83313
  --> https://bugs.freedesktop.org/attachment.cgi?id=83313=edit
xorg log without xorg.conf

-- 
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/20130730/c46e19f0/attachment.html>

[Bug 67550] Radeon+Intel GPU with HDMI audio on Intel

2013-07-30 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=67550

--- Comment #1 from Andre Heider  ---
Created attachment 83312
  --> https://bugs.freedesktop.org/attachment.cgi?id=83312=edit
xorg.conf

-- 
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/20130730/52aaf516/attachment.html>

[Bug 67550] New: Radeon+Intel GPU with HDMI audio on Intel

2013-07-30 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=67550

  Priority: medium
Bug ID: 67550
  Assignee: dri-devel at lists.freedesktop.org
   Summary: Radeon+Intel GPU with HDMI audio on Intel
  Severity: normal
Classification: Unclassified
OS: Linux (All)
  Reporter: a.heider at gmail.com
  Hardware: x86-64 (AMD64)
Status: NEW
   Version: DRI CVS
 Component: General
   Product: DRI

I have multiple, but related, issues with a dual GPU setup:
1) cursor flickering
2) no HDMI audio on secondary GPU without extending X11 for that output
3) xrandr broken with xorg.conf describing the dual setup
4) driQueryOptioni() not multi GPU aware (crash in mesa)

Setup:
Radeon 6850 PCIe as primary device, connected to a TFT over DVI
HD4000 on Ivybridge as secondary device, connected to a receiver over HDMI
(plus a projector connected to my receiver via HDMI)
Pretty much the latest and greatest of everything in the graphics stack.

Why the secondary connection? It's used to get multichannel audio to my
receiver, which isn't possible with the additional radeon HDMI head.

If I extend my desktop via:
xrandr --output $intel_hdmi --right-of $radeon_dvi --mode 1280x720 --refresh 60
It properly extends the display to the secondary GPU. I get a picture on the
projector, as well as HDMI audio on the receiver.

#1, without xorg.conf
Now with both outputs enabled there is a mouse cursor issue with apps on the
primary output:

* mplayer (without using vdpau), dvb-t viewer or firefox+flash: when moving the
cursor over the video output, there's a rectangle of garbage around the cursor.
Looks like a rect of a prior frame on a broken alpha mask. The issue with
mplayer vanishes when using vdpau.
* The cursor in full screen GL games flickers. One frame it's there, then
vanishes some later, but mostly its gone, making GUIs a real pita.

If I disable the $intel_hdmi output again the problem goes away. But that
brings us to the second problem:

#2, without xorg.conf
The receiver sends its own EDID block, so I can extend via xrandr without
turning on the projector.
But the projector is turned off in most cases, so is there a way to disable a
display output but keep the HDMI audio output? (as a workaround for #1)

I found:
xrandr --output $intel_hdmi --set audio force-dvi|off|auto|on
but it seems that only works if the display output is enabled (or I'm too
stupid to properly use xrandr)...

#3 with xorg.conf
xrandr thinks HDMI isn't connected to the Intel GPU, and hence doesn't allow to
toggle it, yet HDMI audio over it just works. While that would probably work
around #1 I cannot tell because then I run into:

#4 with xorg.conf
All GL apps crash with:
glxinfo: /home/andre/devel/mesa/src/mesa/drivers/dri/common/xmlconfig.c:1030:
driQueryOptioni: Assertion `cache->info[i].name != ((void *)0)' failed.

-- 
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/20130730/3ba1cd52/attachment.html>

[PATCH 4/4] snd/hda: add runtime suspend/resume on optimus support

2013-07-30 Thread Dave Airlie 
On Mon, Jul 29, 2013 at 10:46 PM, Takashi Iwai  wrote:
> At Mon, 29 Jul 2013 16:06:59 +1000,
> Dave Airlie wrote:
>>
>> Add support for HDMI audio device on VGA cards that powerdown
>> to D3cold using non-standard ACPI/PCI infrastructure (optimus).
>>
>> This does a couple of things to make it work:
>>
>> a) add a set of power ops for the hdmi domain, and enables them
>> via vga_switcheroo when we are a switcheroo controlled card. This
>> just replaces the runtime resume operation so that when the card
>> is in D3cold the userspace pci config space access via sysfs,
>> the vga switcheroon runtime resume gets called first and it calls
>> the GPU resume callback before calling the sound card runtime
>> resume.
>>
>> b) standard ACPI/PCI stacks won't put a device into D3cold without
>> an ACPI handle, but since the hdmi audio devices on gpus don't have
>> an ACPI handle, we need to manually force the device into D3cold
>> after suspend from the switcheroo path only.
>>
>> c) don't try and do runtime s/r when the GPU is off.
>>
>> d) call runtime suspend/resume during switcheroo suspend/resume
>> this is to make sure the runtime stack knows to try and resume
>> the hdmi audio device for pci config space access.
>>
>> Signed-off-by: Dave Airlie 
>> ---
>>  sound/pci/hda/hda_intel.c | 40 +---
>>  1 file changed, 37 insertions(+), 3 deletions(-)
>>
>> diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
>> index 8860dd5..4b4d05b 100644
>> --- a/sound/pci/hda/hda_intel.c
>> +++ b/sound/pci/hda/hda_intel.c
>> @@ -555,6 +555,9 @@ struct azx {
>>  #ifdef CONFIG_SND_HDA_DSP_LOADER
>>   struct azx_dev saved_azx_dev;
>>  #endif
>> +
>> + /* secondary power domain for hdmi audio under vga device */
>> + struct dev_pm_domain hdmi_pm_domain;
>>  };
>>
>>  #define CREATE_TRACE_POINTS
>> @@ -2898,7 +2901,7 @@ static int param_set_xint(const char *val, const 
>> struct kernel_param *kp)
>>  /*
>>   * power management
>>   */
>> -static int azx_suspend(struct device *dev)
>> +static int azx_do_suspend(struct device *dev, pci_power_t state)
>>  {
>>   struct pci_dev *pci = to_pci_dev(dev);
>>   struct snd_card *card = dev_get_drvdata(dev);
>> @@ -2920,16 +2923,30 @@ static int azx_suspend(struct device *dev)
>>   free_irq(chip->irq, chip);
>>   chip->irq = -1;
>>   }
>> +
>> + /*
>> +  * for vga switcheroo suspend we need to
>> +  * force runtime suspend so lspci works.
>> +  */
>> + if (state == PCI_D3cold)
>> + pm_runtime_suspend(>dev);
>> +
>>   if (chip->msi)
>>   pci_disable_msi(chip->pci);
>>   pci_disable_device(pci);
>>   pci_save_state(pci);
>> - pci_set_power_state(pci, PCI_D3hot);
>> +
>> + pci_set_power_state(pci, state);
>>   if (chip->driver_caps & AZX_DCAPS_I915_POWERWELL)
>>   hda_display_power(false);
>>   return 0;
>>  }
>>
>> +static int azx_suspend(struct device *dev)
>> +{
>> + return azx_do_suspend(dev, PCI_D3hot);
>> +}
>> +
>>  static int azx_resume(struct device *dev)
>>  {
>>   struct pci_dev *pci = to_pci_dev(dev);
>> @@ -2971,6 +2988,9 @@ static int azx_runtime_suspend(struct device *dev)
>>   struct snd_card *card = dev_get_drvdata(dev);
>>   struct azx *chip = card->private_data;
>>
>> + if (chip->disabled)
>> + return 0;
>> +
>>   azx_stop_chip(chip);
>>   azx_enter_link_reset(chip);
>>   azx_clear_irq_pending(chip);
>> @@ -2984,6 +3004,9 @@ static int azx_runtime_resume(struct device *dev)
>>   struct snd_card *card = dev_get_drvdata(dev);
>>   struct azx *chip = card->private_data;
>>
>> + if (chip->disabled)
>> + return 0;
>> +
>>   if (chip->driver_caps & AZX_DCAPS_I915_POWERWELL)
>>   hda_display_power(true);
>>   azx_init_pci(chip);
>> @@ -2996,6 +3019,9 @@ static int azx_runtime_idle(struct device *dev)
>>   struct snd_card *card = dev_get_drvdata(dev);
>>   struct azx *chip = card->private_data;
>>
>> + if (chip->disabled)
>> + return 0;
>> +
>>   if (!power_save_controller ||
>>   !(chip->driver_caps & AZX_DCAPS_PM_RUNTIME))
>>   return -EBUSY;
>> @@ -3078,7 +3104,11 @@ static void azx_vs_set_state(struct pci_dev *pci,
>>  "%s: %s via VGA-switcheroo\n", pci_name(chip->pci),
>>  disabled ? "Disabling" : "Enabling");
>>   if (disabled) {
>> - azx_suspend(>dev);
>> + azx_do_suspend(>dev, PCI_D3cold);
>> + /* when we get suspended by vga switcheroo we end up 
>> in D3cold,
>> +  * however we have no ACPI handle, so pci/acpi can't 
>> put us there,
>> +  * put ourselves there */
>> + pci->current_state = PCI_D3cold;
>>   chip->disabled = true;
>>   if

[PATCH] drm/cirrus: Invalidate page tables when pinning a BO

2013-07-30 Thread Michal Srb 
This is a cirrus version of Egbert Eich's patch for mgag200.

Without bo.bdev->dev_mapping set, the ttm_bo_unmap_virtual_locked
called from ttm_bo_handle_move_mem returns with no effect. If any
application accessed the memory before it was moved, it will
access wrong memory next time. This causes crashes when changing
resolution down.

Signed-off-by: Michal Srb 
---
diff --git a/drivers/gpu/drm/cirrus/cirrus_ttm.c 
b/drivers/gpu/drm/cirrus/cirrus_ttm.c
index 0047012..69fd8f1 100644
--- a/drivers/gpu/drm/cirrus/cirrus_ttm.c
+++ b/drivers/gpu/drm/cirrus/cirrus_ttm.c
@@ -328,6 +328,7 @@ int cirrus_bo_create(struct drm_device *dev, int size, int 
align,

cirrusbo->gem.driver_private = NULL;
cirrusbo->bo.bdev = >ttm.bdev;
+   cirrusbo->bo.bdev->dev_mapping = dev->dev_mapping;

cirrus_ttm_placement(cirrusbo, TTM_PL_FLAG_VRAM | TTM_PL_FLAG_SYSTEM);

[PATCH 1/3] drm/nouveau: fix vblank interrupt being called before event is setup

2013-07-30 Thread Ben Skeggs 
On Tue, Jul 30, 2013 at 4:10 PM, Maarten Lankhorst
 wrote:
> Op 30-07-13 04:42, Ben Skeggs schreef:
>> On Tue, Jul 23, 2013 at 11:43 PM, Maarten Lankhorst
>>  wrote:
>>> Sort of fixes mmiotrace for me again, I could sear I sent a similar patch 
>>> before
>>> the rework to event interface, so I guess it got reintroduced.
>> I don't know how/why you think this fixes anything.  The interrupt
>> handler can't possibly be called until after priv->base.vblank has
>> been initialised...
>>
>> Seriously, go look, the subdev interrupt handler pointer isn't filled
>> in (and can't be) until after nouveau_disp_create() has been called,
>> and nouveau_disp_create() initialises priv->base.vblank before it
>> returns...
>>
> There's also a disp_dtor function right above it and without a smp_wmb
> the writes could still be reordered in the constructor. O:-) A spinlock would
> be needed to make sure that no interrupt is in process if you set intr to null
> before destroying vblank event, though.
>
> I can probably try to get the oops again indicating that priv->base.vblank 
> was null in the interrupt handler if you want,
> iirc it happened reliably during mmiotracing.
It would've had to have happened during a module unload in that case,
I can't see how else it could've possibly happened.

The destructor case is valid though, but not really a critical issue,
so I'd rather find a better solution than these hacked checks :)  I'll
add it to the list...

Ben.

>
> ~Maarten

[Intel-gfx] [PATCH] drm/i915: make user mode sync polarity setting explicit

2013-07-30 Thread Imre Deak 
On Tue, 2013-07-30 at 15:43 +0300, Imre Deak wrote:
> On Tue, 2013-07-30 at 11:57 +0100, Chris Wilson wrote:
> > On Tue, Jul 30, 2013 at 01:36:32PM +0300, Imre Deak wrote:
> > > Userspace can pass a mode with an unspecified vsync/hsync polarity
> > > setting. All encoders in the Intel driver take this to mean a negative
> > > polarity setting. The HW readout/state checker code on the other hand
> > > needs these flags to be explicitly set, otherwise the state checker will
> > > WARN about the mismatch.
> > > 
> > > Get rid of the WARN by making the polarity setting explicit in the
> > > adjusted mode flags based on the requested mode flags. This will keep
> > > the existing behavior otherwise.
> > > 
> > > Note that we could guess from the other timing parameters whether the
> > > user wanted a VESA or other standard mode and set the polarity
> > > accordingly. This is what the NV driver does
> > > (drivers/gpu/drm/nouveau/dispnv04/crtc.c), but I think that's not very
> > > exact and would change the existing behavior of the Intel driver.
> > 
> > Right, don't guess. If the user wanted the standard mode, then the flags
> > would have been taken from the standard modeline.
> >  
> > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65442
> > 
> > You can add a tested-by here for qa.
> 
> Tested-by: Cancan Feng 
>  
> > > Signed-off-by: Imre Deak 
> > Reviewed-by: Chris Wilson 
> 
> CC'ing people who might be interested.
> 
> After some discussion with Ville, we could refine this further at the
> drm core level by enforcing the Intel behavior - defaulting to negative
> polarity and also checking/sanitizing the PHSYNC/PVSYNC flags.
> PHSYNC/PVSYNC isn't used by the Intel driver so we could still go with

Sorry, I meant PCSYNC/NCSYNC above.

--Imre

> the above patch for now and follow-up with a drm core fix.
> 
> We should probably also reject modes at drm core level where both
> positive and negative flags are set, again in a separate follow-up
> patch.
> 
> --Imre

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130730/542259e6/attachment.pgp>

[Intel-gfx] [PATCH] drm/i915: make user mode sync polarity setting explicit

2013-07-30 Thread Imre Deak 

On Tue, 2013-07-30 at 11:57 +0100, Chris Wilson wrote:
> On Tue, Jul 30, 2013 at 01:36:32PM +0300, Imre Deak wrote:
> > Userspace can pass a mode with an unspecified vsync/hsync polarity
> > setting. All encoders in the Intel driver take this to mean a negative
> > polarity setting. The HW readout/state checker code on the other hand
> > needs these flags to be explicitly set, otherwise the state checker will
> > WARN about the mismatch.
> > 
> > Get rid of the WARN by making the polarity setting explicit in the
> > adjusted mode flags based on the requested mode flags. This will keep
> > the existing behavior otherwise.
> > 
> > Note that we could guess from the other timing parameters whether the
> > user wanted a VESA or other standard mode and set the polarity
> > accordingly. This is what the NV driver does
> > (drivers/gpu/drm/nouveau/dispnv04/crtc.c), but I think that's not very
> > exact and would change the existing behavior of the Intel driver.
> 
> Right, don't guess. If the user wanted the standard mode, then the flags
> would have been taken from the standard modeline.
>  
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65442
> 
> You can add a tested-by here for qa.

Tested-by: Cancan Feng 

> > Signed-off-by: Imre Deak 
> Reviewed-by: Chris Wilson 

CC'ing people who might be interested.

After some discussion with Ville, we could refine this further at the
drm core level by enforcing the Intel behavior - defaulting to negative
polarity and also checking/sanitizing the PHSYNC/PVSYNC flags.
PHSYNC/PVSYNC isn't used by the Intel driver so we could still go with
the above patch for now and follow-up with a drm core fix.

We should probably also reject modes at drm core level where both
positive and negative flags are set, again in a separate follow-up
patch.

--Imre
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130730/46198ba6/attachment.pgp>

[edid-decode] Decode HDMI 1.4 4k VICs

2013-07-30 Thread Damien Lespiau 
Signed-off-by: Damien Lespiau 
---
 edid-decode.c | 15 +--
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/edid-decode.c b/edid-decode.c
index 9840db6..f74bbe4 100644
--- a/edid-decode.c
+++ b/edid-decode.c
@@ -625,7 +625,7 @@ cea_hdmi_block(unsigned char *x)

if (x[8] & 0x20) {
int mask = 0, formats = 0;
-   int len_xx, len_3d;
+   int len_vic, len_3d;
printf("Extended HDMI video details:\n");
if (x[9 + b] & 0x80)
printf("  3D present\n");
@@ -650,14 +650,17 @@ cea_hdmi_block(unsigned char *x)
printf("  Base EDID image size is in units of 5cm\n");
break;
}
-   len_xx = (x[10 + b] & 0xe0) >> 5;
+   len_vic = (x[10 + b] & 0xe0) >> 5;
len_3d = (x[10 + b] & 0x1f) >> 0;
b += 2;

-   if (len_xx) {
-   printf("  Skipping %d bytes that HDMI refuses to publicly"
-  " document\n", len_xx);
-   b += len_xx;
+   if (len_vic) {
+   int i;
+
+   for (i = 0; i < len_vic; i++)
+   printf("  HDMI VIC %d\n", x[9 + b + i]);
+
+   b += len_vic;
}

if (len_3d) {
-- 
1.8.3.1

[Bug 67435] HDMI audio silent on Radeon Mobility HD4650

2013-07-30 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=67435

--- Comment #17 from Christian K?nig  ---
It's just a guess, but could you just try the following (without any patches):

avivotool regset 0x0514 0x00249f00

Does that helps as well?

-- 
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/20130730/9c2cf6cc/attachment.html>

[Bug 67435] HDMI audio silent on Radeon Mobility HD4650

2013-07-30 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=67435

--- Comment #16 from Alex Deucher  ---
Created attachment 83304
  --> https://bugs.freedesktop.org/attachment.cgi?id=83304=edit
fix

This patch should fix it.

-- 
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/20130730/ee281241/attachment.html>

[Bug 67435] HDMI audio silent on Radeon Mobility HD4650

2013-07-30 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=67435

--- Comment #15 from Kris Scott  ---
Tried it, that did not fix the sound.

-- 
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/20130730/675f6de9/attachment.html>

[RFC 0/2] exynos5250/hdmi: replace dummy hdmiphy clock with pmu reg control

2013-07-30 Thread Seung-Woo Kim 
Hi Rahul,

On 2013? 07? 30? 12:42, Rahul Sharma wrote:
> 
> 
> On Tue, Jun 18, 2013 at 5:07 PM, Kishon Vijay Abraham I  > wrote:
> 
> Hi,
> 
> On Tuesday 18 June 2013 03:33 PM, Rahul Sharma wrote:
> > Thanks all,
> >
> > On Fri, Jun 14, 2013 at 11:39 AM, ???  > wrote:
> >> Hello Kishon,
> >>
> >> On 2013? 06? 13? 21:54, Kishon Vijay Abraham I wrote:
> >>> Hi,
> >>>
> >>> On Thursday 13 June 2013 04:51 PM, Inki Dae wrote:
> 
> 
> > -Original Message-
> > From: Sylwester Nawrocki [mailto:s.nawrocki at samsung.com
> ]
> > Sent: Thursday, June 13, 2013 5:56 PM
> > To: Rahul Sharma
> > Cc: Rahul Sharma; Inki Dae; linux-samsung-soc at vger.kernel.org
> ;
> > devicetree-
> > discuss at lists.ozlabs.org ;
> DRI mailing list; Kukjin Kim; Seung-Woo Kim;
> > Sean Paul; sunil joshi; Kishon Vijay Abraham I; Stephen Warren;
> > grant.likely at linaro.org 
> > Subject: Re: [RFC 0/2] exynos5250/hdmi: replace dummy hdmiphy
> clock with
> > pmu reg control
> >
> > Hi,
> >
> > On 06/13/2013 06:26 AM, Rahul Sharma wrote:
> >> Mr. Dae,
> >>
> >> Thanks for your valuable inputs.
> >>
> >> I posted it as RFC because, I also have received comments to
> register
> >> hdmiphy as a clock controller. As we always configure it for
> specific
> >> frequency, hdmi-phy looks similar to a PLL. But it really doesn't
> >> belong to that class. Secondly prior to exynos5420, it was a i2c
> >> device. I am not sure we can register a I2C device as a clock
> >> controller. I wanted to discuss and explore this option here.
> >
> > Have you considered using the generic PHY framework for those HDMI
> > PHY devices [1] ? I guess we could add a dedicated group of
> ops for
> > video PHYs, similarly as is is done with struct
> v4l2_subdev_ops. For
> > configuring things like the carrier/pixel clock frequency or
> anything
> > what's common across the video PHYs.
> >
> > Perhaps you could have a look and see if this framework would be
> > useful for HDMI and possibly point out anything what might be
> missing ?
> >
> > I'm not sure it it really solves the issues specific to the Exynos
> > HDMI but at least with a generic PHY driver the PHY module
> would be
> > separate from the PHY controller, as often same HDMI DPHY can
> be used
> > with various types of a HDMI controller. So this would allow
> to not
> > duplicate the HDMI PHY drivers in the long-term perspective.
> 
>  Yeah, at least, it seems that we could use PHY module to
> control PMU
>  register, HDMI_PHY_CONTROL. However, PHY module provides only
> init/on/off
>  callbacks. As you may know, HDMIPHY needs i2c interfaces to control
>  HDMIPHY
>  clock. So with PHY module, HDMIPHY driver could enable PMU more
>  generically,
>  but also has to use existing i2c stuff to control HDMIPHY
> clock. I had a
>  quick review to Generic PHY Framework[v6] but I didn't see that
> the PHY
>  module could generically support more features such as i2c stuff.
> >>>
> >>> I don't think PHY framework needs to provide i2c interfaces to
> program
> >>> certain configurations. Instead in one of the callbacks
> (init/on/off)
> >>> PHY driver can program whatever it wants using any of the
> interfaces it
> >>> needs. IMO PHY framework should work independent of the interfaces.
> >>
> >> In exnoys hdmi case, i2c interface is not the exact issue. In exynos
> >> hdmi, hdmiphy should send i2c configuration about video clock
> >> information as the video mode information including resolution,
> bit per
> >> pixel, refresh rate passed from drm subsystem. So init/on/off
> callbacks
> >> of phy framework are not enough for exynos hdmiphy and it should
> have a
> >> callback to set video mode.
> >>
> >> Do you have plan to add driver specific extend callback pointers
> to phy
> >> framework?
> >>
> >> Currently, hdmi directly calls phy operations, but Rahul's
> another patch
> >> set, mentioned by Inki, divides hdmi and hdmiphy and hdmi and
> hdmiphy is
> >> connected with exynos hdmi own sub driver callback operations.
> >>
> >> IMHO, if phy framework can support extend callback feature, then this
> >> own sub driver callbacks can be replaced with phy framework at
>

[RFC 0/2] exynos5250/hdmi: replace dummy hdmiphy clock with pmu reg control

2013-07-30 Thread Rahul Sharma 
Thanks Seung-Woo,

On Tue, Jul 30, 2013 at 11:36 AM, Seung-Woo Kim  
wrote:
> Hi Rahul,
>
> On 2013? 07? 30? 12:42, Rahul Sharma wrote:
>>
>>
>> On Tue, Jun 18, 2013 at 5:07 PM, Kishon Vijay Abraham I > > wrote:
>>
>> Hi,
>>
>> On Tuesday 18 June 2013 03:33 PM, Rahul Sharma wrote:
>> > Thanks all,
>> >
>> > On Fri, Jun 14, 2013 at 11:39 AM, ??? > > wrote:
>> >> Hello Kishon,
>> >>
>> >> On 2013? 06? 13? 21:54, Kishon Vijay Abraham I wrote:
>> >>> Hi,
>> >>>
>> >>> On Thursday 13 June 2013 04:51 PM, Inki Dae wrote:
>> 
>> 
>> > -Original Message-
>> > From: Sylwester Nawrocki [mailto:s.nawrocki at samsung.com
>> ]
>> > Sent: Thursday, June 13, 2013 5:56 PM
>> > To: Rahul Sharma
>> > Cc: Rahul Sharma; Inki Dae; linux-samsung-soc at vger.kernel.org
>> ;
>> > devicetree-
>> > discuss at lists.ozlabs.org ;
>> DRI mailing list; Kukjin Kim; Seung-Woo Kim;
>> > Sean Paul; sunil joshi; Kishon Vijay Abraham I; Stephen Warren;
>> > grant.likely at linaro.org 
>> > Subject: Re: [RFC 0/2] exynos5250/hdmi: replace dummy hdmiphy
>> clock with
>> > pmu reg control
>> >
>> > Hi,
>> >
>> > On 06/13/2013 06:26 AM, Rahul Sharma wrote:
>> >> Mr. Dae,
>> >>
>> >> Thanks for your valuable inputs.
>> >>
>> >> I posted it as RFC because, I also have received comments to
>> register
>> >> hdmiphy as a clock controller. As we always configure it for
>> specific
>> >> frequency, hdmi-phy looks similar to a PLL. But it really doesn't
>> >> belong to that class. Secondly prior to exynos5420, it was a i2c
>> >> device. I am not sure we can register a I2C device as a clock
>> >> controller. I wanted to discuss and explore this option here.
>> >
>> > Have you considered using the generic PHY framework for those HDMI
>> > PHY devices [1] ? I guess we could add a dedicated group of
>> ops for
>> > video PHYs, similarly as is is done with struct
>> v4l2_subdev_ops. For
>> > configuring things like the carrier/pixel clock frequency or
>> anything
>> > what's common across the video PHYs.
>> >
>> > Perhaps you could have a look and see if this framework would be
>> > useful for HDMI and possibly point out anything what might be
>> missing ?
>> >
>> > I'm not sure it it really solves the issues specific to the Exynos
>> > HDMI but at least with a generic PHY driver the PHY module
>> would be
>> > separate from the PHY controller, as often same HDMI DPHY can
>> be used
>> > with various types of a HDMI controller. So this would allow
>> to not
>> > duplicate the HDMI PHY drivers in the long-term perspective.
>> 
>>  Yeah, at least, it seems that we could use PHY module to
>> control PMU
>>  register, HDMI_PHY_CONTROL. However, PHY module provides only
>> init/on/off
>>  callbacks. As you may know, HDMIPHY needs i2c interfaces to control
>>  HDMIPHY
>>  clock. So with PHY module, HDMIPHY driver could enable PMU more
>>  generically,
>>  but also has to use existing i2c stuff to control HDMIPHY
>> clock. I had a
>>  quick review to Generic PHY Framework[v6] but I didn't see that
>> the PHY
>>  module could generically support more features such as i2c stuff.
>> >>>
>> >>> I don't think PHY framework needs to provide i2c interfaces to
>> program
>> >>> certain configurations. Instead in one of the callbacks
>> (init/on/off)
>> >>> PHY driver can program whatever it wants using any of the
>> interfaces it
>> >>> needs. IMO PHY framework should work independent of the interfaces.
>> >>
>> >> In exnoys hdmi case, i2c interface is not the exact issue. In exynos
>> >> hdmi, hdmiphy should send i2c configuration about video clock
>> >> information as the video mode information including resolution,
>> bit per
>> >> pixel, refresh rate passed from drm subsystem. So init/on/off
>> callbacks
>> >> of phy framework are not enough for exynos hdmiphy and it should
>> have a
>> >> callback to set video mode.
>> >>
>> >> Do you have plan to add driver specific extend callback pointers
>> to phy
>> >> framework?
>> >>
>> >> Currently, hdmi directly calls phy operations, but Rahul's
>> another patch
>> >> set, mentioned by Inki, divides hdmi and hdmiphy and hdmi and
>> hdmiphy is
>> >> connected with exynos hdmi own

[PATCH 1/4] gpu/vga_switcheroo: add driver control power feature. (v3)

2013-07-30 Thread Dave Airlie 
On Tue, Jul 30, 2013 at 11:50 AM, Hohahiu  wrote:
> Hello, Dave!
>
> I have a hybrid muxless laptop with intel+radeon:
> #lspci | grep VGA
> 00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor
> Graphics Controller (rev 09)
> 01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI Cape
> Verde [Radeon HD 7700M Series]
>
> I have some questions related to this series of patches.
> When I power down discrete card by vgaswitcheroo, restart X server and turn
> on radeon card again, xrandr doesn't recognize my discrete card and only
> shows the intel one. Is this a bug or a feature of X server?
> And how would this behavior change with this patch?

Yes this with radeon support will save you having to power down things yourself,
so would just make it all happen dynamically and you'd never see it.

However if the machine dies on power down that could be fun to solve
with these patches as well.

Dave.

Commit f5d9b7f0f9 (fix r600_enable_sclk_control()) causes kexec issues

2013-07-30 Thread Markus Trippelsdorf 
On 2013.07.30 at 13:27 +0200, Markus Trippelsdorf wrote:
> On 2013.07.29 at 15:53 -0400, Alex Deucher wrote:
> > On Mon, Jul 29, 2013 at 2:10 PM, Eric W. Biederman
> >  wrote:
> > > Alex Deucher  writes:
> > >
> > >> On Mon, Jul 29, 2013 at 11:50 AM, Eric W. Biederman
> > >>  wrote:
> > >>>
> > >>>
> > >>> Alex Deucher  wrote:
> > On Mon, Jul 29, 2013 at 10:09 AM, Markus Trippelsdorf
> >  wrote:
> > > On 2013.07.29 at 09:58 -0400, Alex Deucher wrote:
> > >> On Mon, Jul 29, 2013 at 3:51 AM, Markus Trippelsdorf
> > >>  wrote:
> > >> > On my test machine Xorg doesn't start anymore when I kexec into a
> > >> > 3.11.0-rc3 kernel.
> > >>
> > >> With kexec, dpm doesn't get torn down properly which can result in a
> > >> bad hardware state when the driver loads again.  Does the attached
> > >> patch help?  It attempts to disable dpm at startup in case it wasn't
> > >> torn down properly previously.
> > >
> > > dpm initialization now works, but unfortunately GPU acceleration
> > still gets
> > > disabled:
> > 
> > Stupid kexec complicates things.  We need to make sure dpm is torn
> > down before we init the rest of the GPU, but dpm needs get initialized
> > later in the init process since it depends on certain other state from
> > the driver.  I need to think about this for a bit.  I'm not sure of a
> > good way to handle this.
> > >>>
> > >>> You might just want to implement a shutdown method that cleans things 
> > >>> up properly.   At least as a first pass until you worry about things 
> > >>> like kexec on panic.
> > >>>
> > >>> Or can you not shutdown the graphics stack on reboot because of the 
> > >>> need to display the kernels shutdown progress?
> > >>
> > >> Does kexec actually call this shutdown method?  The driver implements
> > >> appropriate clean-up measures if it's shutdown properly.
> > >
> > > Absoltuely.  All parts of the reboot path call ->shutdown.  Including
> > > kexec.
> > >
> > > You don't get a device remove/hotunplug but unless this is a kexec on
> > > panic ->shutdown is most definitely called.  Now I am talking about the
> > > device layer/pci layer shutdown method I don't know how gpu drivers are
> > > wired up.  GPU land was a little strange last I looked.  Hopefully it
> > > isn't so strange that there is a method named shutdown that is not wired
> > > up.
> > 
> > It doesn't look like the drm infrastructure has a shutdown callback.
> > The drm drivers register a drm_driver callback struct that includes an
> > unload callback which takes care of all the device teardown (if you
> > unload the module for example).  I don't know that it actually gets
> > called at kexec time however.  I don't know enough about how kexec
> > works.
> 
> BTW there is r100_restore_sanity() in drm/radeon/r100.c that explicitly
> handles the kexec case during init. So maybe an r600_restore_sanity()
> function is needed?

Oh, I see r100_restore_sanity() gets also called for the other ASICs...

-- 
Markus

Commit f5d9b7f0f9 (fix r600_enable_sclk_control()) causes kexec issues

2013-07-30 Thread Markus Trippelsdorf 
On 2013.07.29 at 15:53 -0400, Alex Deucher wrote:
> On Mon, Jul 29, 2013 at 2:10 PM, Eric W. Biederman
>  wrote:
> > Alex Deucher  writes:
> >
> >> On Mon, Jul 29, 2013 at 11:50 AM, Eric W. Biederman
> >>  wrote:
> >>>
> >>>
> >>> Alex Deucher  wrote:
> On Mon, Jul 29, 2013 at 10:09 AM, Markus Trippelsdorf
>  wrote:
> > On 2013.07.29 at 09:58 -0400, Alex Deucher wrote:
> >> On Mon, Jul 29, 2013 at 3:51 AM, Markus Trippelsdorf
> >>  wrote:
> >> > On my test machine Xorg doesn't start anymore when I kexec into a
> >> > 3.11.0-rc3 kernel.
> >>
> >> With kexec, dpm doesn't get torn down properly which can result in a
> >> bad hardware state when the driver loads again.  Does the attached
> >> patch help?  It attempts to disable dpm at startup in case it wasn't
> >> torn down properly previously.
> >
> > dpm initialization now works, but unfortunately GPU acceleration
> still gets
> > disabled:
> 
> Stupid kexec complicates things.  We need to make sure dpm is torn
> down before we init the rest of the GPU, but dpm needs get initialized
> later in the init process since it depends on certain other state from
> the driver.  I need to think about this for a bit.  I'm not sure of a
> good way to handle this.
> >>>
> >>> You might just want to implement a shutdown method that cleans things up 
> >>> properly.   At least as a first pass until you worry about things like 
> >>> kexec on panic.
> >>>
> >>> Or can you not shutdown the graphics stack on reboot because of the need 
> >>> to display the kernels shutdown progress?
> >>
> >> Does kexec actually call this shutdown method?  The driver implements
> >> appropriate clean-up measures if it's shutdown properly.
> >
> > Absoltuely.  All parts of the reboot path call ->shutdown.  Including
> > kexec.
> >
> > You don't get a device remove/hotunplug but unless this is a kexec on
> > panic ->shutdown is most definitely called.  Now I am talking about the
> > device layer/pci layer shutdown method I don't know how gpu drivers are
> > wired up.  GPU land was a little strange last I looked.  Hopefully it
> > isn't so strange that there is a method named shutdown that is not wired
> > up.
> 
> It doesn't look like the drm infrastructure has a shutdown callback.
> The drm drivers register a drm_driver callback struct that includes an
> unload callback which takes care of all the device teardown (if you
> unload the module for example).  I don't know that it actually gets
> called at kexec time however.  I don't know enough about how kexec
> works.

BTW there is r100_restore_sanity() in drm/radeon/r100.c that explicitly
handles the kexec case during init. So maybe an r600_restore_sanity()
function is needed?

(One of the advantages of using kexec (besides the much quicker boot
time) is that the monitor is not switched off and then on during boot.
I guess that advantage would be lost if the unload callback would be
called.)

-- 
Markus

[PATCH 1/3] drm/nouveau: fix vblank interrupt being called before event is setup

2013-07-30 Thread Ben Skeggs 
On Tue, Jul 23, 2013 at 11:43 PM, Maarten Lankhorst
 wrote:
> Sort of fixes mmiotrace for me again, I could sear I sent a similar patch 
> before
> the rework to event interface, so I guess it got reintroduced.
I don't know how/why you think this fixes anything.  The interrupt
handler can't possibly be called until after priv->base.vblank has
been initialised...

Seriously, go look, the subdev interrupt handler pointer isn't filled
in (and can't be) until after nouveau_disp_create() has been called,
and nouveau_disp_create() initialises priv->base.vblank before it
returns...

Ben.


>
> Signed-off-by: Maarten Lankhorst 
> ---
> diff --git a/drivers/gpu/drm/nouveau/core/engine/disp/nv50.c 
> b/drivers/gpu/drm/nouveau/core/engine/disp/nv50.c
> index 7e3875d..35e526b 100644
> --- a/drivers/gpu/drm/nouveau/core/engine/disp/nv50.c
> +++ b/drivers/gpu/drm/nouveau/core/engine/disp/nv50.c
> @@ -1266,13 +1266,15 @@ nv50_disp_intr(struct nouveau_subdev *subdev)
> }
>
> if (intr1 & 0x0004) {
> -   nouveau_event_trigger(priv->base.vblank, 0);
> +   if (priv->base.vblank)
> +   nouveau_event_trigger(priv->base.vblank, 0);
> nv_wr32(priv, 0x610024, 0x0004);
> intr1 &= ~0x0004;
> }
>
> if (intr1 & 0x0008) {
> -   nouveau_event_trigger(priv->base.vblank, 1);
> +   if (priv->base.vblank)
> +   nouveau_event_trigger(priv->base.vblank, 1);
> nv_wr32(priv, 0x610024, 0x0008);
> intr1 &= ~0x0008;
> }
> diff --git a/drivers/gpu/drm/nouveau/core/engine/disp/nvd0.c 
> b/drivers/gpu/drm/nouveau/core/engine/disp/nvd0.c
> index 52dd7a1..4095f65 100644
> --- a/drivers/gpu/drm/nouveau/core/engine/disp/nvd0.c
> +++ b/drivers/gpu/drm/nouveau/core/engine/disp/nvd0.c
> @@ -941,7 +941,7 @@ nvd0_disp_intr(struct nouveau_subdev *subdev)
> u32 mask = 0x0100 << i;
> if (mask & intr) {
> u32 stat = nv_rd32(priv, 0x6100bc + (i * 0x800));
> -   if (stat & 0x0001)
> +   if ((stat & 0x0001) && priv->base.vblank)
> nouveau_event_trigger(priv->base.vblank, i);
> nv_mask(priv, 0x6100bc + (i * 0x800), 0, 0);
> nv_rd32(priv, 0x6100c0 + (i * 0x800));
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 67530] VDPAU state tracker reports wrong codec level

2013-07-30 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=67530

--- Comment #3 from Christian K?nig  ---
(In reply to comment #2)
> Good to know! I'll stop bothering the world and his dog about that, then. :-)
> Is this also normal that the decoder only report NV12 and no YV12, UYVY or
> YUYV? Is it some hardware limitation?

Yes that's a hardware limitation, UVD can only decode to an NV12 destination.

Well actually we somewhat abused the query interface here, cause VDPAU asks the
driver what image formats are supported in up/downloads and not as decoding
target.

Should probably fix that at some point as well. On the other hand that should
be really easy to do, so if anybody volunteers...

-- 
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/20130730/f14e0513/attachment-0001.html>

[Bug 67530] VDPAU state tracker reports wrong codec level

2013-07-30 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=67530

--- Comment #2 from Richard Van Den Boom  ---
Good to know! I'll stop bothering the world and his dog about that, then. :-)
Is this also normal that the decoder only report NV12 and no YV12, UYVY or
YUYV? Is it some hardware limitation?

-- 
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/20130730/966ac02a/attachment.html>

[Bug 67530] VDPAU state tracker reports wrong codec level

2013-07-30 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=67530

Christian K?nig  changed:

   What|Removed |Added

   Severity|normal  |enhancement
Summary|Wrong UVD capabilities  |VDPAU state tracker reports
   |reported by VDPAU on Brazos |wrong codec level

--- Comment #1 from Christian K?nig  ---
Indeed, so far we have hardcoded the level in vlVdpDecoderQueryCapabilities.

Should be updated to correctly return the supported codec level.

-- 
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/20130730/76eb3bd8/attachment.html>

[PATCH] host1x: hdmi: Make sure clock is enabled before dumping registers

2013-07-30 Thread Mikko Perttunen 
The debugfs register dumping function did not enable the HDMI clock.
This led to a possible system hang when reading the debugfs entry
while no HDMI cable was connected to the system. This patch makes
sure that the clock is enabled during the read.

Signed-off-by: Mikko Perttunen 
---
 drivers/gpu/host1x/drm/hdmi.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/gpu/host1x/drm/hdmi.c b/drivers/gpu/host1x/drm/hdmi.c
index 01097da..bf7f027 100644
--- a/drivers/gpu/host1x/drm/hdmi.c
+++ b/drivers/gpu/host1x/drm/hdmi.c
@@ -904,6 +904,11 @@ static int tegra_hdmi_show_regs(struct seq_file *s, void 
*data)
 {
struct drm_info_node *node = s->private;
struct tegra_hdmi *hdmi = node->info_ent->data;
+   int err;
+
+   err = clk_enable(hdmi->clk);
+   if (err)
+   return err;

 #define DUMP_REG(name) \
seq_printf(s, "%-56s %#05x %08lx\n", #name, name,   \
@@ -1069,6 +1074,8 @@ static int tegra_hdmi_show_regs(struct seq_file *s, void 
*data)

 #undef DUMP_REG

+   clk_disable(hdmi->clk);
+
return 0;
 }

-- 
1.8.1.5

[RFC 0/2] exynos5250/hdmi: replace dummy hdmiphy clock with pmu reg control

2013-07-30 Thread Rahul Sharma 
ad a
> > >>>> quick review to Generic PHY Framework[v6] but I didn't see that
> the PHY
> > >>>> module could generically support more features such as i2c
> stuff.
> > >>>
> > >>> I don't think PHY framework needs to provide i2c interfaces to
> program
> > >>> certain configurations. Instead in one of the callbacks
> (init/on/off)
> > >>> PHY driver can program whatever it wants using any of the
> interfaces it
> > >>> needs. IMO PHY framework should work independent of the
> interfaces.
> > >>
> > >> In exnoys hdmi case, i2c interface is not the exact issue. In
> exynos
> > >> hdmi, hdmiphy should send i2c configuration about video clock
> > >> information as the video mode information including resolution,
> bit per
> > >> pixel, refresh rate passed from drm subsystem. So init/on/off
> callbacks
> > >> of phy framework are not enough for exynos hdmiphy and it should
> have a
> > >> callback to set video mode.
> > >>
> > >> Do you have plan to add driver specific extend callback pointers
> to phy
> > >> framework?
> > >>
> > >> Currently, hdmi directly calls phy operations, but Rahul's
> another patch
> > >> set, mentioned by Inki, divides hdmi and hdmiphy and hdmi and
> hdmiphy is
> > >> connected with exynos hdmi own sub driver callback operations.
> > >>
> > >> IMHO, if phy framework can support extend callback feature, then
> this
> > >> own sub driver callbacks can be replaced with phy framework at
> long term
> > >> view.
> > >
> > > Extended callbacks are always welcome. I can also use phy device
> > > private data to pass on private ops like get_pixelclk and
> set_pixelclk.
> >
> > I would recommend creating a wrapper to the existing PHY framework
> > for HDMI PHY. That way, we can have other HDMI phys added
> > easily. We need to figure out all the ops that might be needed by the
> > HDMI PHY to be added to the wrapper.
> > IMO extended callbacks can lead to abuse of the system and should be
> > used only when absolutely necessary.
> >
> > Thanks
> > Kishon
> >
> >
> > Thanks Kishon,
> >
> > I have started working on this wrapper layer which is customized for
> video phys.
> > As if now, adding set_dv_timing, get_dv_timing as the only additional
> callbacks.
> > I will post the RFC patches.
>
> Idea of creating wrapper layer for different types of controller is shot
> down
> in the community [1] :-s
>
> [1] ->
> http://lists.infradead.org/pipermail/linux-arm-kernel/2013-July/181710.html
>
> Thanks
> Kishon
>

Thanks Kishon,

I didn't notice the mail thread. I will continue the discussion there.

Regards,
Rahul Sharma
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130730/d531e3fc/attachment.html>

Commit f5d9b7f0f9 (fix r600_enable_sclk_control()) causes kexec issues

2013-07-30 Thread Alex Deucher 
On Tue, Jul 30, 2013 at 7:27 AM, Markus Trippelsdorf
 wrote:
> On 2013.07.29 at 15:53 -0400, Alex Deucher wrote:
>> On Mon, Jul 29, 2013 at 2:10 PM, Eric W. Biederman
>>  wrote:
>> > Alex Deucher  writes:
>> >
>> >> On Mon, Jul 29, 2013 at 11:50 AM, Eric W. Biederman
>> >>  wrote:
>> >>>
>> >>>
>> >>> Alex Deucher  wrote:
>> On Mon, Jul 29, 2013 at 10:09 AM, Markus Trippelsdorf
>>  wrote:
>> > On 2013.07.29 at 09:58 -0400, Alex Deucher wrote:
>> >> On Mon, Jul 29, 2013 at 3:51 AM, Markus Trippelsdorf
>> >>  wrote:
>> >> > On my test machine Xorg doesn't start anymore when I kexec into a
>> >> > 3.11.0-rc3 kernel.
>> >>
>> >> With kexec, dpm doesn't get torn down properly which can result in a
>> >> bad hardware state when the driver loads again.  Does the attached
>> >> patch help?  It attempts to disable dpm at startup in case it wasn't
>> >> torn down properly previously.
>> >
>> > dpm initialization now works, but unfortunately GPU acceleration
>> still gets
>> > disabled:
>> 
>> Stupid kexec complicates things.  We need to make sure dpm is torn
>> down before we init the rest of the GPU, but dpm needs get initialized
>> later in the init process since it depends on certain other state from
>> the driver.  I need to think about this for a bit.  I'm not sure of a
>> good way to handle this.
>> >>>
>> >>> You might just want to implement a shutdown method that cleans things up 
>> >>> properly.   At least as a first pass until you worry about things like 
>> >>> kexec on panic.
>> >>>
>> >>> Or can you not shutdown the graphics stack on reboot because of the need 
>> >>> to display the kernels shutdown progress?
>> >>
>> >> Does kexec actually call this shutdown method?  The driver implements
>> >> appropriate clean-up measures if it's shutdown properly.
>> >
>> > Absoltuely.  All parts of the reboot path call ->shutdown.  Including
>> > kexec.
>> >
>> > You don't get a device remove/hotunplug but unless this is a kexec on
>> > panic ->shutdown is most definitely called.  Now I am talking about the
>> > device layer/pci layer shutdown method I don't know how gpu drivers are
>> > wired up.  GPU land was a little strange last I looked.  Hopefully it
>> > isn't so strange that there is a method named shutdown that is not wired
>> > up.
>>
>> It doesn't look like the drm infrastructure has a shutdown callback.
>> The drm drivers register a drm_driver callback struct that includes an
>> unload callback which takes care of all the device teardown (if you
>> unload the module for example).  I don't know that it actually gets
>> called at kexec time however.  I don't know enough about how kexec
>> works.
>
> BTW there is r100_restore_sanity() in drm/radeon/r100.c that explicitly
> handles the kexec case during init. So maybe an r600_restore_sanity()
> function is needed?
>
> (One of the advantages of using kexec (besides the much quicker boot
> time) is that the monitor is not switched off and then on during boot.
> I guess that advantage would be lost if the unload callback would be
> called.)

r100_restore_sanity() is basically a set of hacks (that gets called at
driver startup) to work around the fact that with kexec the drm driver
is not torn down correctly.  So we could add a bunch more asic
specific tear down sequences to deal with dpm (and all the other
engines on the GPU that may potentially cause problems if they are not
torn down properly), but that will just turn into a mess.  All of
these hacks also add latency to the driver load.  I think the best
solution would probably be to figure how to hook up the drm unload
callback to the shutdown method that kexec uses.

Alex

[PATCH] mutex: fix deadlock injection

2013-07-30 Thread Peter Zijlstra 
On Tue, Jul 30, 2013 at 10:13:41AM +0200, Maarten Lankhorst wrote:
> The check needs to be for > 1, because ctx->acquired is already incremented.
> This will prevent ww_mutex_lock_slow from returning -EDEADLK and not locking
> the mutex. It caused a lot of false gpu lockups on radeon with
> CONFIG_DEBUG_WW_MUTEX_SLOWPATH=y because a function that shouldn't be able
> to return -EDEADLK did.
> 
> Cc: Alex Deucher 
> Signed-off-by: Maarten Lankhorst 

Thanks!

Is: Regression introduced by 0108bc808107b97e101b15af9705729626be6447 - drm/nouveau: do not allow negative sizes for now (Was:Re: nouveau crash with 3.11-rc2)

2013-07-30 Thread Konrad Rzeszutek Wilk 
On Fri, Jul 26, 2013 at 04:37:32PM -0400, Ilia Mirkin wrote:
> On Fri, Jul 26, 2013 at 2:28 PM, konrad wilk  
> wrote:
> > I just saw this on a box of mine (rc1 worked) I hadn't done yet a bisection.
> > Any suggestions?
> >
> > ring 0 polarity 1
> > [6.023776] Already setup the GSI :22
> > ^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G[6.036680] nouveau  [
> > DEVICE][:00:0d.0] BOOT0  : 0x04c000a2
> > [6.036740] nouveau  [  DEVICE][:00:0d.0] Chipset: C61 (NV4C)
> > [6.036792] nouveau  [  DEVICE][:00:0d.0] Family : NV40
> > [6.038554] nouveau  [   VBIOS][:00:0d.0] checking PRAMIN for
> > image...
> > [6.062295] ata1: SATA link down (SStatus 0 SControl 300)
> > [6.07] nouveau  [   VBIOS][:00:0d.0] ... appears to be valid
> > [6.077829] nouveau  [   VBIOS][:00:0d.0] using image from PRAMIN
> > [6.078024] nouveau  [   VBIOS][:00:0d.0] BIT signature found
> > [6.078076] nouveau  [   VBIOS][:00:0d.0] version 05.61.32.22.01
> > [6.078666] skge :01:08.0 eth2: addr 00:0a:5e:65:74:93
> > [6.086529] nouveau  [ PFB][:00:0d.0] RAM type: unknown
> > [6.086594] nouveau  [ PFB][:00:0d.0] RAM size: 128 MiB
> > [6.086648] nouveau  [ PFB][:00:0d.0]ZCOMP: 0 tags
> > [6.115583] nouveau  [  PTHERM][:00:0d.0] FAN control: none /
> > external
> > [6.115645] nouveau  [  PTHERM][:00:0d.0] fan management: disabled
> > [6.115698] nouveau  [  PTHERM][:00:0d.0] internal sensor: no
> > [6.140702] [TTM] Zone  kernel: Available graphics memory: 461396 kiB
> > [6.140763] [TTM] Initializing pool allocator
> > [6.140852] [TTM] Initializing DMA pool allocator
> > [6.141034] Failed to add WC MTRR for
> > [e000-efff]; performance may suffer.
> > [6.141095] nouveau  [ DRM] VRAM: 125 MiB
> > [6.141189] nouveau  [ DRM] GART: 512 MiB
> > [6.141242] nouveau  [ DRM] TMDS table version 1.1
> > [6.141293] nouveau  [ DRM] DCB version 3.0
> > [6.141342] nouveau  [ DRM] DCB outp 00: 01000310 0023
> > [6.141421] nouveau  [ DRM] DCB outp 01: 00110204 97e5
> > [6.141471] nouveau  [ DRM] DCB conn 00: 
> > [6.141839] nouveau  [ DRM] Saving VGA fonts
> > [6.180531] BUG: unable to handle kernel NULL pointer dereference at
> > (null)
> > [6.180657] IP: [] nouveau_bo_new+0x36/0x330 [nouveau]
> > [6.180775] PGD 29449067 PUD 28aad067 PMD 0
> > [6.180907] Oops:  [#1] SMP
> > [6.181013] Modules linked in: nouveau(+) skge e1000 fbcon tileblit font
> > bitblit ttm softcursor ata_generic sata_nv drm_kms_helper mxm_wmi video wmi
> > libata scsi_mod mperf xen_blkfront xen_netfront fb_sys_fops sysimgblt
> > sysfillrect syscopyarea xenfs xen_privcmd
> > [6.181953] CPU: 0 PID: 428 Comm: kworker/0:1 Not tainted
> > 3.11.0-rc2upstream-00185-g07bc9dc #1
> > [6.182016] Hardware name: BIOSTAR Group N61PB-M2S/N61PB-M2S, BIOS 6.00
> > PG 09/03/2009
> > [6.182084] Workqueue: events work_for_cpu_fn
> > [6.182167] task: 880037e69000 ti: 88003791a000 task.ti:
> > 88003791a000
> > [6.182228] RIP: e030:[] []
> > nouveau_bo_new+0x36/0x330 [nouveau]
> > [6.182344] RSP: e02b:88003791ba88  EFLAGS: 00010287
> > [6.182396] RAX:  RBX: 880028f7f000 RCX:
> > 0004
> > [6.182457] RDX: 0100 RSI: 4000 RDI:
> > 88002b576800
> > [6.182511] RBP: 88003791bb08 R08:  R09:
> > 
> > [6.182565] R10: 0004 R11: 0100 R12:
> > 4000
> > [6.182619] R13: 88002b1e3000 R14: a01fe740 R15:
> > 
> > [6.182679] FS:  7f3da25417a0() GS:88003de0()
> > knlGS:
> > [6.182748] CS:  e033 DS:  ES:  CR0: 8005003b
> > [6.182798] CR2:  CR3: 27416000 CR4:
> > 0660
> > [6.182851] Stack:
> > [6.182896]  88003791bae8 811aa1f9 88002b576800
> > 880027aad240
> > [6.183108]  880080d0 8142a566 880028f7f000
> > 880028f7f000
> > [6.183295]  88002b576800  a01fe740
> > 880028f7f000
> > [6.183488] Call Trace:
> > [6.183544]  [] ? __kmalloc+0x259/0x2a0
> > [6.183603]  [] ?
> > drm_mode_crtc_set_gamma_size+0x26/0x60
> > [6.183680]  [] nv04_crtc_create+0xdf/0x160 [nouveau]
> > [6.183757]  [] nv04_display_create+0x11a/0x400
> > [nouveau]
> > [6.183813]  [] ? __cancel_work_timer+0x7e/0x110
> > [6.183886]  [] nouveau_display_create+0x598/0x5a0
> > [nouveau]
> > [6.183981]  [] nouveau_drm_load+0x25c/0x670 [nouveau]
> > [6.184040]  [] ? device_register+0x19/0x20
> > [6.184098]  [] ? drm_get_minor+0x1fc/0x280
> > [6.187041]  [] drm_get_pci_dev+0x178/0x2a0
> > [6.187096]  [] ? pcibios_set_master+0x83/0xb0
> > [

[RFC 0/2] exynos5250/hdmi: replace dummy hdmiphy clock with pmu reg control

2013-07-30 Thread Kishon Vijay Abraham I 
Hi,

On Tuesday 30 July 2013 09:12 AM, Rahul Sharma wrote:
> 
> 
> On Tue, Jun 18, 2013 at 5:07 PM, Kishon Vijay Abraham I  > wrote:
> 
> Hi,
> 
> On Tuesday 18 June 2013 03:33 PM, Rahul Sharma wrote:
> > Thanks all,
> >
> > On Fri, Jun 14, 2013 at 11:39 AM, ???  > wrote:
> >> Hello Kishon,
> >>
> >> On 2013? 06? 13? 21:54, Kishon Vijay Abraham I wrote:
> >>> Hi,
> >>>
> >>> On Thursday 13 June 2013 04:51 PM, Inki Dae wrote:
> 
> 
> > -Original Message-
> > From: Sylwester Nawrocki [mailto:s.nawrocki at samsung.com
> ]
> > Sent: Thursday, June 13, 2013 5:56 PM
> > To: Rahul Sharma
> > Cc: Rahul Sharma; Inki Dae; linux-samsung-soc at vger.kernel.org
> ;
> > devicetree-
> > discuss at lists.ozlabs.org ; 
> DRI
> mailing list; Kukjin Kim; Seung-Woo Kim;
> > Sean Paul; sunil joshi; Kishon Vijay Abraham I; Stephen Warren;
> > grant.likely at linaro.org 
> > Subject: Re: [RFC 0/2] exynos5250/hdmi: replace dummy hdmiphy clock 
> with
> > pmu reg control
> >
> > Hi,
> >
> > On 06/13/2013 06:26 AM, Rahul Sharma wrote:
> >> Mr. Dae,
> >>
> >> Thanks for your valuable inputs.
> >>
> >> I posted it as RFC because, I also have received comments to 
> register
> >> hdmiphy as a clock controller. As we always configure it for 
> specific
> >> frequency, hdmi-phy looks similar to a PLL. But it really doesn't
> >> belong to that class. Secondly prior to exynos5420, it was a i2c
> >> device. I am not sure we can register a I2C device as a clock
> >> controller. I wanted to discuss and explore this option here.
> >
> > Have you considered using the generic PHY framework for those HDMI
> > PHY devices [1] ? I guess we could add a dedicated group of ops for
> > video PHYs, similarly as is is done with struct v4l2_subdev_ops. For
> > configuring things like the carrier/pixel clock frequency or 
> anything
> > what's common across the video PHYs.
> >
> > Perhaps you could have a look and see if this framework would be
> > useful for HDMI and possibly point out anything what might be 
> missing ?
> >
> > I'm not sure it it really solves the issues specific to the Exynos
> > HDMI but at least with a generic PHY driver the PHY module would be
> > separate from the PHY controller, as often same HDMI DPHY can be 
> used
> > with various types of a HDMI controller. So this would allow to not
> > duplicate the HDMI PHY drivers in the long-term perspective.
> 
>  Yeah, at least, it seems that we could use PHY module to control PMU
>  register, HDMI_PHY_CONTROL. However, PHY module provides only 
> init/on/off
>  callbacks. As you may know, HDMIPHY needs i2c interfaces to control
>  HDMIPHY
>  clock. So with PHY module, HDMIPHY driver could enable PMU more
>  generically,
>  but also has to use existing i2c stuff to control HDMIPHY clock. I 
> had a
>  quick review to Generic PHY Framework[v6] but I didn't see that the 
> PHY
>  module could generically support more features such as i2c stuff.
> >>>
> >>> I don't think PHY framework needs to provide i2c interfaces to program
> >>> certain configurations. Instead in one of the callbacks (init/on/off)
> >>> PHY driver can program whatever it wants using any of the interfaces 
> it
> >>> needs. IMO PHY framework should work independent of the interfaces.
> >>
> >> In exnoys hdmi case, i2c interface is not the exact issue. In exynos
> >> hdmi, hdmiphy should send i2c configuration about video clock
> >> information as the video mode information including resolution, bit per
> >> pixel, refresh rate passed from drm subsystem. So init/on/off callbacks
> >> of phy framework are not enough for exynos hdmiphy and it should have a
> >> callback to set video mode.
> >>
> >> Do you have plan to add driver specific extend callback pointers to phy
> >> framework?
> >>
> >> Currently, hdmi directly calls phy operations, but Rahul's another 
> patch
> >> set, mentioned by Inki, divides hdmi and hdmiphy and hdmi and hdmiphy 
> is
> >> connected with exynos hdmi own sub driver callback operations.
> >>
> >> IMHO, if phy framework can support extend callback feature, then this
> >> own sub driver callbacks can be replaced with phy framework at long 
> term
> >> view.
> >
> > Extended callbacks are always welcome. I can also use

[Bug 67530] New: Wrong UVD capabilities reported by VDPAU on Brazos

2013-07-30 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=67530

  Priority: medium
Bug ID: 67530
  Assignee: dri-devel at lists.freedesktop.org
   Summary: Wrong UVD capabilities reported by VDPAU on Brazos
  Severity: normal
Classification: Unclassified
OS: Linux (All)
  Reporter: richard.vdboom at gmail.com
  Hardware: x86-64 (AMD64)
Status: NEW
   Version: XOrg CVS
 Component: DRM/Radeon
   Product: DRI

The VDPAU collects from VDPAU drivers a certain amount of capabilities that are
supposed to allow user space program to check if the decoder is able to decode
a particular stream or not.
These parameters can be checked by the vdpauinfo tool and the begining of the
output on Nvidia hardware looks like this :

**

display: (null)   screen: 0
API version: 0
Information string: Unknown

Video surface:

name   width height types
---
420 4096  4096  NV12 YV12 
422 4096  4096  UYVY YUYV 

Decoder capabilities:

name  level ref width height

MPEG1 0  2  4096  4096
MPEG2_SIMPLE  3  2  4096  4096
MPEG2_MAIN3  2  4096  4096
H264_MAIN41  4  4096  4096
H264_HIGH41  4  4096  4096

***



Right now, the output on a Zacate / Brazos E450 system looks like this :

***

bash-4.2$ vdpauinfo 
display: :0   screen: 0
API version: 1
Information string: G3DVL VDPAU Driver Shared Library version 1.0

Video surface:

name   width height types
---
42016384 16384  NV12 
42216384 16384  NV12 
44416384 16384  NV12 

Decoder capabilities:

name   level macbs width height
---
MPEG116  9216  2048  1152
MPEG2_SIMPLE 16  9216  2048  1152
MPEG2_MAIN   16  9216  2048  1152
H264_BASELINE16  9216  2048  1152
H264_MAIN16  9216  2048  1152
H264_HIGH16  9216  2048  1152
VC1_SIMPLE   16  9216  2048  1152
VC1_MAIN 16  9216  2048  1152
VC1_ADVANCED 16  9216  2048  1152
MPEG4_PART2_SP   16  9216  2048  1152
MPEG4_PART2_ASP  16  9216  2048  1152

*

Whatever the codec, the supported level is shown to be 16 (a non-existing level
for h264 at least) and the macbs (the number of macroblocks) is always the
same.
This confuses players like VLC which adress libvdpau directly and get this
answer (16) for the supported h264 level. Players like mplayer, which do not
check this, play the video using UVD without problem.
So there is just an issue with the way VDPAU reports UVD capabilities : it
seems to just provide some kind of default.

-- 
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/20130730/1b031a39/attachment.html>

[PATCH] mutex: fix deadlock injection

2013-07-30 Thread Maarten Lankhorst 
The check needs to be for > 1, because ctx->acquired is already incremented.
This will prevent ww_mutex_lock_slow from returning -EDEADLK and not locking
the mutex. It caused a lot of false gpu lockups on radeon with
CONFIG_DEBUG_WW_MUTEX_SLOWPATH=y because a function that shouldn't be able
to return -EDEADLK did.

Cc: Alex Deucher 
Signed-off-by: Maarten Lankhorst 
---
diff --git a/kernel/mutex.c b/kernel/mutex.c
index ff05f4b..a52ee7bb 100644
--- a/kernel/mutex.c
+++ b/kernel/mutex.c
@@ -686,7 +686,7 @@ __ww_mutex_lock(struct ww_mutex *lock, struct 
ww_acquire_ctx *ctx)
might_sleep();
ret =  __mutex_lock_common(>base, TASK_UNINTERRUPTIBLE,
   0, >dep_map, _RET_IP_, ctx);
-   if (!ret && ctx->acquired > 0)
+   if (!ret && ctx->acquired > 1)
return ww_mutex_deadlock_injection(lock, ctx);

return ret;
@@ -702,7 +702,7 @@ __ww_mutex_lock_interruptible(struct ww_mutex *lock, struct 
ww_acquire_ctx *ctx)
ret = __mutex_lock_common(>base, TASK_INTERRUPTIBLE,
  0, >dep_map, _RET_IP_, ctx);

-   if (!ret && ctx->acquired > 0)
+   if (!ret && ctx->acquired > 1)
return ww_mutex_deadlock_injection(lock, ctx);

return ret;

[PATCH v2] drm/gem: fix mmap vma size calculations

2013-07-30 Thread Sedat Dilek 
On Tue, Jul 30, 2013 at 9:41 AM, Sedat Dilek  wrote:
> On Fri, Jul 26, 2013 at 10:15 PM, Daniel Vetter  wrote:
>> On Fri, Jul 26, 2013 at 12:09:32PM +0200, David Herrmann wrote:
>>> The VMA manager is page-size based so drm_vma_node_size() returns the size
>>> in pages. However, drm_gem_mmap_obj() requires the size in bytes. Apply
>>> PAGE_SHIFT so we no longer get EINVAL during mmaps due to too small
>>> buffers.
>>>
>>> This bug was introduced in commit:
>>>   0de23977cfeb5b357ec884ba15417ae118ff9e9b
>>>   "drm/gem: convert to new unified vma manager"
>>>
>>> Fixes i915 gtt mmap failure reported by Sedat Dilek in:
>>>   Re: linux-next: Tree for Jul 25 [ call-trace: drm | drm-intel related? ]
>>>
>>> Cc: Daniel Vetter 
>>> Cc: Chris Wilson 
>>> Signed-off-by: David Herrmann 
>>> Reported-by: Sedat Dilek 
>>> Tested-by: Sedat Dilek 
>>
>> I remember that I even checked whether v4 was consistent with pages vs.
>> bytes ;-) So
>>
>
> Hi David, Daniel, and Dave,
>
> Just reading quickly "drm: add unified vma offset manager"... is that
> below in the docs?
>
> "The VMA manager is page-size based so drm_vma_node_size() returns the size
> in pages. However, drm_gem_mmap_obj() requires the size in bytes. Apply
> PAGE_SHIFT so we no longer get EINVAL during mmaps due to too small
> buffers."
>
> If not, do you mind adding it?
>

To quote this two:

[ include/drm/drm_vma_manager.h ]

/**
 * drm_vma_node_size() - Return size (page-based)
 * @node: Node to inspect
 *
 * Return the size as number of pages for the given node. This is the same size
 * that was passed to drm_vma_offset_add(). If no offset is allocated for the
 * node, this is 0.
 *
 * RETURNS:
 * Size of @node as number of pages. 0 if the node does not have an offset
 * allocated.
 */

[ drivers/gpu/drm/drm_gem.c ]

/**
 * drm_gem_mmap - memory map routine for GEM objects
 * @filp: DRM file pointer
 * @vma: VMA for the area to be mapped
 *
 * If a driver supports GEM object mapping, mmap calls on the DRM file
 * descriptor will end up here.
 *
 * Look up the GEM object based on the offset passed in (vma->vm_pgoff will
 * contain the fake offset we created when the GTT map ioctl was called on
 * the object) and map it with a call to drm_gem_mmap_obj().
 */

- Sedat -

> Thanks in advance!
>
> - Sedat -
>
>> Reviewed-by: Daniel Vetter 
>>
>> on this little fixup.
>> -Daniel
>>
>>> ---
>>>  drivers/gpu/drm/drm_gem.c | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
>>> index 3613b50..1f76572 100644
>>> --- a/drivers/gpu/drm/drm_gem.c
>>> +++ b/drivers/gpu/drm/drm_gem.c
>>> @@ -666,7 +666,7 @@ int drm_gem_mmap(struct file *filp, struct 
>>> vm_area_struct *vma)
>>>   }
>>>
>>>   obj = container_of(node, struct drm_gem_object, vma_node);
>>> - ret = drm_gem_mmap_obj(obj, drm_vma_node_size(node), vma);
>>> + ret = drm_gem_mmap_obj(obj, drm_vma_node_size(node) << PAGE_SHIFT, 
>>> vma);
>>>
>>>   mutex_unlock(>struct_mutex);
>>>
>>> --
>>> 1.8.3.4
>>>
>>
>> --
>> Daniel Vetter
>> Software Engineer, Intel Corporation
>> +41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH v2] drm/gem: fix mmap vma size calculations

2013-07-30 Thread Sedat Dilek 
On Fri, Jul 26, 2013 at 10:15 PM, Daniel Vetter  wrote:
> On Fri, Jul 26, 2013 at 12:09:32PM +0200, David Herrmann wrote:
>> The VMA manager is page-size based so drm_vma_node_size() returns the size
>> in pages. However, drm_gem_mmap_obj() requires the size in bytes. Apply
>> PAGE_SHIFT so we no longer get EINVAL during mmaps due to too small
>> buffers.
>>
>> This bug was introduced in commit:
>>   0de23977cfeb5b357ec884ba15417ae118ff9e9b
>>   "drm/gem: convert to new unified vma manager"
>>
>> Fixes i915 gtt mmap failure reported by Sedat Dilek in:
>>   Re: linux-next: Tree for Jul 25 [ call-trace: drm | drm-intel related? ]
>>
>> Cc: Daniel Vetter 
>> Cc: Chris Wilson 
>> Signed-off-by: David Herrmann 
>> Reported-by: Sedat Dilek 
>> Tested-by: Sedat Dilek 
>
> I remember that I even checked whether v4 was consistent with pages vs.
> bytes ;-) So
>

Hi David, Daniel, and Dave,

Just reading quickly "drm: add unified vma offset manager"... is that
below in the docs?

"The VMA manager is page-size based so drm_vma_node_size() returns the size
in pages. However, drm_gem_mmap_obj() requires the size in bytes. Apply
PAGE_SHIFT so we no longer get EINVAL during mmaps due to too small
buffers."

If not, do you mind adding it?

Thanks in advance!

- Sedat -

> Reviewed-by: Daniel Vetter 
>
> on this little fixup.
> -Daniel
>
>> ---
>>  drivers/gpu/drm/drm_gem.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
>> index 3613b50..1f76572 100644
>> --- a/drivers/gpu/drm/drm_gem.c
>> +++ b/drivers/gpu/drm/drm_gem.c
>> @@ -666,7 +666,7 @@ int drm_gem_mmap(struct file *filp, struct 
>> vm_area_struct *vma)
>>   }
>>
>>   obj = container_of(node, struct drm_gem_object, vma_node);
>> - ret = drm_gem_mmap_obj(obj, drm_vma_node_size(node), vma);
>> + ret = drm_gem_mmap_obj(obj, drm_vma_node_size(node) << PAGE_SHIFT, 
>> vma);
>>
>>   mutex_unlock(>struct_mutex);
>>
>> --
>> 1.8.3.4
>>
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH 0/2] drm/tilcdc drm/i2c/tda998x workaround for sync issues on TI SoC

2013-07-30 Thread Sebastian Hesselbarth 
On 07/25/2013 09:32 PM, Rob Clark wrote:
> On Thu, Jul 25, 2013 at 2:32 PM, Darren Etheridge  
> wrote:
>> Russell King and Sebastian Hasselbarth had proposed some very good changes
>> for the tda998x HDMI encoder driver.  But when those changes were tested
>> on BeagleBone Black against the tilcdc driver many modes would no longer
>> display correctly.  After analyzing the sync signals from the TI lcd 
>> contoller
>> to the nxp it is apparent that the hsync/vsync's are not rising at the same
>> time as per the VESA spec and this is causing the HDMI encoder to get
>> messed up and failing to lock correctly.
>>
>> This series of patches should be applied on top of:
>>
>> Russell King's
>> rmk's Dove DRM/TDA19988 Cubox driver series
>>
>> Sebastian Hasselbarth's
>> drm/i2c: tda998x: fix sync generation and calculation
>>
>> I have done as much of the change as I can in the tilcdc driver but there
>> is a small unavoidable change in the tda998x driver.  However I have been
>> careful not to break anything from the Dove drivers perspective. It
>> would be great if somebody can test on Cubox and confirm that.
>>
>> This patch set inverts the hsync signal coming from the tilcdc so the NXP
>> is kept happy and then shifts the output to the right to compensate for the
>> sync timing issues.  Display modes from the NXP have been verified using a
>> HDMI analyzer and are reporting correct timings at the output stage.
>>
>> Hopefully this will allow the dove/tda driver changes to progress now that
>> were blocked as per this discussion:
>> http://lists.freedesktop.org/archives/dri-devel/2013-July/040900.html
>>
>
> Good find Darren!  The patches look good to me from a quick review.
> It would be good to get a tested-by from someone on cubox, but it is
> good that we finally found the issue so that we can unblock further
> tda998x development.

Thanks to Darren, I can now test tda998x sync changes on both Cubox and
Beaglebone Black. I don't think the changes will affect Armada DRM in
any way, as it is not setting adjusted_mode.

I will put a scope on AM335x/TDA998x sync signals to fully understand
the issues tilcdc has, but I can think of a flag for TDA998x to always
accept falling input hsync/vsync and tilcdc to supply that sync. That
will maybe allow us to get rid of hskew workaround.

As far as I understand the issue, tilcdc always aligns VS with the
rising HS edge? If so, enforcing positive HS/VS on tilcdc and telling
TDA998x that it is always positive, may be a cleaner workaround. TDA998x
can invert input and output sync independently.

In any way, it will take some time to get a working setup. If you are
happy with the patches, I can still send some follow-up patches later.

Sebastian

[RFC 0/2] exynos5250/hdmi: replace dummy hdmiphy clock with pmu reg control

2013-07-30 Thread Rahul Sharma 
callback pointers to phy
> >> framework?
> >>
> >> Currently, hdmi directly calls phy operations, but Rahul's another patch
> >> set, mentioned by Inki, divides hdmi and hdmiphy and hdmi and hdmiphy is
> >> connected with exynos hdmi own sub driver callback operations.
> >>
> >> IMHO, if phy framework can support extend callback feature, then this
> >> own sub driver callbacks can be replaced with phy framework at long term
> >> view.
> >
> > Extended callbacks are always welcome. I can also use phy device
> > private data to pass on private ops like get_pixelclk and set_pixelclk.
>
> I would recommend creating a wrapper to the existing PHY framework
> for HDMI PHY. That way, we can have other HDMI phys added
> easily. We need to figure out all the ops that might be needed by the
> HDMI PHY to be added to the wrapper.
> IMO extended callbacks can lead to abuse of the system and should be
> used only when absolutely necessary.
>
> Thanks
> Kishon
>

Thanks Kishon,

I have started working on this wrapper layer which is customized for video
phys.
As if now, adding set_dv_timing, get_dv_timing as the only additional
callbacks.
I will post the RFC patches.

regards,
Rahul Sharma.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130730/924b5482/attachment-0001.html>

[PATCH] mutex: fix deadlock injection

2013-07-30 Thread Alex Deucher 
On Tue, Jul 30, 2013 at 4:13 AM, Maarten Lankhorst
 wrote:
> The check needs to be for > 1, because ctx->acquired is already incremented.
> This will prevent ww_mutex_lock_slow from returning -EDEADLK and not locking
> the mutex. It caused a lot of false gpu lockups on radeon with
> CONFIG_DEBUG_WW_MUTEX_SLOWPATH=y because a function that shouldn't be able
> to return -EDEADLK did.
>

I haven't followed the new reservation stuff too closely, but seems plausible.

Acked-by: Alex Deucher 

> Cc: Alex Deucher 
> Signed-off-by: Maarten Lankhorst 
> ---
> diff --git a/kernel/mutex.c b/kernel/mutex.c
> index ff05f4b..a52ee7bb 100644
> --- a/kernel/mutex.c
> +++ b/kernel/mutex.c
> @@ -686,7 +686,7 @@ __ww_mutex_lock(struct ww_mutex *lock, struct 
> ww_acquire_ctx *ctx)
> might_sleep();
> ret =  __mutex_lock_common(>base, TASK_UNINTERRUPTIBLE,
>0, >dep_map, _RET_IP_, ctx);
> -   if (!ret && ctx->acquired > 0)
> +   if (!ret && ctx->acquired > 1)
> return ww_mutex_deadlock_injection(lock, ctx);
>
> return ret;
> @@ -702,7 +702,7 @@ __ww_mutex_lock_interruptible(struct ww_mutex *lock, 
> struct ww_acquire_ctx *ctx)
> ret = __mutex_lock_common(>base, TASK_INTERRUPTIBLE,
>   0, >dep_map, _RET_IP_, ctx);
>
> -   if (!ret && ctx->acquired > 0)
> +   if (!ret && ctx->acquired > 1)
> return ww_mutex_deadlock_injection(lock, ctx);
>
> return ret;
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 67187] Radeon HD6950: UVD not responding, trying to reset the VCPU

2013-07-30 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=67187

--- Comment #6 from Harald Judt  ---
Note that the cayman: "suspending"/"suspend complete" and "resuming"/"resume
complete" functions are only simple printks I added to the begin and end of the
cayman_suspend/cayman_resume functions.

-- 
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/20130730/2d7a3a97/attachment.html>

[Bug 67187] Radeon HD6950: UVD not responding, trying to reset the VCPU

2013-07-30 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=67187

--- Comment #5 from Harald Judt  ---
Created attachment 83279
  --> https://bugs.freedesktop.org/attachment.cgi?id=83279=edit
dmesg.out

Ok, I gave it a try with new vanilla 3.11-rc3. It ends with the following error
message, though I'm not sure it isn't simply a follow-up problem caused by
previous errors:

[ 2203.028013] [drm:r600_ring_test] *ERROR* radeon: ring 0 test failed
(scratch(0x8504)=0xCAFEDEAD)

As you can deduce from the dmesg.out file attached to the bug report, the first
few tries work ok. The problem seems to be more easily reproducible (but not
restricted to that) when pm_async is enabled. I'm not yet sure it happens with
pm_async off, but by experience, the chances that it does are very likely.

What is a bit strange is that the message "entering sleep state S4" never
appears in the dmesg.out. This _could_ be because I issued "echo reboot >
/sys/power/disk". However, this is about hibernate/resume, as you can see when
you look at the pm messages.

I believe the main problem occurs already at suspend time, because when it
happens, suspend always takes longer than usual, hanging a bit with the monitor
turned off. However, there are no error messages to be found in the log, only
when resuming. Perhaps I should use no_suspend_console and/or net_console.

Also note how the UVD initialization fails, then the machine continues booting
and later you can hibernate again, which will restore UVD but cause the ring 0
failure with CAFEDEAD. At first, the screen is blank, then shows an animated
nostalgic noise picture similar to analog tv that has no reception. The machine
is still responsive and one can ssh in.

Is there perhaps an option to enable for more debugging messages that could
give more insight?

-- 
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/20130730/1c952dbc/attachment.html>

[PATCH 1/3] drm/nouveau: fix vblank interrupt being called before event is setup

2013-07-30 Thread Maarten Lankhorst 
Op 30-07-13 04:42, Ben Skeggs schreef:
> On Tue, Jul 23, 2013 at 11:43 PM, Maarten Lankhorst
>  wrote:
>> Sort of fixes mmiotrace for me again, I could sear I sent a similar patch 
>> before
>> the rework to event interface, so I guess it got reintroduced.
> I don't know how/why you think this fixes anything.  The interrupt
> handler can't possibly be called until after priv->base.vblank has
> been initialised...
>
> Seriously, go look, the subdev interrupt handler pointer isn't filled
> in (and can't be) until after nouveau_disp_create() has been called,
> and nouveau_disp_create() initialises priv->base.vblank before it
> returns...
>
There's also a disp_dtor function right above it and without a smp_wmb
the writes could still be reordered in the constructor. O:-) A spinlock would
be needed to make sure that no interrupt is in process if you set intr to null
before destroying vblank event, though.

I can probably try to get the oops again indicating that priv->base.vblank was 
null in the interrupt handler if you want,
iirc it happened reliably during mmiotracing.

~Maarten

[Bug 60381] AMD Radeon 7770 Ghz edition Crash with DPM active

2013-07-30 Thread bugzilla-dae...@bugzilla.kernel.org 
https://bugzilla.kernel.org/show_bug.cgi?id=60381

--- Comment #35 from Arek Ru?niak  ---
no pain no gain. Now everything works fast as hell.
Even UVD is fliker-free now. Thanks Alex, best regards to you and radeon team.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 60639] RV635: Kernel displays black screen when monitor is connect via DisplayPort

2013-07-30 Thread bugzilla-dae...@bugzilla.kernel.org 
https://bugzilla.kernel.org/show_bug.cgi?id=60639

--- Comment #2 from Alex Deucher  ---
Created attachment 107040
  --> https://bugzilla.kernel.org/attachment.cgi?id=107040=edit
possible fix

The attached patch should fix the issue.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[PATCH v2] drm: use ida to allocate connector ids

2013-07-30 Thread Ilia Mirkin 
This makes it so that reloading a module does not cause all the
connector ids to change, which are user-visible and sometimes used
for configuration.

Signed-off-by: Ilia Mirkin 
---

v1 -> v2: correct loop condition... not sure how that slipped past
me... the code started out by being <= DRM...VIRTUAL, I guess

 drivers/gpu/drm/drm_crtc.c | 61 +++---
 drivers/gpu/drm/drm_drv.c  |  2 ++
 include/drm/drm_crtc.h |  2 ++
 3 files changed, 46 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index fc83bb9..ed7599a 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -186,29 +186,29 @@ static const struct drm_prop_enum_list 
drm_dirty_info_enum_list[] = {
 struct drm_conn_prop_enum_list {
int type;
const char *name;
-   int count;
+   struct ida count;
 };

 /*
  * Connector and encoder types.
  */
 static struct drm_conn_prop_enum_list drm_connector_enum_list[] =
-{  { DRM_MODE_CONNECTOR_Unknown, "Unknown", 0 },
-   { DRM_MODE_CONNECTOR_VGA, "VGA", 0 },
-   { DRM_MODE_CONNECTOR_DVII, "DVI-I", 0 },
-   { DRM_MODE_CONNECTOR_DVID, "DVI-D", 0 },
-   { DRM_MODE_CONNECTOR_DVIA, "DVI-A", 0 },
-   { DRM_MODE_CONNECTOR_Composite, "Composite", 0 },
-   { DRM_MODE_CONNECTOR_SVIDEO, "SVIDEO", 0 },
-   { DRM_MODE_CONNECTOR_LVDS, "LVDS", 0 },
-   { DRM_MODE_CONNECTOR_Component, "Component", 0 },
-   { DRM_MODE_CONNECTOR_9PinDIN, "DIN", 0 },
-   { DRM_MODE_CONNECTOR_DisplayPort, "DP", 0 },
-   { DRM_MODE_CONNECTOR_HDMIA, "HDMI-A", 0 },
-   { DRM_MODE_CONNECTOR_HDMIB, "HDMI-B", 0 },
-   { DRM_MODE_CONNECTOR_TV, "TV", 0 },
-   { DRM_MODE_CONNECTOR_eDP, "eDP", 0 },
-   { DRM_MODE_CONNECTOR_VIRTUAL, "Virtual", 0},
+{  { DRM_MODE_CONNECTOR_Unknown, "Unknown" },
+   { DRM_MODE_CONNECTOR_VGA, "VGA" },
+   { DRM_MODE_CONNECTOR_DVII, "DVI-I" },
+   { DRM_MODE_CONNECTOR_DVID, "DVI-D" },
+   { DRM_MODE_CONNECTOR_DVIA, "DVI-A" },
+   { DRM_MODE_CONNECTOR_Composite, "Composite" },
+   { DRM_MODE_CONNECTOR_SVIDEO, "SVIDEO" },
+   { DRM_MODE_CONNECTOR_LVDS, "LVDS" },
+   { DRM_MODE_CONNECTOR_Component, "Component" },
+   { DRM_MODE_CONNECTOR_9PinDIN, "DIN" },
+   { DRM_MODE_CONNECTOR_DisplayPort, "DP" },
+   { DRM_MODE_CONNECTOR_HDMIA, "HDMI-A" },
+   { DRM_MODE_CONNECTOR_HDMIB, "HDMI-B" },
+   { DRM_MODE_CONNECTOR_TV, "TV" },
+   { DRM_MODE_CONNECTOR_eDP, "eDP" },
+   { DRM_MODE_CONNECTOR_VIRTUAL, "Virtual" },
 };

 static const struct drm_prop_enum_list drm_encoder_enum_list[] =
@@ -220,6 +220,22 @@ static const struct drm_prop_enum_list 
drm_encoder_enum_list[] =
{ DRM_MODE_ENCODER_VIRTUAL, "Virtual" },
 };

+void drm_connector_ida_init(void)
+{
+   int i;
+
+   for (i = 0; i < ARRAY_SIZE(drm_connector_enum_list); i++)
+   ida_init(_connector_enum_list[i].count);
+}
+
+void drm_connector_ida_destroy(void)
+{
+   int i;
+
+   for (i = 0; i < ARRAY_SIZE(drm_connector_enum_list); i++)
+   ida_destroy(_connector_enum_list[i].count);
+}
+
 const char *drm_get_encoder_name(const struct drm_encoder *encoder)
 {
static char buf[32];
@@ -711,6 +727,9 @@ int drm_connector_init(struct drm_device *dev,
   int connector_type)
 {
int ret;
+   struct ida *count = _connector_enum_list[connector_type].count;
+
+   ida_pre_get(count, GFP_KERNEL);

drm_modeset_lock_all(dev);

@@ -722,8 +741,9 @@ int drm_connector_init(struct drm_device *dev,
connector->dev = dev;
connector->funcs = funcs;
connector->connector_type = connector_type;
-   connector->connector_type_id =
-   ++drm_connector_enum_list[connector_type].count; /* TODO */
+   ret = ida_get_new_above(count, 1, >connector_type_id);
+   if (ret)
+   goto out;
INIT_LIST_HEAD(>probed_modes);
INIT_LIST_HEAD(>modes);
connector->edid_blob_ptr = NULL;
@@ -764,6 +784,9 @@ void drm_connector_cleanup(struct drm_connector *connector)
list_for_each_entry_safe(mode, t, >modes, head)
drm_mode_remove(connector, mode);

+   ida_remove(_connector_enum_list[connector->connector_type].count,
+  connector->connector_type_id);
+
drm_mode_object_put(dev, >base);
list_del(>head);
dev->mode_config.num_connector--;
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 99fcd7c..00597a1 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -251,6 +251,7 @@ static int __init drm_core_init(void)
int ret = -ENOMEM;

drm_global_init();
+   drm_connector_ida_init();
idr_init(_minors_idr);

if (register_chrdev(DRM_MAJOR, "drm", _stub_fops))
@@ -298,6 +299,7 @@ static void __exit drm_core_exit(void)

unregister_chrdev(DRM_MAJOR, "drm");

+

[Bug 66963] r600: linux 3.11RC isn't booting with radeon.dpm=1 option in grub

2013-07-30 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=66963

--- Comment #25 from Alex Deucher  ---
Created attachment 83258
  --> https://bugs.freedesktop.org/attachment.cgi?id=83258=edit
use alternate fb_div scale

Another patch to test.

-- 
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/20130730/0348f8ff/attachment-0001.html>

[Bug 66963] r600: linux 3.11RC isn't booting with radeon.dpm=1 option in grub

2013-07-30 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=66963

--- Comment #24 from Alex Deucher  ---
Created attachment 83257
  --> https://bugs.freedesktop.org/attachment.cgi?id=83257=edit
disable lvtma resync

Another patch to test.

-- 
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/20130730/a119ee94/attachment.html>

[PATCH] drm: use ida to allocate connector ids

2013-07-30 Thread Ilia Mirkin 
This makes it so that reloading a module does not cause all the
connector ids to change, which are user-visible and sometimes used
for configuration.

Signed-off-by: Ilia Mirkin 
---

Only mild testing... reloaded nouveau a few times, all the connectors
kept their original ids.

 drivers/gpu/drm/drm_crtc.c | 61 +++---
 drivers/gpu/drm/drm_drv.c  |  2 ++
 include/drm/drm_crtc.h |  2 ++
 3 files changed, 46 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index fc83bb9..fff238f 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -186,29 +186,29 @@ static const struct drm_prop_enum_list 
drm_dirty_info_enum_list[] = {
 struct drm_conn_prop_enum_list {
int type;
const char *name;
-   int count;
+   struct ida count;
 };

 /*
  * Connector and encoder types.
  */
 static struct drm_conn_prop_enum_list drm_connector_enum_list[] =
-{  { DRM_MODE_CONNECTOR_Unknown, "Unknown", 0 },
-   { DRM_MODE_CONNECTOR_VGA, "VGA", 0 },
-   { DRM_MODE_CONNECTOR_DVII, "DVI-I", 0 },
-   { DRM_MODE_CONNECTOR_DVID, "DVI-D", 0 },
-   { DRM_MODE_CONNECTOR_DVIA, "DVI-A", 0 },
-   { DRM_MODE_CONNECTOR_Composite, "Composite", 0 },
-   { DRM_MODE_CONNECTOR_SVIDEO, "SVIDEO", 0 },
-   { DRM_MODE_CONNECTOR_LVDS, "LVDS", 0 },
-   { DRM_MODE_CONNECTOR_Component, "Component", 0 },
-   { DRM_MODE_CONNECTOR_9PinDIN, "DIN", 0 },
-   { DRM_MODE_CONNECTOR_DisplayPort, "DP", 0 },
-   { DRM_MODE_CONNECTOR_HDMIA, "HDMI-A", 0 },
-   { DRM_MODE_CONNECTOR_HDMIB, "HDMI-B", 0 },
-   { DRM_MODE_CONNECTOR_TV, "TV", 0 },
-   { DRM_MODE_CONNECTOR_eDP, "eDP", 0 },
-   { DRM_MODE_CONNECTOR_VIRTUAL, "Virtual", 0},
+{  { DRM_MODE_CONNECTOR_Unknown, "Unknown" },
+   { DRM_MODE_CONNECTOR_VGA, "VGA" },
+   { DRM_MODE_CONNECTOR_DVII, "DVI-I" },
+   { DRM_MODE_CONNECTOR_DVID, "DVI-D" },
+   { DRM_MODE_CONNECTOR_DVIA, "DVI-A" },
+   { DRM_MODE_CONNECTOR_Composite, "Composite" },
+   { DRM_MODE_CONNECTOR_SVIDEO, "SVIDEO" },
+   { DRM_MODE_CONNECTOR_LVDS, "LVDS" },
+   { DRM_MODE_CONNECTOR_Component, "Component" },
+   { DRM_MODE_CONNECTOR_9PinDIN, "DIN" },
+   { DRM_MODE_CONNECTOR_DisplayPort, "DP" },
+   { DRM_MODE_CONNECTOR_HDMIA, "HDMI-A" },
+   { DRM_MODE_CONNECTOR_HDMIB, "HDMI-B" },
+   { DRM_MODE_CONNECTOR_TV, "TV" },
+   { DRM_MODE_CONNECTOR_eDP, "eDP" },
+   { DRM_MODE_CONNECTOR_VIRTUAL, "Virtual" },
 };

 static const struct drm_prop_enum_list drm_encoder_enum_list[] =
@@ -220,6 +220,22 @@ static const struct drm_prop_enum_list 
drm_encoder_enum_list[] =
{ DRM_MODE_ENCODER_VIRTUAL, "Virtual" },
 };

+void drm_connector_ida_init(void)
+{
+   int i;
+
+   for (i = 0; i <= ARRAY_SIZE(drm_connector_enum_list); i++)
+   ida_init(_connector_enum_list[i].count);
+}
+
+void drm_connector_ida_destroy(void)
+{
+   int i;
+
+   for (i = 0; i <= ARRAY_SIZE(drm_connector_enum_list); i++)
+   ida_destroy(_connector_enum_list[i].count);
+}
+
 const char *drm_get_encoder_name(const struct drm_encoder *encoder)
 {
static char buf[32];
@@ -711,6 +727,9 @@ int drm_connector_init(struct drm_device *dev,
   int connector_type)
 {
int ret;
+   struct ida *count = _connector_enum_list[connector_type].count;
+
+   ida_pre_get(count, GFP_KERNEL);

drm_modeset_lock_all(dev);

@@ -722,8 +741,9 @@ int drm_connector_init(struct drm_device *dev,
connector->dev = dev;
connector->funcs = funcs;
connector->connector_type = connector_type;
-   connector->connector_type_id =
-   ++drm_connector_enum_list[connector_type].count; /* TODO */
+   ret = ida_get_new_above(count, 1, >connector_type_id);
+   if (ret)
+   goto out;
INIT_LIST_HEAD(>probed_modes);
INIT_LIST_HEAD(>modes);
connector->edid_blob_ptr = NULL;
@@ -764,6 +784,9 @@ void drm_connector_cleanup(struct drm_connector *connector)
list_for_each_entry_safe(mode, t, >modes, head)
drm_mode_remove(connector, mode);

+   ida_remove(_connector_enum_list[connector->connector_type].count,
+  connector->connector_type_id);
+
drm_mode_object_put(dev, >base);
list_del(>head);
dev->mode_config.num_connector--;
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 99fcd7c..00597a1 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -251,6 +251,7 @@ static int __init drm_core_init(void)
int ret = -ENOMEM;

drm_global_init();
+   drm_connector_ida_init();
idr_init(_minors_idr);

if (register_chrdev(DRM_MAJOR, "drm", _stub_fops))
@@ -298,6 +299,7 @@ static void __exit drm_core_exit(void)

unregister_chrdev(DRM_MAJOR, "drm");

+

[Bug 66942] Cayman HD 6950 hangs at start when loading kernel 3.11.0-rc1 or drm-next

2013-07-30 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=66942

--- Comment #19 from Alex Deucher  ---
Does booting a recent 3.11rc kernel with radeon.aspm=0 help?

-- 
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/20130730/3f32e572/attachment.html>

[Bug 66942] Cayman HD 6950 hangs at start when loading kernel 3.11.0-rc1 or drm-next

2013-07-30 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=66942

--- Comment #18 from Alex Deucher  ---
(In reply to comment #17)
> Alex, is there a chance for me to reverse some commits prior to 69e0b57 to
> find which one or which feature is hanging my computer? Any approach I
> should try?

I'm not really sure what would have broken your system.  I also don't really
see how 69e0b57 could have broken anything since nothing changes with that as
long as dpm is disabled.  Do you still have the issue if you reset your tree to
the commit prior to 69e0b57?  Do you still get hangs if you disable radeon
(e.g., add radeon.modeset=0 to your kernel command line in grub)?

-- 
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/20130730/d862c897/attachment.html>

[Bug 66942] Cayman HD 6950 hangs at start when loading kernel 3.11.0-rc1 or drm-next

2013-07-30 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=66942

--- Comment #17 from Alexandre Demers  ---
Alex, is there a chance for me to reverse some commits prior to 69e0b57 to find
which one or which feature is hanging my computer? Any approach I should try?

-- 
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/20130730/da9167ce/attachment.html>

[PATCH 08/14] backports: backport ww_mutex support

2013-07-30 Thread Luis R. Rodriguez 
From: "Luis R. Rodriguez" 

This backports the kernel's wound/wait style locks 040a0a371,
using the linux-stable v3.11-rc2 as a base for development.
Given the complexity to support debugging mutexes this backport
implementation is simplified by only making this feature availabe
if you to have DEBUG_MUTEXES and DEBUG_LOCK_ALLOC disabled.

Given that ww mutex is required for DRM this also means we must
update the kconfig for DRM and require you to also not be able to build
DRM if you have either of these options enabled. Support for
DEBUG_MUTEXES and DEBUG_LOCK_ALLOC can be added later by anyone
daring. This uses the new dependencies file kconfig language
extension to specify the backport feature build restrictions
for DRM.

Part of the ww mutex addition to the kernel required modifying
the fast path mutex locking scheme by requiring you to deal
with the slow path alternatives on your own (refer to a41b56ef).
The reason for this change was that the mutex fastpath implementation
assumed your slowpath alternative can only be passed one argument
and the addition of ww mutexes requires dealing with the slow
path with a context passed.

It'd be painful to backport all asm for an optimized fastpath
implementation so we penalize the backport ww mutex fast path
by using the generic atomic_dec_return().

To backport a clean our own mutex_lock_common() with the least
amount of changes against upstream commits 2bd2c92c and 41fcb9f2
also needed to be backported. Commit 2bd2c92c dealt with adding
support for queue mutex spinners with an MCS lock, since this
cannot be backported for older kernels we provide empty inlines.
Commit 41fcb9f2 just removed SCHED_FEAT_OWNER_SPIN as it was an
early hack, the only thing required to backport this commit was
to provide an alternative declaration for mutex_spin_on_owner()
as it was declared non-inline for older kernels.

Finally c5491ea7 required backporting schedule_preempt_disabled()
as well but that just consisted of carrying over the original
implementation. Since its not exported we need to reimplement
it to make it available to our internal core ww mutex port.

mcgrof at frijol ~/linux-stable (git::master)$ git describe --contains 040a0a371
v3.11-rc1~147^2~5

mcgrof at frijol ~/linux-stable (git::master)$ git describe --contains a41b56ef
v3.11-rc1~147^2~6

mcgrof at frijol ~/linux-stable (git::master)$ git describe --contains 2bd2c92c
v3.10-rc1~200^2~3

mcgrof at frijol ~/linux-stable (git::master)$ git describe --contains 41fcb9f2
v3.10-rc1~200^2~5

mcgrof at frijol ~/linux-stable (git::master)$ git describe --contains c5491ea7
v3.4-rc1~3^2~27

commit 040a0a37100563754bb1fee6ff6427420bcfa609
Author: Maarten Lankhorst 
Date:   Mon Jun 24 10:30:04 2013 +0200

mutex: Add support for wound/wait style locks

Wound/wait mutexes are used when other multiple lock
acquisitions of a similar type can be done in an arbitrary
order. The deadlock handling used here is called wait/wound in
the RDBMS literature: The older tasks waits until it can acquire
the contended lock. The younger tasks needs to back off and drop
all the locks it is currently holding, i.e. the younger task is
wounded.

For full documentation please read Documentation/ww-mutex-design.txt.

References: https://lwn.net/Articles/548909/
Signed-off-by: Maarten Lankhorst 
Acked-by: Daniel Vetter 
Acked-by: Rob Clark 
Acked-by: Peter Zijlstra 
Cc: dri-devel at lists.freedesktop.org
Cc: linaro-mm-sig at lists.linaro.org
Cc: rostedt at goodmis.org
Cc: daniel at ffwll.ch
Cc: Linus Torvalds 
Cc: Andrew Morton 
Cc: Thomas Gleixner 
Link: http://lkml.kernel.org/r/51C8038C.9000106 at canonical.com
Signed-off-by: Ingo Molnar 

commit a41b56efa70e060f650aeb54740aaf52044a1ead
Author: Maarten Lankhorst 
Date:   Thu Jun 20 13:31:05 2013 +0200

arch: Make __mutex_fastpath_lock_retval return whether fastpath succeeded 
or not

This will allow me to call functions that have multiple
arguments if fastpath fails. This is required to support ticket
mutexes, because they need to be able to pass an extra argument
to the fail function.

Originally I duplicated the functions, by adding
__mutex_fastpath_lock_retval_arg. This ended up being just a
duplication of the existing function, so a way to test if
fastpath was called ended up being better.

This also cleaned up the reservation mutex patch some by being
able to call an atomic_set instead of atomic_xchg, and making it
easier to detect if the wrong unlock function was previously
used.

Signed-off-by: Maarten Lankhorst 
Acked-by: Peter Zijlstra 
Cc: dri-devel at lists.freedesktop.org
Cc: linaro-mm-sig at lists.linaro.org
Cc: robclark at gmail.com
Cc: rostedt at goodmis.org
Cc: daniel at ffwll.ch
Cc: Linus Torvalds 
Cc: Andrew Morton 
Cc: Thomas Gleixner 
Link:

[GIT PULL] exynos-drm-fixes

2013-07-30 Thread inki....@samsung.com 
Hi Dave,
   This pull request fixes module build and g2d clock
   control issues, and includes related cleanup.

Please kindly let me know if there is any problem.

Thanks,
Inki Dae

The following changes since commit bf903e4141fce4b35072d5b8fa0ddd299aaf01ea:

  Merge tag 'drm-intel-fixes-2013-07-25' of 
git://people.freedesktop.org/~danvet/drm-intel into drm-fixes (2013-07-26 
20:38:14 +1000)

are available in the git repository at:


  git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git 
exynos-drm-fixes

for you to fetch changes up to db70d16ef63dbd412a974c893c52ee5ad0777d21:

  drm/exynos: Remove module.h header inclusion (2013-07-30 02:01:54 +0900)


Inki Dae (2):
  drm/exynos: fix module build error
  drm/exynos: consider common clock framework to g2d driver.

Sachin Kamat (1):
  drm/exynos: Remove module.h header inclusion

Wei Yongjun (1):
  drm/exynos: exynos_drm_ipp: fix return value check

 drivers/gpu/drm/exynos/exynos_ddc.c |  1 -
 drivers/gpu/drm/exynos/exynos_drm_fimc.c|  1 -
 drivers/gpu/drm/exynos/exynos_drm_fimd.c|  3 ---
 drivers/gpu/drm/exynos/exynos_drm_g2d.c | 19 ++-
 drivers/gpu/drm/exynos/exynos_drm_gsc.c |  1 -
 drivers/gpu/drm/exynos/exynos_drm_hdmi.c|  1 -
 drivers/gpu/drm/exynos/exynos_drm_ipp.c | 13 ++---
 drivers/gpu/drm/exynos/exynos_drm_rotator.c |  1 -
 drivers/gpu/drm/exynos/exynos_drm_vidi.c|  1 -
 drivers/gpu/drm/exynos/exynos_hdmi.c|  1 -
 drivers/gpu/drm/exynos/exynos_hdmiphy.c |  1 -
 drivers/gpu/drm/exynos/exynos_mixer.c   |  1 -
 12 files changed, 20 insertions(+), 24 deletions(-)

[Bug 60381] AMD Radeon 7770 Ghz edition Crash with DPM active

2013-07-30 Thread bugzilla-dae...@bugzilla.kernel.org 
https://bugzilla.kernel.org/show_bug.cgi?id=60381

--- Comment #34 from rafael castillo  ---
tested with today drm-fixes patches and its reclocking like a boss and xonotic
passed from 30 FPS to an massive 190FPS in ultimate at 1366x768. i read you
need some fixes for other part of asic for later so is up to you if you wish to
close the bug report.

again a hundred bazillions thanks this is just awesome now

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 66963] r600: linux 3.11RC isn't booting with radeon.dpm=1 option in grub

2013-07-30 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=66963

--- Comment #23 from Alex Deucher  ---
Created attachment 83246
  --> https://bugs.freedesktop.org/attachment.cgi?id=83246=edit
hacks to test

That attached patch disables some options in the dpm driver.  See if it helps
at all.  Make sure you are using a kernel that contains the fixes mentioned in
comment 9 or my drm-fixes-3.11 branch.

If the patch doesn't work as is, try changing the:
#if 1
in the patch to:
#if 0
and see if that helps.

Please attach your dmesg output with the patch applied.

-- 
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/20130730/52b63041/attachment.html>

[Bug 67435] HDMI audio silent on Radeon Mobility HD4650

2013-07-30 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=67435

--- Comment #14 from Alex Deucher  ---
Can you boot back into the broken state and try this alternative fix:
avivotool regset 0x7344 0x0170

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:

[Bug 67435] HDMI audio silent on Radeon Mobility HD4650

2013-07-30 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=67435

--- Comment #13 from Kris Scott  ---
That is also after I had changed the registers that Rafal asked me to change,
if it makes any difference.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:

[Bug 67435] HDMI audio silent on Radeon Mobility HD4650

2013-07-30 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=67435

--- Comment #12 from Kris Scott  ---
0x73400x001b0018 (1769496)
0x73440x0070 (112)
0x5200x0070 (112)
0x5300x0070 (112)

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:

[Bug 67435] HDMI audio silent on Radeon Mobility HD4650

2013-07-30 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=67435

--- Comment #11 from Alex Deucher  ---
Can you tell be the values of 0x7340, 0x7344, 0x520, and 0x530?
avivotool regmatch 0x7340
avivotool regmatch 0x7344
avivotool regmatch 0x520
avivotool regmatch 0x530

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:

Re: [RFC 0/2] exynos5250/hdmi: replace dummy hdmiphy clock with pmu reg control

2013-07-30 Thread Seung-Woo Kim 
Hi Rahul,

On 2013년 07월 30일 12:42, Rahul Sharma wrote:
 
 
 On Tue, Jun 18, 2013 at 5:07 PM, Kishon Vijay Abraham I kis...@ti.com
 mailto:kis...@ti.com wrote:
 
 Hi,
 
 On Tuesday 18 June 2013 03:33 PM, Rahul Sharma wrote:
  Thanks all,
 
  On Fri, Jun 14, 2013 at 11:39 AM, 김승우 sw0312@samsung.com
 mailto:sw0312@samsung.com wrote:
  Hello Kishon,
 
  On 2013년 06월 13일 21:54, Kishon Vijay Abraham I wrote:
  Hi,
 
  On Thursday 13 June 2013 04:51 PM, Inki Dae wrote:
 
 
  -Original Message-
  From: Sylwester Nawrocki [mailto:s.nawro...@samsung.com
 mailto:s.nawro...@samsung.com]
  Sent: Thursday, June 13, 2013 5:56 PM
  To: Rahul Sharma
  Cc: Rahul Sharma; Inki Dae; linux-samsung-...@vger.kernel.org
 mailto:linux-samsung-...@vger.kernel.org;
  devicetree-
  disc...@lists.ozlabs.org mailto:disc...@lists.ozlabs.org;
 DRI mailing list; Kukjin Kim; Seung-Woo Kim;
  Sean Paul; sunil joshi; Kishon Vijay Abraham I; Stephen Warren;
  grant.lik...@linaro.org mailto:grant.lik...@linaro.org
  Subject: Re: [RFC 0/2] exynos5250/hdmi: replace dummy hdmiphy
 clock with
  pmu reg control
 
  Hi,
 
  On 06/13/2013 06:26 AM, Rahul Sharma wrote:
  Mr. Dae,
 
  Thanks for your valuable inputs.
 
  I posted it as RFC because, I also have received comments to
 register
  hdmiphy as a clock controller. As we always configure it for
 specific
  frequency, hdmi-phy looks similar to a PLL. But it really doesn't
  belong to that class. Secondly prior to exynos5420, it was a i2c
  device. I am not sure we can register a I2C device as a clock
  controller. I wanted to discuss and explore this option here.
 
  Have you considered using the generic PHY framework for those HDMI
  PHY devices [1] ? I guess we could add a dedicated group of
 ops for
  video PHYs, similarly as is is done with struct
 v4l2_subdev_ops. For
  configuring things like the carrier/pixel clock frequency or
 anything
  what's common across the video PHYs.
 
  Perhaps you could have a look and see if this framework would be
  useful for HDMI and possibly point out anything what might be
 missing ?
 
  I'm not sure it it really solves the issues specific to the Exynos
  HDMI but at least with a generic PHY driver the PHY module
 would be
  separate from the PHY controller, as often same HDMI DPHY can
 be used
  with various types of a HDMI controller. So this would allow
 to not
  duplicate the HDMI PHY drivers in the long-term perspective.
 
  Yeah, at least, it seems that we could use PHY module to
 control PMU
  register, HDMI_PHY_CONTROL. However, PHY module provides only
 init/on/off
  callbacks. As you may know, HDMIPHY needs i2c interfaces to control
  HDMIPHY
  clock. So with PHY module, HDMIPHY driver could enable PMU more
  generically,
  but also has to use existing i2c stuff to control HDMIPHY
 clock. I had a
  quick review to Generic PHY Framework[v6] but I didn't see that
 the PHY
  module could generically support more features such as i2c stuff.
 
  I don't think PHY framework needs to provide i2c interfaces to
 program
  certain configurations. Instead in one of the callbacks
 (init/on/off)
  PHY driver can program whatever it wants using any of the
 interfaces it
  needs. IMO PHY framework should work independent of the interfaces.
 
  In exnoys hdmi case, i2c interface is not the exact issue. In exynos
  hdmi, hdmiphy should send i2c configuration about video clock
  information as the video mode information including resolution,
 bit per
  pixel, refresh rate passed from drm subsystem. So init/on/off
 callbacks
  of phy framework are not enough for exynos hdmiphy and it should
 have a
  callback to set video mode.
 
  Do you have plan to add driver specific extend callback pointers
 to phy
  framework?
 
  Currently, hdmi directly calls phy operations, but Rahul's
 another patch
  set, mentioned by Inki, divides hdmi and hdmiphy and hdmi and
 hdmiphy is
  connected with exynos hdmi own sub driver callback operations.
 
  IMHO, if phy framework can support extend callback feature, then this
  own sub driver callbacks can be replaced with phy framework at
 long term
  view.
 
  Extended callbacks are always welcome. I can also use phy device
  private data to pass on private ops like get_pixelclk and
 set_pixelclk.
 
 I would recommend creating a wrapper to the existing PHY framework
 for HDMI PHY. That way, we can have other HDMI phys added
 easily. We need to figure out all the ops that might be needed by the
 HDMI PHY to be added to the wrapper.
 IMO

Re: [PATCH 1/3] drm/nouveau: fix vblank interrupt being called before event is setup

2013-07-30 Thread Maarten Lankhorst 
Op 30-07-13 04:42, Ben Skeggs schreef:
 On Tue, Jul 23, 2013 at 11:43 PM, Maarten Lankhorst
 maarten.lankho...@canonical.com wrote:
 Sort of fixes mmiotrace for me again, I could sear I sent a similar patch 
 before
 the rework to event interface, so I guess it got reintroduced.
 I don't know how/why you think this fixes anything.  The interrupt
 handler can't possibly be called until after priv-base.vblank has
 been initialised...

 Seriously, go look, the subdev interrupt handler pointer isn't filled
 in (and can't be) until after nouveau_disp_create() has been called,
 and nouveau_disp_create() initialises priv-base.vblank before it
 returns...

There's also a disp_dtor function right above it and without a smp_wmb
the writes could still be reordered in the constructor. O:-) A spinlock would
be needed to make sure that no interrupt is in process if you set intr to null
before destroying vblank event, though.

I can probably try to get the oops again indicating that priv-base.vblank was 
null in the interrupt handler if you want,
iirc it happened reliably during mmiotracing.

~Maarten
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/3] drm/nouveau: fix vblank interrupt being called before event is setup

2013-07-30 Thread Ben Skeggs 
On Tue, Jul 30, 2013 at 4:10 PM, Maarten Lankhorst
maarten.lankho...@canonical.com wrote:
 Op 30-07-13 04:42, Ben Skeggs schreef:
 On Tue, Jul 23, 2013 at 11:43 PM, Maarten Lankhorst
 maarten.lankho...@canonical.com wrote:
 Sort of fixes mmiotrace for me again, I could sear I sent a similar patch 
 before
 the rework to event interface, so I guess it got reintroduced.
 I don't know how/why you think this fixes anything.  The interrupt
 handler can't possibly be called until after priv-base.vblank has
 been initialised...

 Seriously, go look, the subdev interrupt handler pointer isn't filled
 in (and can't be) until after nouveau_disp_create() has been called,
 and nouveau_disp_create() initialises priv-base.vblank before it
 returns...

 There's also a disp_dtor function right above it and without a smp_wmb
 the writes could still be reordered in the constructor. O:-) A spinlock would
 be needed to make sure that no interrupt is in process if you set intr to null
 before destroying vblank event, though.

 I can probably try to get the oops again indicating that priv-base.vblank 
 was null in the interrupt handler if you want,
 iirc it happened reliably during mmiotracing.
It would've had to have happened during a module unload in that case,
I can't see how else it could've possibly happened.

The destructor case is valid though, but not really a critical issue,
so I'd rather find a better solution than these hacked checks :)  I'll
add it to the list...

Ben.


 ~Maarten
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 4/4] snd/hda: add runtime suspend/resume on optimus support

2013-07-30 Thread Dave Airlie 
On Mon, Jul 29, 2013 at 10:46 PM, Takashi Iwai ti...@suse.de wrote:
 At Mon, 29 Jul 2013 16:06:59 +1000,
 Dave Airlie wrote:

 Add support for HDMI audio device on VGA cards that powerdown
 to D3cold using non-standard ACPI/PCI infrastructure (optimus).

 This does a couple of things to make it work:

 a) add a set of power ops for the hdmi domain, and enables them
 via vga_switcheroo when we are a switcheroo controlled card. This
 just replaces the runtime resume operation so that when the card
 is in D3cold the userspace pci config space access via sysfs,
 the vga switcheroon runtime resume gets called first and it calls
 the GPU resume callback before calling the sound card runtime
 resume.

 b) standard ACPI/PCI stacks won't put a device into D3cold without
 an ACPI handle, but since the hdmi audio devices on gpus don't have
 an ACPI handle, we need to manually force the device into D3cold
 after suspend from the switcheroo path only.

 c) don't try and do runtime s/r when the GPU is off.

 d) call runtime suspend/resume during switcheroo suspend/resume
 this is to make sure the runtime stack knows to try and resume
 the hdmi audio device for pci config space access.

 Signed-off-by: Dave Airlie airl...@redhat.com
 ---
  sound/pci/hda/hda_intel.c | 40 +---
  1 file changed, 37 insertions(+), 3 deletions(-)

 diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
 index 8860dd5..4b4d05b 100644
 --- a/sound/pci/hda/hda_intel.c
 +++ b/sound/pci/hda/hda_intel.c
 @@ -555,6 +555,9 @@ struct azx {
  #ifdef CONFIG_SND_HDA_DSP_LOADER
   struct azx_dev saved_azx_dev;
  #endif
 +
 + /* secondary power domain for hdmi audio under vga device */
 + struct dev_pm_domain hdmi_pm_domain;
  };

  #define CREATE_TRACE_POINTS
 @@ -2898,7 +2901,7 @@ static int param_set_xint(const char *val, const 
 struct kernel_param *kp)
  /*
   * power management
   */
 -static int azx_suspend(struct device *dev)
 +static int azx_do_suspend(struct device *dev, pci_power_t state)
  {
   struct pci_dev *pci = to_pci_dev(dev);
   struct snd_card *card = dev_get_drvdata(dev);
 @@ -2920,16 +2923,30 @@ static int azx_suspend(struct device *dev)
   free_irq(chip-irq, chip);
   chip-irq = -1;
   }
 +
 + /*
 +  * for vga switcheroo suspend we need to
 +  * force runtime suspend so lspci works.
 +  */
 + if (state == PCI_D3cold)
 + pm_runtime_suspend(pci-dev);
 +
   if (chip-msi)
   pci_disable_msi(chip-pci);
   pci_disable_device(pci);
   pci_save_state(pci);
 - pci_set_power_state(pci, PCI_D3hot);
 +
 + pci_set_power_state(pci, state);
   if (chip-driver_caps  AZX_DCAPS_I915_POWERWELL)
   hda_display_power(false);
   return 0;
  }

 +static int azx_suspend(struct device *dev)
 +{
 + return azx_do_suspend(dev, PCI_D3hot);
 +}
 +
  static int azx_resume(struct device *dev)
  {
   struct pci_dev *pci = to_pci_dev(dev);
 @@ -2971,6 +2988,9 @@ static int azx_runtime_suspend(struct device *dev)
   struct snd_card *card = dev_get_drvdata(dev);
   struct azx *chip = card-private_data;

 + if (chip-disabled)
 + return 0;
 +
   azx_stop_chip(chip);
   azx_enter_link_reset(chip);
   azx_clear_irq_pending(chip);
 @@ -2984,6 +3004,9 @@ static int azx_runtime_resume(struct device *dev)
   struct snd_card *card = dev_get_drvdata(dev);
   struct azx *chip = card-private_data;

 + if (chip-disabled)
 + return 0;
 +
   if (chip-driver_caps  AZX_DCAPS_I915_POWERWELL)
   hda_display_power(true);
   azx_init_pci(chip);
 @@ -2996,6 +3019,9 @@ static int azx_runtime_idle(struct device *dev)
   struct snd_card *card = dev_get_drvdata(dev);
   struct azx *chip = card-private_data;

 + if (chip-disabled)
 + return 0;
 +
   if (!power_save_controller ||
   !(chip-driver_caps  AZX_DCAPS_PM_RUNTIME))
   return -EBUSY;
 @@ -3078,7 +3104,11 @@ static void azx_vs_set_state(struct pci_dev *pci,
  %s: %s via VGA-switcheroo\n, pci_name(chip-pci),
  disabled ? Disabling : Enabling);
   if (disabled) {
 - azx_suspend(pci-dev);
 + azx_do_suspend(pci-dev, PCI_D3cold);
 + /* when we get suspended by vga switcheroo we end up 
 in D3cold,
 +  * however we have no ACPI handle, so pci/acpi can't 
 put us there,
 +  * put ourselves there */
 + pci-current_state = PCI_D3cold;
   chip-disabled = true;
   if (snd_hda_lock_devices(chip-bus))
   snd_printk(KERN_WARNING SFX %s: Cannot lock 
 devices!\n,
 @@ -3087,6 +3117,7 @@ static void azx_vs_set_state(struct pci_dev *pci,
   snd_hda_unlock_devices(chip-bus);

[PATCH] drm: use ida to allocate connector ids

2013-07-30 Thread Ilia Mirkin 
This makes it so that reloading a module does not cause all the
connector ids to change, which are user-visible and sometimes used
for configuration.

Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
---

Only mild testing... reloaded nouveau a few times, all the connectors
kept their original ids.

 drivers/gpu/drm/drm_crtc.c | 61 +++---
 drivers/gpu/drm/drm_drv.c  |  2 ++
 include/drm/drm_crtc.h |  2 ++
 3 files changed, 46 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index fc83bb9..fff238f 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -186,29 +186,29 @@ static const struct drm_prop_enum_list 
drm_dirty_info_enum_list[] = {
 struct drm_conn_prop_enum_list {
int type;
const char *name;
-   int count;
+   struct ida count;
 };
 
 /*
  * Connector and encoder types.
  */
 static struct drm_conn_prop_enum_list drm_connector_enum_list[] =
-{  { DRM_MODE_CONNECTOR_Unknown, Unknown, 0 },
-   { DRM_MODE_CONNECTOR_VGA, VGA, 0 },
-   { DRM_MODE_CONNECTOR_DVII, DVI-I, 0 },
-   { DRM_MODE_CONNECTOR_DVID, DVI-D, 0 },
-   { DRM_MODE_CONNECTOR_DVIA, DVI-A, 0 },
-   { DRM_MODE_CONNECTOR_Composite, Composite, 0 },
-   { DRM_MODE_CONNECTOR_SVIDEO, SVIDEO, 0 },
-   { DRM_MODE_CONNECTOR_LVDS, LVDS, 0 },
-   { DRM_MODE_CONNECTOR_Component, Component, 0 },
-   { DRM_MODE_CONNECTOR_9PinDIN, DIN, 0 },
-   { DRM_MODE_CONNECTOR_DisplayPort, DP, 0 },
-   { DRM_MODE_CONNECTOR_HDMIA, HDMI-A, 0 },
-   { DRM_MODE_CONNECTOR_HDMIB, HDMI-B, 0 },
-   { DRM_MODE_CONNECTOR_TV, TV, 0 },
-   { DRM_MODE_CONNECTOR_eDP, eDP, 0 },
-   { DRM_MODE_CONNECTOR_VIRTUAL, Virtual, 0},
+{  { DRM_MODE_CONNECTOR_Unknown, Unknown },
+   { DRM_MODE_CONNECTOR_VGA, VGA },
+   { DRM_MODE_CONNECTOR_DVII, DVI-I },
+   { DRM_MODE_CONNECTOR_DVID, DVI-D },
+   { DRM_MODE_CONNECTOR_DVIA, DVI-A },
+   { DRM_MODE_CONNECTOR_Composite, Composite },
+   { DRM_MODE_CONNECTOR_SVIDEO, SVIDEO },
+   { DRM_MODE_CONNECTOR_LVDS, LVDS },
+   { DRM_MODE_CONNECTOR_Component, Component },
+   { DRM_MODE_CONNECTOR_9PinDIN, DIN },
+   { DRM_MODE_CONNECTOR_DisplayPort, DP },
+   { DRM_MODE_CONNECTOR_HDMIA, HDMI-A },
+   { DRM_MODE_CONNECTOR_HDMIB, HDMI-B },
+   { DRM_MODE_CONNECTOR_TV, TV },
+   { DRM_MODE_CONNECTOR_eDP, eDP },
+   { DRM_MODE_CONNECTOR_VIRTUAL, Virtual },
 };
 
 static const struct drm_prop_enum_list drm_encoder_enum_list[] =
@@ -220,6 +220,22 @@ static const struct drm_prop_enum_list 
drm_encoder_enum_list[] =
{ DRM_MODE_ENCODER_VIRTUAL, Virtual },
 };
 
+void drm_connector_ida_init(void)
+{
+   int i;
+
+   for (i = 0; i = ARRAY_SIZE(drm_connector_enum_list); i++)
+   ida_init(drm_connector_enum_list[i].count);
+}
+
+void drm_connector_ida_destroy(void)
+{
+   int i;
+
+   for (i = 0; i = ARRAY_SIZE(drm_connector_enum_list); i++)
+   ida_destroy(drm_connector_enum_list[i].count);
+}
+
 const char *drm_get_encoder_name(const struct drm_encoder *encoder)
 {
static char buf[32];
@@ -711,6 +727,9 @@ int drm_connector_init(struct drm_device *dev,
   int connector_type)
 {
int ret;
+   struct ida *count = drm_connector_enum_list[connector_type].count;
+
+   ida_pre_get(count, GFP_KERNEL);
 
drm_modeset_lock_all(dev);
 
@@ -722,8 +741,9 @@ int drm_connector_init(struct drm_device *dev,
connector-dev = dev;
connector-funcs = funcs;
connector-connector_type = connector_type;
-   connector-connector_type_id =
-   ++drm_connector_enum_list[connector_type].count; /* TODO */
+   ret = ida_get_new_above(count, 1, connector-connector_type_id);
+   if (ret)
+   goto out;
INIT_LIST_HEAD(connector-probed_modes);
INIT_LIST_HEAD(connector-modes);
connector-edid_blob_ptr = NULL;
@@ -764,6 +784,9 @@ void drm_connector_cleanup(struct drm_connector *connector)
list_for_each_entry_safe(mode, t, connector-modes, head)
drm_mode_remove(connector, mode);
 
+   ida_remove(drm_connector_enum_list[connector-connector_type].count,
+  connector-connector_type_id);
+
drm_mode_object_put(dev, connector-base);
list_del(connector-head);
dev-mode_config.num_connector--;
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 99fcd7c..00597a1 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -251,6 +251,7 @@ static int __init drm_core_init(void)
int ret = -ENOMEM;
 
drm_global_init();
+   drm_connector_ida_init();
idr_init(drm_minors_idr);
 
if (register_chrdev(DRM_MAJOR, drm, drm_stub_fops))
@@ -298,6 +299,7 @@ static void __exit drm_core_exit(void)
 
unregister_chrdev(DRM_MAJOR, drm);
 
+

[PATCH v2] drm: use ida to allocate connector ids

2013-07-30 Thread Ilia Mirkin 
This makes it so that reloading a module does not cause all the
connector ids to change, which are user-visible and sometimes used
for configuration.

Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
---

v1 - v2: correct loop condition... not sure how that slipped past
me... the code started out by being = DRM...VIRTUAL, I guess

 drivers/gpu/drm/drm_crtc.c | 61 +++---
 drivers/gpu/drm/drm_drv.c  |  2 ++
 include/drm/drm_crtc.h |  2 ++
 3 files changed, 46 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index fc83bb9..ed7599a 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -186,29 +186,29 @@ static const struct drm_prop_enum_list 
drm_dirty_info_enum_list[] = {
 struct drm_conn_prop_enum_list {
int type;
const char *name;
-   int count;
+   struct ida count;
 };
 
 /*
  * Connector and encoder types.
  */
 static struct drm_conn_prop_enum_list drm_connector_enum_list[] =
-{  { DRM_MODE_CONNECTOR_Unknown, Unknown, 0 },
-   { DRM_MODE_CONNECTOR_VGA, VGA, 0 },
-   { DRM_MODE_CONNECTOR_DVII, DVI-I, 0 },
-   { DRM_MODE_CONNECTOR_DVID, DVI-D, 0 },
-   { DRM_MODE_CONNECTOR_DVIA, DVI-A, 0 },
-   { DRM_MODE_CONNECTOR_Composite, Composite, 0 },
-   { DRM_MODE_CONNECTOR_SVIDEO, SVIDEO, 0 },
-   { DRM_MODE_CONNECTOR_LVDS, LVDS, 0 },
-   { DRM_MODE_CONNECTOR_Component, Component, 0 },
-   { DRM_MODE_CONNECTOR_9PinDIN, DIN, 0 },
-   { DRM_MODE_CONNECTOR_DisplayPort, DP, 0 },
-   { DRM_MODE_CONNECTOR_HDMIA, HDMI-A, 0 },
-   { DRM_MODE_CONNECTOR_HDMIB, HDMI-B, 0 },
-   { DRM_MODE_CONNECTOR_TV, TV, 0 },
-   { DRM_MODE_CONNECTOR_eDP, eDP, 0 },
-   { DRM_MODE_CONNECTOR_VIRTUAL, Virtual, 0},
+{  { DRM_MODE_CONNECTOR_Unknown, Unknown },
+   { DRM_MODE_CONNECTOR_VGA, VGA },
+   { DRM_MODE_CONNECTOR_DVII, DVI-I },
+   { DRM_MODE_CONNECTOR_DVID, DVI-D },
+   { DRM_MODE_CONNECTOR_DVIA, DVI-A },
+   { DRM_MODE_CONNECTOR_Composite, Composite },
+   { DRM_MODE_CONNECTOR_SVIDEO, SVIDEO },
+   { DRM_MODE_CONNECTOR_LVDS, LVDS },
+   { DRM_MODE_CONNECTOR_Component, Component },
+   { DRM_MODE_CONNECTOR_9PinDIN, DIN },
+   { DRM_MODE_CONNECTOR_DisplayPort, DP },
+   { DRM_MODE_CONNECTOR_HDMIA, HDMI-A },
+   { DRM_MODE_CONNECTOR_HDMIB, HDMI-B },
+   { DRM_MODE_CONNECTOR_TV, TV },
+   { DRM_MODE_CONNECTOR_eDP, eDP },
+   { DRM_MODE_CONNECTOR_VIRTUAL, Virtual },
 };
 
 static const struct drm_prop_enum_list drm_encoder_enum_list[] =
@@ -220,6 +220,22 @@ static const struct drm_prop_enum_list 
drm_encoder_enum_list[] =
{ DRM_MODE_ENCODER_VIRTUAL, Virtual },
 };
 
+void drm_connector_ida_init(void)
+{
+   int i;
+
+   for (i = 0; i  ARRAY_SIZE(drm_connector_enum_list); i++)
+   ida_init(drm_connector_enum_list[i].count);
+}
+
+void drm_connector_ida_destroy(void)
+{
+   int i;
+
+   for (i = 0; i  ARRAY_SIZE(drm_connector_enum_list); i++)
+   ida_destroy(drm_connector_enum_list[i].count);
+}
+
 const char *drm_get_encoder_name(const struct drm_encoder *encoder)
 {
static char buf[32];
@@ -711,6 +727,9 @@ int drm_connector_init(struct drm_device *dev,
   int connector_type)
 {
int ret;
+   struct ida *count = drm_connector_enum_list[connector_type].count;
+
+   ida_pre_get(count, GFP_KERNEL);
 
drm_modeset_lock_all(dev);
 
@@ -722,8 +741,9 @@ int drm_connector_init(struct drm_device *dev,
connector-dev = dev;
connector-funcs = funcs;
connector-connector_type = connector_type;
-   connector-connector_type_id =
-   ++drm_connector_enum_list[connector_type].count; /* TODO */
+   ret = ida_get_new_above(count, 1, connector-connector_type_id);
+   if (ret)
+   goto out;
INIT_LIST_HEAD(connector-probed_modes);
INIT_LIST_HEAD(connector-modes);
connector-edid_blob_ptr = NULL;
@@ -764,6 +784,9 @@ void drm_connector_cleanup(struct drm_connector *connector)
list_for_each_entry_safe(mode, t, connector-modes, head)
drm_mode_remove(connector, mode);
 
+   ida_remove(drm_connector_enum_list[connector-connector_type].count,
+  connector-connector_type_id);
+
drm_mode_object_put(dev, connector-base);
list_del(connector-head);
dev-mode_config.num_connector--;
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 99fcd7c..00597a1 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -251,6 +251,7 @@ static int __init drm_core_init(void)
int ret = -ENOMEM;
 
drm_global_init();
+   drm_connector_ida_init();
idr_init(drm_minors_idr);
 
if (register_chrdev(DRM_MAJOR, drm, drm_stub_fops))
@@ -298,6 +299,7 @@ static void __exit drm_core_exit(void)

[Bug 60381] AMD Radeon 7770 Ghz edition Crash with DPM active

2013-07-30 Thread bugzilla-daemon 
https://bugzilla.kernel.org/show_bug.cgi?id=60381

--- Comment #35 from Arek Ruśniak arek.r...@gmail.com ---
no pain no gain. Now everything works fast as hell.
Even UVD is fliker-free now. Thanks Alex, best regards to you and radeon team.

-- 
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 67187] Radeon HD6950: UVD not responding, trying to reset the VCPU

2013-07-30 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=67187

--- Comment #5 from Harald Judt h.j...@gmx.at ---
Created attachment 83279
  -- https://bugs.freedesktop.org/attachment.cgi?id=83279action=edit
dmesg.out

Ok, I gave it a try with new vanilla 3.11-rc3. It ends with the following error
message, though I'm not sure it isn't simply a follow-up problem caused by
previous errors:

[ 2203.028013] [drm:r600_ring_test] *ERROR* radeon: ring 0 test failed
(scratch(0x8504)=0xCAFEDEAD)

As you can deduce from the dmesg.out file attached to the bug report, the first
few tries work ok. The problem seems to be more easily reproducible (but not
restricted to that) when pm_async is enabled. I'm not yet sure it happens with
pm_async off, but by experience, the chances that it does are very likely.

What is a bit strange is that the message entering sleep state S4 never
appears in the dmesg.out. This _could_ be because I issued echo reboot 
/sys/power/disk. However, this is about hibernate/resume, as you can see when
you look at the pm messages.

I believe the main problem occurs already at suspend time, because when it
happens, suspend always takes longer than usual, hanging a bit with the monitor
turned off. However, there are no error messages to be found in the log, only
when resuming. Perhaps I should use no_suspend_console and/or net_console.

Also note how the UVD initialization fails, then the machine continues booting
and later you can hibernate again, which will restore UVD but cause the ring 0
failure with CAFEDEAD. At first, the screen is blank, then shows an animated
nostalgic noise picture similar to analog tv that has no reception. The machine
is still responsive and one can ssh in.

Is there perhaps an option to enable for more debugging messages that could
give more insight?

-- 
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 67187] Radeon HD6950: UVD not responding, trying to reset the VCPU

2013-07-30 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=67187

--- Comment #6 from Harald Judt h.j...@gmx.at ---
Note that the cayman: suspending/suspend complete and resuming/resume
complete functions are only simple printks I added to the begin and end of the
cayman_suspend/cayman_resume functions.

-- 
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: [RFC 0/2] exynos5250/hdmi: replace dummy hdmiphy clock with pmu reg control

2013-07-30 Thread Rahul Sharma 
Thanks Seung-Woo,

On Tue, Jul 30, 2013 at 11:36 AM, Seung-Woo Kim sw0312@samsung.com wrote:
 Hi Rahul,

 On 2013년 07월 30일 12:42, Rahul Sharma wrote:


 On Tue, Jun 18, 2013 at 5:07 PM, Kishon Vijay Abraham I kis...@ti.com
 mailto:kis...@ti.com wrote:

 Hi,

 On Tuesday 18 June 2013 03:33 PM, Rahul Sharma wrote:
  Thanks all,
 
  On Fri, Jun 14, 2013 at 11:39 AM, 김승우 sw0312@samsung.com
 mailto:sw0312@samsung.com wrote:
  Hello Kishon,
 
  On 2013년 06월 13일 21:54, Kishon Vijay Abraham I wrote:
  Hi,
 
  On Thursday 13 June 2013 04:51 PM, Inki Dae wrote:
 
 
  -Original Message-
  From: Sylwester Nawrocki [mailto:s.nawro...@samsung.com
 mailto:s.nawro...@samsung.com]
  Sent: Thursday, June 13, 2013 5:56 PM
  To: Rahul Sharma
  Cc: Rahul Sharma; Inki Dae; linux-samsung-...@vger.kernel.org
 mailto:linux-samsung-...@vger.kernel.org;
  devicetree-
  disc...@lists.ozlabs.org mailto:disc...@lists.ozlabs.org;
 DRI mailing list; Kukjin Kim; Seung-Woo Kim;
  Sean Paul; sunil joshi; Kishon Vijay Abraham I; Stephen Warren;
  grant.lik...@linaro.org mailto:grant.lik...@linaro.org
  Subject: Re: [RFC 0/2] exynos5250/hdmi: replace dummy hdmiphy
 clock with
  pmu reg control
 
  Hi,
 
  On 06/13/2013 06:26 AM, Rahul Sharma wrote:
  Mr. Dae,
 
  Thanks for your valuable inputs.
 
  I posted it as RFC because, I also have received comments to
 register
  hdmiphy as a clock controller. As we always configure it for
 specific
  frequency, hdmi-phy looks similar to a PLL. But it really doesn't
  belong to that class. Secondly prior to exynos5420, it was a i2c
  device. I am not sure we can register a I2C device as a clock
  controller. I wanted to discuss and explore this option here.
 
  Have you considered using the generic PHY framework for those HDMI
  PHY devices [1] ? I guess we could add a dedicated group of
 ops for
  video PHYs, similarly as is is done with struct
 v4l2_subdev_ops. For
  configuring things like the carrier/pixel clock frequency or
 anything
  what's common across the video PHYs.
 
  Perhaps you could have a look and see if this framework would be
  useful for HDMI and possibly point out anything what might be
 missing ?
 
  I'm not sure it it really solves the issues specific to the Exynos
  HDMI but at least with a generic PHY driver the PHY module
 would be
  separate from the PHY controller, as often same HDMI DPHY can
 be used
  with various types of a HDMI controller. So this would allow
 to not
  duplicate the HDMI PHY drivers in the long-term perspective.
 
  Yeah, at least, it seems that we could use PHY module to
 control PMU
  register, HDMI_PHY_CONTROL. However, PHY module provides only
 init/on/off
  callbacks. As you may know, HDMIPHY needs i2c interfaces to control
  HDMIPHY
  clock. So with PHY module, HDMIPHY driver could enable PMU more
  generically,
  but also has to use existing i2c stuff to control HDMIPHY
 clock. I had a
  quick review to Generic PHY Framework[v6] but I didn't see that
 the PHY
  module could generically support more features such as i2c stuff.
 
  I don't think PHY framework needs to provide i2c interfaces to
 program
  certain configurations. Instead in one of the callbacks
 (init/on/off)
  PHY driver can program whatever it wants using any of the
 interfaces it
  needs. IMO PHY framework should work independent of the interfaces.
 
  In exnoys hdmi case, i2c interface is not the exact issue. In exynos
  hdmi, hdmiphy should send i2c configuration about video clock
  information as the video mode information including resolution,
 bit per
  pixel, refresh rate passed from drm subsystem. So init/on/off
 callbacks
  of phy framework are not enough for exynos hdmiphy and it should
 have a
  callback to set video mode.
 
  Do you have plan to add driver specific extend callback pointers
 to phy
  framework?
 
  Currently, hdmi directly calls phy operations, but Rahul's
 another patch
  set, mentioned by Inki, divides hdmi and hdmiphy and hdmi and
 hdmiphy is
  connected with exynos hdmi own sub driver callback operations.
 
  IMHO, if phy framework can support extend callback feature, then this
  own sub driver callbacks can be replaced with phy framework at
 long term
  view.
 
  Extended callbacks are always welcome. I can also use phy device
  private data to pass on private ops like get_pixelclk and
 set_pixelclk.

 I would recommend creating a wrapper to the existing PHY framework
 for HDMI PHY. That way, we can have other HDMI phys added
 easily. We need to figure

[Bug 67530] New: Wrong UVD capabilities reported by VDPAU on Brazos

2013-07-30 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=67530

  Priority: medium
Bug ID: 67530
  Assignee: dri-devel@lists.freedesktop.org
   Summary: Wrong UVD capabilities reported by VDPAU on Brazos
  Severity: normal
Classification: Unclassified
OS: Linux (All)
  Reporter: richard.vdb...@gmail.com
  Hardware: x86-64 (AMD64)
Status: NEW
   Version: XOrg CVS
 Component: DRM/Radeon
   Product: DRI

The VDPAU collects from VDPAU drivers a certain amount of capabilities that are
supposed to allow user space program to check if the decoder is able to decode
a particular stream or not.
These parameters can be checked by the vdpauinfo tool and the begining of the
output on Nvidia hardware looks like this :

**

display: (null)   screen: 0
API version: 0
Information string: Unknown

Video surface:

name   width height types
---
420 4096  4096  NV12 YV12 
422 4096  4096  UYVY YUYV 

Decoder capabilities:

name  level ref width height

MPEG1 0  2  4096  4096
MPEG2_SIMPLE  3  2  4096  4096
MPEG2_MAIN3  2  4096  4096
H264_MAIN41  4  4096  4096
H264_HIGH41  4  4096  4096

***



Right now, the output on a Zacate / Brazos E450 system looks like this :

***

bash-4.2$ vdpauinfo 
display: :0   screen: 0
API version: 1
Information string: G3DVL VDPAU Driver Shared Library version 1.0

Video surface:

name   width height types
---
42016384 16384  NV12 
42216384 16384  NV12 
44416384 16384  NV12 

Decoder capabilities:

name   level macbs width height
---
MPEG116  9216  2048  1152
MPEG2_SIMPLE 16  9216  2048  1152
MPEG2_MAIN   16  9216  2048  1152
H264_BASELINE16  9216  2048  1152
H264_MAIN16  9216  2048  1152
H264_HIGH16  9216  2048  1152
VC1_SIMPLE   16  9216  2048  1152
VC1_MAIN 16  9216  2048  1152
VC1_ADVANCED 16  9216  2048  1152
MPEG4_PART2_SP   16  9216  2048  1152
MPEG4_PART2_ASP  16  9216  2048  1152

*

Whatever the codec, the supported level is shown to be 16 (a non-existing level
for h264 at least) and the macbs (the number of macroblocks) is always the
same.
This confuses players like VLC which adress libvdpau directly and get this
answer (16) for the supported h264 level. Players like mplayer, which do not
check this, play the video using UVD without problem.
So there is just an issue with the way VDPAU reports UVD capabilities : it
seems to just provide some kind of default.

-- 
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: Commit f5d9b7f0f9 (fix r600_enable_sclk_control()) causes kexec issues

2013-07-30 Thread Markus Trippelsdorf 
On 2013.07.29 at 15:53 -0400, Alex Deucher wrote:
 On Mon, Jul 29, 2013 at 2:10 PM, Eric W. Biederman
 ebied...@xmission.com wrote:
  Alex Deucher alexdeuc...@gmail.com writes:
 
  On Mon, Jul 29, 2013 at 11:50 AM, Eric W. Biederman
  ebied...@xmission.com wrote:
 
 
  Alex Deucher alexdeuc...@gmail.com wrote:
 On Mon, Jul 29, 2013 at 10:09 AM, Markus Trippelsdorf
 mar...@trippelsdorf.de wrote:
  On 2013.07.29 at 09:58 -0400, Alex Deucher wrote:
  On Mon, Jul 29, 2013 at 3:51 AM, Markus Trippelsdorf
  mar...@trippelsdorf.de wrote:
   On my test machine Xorg doesn't start anymore when I kexec into a
   3.11.0-rc3 kernel.
 
  With kexec, dpm doesn't get torn down properly which can result in a
  bad hardware state when the driver loads again.  Does the attached
  patch help?  It attempts to disable dpm at startup in case it wasn't
  torn down properly previously.
 
  dpm initialization now works, but unfortunately GPU acceleration
 still gets
  disabled:
 
 Stupid kexec complicates things.  We need to make sure dpm is torn
 down before we init the rest of the GPU, but dpm needs get initialized
 later in the init process since it depends on certain other state from
 the driver.  I need to think about this for a bit.  I'm not sure of a
 good way to handle this.
 
  You might just want to implement a shutdown method that cleans things up 
  properly.   At least as a first pass until you worry about things like 
  kexec on panic.
 
  Or can you not shutdown the graphics stack on reboot because of the need 
  to display the kernels shutdown progress?
 
  Does kexec actually call this shutdown method?  The driver implements
  appropriate clean-up measures if it's shutdown properly.
 
  Absoltuely.  All parts of the reboot path call -shutdown.  Including
  kexec.
 
  You don't get a device remove/hotunplug but unless this is a kexec on
  panic -shutdown is most definitely called.  Now I am talking about the
  device layer/pci layer shutdown method I don't know how gpu drivers are
  wired up.  GPU land was a little strange last I looked.  Hopefully it
  isn't so strange that there is a method named shutdown that is not wired
  up.
 
 It doesn't look like the drm infrastructure has a shutdown callback.
 The drm drivers register a drm_driver callback struct that includes an
 unload callback which takes care of all the device teardown (if you
 unload the module for example).  I don't know that it actually gets
 called at kexec time however.  I don't know enough about how kexec
 works.

BTW there is r100_restore_sanity() in drm/radeon/r100.c that explicitly
handles the kexec case during init. So maybe an r600_restore_sanity()
function is needed?

(One of the advantages of using kexec (besides the much quicker boot
time) is that the monitor is not switched off and then on during boot.
I guess that advantage would be lost if the unload callback would be
called.)

-- 
Markus
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 67530] VDPAU state tracker reports wrong codec level

2013-07-30 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=67530

Christian König deathsim...@vodafone.de changed:

   What|Removed |Added

   Severity|normal  |enhancement
Summary|Wrong UVD capabilities  |VDPAU state tracker reports
   |reported by VDPAU on Brazos |wrong codec level

--- Comment #1 from Christian König deathsim...@vodafone.de ---
Indeed, so far we have hardcoded the level in vlVdpDecoderQueryCapabilities.

Should be updated to correctly return the supported codec level.

-- 
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

  1   2   >