[Nouveau] [PATCH] drm/nouveau: Ack interrupts for some fuc engines

[Marcin Slusarz]

On Tue, Mar 26, 2013 at 07:29:24AM +0100, Maarten Lankhorst wrote:
> Op 25-03-13 19:14, Marcin Slusarz schreef:
> > On Mon, Mar 25, 2013 at 10:22:37AM +0100, Maarten Lankhorst wrote:
> >> Fixes 100% cpu usage when the exit interrupt never got acked.
> >>
> >> Signed-off-by: Maarten Lankhorst 
> >> ---
> >> diff --git a/drivers/gpu/drm/nouveau/core/core/falcon.c 
> >> b/drivers/gpu/drm/nouveau/core/core/falcon.c
> >> index e05c157..b11c5f3 100644
> >> --- a/drivers/gpu/drm/nouveau/core/core/falcon.c
> >> +++ b/drivers/gpu/drm/nouveau/core/core/falcon.c
> >> @@ -229,6 +229,24 @@ _nouveau_falcon_fini(struct nouveau_object *object, 
> >> bool suspend)
> >>return nouveau_engine_fini(>base, suspend);
> >>  }
> >>  
> >> +void
> >> +nouveau_falcon_intr(struct nouveau_subdev *subdev)
> >> +{
> >> +  struct nouveau_falcon *falcon = (void*)subdev;
> >> +  u32 intr = nv_ro32(falcon, 0x008);
> >> +
> >> +  nv_wo32(falcon, 0x004, intr);
> >> +
> >> +  if (intr & 0x10) {
> >> +  intr &= ~0x10;
> >> +
> >> +  nv_info(falcon, "Exit interrupt called\n");
> > Do you really want to print it at "info" level? How frequent it is?
> It shouldn't be often, I want it to run at the error level since that usually
> means the firmware exited prematurely/crashed and things go bad, but it
> happens with the secret scrubber finishing on initialization too. That one
> is harmless though.

Maybe it should say:
nv_error(falcon, "firmware exited prematurely\n");
?

> >> +  }
> >> +
> >> +  if (intr)
> >> +  nv_error(falcon, "Unhandled interrupt %08x\n", intr);
> >> +}
> >> +
> >>  int
> >>  nouveau_falcon_create_(struct nouveau_object *parent,
> >>   struct nouveau_object *engine,
> > ___
> > dri-devel mailing list
> > dri-devel at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/dri-devel
> >
> 

[PATCH] drm: fix i_mapping and f_mapping initialization in drm_open in error path

[Michal Hocko]

Hi,
the patch bellow fixes a nullptr dereference reported with OpenSUSE12.3.
I am not familiar with the area so I have no idea whether this is the
right way to go but after applying this patch the problem is not
reproducible anymore.
If the patch is correct then please mark it for stable (3.7+).

Thanks!
---

[PATCH v2 8/8] OMAPDSS: DISPC: Revert to older DISPC Smart Standby mechanism for OMAP5

[Archit Taneja]

DISPC on OMAP5 has a more optimised mechanism of asserting Mstandby to achieve
more power savings when DISPC is configured in Smart Standby mode. This
mechanism leads to underflows when multiple DISPC pipes are enabled.

There is a register field which can let us revert to the older mechanism of
asserting Mstandby. Configure this field to prevent underflows.

Signed-off-by: Archit Taneja 
---
 drivers/video/omap2/dss/dispc.c |7 +++
 drivers/video/omap2/dss/dispc.h |1 +
 2 files changed, 8 insertions(+)

diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index ddbf031..b33b016 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -87,6 +87,9 @@ struct dispc_features {

/* no DISPC_IRQ_FRAMEDONETV on this SoC */
bool no_framedone_tv:1;
+
+   /* revert to the OMAP4 mechanism of DISPC Smart Standby operation */
+   bool mstandby_workaround:1;
 };

 #define DISPC_MAX_NR_FIFOS 5
@@ -3502,6 +3505,9 @@ static void _omap_dispc_initial_config(void)
dispc_configure_burst_sizes();

dispc_ovl_enable_zorder_planes();
+
+   if (dispc.feat->mstandby_workaround)
+   REG_FLD_MOD(DISPC_MSTANDBY_CTRL, 1, 0, 0);
 }

 static const struct dispc_features omap24xx_dispc_feats __initconst = {
@@ -3596,6 +3602,7 @@ static const struct dispc_features omap54xx_dispc_feats 
__initconst = {
.calc_core_clk  =   calc_core_clk_44xx,
.num_fifos  =   5,
.gfx_fifo_workaround=   true,
+   .mstandby_workaround=   true,
 };

 static int __init dispc_init_features(struct platform_device *pdev)
diff --git a/drivers/video/omap2/dss/dispc.h b/drivers/video/omap2/dss/dispc.h
index 222363c..de4863d 100644
--- a/drivers/video/omap2/dss/dispc.h
+++ b/drivers/video/omap2/dss/dispc.h
@@ -39,6 +39,7 @@
 #define DISPC_GLOBAL_BUFFER0x0800
 #define DISPC_CONTROL3  0x0848
 #define DISPC_CONFIG3   0x084C
+#define DISPC_MSTANDBY_CTRL0x0858

 /* DISPC overlay registers */
 #define DISPC_OVL_BA0(n)   (DISPC_OVL_BASE(n) + \
-- 
1.7.10.4

[PATCH v2 7/8] OMAPDSS: DISPC: Configure doublestride for NV12 when using 2D Tiler buffers

[Archit Taneja]

When using a DISPC video pipeline to a fetch a NV12 buffer in a 2D container, we
need to set set a doublestride bit in the video pipe's ATTRIBUTES register. This
is needed because the stride for the UV plane(using a 16 bit Tiler container) is
double the stride for the Y plane(using a 8 bit Tiler container) for the 0 or
180 degree views. The ROW_INC register is meant for the Y plane, and the HW will
calculate the row increment needed for the UV plane by using double the stride
value based on whether this bit is set or not.

Set the bit when we are using a 2D Tiler buffer and when rotation is 0 or 180
degrees. The stride value is the same for 90 and 270 degree Tiler views, hence
the bit shouldn't be set.

Signed-off-by: Archit Taneja 
---
 drivers/video/omap2/dss/dispc.c |   13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index 73a730a..ddbf031 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -1588,6 +1588,7 @@ static void dispc_ovl_set_scaling(enum omap_plane plane,
 }

 static void dispc_ovl_set_rotation_attrs(enum omap_plane plane, u8 rotation,
+   enum omap_dss_rotation_type rotation_type,
bool mirroring, enum omap_color_mode color_mode)
 {
bool row_repeat = false;
@@ -1638,6 +1639,15 @@ static void dispc_ovl_set_rotation_attrs(enum omap_plane 
plane, u8 rotation,
if (dss_has_feature(FEAT_ROWREPEATENABLE))
REG_FLD_MOD(DISPC_OVL_ATTRIBUTES(plane),
row_repeat ? 1 : 0, 18, 18);
+
+   if (color_mode == OMAP_DSS_COLOR_NV12) {
+   bool doublestride = (rotation_type == OMAP_DSS_ROT_TILER) &&
+   (rotation == OMAP_DSS_ROT_0 ||
+   rotation == OMAP_DSS_ROT_180);
+   /* DOUBLESTRIDE */
+   REG_FLD_MOD(DISPC_OVL_ATTRIBUTES(plane), doublestride, 22, 22);
+   }
+
 }

 static int color_mode_to_bpp(enum omap_color_mode color_mode)
@@ -2516,7 +2526,8 @@ static int dispc_ovl_setup_common(enum omap_plane plane,
dispc_ovl_set_vid_color_conv(plane, cconv);
}

-   dispc_ovl_set_rotation_attrs(plane, rotation, mirror, color_mode);
+   dispc_ovl_set_rotation_attrs(plane, rotation, rotation_type, mirror,
+   color_mode);

dispc_ovl_set_zorder(plane, caps, zorder);
dispc_ovl_set_pre_mult_alpha(plane, caps, pre_mult_alpha);
-- 
1.7.10.4

[PATCH v2 6/8] omapdss: Features: Fix some parameter ranges

[Archit Taneja]

Increase the DSS_FCLK and DSI_FCLK max supported frequencies, these come because
some frequencies were increased from OMAP5 ES1 to OMAP5 ES2. We support only
OMAP5 ES2 in the kernel, so replace the ES1 values with ES2 values. Increase the
DSI PLL Fint range, this was previously just copied from the OMAP4 param range
struct.

Fix the maximum DSS_FCLK on OMAP2, it's 133 Mhz according to the TRM.

Signed-off-by: Archit Taneja 
---
 drivers/video/omap2/dss/dss_features.c |8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/video/omap2/dss/dss_features.c 
b/drivers/video/omap2/dss/dss_features.c
index 7f791ae..77dbe0c 100644
--- a/drivers/video/omap2/dss/dss_features.c
+++ b/drivers/video/omap2/dss/dss_features.c
@@ -414,7 +414,7 @@ static const char * const omap5_dss_clk_source_names[] = {
 };

 static const struct dss_param_range omap2_dss_param_range[] = {
-   [FEAT_PARAM_DSS_FCK]= { 0, 17300 },
+   [FEAT_PARAM_DSS_FCK]= { 0, 13300 },
[FEAT_PARAM_DSS_PCD]= { 2, 255 },
[FEAT_PARAM_DSIPLL_REGN]= { 0, 0 },
[FEAT_PARAM_DSIPLL_REGM]= { 0, 0 },
@@ -459,15 +459,15 @@ static const struct dss_param_range 
omap4_dss_param_range[] = {
 };

 static const struct dss_param_range omap5_dss_param_range[] = {
-   [FEAT_PARAM_DSS_FCK]= { 0, 2 },
+   [FEAT_PARAM_DSS_FCK]= { 0, 20925 },
[FEAT_PARAM_DSS_PCD]= { 1, 255 },
[FEAT_PARAM_DSIPLL_REGN]= { 0, (1 << 8) - 1 },
[FEAT_PARAM_DSIPLL_REGM]= { 0, (1 << 12) - 1 },
[FEAT_PARAM_DSIPLL_REGM_DISPC]  = { 0, (1 << 5) - 1 },
[FEAT_PARAM_DSIPLL_REGM_DSI]= { 0, (1 << 5) - 1 },
-   [FEAT_PARAM_DSIPLL_FINT]= { 50, 250 },
+   [FEAT_PARAM_DSIPLL_FINT]= { 15, 5200 },
[FEAT_PARAM_DSIPLL_LPDIV]   = { 0, (1 << 13) - 1 },
-   [FEAT_PARAM_DSI_FCK]= { 0, 17000 },
+   [FEAT_PARAM_DSI_FCK]= { 0, 20925 },
[FEAT_PARAM_DOWNSCALE]  = { 1, 4 },
[FEAT_PARAM_LINEWIDTH]  = { 1, 2048 },
 };
-- 
1.7.10.4

[PATCH v2 5/8] omapdss: DISPC: add max pixel clock limits for LCD and TV managers

[Archit Taneja]

Each version of OMAP has a limitation on the maximum pixel clock frequency
supported by an overlay manager. This limit isn't checked by omapdss. Add
dispc feats for lcd and tv managers and check whether the target timings can
be supported or not.

The pixel clock limitations are actually more complex. They depend on which OPP
OMAP is in, and they also depend on which encoder is the manager connected to.
The OPP dependence is ignored as DSS forces the PM framework to be on OPP100
when DSS is enabled, and the encoder dependencies are ignored by DISPC for now.
These limits should come from the encoder driver.

The OMAP2 TRM doesn't mention the maximum pixel clock limit. This value is left
as half of DSS_FCLK, as OMAP2 requires the PCD to be atleast 2.

Signed-off-by: Archit Taneja 
---
 drivers/video/omap2/dss/dispc.c |   32 +++-
 1 file changed, 27 insertions(+), 5 deletions(-)

diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index 8cfa27b..73a730a 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -69,6 +69,8 @@ struct dispc_features {
u8 mgr_height_start;
u16 mgr_width_max;
u16 mgr_height_max;
+   unsigned long max_lcd_pclk;
+   unsigned long max_tv_pclk;
int (*calc_scaling) (unsigned long pclk, unsigned long lclk,
const struct omap_video_timings *mgr_timings,
u16 width, u16 height, u16 out_width, u16 out_height,
@@ -2825,6 +2827,15 @@ static bool _dispc_lcd_timings_ok(int hsw, int hfp, int 
hbp,
return true;
 }

+static bool _dispc_mgr_pclk_ok(enum omap_channel channel,
+   unsigned long pclk)
+{
+   if (dss_mgr_is_lcd(channel))
+   return pclk <= dispc.feat->max_lcd_pclk ? true : false;
+   else
+   return pclk <= dispc.feat->max_tv_pclk ? true : false;
+}
+
 bool dispc_mgr_timings_ok(enum omap_channel channel,
const struct omap_video_timings *timings)
 {
@@ -2832,11 +2843,13 @@ bool dispc_mgr_timings_ok(enum omap_channel channel,

timings_ok = _dispc_mgr_size_ok(timings->x_res, timings->y_res);

-   if (dss_mgr_is_lcd(channel))
-   timings_ok =  timings_ok && _dispc_lcd_timings_ok(timings->hsw,
-   timings->hfp, timings->hbp,
-   timings->vsw, timings->vfp,
-   timings->vbp);
+   timings_ok &= _dispc_mgr_pclk_ok(channel, timings->pixel_clock * 1000);
+
+   if (dss_mgr_is_lcd(channel)) {
+   timings_ok &= _dispc_lcd_timings_ok(timings->hsw, timings->hfp,
+   timings->hbp, timings->vsw, timings->vfp,
+   timings->vbp);
+   }

return timings_ok;
 }
@@ -3491,6 +3504,7 @@ static const struct dispc_features omap24xx_dispc_feats 
__initconst = {
.mgr_height_start   =   26,
.mgr_width_max  =   2048,
.mgr_height_max =   2048,
+   .max_lcd_pclk   =   6650,
.calc_scaling   =   dispc_ovl_calc_scaling_24xx,
.calc_core_clk  =   calc_core_clk_24xx,
.num_fifos  =   3,
@@ -3508,6 +3522,8 @@ static const struct dispc_features 
omap34xx_rev1_0_dispc_feats __initconst = {
.mgr_height_start   =   26,
.mgr_width_max  =   2048,
.mgr_height_max =   2048,
+   .max_lcd_pclk   =   17300,
+   .max_tv_pclk=   5900,
.calc_scaling   =   dispc_ovl_calc_scaling_34xx,
.calc_core_clk  =   calc_core_clk_34xx,
.num_fifos  =   3,
@@ -3525,6 +3541,8 @@ static const struct dispc_features 
omap34xx_rev3_0_dispc_feats __initconst = {
.mgr_height_start   =   26,
.mgr_width_max  =   2048,
.mgr_height_max =   2048,
+   .max_lcd_pclk   =   17300,
+   .max_tv_pclk=   5900,
.calc_scaling   =   dispc_ovl_calc_scaling_34xx,
.calc_core_clk  =   calc_core_clk_34xx,
.num_fifos  =   3,
@@ -3542,6 +3560,8 @@ static const struct dispc_features omap44xx_dispc_feats 
__initconst = {
.mgr_height_start   =   26,
.mgr_width_max  =   2048,
.mgr_height_max =   2048,
+   .max_lcd_pclk   =   17000,
+   .max_tv_pclk=   185625000,
.calc_scaling   =   dispc_ovl_calc_scaling_44xx,
.calc_core_clk  =   calc_core_clk_44xx,
.num_fifos  =   5,
@@ -3559,6 +3579,8 @@ static const struct dispc_features omap54xx_dispc_feats 
__initconst = {
.mgr_height_start   =   27,

[PATCH v2 4/8] omapdss: features: fixed supported outputs for OMAP4

[Archit Taneja]

The support outputs struct for overlay managers is incorrect for OMAP4. Make
these changes:

- DPI isn't supported via the LCD1 overlay manager, remove DPI as a supported
  output.
- the TV manager can suppport DPI, but the omapdss driver doesn't support that
  yet, we require some muxing at the DSS level, and we also need to configure
  the hdmi pll in the DPI driver so that the TV manager has a pixel clock. We
  don't support that yet.

Signed-off-by: Archit Taneja 
---
 drivers/video/omap2/dss/dss_features.c |6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/video/omap2/dss/dss_features.c 
b/drivers/video/omap2/dss/dss_features.c
index d7d66ef..7f791ae 100644
--- a/drivers/video/omap2/dss/dss_features.c
+++ b/drivers/video/omap2/dss/dss_features.c
@@ -202,12 +202,10 @@ static const enum omap_dss_output_id 
omap3630_dss_supported_outputs[] = {

 static const enum omap_dss_output_id omap4_dss_supported_outputs[] = {
/* OMAP_DSS_CHANNEL_LCD */
-   OMAP_DSS_OUTPUT_DPI | OMAP_DSS_OUTPUT_DBI |
-   OMAP_DSS_OUTPUT_DSI1,
+   OMAP_DSS_OUTPUT_DBI | OMAP_DSS_OUTPUT_DSI1,

/* OMAP_DSS_CHANNEL_DIGIT */
-   OMAP_DSS_OUTPUT_VENC | OMAP_DSS_OUTPUT_HDMI |
-   OMAP_DSS_OUTPUT_DPI,
+   OMAP_DSS_OUTPUT_VENC | OMAP_DSS_OUTPUT_HDMI,

/* OMAP_DSS_CHANNEL_LCD2 */
OMAP_DSS_OUTPUT_DPI | OMAP_DSS_OUTPUT_DBI |
-- 
1.7.10.4

[PATCH v3 3/8] drm/omap: Make fixed resolution panels work

[Archit Taneja]

The omapdrm driver requires omapdss panel drivers to expose ops like detect,
set_timings and check_timings. These can be NULL for fixed panel DPI, DBI, DSI
and SDI drivers. At some places, there are no checks to see if the panel driver
has these ops or not, and that leads to a crash.

The following things are done to make fixed panels work:

- The omap_connector's detect function is modified such that it considers panel
  types which are generally fixed panels as always connected(provided the panel
  driver doesn't have a detect op). Hence, the connector corresponding to these
  panels is always in a 'connected' state.

- If a panel driver doesn't have a check_timings op, assume that it supports the
  mode passed to omap_connector_mode_valid(the 'mode_valid' drm helper function)

- The function omap_encoder_update shouldn't really do anything for fixed
  resolution panels, make sure that it calls set_timings only if the panel
  driver has one.

Signed-off-by: Archit Taneja 
---
v3: clear the timings local variable first before using memcmp
v2: make sure the timings we try to set for a fixed resolution panel match the
panel's timings

 drivers/gpu/drm/omapdrm/omap_connector.c |   27 +--
 drivers/gpu/drm/omapdrm/omap_encoder.c   |   17 +++--
 2 files changed, 40 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_connector.c 
b/drivers/gpu/drm/omapdrm/omap_connector.c
index c451c41..912759d 100644
--- a/drivers/gpu/drm/omapdrm/omap_connector.c
+++ b/drivers/gpu/drm/omapdrm/omap_connector.c
@@ -110,6 +110,11 @@ static enum drm_connector_status omap_connector_detect(
ret = connector_status_connected;
else
ret = connector_status_disconnected;
+   } else if (dssdev->type == OMAP_DISPLAY_TYPE_DPI ||
+   dssdev->type == OMAP_DISPLAY_TYPE_DBI ||
+   dssdev->type == OMAP_DISPLAY_TYPE_SDI ||
+   dssdev->type == OMAP_DISPLAY_TYPE_DSI) {
+   ret = connector_status_connected;
} else {
ret = connector_status_unknown;
}
@@ -189,12 +194,30 @@ static int omap_connector_mode_valid(struct drm_connector 
*connector,
struct omap_video_timings timings = {0};
struct drm_device *dev = connector->dev;
struct drm_display_mode *new_mode;
-   int ret = MODE_BAD;
+   int r, ret = MODE_BAD;

copy_timings_drm_to_omap(, mode);
mode->vrefresh = drm_mode_vrefresh(mode);

-   if (!dssdrv->check_timings(dssdev, )) {
+   /*
+* if the panel driver doesn't have a check_timings, it's most likely
+* a fixed resolution panel, check if the timings match with the
+* panel's timings
+*/
+   if (dssdrv->check_timings) {
+   r = dssdrv->check_timings(dssdev, );
+   } else {
+   struct omap_video_timings t = {0};
+
+   dssdrv->get_timings(dssdev, );
+
+   if (memcmp(, , sizeof(struct omap_video_timings)))
+   r = -EINVAL;
+   else
+   r = 0;
+   }
+
+   if (!r) {
/* check if vrefresh is still valid */
new_mode = drm_mode_duplicate(dev, mode);
new_mode->clock = timings.pixel_clock;
diff --git a/drivers/gpu/drm/omapdrm/omap_encoder.c 
b/drivers/gpu/drm/omapdrm/omap_encoder.c
index d48df71..c29451b 100644
--- a/drivers/gpu/drm/omapdrm/omap_encoder.c
+++ b/drivers/gpu/drm/omapdrm/omap_encoder.c
@@ -135,13 +135,26 @@ int omap_encoder_update(struct drm_encoder *encoder,

dssdev->output->manager = mgr;

-   ret = dssdrv->check_timings(dssdev, timings);
+   if (dssdrv->check_timings) {
+   ret = dssdrv->check_timings(dssdev, timings);
+   } else {
+   struct omap_video_timings t = {0};
+
+   dssdrv->get_timings(dssdev, );
+
+   if (memcmp(timings, , sizeof(struct omap_video_timings)))
+   ret = -EINVAL;
+   else
+   ret = 0;
+   }
+
if (ret) {
dev_err(dev->dev, "could not set timings: %d\n", ret);
return ret;
}

-   dssdrv->set_timings(dssdev, timings);
+   if (dssdrv->set_timings)
+   dssdrv->set_timings(dssdev, timings);

return 0;
 }
-- 
1.7.10.4

[PATCH v2 2/8] drm/omap: Fix and improve crtc and overlay manager correlation

[Archit Taneja]

The omapdrm driver currently takes a config/module arg to figure out the number
of crtcs it needs to create. We could create as many crtcs as there are overlay
managers in the DSS hardware, but we don't do that because each crtc eats up
one DSS overlay, and that reduces the number of planes we can attach to a single
crtc.

Since the number of crtcs may be lesser than the number of hardware overlay
managers, we need to figure out which overlay managers to use for our crtcs. The
current approach is to use pipe2chan(), which returns a higher numbered manager
for the crtc.

The problem with this approach is that it assumes that the overlay managers we
choose will connect to the encoders the platform's panels are going to use,
this isn't true, an overlay manager connects only to a few outputs/encoders, and
choosing any overlay manager for our crtc might lead to a situation where the
encoder cannot connect to any of the crtcs we have chosen. For example, an
omap5-panda board has just one hdmi output. If num_crtc is set to 1, with the
current approach, pipe2chan will pick up the LCD2 overlay manager, which cannot
connect to the hdmi encoder at all. The only manager that could have connected
to hdmi was the TV overlay manager.

Therefore, there is a need to choose our overlay managers keeping in mind the
panels we have on that platform. The new approach iterates through all the
available panels, creates encoders and connectors for them, and then tries to
get a suitable overlay manager to create a crtc which can connect to the
encoders.

We use the dispc_channel field in omap_dss_output to retrieve the desired
overlay manager's channel number, we then check whether the manager had already
been assigned to a crtc or not. If it was already assigned to a crtc, we assume
that out of all the encoders which intend use this crtc, only one will run at a
time. If the overlay manager wan't assigned to a crtc till then, we create a
new crtc and link it with the overlay manager.

This approach just looks for the best dispc_channel for each encoder. On DSS HW,
some encoders can connect to multiple overlay managers. Since we don't try
looking for alternate overlay managers, there is a greater possibility that 2
or more encoders end up asking for the same crtc, causing only one encoder to
run at a time.

Also, this approach isn't the most optimal one, it can do either good or bad
depending on the sequence in which the panels/outputs are parsed. The optimal
way would be some sort of back tracking approach, where we improve the set of
managers we use as we iterate through the list of panels/encoders. That's
something left for later.

Signed-off-by: Archit Taneja 
---
 drivers/gpu/drm/omapdrm/omap_crtc.c|   21 +++--
 drivers/gpu/drm/omapdrm/omap_drv.c |  157 ++--
 drivers/gpu/drm/omapdrm/omap_drv.h |   38 +---
 drivers/gpu/drm/omapdrm/omap_encoder.c |7 ++
 drivers/gpu/drm/omapdrm/omap_irq.c |   17 ++--
 5 files changed, 165 insertions(+), 75 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c 
b/drivers/gpu/drm/omapdrm/omap_crtc.c
index bec66a4..79b200a 100644
--- a/drivers/gpu/drm/omapdrm/omap_crtc.c
+++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
@@ -74,6 +74,13 @@ struct omap_crtc {
struct work_struct page_flip_work;
 };

+uint32_t pipe2vbl(struct drm_crtc *crtc)
+{
+   struct omap_crtc *omap_crtc = to_omap_crtc(crtc);
+
+   return dispc_mgr_get_vsync_irq(omap_crtc->channel);
+}
+
 /*
  * Manager-ops, callbacks from output when they need to configure
  * the upstream part of the video pipe.
@@ -613,7 +620,13 @@ struct drm_crtc *omap_crtc_init(struct drm_device *dev,
omap_crtc->apply.pre_apply  = omap_crtc_pre_apply;
omap_crtc->apply.post_apply = omap_crtc_post_apply;

-   omap_crtc->apply_irq.irqmask = pipe2vbl(id);
+   omap_crtc->channel = channel;
+   omap_crtc->plane = plane;
+   omap_crtc->plane->crtc = crtc;
+   omap_crtc->name = channel_names[channel];
+   omap_crtc->pipe = id;
+
+   omap_crtc->apply_irq.irqmask = pipe2vbl(crtc);
omap_crtc->apply_irq.irq = omap_crtc_apply_irq;

omap_crtc->error_irq.irqmask =
@@ -621,12 +634,6 @@ struct drm_crtc *omap_crtc_init(struct drm_device *dev,
omap_crtc->error_irq.irq = omap_crtc_error_irq;
omap_irq_register(dev, _crtc->error_irq);

-   omap_crtc->channel = channel;
-   omap_crtc->plane = plane;
-   omap_crtc->plane->crtc = crtc;
-   omap_crtc->name = channel_names[channel];
-   omap_crtc->pipe = id;
-
/* temporary: */
omap_crtc->mgr.id = channel;

diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c 
b/drivers/gpu/drm/omapdrm/omap_drv.c
index 77b7225..cbaa003 100644
--- a/drivers/gpu/drm/omapdrm/omap_drv.c
+++ b/drivers/gpu/drm/omapdrm/omap_drv.c
@@ -74,49 +74,48 @@ static int get_connector_type(struct omap_dss_device 
*dssdev)
}
 }

+static bool channel_used(struct drm_device *dev, enum 

[PATCH v2 1/8] drm/omap: Don't return from modeset_init if a panel doesn't satisfy omapdrm requirements

[Archit Taneja]

modeset_init iterates through all the registered omapdss devices and has some
initial checks to see if the panel has a driver and the required driver ops for
it to be usable by omapdrm.

The function bails out from modeset_init if a panel doesn't meet the
requirements, and stops the registration of the future panels and encoders which
come after it, that isn't the correct thing to do, we should go through the rest
of the panels. Replace the 'return's with 'continue's.

Reviewed-by: Rob Clark 
Signed-off-by: Archit Taneja 
---
 drivers/gpu/drm/omapdrm/omap_drv.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c 
b/drivers/gpu/drm/omapdrm/omap_drv.c
index 079c54c..77b7225 100644
--- a/drivers/gpu/drm/omapdrm/omap_drv.c
+++ b/drivers/gpu/drm/omapdrm/omap_drv.c
@@ -121,7 +121,7 @@ static int omap_modeset_init(struct drm_device *dev)
if (!dssdev->driver) {
dev_warn(dev->dev, "%s has no driver.. skipping it\n",
dssdev->name);
-   return 0;
+   continue;
}

if (!(dssdev->driver->get_timings ||
@@ -129,7 +129,7 @@ static int omap_modeset_init(struct drm_device *dev)
dev_warn(dev->dev, "%s driver does not support "
"get_timings or read_edid.. skipping it!\n",
dssdev->name);
-   return 0;
+   continue;
}

encoder = omap_encoder_init(dev, dssdev);
-- 
1.7.10.4

[PATCH v2 0/8] omapdss/omapdrm: Misc fixes and improvements

[Archit Taneja]

These are misc fixes and improvements within omapdrm and omapdss. The fixes do 
the
following:

- Make omapdrm smarter to choose the right overlay managers as it's crtcs. This
  makes sure that omapdrm is functional for OMAP platforms with different
  combinations of panels connected to it.

- Fix certain areas in omapdrm which allow fixed resolution panels to work.

- Fix functional and pixel clock limits for DISPC, this ensures we don't try
  to try a mode that the hardware can't support.

- Some changes that came in OMAP5 ES2 silicon.

Note: The branch is based on the DSS misc series and dsi video mode calc series
posted by Tomi. Reference branch:

git://gitorious.org/~boddob/linux-omap-dss2/archit-dss2-clone.git 
for-3.10/misc_drm_dss

Archit Taneja (8):
  drm/omap: Don't return from modeset_init if a panel doesn't satisfy
omapdrm requirements
  drm/omap: Fix and improve crtc and overlay manager correlation
  drm/omap: Make fixed resolution panels work
  omapdss: features: fixed supported outputs for OMAP4
  omapdss: DISPC: add max pixel clock limits for LCD and TV managers
  omapdss: Features: Fix some parameter ranges
  OMAPDSS: DISPC: Configure doublestride for NV12 when using 2D Tiler
buffers
  OMAPDSS: DISPC: Revert to older DISPC Smart Standby mechanism for
OMAP5

 drivers/gpu/drm/omapdrm/omap_connector.c |   27 -
 drivers/gpu/drm/omapdrm/omap_crtc.c  |   21 ++--
 drivers/gpu/drm/omapdrm/omap_drv.c   |  161 --
 drivers/gpu/drm/omapdrm/omap_drv.h   |   38 +--
 drivers/gpu/drm/omapdrm/omap_encoder.c   |   24 -
 drivers/gpu/drm/omapdrm/omap_irq.c   |   17 ++--
 drivers/video/omap2/dss/dispc.c  |   52 --
 drivers/video/omap2/dss/dispc.h  |1 +
 drivers/video/omap2/dss/dss_features.c   |   14 ++-
 9 files changed, 260 insertions(+), 95 deletions(-)

-- 
1.7.10.4

[PATCH] drm: fix i_mapping and f_mapping initialization in drm_open in error path

[Michal Hocko]

Starting with fdb40a08 (drm: set dev_mapping before calling
drm_open_helper) inode and file mappings are set to old_mapping in the
error path. old_mapping can be NULL, however, which is handled by
initializing dev_mapping to default inode->i_data. old_mapping is left
intact though so the both inode's and filep's mapping will still point
to NULL which is unexpected and can it results in crashes later one.

Marco Munderloh has reported such crashes:
 BUG: unable to handle kernel NULL pointer dereference at 0058
 IP: [] drop_pagecache_sb+0x74/0xe0
 PGD 252bc1067 PUD 253d11067 PMD 0
 Oops:  [#1] SMP
 Modules linked in: fuse af_packet xt_tcpudp xt_pkttype xt_LOG xt_limit bnep 
bluetooth ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6
ip6table_raw ipt_REJECT iptable_raw xt_CT iptable_filter ip6table_mangle 
nf_conntrack_netbios_ns nf_conntrack_broadcast nf_conntrack_ipv4 nf_defrag_ipv4 
ip_tables xt_conntrack nf_conntrack ip6table_filter ip6_tables x_tables 
cpufreq_conservative cpufreq_userspace cpufreq_powersave acpi_cpufreq 
snd_hda_codec_hdmi mperf coretemp snd_hda_codec_realtek snd_hda_intel 
snd_hda_codec snd_hwdep kvm_intel snd_pcm arc4 snd_seq snd_timer snd_seq_device 
kvm iwldvm mac80211 snd uvcvideo crc32c_intel videobuf2_core videodev 
ghash_clmulni_intel aesni_intel ablk_helper cryptd lrw videobuf2_vmalloc 
aes_x86_64 iTCO_wdt xts tpm_infineon mei r8169 videobuf2_memops 
iTCO_vendor_support sr_mod lpc_ich iwlwifi gf128mul sony_laptop rts_pstor(C) 
cdrom i2c_i801 tpm_tis tpm tpm_bios battery mfd_core soundcore snd_page_alloc 
cfg80211 rfkill ac sg microcode pcspkr autofs4 xhci_hcd ehci_hcd usbcore 
usb_common radeon i915 video ttm drm_kms_helper drm i2c_algo_bit thermal button 
processor thermal_sys scsi_dh_emc scsi_dh_rdac scsi_dh_hp_sw scsi_dh_alua
scsi_dh
 CPU 0
 Pid: 1452, comm: bash Tainted: G C   3.7.10-1.1-default
ation VPCSA4W9E/VAIO
 RIP: 0010:[]  [] 
drop_pagecache_sb+0x74/0xe0
 RSP: 0018:880252bc9e18  EFLAGS: 00010246
 RAX:  RBX: 88024ecb7db0 RCX: 0002
 RDX: 0007 RSI: 88024f63a670 RDI: 88024ecb7e38
 RBP: 88024ecb7e38 R08: dead00200200 R09: 
 R10: 0001 R11: 0210 R12: 880254d588a0
 R13: 88024fcb25e8 R14: 81190b70 R15: ffea
 FS:  7fad2b9ed700() GS:88025fa0() knlGS:
 CS:  0010 DS:  ES:  CR0: 80050033
 CR2: 0058 CR3: 000252ad2000 CR4: 000407f0
 DR0:  DR1:  DR2: 
 DR3:  DR6: 0ff0 DR7: 0400
 Process bash (pid: 1452, threadinfo 880252bc8000, task 880253d321c0)
 Stack:
  0001 880254d58800 880254e94800 880254d58868
   8116a499  0001
  81a228a0 880252bc9f50 0002 81190cce
 Call Trace:
  [] iterate_supers+0xd9/0xe0
  [] drop_caches_sysctl_handler+0x7e/0x90
  [] proc_sys_call_handler.isra.10+0xc6/0xe0
  [] vfs_write+0xa7/0x180
  [] sys_write+0x51/0xa0
  [] system_call_fastpath+0x1a/0x1f
  [<7fad2ae959c0>] 0x7fad2ae959bf
 Code: 01 00 00 49 39 c4 48 8d 98 00 ff ff ff 74 68 48 8d ab 88 00 00 00 48 89 
ef e8 49 69 3b 00 f6 83 a0 00 00 00 38 75 d0 48 8b 43 30 <48> 83 78 58 00 74 c5 
48 89 df e8 dd ef fe ff 66 83 45 00 01 66
 RIP  [] drop_pagecache_sb+0x74/0xe0
  RSP 
 CR2: 0058

when dropping caches when inode with NULL i_mapping is encountered. Or a
different one when umounting devtmpfs:
 BUG: unable to handle kernel NULL pointer dereference at 0068
 IP: [] shmem_evict_inode+0x11/0x130
 PGD 0
 Oops:  [#1] SMP
 Modules linked in: xt_tcpudp xt_pkttype xt_LOG xt_limit af_packet ip6t_REJECT 
nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_raw ipt_REJECT iptable_raw xt_CT 
iptable_filter ip6table_mangle nf_conntrack_netbios_ns nf_conntrack_broadcast 
nf_conntrack_ipv4 nf_defrag_ipv4 ip_tables xt_conntrack nf_conntrack bnep 
bluetooth ip6table_filter ip6_tables cpufreq_conservative x_tables 
cpufreq_userspace cpufreq_powersave snd_hda_codec_hdmi snd_hda_codec_realtek 
acpi_cpufreq snd_hda_intel mperf snd_hda_codec coretemp snd_hwdep kvm_intel 
snd_pcm kvm arc4 snd_seq iwldvm mac80211 crc32c_intel ghash_clmulni_intel 
snd_timer aesni_intel snd_seq_device iTCO_wdt uvcvideo videobuf2_core iwlwifi 
videodev sony_laptop videobuf2_vmalloc videobuf2_memops ablk_helper 
iTCO_vendor_support cryptd cfg80211 tpm_infineon r8169 sr_mod cdrom mei snd 
lpc_ich battery lrw aes_x86_64 xts rfkill i2c_i801 pcspkr mfd_core tpm_tis ac 
gf128mul tpm tpm_bios soundcore snd_page_alloc sg microcode autofs4 xhci_hcd 
ehci_hcd radeon(-) i915 ttm drm_kms_helper usbcore usb_common drm thermal 
i2c_algo_bit video button processor thermal_sys scsi_dh_emc scsi_dh_rdac 
scsi_dh_hp_sw scsi_dh_alua scsi_dh
 CPU 1 <4>[   44.175256] Pid: 29, comm: kdevtmpfs Tainted: GW

[PATCH 0/1] drm/i915: Allow specifying a minimum brightness level for sysfs control.

[Danny Baumann]

Hi,

Am 26.03.2013 18:02, schrieb Matthew Garrett:
> On Tue, Mar 26, 2013 at 12:48:44PM +0100, Danny Baumann wrote:
>> This patch makes the behaviour of the intel_backlight backlight device
>> consistent to e.g. acpi_videoX: When writing the value 0, the set brightness
>> makes the panel content barely readable instead of turning the backlight off.
>> This matches the expectations of user space (e.g. kde-workspace or the Intel
>> X11 driver), which expects that it can use intel_backlight as a drop-in
>> replacement for acpi_videoX.
>
> I'm not quite clear what you mean here. The behaviour of "0" isn't well
> defined for the ACPI backlight driver - it's perfectly reasonable for it
> to turn the backlight off entirely. Anything assuming that "0" is still
> visible is broken.

Well, the ACPI spec says this (section B.5.2):

"
The OEM may define the number 0 as "Zero brightness" that can mean to 
turn off the lighting (e.g. LCD panel backlight) in the device. This may 
be useful in the case of an output device that can still be viewed using 
only ambient light, for example, a transflective LCD.
"

My interpretation of this is that the value 0 is supposed to still be 
visible. I'm pretty sure I saw a statement that 0 is supposed to mean 
"barely visible" somewhere, but can't find it at the moment. I'll search 
for the source of it.

Regards,

Danny

[PATCH 1/1] drm/i915: Allow specifying a minimum brightness level for sysfs control.

[Danny Baumann]

Hi,

>> Thus far our assumption always was that the acpi backlight works better
>> than the intel native backlight. So everything only uses the intel
>> backlight if there's no other backlight driver by default.
>
> There are machines, such as the pnv netbook on my desk, on which
> intel_backlight does nothing and the only control is through
> acpi_backlight0.

That's fine - but on my machine, (at least currently) it's the other way 
around. acpi_video[0|1] do nothing, while intel_backlight is the only 
method that works. This sucks (please also see my reply to Daniel), but 
it's a fact.

> Generalising expected behaviour based on one firmware
> implementation is fraught with danger.

I'm not sure what you mean here. I interpret the statement as 'user 
space should treat acpi_videoX and intel_backlight differently'. Is this 
interpretation correct?
If so, how is user space supposed to know how the respective backlight 
device will behave, as this behaviour might change at any point in time 
if there's no understanding in how it _should_ behave? What currently 
happens on my machine is that KDE completely turns off the backlight 
after the dim timeout, because it assumes that the value 0 will keep the 
backlight at a readable level (which would be the case if it used 
acpi_videoX because this behaviour is mandated by the spec there). I 
first thought of sending a patch to KDE, but I couldn't figure out how 
KDE is _supposed_ to correctly handle the situation, especially given 
that the actual sysfs interface used is abstracted away by Xrandr (and 
chosen by the Intel Xorg driver). With my patch, intel_backlight behaves 
in a way that roughly matches the behaviour mandated by the ACPI spec.
Do you have a way in mind that allows fixing this in user space?

Thanks,

Danny

[PATCH 1/1] drm/i915: Allow specifying a minimum brightness level for sysfs control.

[Danny Baumann]

Hi,

> Thus far our assumption always was that the acpi backlight works better
> than the intel native backlight. So everything only uses the intel
> backlight if there's no other backlight driver by default.
>
> So if I should merge this as a general solution for Windows 8 machines not
> working properly, we first need to figure out what windows does on these
> machines and either disable the acpi backlight or adapt it.

I fully agree to that. Making acpi_video control usable is preferable 
over using intel_backlight. As I lack the detail knowledge about the 
ACPI video stuff, I'd be great of one (or some) of you guys could look 
at the mentioned bug report ([1]) and comment on what the problem might 
be. I have added the basic needed information already and would be happy 
to provide any needed debugging info.

> Adding more kernel options is not a viable solution for the backlight mess
> imo.

Actually I'm fine with hardcoding the percentage as well ;) I just 
figured it might make sense to make it controllable for special-case 
uses, while still making intel_backlight usable for the 'normal' use case.

Regards,

Danny

[1] https://bugzilla.kernel.org/show_bug.cgi?id=55071

[PATCH 0/1] drm/i915: Allow specifying a minimum brightness level for sysfs control.

[Matthew Garrett]

On Tue, Mar 26, 2013 at 06:10:30PM +0100, Danny Baumann wrote:
> Am 26.03.2013 18:02, schrieb Matthew Garrett:
> >I'm not quite clear what you mean here. The behaviour of "0" isn't well
> >defined for the ACPI backlight driver - it's perfectly reasonable for it
> >to turn the backlight off entirely. Anything assuming that "0" is still
> >visible is broken.
> 
> Well, the ACPI spec says this (section B.5.2):
> 
> "
> The OEM may define the number 0 as "Zero brightness" that can mean
> to turn off the lighting (e.g. LCD panel backlight) in the device.
> This may be useful in the case of an output device that can still be
> viewed using only ambient light, for example, a transflective LCD.
> "
> 
> My interpretation of this is that the value 0 is supposed to still
> be visible. I'm pretty sure I saw a statement that 0 is supposed to
> mean "barely visible" somewhere, but can't find it at the moment.
> I'll search for the source of it.

I think that's a stretch - "This may be useful" isn't normative 
language, "The OEM may define" is. But even if we do assert it for the 
ACPI backlight, it's not true for other interfaces - zero backlight 
intensity is supposed to be screen off on Apple hardware, for instance.

-- 
Matthew Garrett | mjg59 at srcf.ucam.org

[PATCH 0/1] drm/i915: Allow specifying a minimum brightness level for sysfs control.

[Matthew Garrett]

On Tue, Mar 26, 2013 at 12:48:44PM +0100, Danny Baumann wrote:
> This patch makes the behaviour of the intel_backlight backlight device
> consistent to e.g. acpi_videoX: When writing the value 0, the set brightness
> makes the panel content barely readable instead of turning the backlight off.
> This matches the expectations of user space (e.g. kde-workspace or the Intel
> X11 driver), which expects that it can use intel_backlight as a drop-in
> replacement for acpi_videoX.

I'm not quite clear what you mean here. The behaviour of "0" isn't well 
defined for the ACPI backlight driver - it's perfectly reasonable for it 
to turn the backlight off entirely. Anything assuming that "0" is still 
visible is broken.

-- 
Matthew Garrett | mjg59 at srcf.ucam.org

[Intel-gfx] [PATCH] drm/i915: Add i915.dp_limit_max_lane_count driver option.

[Daniel Vetter]

On Tue, Mar 26, 2013 at 4:40 PM, Michal Srb  wrote:
> Since 2514bc510d0c3aadcc5204056bb440fa36845147, the intel_dp_mode_fixup
> function prefers lane count over frequency. That causes problems on
> hardware that has less working lanes than it reports. This option allows
> to workaround such hardware bugs.
>
> Signed-off-by: Michal Srb 
> ---
> This is workaround for hardware issues uncovered by this commit:
>
>   commit 2514bc510d0c3aadcc5204056bb440fa36845147
>   Author: Jesse Barnes 
>   Date:   Thu Jun 21 15:13:50 2012 -0700
>
>   drm/i915: prefer wide & slow to fast & narrow in DP configs
>
>   High frequency link configurations have the potential to cause trouble
>   with long and/or cheap cables, so prefer slow and wide configurations
>   instead.  This patch has the potential to cause trouble for eDP
>   configurations that lie about available lanes, so if we run into that we
>   can make it conditional on eDP.
>
> I have IBM POS machine (4852-570 Truman) that has internal monitor
> connected over display port. It reports to have 2 lanes, but only 1
> lane works reliably. With 2 lanes used, the monitor sometimes doesn't
> turn on. It seems that this is hardware issue specific for this model.
>
> From discussion that was around the 2514bc510d0c3aadcc5204056bb440fa36845147
> commit I understand there are more machines that have similar problems.
> This option can be used to solve them.

It sounds like we need to start with a DPCD quirk database ... Ajax?
-Daniel

> ---
>
>  drivers/gpu/drm/i915/i915_drv.c |6 ++
>  drivers/gpu/drm/i915/i915_drv.h |1 +
>  drivers/gpu/drm/i915/intel_dp.c |   15 +--
>  3 files changed, 20 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 6c4b13c..5949d7c 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -123,6 +123,12 @@ module_param_named(preliminary_hw_support,
> i915_preliminary_hw_support, int, 060
>  MODULE_PARM_DESC(preliminary_hw_support,
> "Enable preliminary hardware support. (default: false)");
>
> +int i915_dp_limit_max_lane_count __read_mostly = -1;
> +module_param_named(dp_limit_max_lane_count, i915_dp_limit_max_lane_count,
> int, 0600);
> +MODULE_PARM_DESC(dp_limit_max_lane_count,
> +   "Limit the maximal number of used display port lanes. "
> +   "(default: -1 (no limit))");
> +
>  static struct drm_driver driver;
>  extern int intel_agp_enabled;
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 1657d873..646e400 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1398,6 +1398,7 @@ extern int i915_enable_fbc __read_mostly;
>  extern bool i915_enable_hangcheck __read_mostly;
>  extern int i915_enable_ppgtt __read_mostly;
>  extern unsigned int i915_preliminary_hw_support __read_mostly;
> +extern int i915_dp_limit_max_lane_count __read_mostly;
>
>  extern int i915_suspend(struct drm_device *dev, pm_message_t state);
>  extern int i915_resume(struct drm_device *dev);
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 662a185..3812773 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -132,6 +132,17 @@ intel_edp_target_clock(struct intel_encoder
> *intel_encoder,
> return mode->clock;
>  }
>
> +static inline u8
> +intel_dp_max_lane_count(u8 dpcd[DP_RECEIVER_CAP_SIZE])
> +{
> +   u8 max_lane_count = drm_dp_max_lane_count(dpcd);
> +
> +   if(i915_dp_limit_max_lane_count != -1 && max_lane_count >
> i915_dp_limit_max_lane_count)
> +   max_lane_count = i915_dp_limit_max_lane_count;
> +
> +   return max_lane_count;
> +}
> +
>  static int
>  intel_dp_max_link_bw(struct intel_dp *intel_dp)
>  {
> @@ -184,7 +195,7 @@ intel_dp_adjust_dithering(struct intel_dp *intel_dp,
>  {
> int max_link_clock =
> drm_dp_bw_code_to_link_rate(intel_dp_max_link_bw(intel_dp));
> -   int max_lanes = drm_dp_max_lane_count(intel_dp->dpcd);
> +   int max_lanes = intel_dp_max_lane_count(intel_dp->dpcd);
> int max_rate, mode_rate;
>
> mode_rate = intel_dp_link_required(mode->clock, 24);
> @@ -697,7 +708,7 @@ intel_dp_mode_fixup(struct drm_encoder *encoder,
> struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> struct intel_connector *intel_connector = 
> intel_dp->attached_connector;
> int lane_count, clock;
> -   int max_lane_count = drm_dp_max_lane_count(intel_dp->dpcd);
> +   int max_lane_count = intel_dp_max_lane_count(intel_dp->dpcd);
> int max_clock = intel_dp_max_link_bw(intel_dp) == DP_LINK_BW_2_7 ? 1 
> : 0;
> int bpp, mode_rate;
> static int bws[2] = { DP_LINK_BW_1_62, DP_LINK_BW_2_7 };
> --
> 1.7.7
>
>
> ___
> Intel-gfx mailing list
> Intel-gfx at 

[PATCH 1/1] drm/i915: Allow specifying a minimum brightness level for sysfs control.

[Daniel Vetter]

On Tue, Mar 26, 2013 at 12:48:45PM +0100, Danny Baumann wrote:
> When controlling backlight devices via sysfs interface, user space
> generally assumes the minimum level (0) still providing a brightness
> that is usable by the user (probably due to the most commonly used
> backlight device, acpi_videoX, behaving exactly like that). This doesn't
> match the current behaviour of the intel_backlight control, though, as
> the value 0 means 'backlight off'.
> 
> In order to make intel_backlight consistent to other backlight devices,
> introduce a module parameter that allows shifting the 0 level of the
> intel_backlight device. It's expressed in percentages of the maximum
> level. The default is 5, which provides a backlight level that is barely
> readable. Setting it to 0 restores the old behaviour.
> 
> Signed-off-by: Danny Baumann 

Thus far our assumption always was that the acpi backlight works better
than the intel native backlight. So everything only uses the intel
backlight if there's no other backlight driver by default.

So if I should merge this as a general solution for Windows 8 machines not
working properly, we first need to figure out what windows does on these
machines and either disable the acpi backlight or adapt it.

Adding more kernel options is not a viable solution for the backlight mess
imo.
-Daniel

> ---
>  drivers/gpu/drm/i915/intel_panel.c | 48 
> --
>  1 file changed, 41 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_panel.c 
> b/drivers/gpu/drm/i915/intel_panel.c
> index bee8cb6..5bad49d 100644
> --- a/drivers/gpu/drm/i915/intel_panel.c
> +++ b/drivers/gpu/drm/i915/intel_panel.c
> @@ -395,10 +395,35 @@ intel_panel_detect(struct drm_device *dev)
>  }
>  
>  #ifdef CONFIG_BACKLIGHT_CLASS_DEVICE
> +
> +static int i915_panel_min_brightness_percent = 5;
> +MODULE_PARM_DESC(min_sysfs_brightness, "Minimum brightness percentage 
> settable "
> + "via sysfs. This adjusts the brightness level of the value '0' in the "
> + "intel_backlight sysfs backlight interface.");
> +module_param_named(min_sysfs_brightness,
> +i915_panel_min_brightness_percent, int, 0400);
> +
> +static int intel_panel_min_brightness(struct drm_device *dev)
> +{
> + int max;
> +
> + if (i915_panel_min_brightness_percent <= 0)
> + return 0;
> +
> + max = intel_panel_get_max_backlight(dev);
> + if (i915_panel_min_brightness_percent >= 100)
> + return max;
> +
> + return max * i915_panel_min_brightness_percent / 100;
> +}
> +
>  static int intel_panel_update_status(struct backlight_device *bd)
>  {
>   struct drm_device *dev = bl_get_data(bd);
> - intel_panel_set_backlight(dev, bd->props.brightness);
> + int brightness =
> + bd->props.brightness + intel_panel_min_brightness(dev);
> +
> + intel_panel_set_backlight(dev, brightness);
>   return 0;
>  }
>  
> @@ -406,7 +431,10 @@ static int intel_panel_get_brightness(struct 
> backlight_device *bd)
>  {
>   struct drm_device *dev = bl_get_data(bd);
>   struct drm_i915_private *dev_priv = dev->dev_private;
> - return dev_priv->backlight_level;
> + int brightness =
> + dev_priv->backlight_level - intel_panel_min_brightness(dev);
> +
> + return brightness;
>  }
>  
>  static const struct backlight_ops intel_panel_bl_ops = {
> @@ -419,16 +447,21 @@ int intel_panel_setup_backlight(struct drm_connector 
> *connector)
>   struct drm_device *dev = connector->dev;
>   struct drm_i915_private *dev_priv = dev->dev_private;
>   struct backlight_properties props;
> + int max_brightness;
>  
>   intel_panel_init_backlight(dev);
>  
> - memset(, 0, sizeof(props));
> - props.type = BACKLIGHT_RAW;
> - props.max_brightness = _intel_panel_get_max_backlight(dev);
> - if (props.max_brightness == 0) {
> + max_brightness = _intel_panel_get_max_backlight(dev);
> + if (max_brightness == 0) {
>   DRM_DEBUG_DRIVER("Failed to get maximum backlight value\n");
>   return -ENODEV;
>   }
> +
> + memset(, 0, sizeof(props));
> + props.type = BACKLIGHT_RAW;
> + props.max_brightness =
> + max_brightness - intel_panel_min_brightness(dev);
> +
>   dev_priv->backlight =
>   backlight_device_register("intel_backlight",
> >kdev, dev,
> @@ -440,7 +473,8 @@ int intel_panel_setup_backlight(struct drm_connector 
> *connector)
>   dev_priv->backlight = NULL;
>   return -ENODEV;
>   }
> - dev_priv->backlight->props.brightness = intel_panel_get_backlight(dev);
> + dev_priv->backlight->props.brightness = intel_panel_get_backlight(dev)
> + - intel_panel_min_brightness(dev);
>   return 0;
>  }
>  
> -- 
> 1.8.1.4
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> 

[PATCH 1/1] drm/i915: Allow specifying a minimum brightness level for sysfs control.

[Chris Wilson]

On Tue, Mar 26, 2013 at 04:13:13PM +0100, Daniel Vetter wrote:
> On Tue, Mar 26, 2013 at 12:48:45PM +0100, Danny Baumann wrote:
> > When controlling backlight devices via sysfs interface, user space
> > generally assumes the minimum level (0) still providing a brightness
> > that is usable by the user (probably due to the most commonly used
> > backlight device, acpi_videoX, behaving exactly like that). This doesn't
> > match the current behaviour of the intel_backlight control, though, as
> > the value 0 means 'backlight off'.
> > 
> > In order to make intel_backlight consistent to other backlight devices,
> > introduce a module parameter that allows shifting the 0 level of the
> > intel_backlight device. It's expressed in percentages of the maximum
> > level. The default is 5, which provides a backlight level that is barely
> > readable. Setting it to 0 restores the old behaviour.
> > 
> > Signed-off-by: Danny Baumann 
> 
> Thus far our assumption always was that the acpi backlight works better
> than the intel native backlight. So everything only uses the intel
> backlight if there's no other backlight driver by default.

There are machines, such as the pnv netbook on my desk, on which
intel_backlight does nothing and the only control is through
acpi_backlight0. Generalising expected behaviour based on one firmware
implementation is fraught with danger.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[PATCH v4 09/21] modetest: Allow specifying plane position

[Archit Taneja]

On Tuesday 26 March 2013 04:11 AM, Laurent Pinchart wrote:
> Hi Archit,
>
> On Monday 25 March 2013 11:44:35 Archit Taneja wrote:
>> Hi Laurent,
>>
>> On Tuesday 19 March 2013 08:25 PM, Laurent Pinchart wrote:
>>> Extend the -P option to allow specifying the plane x and y offsets. The
>>> position is optional, if not specified the plane will be positioned at
>>> the center of the screen as before.
>>
>> Thanks for this series. I tested the patches with a Panda ES board.
>>
>> I was facing issues with the plane position though, when I execute this
>> on the command line:
>>
>> ./modetest -s 12:1440x900 -P 6:(0,0)/300x200
>>
>> I get a syntax error by bash saying it doesn't expect "(". I guess there
>> are ways around to get over this,
>
> I use
>
> ./modetest -s 12:1440x900 -P '6:(0,0)/300x200'
>
>> but I was wondering if we could get rid of the braces all together to keep
>> it simple? The "/" character could be used to figure out whether the user
>> has also mentioned position or not.
>
> It makes parsing the option a bit more complex, but I can do that if you think
> it's better.

I think it's fine. After googling a bit on the syntax error issue, I 
thought that putting the command in a script file was the only option, 
but your method above is convenient enough.

Thanks,
Archit

[PATCH 1/1] drm/i915: Allow specifying a minimum brightness level for sysfs control.

[Danny Baumann]

When controlling backlight devices via sysfs interface, user space
generally assumes the minimum level (0) still providing a brightness
that is usable by the user (probably due to the most commonly used
backlight device, acpi_videoX, behaving exactly like that). This doesn't
match the current behaviour of the intel_backlight control, though, as
the value 0 means 'backlight off'.

In order to make intel_backlight consistent to other backlight devices,
introduce a module parameter that allows shifting the 0 level of the
intel_backlight device. It's expressed in percentages of the maximum
level. The default is 5, which provides a backlight level that is barely
readable. Setting it to 0 restores the old behaviour.

Signed-off-by: Danny Baumann 
---
 drivers/gpu/drm/i915/intel_panel.c | 48 --
 1 file changed, 41 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_panel.c 
b/drivers/gpu/drm/i915/intel_panel.c
index bee8cb6..5bad49d 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -395,10 +395,35 @@ intel_panel_detect(struct drm_device *dev)
 }

 #ifdef CONFIG_BACKLIGHT_CLASS_DEVICE
+
+static int i915_panel_min_brightness_percent = 5;
+MODULE_PARM_DESC(min_sysfs_brightness, "Minimum brightness percentage settable 
"
+   "via sysfs. This adjusts the brightness level of the value '0' in the "
+   "intel_backlight sysfs backlight interface.");
+module_param_named(min_sysfs_brightness,
+  i915_panel_min_brightness_percent, int, 0400);
+
+static int intel_panel_min_brightness(struct drm_device *dev)
+{
+   int max;
+
+   if (i915_panel_min_brightness_percent <= 0)
+   return 0;
+
+   max = intel_panel_get_max_backlight(dev);
+   if (i915_panel_min_brightness_percent >= 100)
+   return max;
+
+   return max * i915_panel_min_brightness_percent / 100;
+}
+
 static int intel_panel_update_status(struct backlight_device *bd)
 {
struct drm_device *dev = bl_get_data(bd);
-   intel_panel_set_backlight(dev, bd->props.brightness);
+   int brightness =
+   bd->props.brightness + intel_panel_min_brightness(dev);
+
+   intel_panel_set_backlight(dev, brightness);
return 0;
 }

@@ -406,7 +431,10 @@ static int intel_panel_get_brightness(struct 
backlight_device *bd)
 {
struct drm_device *dev = bl_get_data(bd);
struct drm_i915_private *dev_priv = dev->dev_private;
-   return dev_priv->backlight_level;
+   int brightness =
+   dev_priv->backlight_level - intel_panel_min_brightness(dev);
+
+   return brightness;
 }

 static const struct backlight_ops intel_panel_bl_ops = {
@@ -419,16 +447,21 @@ int intel_panel_setup_backlight(struct drm_connector 
*connector)
struct drm_device *dev = connector->dev;
struct drm_i915_private *dev_priv = dev->dev_private;
struct backlight_properties props;
+   int max_brightness;

intel_panel_init_backlight(dev);

-   memset(, 0, sizeof(props));
-   props.type = BACKLIGHT_RAW;
-   props.max_brightness = _intel_panel_get_max_backlight(dev);
-   if (props.max_brightness == 0) {
+   max_brightness = _intel_panel_get_max_backlight(dev);
+   if (max_brightness == 0) {
DRM_DEBUG_DRIVER("Failed to get maximum backlight value\n");
return -ENODEV;
}
+
+   memset(, 0, sizeof(props));
+   props.type = BACKLIGHT_RAW;
+   props.max_brightness =
+   max_brightness - intel_panel_min_brightness(dev);
+
dev_priv->backlight =
backlight_device_register("intel_backlight",
  >kdev, dev,
@@ -440,7 +473,8 @@ int intel_panel_setup_backlight(struct drm_connector 
*connector)
dev_priv->backlight = NULL;
return -ENODEV;
}
-   dev_priv->backlight->props.brightness = intel_panel_get_backlight(dev);
+   dev_priv->backlight->props.brightness = intel_panel_get_backlight(dev)
+   - intel_panel_min_brightness(dev);
return 0;
 }

-- 
1.8.1.4

[PATCH 0/1] drm/i915: Allow specifying a minimum brightness level for sysfs control.

[Danny Baumann]

This patch makes the behaviour of the intel_backlight backlight device
consistent to e.g. acpi_videoX: When writing the value 0, the set brightness
makes the panel content barely readable instead of turning the backlight off.
This matches the expectations of user space (e.g. kde-workspace or the Intel
X11 driver), which expects that it can use intel_backlight as a drop-in
replacement for acpi_videoX.
As BIOSes written for Windows 8 support seem to expect the display driver
taking care of the brightness control instead of ACPI methods (see [1]),
I would expect quite a number of people (like me ;) ) having the need of
using intel_backlight instead of acpi_videoX. A quick Google search
indicated that most people are confused by the current behaviour, so I think
it's a good idea to make the default behaviour somehow match acpi_videoX.

Regards,

Danny

[1] https://bugzilla.kernel.org/show_bug.cgi?id=55071

Danny Baumann (1):
  drm/i915: Allow specifying a minimum brightness level for sysfs
control.

 drivers/gpu/drm/i915/intel_panel.c | 48 --
 1 file changed, 41 insertions(+), 7 deletions(-)

-- 
1.8.1.4

[PATCHv2 1/3] pci: added pcie_get_speed_cap_mask function

[Bjorn Helgaas]

On Tue, Mar 19, 2013 at 11:24 PM, Lucas Kannebley Tavares
 wrote:
> Added function to gather the speed cap for a device and return a mask to
> supported speeds. The function is divided into an interface and a weak
> implementation so that architecture-specific functions can be called.
>
> This is the first step in moving function drm_pcie_get_speed_cap_mask
> from the drm subsystem to the pci one.

This still doesn't feel right to me.

I'm definitely not a hardware guy, but my understanding based on the
PCIe spec r3.0, sec 6.11, is that the hardware will automatically
maintain the link at the highest speed supported by both ends of the
link, unless software sets a lower Target Link Speed.  The only users
of this function are some Radeon drivers, and it looks like they only
use it because the hardware doesn't conform to this aspect of the spec
and requires device-specific tweaking.

We already have bus->max_bus_speed, which should tell you the max
speed supported by the upstream component.  Is that enough
information?  Maybe the radeon drivers could simply do something like
this:

speed = rdev->ddev->pdev->bus->max_bus_speed;
if (speed == PCI_SPEED_UNKNOWN || speed < PCIE_SPEED_5_0GT)
return;

In your original email [1], you mentioned a null pointer dereference,
presumably when reading the PCIe capability for dev->pdev->bus->self,
with "self" being NULL.  This only happens for a bus with no upstream
P2P bridge, i.e., self will be NULL only if pdev is on a root bus.
But we also know pdev is a PCIe device, and I think a PCIe device on a
root bus must be a "Root Complex Integrated Endpoint" (PCIe spec sec
1.3.2.3).  Such a device does not have a link at all, so there's no
point in fiddling with its link speed.

I don't see how a radeon device could be an integrated endpoint, but
in your hypervisor environment, maybe it isn't quite spec-compliant in
terms of its attachment.  Can you collect the output of "lspci -vv"?
Maybe that will make things clearer.

In any case, if a radeon device is on a root bus, I think the root bus
max_bus_speed will be PCI_SPEED_UNKNOWN, and if it's not on a root
bus, max_bus_speed should be set correctly based on the upstream PCIe
port.

Bjorn

[1] http://lkml.kernel.org/r/50819140.8030806 at linux.vnet.ibm.com

> Signed-off-by: Lucas Kannebley Tavares 
> ---
>  drivers/pci/pci.c   |   44 
>  include/linux/pci.h |6 ++
>  2 files changed, 50 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index b099e00..d94ab79 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -3931,6 +3931,50 @@ static int __init pci_setup(char *str)
>  }
>  early_param("pci", pci_setup);
>
> +int __weak pcibios_get_speed_cap_mask(struct pci_dev *dev, u32 *mask)
> +{
> +   struct pci_dev *root;
> +   u32 lnkcap, lnkcap2;
> +
> +   *mask = 0;
> +   if (!dev)
> +   return -EINVAL;
> +
> +   root = dev->bus->self;
> +
> +   /* we've been informed via and serverworks don't make the cut */
> +   if (root->vendor == PCI_VENDOR_ID_VIA ||
> +   root->vendor == PCI_VENDOR_ID_SERVERWORKS)
> +   return -EINVAL;
> +
> +   pcie_capability_read_dword(root, PCI_EXP_LNKCAP, );
> +   pcie_capability_read_dword(root, PCI_EXP_LNKCAP2, );
> +
> +   if (lnkcap2) {  /* PCIe r3.0-compliant */
> +   if (lnkcap2 & PCI_EXP_LNKCAP2_SLS_2_5GB)
> +   *mask |= PCIE_SPEED_25;
> +   if (lnkcap2 & PCI_EXP_LNKCAP2_SLS_5_0GB)
> +   *mask |= PCIE_SPEED_50;
> +   if (lnkcap2 & PCI_EXP_LNKCAP2_SLS_8_0GB)
> +   *mask |= PCIE_SPEED_80;
> +   } else {/* pre-r3.0 */
> +   if (lnkcap & PCI_EXP_LNKCAP_SLS_2_5GB)
> +   *mask |= PCIE_SPEED_25;
> +   if (lnkcap & PCI_EXP_LNKCAP_SLS_5_0GB)
> +   *mask |= (PCIE_SPEED_25 | PCIE_SPEED_50);
> +   }
> +
> +   dev_info(>dev, "probing gen 2 caps for device %x:%x = %x/%x\n",
> +   root->vendor, root->device, lnkcap, lnkcap2);
> +   return 0;
> +}
> +
> +int pcie_get_speed_cap_mask(struct pci_dev *dev, u32 *mask)
> +{
> +   return pcibios_get_speed_cap_mask(dev, mask);
> +}
> +EXPORT_SYMBOL(pcie_get_speed_cap_mask);
> +
>  EXPORT_SYMBOL(pci_reenable_device);
>  EXPORT_SYMBOL(pci_enable_device_io);
>  EXPORT_SYMBOL(pci_enable_device_mem);
> diff --git a/include/linux/pci.h b/include/linux/pci.h
> index 2461033a..24a2f63 100644
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -1861,4 +1861,10 @@ static inline struct eeh_dev 
> *pci_dev_to_eeh_dev(struct pci_dev *pdev)
>   */
>  struct pci_dev *pci_find_upstream_pcie_bridge(struct pci_dev *pdev);
>
> +#define PCIE_SPEED_25 1
> +#define PCIE_SPEED_50 2
> +#define PCIE_SPEED_80 4
> +
> +extern int pcie_get_speed_cap_mask(struct pci_dev *dev, u32 *speed_mask);
> +
>  #endif /* 

[Bug 62756] Rendering errors on rv790 with llvm and unigine heaven 3.0

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=62756

--- Comment #1 from Michel D?nzer  ---
(In reply to comment #1)
> I tried finding a working commit going back with mesa, but I get to a point
> where llvm renders nothing at all with anything using current llvm svn.

There have been incompatible changes to the interface between r600g and the
LLVM R600 backend, so you'd probably need a matching LLVM snapshot. The Git
mirror at http://llvm.org/git/llvm.git might be helpful for this.

-- 
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/20130326/39e9b2cc/attachment.html>

[Bug 62756] Rendering errors on rv790 with llvm and unigine heaven 3.0

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=62756

Andy Furniss  changed:

   What|Removed |Added

  Attachment #77043|text/plain  |image/jpeg
  mime type||

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130326/67babb30/attachment.html>

[Bug 62756] New: Rendering errors on rv790 with llvm and unigine heaven 3.0

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=62756

  Priority: medium
Bug ID: 62756
  Assignee: dri-devel at lists.freedesktop.org
   Summary: Rendering errors on rv790 with llvm and unigine heaven
3.0
  Severity: normal
Classification: Unclassified
OS: Linux (All)
  Reporter: lists at andyfurniss.entadsl.com
  Hardware: x86-64 (AMD64)
Status: NEW
   Version: git
 Component: Drivers/Gallium/r600
   Product: Mesa

Created attachment 77043
  --> https://bugs.freedesktop.org/attachment.cgi?id=77043=edit
heaven + llvm on rv790 rendering errors.

rv790 with git mesa and svn llvm, testing unigine heaven 3.0 like -

MESA_EXTENSION_OVERRIDE=-GL_ARB_shader_bit_encoding 
force_glsl_extensions_warn=true  ./heaven

I haven't tested this for a while - it was OK sometime ago with FDO llvm but
now I am getting some rendering errors (scree shot attached) with current mesa
git and llvm svn.

I tried finding a working commit going back with mesa, but I get to a point
where llvm renders nothing at all with anything using current llvm svn.

R600_LLVM=0 has no problems.

-- 
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/20130326/fa2aa6b9/attachment.html>

[Bug 8191] a running org crahses when swithing back from a fb console with dri enabled on an amd64 with a mga g550

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=8191

--- Comment #6 from markus gapp  ---
I only can change the status to: assigned, resolved oder needinfo -- none of
them seems appropriate, but please feel free to change...

markus

-- 
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/20130326/981af754/attachment-0001.html>

[Bug 62696] [r300g, bisected] Around 50 piglit vs variable-indexing tests fails after "glsl_to_tgsi: allocate arrays separately v2"

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=62696

Christian K?nig  changed:

   What|Removed |Added

 Status|NEEDINFO|RESOLVED
 Resolution|--- |FIXED

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130326/01fd58cb/attachment.html>

[Bug 62226] Build Fails with LLVM

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=62226

--- Comment #4 from Niels Ole Salscheider  
---
This is still an issue for me.

I use an out-of-tree build for mesa (and build the shared llvm libraries with
cmake), though.

-- 
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/20130326/f2ff7d1f/attachment.html>

[Bug 8174] Store back-buffer/depth-buffer in AGP memory (rather than video RAM)

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=8174

--- Comment #2 from chemtech  ---
Jaime,
Do you still experience this issue with newer soft ?
Please check the status of your issue.
Or close this bug.

-- 
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/20130326/21c77b95/attachment.html>

[Bug 9379] drmCommandNone( fd, DRM_R128_CCE_IDLE ) - gives errno 22

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=9379

--- Comment #21 from chemtech  ---
Please check the status of your issue.
Or close this bug.

-- 
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/20130326/33926d3c/attachment.html>

[Nouveau] [PATCH] drm/nouveau: Ack interrupts for some fuc engines

[Maarten Lankhorst]

Op 25-03-13 19:14, Marcin Slusarz schreef:
> On Mon, Mar 25, 2013 at 10:22:37AM +0100, Maarten Lankhorst wrote:
>> Fixes 100% cpu usage when the exit interrupt never got acked.
>>
>> Signed-off-by: Maarten Lankhorst 
>> ---
>> diff --git a/drivers/gpu/drm/nouveau/core/core/falcon.c 
>> b/drivers/gpu/drm/nouveau/core/core/falcon.c
>> index e05c157..b11c5f3 100644
>> --- a/drivers/gpu/drm/nouveau/core/core/falcon.c
>> +++ b/drivers/gpu/drm/nouveau/core/core/falcon.c
>> @@ -229,6 +229,24 @@ _nouveau_falcon_fini(struct nouveau_object *object, 
>> bool suspend)
>>  return nouveau_engine_fini(>base, suspend);
>>  }
>>  
>> +void
>> +nouveau_falcon_intr(struct nouveau_subdev *subdev)
>> +{
>> +struct nouveau_falcon *falcon = (void*)subdev;
>> +u32 intr = nv_ro32(falcon, 0x008);
>> +
>> +nv_wo32(falcon, 0x004, intr);
>> +
>> +if (intr & 0x10) {
>> +intr &= ~0x10;
>> +
>> +nv_info(falcon, "Exit interrupt called\n");
> Do you really want to print it at "info" level? How frequent it is?
It shouldn't be often, I want it to run at the error level since that usually 
means the firmware exited prematurely/crashed and things go bad, but it happens 
with the secret scrubber finishing on initialization too. That one is harmless 
though.
>> +}
>> +
>> +if (intr)
>> +nv_error(falcon, "Unhandled interrupt %08x\n", intr);
>> +}
>> +
>>  int
>>  nouveau_falcon_create_(struct nouveau_object *parent,
>> struct nouveau_object *engine,
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>

[Bug 8191] a running org crahses when swithing back from a fb console with dri enabled on an amd64 with a mga g550

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=8191

--- Comment #5 from chemtech  ---
How can`t you close this bug?

-- 
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/20130326/c57944ef/attachment.html>

[PATCH v4 09/21] modetest: Allow specifying plane position

[Laurent Pinchart]

Hi Archit,

On Monday 25 March 2013 11:44:35 Archit Taneja wrote:
> Hi Laurent,
> 
> On Tuesday 19 March 2013 08:25 PM, Laurent Pinchart wrote:
> > Extend the -P option to allow specifying the plane x and y offsets. The
> > position is optional, if not specified the plane will be positioned at
> > the center of the screen as before.
> 
> Thanks for this series. I tested the patches with a Panda ES board.
> 
> I was facing issues with the plane position though, when I execute this
> on the command line:
> 
> ./modetest -s 12:1440x900 -P 6:(0,0)/300x200
> 
> I get a syntax error by bash saying it doesn't expect "(". I guess there
> are ways around to get over this,

I use

./modetest -s 12:1440x900 -P '6:(0,0)/300x200'

> but I was wondering if we could get rid of the braces all together to keep
> it simple? The "/" character could be used to figure out whether the user
> has also mentioned position or not.

It makes parsing the option a bit more complex, but I can do that if you think 
it's better.

-- 
Regards,

Laurent Pinchart

[Bug 62671] KDE thinks the monitor is reconnected each time it resumes

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=62671

--- Comment #3 from Filipus Klutiero  ---
I just identified that the regression appeared between 3.3.6 and 3.4.1. Beyond
that, Debian has no images for me to try. I never installed Linux without using
Debian packages. And even building with make-kpkg is something I haven't done
for a number of years.

If more testing is wanted, I would need guidance. To install intermediary
images, and maybe also to test more quickly, as with my current manual test,
just testing (after the target version is installed) requires about 5 minutes
per version.

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

Re: [Nouveau] [PATCH] drm/nouveau: Ack interrupts for some fuc engines

[Maarten Lankhorst]

Op 25-03-13 19:14, Marcin Slusarz schreef:
 On Mon, Mar 25, 2013 at 10:22:37AM +0100, Maarten Lankhorst wrote:
 Fixes 100% cpu usage when the exit interrupt never got acked.

 Signed-off-by: Maarten Lankhorst m.b.lankho...@gmail.com
 ---
 diff --git a/drivers/gpu/drm/nouveau/core/core/falcon.c 
 b/drivers/gpu/drm/nouveau/core/core/falcon.c
 index e05c157..b11c5f3 100644
 --- a/drivers/gpu/drm/nouveau/core/core/falcon.c
 +++ b/drivers/gpu/drm/nouveau/core/core/falcon.c
 @@ -229,6 +229,24 @@ _nouveau_falcon_fini(struct nouveau_object *object, 
 bool suspend)
  return nouveau_engine_fini(falcon-base, suspend);
  }
  
 +void
 +nouveau_falcon_intr(struct nouveau_subdev *subdev)
 +{
 +struct nouveau_falcon *falcon = (void*)subdev;
 +u32 intr = nv_ro32(falcon, 0x008);
 +
 +nv_wo32(falcon, 0x004, intr);
 +
 +if (intr  0x10) {
 +intr = ~0x10;
 +
 +nv_info(falcon, Exit interrupt called\n);
 Do you really want to print it at info level? How frequent it is?
It shouldn't be often, I want it to run at the error level since that usually 
means the firmware exited prematurely/crashed and things go bad, but it happens 
with the secret scrubber finishing on initialization too. That one is harmless 
though.
 +}
 +
 +if (intr)
 +nv_error(falcon, Unhandled interrupt %08x\n, intr);
 +}
 +
  int
  nouveau_falcon_create_(struct nouveau_object *parent,
 struct nouveau_object *engine,
 ___
 dri-devel mailing list
 dri-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/dri-devel


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

Re: [PATCH 1/4] drm/tilcdc: Fix an incorrect condition

[Sachin Kamat]

On 11 March 2013 15:38, Sachin Kamat sachin.ka...@linaro.org wrote:
 Hi Rob,

 On 2 March 2013 20:40, Rob Clark robdcl...@gmail.com wrote:
 On Sat, Mar 2, 2013 at 5:23 AM, Sachin Kamat sachin.ka...@linaro.org wrote:
 Instead of checking if num_encoders is zero, it is being assigned 0.
 Convert the assignment to a check.

 Signed-off-by: Sachin Kamat sachin.ka...@linaro.org

 Signed-off-by: Rob Clark robdcl...@gmail.com

 Just curious. Which tree would these patches be applied to (I mean
 your tree or Dave's)?

ping...


-- 
With warm regards,
Sachin
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/4] drm/tilcdc: Fix an incorrect condition

[Sachin Kamat]

On 25 March 2013 19:06, Rob Clark robdcl...@gmail.com wrote:
 sorry, was offline for a while (moving), and missed the last email..

No problem :)

 I would guess that Tomi would send pull-req for tilcdc and omapdrm.
 Well I suppose I could do it if Tomi can't, although my
 pandas/beagles/beaglebones are not unpacked yet..

Ok. Thanks.


-- 
With warm regards,
Sachin
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/nouveau: fix NULL ptr dereference from nv50_disp_intr()

[Peter Hurley]

On Sun, 2013-03-24 at 12:56 +0100, Maarten Lankhorst wrote:
 Op 23-03-13 12:47, Peter Hurley schreef:
  On Tue, 2013-03-19 at 11:13 -0400, Peter Hurley wrote:
  On vanilla 3.9.0-rc3, I get this 100% repeatable oops after login when
  the user X session is coming up:
  Perhaps I wasn't clear that this happens on every boot and is a
  regression from 3.8
 
  I'd be happy to help resolve this but time is of the essence; it would
  be a shame to have to revert all of this for 3.9
 
 Well it broke on my system too, so it was easy to fix.
 
 I didn't even need gdm to trigger it!
 
 8
 This fixes regression caused by 1d7c71a3e2f7 (drm/nouveau/disp: port vblank 
 handling to event interface),

Thanks Maarten!

But am I the only one running multi-head nouveau on linux-next and early
RCs? That's a scary thought.

Is there a test bench for validating nouveau?

Regards,
Peter Hurley


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

[Bug 9379] drmCommandNone( fd, DRM_R128_CCE_IDLE ) - gives errno 22

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=9379

--- Comment #21 from chemtech patsev.an...@gmail.com ---
Please check the status of your issue.
Or close this bug.

-- 
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 8174] Store back-buffer/depth-buffer in AGP memory (rather than video RAM)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=8174

--- Comment #2 from chemtech patsev.an...@gmail.com ---
Jaime,
Do you still experience this issue with newer soft ?
Please check the status of your issue.
Or close this bug.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 09/21] modetest: Allow specifying plane position

[Archit Taneja]

On Tuesday 26 March 2013 04:11 AM, Laurent Pinchart wrote:

Hi Archit,

On Monday 25 March 2013 11:44:35 Archit Taneja wrote:

Hi Laurent,

On Tuesday 19 March 2013 08:25 PM, Laurent Pinchart wrote:

Extend the -P option to allow specifying the plane x and y offsets. The
position is optional, if not specified the plane will be positioned at
the center of the screen as before.


Thanks for this series. I tested the patches with a Panda ES board.

I was facing issues with the plane position though, when I execute this
on the command line:

./modetest -s 12:1440x900 -P 6:(0,0)/300x200

I get a syntax error by bash saying it doesn't expect (. I guess there
are ways around to get over this,


I use

./modetest -s 12:1440x900 -P '6:(0,0)/300x200'


but I was wondering if we could get rid of the braces all together to keep
it simple? The / character could be used to figure out whether the user
has also mentioned position or not.


It makes parsing the option a bit more complex, but I can do that if you think
it's better.


I think it's fine. After googling a bit on the syntax error issue, I 
thought that putting the command in a script file was the only option, 
but your method above is convenient enough.


Thanks,
Archit

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

[Bug 62696] [r300g, bisected] Around 50 piglit vs variable-indexing tests fails after glsl_to_tgsi: allocate arrays separately v2

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=62696

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

   What|Removed |Added

 Status|NEEDINFO|RESOLVED
 Resolution|--- |FIXED

-- 
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 8191] a running org crahses when swithing back from a fb console with dri enabled on an amd64 with a mga g550

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=8191

--- Comment #6 from markus gapp markus.g...@ktv-one.at ---
I only can change the status to: assigned, resolved oder needinfo -- none of
them seems appropriate, but please feel free to change...

markus

-- 
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 62756] New: Rendering errors on rv790 with llvm and unigine heaven 3.0

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=62756

  Priority: medium
Bug ID: 62756
  Assignee: dri-devel@lists.freedesktop.org
   Summary: Rendering errors on rv790 with llvm and unigine heaven
3.0
  Severity: normal
Classification: Unclassified
OS: Linux (All)
  Reporter: li...@andyfurniss.entadsl.com
  Hardware: x86-64 (AMD64)
Status: NEW
   Version: git
 Component: Drivers/Gallium/r600
   Product: Mesa

Created attachment 77043
  -- https://bugs.freedesktop.org/attachment.cgi?id=77043action=edit
heaven + llvm on rv790 rendering errors.

rv790 with git mesa and svn llvm, testing unigine heaven 3.0 like -

MESA_EXTENSION_OVERRIDE=-GL_ARB_shader_bit_encoding 
force_glsl_extensions_warn=true  ./heaven

I haven't tested this for a while - it was OK sometime ago with FDO llvm but
now I am getting some rendering errors (scree shot attached) with current mesa
git and llvm svn.

I tried finding a working commit going back with mesa, but I get to a point
where llvm renders nothing at all with anything using current llvm svn.

R600_LLVM=0 has no problems.

-- 
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 62756] Rendering errors on rv790 with llvm and unigine heaven 3.0

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=62756

Andy Furniss li...@andyfurniss.entadsl.com changed:

   What|Removed |Added

  Attachment #77043|text/plain  |image/jpeg
  mime type||

-- 
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 62756] Rendering errors on rv790 with llvm and unigine heaven 3.0

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=62756

--- Comment #1 from Michel Dänzer mic...@daenzer.net ---
(In reply to comment #1)
 I tried finding a working commit going back with mesa, but I get to a point
 where llvm renders nothing at all with anything using current llvm svn.

There have been incompatible changes to the interface between r600g and the
LLVM R600 backend, so you'd probably need a matching LLVM snapshot. The Git
mirror at http://llvm.org/git/llvm.git might be helpful for this.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 0/8] omapdss/omapdrm: Misc fixes and improvements

[Archit Taneja]

These are misc fixes and improvements within omapdrm and omapdss. The fixes do 
the
following:

- Make omapdrm smarter to choose the right overlay managers as it's crtcs. This
  makes sure that omapdrm is functional for OMAP platforms with different
  combinations of panels connected to it.

- Fix certain areas in omapdrm which allow fixed resolution panels to work.

- Fix functional and pixel clock limits for DISPC, this ensures we don't try
  to try a mode that the hardware can't support.

- Some changes that came in OMAP5 ES2 silicon.

Note: The branch is based on the DSS misc series and dsi video mode calc series
posted by Tomi. Reference branch:

git://gitorious.org/~boddob/linux-omap-dss2/archit-dss2-clone.git 
for-3.10/misc_drm_dss

Archit Taneja (8):
  drm/omap: Don't return from modeset_init if a panel doesn't satisfy
omapdrm requirements
  drm/omap: Fix and improve crtc and overlay manager correlation
  drm/omap: Make fixed resolution panels work
  omapdss: features: fixed supported outputs for OMAP4
  omapdss: DISPC: add max pixel clock limits for LCD and TV managers
  omapdss: Features: Fix some parameter ranges
  OMAPDSS: DISPC: Configure doublestride for NV12 when using 2D Tiler
buffers
  OMAPDSS: DISPC: Revert to older DISPC Smart Standby mechanism for
OMAP5

 drivers/gpu/drm/omapdrm/omap_connector.c |   27 -
 drivers/gpu/drm/omapdrm/omap_crtc.c  |   21 ++--
 drivers/gpu/drm/omapdrm/omap_drv.c   |  161 --
 drivers/gpu/drm/omapdrm/omap_drv.h   |   38 +--
 drivers/gpu/drm/omapdrm/omap_encoder.c   |   24 -
 drivers/gpu/drm/omapdrm/omap_irq.c   |   17 ++--
 drivers/video/omap2/dss/dispc.c  |   52 --
 drivers/video/omap2/dss/dispc.h  |1 +
 drivers/video/omap2/dss/dss_features.c   |   14 ++-
 9 files changed, 260 insertions(+), 95 deletions(-)

-- 
1.7.10.4

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

[PATCH v2 1/8] drm/omap: Don't return from modeset_init if a panel doesn't satisfy omapdrm requirements

[Archit Taneja]

modeset_init iterates through all the registered omapdss devices and has some
initial checks to see if the panel has a driver and the required driver ops for
it to be usable by omapdrm.

The function bails out from modeset_init if a panel doesn't meet the
requirements, and stops the registration of the future panels and encoders which
come after it, that isn't the correct thing to do, we should go through the rest
of the panels. Replace the 'return's with 'continue's.

Reviewed-by: Rob Clark robdcl...@gmail.com
Signed-off-by: Archit Taneja arc...@ti.com
---
 drivers/gpu/drm/omapdrm/omap_drv.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c 
b/drivers/gpu/drm/omapdrm/omap_drv.c
index 079c54c..77b7225 100644
--- a/drivers/gpu/drm/omapdrm/omap_drv.c
+++ b/drivers/gpu/drm/omapdrm/omap_drv.c
@@ -121,7 +121,7 @@ static int omap_modeset_init(struct drm_device *dev)
if (!dssdev-driver) {
dev_warn(dev-dev, %s has no driver.. skipping it\n,
dssdev-name);
-   return 0;
+   continue;
}
 
if (!(dssdev-driver-get_timings ||
@@ -129,7 +129,7 @@ static int omap_modeset_init(struct drm_device *dev)
dev_warn(dev-dev, %s driver does not support 
get_timings or read_edid.. skipping it!\n,
dssdev-name);
-   return 0;
+   continue;
}
 
encoder = omap_encoder_init(dev, dssdev);
-- 
1.7.10.4

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

[PATCH v2 2/8] drm/omap: Fix and improve crtc and overlay manager correlation

[Archit Taneja]

The omapdrm driver currently takes a config/module arg to figure out the number
of crtcs it needs to create. We could create as many crtcs as there are overlay
managers in the DSS hardware, but we don't do that because each crtc eats up
one DSS overlay, and that reduces the number of planes we can attach to a single
crtc.

Since the number of crtcs may be lesser than the number of hardware overlay
managers, we need to figure out which overlay managers to use for our crtcs. The
current approach is to use pipe2chan(), which returns a higher numbered manager
for the crtc.

The problem with this approach is that it assumes that the overlay managers we
choose will connect to the encoders the platform's panels are going to use,
this isn't true, an overlay manager connects only to a few outputs/encoders, and
choosing any overlay manager for our crtc might lead to a situation where the
encoder cannot connect to any of the crtcs we have chosen. For example, an
omap5-panda board has just one hdmi output. If num_crtc is set to 1, with the
current approach, pipe2chan will pick up the LCD2 overlay manager, which cannot
connect to the hdmi encoder at all. The only manager that could have connected
to hdmi was the TV overlay manager.

Therefore, there is a need to choose our overlay managers keeping in mind the
panels we have on that platform. The new approach iterates through all the
available panels, creates encoders and connectors for them, and then tries to
get a suitable overlay manager to create a crtc which can connect to the
encoders.

We use the dispc_channel field in omap_dss_output to retrieve the desired
overlay manager's channel number, we then check whether the manager had already
been assigned to a crtc or not. If it was already assigned to a crtc, we assume
that out of all the encoders which intend use this crtc, only one will run at a
time. If the overlay manager wan't assigned to a crtc till then, we create a
new crtc and link it with the overlay manager.

This approach just looks for the best dispc_channel for each encoder. On DSS HW,
some encoders can connect to multiple overlay managers. Since we don't try
looking for alternate overlay managers, there is a greater possibility that 2
or more encoders end up asking for the same crtc, causing only one encoder to
run at a time.

Also, this approach isn't the most optimal one, it can do either good or bad
depending on the sequence in which the panels/outputs are parsed. The optimal
way would be some sort of back tracking approach, where we improve the set of
managers we use as we iterate through the list of panels/encoders. That's
something left for later.

Signed-off-by: Archit Taneja arc...@ti.com
---
 drivers/gpu/drm/omapdrm/omap_crtc.c|   21 +++--
 drivers/gpu/drm/omapdrm/omap_drv.c |  157 ++--
 drivers/gpu/drm/omapdrm/omap_drv.h |   38 +---
 drivers/gpu/drm/omapdrm/omap_encoder.c |7 ++
 drivers/gpu/drm/omapdrm/omap_irq.c |   17 ++--
 5 files changed, 165 insertions(+), 75 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c 
b/drivers/gpu/drm/omapdrm/omap_crtc.c
index bec66a4..79b200a 100644
--- a/drivers/gpu/drm/omapdrm/omap_crtc.c
+++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
@@ -74,6 +74,13 @@ struct omap_crtc {
struct work_struct page_flip_work;
 };
 
+uint32_t pipe2vbl(struct drm_crtc *crtc)
+{
+   struct omap_crtc *omap_crtc = to_omap_crtc(crtc);
+
+   return dispc_mgr_get_vsync_irq(omap_crtc-channel);
+}
+
 /*
  * Manager-ops, callbacks from output when they need to configure
  * the upstream part of the video pipe.
@@ -613,7 +620,13 @@ struct drm_crtc *omap_crtc_init(struct drm_device *dev,
omap_crtc-apply.pre_apply  = omap_crtc_pre_apply;
omap_crtc-apply.post_apply = omap_crtc_post_apply;
 
-   omap_crtc-apply_irq.irqmask = pipe2vbl(id);
+   omap_crtc-channel = channel;
+   omap_crtc-plane = plane;
+   omap_crtc-plane-crtc = crtc;
+   omap_crtc-name = channel_names[channel];
+   omap_crtc-pipe = id;
+
+   omap_crtc-apply_irq.irqmask = pipe2vbl(crtc);
omap_crtc-apply_irq.irq = omap_crtc_apply_irq;
 
omap_crtc-error_irq.irqmask =
@@ -621,12 +634,6 @@ struct drm_crtc *omap_crtc_init(struct drm_device *dev,
omap_crtc-error_irq.irq = omap_crtc_error_irq;
omap_irq_register(dev, omap_crtc-error_irq);
 
-   omap_crtc-channel = channel;
-   omap_crtc-plane = plane;
-   omap_crtc-plane-crtc = crtc;
-   omap_crtc-name = channel_names[channel];
-   omap_crtc-pipe = id;
-
/* temporary: */
omap_crtc-mgr.id = channel;
 
diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c 
b/drivers/gpu/drm/omapdrm/omap_drv.c
index 77b7225..cbaa003 100644
--- a/drivers/gpu/drm/omapdrm/omap_drv.c
+++ b/drivers/gpu/drm/omapdrm/omap_drv.c
@@ -74,49 +74,48 @@ static int get_connector_type(struct omap_dss_device 
*dssdev)
}
 }
 
+static bool channel_used(struct drm_device *dev, enum 

[PATCH v3 3/8] drm/omap: Make fixed resolution panels work

[Archit Taneja]

The omapdrm driver requires omapdss panel drivers to expose ops like detect,
set_timings and check_timings. These can be NULL for fixed panel DPI, DBI, DSI
and SDI drivers. At some places, there are no checks to see if the panel driver
has these ops or not, and that leads to a crash.

The following things are done to make fixed panels work:

- The omap_connector's detect function is modified such that it considers panel
  types which are generally fixed panels as always connected(provided the panel
  driver doesn't have a detect op). Hence, the connector corresponding to these
  panels is always in a 'connected' state.

- If a panel driver doesn't have a check_timings op, assume that it supports the
  mode passed to omap_connector_mode_valid(the 'mode_valid' drm helper function)

- The function omap_encoder_update shouldn't really do anything for fixed
  resolution panels, make sure that it calls set_timings only if the panel
  driver has one.

Signed-off-by: Archit Taneja arc...@ti.com
---
v3: clear the timings local variable first before using memcmp
v2: make sure the timings we try to set for a fixed resolution panel match the
panel's timings

 drivers/gpu/drm/omapdrm/omap_connector.c |   27 +--
 drivers/gpu/drm/omapdrm/omap_encoder.c   |   17 +++--
 2 files changed, 40 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_connector.c 
b/drivers/gpu/drm/omapdrm/omap_connector.c
index c451c41..912759d 100644
--- a/drivers/gpu/drm/omapdrm/omap_connector.c
+++ b/drivers/gpu/drm/omapdrm/omap_connector.c
@@ -110,6 +110,11 @@ static enum drm_connector_status omap_connector_detect(
ret = connector_status_connected;
else
ret = connector_status_disconnected;
+   } else if (dssdev-type == OMAP_DISPLAY_TYPE_DPI ||
+   dssdev-type == OMAP_DISPLAY_TYPE_DBI ||
+   dssdev-type == OMAP_DISPLAY_TYPE_SDI ||
+   dssdev-type == OMAP_DISPLAY_TYPE_DSI) {
+   ret = connector_status_connected;
} else {
ret = connector_status_unknown;
}
@@ -189,12 +194,30 @@ static int omap_connector_mode_valid(struct drm_connector 
*connector,
struct omap_video_timings timings = {0};
struct drm_device *dev = connector-dev;
struct drm_display_mode *new_mode;
-   int ret = MODE_BAD;
+   int r, ret = MODE_BAD;
 
copy_timings_drm_to_omap(timings, mode);
mode-vrefresh = drm_mode_vrefresh(mode);
 
-   if (!dssdrv-check_timings(dssdev, timings)) {
+   /*
+* if the panel driver doesn't have a check_timings, it's most likely
+* a fixed resolution panel, check if the timings match with the
+* panel's timings
+*/
+   if (dssdrv-check_timings) {
+   r = dssdrv-check_timings(dssdev, timings);
+   } else {
+   struct omap_video_timings t = {0};
+
+   dssdrv-get_timings(dssdev, t);
+
+   if (memcmp(timings, t, sizeof(struct omap_video_timings)))
+   r = -EINVAL;
+   else
+   r = 0;
+   }
+
+   if (!r) {
/* check if vrefresh is still valid */
new_mode = drm_mode_duplicate(dev, mode);
new_mode-clock = timings.pixel_clock;
diff --git a/drivers/gpu/drm/omapdrm/omap_encoder.c 
b/drivers/gpu/drm/omapdrm/omap_encoder.c
index d48df71..c29451b 100644
--- a/drivers/gpu/drm/omapdrm/omap_encoder.c
+++ b/drivers/gpu/drm/omapdrm/omap_encoder.c
@@ -135,13 +135,26 @@ int omap_encoder_update(struct drm_encoder *encoder,
 
dssdev-output-manager = mgr;
 
-   ret = dssdrv-check_timings(dssdev, timings);
+   if (dssdrv-check_timings) {
+   ret = dssdrv-check_timings(dssdev, timings);
+   } else {
+   struct omap_video_timings t = {0};
+
+   dssdrv-get_timings(dssdev, t);
+
+   if (memcmp(timings, t, sizeof(struct omap_video_timings)))
+   ret = -EINVAL;
+   else
+   ret = 0;
+   }
+
if (ret) {
dev_err(dev-dev, could not set timings: %d\n, ret);
return ret;
}
 
-   dssdrv-set_timings(dssdev, timings);
+   if (dssdrv-set_timings)
+   dssdrv-set_timings(dssdev, timings);
 
return 0;
 }
-- 
1.7.10.4

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

[PATCH v2 4/8] omapdss: features: fixed supported outputs for OMAP4

[Archit Taneja]

The support outputs struct for overlay managers is incorrect for OMAP4. Make
these changes:

- DPI isn't supported via the LCD1 overlay manager, remove DPI as a supported
  output.
- the TV manager can suppport DPI, but the omapdss driver doesn't support that
  yet, we require some muxing at the DSS level, and we also need to configure
  the hdmi pll in the DPI driver so that the TV manager has a pixel clock. We
  don't support that yet.

Signed-off-by: Archit Taneja arc...@ti.com
---
 drivers/video/omap2/dss/dss_features.c |6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/video/omap2/dss/dss_features.c 
b/drivers/video/omap2/dss/dss_features.c
index d7d66ef..7f791ae 100644
--- a/drivers/video/omap2/dss/dss_features.c
+++ b/drivers/video/omap2/dss/dss_features.c
@@ -202,12 +202,10 @@ static const enum omap_dss_output_id 
omap3630_dss_supported_outputs[] = {
 
 static const enum omap_dss_output_id omap4_dss_supported_outputs[] = {
/* OMAP_DSS_CHANNEL_LCD */
-   OMAP_DSS_OUTPUT_DPI | OMAP_DSS_OUTPUT_DBI |
-   OMAP_DSS_OUTPUT_DSI1,
+   OMAP_DSS_OUTPUT_DBI | OMAP_DSS_OUTPUT_DSI1,
 
/* OMAP_DSS_CHANNEL_DIGIT */
-   OMAP_DSS_OUTPUT_VENC | OMAP_DSS_OUTPUT_HDMI |
-   OMAP_DSS_OUTPUT_DPI,
+   OMAP_DSS_OUTPUT_VENC | OMAP_DSS_OUTPUT_HDMI,
 
/* OMAP_DSS_CHANNEL_LCD2 */
OMAP_DSS_OUTPUT_DPI | OMAP_DSS_OUTPUT_DBI |
-- 
1.7.10.4

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

[PATCH v2 5/8] omapdss: DISPC: add max pixel clock limits for LCD and TV managers

[Archit Taneja]

Each version of OMAP has a limitation on the maximum pixel clock frequency
supported by an overlay manager. This limit isn't checked by omapdss. Add
dispc feats for lcd and tv managers and check whether the target timings can
be supported or not.

The pixel clock limitations are actually more complex. They depend on which OPP
OMAP is in, and they also depend on which encoder is the manager connected to.
The OPP dependence is ignored as DSS forces the PM framework to be on OPP100
when DSS is enabled, and the encoder dependencies are ignored by DISPC for now.
These limits should come from the encoder driver.

The OMAP2 TRM doesn't mention the maximum pixel clock limit. This value is left
as half of DSS_FCLK, as OMAP2 requires the PCD to be atleast 2.

Signed-off-by: Archit Taneja arc...@ti.com
---
 drivers/video/omap2/dss/dispc.c |   32 +++-
 1 file changed, 27 insertions(+), 5 deletions(-)

diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index 8cfa27b..73a730a 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -69,6 +69,8 @@ struct dispc_features {
u8 mgr_height_start;
u16 mgr_width_max;
u16 mgr_height_max;
+   unsigned long max_lcd_pclk;
+   unsigned long max_tv_pclk;
int (*calc_scaling) (unsigned long pclk, unsigned long lclk,
const struct omap_video_timings *mgr_timings,
u16 width, u16 height, u16 out_width, u16 out_height,
@@ -2825,6 +2827,15 @@ static bool _dispc_lcd_timings_ok(int hsw, int hfp, int 
hbp,
return true;
 }
 
+static bool _dispc_mgr_pclk_ok(enum omap_channel channel,
+   unsigned long pclk)
+{
+   if (dss_mgr_is_lcd(channel))
+   return pclk = dispc.feat-max_lcd_pclk ? true : false;
+   else
+   return pclk = dispc.feat-max_tv_pclk ? true : false;
+}
+
 bool dispc_mgr_timings_ok(enum omap_channel channel,
const struct omap_video_timings *timings)
 {
@@ -2832,11 +2843,13 @@ bool dispc_mgr_timings_ok(enum omap_channel channel,
 
timings_ok = _dispc_mgr_size_ok(timings-x_res, timings-y_res);
 
-   if (dss_mgr_is_lcd(channel))
-   timings_ok =  timings_ok  _dispc_lcd_timings_ok(timings-hsw,
-   timings-hfp, timings-hbp,
-   timings-vsw, timings-vfp,
-   timings-vbp);
+   timings_ok = _dispc_mgr_pclk_ok(channel, timings-pixel_clock * 1000);
+
+   if (dss_mgr_is_lcd(channel)) {
+   timings_ok = _dispc_lcd_timings_ok(timings-hsw, timings-hfp,
+   timings-hbp, timings-vsw, timings-vfp,
+   timings-vbp);
+   }
 
return timings_ok;
 }
@@ -3491,6 +3504,7 @@ static const struct dispc_features omap24xx_dispc_feats 
__initconst = {
.mgr_height_start   =   26,
.mgr_width_max  =   2048,
.mgr_height_max =   2048,
+   .max_lcd_pclk   =   6650,
.calc_scaling   =   dispc_ovl_calc_scaling_24xx,
.calc_core_clk  =   calc_core_clk_24xx,
.num_fifos  =   3,
@@ -3508,6 +3522,8 @@ static const struct dispc_features 
omap34xx_rev1_0_dispc_feats __initconst = {
.mgr_height_start   =   26,
.mgr_width_max  =   2048,
.mgr_height_max =   2048,
+   .max_lcd_pclk   =   17300,
+   .max_tv_pclk=   5900,
.calc_scaling   =   dispc_ovl_calc_scaling_34xx,
.calc_core_clk  =   calc_core_clk_34xx,
.num_fifos  =   3,
@@ -3525,6 +3541,8 @@ static const struct dispc_features 
omap34xx_rev3_0_dispc_feats __initconst = {
.mgr_height_start   =   26,
.mgr_width_max  =   2048,
.mgr_height_max =   2048,
+   .max_lcd_pclk   =   17300,
+   .max_tv_pclk=   5900,
.calc_scaling   =   dispc_ovl_calc_scaling_34xx,
.calc_core_clk  =   calc_core_clk_34xx,
.num_fifos  =   3,
@@ -3542,6 +3560,8 @@ static const struct dispc_features omap44xx_dispc_feats 
__initconst = {
.mgr_height_start   =   26,
.mgr_width_max  =   2048,
.mgr_height_max =   2048,
+   .max_lcd_pclk   =   17000,
+   .max_tv_pclk=   185625000,
.calc_scaling   =   dispc_ovl_calc_scaling_44xx,
.calc_core_clk  =   calc_core_clk_44xx,
.num_fifos  =   5,
@@ -3559,6 +3579,8 @@ static const struct dispc_features omap54xx_dispc_feats 
__initconst = {
.mgr_height_start   =   27,

[PATCH v2 6/8] omapdss: Features: Fix some parameter ranges

[Archit Taneja]

Increase the DSS_FCLK and DSI_FCLK max supported frequencies, these come because
some frequencies were increased from OMAP5 ES1 to OMAP5 ES2. We support only
OMAP5 ES2 in the kernel, so replace the ES1 values with ES2 values. Increase the
DSI PLL Fint range, this was previously just copied from the OMAP4 param range
struct.

Fix the maximum DSS_FCLK on OMAP2, it's 133 Mhz according to the TRM.

Signed-off-by: Archit Taneja arc...@ti.com
---
 drivers/video/omap2/dss/dss_features.c |8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/video/omap2/dss/dss_features.c 
b/drivers/video/omap2/dss/dss_features.c
index 7f791ae..77dbe0c 100644
--- a/drivers/video/omap2/dss/dss_features.c
+++ b/drivers/video/omap2/dss/dss_features.c
@@ -414,7 +414,7 @@ static const char * const omap5_dss_clk_source_names[] = {
 };
 
 static const struct dss_param_range omap2_dss_param_range[] = {
-   [FEAT_PARAM_DSS_FCK]= { 0, 17300 },
+   [FEAT_PARAM_DSS_FCK]= { 0, 13300 },
[FEAT_PARAM_DSS_PCD]= { 2, 255 },
[FEAT_PARAM_DSIPLL_REGN]= { 0, 0 },
[FEAT_PARAM_DSIPLL_REGM]= { 0, 0 },
@@ -459,15 +459,15 @@ static const struct dss_param_range 
omap4_dss_param_range[] = {
 };
 
 static const struct dss_param_range omap5_dss_param_range[] = {
-   [FEAT_PARAM_DSS_FCK]= { 0, 2 },
+   [FEAT_PARAM_DSS_FCK]= { 0, 20925 },
[FEAT_PARAM_DSS_PCD]= { 1, 255 },
[FEAT_PARAM_DSIPLL_REGN]= { 0, (1  8) - 1 },
[FEAT_PARAM_DSIPLL_REGM]= { 0, (1  12) - 1 },
[FEAT_PARAM_DSIPLL_REGM_DISPC]  = { 0, (1  5) - 1 },
[FEAT_PARAM_DSIPLL_REGM_DSI]= { 0, (1  5) - 1 },
-   [FEAT_PARAM_DSIPLL_FINT]= { 50, 250 },
+   [FEAT_PARAM_DSIPLL_FINT]= { 15, 5200 },
[FEAT_PARAM_DSIPLL_LPDIV]   = { 0, (1  13) - 1 },
-   [FEAT_PARAM_DSI_FCK]= { 0, 17000 },
+   [FEAT_PARAM_DSI_FCK]= { 0, 20925 },
[FEAT_PARAM_DOWNSCALE]  = { 1, 4 },
[FEAT_PARAM_LINEWIDTH]  = { 1, 2048 },
 };
-- 
1.7.10.4

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

[PATCH v2 7/8] OMAPDSS: DISPC: Configure doublestride for NV12 when using 2D Tiler buffers

[Archit Taneja]

When using a DISPC video pipeline to a fetch a NV12 buffer in a 2D container, we
need to set set a doublestride bit in the video pipe's ATTRIBUTES register. This
is needed because the stride for the UV plane(using a 16 bit Tiler container) is
double the stride for the Y plane(using a 8 bit Tiler container) for the 0 or
180 degree views. The ROW_INC register is meant for the Y plane, and the HW will
calculate the row increment needed for the UV plane by using double the stride
value based on whether this bit is set or not.

Set the bit when we are using a 2D Tiler buffer and when rotation is 0 or 180
degrees. The stride value is the same for 90 and 270 degree Tiler views, hence
the bit shouldn't be set.

Signed-off-by: Archit Taneja arc...@ti.com
---
 drivers/video/omap2/dss/dispc.c |   13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index 73a730a..ddbf031 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -1588,6 +1588,7 @@ static void dispc_ovl_set_scaling(enum omap_plane plane,
 }
 
 static void dispc_ovl_set_rotation_attrs(enum omap_plane plane, u8 rotation,
+   enum omap_dss_rotation_type rotation_type,
bool mirroring, enum omap_color_mode color_mode)
 {
bool row_repeat = false;
@@ -1638,6 +1639,15 @@ static void dispc_ovl_set_rotation_attrs(enum omap_plane 
plane, u8 rotation,
if (dss_has_feature(FEAT_ROWREPEATENABLE))
REG_FLD_MOD(DISPC_OVL_ATTRIBUTES(plane),
row_repeat ? 1 : 0, 18, 18);
+
+   if (color_mode == OMAP_DSS_COLOR_NV12) {
+   bool doublestride = (rotation_type == OMAP_DSS_ROT_TILER) 
+   (rotation == OMAP_DSS_ROT_0 ||
+   rotation == OMAP_DSS_ROT_180);
+   /* DOUBLESTRIDE */
+   REG_FLD_MOD(DISPC_OVL_ATTRIBUTES(plane), doublestride, 22, 22);
+   }
+
 }
 
 static int color_mode_to_bpp(enum omap_color_mode color_mode)
@@ -2516,7 +2526,8 @@ static int dispc_ovl_setup_common(enum omap_plane plane,
dispc_ovl_set_vid_color_conv(plane, cconv);
}
 
-   dispc_ovl_set_rotation_attrs(plane, rotation, mirror, color_mode);
+   dispc_ovl_set_rotation_attrs(plane, rotation, rotation_type, mirror,
+   color_mode);
 
dispc_ovl_set_zorder(plane, caps, zorder);
dispc_ovl_set_pre_mult_alpha(plane, caps, pre_mult_alpha);
-- 
1.7.10.4

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

[PATCH v2 8/8] OMAPDSS: DISPC: Revert to older DISPC Smart Standby mechanism for OMAP5

[Archit Taneja]

DISPC on OMAP5 has a more optimised mechanism of asserting Mstandby to achieve
more power savings when DISPC is configured in Smart Standby mode. This
mechanism leads to underflows when multiple DISPC pipes are enabled.

There is a register field which can let us revert to the older mechanism of
asserting Mstandby. Configure this field to prevent underflows.

Signed-off-by: Archit Taneja arc...@ti.com
---
 drivers/video/omap2/dss/dispc.c |7 +++
 drivers/video/omap2/dss/dispc.h |1 +
 2 files changed, 8 insertions(+)

diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index ddbf031..b33b016 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -87,6 +87,9 @@ struct dispc_features {
 
/* no DISPC_IRQ_FRAMEDONETV on this SoC */
bool no_framedone_tv:1;
+
+   /* revert to the OMAP4 mechanism of DISPC Smart Standby operation */
+   bool mstandby_workaround:1;
 };
 
 #define DISPC_MAX_NR_FIFOS 5
@@ -3502,6 +3505,9 @@ static void _omap_dispc_initial_config(void)
dispc_configure_burst_sizes();
 
dispc_ovl_enable_zorder_planes();
+
+   if (dispc.feat-mstandby_workaround)
+   REG_FLD_MOD(DISPC_MSTANDBY_CTRL, 1, 0, 0);
 }
 
 static const struct dispc_features omap24xx_dispc_feats __initconst = {
@@ -3596,6 +3602,7 @@ static const struct dispc_features omap54xx_dispc_feats 
__initconst = {
.calc_core_clk  =   calc_core_clk_44xx,
.num_fifos  =   5,
.gfx_fifo_workaround=   true,
+   .mstandby_workaround=   true,
 };
 
 static int __init dispc_init_features(struct platform_device *pdev)
diff --git a/drivers/video/omap2/dss/dispc.h b/drivers/video/omap2/dss/dispc.h
index 222363c..de4863d 100644
--- a/drivers/video/omap2/dss/dispc.h
+++ b/drivers/video/omap2/dss/dispc.h
@@ -39,6 +39,7 @@
 #define DISPC_GLOBAL_BUFFER0x0800
 #define DISPC_CONTROL3  0x0848
 #define DISPC_CONFIG3   0x084C
+#define DISPC_MSTANDBY_CTRL0x0858
 
 /* DISPC overlay registers */
 #define DISPC_OVL_BA0(n)   (DISPC_OVL_BASE(n) + \
-- 
1.7.10.4

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

[PATCH 0/1] drm/i915: Allow specifying a minimum brightness level for sysfs control.

[Danny Baumann]

This patch makes the behaviour of the intel_backlight backlight device
consistent to e.g. acpi_videoX: When writing the value 0, the set brightness
makes the panel content barely readable instead of turning the backlight off.
This matches the expectations of user space (e.g. kde-workspace or the Intel
X11 driver), which expects that it can use intel_backlight as a drop-in
replacement for acpi_videoX.
As BIOSes written for Windows 8 support seem to expect the display driver
taking care of the brightness control instead of ACPI methods (see [1]),
I would expect quite a number of people (like me ;) ) having the need of
using intel_backlight instead of acpi_videoX. A quick Google search
indicated that most people are confused by the current behaviour, so I think
it's a good idea to make the default behaviour somehow match acpi_videoX.

Regards,

Danny

[1] https://bugzilla.kernel.org/show_bug.cgi?id=55071

Danny Baumann (1):
  drm/i915: Allow specifying a minimum brightness level for sysfs
control.

 drivers/gpu/drm/i915/intel_panel.c | 48 --
 1 file changed, 41 insertions(+), 7 deletions(-)

-- 
1.8.1.4

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

[PATCH 1/1] drm/i915: Allow specifying a minimum brightness level for sysfs control.

[Danny Baumann]

When controlling backlight devices via sysfs interface, user space
generally assumes the minimum level (0) still providing a brightness
that is usable by the user (probably due to the most commonly used
backlight device, acpi_videoX, behaving exactly like that). This doesn't
match the current behaviour of the intel_backlight control, though, as
the value 0 means 'backlight off'.

In order to make intel_backlight consistent to other backlight devices,
introduce a module parameter that allows shifting the 0 level of the
intel_backlight device. It's expressed in percentages of the maximum
level. The default is 5, which provides a backlight level that is barely
readable. Setting it to 0 restores the old behaviour.

Signed-off-by: Danny Baumann dannybaum...@web.de
---
 drivers/gpu/drm/i915/intel_panel.c | 48 --
 1 file changed, 41 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_panel.c 
b/drivers/gpu/drm/i915/intel_panel.c
index bee8cb6..5bad49d 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -395,10 +395,35 @@ intel_panel_detect(struct drm_device *dev)
 }
 
 #ifdef CONFIG_BACKLIGHT_CLASS_DEVICE
+
+static int i915_panel_min_brightness_percent = 5;
+MODULE_PARM_DESC(min_sysfs_brightness, Minimum brightness percentage settable 

+   via sysfs. This adjusts the brightness level of the value '0' in the 
+   intel_backlight sysfs backlight interface.);
+module_param_named(min_sysfs_brightness,
+  i915_panel_min_brightness_percent, int, 0400);
+
+static int intel_panel_min_brightness(struct drm_device *dev)
+{
+   int max;
+
+   if (i915_panel_min_brightness_percent = 0)
+   return 0;
+
+   max = intel_panel_get_max_backlight(dev);
+   if (i915_panel_min_brightness_percent = 100)
+   return max;
+
+   return max * i915_panel_min_brightness_percent / 100;
+}
+
 static int intel_panel_update_status(struct backlight_device *bd)
 {
struct drm_device *dev = bl_get_data(bd);
-   intel_panel_set_backlight(dev, bd-props.brightness);
+   int brightness =
+   bd-props.brightness + intel_panel_min_brightness(dev);
+
+   intel_panel_set_backlight(dev, brightness);
return 0;
 }
 
@@ -406,7 +431,10 @@ static int intel_panel_get_brightness(struct 
backlight_device *bd)
 {
struct drm_device *dev = bl_get_data(bd);
struct drm_i915_private *dev_priv = dev-dev_private;
-   return dev_priv-backlight_level;
+   int brightness =
+   dev_priv-backlight_level - intel_panel_min_brightness(dev);
+
+   return brightness;
 }
 
 static const struct backlight_ops intel_panel_bl_ops = {
@@ -419,16 +447,21 @@ int intel_panel_setup_backlight(struct drm_connector 
*connector)
struct drm_device *dev = connector-dev;
struct drm_i915_private *dev_priv = dev-dev_private;
struct backlight_properties props;
+   int max_brightness;
 
intel_panel_init_backlight(dev);
 
-   memset(props, 0, sizeof(props));
-   props.type = BACKLIGHT_RAW;
-   props.max_brightness = _intel_panel_get_max_backlight(dev);
-   if (props.max_brightness == 0) {
+   max_brightness = _intel_panel_get_max_backlight(dev);
+   if (max_brightness == 0) {
DRM_DEBUG_DRIVER(Failed to get maximum backlight value\n);
return -ENODEV;
}
+
+   memset(props, 0, sizeof(props));
+   props.type = BACKLIGHT_RAW;
+   props.max_brightness =
+   max_brightness - intel_panel_min_brightness(dev);
+
dev_priv-backlight =
backlight_device_register(intel_backlight,
  connector-kdev, dev,
@@ -440,7 +473,8 @@ int intel_panel_setup_backlight(struct drm_connector 
*connector)
dev_priv-backlight = NULL;
return -ENODEV;
}
-   dev_priv-backlight-props.brightness = intel_panel_get_backlight(dev);
+   dev_priv-backlight-props.brightness = intel_panel_get_backlight(dev)
+   - intel_panel_min_brightness(dev);
return 0;
 }
 
-- 
1.8.1.4

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

Re: [PATCH 1/1] drm/i915: Allow specifying a minimum brightness level for sysfs control.

[Daniel Vetter]

On Tue, Mar 26, 2013 at 12:48:45PM +0100, Danny Baumann wrote:
 When controlling backlight devices via sysfs interface, user space
 generally assumes the minimum level (0) still providing a brightness
 that is usable by the user (probably due to the most commonly used
 backlight device, acpi_videoX, behaving exactly like that). This doesn't
 match the current behaviour of the intel_backlight control, though, as
 the value 0 means 'backlight off'.
 
 In order to make intel_backlight consistent to other backlight devices,
 introduce a module parameter that allows shifting the 0 level of the
 intel_backlight device. It's expressed in percentages of the maximum
 level. The default is 5, which provides a backlight level that is barely
 readable. Setting it to 0 restores the old behaviour.
 
 Signed-off-by: Danny Baumann dannybaum...@web.de

Thus far our assumption always was that the acpi backlight works better
than the intel native backlight. So everything only uses the intel
backlight if there's no other backlight driver by default.

So if I should merge this as a general solution for Windows 8 machines not
working properly, we first need to figure out what windows does on these
machines and either disable the acpi backlight or adapt it.

Adding more kernel options is not a viable solution for the backlight mess
imo.
-Daniel

 ---
  drivers/gpu/drm/i915/intel_panel.c | 48 
 --
  1 file changed, 41 insertions(+), 7 deletions(-)
 
 diff --git a/drivers/gpu/drm/i915/intel_panel.c 
 b/drivers/gpu/drm/i915/intel_panel.c
 index bee8cb6..5bad49d 100644
 --- a/drivers/gpu/drm/i915/intel_panel.c
 +++ b/drivers/gpu/drm/i915/intel_panel.c
 @@ -395,10 +395,35 @@ intel_panel_detect(struct drm_device *dev)
  }
  
  #ifdef CONFIG_BACKLIGHT_CLASS_DEVICE
 +
 +static int i915_panel_min_brightness_percent = 5;
 +MODULE_PARM_DESC(min_sysfs_brightness, Minimum brightness percentage 
 settable 
 + via sysfs. This adjusts the brightness level of the value '0' in the 
 + intel_backlight sysfs backlight interface.);
 +module_param_named(min_sysfs_brightness,
 +i915_panel_min_brightness_percent, int, 0400);
 +
 +static int intel_panel_min_brightness(struct drm_device *dev)
 +{
 + int max;
 +
 + if (i915_panel_min_brightness_percent = 0)
 + return 0;
 +
 + max = intel_panel_get_max_backlight(dev);
 + if (i915_panel_min_brightness_percent = 100)
 + return max;
 +
 + return max * i915_panel_min_brightness_percent / 100;
 +}
 +
  static int intel_panel_update_status(struct backlight_device *bd)
  {
   struct drm_device *dev = bl_get_data(bd);
 - intel_panel_set_backlight(dev, bd-props.brightness);
 + int brightness =
 + bd-props.brightness + intel_panel_min_brightness(dev);
 +
 + intel_panel_set_backlight(dev, brightness);
   return 0;
  }
  
 @@ -406,7 +431,10 @@ static int intel_panel_get_brightness(struct 
 backlight_device *bd)
  {
   struct drm_device *dev = bl_get_data(bd);
   struct drm_i915_private *dev_priv = dev-dev_private;
 - return dev_priv-backlight_level;
 + int brightness =
 + dev_priv-backlight_level - intel_panel_min_brightness(dev);
 +
 + return brightness;
  }
  
  static const struct backlight_ops intel_panel_bl_ops = {
 @@ -419,16 +447,21 @@ int intel_panel_setup_backlight(struct drm_connector 
 *connector)
   struct drm_device *dev = connector-dev;
   struct drm_i915_private *dev_priv = dev-dev_private;
   struct backlight_properties props;
 + int max_brightness;
  
   intel_panel_init_backlight(dev);
  
 - memset(props, 0, sizeof(props));
 - props.type = BACKLIGHT_RAW;
 - props.max_brightness = _intel_panel_get_max_backlight(dev);
 - if (props.max_brightness == 0) {
 + max_brightness = _intel_panel_get_max_backlight(dev);
 + if (max_brightness == 0) {
   DRM_DEBUG_DRIVER(Failed to get maximum backlight value\n);
   return -ENODEV;
   }
 +
 + memset(props, 0, sizeof(props));
 + props.type = BACKLIGHT_RAW;
 + props.max_brightness =
 + max_brightness - intel_panel_min_brightness(dev);
 +
   dev_priv-backlight =
   backlight_device_register(intel_backlight,
 connector-kdev, dev,
 @@ -440,7 +473,8 @@ int intel_panel_setup_backlight(struct drm_connector 
 *connector)
   dev_priv-backlight = NULL;
   return -ENODEV;
   }
 - dev_priv-backlight-props.brightness = intel_panel_get_backlight(dev);
 + dev_priv-backlight-props.brightness = intel_panel_get_backlight(dev)
 + - intel_panel_min_brightness(dev);
   return 0;
  }
  
 -- 
 1.8.1.4
 
 ___
 dri-devel mailing list
 dri-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 

Re: [PATCH 1/1] drm/i915: Allow specifying a minimum brightness level for sysfs control.

[Chris Wilson]

On Tue, Mar 26, 2013 at 04:13:13PM +0100, Daniel Vetter wrote:
 On Tue, Mar 26, 2013 at 12:48:45PM +0100, Danny Baumann wrote:
  When controlling backlight devices via sysfs interface, user space
  generally assumes the minimum level (0) still providing a brightness
  that is usable by the user (probably due to the most commonly used
  backlight device, acpi_videoX, behaving exactly like that). This doesn't
  match the current behaviour of the intel_backlight control, though, as
  the value 0 means 'backlight off'.
  
  In order to make intel_backlight consistent to other backlight devices,
  introduce a module parameter that allows shifting the 0 level of the
  intel_backlight device. It's expressed in percentages of the maximum
  level. The default is 5, which provides a backlight level that is barely
  readable. Setting it to 0 restores the old behaviour.
  
  Signed-off-by: Danny Baumann dannybaum...@web.de
 
 Thus far our assumption always was that the acpi backlight works better
 than the intel native backlight. So everything only uses the intel
 backlight if there's no other backlight driver by default.

There are machines, such as the pnv netbook on my desk, on which
intel_backlight does nothing and the only control is through
acpi_backlight0. Generalising expected behaviour based on one firmware
implementation is fraught with danger.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH] drm/i915: Add i915.dp_limit_max_lane_count driver option.

[Daniel Vetter]

On Tue, Mar 26, 2013 at 4:40 PM, Michal Srb m...@suse.com wrote:
 Since 2514bc510d0c3aadcc5204056bb440fa36845147, the intel_dp_mode_fixup
 function prefers lane count over frequency. That causes problems on
 hardware that has less working lanes than it reports. This option allows
 to workaround such hardware bugs.

 Signed-off-by: Michal Srb m...@suse.com
 ---
 This is workaround for hardware issues uncovered by this commit:

   commit 2514bc510d0c3aadcc5204056bb440fa36845147
   Author: Jesse Barnes jbar...@virtuousgeek.org
   Date:   Thu Jun 21 15:13:50 2012 -0700

   drm/i915: prefer wide  slow to fast  narrow in DP configs

   High frequency link configurations have the potential to cause trouble
   with long and/or cheap cables, so prefer slow and wide configurations
   instead.  This patch has the potential to cause trouble for eDP
   configurations that lie about available lanes, so if we run into that we
   can make it conditional on eDP.

 I have IBM POS machine (4852-570 Truman) that has internal monitor
 connected over display port. It reports to have 2 lanes, but only 1
 lane works reliably. With 2 lanes used, the monitor sometimes doesn't
 turn on. It seems that this is hardware issue specific for this model.

 From discussion that was around the 2514bc510d0c3aadcc5204056bb440fa36845147
 commit I understand there are more machines that have similar problems.
 This option can be used to solve them.

It sounds like we need to start with a DPCD quirk database ... Ajax?
-Daniel

 ---

  drivers/gpu/drm/i915/i915_drv.c |6 ++
  drivers/gpu/drm/i915/i915_drv.h |1 +
  drivers/gpu/drm/i915/intel_dp.c |   15 +--
  3 files changed, 20 insertions(+), 2 deletions(-)

 diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
 index 6c4b13c..5949d7c 100644
 --- a/drivers/gpu/drm/i915/i915_drv.c
 +++ b/drivers/gpu/drm/i915/i915_drv.c
 @@ -123,6 +123,12 @@ module_param_named(preliminary_hw_support,
 i915_preliminary_hw_support, int, 060
  MODULE_PARM_DESC(preliminary_hw_support,
 Enable preliminary hardware support. (default: false));

 +int i915_dp_limit_max_lane_count __read_mostly = -1;
 +module_param_named(dp_limit_max_lane_count, i915_dp_limit_max_lane_count,
 int, 0600);
 +MODULE_PARM_DESC(dp_limit_max_lane_count,
 +   Limit the maximal number of used display port lanes. 
 +   (default: -1 (no limit)));
 +
  static struct drm_driver driver;
  extern int intel_agp_enabled;

 diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
 index 1657d873..646e400 100644
 --- a/drivers/gpu/drm/i915/i915_drv.h
 +++ b/drivers/gpu/drm/i915/i915_drv.h
 @@ -1398,6 +1398,7 @@ extern int i915_enable_fbc __read_mostly;
  extern bool i915_enable_hangcheck __read_mostly;
  extern int i915_enable_ppgtt __read_mostly;
  extern unsigned int i915_preliminary_hw_support __read_mostly;
 +extern int i915_dp_limit_max_lane_count __read_mostly;

  extern int i915_suspend(struct drm_device *dev, pm_message_t state);
  extern int i915_resume(struct drm_device *dev);
 diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
 index 662a185..3812773 100644
 --- a/drivers/gpu/drm/i915/intel_dp.c
 +++ b/drivers/gpu/drm/i915/intel_dp.c
 @@ -132,6 +132,17 @@ intel_edp_target_clock(struct intel_encoder
 *intel_encoder,
 return mode-clock;
  }

 +static inline u8
 +intel_dp_max_lane_count(u8 dpcd[DP_RECEIVER_CAP_SIZE])
 +{
 +   u8 max_lane_count = drm_dp_max_lane_count(dpcd);
 +
 +   if(i915_dp_limit_max_lane_count != -1  max_lane_count 
 i915_dp_limit_max_lane_count)
 +   max_lane_count = i915_dp_limit_max_lane_count;
 +
 +   return max_lane_count;
 +}
 +
  static int
  intel_dp_max_link_bw(struct intel_dp *intel_dp)
  {
 @@ -184,7 +195,7 @@ intel_dp_adjust_dithering(struct intel_dp *intel_dp,
  {
 int max_link_clock =
 drm_dp_bw_code_to_link_rate(intel_dp_max_link_bw(intel_dp));
 -   int max_lanes = drm_dp_max_lane_count(intel_dp-dpcd);
 +   int max_lanes = intel_dp_max_lane_count(intel_dp-dpcd);
 int max_rate, mode_rate;

 mode_rate = intel_dp_link_required(mode-clock, 24);
 @@ -697,7 +708,7 @@ intel_dp_mode_fixup(struct drm_encoder *encoder,
 struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
 struct intel_connector *intel_connector = 
 intel_dp-attached_connector;
 int lane_count, clock;
 -   int max_lane_count = drm_dp_max_lane_count(intel_dp-dpcd);
 +   int max_lane_count = intel_dp_max_lane_count(intel_dp-dpcd);
 int max_clock = intel_dp_max_link_bw(intel_dp) == DP_LINK_BW_2_7 ? 1 
 : 0;
 int bpp, mode_rate;
 static int bws[2] = { DP_LINK_BW_1_62, DP_LINK_BW_2_7 };
 --
 1.7.7


 ___
 Intel-gfx mailing list
 intel-...@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/intel-gfx



-- 
Daniel Vetter

Re: [PATCH 0/1] drm/i915: Allow specifying a minimum brightness level for sysfs control.

[Matthew Garrett]

On Tue, Mar 26, 2013 at 06:10:30PM +0100, Danny Baumann wrote:
 Am 26.03.2013 18:02, schrieb Matthew Garrett:
 I'm not quite clear what you mean here. The behaviour of 0 isn't well
 defined for the ACPI backlight driver - it's perfectly reasonable for it
 to turn the backlight off entirely. Anything assuming that 0 is still
 visible is broken.
 
 Well, the ACPI spec says this (section B.5.2):
 
 
 The OEM may define the number 0 as Zero brightness that can mean
 to turn off the lighting (e.g. LCD panel backlight) in the device.
 This may be useful in the case of an output device that can still be
 viewed using only ambient light, for example, a transflective LCD.
 
 
 My interpretation of this is that the value 0 is supposed to still
 be visible. I'm pretty sure I saw a statement that 0 is supposed to
 mean barely visible somewhere, but can't find it at the moment.
 I'll search for the source of it.

I think that's a stretch - This may be useful isn't normative 
language, The OEM may define is. But even if we do assert it for the 
ACPI backlight, it's not true for other interfaces - zero backlight 
intensity is supposed to be screen off on Apple hardware, for instance.

-- 
Matthew Garrett | mj...@srcf.ucam.org
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/1] drm/i915: Allow specifying a minimum brightness level for sysfs control.

[Matthew Garrett]

On Tue, Mar 26, 2013 at 12:48:44PM +0100, Danny Baumann wrote:
 This patch makes the behaviour of the intel_backlight backlight device
 consistent to e.g. acpi_videoX: When writing the value 0, the set brightness
 makes the panel content barely readable instead of turning the backlight off.
 This matches the expectations of user space (e.g. kde-workspace or the Intel
 X11 driver), which expects that it can use intel_backlight as a drop-in
 replacement for acpi_videoX.

I'm not quite clear what you mean here. The behaviour of 0 isn't well 
defined for the ACPI backlight driver - it's perfectly reasonable for it 
to turn the backlight off entirely. Anything assuming that 0 is still 
visible is broken.

-- 
Matthew Garrett | mj...@srcf.ucam.org
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/1] drm/i915: Allow specifying a minimum brightness level for sysfs control.

[Danny Baumann]

Hi,


Thus far our assumption always was that the acpi backlight works better
than the intel native backlight. So everything only uses the intel
backlight if there's no other backlight driver by default.


There are machines, such as the pnv netbook on my desk, on which
intel_backlight does nothing and the only control is through
acpi_backlight0.


That's fine - but on my machine, (at least currently) it's the other way 
around. acpi_video[0|1] do nothing, while intel_backlight is the only 
method that works. This sucks (please also see my reply to Daniel), but 
it's a fact.



Generalising expected behaviour based on one firmware
implementation is fraught with danger.


I'm not sure what you mean here. I interpret the statement as 'user 
space should treat acpi_videoX and intel_backlight differently'. Is this 
interpretation correct?
If so, how is user space supposed to know how the respective backlight 
device will behave, as this behaviour might change at any point in time 
if there's no understanding in how it _should_ behave? What currently 
happens on my machine is that KDE completely turns off the backlight 
after the dim timeout, because it assumes that the value 0 will keep the 
backlight at a readable level (which would be the case if it used 
acpi_videoX because this behaviour is mandated by the spec there). I 
first thought of sending a patch to KDE, but I couldn't figure out how 
KDE is _supposed_ to correctly handle the situation, especially given 
that the actual sysfs interface used is abstracted away by Xrandr (and 
chosen by the Intel Xorg driver). With my patch, intel_backlight behaves 
in a way that roughly matches the behaviour mandated by the ACPI spec.

Do you have a way in mind that allows fixing this in user space?

Thanks,

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

Re: [PATCH 0/1] drm/i915: Allow specifying a minimum brightness level for sysfs control.

[Danny Baumann]

Hi,

Am 26.03.2013 18:02, schrieb Matthew Garrett:

On Tue, Mar 26, 2013 at 12:48:44PM +0100, Danny Baumann wrote:

This patch makes the behaviour of the intel_backlight backlight device
consistent to e.g. acpi_videoX: When writing the value 0, the set brightness
makes the panel content barely readable instead of turning the backlight off.
This matches the expectations of user space (e.g. kde-workspace or the Intel
X11 driver), which expects that it can use intel_backlight as a drop-in
replacement for acpi_videoX.


I'm not quite clear what you mean here. The behaviour of 0 isn't well
defined for the ACPI backlight driver - it's perfectly reasonable for it
to turn the backlight off entirely. Anything assuming that 0 is still
visible is broken.


Well, the ACPI spec says this (section B.5.2):


The OEM may define the number 0 as Zero brightness that can mean to 
turn off the lighting (e.g. LCD panel backlight) in the device. This may 
be useful in the case of an output device that can still be viewed using 
only ambient light, for example, a transflective LCD.



My interpretation of this is that the value 0 is supposed to still be 
visible. I'm pretty sure I saw a statement that 0 is supposed to mean 
barely visible somewhere, but can't find it at the moment. I'll search 
for the source of it.


Regards,

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

Re: [PATCH 1/1] drm/i915: Allow specifying a minimum brightness level for sysfs control.

[Danny Baumann]

Hi,


Thus far our assumption always was that the acpi backlight works better
than the intel native backlight. So everything only uses the intel
backlight if there's no other backlight driver by default.

So if I should merge this as a general solution for Windows 8 machines not
working properly, we first need to figure out what windows does on these
machines and either disable the acpi backlight or adapt it.


I fully agree to that. Making acpi_video control usable is preferable 
over using intel_backlight. As I lack the detail knowledge about the 
ACPI video stuff, I'd be great of one (or some) of you guys could look 
at the mentioned bug report ([1]) and comment on what the problem might 
be. I have added the basic needed information already and would be happy 
to provide any needed debugging info.



Adding more kernel options is not a viable solution for the backlight mess
imo.


Actually I'm fine with hardcoding the percentage as well ;) I just 
figured it might make sense to make it controllable for special-case 
uses, while still making intel_backlight usable for the 'normal' use case.


Regards,

Danny

[1] https://bugzilla.kernel.org/show_bug.cgi?id=55071
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCHv2 1/3] pci: added pcie_get_speed_cap_mask function

[Bjorn Helgaas]

On Tue, Mar 19, 2013 at 11:24 PM, Lucas Kannebley Tavares
luca...@linux.vnet.ibm.com wrote:
 Added function to gather the speed cap for a device and return a mask to
 supported speeds. The function is divided into an interface and a weak
 implementation so that architecture-specific functions can be called.

 This is the first step in moving function drm_pcie_get_speed_cap_mask
 from the drm subsystem to the pci one.

This still doesn't feel right to me.

I'm definitely not a hardware guy, but my understanding based on the
PCIe spec r3.0, sec 6.11, is that the hardware will automatically
maintain the link at the highest speed supported by both ends of the
link, unless software sets a lower Target Link Speed.  The only users
of this function are some Radeon drivers, and it looks like they only
use it because the hardware doesn't conform to this aspect of the spec
and requires device-specific tweaking.

We already have bus-max_bus_speed, which should tell you the max
speed supported by the upstream component.  Is that enough
information?  Maybe the radeon drivers could simply do something like
this:

speed = rdev-ddev-pdev-bus-max_bus_speed;
if (speed == PCI_SPEED_UNKNOWN || speed  PCIE_SPEED_5_0GT)
return;

In your original email [1], you mentioned a null pointer dereference,
presumably when reading the PCIe capability for dev-pdev-bus-self,
with self being NULL.  This only happens for a bus with no upstream
P2P bridge, i.e., self will be NULL only if pdev is on a root bus.
But we also know pdev is a PCIe device, and I think a PCIe device on a
root bus must be a Root Complex Integrated Endpoint (PCIe spec sec
1.3.2.3).  Such a device does not have a link at all, so there's no
point in fiddling with its link speed.

I don't see how a radeon device could be an integrated endpoint, but
in your hypervisor environment, maybe it isn't quite spec-compliant in
terms of its attachment.  Can you collect the output of lspci -vv?
Maybe that will make things clearer.

In any case, if a radeon device is on a root bus, I think the root bus
max_bus_speed will be PCI_SPEED_UNKNOWN, and if it's not on a root
bus, max_bus_speed should be set correctly based on the upstream PCIe
port.

Bjorn

[1] http://lkml.kernel.org/r/50819140.8030...@linux.vnet.ibm.com

 Signed-off-by: Lucas Kannebley Tavares luca...@linux.vnet.ibm.com
 ---
  drivers/pci/pci.c   |   44 
  include/linux/pci.h |6 ++
  2 files changed, 50 insertions(+), 0 deletions(-)

 diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
 index b099e00..d94ab79 100644
 --- a/drivers/pci/pci.c
 +++ b/drivers/pci/pci.c
 @@ -3931,6 +3931,50 @@ static int __init pci_setup(char *str)
  }
  early_param(pci, pci_setup);

 +int __weak pcibios_get_speed_cap_mask(struct pci_dev *dev, u32 *mask)
 +{
 +   struct pci_dev *root;
 +   u32 lnkcap, lnkcap2;
 +
 +   *mask = 0;
 +   if (!dev)
 +   return -EINVAL;
 +
 +   root = dev-bus-self;
 +
 +   /* we've been informed via and serverworks don't make the cut */
 +   if (root-vendor == PCI_VENDOR_ID_VIA ||
 +   root-vendor == PCI_VENDOR_ID_SERVERWORKS)
 +   return -EINVAL;
 +
 +   pcie_capability_read_dword(root, PCI_EXP_LNKCAP, lnkcap);
 +   pcie_capability_read_dword(root, PCI_EXP_LNKCAP2, lnkcap2);
 +
 +   if (lnkcap2) {  /* PCIe r3.0-compliant */
 +   if (lnkcap2  PCI_EXP_LNKCAP2_SLS_2_5GB)
 +   *mask |= PCIE_SPEED_25;
 +   if (lnkcap2  PCI_EXP_LNKCAP2_SLS_5_0GB)
 +   *mask |= PCIE_SPEED_50;
 +   if (lnkcap2  PCI_EXP_LNKCAP2_SLS_8_0GB)
 +   *mask |= PCIE_SPEED_80;
 +   } else {/* pre-r3.0 */
 +   if (lnkcap  PCI_EXP_LNKCAP_SLS_2_5GB)
 +   *mask |= PCIE_SPEED_25;
 +   if (lnkcap  PCI_EXP_LNKCAP_SLS_5_0GB)
 +   *mask |= (PCIE_SPEED_25 | PCIE_SPEED_50);
 +   }
 +
 +   dev_info(dev-dev, probing gen 2 caps for device %x:%x = %x/%x\n,
 +   root-vendor, root-device, lnkcap, lnkcap2);
 +   return 0;
 +}
 +
 +int pcie_get_speed_cap_mask(struct pci_dev *dev, u32 *mask)
 +{
 +   return pcibios_get_speed_cap_mask(dev, mask);
 +}
 +EXPORT_SYMBOL(pcie_get_speed_cap_mask);
 +
  EXPORT_SYMBOL(pci_reenable_device);
  EXPORT_SYMBOL(pci_enable_device_io);
  EXPORT_SYMBOL(pci_enable_device_mem);
 diff --git a/include/linux/pci.h b/include/linux/pci.h
 index 2461033a..24a2f63 100644
 --- a/include/linux/pci.h
 +++ b/include/linux/pci.h
 @@ -1861,4 +1861,10 @@ static inline struct eeh_dev 
 *pci_dev_to_eeh_dev(struct pci_dev *pdev)
   */
  struct pci_dev *pci_find_upstream_pcie_bridge(struct pci_dev *pdev);

 +#define PCIE_SPEED_25 1
 +#define PCIE_SPEED_50 2
 +#define PCIE_SPEED_80 4
 +
 +extern int pcie_get_speed_cap_mask(struct pci_dev *dev, u32 *speed_mask);
 +
  #endif /* LINUX_PCI_H */
 --
 1.7.4.4

 --
 To unsubscribe 

[PATCH] drm: fix i_mapping and f_mapping initialization in drm_open in error path

[Michal Hocko]

Hi,
the patch bellow fixes a nullptr dereference reported with OpenSUSE12.3.
I am not familiar with the area so I have no idea whether this is the
right way to go but after applying this patch the problem is not
reproducible anymore.
If the patch is correct then please mark it for stable (3.7+).

Thanks!
---
From a786a701bd6c277329e2b788fea9a69b1c3ced2e Mon Sep 17 00:00:00 2001
From: Michal Hocko mho...@suse.cz
Date: Tue, 26 Mar 2013 19:04:40 +0100
Subject: [PATCH] drm: fix i_mapping and f_mapping initialization in drm_open
 in error path

Starting with fdb40a08 (drm: set dev_mapping before calling
drm_open_helper) inode and file mappings are set to old_mapping in the
error path. old_mapping can be NULL, however, which is handled by
initializing dev_mapping to default inode-i_data. old_mapping is left
intact though so the both inode's and filep's mapping will still point
to NULL which is unexpected and can it results in crashes later one.

Marco Munderloh has reported such crashes:
 BUG: unable to handle kernel NULL pointer dereference at 0058
 IP: [81190be4] drop_pagecache_sb+0x74/0xe0
 PGD 252bc1067 PUD 253d11067 PMD 0
 Oops:  [#1] SMP
 Modules linked in: fuse af_packet xt_tcpudp xt_pkttype xt_LOG xt_limit bnep 
bluetooth ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6
ip6table_raw ipt_REJECT iptable_raw xt_CT iptable_filter ip6table_mangle 
nf_conntrack_netbios_ns nf_conntrack_broadcast nf_conntrack_ipv4 nf_defrag_ipv4 
ip_tables xt_conntrack nf_conntrack ip6table_filter ip6_tables x_tables 
cpufreq_conservative cpufreq_userspace cpufreq_powersave acpi_cpufreq 
snd_hda_codec_hdmi mperf coretemp snd_hda_codec_realtek snd_hda_intel 
snd_hda_codec snd_hwdep kvm_intel snd_pcm arc4 snd_seq snd_timer snd_seq_device 
kvm iwldvm mac80211 snd uvcvideo crc32c_intel videobuf2_core videodev 
ghash_clmulni_intel aesni_intel ablk_helper cryptd lrw videobuf2_vmalloc 
aes_x86_64 iTCO_wdt xts tpm_infineon mei r8169 videobuf2_memops 
iTCO_vendor_support sr_mod lpc_ich iwlwifi gf128mul sony_laptop rts_pstor(C) 
cdrom i2c_i801 tpm_tis tpm tpm_bios battery mfd_core soundcore snd_page_alloc 
cfg80211 rfkill ac sg microcode pcspkr autofs4 xhci_hcd ehci_hcd usbcore 
usb_common radeon i915 video ttm drm_kms_helper drm i2c_algo_bit thermal button 
processor thermal_sys scsi_dh_
 emc scsi_dh_rdac scsi_dh_hp_sw scsi_dh_alua
scsi_dh
 CPU 0
 Pid: 1452, comm: bash Tainted: G C   3.7.10-1.1-default
ation VPCSA4W9E/VAIO
 RIP: 0010:[81190be4]  [81190be4] 
drop_pagecache_sb+0x74/0xe0
 RSP: 0018:880252bc9e18  EFLAGS: 00010246
 RAX:  RBX: 88024ecb7db0 RCX: 0002
 RDX: 0007 RSI: 88024f63a670 RDI: 88024ecb7e38
 RBP: 88024ecb7e38 R08: dead00200200 R09: 
 R10: 0001 R11: 0210 R12: 880254d588a0
 R13: 88024fcb25e8 R14: 81190b70 R15: ffea
 FS:  7fad2b9ed700() GS:88025fa0() knlGS:
 CS:  0010 DS:  ES:  CR0: 80050033
 CR2: 0058 CR3: 000252ad2000 CR4: 000407f0
 DR0:  DR1:  DR2: 
 DR3:  DR6: 0ff0 DR7: 0400
 Process bash (pid: 1452, threadinfo 880252bc8000, task 880253d321c0)
 Stack:
  0001 880254d58800 880254e94800 880254d58868
   8116a499  0001
  81a228a0 880252bc9f50 0002 81190cce
 Call Trace:
  [8116a499] iterate_supers+0xd9/0xe0
  [81190cce] drop_caches_sysctl_handler+0x7e/0x90
  [811d0e26] proc_sys_call_handler.isra.10+0xc6/0xe0
  [81166fd7] vfs_write+0xa7/0x180
  [81167321] sys_write+0x51/0xa0
  [8154f2ed] system_call_fastpath+0x1a/0x1f
  [7fad2ae959c0] 0x7fad2ae959bf
 Code: 01 00 00 49 39 c4 48 8d 98 00 ff ff ff 74 68 48 8d ab 88 00 00 00 48 89 
ef e8 49 69 3b 00 f6 83 a0 00 00 00 38 75 d0 48 8b 43 30 48 83 78 58 00 74 c5 
48 89 df e8 dd ef fe ff 66 83 45 00 01 66
 RIP  [81190be4] drop_pagecache_sb+0x74/0xe0
  RSP 880252bc9e18
 CR2: 0058

when dropping caches when inode with NULL i_mapping is encountered. Or a
different one when umounting devtmpfs:
 BUG: unable to handle kernel NULL pointer dereference at 0068
 IP: [81122001] shmem_evict_inode+0x11/0x130
 PGD 0
 Oops:  [#1] SMP
 Modules linked in: xt_tcpudp xt_pkttype xt_LOG xt_limit af_packet ip6t_REJECT 
nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_raw ipt_REJECT iptable_raw xt_CT 
iptable_filter ip6table_mangle nf_conntrack_netbios_ns nf_conntrack_broadcast 
nf_conntrack_ipv4 nf_defrag_ipv4 ip_tables xt_conntrack nf_conntrack bnep 
bluetooth ip6table_filter ip6_tables cpufreq_conservative x_tables 
cpufreq_userspace cpufreq_powersave snd_hda_codec_hdmi snd_hda_codec_realtek 
acpi_cpufreq snd_hda_intel mperf snd_hda_codec coretemp snd_hwdep kvm_intel 

Re: [Nouveau] [PATCH] drm/nouveau: Ack interrupts for some fuc engines

[Marcin Slusarz]

On Tue, Mar 26, 2013 at 07:29:24AM +0100, Maarten Lankhorst wrote:
 Op 25-03-13 19:14, Marcin Slusarz schreef:
  On Mon, Mar 25, 2013 at 10:22:37AM +0100, Maarten Lankhorst wrote:
  Fixes 100% cpu usage when the exit interrupt never got acked.
 
  Signed-off-by: Maarten Lankhorst m.b.lankho...@gmail.com
  ---
  diff --git a/drivers/gpu/drm/nouveau/core/core/falcon.c 
  b/drivers/gpu/drm/nouveau/core/core/falcon.c
  index e05c157..b11c5f3 100644
  --- a/drivers/gpu/drm/nouveau/core/core/falcon.c
  +++ b/drivers/gpu/drm/nouveau/core/core/falcon.c
  @@ -229,6 +229,24 @@ _nouveau_falcon_fini(struct nouveau_object *object, 
  bool suspend)
 return nouveau_engine_fini(falcon-base, suspend);
   }
   
  +void
  +nouveau_falcon_intr(struct nouveau_subdev *subdev)
  +{
  +  struct nouveau_falcon *falcon = (void*)subdev;
  +  u32 intr = nv_ro32(falcon, 0x008);
  +
  +  nv_wo32(falcon, 0x004, intr);
  +
  +  if (intr  0x10) {
  +  intr = ~0x10;
  +
  +  nv_info(falcon, Exit interrupt called\n);
  Do you really want to print it at info level? How frequent it is?
 It shouldn't be often, I want it to run at the error level since that usually
 means the firmware exited prematurely/crashed and things go bad, but it
 happens with the secret scrubber finishing on initialization too. That one
 is harmless though.

Maybe it should say:
nv_error(falcon, firmware exited prematurely\n);
?

  +  }
  +
  +  if (intr)
  +  nv_error(falcon, Unhandled interrupt %08x\n, intr);
  +}
  +
   int
   nouveau_falcon_create_(struct nouveau_object *parent,
struct nouveau_object *engine,
  ___
  dri-devel mailing list
  dri-devel@lists.freedesktop.org
  http://lists.freedesktop.org/mailman/listinfo/dri-devel
 
 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/2] dma-buf: Add debugfs support

[Laurent Pinchart]

Hi Sumit,

Thanks for the patch.

On Monday 25 March 2013 16:50:46 Sumit Semwal wrote:
 Add debugfs support to make it easier to print debug information
 about the dma-buf buffers.
 
 Cc: Dave Airlie airl...@redhat.com
  [minor fixes on init and warning fix]
 Signed-off-by: Sumit Semwal sumit.sem...@linaro.org
 ---
 changes since v1:
  - fixes on init and warnings as reported and corrected by Dave Airlie.
  - add locking while walking attachment list - reported by Daniel Vetter.
 
  drivers/base/dma-buf.c  |  162 
  include/linux/dma-buf.h |5 +-
  2 files changed, 166 insertions(+), 1 deletion(-)
 
 diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
 index d89102a..7d867ed 100644
 --- a/drivers/base/dma-buf.c
 +++ b/drivers/base/dma-buf.c
 @@ -27,9 +27,18 @@
  #include linux/dma-buf.h
  #include linux/anon_inodes.h
  #include linux/export.h
 +#include linux/debugfs.h
 +#include linux/seq_file.h
 
  static inline int is_dma_buf_file(struct file *);
 
 +struct dma_buf_list {
 + struct list_head head;
 + struct mutex lock;
 +};
 +
 +static struct dma_buf_list db_list;
 +
  static int dma_buf_release(struct inode *inode, struct file *file)
  {
   struct dma_buf *dmabuf;
 @@ -42,6 +51,11 @@ static int dma_buf_release(struct inode *inode, struct
 file *file) BUG_ON(dmabuf-vmapping_counter);
 
   dmabuf-ops-release(dmabuf);
 +
 + mutex_lock(db_list.lock);
 + list_del(dmabuf-list_node);
 + mutex_unlock(db_list.lock);
 +
   kfree(dmabuf);
   return 0;
  }
 @@ -125,6 +139,10 @@ struct dma_buf *dma_buf_export_named(void *priv, const
 struct dma_buf_ops *ops, mutex_init(dmabuf-lock);
   INIT_LIST_HEAD(dmabuf-attachments);
 
 + mutex_lock(db_list.lock);
 + list_add(dmabuf-list_node, db_list.head);
 + mutex_unlock(db_list.lock);
 +
   return dmabuf;
  }
  EXPORT_SYMBOL_GPL(dma_buf_export_named);
 @@ -551,3 +569,147 @@ void dma_buf_vunmap(struct dma_buf *dmabuf, void
 *vaddr) mutex_unlock(dmabuf-lock);
  }
  EXPORT_SYMBOL_GPL(dma_buf_vunmap);
 +
 +static int dma_buf_init_debugfs(void);
 +static void dma_buf_uninit_debugfs(void);
 +
 +static int __init dma_buf_init(void)
 +{
 + mutex_init(db_list.lock);
 + INIT_LIST_HEAD(db_list.head);
 + dma_buf_init_debugfs();
 + return 0;
 +}
 +
 +subsys_initcall(dma_buf_init);
 +
 +static void __exit dma_buf_deinit(void)

This function is never called.

 +{
 + dma_buf_uninit_debugfs();
 +}

If you moved those two functions at the end of the file you could get rid of 
the forward declarations above.

 +
 +#ifdef CONFIG_DEBUG_FS
 +static int dma_buf_describe(struct seq_file *s)
 +{
 + int ret;
 + struct dma_buf *buf_obj;
 + struct dma_buf_attachment *attach_obj;
 + int count = 0, attach_count;
 + size_t size = 0;
 +
 + ret = mutex_lock_interruptible(db_list.lock);
 +
 + if (ret)
 + return ret;
 +
 + seq_printf(s, \nDma-buf Objects:\n);
 + seq_printf(s, \texp_name\tsize\tflags\tmode\tcount\n);
 +
 + list_for_each_entry(buf_obj, db_list.head, list_node) {
 + ret = mutex_lock_interruptible(buf_obj-lock);
 +
 + if (ret) {
 + seq_printf(s,
 +   \tERROR locking buffer object: skipping\n);
 + goto skip_buffer;
 + }
 +
 + seq_printf(s, \t);
 +
 + seq_printf(s, \t%s\t%08zu\t%08x\t%08x\t%08d\n,
 + buf_obj-exp_name, buf_obj-size,
 + buf_obj-file-f_flags, buf_obj-file-f_mode,
 + buf_obj-file-f_count.counter);
 +
 + seq_printf(s, \t\tAttached Devices:\n);
 + attach_count = 0;
 +
 + list_for_each_entry(attach_obj, buf_obj-attachments, node) {
 + seq_printf(s, \t\t);
 +
 + seq_printf(s, %s\n, attach_obj-dev-init_name);
 + attach_count++;
 + }
 +
 + seq_printf(s, \n\t\tTotal %d devices attached\n,
 + attach_count);
 +
 + count++;
 + size += buf_obj-size;
 +skip_buffer:
 + mutex_unlock(buf_obj-lock);
 + }
 +
 + seq_printf(s, \nTotal %d objects, %zu bytes\n, count, size);
 +
 + mutex_unlock(db_list.lock);
 + return 0;
 +}
 +
 +static int dma_buf_show(struct seq_file *s, void *unused)
 +{
 + void (*func)(struct seq_file *) = s-private;
 + func(s);
 + return 0;
 +}
 +
 +static int dma_buf_debug_open(struct inode *inode, struct file *file)
 +{
 + return single_open(file, dma_buf_show, inode-i_private);
 +}
 +
 +static const struct file_operations dma_buf_debug_fops = {
 + .open   = dma_buf_debug_open,
 + .read   = seq_read,
 + .llseek = seq_lseek,
 + .release= single_release,
 +};
 +
 +static struct dentry *dma_buf_debugfs_dir;
 +
 +static int