Re: [Intel-gfx] [PATCH] [RFC] mm/shrinker: Add a shrinker flag to always shrink a bit
On 19.09.2013 08:57, Daniel Vetter wrote:
On Wed, Sep 18, 2013 at 10:38 PM, Dave Chinner wrote:
No, that's wrong. ->count_objects should never ass SHRINK_STOP.
Indeed, it should always return a count of objects in the cache,
regardless of the context.
SHRINK_STOP is for ->scan_objects to tell the shrinker it can make
any progress due to the context it is called in. This allows the
shirnker to defer the work to another call in a different context.
However, if ->count-objects doesn't return a count, the work that
was supposed to be done cannot be deferred, and that is what
->count_objects should always return the number of objects in the
cache.
So we should rework the locking in the drm/i915 shrinker to be able to
always count objects? Thus far no one screamed yet that we're not
really able to do that in all call contexts ...
If this would have been a problem in the past, it probably would
have been ended up as one of those unresolved random glitches ...
So should I revert 81e49f or will the early return 0; completely upset
the core shrinker logic?
After Daves answer and a look at all other uses of SHRINK_STOP in the current
kernel sources it is clear that 81e49f must be reverted.
Wherever else SHRINK_STOP is returned, it ends up in ->scan_objects.
So i915_gem_inactive_scan() and not i915_gem_inactive_count()
should return that value in case of a failed trylock:
i915_gem_inactive_scan(struct shrinker *shrinker, struct shrink_control *sc)
{
struct drm_i915_private *dev_priv =
container_of(shrinker,
struct drm_i915_private,
mm.inactive_shrinker);
struct drm_device *dev = dev_priv->dev;
int nr_to_scan = sc->nr_to_scan;
unsigned long freed;
bool unlock = true;
if (!mutex_trylock(&dev->struct_mutex)) {
if (!mutex_is_locked_by(&dev->struct_mutex, current))
-return 0;
+return SHRINK_STOP;
if (dev_priv->mm.shrinker_no_lock_stealing)
-return 0;
+return SHRINK_STOP;
unlock = false;
}
atm a kernel with 81e49f reverted,
i915_gem_inactive_scan() changed as described above,
and i915_gem_inactive_count() always counting _without_ any locking
seems to work fine here. Is locking really needed at that place?
cu,
Knut
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] drm-intel-fixes
Hi Dave, Looks like I'm just a bit late with my -fixes pull request. Some more dealock fixes around pageflips and gpu hangs, fixes for hsw hangs when doing modesets/dpms. And a few minor things to rectify issues with our modeset state tracking which the checker spotted. Nothing yet for the vgaarb fun (can I just wish that one away?) and we seem to have some minor fun with the new shrinker stuff - still discussing that with Dave Chinner. Cheers, Daniel The following changes since commit 6e1b4fdad5157bb9e88777d525704aba24389bee: drm/i915: Delay disabling of VGA memory until vgacon->fbcon handoff is done (2013-09-06 23:27:03 +0200) are available in the git repository at: git://people.freedesktop.org/~danvet/drm-intel tags/drm-intel-fixes-2013-09-19 for you to fetch changes up to f2f5f771c5fc0fa252cde3d0d0452dcc785cc17a: drm/i915: Don't enable the cursor on a disable pipe (2013-09-18 10:00:30 +0200) Chris Wilson (1): drm/i915: Track pfit enable state separately from size Daniel Vetter (5): drm/i915: fix wait_for_pending_flips vs gpu hang deadlock drm/i915/sdvo: Fully translate sync flags in the dtd->mode conversion drm/i915/sdvo: Robustify the dtd<->drm_mode conversions drm/i915/dvo: set crtc timings again for panel fixed modes drm/i915: kill set_need_resched Jani Nikula (1): drm/i915: do not update cursor in crtc mode set Takashi Iwai (1): drm/i915: Use proper print format for debug prints Ville Syrjälä (1): drm/i915: Don't enable the cursor on a disable pipe drivers/gpu/drm/i915/i915_gem.c | 11 +++--- drivers/gpu/drm/i915/i915_irq.c | 68 drivers/gpu/drm/i915/intel_ddi.c | 2 +- drivers/gpu/drm/i915/intel_display.c | 42 +++--- drivers/gpu/drm/i915/intel_drv.h | 1 + drivers/gpu/drm/i915/intel_dvo.c | 2 ++ drivers/gpu/drm/i915/intel_panel.c | 1 + drivers/gpu/drm/i915/intel_pm.c | 6 ++-- drivers/gpu/drm/i915/intel_sdvo.c| 63 +++-- 9 files changed, 122 insertions(+), 74 deletions(-) -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm: omap: fix: Defer probe if an omapdss device requests for it at connect
Some omapdss panels are connected to outputs/encoders(HDMI/DSI/DPI) that require
regulators. The output's connect op tries to get a regulator which may not exist
yet because it might get registered later in the kernel boot.
omapdrm currently ignores those panels which return a non zero value when
connected. A better approach would be for omapdrm to request for probe
deferral if a panel's connect op returns -EPROBE_DEFER.
The connecting of panels is moved very early in the the drm device's probe
before anything else is initialized. When we enter omap_modeset_init(), we have
a set of panels that have been connected. We now proceed with registering only
those panels which are already connected.
Checking whether the panel has a driver or whether it has get_timing/read_edid
ops in omap_modeset_init() are redundant with the new display model. These can
be removed since a dssdev device will always have a driver associated with it,
and all dssdev drivers have a get_timings op.
This fixes boot with omapdrm on an omap4 panda ES board. The regulators used by
HDMI aren't initialized because I2c isn't initialized, I2C isn't initialized
as it's pins are not configured because pinctrl is yet to probe.
Signed-off-by: Archit Taneja
---
drivers/gpu/drm/omapdrm/omap_crtc.c | 5 +++
drivers/gpu/drm/omapdrm/omap_drv.c | 64 -
drivers/gpu/drm/omapdrm/omap_drv.h | 1 +
3 files changed, 48 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c
b/drivers/gpu/drm/omapdrm/omap_crtc.c
index 0fd2eb1..9c01311 100644
--- a/drivers/gpu/drm/omapdrm/omap_crtc.c
+++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
@@ -623,6 +623,11 @@ void omap_crtc_pre_init(void)
dss_install_mgr_ops(&mgr_ops);
}
+void omap_crtc_pre_uninit(void)
+{
+ dss_uninstall_mgr_ops();
+}
+
/* initialize crtc */
struct drm_crtc *omap_crtc_init(struct drm_device *dev,
struct drm_plane *plane, enum omap_channel channel, int id)
diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c
b/drivers/gpu/drm/omapdrm/omap_drv.c
index 2603d90..45fbb1c 100644
--- a/drivers/gpu/drm/omapdrm/omap_drv.c
+++ b/drivers/gpu/drm/omapdrm/omap_drv.c
@@ -87,6 +87,37 @@ static bool channel_used(struct drm_device *dev, enum
omap_channel channel)
return false;
}
+static int omap_connect_dssdevs(void)
+{
+ int r;
+ struct omap_dss_device *dssdev = NULL;
+
+ for_each_dss_dev(dssdev) {
+ r = dssdev->driver->connect(dssdev);
+ if (r == -EPROBE_DEFER) {
+ omap_dss_put_device(dssdev);
+ goto cleanup;
+ } else if (r) {
+ dev_warn(dssdev->dev, "could not connect display: %s\n",
+ dssdev->name);
+ }
+ }
+
+ return 0;
+
+cleanup:
+ /*
+* if we are deferring probe, we disconnect the devices we previously
+* connected
+*/
+ dssdev = NULL;
+
+ for_each_dss_dev(dssdev)
+ dssdev->driver->disconnect(dssdev);
+
+ return r;
+}
+
static int omap_modeset_init(struct drm_device *dev)
{
struct omap_drm_private *priv = dev->dev_private;
@@ -95,9 +126,6 @@ static int omap_modeset_init(struct drm_device *dev)
int num_mgrs = dss_feat_get_num_mgrs();
int num_crtcs;
int i, id = 0;
- int r;
-
- omap_crtc_pre_init();
drm_mode_config_init(dev);
@@ -119,26 +147,8 @@ static int omap_modeset_init(struct drm_device *dev)
enum omap_channel channel;
struct omap_overlay_manager *mgr;
- if (!dssdev->driver) {
- dev_warn(dev->dev, "%s has no driver.. skipping it\n",
- dssdev->name);
- continue;
- }
-
- if (!(dssdev->driver->get_timings ||
- dssdev->driver->read_edid)) {
- dev_warn(dev->dev, "%s driver does not support "
- "get_timings or read_edid.. skipping it!\n",
- dssdev->name);
+ if (!omapdss_device_is_connected(dssdev))
continue;
- }
-
- r = dssdev->driver->connect(dssdev);
- if (r) {
- dev_err(dev->dev, "could not connect display: %s\n",
- dssdev->name);
- continue;
- }
encoder = omap_encoder_init(dev, dssdev);
@@ -656,9 +666,19 @@ static void pdev_shutdown(struct platform_device *device)
static int pdev_probe(struct platform_device *device)
{
+ int r;
+
if (omapdss_is_initialized() == false)
return -EPROBE_DEFER;
+ omap_crtc_pre_init();
+
+ r = omap_connect_dssdevs();
+ if (r) {
+ omap_crtc_pre_un
[PATCH 2/2] drm: omap: disconnect devices when omapdrm module is removed
omapdrm established connections for omap_dss_device devices when probed. It
should also be responsible to disconnect the devices. Keeping the devices
connected can prevent the panel driver modules from unloading, it can also
cause problems when omapdrm is re-inserted.
Signed-off-by: Archit Taneja
---
drivers/gpu/drm/omapdrm/omap_drv.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c
b/drivers/gpu/drm/omapdrm/omap_drv.c
index 45fbb1c..44a1203 100644
--- a/drivers/gpu/drm/omapdrm/omap_drv.c
+++ b/drivers/gpu/drm/omapdrm/omap_drv.c
@@ -86,6 +86,13 @@ static bool channel_used(struct drm_device *dev, enum
omap_channel channel)
return false;
}
+static void omap_disconnect_dssdevs(void)
+{
+ struct omap_dss_device *dssdev = NULL;
+
+ for_each_dss_dev(dssdev)
+ dssdev->driver->disconnect(dssdev);
+}
static int omap_connect_dssdevs(void)
{
@@ -110,10 +117,7 @@ cleanup:
* if we are deferring probe, we disconnect the devices we previously
* connected
*/
- dssdev = NULL;
-
- for_each_dss_dev(dssdev)
- dssdev->driver->disconnect(dssdev);
+ omap_disconnect_dssdevs();
return r;
}
@@ -688,6 +692,8 @@ static int pdev_remove(struct platform_device *device)
DBG("");
drm_platform_exit(&omap_drm_driver, device);
+ omap_disconnect_dssdevs();
+
platform_driver_unregister(&omap_dmm_driver);
return 0;
}
--
1.8.1.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] [RFC] mm/shrinker: Add a shrinker flag to always shrink a bit
On Wed, Sep 18, 2013 at 12:38:23PM +0200, Knut Petersen wrote: > On 18.09.2013 11:10, Daniel Vetter wrote: > > Just now I prepared a patch changing the same function in vmscan.c > >Also, this needs to be rebased to the new shrinker api in 3.12, I > >simply haven't rolled my trees forward yet. > > Well, you should. Since commit 81e49f shrinker->count_objects might be > set to SHRINK_STOP, causing shrink_slab_node() to complain loud and often: > > [ 1908.234595] shrink_slab: i915_gem_inactive_scan+0x0/0x9c negative objects > to delete nr=-x > > The kernel emitted a few thousand log lines like the one quoted above during > the > last few days on my system. > > >diff --git a/mm/vmscan.c b/mm/vmscan.c > >index 2cff0d4..d81f6e0 100644 > >--- a/mm/vmscan.c > >+++ b/mm/vmscan.c > >@@ -254,6 +254,10 @@ unsigned long shrink_slab(struct shrink_control *shrink, > > total_scan = max_pass; > > } > >+/* Always try to shrink a bit to make forward progress. */ > >+if (shrinker->evicts_to_page_lru) > >+total_scan = max_t(long, total_scan, batch_size); > >+ > At that place the error message is already emitted. > > /* > > * We need to avoid excessive windup on filesystem shrinkers > > * due to large numbers of GFP_NOFS allocations causing the > > Have a look at the attached patch. It fixes my problem with the > erroneous/misleading > error messages, and I think it´s right to just bail out early if SHRINK_STOP > is found. > > Do you agree ? No, that's wrong. ->count_objects should never ass SHRINK_STOP. Indeed, it should always return a count of objects in the cache, regardless of the context. SHRINK_STOP is for ->scan_objects to tell the shrinker it can make any progress due to the context it is called in. This allows the shirnker to defer the work to another call in a different context. However, if ->count-objects doesn't return a count, the work that was supposed to be done cannot be deferred, and that is what ->count_objects should always return the number of objects in the cache. Cheers, Dave. -- Dave Chinner da...@fromorbit.com ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] [RFC] mm/shrinker: Add a shrinker flag to always shrink a bit
[my keyboard my be on the fritz - it's not typing what I'm thinking...] On Thu, Sep 19, 2013 at 06:38:22AM +1000, Dave Chinner wrote: > On Wed, Sep 18, 2013 at 12:38:23PM +0200, Knut Petersen wrote: > > On 18.09.2013 11:10, Daniel Vetter wrote: > > > > Just now I prepared a patch changing the same function in vmscan.c > > >Also, this needs to be rebased to the new shrinker api in 3.12, I > > >simply haven't rolled my trees forward yet. > > > > Well, you should. Since commit 81e49f shrinker->count_objects might be > > set to SHRINK_STOP, causing shrink_slab_node() to complain loud and often: > > > > [ 1908.234595] shrink_slab: i915_gem_inactive_scan+0x0/0x9c negative > > objects to delete nr=-x > > > > The kernel emitted a few thousand log lines like the one quoted above > > during the > > last few days on my system. > > > > >diff --git a/mm/vmscan.c b/mm/vmscan.c > > >index 2cff0d4..d81f6e0 100644 > > >--- a/mm/vmscan.c > > >+++ b/mm/vmscan.c > > >@@ -254,6 +254,10 @@ unsigned long shrink_slab(struct shrink_control > > >*shrink, > > > total_scan = max_pass; > > > } > > >+ /* Always try to shrink a bit to make forward progress. */ > > >+ if (shrinker->evicts_to_page_lru) > > >+ total_scan = max_t(long, total_scan, batch_size); > > >+ > > At that place the error message is already emitted. > > > /* > > >* We need to avoid excessive windup on filesystem shrinkers > > >* due to large numbers of GFP_NOFS allocations causing the > > > > Have a look at the attached patch. It fixes my problem with the > > erroneous/misleading > > error messages, and I think it´s right to just bail out early if > > SHRINK_STOP is found. > > > > Do you agree ? > > No, that's wrong. ->count_objects should never ass SHRINK_STOP. *pass > Indeed, it should always return a count of objects in the cache, > regardless of the context. > > SHRINK_STOP is for ->scan_objects to tell the shrinker it can make *can't > any progress due to the context it is called in. This allows the > shirnker to defer the work to another call in a different context. > However, if ->count-objects doesn't return a count, the work that > was supposed to be done cannot be deferred, and that is what *why > ->count_objects should always return the number of objects in the > cache. Cheers, Dave. -- Dave Chinner da...@fromorbit.com ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/1] drm/exynos: Fix trivial typo in exynos_drm_fimd.c
Fixed a trivial typo. Signed-off-by: Sachin Kamat --- drivers/gpu/drm/exynos/exynos_drm_fimd.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c b/drivers/gpu/drm/exynos/exynos_drm_fimd.c index 868a14d..5d5b97d 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c @@ -31,7 +31,7 @@ #include "exynos_drm_iommu.h" /* - * FIMD is stand for Fully Interactive Mobile Display and + * FIMD stands for Fully Interactive Mobile Display and * as a display controller, it transfers contents drawn on memory * to a LCD Panel through Display Interfaces such as RGB or * CPU Interface. -- 1.7.9.5 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [drm/exynos-fimd] Display regression in v3.12-rc1
Hi Andrzej,
Thanks for your quick response.
Removing display-timings::clock-frequency property from
arch/arm/boot/dts/exynos4210-origen.dts
fixed this issue. However, I also had to remove the same from
drivers/video/of_display_timing.c as
shown below, else probe fails. I will send a patch to fix the Origen
dts file. Thanks for your help.
8<---
diff --git a/drivers/video/of_display_timing.c
b/drivers/video/of_display_timing.c
index 171821d..4e991e1 100644
--- a/drivers/video/of_display_timing.c
+++ b/drivers/video/of_display_timing.c
@@ -72,7 +72,6 @@ static int of_parse_display_timing(const struct
device_node *np,
ret |= parse_timing_property(np, "vfront-porch", &dt->vfront_porch);
ret |= parse_timing_property(np, "vactive", &dt->vactive);
ret |= parse_timing_property(np, "vsync-len", &dt->vsync_len);
- ret |= parse_timing_property(np, "clock-frequency", &dt->pixelclock);
dt->flags = 0;
--
With warm regards,
Sachin
On 18 September 2013 12:18, Andrzej Hajda wrote:
> Hi Sachin,
>
> Could you test it with removed display-timings::clock-frequency property.
> Currently in arch/arm/boot/dts/exynos4210-origen.dts
> display-timings::clock-frequency is set to 5,
> this is incorrect value. With the property removed fimd calculates
> clock-frequency from other properties with assumption of default
> 60Hz refresh rate.
>
> It could work before because of_get_fb_videomode calculated refresh rate
> from display-timings and with clock 5, the result was 0(due to
> rounding down in some division),
> so fimd assumed he should use default refresh rate of 60Hz.
>
> Regards
> Andrzej
>
> On 09/18/2013 07:22 AM, Sachin Kamat wrote:
>> Hi Andrzej ,
>>
>> I was testing the latest Linux kernel release (v3.12-rc1) on
>> Exynos4210 based Origen board.
>> I found a display regression with that. I do not get any display on
>> the LCD (other than backlight) with the latest kernel. Git bisect
>> pointed me to the following commit:
>> 111e6055d4e0d35c6a4b6cd37d7bb00a88eaffb4 ("drm/exynos: fimd: replace
>> struct fb_videomode with videomode"). Reverting this patch does not
>> cause the issue. Let me know if you need any other info to help
>> identify the problem.
>>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [drm/exynos-fimd] Display regression in v3.12-rc1
Hi,
You can just set this property to zero.
of_parse_display_timing will not complain and
you will have default settings.
Regards
Andrzej
On 09/18/2013 10:15 AM, Sachin Kamat wrote:
> Hi Andrzej,
>
> Thanks for your quick response.
> Removing display-timings::clock-frequency property from
> arch/arm/boot/dts/exynos4210-origen.dts
> fixed this issue. However, I also had to remove the same from
> drivers/video/of_display_timing.c as
> shown below, else probe fails. I will send a patch to fix the Origen
> dts file. Thanks for your help.
>
> 8<---
> diff --git a/drivers/video/of_display_timing.c
> b/drivers/video/of_display_timing.c
> index 171821d..4e991e1 100644
> --- a/drivers/video/of_display_timing.c
> +++ b/drivers/video/of_display_timing.c
> @@ -72,7 +72,6 @@ static int of_parse_display_timing(const struct
> device_node *np,
> ret |= parse_timing_property(np, "vfront-porch", &dt->vfront_porch);
> ret |= parse_timing_property(np, "vactive", &dt->vactive);
> ret |= parse_timing_property(np, "vsync-len", &dt->vsync_len);
> - ret |= parse_timing_property(np, "clock-frequency", &dt->pixelclock);
>
> dt->flags = 0;
>
> --
> With warm regards,
> Sachin
>
> On 18 September 2013 12:18, Andrzej Hajda wrote:
>> Hi Sachin,
>>
>> Could you test it with removed display-timings::clock-frequency property.
>> Currently in arch/arm/boot/dts/exynos4210-origen.dts
>> display-timings::clock-frequency is set to 5,
>> this is incorrect value. With the property removed fimd calculates
>> clock-frequency from other properties with assumption of default
>> 60Hz refresh rate.
>>
>> It could work before because of_get_fb_videomode calculated refresh rate
>> from display-timings and with clock 5, the result was 0(due to
>> rounding down in some division),
>> so fimd assumed he should use default refresh rate of 60Hz.
>>
>> Regards
>> Andrzej
>>
>> On 09/18/2013 07:22 AM, Sachin Kamat wrote:
>>> Hi Andrzej ,
>>>
>>> I was testing the latest Linux kernel release (v3.12-rc1) on
>>> Exynos4210 based Origen board.
>>> I found a display regression with that. I do not get any display on
>>> the LCD (other than backlight) with the latest kernel. Git bisect
>>> pointed me to the following commit:
>>> 111e6055d4e0d35c6a4b6cd37d7bb00a88eaffb4 ("drm/exynos: fimd: replace
>>> struct fb_videomode with videomode"). Reverting this patch does not
>>> cause the issue. Let me know if you need any other info to help
>>> identify the problem.
>>>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH/RFC v3 08/19] video: display: Add MIPI DBI bus support
Hi Laurent,
On 6 September 2013 20:07, Laurent Pinchart
wrote:
> Hi Vikas,
>
> On Wednesday 04 September 2013 16:20:59 Vikas Sajjan wrote:
>> On 9 August 2013 22:44, Laurent Pinchart wrote:
>> > MIPI DBI is a configurable-width parallel display bus that transmits
>> > commands and data.
>> >
>> > Add a new DBI Linux bus type that implements the usual bus
>> > infrastructure (including devices and drivers (un)registration and
>> > matching, and bus configuration and access functions).
>> >
>> > Signed-off-by: Laurent Pinchart
>> > ---
>> >
>> > drivers/video/display/Kconfig| 8 ++
>> > drivers/video/display/Makefile | 1 +
>> > drivers/video/display/mipi-dbi-bus.c | 234 ++
>> > include/video/display.h | 4 +
>> > include/video/mipi-dbi-bus.h | 125 +++
>> > 5 files changed, 372 insertions(+)
>> > create mode 100644 drivers/video/display/mipi-dbi-bus.c
>> > create mode 100644 include/video/mipi-dbi-bus.h
>
> [snip]
>
>> > diff --git a/drivers/video/display/mipi-dbi-bus.c
>> > b/drivers/video/display/mipi-dbi-bus.c new file mode 100644
>> > index 000..791fb4d
>> > --- /dev/null
>> > +++ b/drivers/video/display/mipi-dbi-bus.c
>
> [snip]
>
>> > +/* --
>> > + * Device and driver (un)registration
>> > + */
>> > +
>> > +/**
>> > + * mipi_dbi_device_register - register a DBI device
>> > + * @dev: DBI device we're registering
>> > + */
>> > +int mipi_dbi_device_register(struct mipi_dbi_device *dev,
>> > + struct mipi_dbi_bus *bus)
>> > +{
>> > + device_initialize(&dev->dev);
>> > +
>> > + dev->bus = bus;
>> > + dev->dev.bus = &mipi_dbi_bus_type;
>> > + dev->dev.parent = bus->dev;
>> > +
>> > + if (dev->id != -1)
>> > + dev_set_name(&dev->dev, "%s.%d", dev->name, dev->id);
>> > + else
>> > + dev_set_name(&dev->dev, "%s", dev->name);
>> > +
>> > + return device_add(&dev->dev);
>> > +}
>>
>> The function looks very much specific to NON-DT case where you will be
>> calling mipi_dbi_device_register() in the machine file.
>
> You're absolutely right.
>
>> I was actually trying to migrate to CDFv3 and adding MIPI DSI support
>> for exynos5250,
>> but in my case where exynos5250 is fully DT based, in which case we
>> need something like ./drivers/of/platform.c for MIPI DBI and MIPI DSI
>> to add the MIPI DBI/DSI device via DT way, ./drivers/of/mipi_dbi.c and
>> ./drivers/of/mipi_dsi.c
>>
>> may look like below,
>>
>> int of_mipi_dbi_device_register(struct device_node *np,
>> const char *bus_id,
>> struct device *parent)
>> {
>> struct mipi_dbi_device *dev;
>> dev = of_device_alloc(np, bus_id, parent);
>>
>> if (!dev)
>> return NULL;
>>device_initialize(dev);
>>
>>dev->bus = &mipi_dbi_bus_type;
>>dev->parent = parent;
>>
>>return of_device_add(dev);
>> }
>>
>> Correct me if I am wrong.
>
> You're correct, but the implementation will need to be a little bit more
> complex than that. From an API point of view, something like
> of_i2c_register_devices() (drivers/of/of_i2c.c) would probably make sense. the
> function should iterate over child nodes, and call
> of_mipi_dbi_device_register() (we could maybe rename that to
> of_mipi_dbi_device_create() to mimic the platform device code) for each child.
>
> In your above code, you should replace of_device_alloc() with
> of_mipi_dbi_device_alloc(), as of_device_alloc() allocates a struct
> platform_device. You should also call mipi_dsi_device_put() on the device if
> of_device_add() returns a failure.
>
> Would you like to send a patch on top of 08/19 to implement this ?
>
Sure, will send the patch to add MIPI DBI/DSI device via DT way.
>> > +EXPORT_SYMBOL_GPL(mipi_dbi_device_register);
>> > +
>> > +/**
>> > + * mipi_dbi_device_unregister - unregister a DBI device
>> > + * @dev: DBI device we're unregistering
>> > + */
>> > +void mipi_dbi_device_unregister(struct mipi_dbi_device *dev)
>> > +{
>> > + device_del(&dev->dev);
>> > + put_device(&dev->dev);
>> > +}
>> > +EXPORT_SYMBOL_GPL(mipi_dbi_device_unregister);
>> > +
>> > +static int mipi_dbi_drv_probe(struct device *_dev)
>> > +{
>> > + struct mipi_dbi_driver *drv = to_mipi_dbi_driver(_dev->driver);
>> > + struct mipi_dbi_device *dev = to_mipi_dbi_device(_dev);
>>
>> Here we are assuming that mipi_dbi_device can be obtained by using
>> _dev pointer, which may NOT be true in DT case, i think.
>
> Why wouldn't it be true (if we create the devices as explained above) ?
Yeah, with the above method, it should be possible.
>
>> let me know if i am missing something.
>>
>> if you can give me a example for DT case, that would be helpful.
>
> I'm afraid I don't have any, as the DBI drivers I wr
Re: [PATCH v2 0/3] Fix Win8 backlight issue
On 09/18/2013 02:30 PM, Igor Gnatenko wrote: > On Wed, 2013-09-18 at 09:03 +0800, Aaron Lu wrote: >> On 09/17/2013 09:34 PM, Igor Gnatenko wrote: >>> >>> Aaron, how about fix indicator on ThinkPads ? >> >> Can you please describe the problem in detail, is it that when you >> adjust brightness level through hotkey, there is no GUI indication? >> Thanks. >> >> -Aaron > > Yes. On my ThinkPad X230 I pressing backlight hotkeys. Actually > brightnes changing, but have no indicator in GUI. Oh, that's still the problem of _BCL not getting executed once for Lenovo thinkpad laptops. I borrowed a Thinkpad X1 this afternoon and can reproduce this, I'll take a look at this issue. The thinkpad-acpi module already has a call to _BCL but somehow that doesn't happen. Since it's national holidays here, I'll check this issue when I got back to work on this Saturday. Thanks for the quick test :-) -Aaron ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 0/3] Fix Win8 backlight issue
On Wed, 2013-09-18 at 20:31 +0800, Aaron Lu wrote: > On 09/18/2013 02:30 PM, Igor Gnatenko wrote: > > On Wed, 2013-09-18 at 09:03 +0800, Aaron Lu wrote: > >> On 09/17/2013 09:34 PM, Igor Gnatenko wrote: > >>> > >>> Aaron, how about fix indicator on ThinkPads ? > >> > >> Can you please describe the problem in detail, is it that when you > >> adjust brightness level through hotkey, there is no GUI indication? > >> Thanks. > >> > >> -Aaron > > > > Yes. On my ThinkPad X230 I pressing backlight hotkeys. Actually > > brightnes changing, but have no indicator in GUI. > > Oh, that's still the problem of _BCL not getting executed once for > Lenovo thinkpad laptops. I borrowed a Thinkpad X1 this afternoon and can > reproduce this, I'll take a look at this issue. The thinkpad-acpi module > already has a call to _BCL but somehow that doesn't happen. > > Since it's national holidays here, I'll check this issue when I got back > to work on this Saturday. Thanks for the quick test :-) Thanks. No problem ;-) > > -Aaron -- Igor Gnatenko Fedora release 20 (Heisenbug) Linux 3.11.1-300.fc20.x86_64 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: omap: fix: Defer probe if an omapdss device requests for it at connect
On 18/09/13 16:17, Archit Taneja wrote:
> On Wednesday 18 September 2013 06:11 PM, Tomi Valkeinen wrote:
>> On 18/09/13 14:08, Archit Taneja wrote:
>>> Some omapdss panels are connected to outputs/encoders(HDMI/DSI/DPI)
>>> that require
>>> regulators. The output's connect op tries to get a regulator which
>>> may not exist
>>> yet because it might get registered later in the kernel boot.
>>>
>>> omapdrm currently ignores those panels which return a non zero value
>>> when
>>> connected. A better approach would be for omapdrm to request for probe
>>> deferral if a panel's connect op returns -EPROBE_DEFER.
>>>
>>> The connecting of panels is moved very early in the the drm device's
>>> probe
>>> before anything else is initialized. When we enter
>>> omap_modeset_init(), we have
>>> a set of panels that have been connected. We now proceed with
>>> registering only
>>> those panels which are already connected.
>>>
>>> Checking whether the panel has a driver or whether it has
>>> get_timing/read_edid
>>> ops in omap_modeset_init() are redundant with the new display model.
>>> These can
>>> be removed since a dssdev device will always have a driver associated
>>> with it,
>>> and all dssdev drivers have a get_timings op.
>>>
>>> This fixes boot with omapdrm on an omap4 panda ES board. The
>>> regulators used by
>>> HDMI aren't initialized because I2c isn't initialized, I2C isn't
>>> initialized
>>> as it's pins are not configured because pinctrl is yet to probe.
>>>
>>> Signed-off-by: Archit Taneja
>>> ---
>>> drivers/gpu/drm/omapdrm/omap_crtc.c | 5
>>> drivers/gpu/drm/omapdrm/omap_drv.c | 51
>>> +
>>> drivers/gpu/drm/omapdrm/omap_drv.h | 1 +
>>> 3 files changed, 35 insertions(+), 22 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c
>>> b/drivers/gpu/drm/omapdrm/omap_crtc.c
>>> index 0fd2eb1..9c01311 100644
>>> --- a/drivers/gpu/drm/omapdrm/omap_crtc.c
>>> +++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
>>> @@ -623,6 +623,11 @@ void omap_crtc_pre_init(void)
>>> dss_install_mgr_ops(&mgr_ops);
>>> }
>>>
>>> +void omap_crtc_pre_uninit(void)
>>> +{
>>> +dss_uninstall_mgr_ops();
>>> +}
>>> +
>>> /* initialize crtc */
>>> struct drm_crtc *omap_crtc_init(struct drm_device *dev,
>>> struct drm_plane *plane, enum omap_channel channel, int id)
>>> diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c
>>> b/drivers/gpu/drm/omapdrm/omap_drv.c
>>> index 2603d90..cbe5d8e 100644
>>> --- a/drivers/gpu/drm/omapdrm/omap_drv.c
>>> +++ b/drivers/gpu/drm/omapdrm/omap_drv.c
>>> @@ -87,6 +87,24 @@ static bool channel_used(struct drm_device *dev,
>>> enum omap_channel channel)
>>> return false;
>>> }
>>>
>>> +static int omap_connect_dssdevs(void)
>>> +{
>>> +int r;
>>> +struct omap_dss_device *dssdev = NULL;
>>> +
>>> +for_each_dss_dev(dssdev) {
>>> +r = dssdev->driver->connect(dssdev);
>>> +if (r == -EPROBE_DEFER) {
>>> +return r;
>>> +} else if (r) {
>>> +dev_warn(dssdev->dev, "could not connect display: %s\n",
>>> +dssdev->name);
>>> +}
>>> +}
>>> +
>>> +return 0;
>>> +}
>>
>> There are two issues with this one:
>>
>> for_each_dss_dev() uses omap_dss_get_next_device(), and that will
>> increase the ref count of the current dssdev. If you interrupt the loop,
>> the ref count won't be decreased. I have a hunch that we could have
>> similar bugs elsewhere too...
>
> You are saying that the ref counts will be correct only if
> for_each_dss_dev() is fully completed?
Right.
> Maybe we can save the first dssdev which doesn't connect, save that
> dssdev and let the loop continue for the refcount to get decremented again.
>
> Or maybe use omap_dss_get_next_device in a custom loop, which takes care
> of doing a put() for the device before returning.
Well, you can just use omap_dss_put_device(dssdev) before the return.
That should fix it.
Check drivers/video/omap2/dss/display.c:omap_dss_get_next_device().
>> Second, in case of error, the dssdevs that were already connected should
>> be disconnected. Although maybe that's not important, as they'll end up
>> being connected again when the omapdrm is probed the next time.
>
> The one's that were already connected won't connect again and return an
> error which isn't EPROBE_DEFER, so that should be okay right?
Right, in practice it doesn't matter. The only issue here is that it's
not very nice if you don't clean up after getting an error =). And,
well, with modules there could be issues in some particular cases, where
leaving things connected would prevent unloading of modules.
omapdrm doesn't seem to disconnect even when it's removed normally. I
guess it'd be nicer to have similar disconnect loop as in omapfb, i.e.
just go over all the displays and disconnect them all.
Tomi
signature.asc
Description: OpenPGP digital signature
___
dri-devel mailing list
Re: [Intel-gfx] [PATCH] [RFC] mm/shrinker: Add a shrinker flag to always shrink a bit
On Thu, Sep 19, 2013 at 08:57:04AM +0200, Daniel Vetter wrote:
> On Wed, Sep 18, 2013 at 10:38 PM, Dave Chinner wrote:
> > No, that's wrong. ->count_objects should never ass SHRINK_STOP.
> > Indeed, it should always return a count of objects in the cache,
> > regardless of the context.
> >
> > SHRINK_STOP is for ->scan_objects to tell the shrinker it can make
> > any progress due to the context it is called in. This allows the
> > shirnker to defer the work to another call in a different context.
> > However, if ->count-objects doesn't return a count, the work that
> > was supposed to be done cannot be deferred, and that is what
> > ->count_objects should always return the number of objects in the
> > cache.
>
> So we should rework the locking in the drm/i915 shrinker to be able to
> always count objects? Thus far no one screamed yet that we're not
> really able to do that in all call contexts ...
It's not the end of the world if you count no objects. in an ideal
world, you keep a count of the object sizes on the LRU when you
add/remove the objects on the list, that way .count_objects doesn't
need to walk or lock anything, which is what things like the inode
and dentry caches do...
>
> So should I revert 81e49f or will the early return 0; completely upset
> the core shrinker logic?
It looks to me like 81e49f changed the wrong function to return
SHRINK_STOP. It should have changed i915_gem_inactive_scan() to
return SHRINK_STOP when the locks could not be taken, not
i915_gem_inactive_count().
What should happen is this:
max_pass = count_objects()
if (max_pass == 0)
/* skip to next shrinker */
/* calculate total_scan from max_pass and previous leftovers */
while (total_scan) {
freed = scan_objects(batch_size)
if (freed == SHRINK_STOP)
break; /* can't make progress */
total_scan -= batch_size;
}
/* save remaining total_scan for next pass */
i.e. SHRINK_STOP will abort the scan loop when nothing can be done.
Right now, if nothing can be done because the locks can't be taken,
the scan loop will continue running until total_scan reaches zero.
i.e. it does a whole lotta nothing.
So right now, I'd revert 81e49f and then convert
i915_gem_inactive_scan() to return SHRINK_STOP if it can't get
locks, and everything shoul dwork just fine...
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60182] X.Org Server terminate when I close video player
https://bugs.freedesktop.org/show_bug.cgi?id=60182 --- Comment #31 from Michel Dänzer --- (In reply to comment #30) > This, plus the patch in comment 6, fixed it for me [...] Thanks, but please try without that other patch. If it's still necessary, something is still wrong. -- 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 69081] [radeonsi] Incorrect rendering of textures
https://bugs.freedesktop.org/show_bug.cgi?id=69081 Michel Dänzer changed: What|Removed |Added Attachment #86100|0 |1 is obsolete|| -- 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 69081] [radeonsi] Incorrect rendering of textures
https://bugs.freedesktop.org/show_bug.cgi?id=69081 Michel Dänzer changed: What|Removed |Added Attachment #86101|0 |1 is obsolete|| -- 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 69081] [radeonsi] Incorrect rendering of textures
https://bugs.freedesktop.org/show_bug.cgi?id=69081 --- Comment #16 from Michel Dänzer --- (In reply to comment #9) > KF still shows the same problem, so it is probable that both problems were > unrelated. Yes, so the KF problem should be tracked separately. For CK II, there are no shader compilation failures anymore. It could be useful if you could generate an apitrace, so we can isolate how it's trying to render the faces. -- 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 60182] X.Org Server terminate when I close video player
https://bugs.freedesktop.org/show_bug.cgi?id=60182 --- Comment #32 from Michel Dänzer --- Actually, just let us know if you still get any 'Attempted to destroy previously destroyed buffer.' messages. -- 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 2/2] drm: omap: disconnect devices when omapdrm module is removed
Hi,
On Thursday 19 September 2013 03:38 PM, Tomi Valkeinen wrote:
On 19/09/13 11:49, Archit Taneja wrote:
omapdrm established connections for omap_dss_device devices when probed. It
should also be responsible to disconnect the devices. Keeping the devices
connected can prevent the panel driver modules from unloading, it can also
cause problems when omapdrm is re-inserted.
Signed-off-by: Archit Taneja
---
drivers/gpu/drm/omapdrm/omap_drv.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c
b/drivers/gpu/drm/omapdrm/omap_drv.c
index 45fbb1c..44a1203 100644
--- a/drivers/gpu/drm/omapdrm/omap_drv.c
+++ b/drivers/gpu/drm/omapdrm/omap_drv.c
@@ -86,6 +86,13 @@ static bool channel_used(struct drm_device *dev, enum
omap_channel channel)
return false;
}
+static void omap_disconnect_dssdevs(void)
+{
+ struct omap_dss_device *dssdev = NULL;
+
+ for_each_dss_dev(dssdev)
+ dssdev->driver->disconnect(dssdev);
+}
With a quick test, it looks like omapdrm leaves the displays enabled
when exiting. This can be fixed by adding to the above loop:
if (dssdev->state != OMAP_DSS_DISPLAY_DISABLED)
dssdev->driver->disable(dssdev);
However... omapdrm still crashes when unloading, and it could be somehow
related to leaving something un-removed. Disabling a CRTC should disable
the display, and maybe omapdrm should disable (and clean-up) all CRTCs
on exit, and maybe that would remove the crash, and also fix the issue
of leaving displays enabled.
But I'm just guessing there, I have no idea how the process of unloading
a drm driver goes.
It seems like dev_unload is the place where we should disconnect the
dssdevs.
omap_modeset_free() calls drm_mode_config_cleanup() which calls omapdrm
specific destroy funcs for connectors, encoders and crtcs.
I don't think crtcs should disable the device. I think it's the
encoder(and connector) which is mapped to a display. The omap_encoder's
destroy op should disable the dssdev device.
I'm not sure about this though. Rob, do you have any comment on this?
Archit
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 61269] Support libkms on FreeBSD
https://bugs.freedesktop.org/show_bug.cgi?id=61269 Christoph Egger changed: What|Removed |Added Attachment #75299|0 |1 is obsolete|| --- Comment #4 from Christoph Egger --- Created attachment 86138 --> https://bugs.freedesktop.org/attachment.cgi?id=86138&action=edit Updated "Add support for FreeBSD’s libkms (patch by Konstantin Belousov)" Attached is an update to the libkms patch. It adds two small modifications so it works on kfreebsd as well and refreshes against libdrm 2.46. It also adds a small fix (len is used before it is assigned) without which it doesn't work for me -- 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 69463] RadeonSI : xserver crashes with Segmentation Fault
https://bugs.freedesktop.org/show_bug.cgi?id=69463 --- Comment #5 from samit vats --- The Debug output is : (II) [KMS] Kernel modesetting enabled. libEGL debug: Native platform type: drm (environment overwrite) libEGL debug: ignore EGL_DRIVERS_PATH for setuid/setgid binaries libEGL debug: EGL search path is /home/atitest/install/lib/egl libEGL debug: added /home/atitest/install/lib/egl/egl_gallium.so to module array libEGL debug: added egl_dri2 to module array libEGL debug: added egl_glx to module array libEGL debug: dlopen(/home/atitest/install/lib/egl/egl_gallium.so) libEGL info: use DRM for display 0x1b741d0 libEGL debug: EGL user error 0x3001 (EGL_NOT_INITIALIZED) in eglInitialize(no usable display) libEGL info: use DRM for display 0x1b741d0 libEGL debug: EGL user error 0x3001 (EGL_NOT_INITIALIZED) in eglInitialize(no usable display) libEGL debug: EGL user error 0x3001 (EGL_NOT_INITIALIZED) in eglInitialize (EE) RADEON(0): eglInitialize() failed (EE) RADEON(0): glamor detected, failed to initialize EGL. X: /home/atitest/work/llvm/include/llvm/Support/CommandLine.h:674: void llvm::cl::parser::addLiteralOption(const char *, const DT &, const char *) [DataType = llvm::ScheduleDAGInstrs *(*)(llvm::MachineSchedContext *), DT = llvm::ScheduleDAGInstrs *(*)(llvm::MachineSchedContext *)]: Assertion `findOption(Name) == Values.size() && "Option already exists!"' failed. xinit: giving up xinit: unable to connect to X server: Connection refused xinit: server error -- 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] radeon: fix pitch alignment for non-power-of-two mipmaps on SI
This fixes VM protection faults.
I have a new piglit test which can iterate over all possible widths, heights,
and depths (including NPOT) and tests mipmapping with various texture targets.
After this is committed, I'll make a new release of libdrm and bump
the libdrm version requirement in Mesa.
---
radeon/radeon_surface.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/radeon/radeon_surface.c b/radeon/radeon_surface.c
index 1710e34..d5c45c4 100644
--- a/radeon/radeon_surface.c
+++ b/radeon/radeon_surface.c
@@ -1412,7 +1412,11 @@ static void si_surf_minify(struct radeon_surface *surf,
uint32_t xalign, uint32_t yalign, uint32_t zalign,
uint32_t slice_align, unsigned offset)
{
-surflevel->npix_x = mip_minify(surf->npix_x, level);
+if (level == 0) {
+surflevel->npix_x = surf->npix_x;
+} else {
+surflevel->npix_x = mip_minify(next_power_of_two(surf->npix_x), level);
+}
surflevel->npix_y = mip_minify(surf->npix_y, level);
surflevel->npix_z = mip_minify(surf->npix_z, level);
@@ -1434,7 +1438,7 @@ static void si_surf_minify(struct radeon_surface *surf,
if (level == 0 && surf->last_level == 0)
/* Non-mipmap pitch padded to slice alignment */
xalign = MAX2(xalign, slice_align / surf->bpe);
-else
+else if (surflevel->mode == RADEON_SURF_MODE_LINEAR_ALIGNED)
/* Small rows evenly distributed across slice */
xalign = MAX2(xalign, slice_align / surf->bpe / surflevel->nblk_y);
@@ -1456,7 +1460,11 @@ static void si_surf_minify_2d(struct radeon_surface
*surf,
{
unsigned mtile_pr, mtile_ps;
-surflevel->npix_x = mip_minify(surf->npix_x, level);
+if (level == 0) {
+surflevel->npix_x = surf->npix_x;
+} else {
+surflevel->npix_x = mip_minify(next_power_of_two(surf->npix_x), level);
+}
surflevel->npix_y = mip_minify(surf->npix_y, level);
surflevel->npix_z = mip_minify(surf->npix_z, level);
--
1.8.1.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 68235] Display freezes after login with kernel 3.11.0-rc5 on Cayman with dpm=1
https://bugs.freedesktop.org/show_bug.cgi?id=68235 --- Comment #40 from Alexandre Demers --- Should I continu to see what value I can reach? -- 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 69463] RadeonSI : xserver crashes with Segmentation Fault
https://bugs.freedesktop.org/show_bug.cgi?id=69463 --- Comment #6 from Michel Dänzer --- (In reply to comment #5) > libEGL debug: Native platform type: drm (environment overwrite) So you set EGL_PLATFORM=drm? Would be interesting to see the debugging output without that as well. > libEGL debug: dlopen(/home/atitest/install/lib/egl/egl_gallium.so) > libEGL info: use DRM for display 0x1b741d0 > libEGL debug: EGL user error 0x3001 (EGL_NOT_INITIALIZED) in > eglInitialize(no usable display) > libEGL info: use DRM for display 0x1b741d0 > libEGL debug: EGL user error 0x3001 (EGL_NOT_INITIALIZED) in > eglInitialize(no usable display) > libEGL debug: EGL user error 0x3001 (EGL_NOT_INITIALIZED) in eglInitialize > (EE) RADEON(0): eglInitialize() failed > (EE) RADEON(0): glamor detected, failed to initialize EGL. That's not the same crash anymore, but 'just' an EGL initialization failure. Does it get further if you set EGL_DRIVER=egl_dri2 as well? -- 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] radeon: fix pitch alignment for non-power-of-two mipmaps on SI
On Don, 2013-09-19 at 14:33 +0200, Marek Olšák wrote:
> This fixes VM protection faults.
>
> I have a new piglit test which can iterate over all possible widths, heights,
> and depths (including NPOT) and tests mipmapping with various texture targets.
>
> After this is committed, I'll make a new release of libdrm and bump
> the libdrm version requirement in Mesa.
> ---
> radeon/radeon_surface.c | 14 +++---
> 1 file changed, 11 insertions(+), 3 deletions(-)
>
> diff --git a/radeon/radeon_surface.c b/radeon/radeon_surface.c
> index 1710e34..d5c45c4 100644
> --- a/radeon/radeon_surface.c
> +++ b/radeon/radeon_surface.c
> @@ -1412,7 +1412,11 @@ static void si_surf_minify(struct radeon_surface *surf,
> uint32_t xalign, uint32_t yalign, uint32_t zalign,
> uint32_t slice_align, unsigned offset)
> {
> -surflevel->npix_x = mip_minify(surf->npix_x, level);
> +if (level == 0) {
> +surflevel->npix_x = surf->npix_x;
> +} else {
> +surflevel->npix_x = mip_minify(next_power_of_two(surf->npix_x),
> level);
> +}
> surflevel->npix_y = mip_minify(surf->npix_y, level);
> surflevel->npix_z = mip_minify(surf->npix_z, level);
>
Shouldn't this be done (only) for nblk_x instead of npix_x?
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Debian, X and DRI developer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 68235] Display freezes after login with kernel 3.11.0-rc5 on Cayman with dpm=1
https://bugs.freedesktop.org/show_bug.cgi?id=68235 --- Comment #41 from Alex Deucher --- Created attachment 86147 --> https://bugs.freedesktop.org/attachment.cgi?id=86147&action=edit mclk debugging pll debugging output Can you attach the dmesg output with this patch applied? I want to make sure the mclk parameters are being properly calculated for the 13 mclk. -- 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 68235] Display freezes after login with kernel 3.11.0-rc5 on Cayman with dpm=1
https://bugs.freedesktop.org/show_bug.cgi?id=68235 --- Comment #42 from Alexandre Demers --- (In reply to comment #41) > Created attachment 86147 [details] [review] > mclk debugging pll debugging output > > Can you attach the dmesg output with this patch applied? I want to make > sure the mclk parameters are being properly calculated for the 13 mclk. I'll try it at home later today. -- 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] radeon: fix pitch alignment for non-power-of-two mipmaps on SI
On Thu, Sep 19, 2013 at 4:41 PM, Michel Dänzer wrote:
> On Don, 2013-09-19 at 14:33 +0200, Marek Olšák wrote:
>> This fixes VM protection faults.
>>
>> I have a new piglit test which can iterate over all possible widths, heights,
>> and depths (including NPOT) and tests mipmapping with various texture
>> targets.
>>
>> After this is committed, I'll make a new release of libdrm and bump
>> the libdrm version requirement in Mesa.
>> ---
>> radeon/radeon_surface.c | 14 +++---
>> 1 file changed, 11 insertions(+), 3 deletions(-)
>>
>> diff --git a/radeon/radeon_surface.c b/radeon/radeon_surface.c
>> index 1710e34..d5c45c4 100644
>> --- a/radeon/radeon_surface.c
>> +++ b/radeon/radeon_surface.c
>> @@ -1412,7 +1412,11 @@ static void si_surf_minify(struct radeon_surface
>> *surf,
>> uint32_t xalign, uint32_t yalign, uint32_t
>> zalign,
>> uint32_t slice_align, unsigned offset)
>> {
>> -surflevel->npix_x = mip_minify(surf->npix_x, level);
>> +if (level == 0) {
>> +surflevel->npix_x = surf->npix_x;
>> +} else {
>> +surflevel->npix_x = mip_minify(next_power_of_two(surf->npix_x),
>> level);
>> +}
>> surflevel->npix_y = mip_minify(surf->npix_y, level);
>> surflevel->npix_z = mip_minify(surf->npix_z, level);
>>
>
> Shouldn't this be done (only) for nblk_x instead of npix_x?
First, level[i].npix_x/y/z have misleading names, because they are
always aligned to a power of two for non-zero mipmap levels, therefore
Mesa shouldn't use them in place of u_minify, because it's not the
same thing. In fact, r600g doesn't really use them and even though
radeonsi does, they are incorrectly used in place of u_minify. It's on
my TODO list.
mip_minify is defined as: level ? MAX2(1, next_power_of_two(x >> level)) : x.
u_minify is defined as: level ? MAX2(1, x >> level) : x.
Considering that probably nothing in Mesa uses level[i].npix_x/y/z
correctly, it's not so important what the variables contain.
The problem this patch fixes is that next_power_of_two should be
applied before the minification, like this: next_power_of_two(x) >>
level. I had to guess it and test it thoroughly. The memory addressing
documentation is pretty useless here.
Marek
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
HDMI stereo support v5
v4 was: http://lists.freedesktop.org/archives/dri-devel/2013-September/045340.html Changes from v4: - The kernel is now in charge of adjusting the stereo mode timings. - There is a per-connector opt-in boolean to expose stereo modes, letting people enable stereo for each driver/connector. - The series now depends on the latest bits from the drm-intel tree - Removed the 2 buffers check that was judged unnecessary - I realized that for frame packing modes (where you have to adjust the vdisplay to be 2 * vdisplay + vblank) with a NTSC clock I was reconstructing the clock without adjusting it by 1000 / 1001. Now that the timing computation is in the kernel, fixed it there. - I also checked that we correctly match against the 2D CEA mode for the AVI infoframes. The last bit to make it work was the introduction of crtc_clock to separate the original clock from the one computed by drm_mode_set_crtcinfo() - And finally, I booted with i915.fastboot=1 and discovered that the pipe_src register was getting clobbered, so fixed that as well ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 01/20] drm: Add a SET_CLIENT_CAP ioctl
This ioctl can be used to turn some knobs in a DRM driver. The client
can ask the DRM core for an alternate view of the reality: it can be
useful to be able to instruct the core that the DRM client can handle
new functionnality that would otherwise break current ABI.
v2: Rename to ioctl from SET_CAP to SET_CLIENT_CAP (Chris Wilson)
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/drm_drv.c | 1 +
drivers/gpu/drm/drm_ioctl.c | 9 +
include/drm/drmP.h | 2 ++
include/uapi/drm/drm.h | 7 +++
4 files changed, 19 insertions(+)
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index e572dd2..e79d8d9 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -69,6 +69,7 @@ static const struct drm_ioctl_desc drm_ioctls[] = {
DRM_IOCTL_DEF(DRM_IOCTL_GET_CLIENT, drm_getclient, DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_GET_STATS, drm_getstats, DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_GET_CAP, drm_getcap,
DRM_UNLOCKED|DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF(DRM_IOCTL_SET_CLIENT_CAP, drm_setclientcap, 0),
DRM_IOCTL_DEF(DRM_IOCTL_SET_VERSION, drm_setversion, DRM_MASTER),
DRM_IOCTL_DEF(DRM_IOCTL_SET_UNIQUE, drm_setunique,
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index 07247e2..15da412 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -303,6 +303,15 @@ int drm_getcap(struct drm_device *dev, void *data, struct
drm_file *file_priv)
}
/**
+ * Set device/driver capabilities
+ */
+int
+drm_setclientcap(struct drm_device *dev, void *data, struct drm_file
*file_priv)
+{
+ return -EINVAL;
+}
+
+/**
* Setversion ioctl.
*
* \param inode device inode.
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 2907341..782433b 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -1303,6 +1303,8 @@ extern int drm_getstats(struct drm_device *dev, void
*data,
struct drm_file *file_priv);
extern int drm_getcap(struct drm_device *dev, void *data,
struct drm_file *file_priv);
+extern int drm_setclientcap(struct drm_device *dev, void *data,
+ struct drm_file *file_priv);
extern int drm_setversion(struct drm_device *dev, void *data,
struct drm_file *file_priv);
extern int drm_noop(struct drm_device *dev, void *data,
diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
index 1e09e8f..526baed 100644
--- a/include/uapi/drm/drm.h
+++ b/include/uapi/drm/drm.h
@@ -627,6 +627,12 @@ struct drm_get_cap {
__u64 value;
};
+/** DRM_IOCTL_SET_CLIENT_CAP ioctl argument type */
+struct drm_set_client_cap {
+ __u64 capability;
+ __u64 value;
+};
+
#define DRM_CLOEXEC O_CLOEXEC
struct drm_prime_handle {
__u32 handle;
@@ -659,6 +665,7 @@ struct drm_prime_handle {
#define DRM_IOCTL_GEM_FLINKDRM_IOWR(0x0a, struct drm_gem_flink)
#define DRM_IOCTL_GEM_OPEN DRM_IOWR(0x0b, struct drm_gem_open)
#define DRM_IOCTL_GET_CAP DRM_IOWR(0x0c, struct drm_get_cap)
+#define DRM_IOCTL_SET_CLIENT_CAP DRM_IOW( 0x0d, struct
drm_set_client_cap)
#define DRM_IOCTL_SET_UNIQUE DRM_IOW( 0x10, struct drm_unique)
#define DRM_IOCTL_AUTH_MAGIC DRM_IOW( 0x11, struct drm_auth)
--
1.8.3.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 02/20] drm: Add HDMI stereo 3D flags to struct drm_mode_modeinfo
HDMI 1.4a defines a few layouts that we'd like to expose. This commits
add new modeinfo flags that can be used to list the supported stereo
layouts (when querying the list of modes) and to set a given stereo 3D
mode (when setting a mode).
v2: Add a drm_mode_is_stereo() helper
Signed-off-by: Damien Lespiau
---
include/drm/drm_crtc.h | 14 ++
include/uapi/drm/drm_mode.h | 36 ++--
2 files changed, 36 insertions(+), 14 deletions(-)
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 24f4995..825d6fa 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -180,6 +180,20 @@ struct drm_display_mode {
int hsync; /* in kHz */
};
+#define DRM_MODE_FLAG_3D_MASK (DRM_MODE_FLAG_3D_FRAME_PACKING | \
+DRM_MODE_FLAG_3D_FIELD_ALTERNATIVE | \
+DRM_MODE_FLAG_3D_LINE_ALTERNATIVE | \
+DRM_MODE_FLAG_3D_SIDE_BY_SIDE_FULL | \
+DRM_MODE_FLAG_3D_L_DEPTH | \
+DRM_MODE_FLAG_3D_L_DEPTH_GFX_GFX_DEPTH | \
+DRM_MODE_FLAG_3D_TOP_AND_BOTTOM| \
+DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF)
+
+static inline bool drm_mode_is_stereo(const struct drm_display_mode *mode)
+{
+ return mode->flags & DRM_MODE_FLAG_3D_MASK;
+}
+
enum drm_connector_status {
connector_status_connected = 1,
connector_status_disconnected = 2,
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index 113d324..bafe612 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -44,20 +44,28 @@
/* Video mode flags */
/* bit compatible with the xorg definitions. */
-#define DRM_MODE_FLAG_PHSYNC (1<<0)
-#define DRM_MODE_FLAG_NHSYNC (1<<1)
-#define DRM_MODE_FLAG_PVSYNC (1<<2)
-#define DRM_MODE_FLAG_NVSYNC (1<<3)
-#define DRM_MODE_FLAG_INTERLACE(1<<4)
-#define DRM_MODE_FLAG_DBLSCAN (1<<5)
-#define DRM_MODE_FLAG_CSYNC(1<<6)
-#define DRM_MODE_FLAG_PCSYNC (1<<7)
-#define DRM_MODE_FLAG_NCSYNC (1<<8)
-#define DRM_MODE_FLAG_HSKEW(1<<9) /* hskew provided */
-#define DRM_MODE_FLAG_BCAST(1<<10)
-#define DRM_MODE_FLAG_PIXMUX (1<<11)
-#define DRM_MODE_FLAG_DBLCLK (1<<12)
-#define DRM_MODE_FLAG_CLKDIV2 (1<<13)
+#define DRM_MODE_FLAG_PHSYNC (1<<0)
+#define DRM_MODE_FLAG_NHSYNC (1<<1)
+#define DRM_MODE_FLAG_PVSYNC (1<<2)
+#define DRM_MODE_FLAG_NVSYNC (1<<3)
+#define DRM_MODE_FLAG_INTERLACE(1<<4)
+#define DRM_MODE_FLAG_DBLSCAN (1<<5)
+#define DRM_MODE_FLAG_CSYNC(1<<6)
+#define DRM_MODE_FLAG_PCSYNC (1<<7)
+#define DRM_MODE_FLAG_NCSYNC (1<<8)
+#define DRM_MODE_FLAG_HSKEW(1<<9) /* hskew provided */
+#define DRM_MODE_FLAG_BCAST(1<<10)
+#define DRM_MODE_FLAG_PIXMUX (1<<11)
+#define DRM_MODE_FLAG_DBLCLK (1<<12)
+#define DRM_MODE_FLAG_CLKDIV2 (1<<13)
+#define DRM_MODE_FLAG_3D_FRAME_PACKING (1<<14)
+#define DRM_MODE_FLAG_3D_FIELD_ALTERNATIVE (1<<15)
+#define DRM_MODE_FLAG_3D_LINE_ALTERNATIVE (1<<16)
+#define DRM_MODE_FLAG_3D_SIDE_BY_SIDE_FULL (1<<17)
+#define DRM_MODE_FLAG_3D_L_DEPTH (1<<18)
+#define DRM_MODE_FLAG_3D_L_DEPTH_GFX_GFX_DEPTH (1<<19)
+#define DRM_MODE_FLAG_3D_TOP_AND_BOTTOM(1<<20)
+#define DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF (1<<21)
/* DPMS flags */
/* bit compatible with the xorg definitions. */
--
1.8.3.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 13/20] drm: Introduce a crtc_clock for struct drm_display_mode
Just like the various timings, make it possible to have a clock field
what we can tweak before giving it to hardware.
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/drm_modes.c | 1 +
include/drm/drm_crtc.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index c2cb2c8..ef26eb2 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -719,6 +719,7 @@ void drm_mode_set_crtcinfo(struct drm_display_mode *p, int
adjust_flags)
if ((p == NULL) || ((p->type & DRM_MODE_TYPE_CRTC_C) ==
DRM_MODE_TYPE_BUILTIN))
return;
+ p->crtc_clock = p->clock;
p->crtc_hdisplay = p->hdisplay;
p->crtc_hsync_start = p->hsync_start;
p->crtc_hsync_end = p->hsync_end;
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 8e9716e..73478bc 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -156,6 +156,7 @@ struct drm_display_mode {
int height_mm;
/* Actual mode we give to hw */
+ int crtc_clock; /* in KHz */
int crtc_hdisplay;
int crtc_hblank_start;
int crtc_hblank_end;
--
1.8.3.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 18/20] drm/i915: Ask the DRM core do make stereo timings adjustements
When scanning out big stereo buffers that are actually bigger that their natural 2D counterpart, we need to blow up the crtc timings as well. Not that this is only done for frame packing as this is the only stereo mode currently exposed needing this kind of ajdustements. Signed-off-by: Damien Lespiau --- drivers/gpu/drm/i915/intel_display.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 2b9f80b..0573036 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -8460,7 +8460,7 @@ encoder_retry: pipe_config->pixel_multiplier = 1; /* Fill in default crtc timings, allow encoders to overwrite them. */ - drm_mode_set_crtcinfo(&pipe_config->adjusted_mode, 0); + drm_mode_set_crtcinfo(&pipe_config->adjusted_mode, CRTC_STEREO_DOUBLE); /* Pass our mode to the connectors and the CRTC to give them a chance to * adjust it according to limitations or connector properties, and also -- 1.8.3.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 14/20] drm: Implement timings adjustments for frame packing
When using the frame packing and a single big framebuffer, some hardware
requires that we do everything like if we were scanning out the big
buffer itself. Let's instrument drm_mode_set_crtcinfo() to be able to do
this adjustement if the driver is asking for it.
Suggested-by: Daniel Vetter
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/drm_modes.c | 51 -
include/drm/drm_crtc.h | 3 ++-
2 files changed, 52 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index ef26eb2..d9c5a34 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -704,15 +704,47 @@ int drm_mode_vrefresh(const struct drm_display_mode *mode)
}
EXPORT_SYMBOL(drm_mode_vrefresh);
+static bool drm_mode_is_ntsc(const struct drm_display_mode *mode)
+{
+ int ntsc_clock;
+
+ ntsc_clock = DIV_ROUND_UP(mode->vtotal * mode->htotal * mode->vrefresh,
+ 1001);
+
+ if (ntsc_clock == mode->clock)
+ return true;
+
+ return false;
+}
+
+static void drm_mode_reconstruct_crtc_clock(struct drm_display_mode *mode)
+{
+ int clock;
+
+ clock = mode->crtc_vtotal * mode->crtc_htotal *
+ drm_mode_vrefresh(mode) / 1000;
+
+ if (drm_mode_is_ntsc(mode))
+ mode->crtc_clock = DIV_ROUND_UP(clock * 1000, 1001);
+ else
+ mode->crtc_clock = clock;
+}
+
/**
* drm_mode_set_crtcinfo - set CRTC modesetting parameters
* @p: mode
- * @adjust_flags: unused? (FIXME)
+ * @adjust_flags: a combination of adjustment flags
*
* LOCKING:
* None.
*
* Setup the CRTC modesetting parameters for @p, adjusting if necessary.
+ *
+ * - The CRTC_INTERLACE_HALVE_V flag can be used to halve vertical timings of
+ * interlaced modes.
+ * - The CRTC_STEREO_DOUBLE flag can be used to compute the timings for
+ * buffers containing two eyes (only adjust the timings when needed, eg. for
+ * "frame packing" or "side by side full").
*/
void drm_mode_set_crtcinfo(struct drm_display_mode *p, int adjust_flags)
{
@@ -753,6 +785,23 @@ void drm_mode_set_crtcinfo(struct drm_display_mode *p, int
adjust_flags)
p->crtc_vtotal *= p->vscan;
}
+ if (adjust_flags & CRTC_STEREO_DOUBLE) {
+ unsigned int layout = p->flags & DRM_MODE_FLAG_3D_MASK;
+ int vactive_space;
+
+ switch (layout) {
+ case DRM_MODE_FLAG_3D_FRAME_PACKING:
+ vactive_space = p->vtotal - p->vdisplay;
+
+ p->crtc_vdisplay += p->vdisplay + vactive_space;
+ p->crtc_vsync_start += p->vdisplay + vactive_space;
+ p->crtc_vsync_end += p->vdisplay + vactive_space;
+ p->crtc_vtotal += p->vdisplay + vactive_space;
+ drm_mode_reconstruct_crtc_clock(p);
+ break;
+ }
+ }
+
p->crtc_vblank_start = min(p->crtc_vsync_start, p->crtc_vdisplay);
p->crtc_vblank_end = max(p->crtc_vsync_end, p->crtc_vtotal);
p->crtc_hblank_start = min(p->crtc_hsync_start, p->crtc_hdisplay);
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 73478bc..b2d08ca 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -125,7 +125,8 @@ enum drm_mode_status {
.vscan = (vs), .flags = (f), \
.base.type = DRM_MODE_OBJECT_MODE
-#define CRTC_INTERLACE_HALVE_V 0x1 /* halve V values for interlacing */
+#define CRTC_INTERLACE_HALVE_V (1 << 0) /* halve V values for interlacing */
+#define CRTC_STEREO_DOUBLE (1 << 1) /* adjust timings for stereo modes */
struct drm_display_mode {
/* Header */
--
1.8.3.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 64600] r600g pyrit OpenCL issue on HD6850
https://bugs.freedesktop.org/show_bug.cgi?id=64600 --- Comment #11 from darkbasic --- Created attachment 86166 --> https://bugs.freedesktop.org/attachment.cgi?id=86166&action=edit debug radeonsi nopatch I here my RADEON_DUMP_SHADERS=1 pyrit benchmark 2> debug.txt with radeonsi (HD 7950) without the patch. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 64201] OpenCL usage result segmentation fault on r600g with HD6850.
https://bugs.freedesktop.org/show_bug.cgi?id=64201 --- Comment #52 from darkbasic --- Created attachment 86167 --> https://bugs.freedesktop.org/attachment.cgi?id=86167&action=edit debug radeonsi nopatch With the patch there are no shaders in the output, so here is the output without the patch. RADEON_DUMP_SHADERS=1 bfgminer --scrypt -o stratum+tcp://stratum2.wemineltc.com:3334 -u user.1 -p password -v1 2> debug.txt -- 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 60182] X.Org Server terminate when I close video player
https://bugs.freedesktop.org/show_bug.cgi?id=60182 --- Comment #33 from Jose P. --- (In reply to comment #32) > Actually, just let us know if you still get any 'Attempted to destroy > previously destroyed buffer.' messages. None at all. I only get 'XIO: fatal IO error 11 (Resource temporarily unavailable) on X server ":0" after 6030 requests (6030 known processed) with 0 events remaining.' in the console when closing glxgears (alt+f4) (which AFAIK is normal, but didn't happen before). -- 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: Regression: bisected: commit 7c510133d93 breaks video
On Thu, Sep 19, 2013 at 06:32:47PM +, Paul Zimmerman wrote: > > From: Paul Zimmerman > > Sent: Thursday, September 19, 2013 11:21 AM > > > > > From: Dave Airlie [mailto:airl...@gmail.com] > > > Sent: Wednesday, September 18, 2013 7:40 PM > > > > > > On Thu, Sep 19, 2013 at 12:02 PM, Paul Zimmerman > > > wrote: > > > > I have an ASUS P6X58D-Premium mobo with a GeForce 9400GT PCIe video > > > > card. > > > > With kernel 3.12-rc1, I get scrambled video on boot. Kernel 3.11 works > > > > fine. > > > > > > > > Bisecting this, I found 7c510133d93dd6f15ca040733ba7b2891ed61fd1 "drm: > > > > mark context support as a legacy subsystem" is the guilty commit. If I > > > > revert that commit, the video works fine. > > > > > > > > Is there any more info I can provide? > > > > > > Full dmesg, and what driver you are using. > > > > Driver is nouveau. > > > > The dmesg from a good boot with the commit reverted is attached. > > > > For the bad boot, the dmesg log is filled with messages like this: > > > > [ 15.871667] nouveau E[ PFB][:03:00.0] trapped write at > > 0x01010010a0 on channel 0x0001fed0 > > [unknown] BAR/PFIFO_WRITE/IN reason: PAGE_NOT_PRESENT > > [ 15.871698] nouveau E[ PFB][:03:00.0] trapped write at > > 0x010100b2e0 on channel 0x0001fed0 > > [unknown] BAR/PFIFO_WRITE/IN reason: PAGE_NOT_PRESENT > > [ 15.871781] nouveau E[ PFB][:03:00.0] trapped write at > > 0x0101011600 on channel 0x0001fed0 > > [unknown] BAR/PFIFO_WRITE/IN reason: PAGE_NOT_PRESENT > > > > I will try next with the patch series you sent to Linus yesterday, to > > see if that happens to fix this. > > Nope, with your patch series from yesterday the problem still exists. Just to double-check: Does the revert still work, even on latest upstream git + Dave's pull request? -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 11/20] drm: Remove clock_index from struct drm_display_mode
This field was only accessed by the nouveau driver, but never set. So
concluded we can rid of this one.
Cc: Ben Skeggs
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/nouveau/dispnv04/crtc.c | 2 --
include/drm/drm_crtc.h | 1 -
2 files changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv04/crtc.c
b/drivers/gpu/drm/nouveau/dispnv04/crtc.c
index d4fbf11..0e3270c 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/crtc.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/crtc.c
@@ -326,8 +326,6 @@ nv_crtc_mode_set_vga(struct drm_crtc *crtc, struct
drm_display_mode *mode)
regp->MiscOutReg = 0x23;/* +hsync +vsync */
}
- regp->MiscOutReg |= (mode->clock_index & 0x03) << 2;
-
/*
* Time Sequencer
*/
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 1b69407..011baaa 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -156,7 +156,6 @@ struct drm_display_mode {
int height_mm;
/* Actual mode we give to hw */
- int clock_index;
int synth_clock;
int crtc_hdisplay;
int crtc_hblank_start;
--
1.8.3.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 49603] [regression] Fullscreen video no longer smooth with GPU in low power mode
https://bugs.freedesktop.org/show_bug.cgi?id=49603 Sven Arvidsson changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Sven Arvidsson --- With Mesa 9.2 and other modern components fullscreen video is smooth in low power mode once again. I guess this is less relevant anyhow what with UVD and dynamic power management also being available. -- 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] radeon: fix pitch alignment for non-power-of-two mipmaps on SI
BTW, the intuitive explanation of the fix is that we have to minify
the pitch (or POT width) instead of the NPOT width.
Marek
On Thu, Sep 19, 2013 at 6:37 PM, Marek Olšák wrote:
> On Thu, Sep 19, 2013 at 4:41 PM, Michel Dänzer wrote:
>> On Don, 2013-09-19 at 14:33 +0200, Marek Olšák wrote:
>>> This fixes VM protection faults.
>>>
>>> I have a new piglit test which can iterate over all possible widths,
>>> heights,
>>> and depths (including NPOT) and tests mipmapping with various texture
>>> targets.
>>>
>>> After this is committed, I'll make a new release of libdrm and bump
>>> the libdrm version requirement in Mesa.
>>> ---
>>> radeon/radeon_surface.c | 14 +++---
>>> 1 file changed, 11 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/radeon/radeon_surface.c b/radeon/radeon_surface.c
>>> index 1710e34..d5c45c4 100644
>>> --- a/radeon/radeon_surface.c
>>> +++ b/radeon/radeon_surface.c
>>> @@ -1412,7 +1412,11 @@ static void si_surf_minify(struct radeon_surface
>>> *surf,
>>> uint32_t xalign, uint32_t yalign, uint32_t
>>> zalign,
>>> uint32_t slice_align, unsigned offset)
>>> {
>>> -surflevel->npix_x = mip_minify(surf->npix_x, level);
>>> +if (level == 0) {
>>> +surflevel->npix_x = surf->npix_x;
>>> +} else {
>>> +surflevel->npix_x = mip_minify(next_power_of_two(surf->npix_x),
>>> level);
>>> +}
>>> surflevel->npix_y = mip_minify(surf->npix_y, level);
>>> surflevel->npix_z = mip_minify(surf->npix_z, level);
>>>
>>
>> Shouldn't this be done (only) for nblk_x instead of npix_x?
>
> First, level[i].npix_x/y/z have misleading names, because they are
> always aligned to a power of two for non-zero mipmap levels, therefore
> Mesa shouldn't use them in place of u_minify, because it's not the
> same thing. In fact, r600g doesn't really use them and even though
> radeonsi does, they are incorrectly used in place of u_minify. It's on
> my TODO list.
>
> mip_minify is defined as: level ? MAX2(1, next_power_of_two(x >> level)) : x.
> u_minify is defined as: level ? MAX2(1, x >> level) : x.
>
> Considering that probably nothing in Mesa uses level[i].npix_x/y/z
> correctly, it's not so important what the variables contain.
>
> The problem this patch fixes is that next_power_of_two should be
> applied before the minification, like this: next_power_of_two(x) >>
> level. I had to guess it and test it thoroughly. The memory addressing
> documentation is pretty useless here.
>
> Marek
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 15/20] drm/i915: Use crtc_clock in intel_dump_crtc_timings()
We want to dump the parameters given to the hardware, so let's use
crtc_clock here.
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/intel_display.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index a1a8172..fb769fe 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -8332,7 +8332,7 @@ static void intel_dump_crtc_timings(const struct
drm_display_mode *mode)
{
DRM_DEBUG_KMS("crtc timings: %d %d %d %d %d %d %d %d %d, "
"type: 0x%x flags: 0x%x\n",
- mode->clock,
+ mode->crtc_clock,
mode->crtc_hdisplay, mode->crtc_hsync_start,
mode->crtc_hsync_end, mode->crtc_htotal,
mode->crtc_vdisplay, mode->crtc_vsync_start,
--
1.8.3.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Regression: bisected: commit 7c510133d93 breaks video
On Fri, Sep 20, 2013 at 7:13 AM, Paul Zimmerman wrote: >> From: Dave Airlie [mailto:airl...@gmail.com] >> Sent: Thursday, September 19, 2013 1:15 PM >> >> On Fri, Sep 20, 2013 at 6:10 AM, Daniel Vetter wrote: >> > On Thu, Sep 19, 2013 at 06:32:47PM +, Paul Zimmerman wrote: >> >> > From: Paul Zimmerman >> >> > Sent: Thursday, September 19, 2013 11:21 AM >> >> > >> >> > > From: Dave Airlie [mailto:airl...@gmail.com] >> >> > > Sent: Wednesday, September 18, 2013 7:40 PM >> >> > > >> >> > > On Thu, Sep 19, 2013 at 12:02 PM, Paul Zimmerman >> >> > > wrote: >> >> > > > I have an ASUS P6X58D-Premium mobo with a GeForce 9400GT PCIe video >> >> > > > card. >> >> > > > With kernel 3.12-rc1, I get scrambled video on boot. Kernel 3.11 >> >> > > > works >> >> > > > fine. >> >> > > > >> >> > > > Bisecting this, I found 7c510133d93dd6f15ca040733ba7b2891ed61fd1 >> >> > > > "drm: >> >> > > > mark context support as a legacy subsystem" is the guilty commit. >> >> > > > If I >> >> > > > revert that commit, the video works fine. >> >> > > > >> >> > > > Is there any more info I can provide? >> >> > > >> >> > > Full dmesg, and what driver you are using. >> >> > >> >> > Driver is nouveau. >> >> > >> >> > The dmesg from a good boot with the commit reverted is attached. >> >> > >> >> > For the bad boot, the dmesg log is filled with messages like this: >> >> > >> >> > [ 15.871667] nouveau E[ PFB][:03:00.0] trapped write at >> >> > 0x01010010a0 on channel >> 0x0001fed0 >> >> > [unknown] BAR/PFIFO_WRITE/IN reason: PAGE_NOT_PRESENT >> >> > [ 15.871698] nouveau E[ PFB][:03:00.0] trapped write at >> >> > 0x010100b2e0 on channel >> 0x0001fed0 >> >> > [unknown] BAR/PFIFO_WRITE/IN reason: PAGE_NOT_PRESENT >> >> > [ 15.871781] nouveau E[ PFB][:03:00.0] trapped write at >> >> > 0x0101011600 on channel >> 0x0001fed0 >> >> > [unknown] BAR/PFIFO_WRITE/IN reason: PAGE_NOT_PRESENT >> >> > >> >> > I will try next with the patch series you sent to Linus yesterday, to >> >> > see if that happens to fix this. >> >> >> >> Nope, with your patch series from yesterday the problem still exists. >> > >> > Just to double-check: Does the revert still work, even on latest upstream >> > git + Dave's pull request? >> >> Also what versions of userspace have you got, libdrm + >> xf86-video-nouveau and mesa? > > Yes, the revert still works. > > I have pretty old userspace, Fedora 14. > > libdrm is 2.4.22-1.fc14, mesa is 7.9-5.fc14. > > I don't have xf86-video-nouveau, I have > xorg-x11-drv-nouveau.x86_64 1:0.0.16-14.20101010git8c8f15c.fc14 Okay it all makes sense now! I'll revert the patch upstream then, older nouveau userspace used contexts, for what reason I've no idea :-) Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 05/20] drm: Extract add_hdmi_mode() out of do_hdmi_vsdb_modes()
So we respect a nice design of having similar functions at the same
level, in this case:
do_hdmi_vsdb_modes()
- add_hdmi_mandatory_stereo_modes()
- add_hdmi_mode()
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/drm_edid.c | 36 +---
1 file changed, 21 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 52e6087..7366007 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -2634,6 +2634,26 @@ static int add_hdmi_mandatory_stereo_modes(struct
drm_connector *connector)
return modes;
}
+static int add_hdmi_mode(struct drm_connector *connector, u8 vic)
+{
+ struct drm_device *dev = connector->dev;
+ struct drm_display_mode *newmode;
+
+ vic--; /* VICs start at 1 */
+ if (vic >= ARRAY_SIZE(edid_4k_modes)) {
+ DRM_ERROR("Unknown HDMI VIC: %d\n", vic);
+ return 0;
+ }
+
+ newmode = drm_mode_duplicate(dev, &edid_4k_modes[vic]);
+ if (!newmode)
+ return 0;
+
+ drm_mode_probed_add(connector, newmode);
+
+ return 1;
+}
+
/*
* do_hdmi_vsdb_modes - Parse the HDMI Vendor Specific data block
* @connector: connector corresponding to the HDMI sink
@@ -2646,7 +2666,6 @@ static int add_hdmi_mandatory_stereo_modes(struct
drm_connector *connector)
static int
do_hdmi_vsdb_modes(struct drm_connector *connector, const u8 *db, u8 len)
{
- struct drm_device *dev = connector->dev;
int modes = 0, offset = 0, i;
u8 vic_len;
@@ -2679,23 +2698,10 @@ do_hdmi_vsdb_modes(struct drm_connector *connector,
const u8 *db, u8 len)
vic_len = db[8 + offset] >> 5;
for (i = 0; i < vic_len && len >= (9 + offset + i); i++) {
- struct drm_display_mode *newmode;
u8 vic;
vic = db[9 + offset + i];
-
- vic--; /* VICs start at 1 */
- if (vic >= ARRAY_SIZE(edid_4k_modes)) {
- DRM_ERROR("Unknown HDMI VIC: %d\n", vic);
- continue;
- }
-
- newmode = drm_mode_duplicate(dev, &edid_4k_modes[vic]);
- if (!newmode)
- continue;
-
- drm_mode_probed_add(connector, newmode);
- modes++;
+ modes += add_hdmi_mode(connector, vic);
}
out:
--
1.8.3.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Regression: bisected: commit 7c510133d93 breaks video
On Fri, Sep 20, 2013 at 6:10 AM, Daniel Vetter wrote: > On Thu, Sep 19, 2013 at 06:32:47PM +, Paul Zimmerman wrote: >> > From: Paul Zimmerman >> > Sent: Thursday, September 19, 2013 11:21 AM >> > >> > > From: Dave Airlie [mailto:airl...@gmail.com] >> > > Sent: Wednesday, September 18, 2013 7:40 PM >> > > >> > > On Thu, Sep 19, 2013 at 12:02 PM, Paul Zimmerman >> > > wrote: >> > > > I have an ASUS P6X58D-Premium mobo with a GeForce 9400GT PCIe video >> > > > card. >> > > > With kernel 3.12-rc1, I get scrambled video on boot. Kernel 3.11 works >> > > > fine. >> > > > >> > > > Bisecting this, I found 7c510133d93dd6f15ca040733ba7b2891ed61fd1 "drm: >> > > > mark context support as a legacy subsystem" is the guilty commit. If I >> > > > revert that commit, the video works fine. >> > > > >> > > > Is there any more info I can provide? >> > > >> > > Full dmesg, and what driver you are using. >> > >> > Driver is nouveau. >> > >> > The dmesg from a good boot with the commit reverted is attached. >> > >> > For the bad boot, the dmesg log is filled with messages like this: >> > >> > [ 15.871667] nouveau E[ PFB][:03:00.0] trapped write at >> > 0x01010010a0 on channel 0x0001fed0 >> > [unknown] BAR/PFIFO_WRITE/IN reason: PAGE_NOT_PRESENT >> > [ 15.871698] nouveau E[ PFB][:03:00.0] trapped write at >> > 0x010100b2e0 on channel 0x0001fed0 >> > [unknown] BAR/PFIFO_WRITE/IN reason: PAGE_NOT_PRESENT >> > [ 15.871781] nouveau E[ PFB][:03:00.0] trapped write at >> > 0x0101011600 on channel 0x0001fed0 >> > [unknown] BAR/PFIFO_WRITE/IN reason: PAGE_NOT_PRESENT >> > >> > I will try next with the patch series you sent to Linus yesterday, to >> > see if that happens to fix this. >> >> Nope, with your patch series from yesterday the problem still exists. > > Just to double-check: Does the revert still work, even on latest upstream > git + Dave's pull request? Also what versions of userspace have you got, libdrm + xf86-video-nouveau and mesa? Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 17/20] drm/i915: Use adjusted_mode in the fastboot hack to disable pfit
When booting with i915.fastboot=1, we always take tha code path and end
up undoing what we're trying to do with adjusted_mode.
Hopefully, as the fastboot hardware readout code is using adjusted_mode
as well, it should be equivalent.
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/intel_display.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index f868266..2b9f80b 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2288,9 +2288,12 @@ intel_pipe_set_base(struct drm_crtc *crtc, int x, int y,
/* Update pipe size and adjust fitter if needed */
if (i915_fastboot) {
+ const struct drm_display_mode *adjusted_mode =
+ &intel_crtc->config.adjusted_mode;
+
I915_WRITE(PIPESRC(intel_crtc->pipe),
- ((crtc->mode.hdisplay - 1) << 16) |
- (crtc->mode.vdisplay - 1));
+ ((adjusted_mode->crtc_hdisplay - 1) << 16) |
+ (adjusted_mode->crtc_vdisplay - 1));
if (!intel_crtc->config.pch_pfit.enabled &&
(intel_pipe_has_type(crtc, INTEL_OUTPUT_LVDS) ||
intel_pipe_has_type(crtc, INTEL_OUTPUT_EDP))) {
--
1.8.3.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 06/20] drm: Reject modes with more than 1 stereo flags set
When setting a stereo 3D mode, there can be only one bit set describing the layout of the frambuffer(s). So reject invalid modes early. Signed-off-by: Damien Lespiau --- drivers/gpu/drm/drm_crtc.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c index 454ac8a..090415f 100644 --- a/drivers/gpu/drm/drm_crtc.c +++ b/drivers/gpu/drm/drm_crtc.c @@ -1319,6 +1319,10 @@ static int drm_crtc_convert_umode(struct drm_display_mode *out, if (in->clock > INT_MAX || in->vrefresh > INT_MAX) return -ERANGE; + /* At most, 1 set bit describing the 3D layout of the mode */ + if (hweight32(in->flags & DRM_MODE_FLAG_3D_MASK) > 1) + return -EINVAL; + out->clock = in->clock; out->hdisplay = in->hdisplay; out->hsync_start = in->hsync_start; -- 1.8.3.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 04/20] drm/edid: Expose mandatory stereo modes for HDMI sinks
For now, let's just look at the 3D_present flag of the CEA HDMI vendor
block to detect if the sink supports a small list of then mandatory 3D
formats.
See the HDMI 1.4a 3D extraction for detail:
http://www.hdmi.org/manufacturer/specification.aspx
v2: Rename freq to vrefresh, make the mandatory structure a bit more
compact, fix some white space issues and add a couple of const
(Ville Syrjälä)
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/drm_edid.c | 110 ++---
1 file changed, 103 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 1688ff5..52e6087 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -2553,13 +2553,95 @@ do_cea_modes(struct drm_connector *connector, const u8
*db, u8 len)
return modes;
}
+struct stereo_mandatory_mode {
+ int width, height, vrefresh;
+ unsigned int flags;
+};
+
+static const struct stereo_mandatory_mode stereo_mandatory_modes[] = {
+ { 1920, 1080, 24,
+ DRM_MODE_FLAG_3D_TOP_AND_BOTTOM | DRM_MODE_FLAG_3D_FRAME_PACKING },
+ { 1920, 1080, 50,
+ DRM_MODE_FLAG_INTERLACE | DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF },
+ { 1920, 1080, 60,
+ DRM_MODE_FLAG_INTERLACE | DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF },
+ { 1280, 720, 50,
+ DRM_MODE_FLAG_3D_TOP_AND_BOTTOM | DRM_MODE_FLAG_3D_FRAME_PACKING },
+ { 1280, 720, 60,
+ DRM_MODE_FLAG_3D_TOP_AND_BOTTOM | DRM_MODE_FLAG_3D_FRAME_PACKING }
+};
+
+static bool
+stereo_match_mandatory(const struct drm_display_mode *mode,
+ const struct stereo_mandatory_mode *stereo_mode)
+{
+ unsigned int interlaced = mode->flags & DRM_MODE_FLAG_INTERLACE;
+
+ return mode->hdisplay == stereo_mode->width &&
+ mode->vdisplay == stereo_mode->height &&
+ interlaced == (stereo_mode->flags & DRM_MODE_FLAG_INTERLACE) &&
+ drm_mode_vrefresh(mode) == stereo_mode->vrefresh;
+}
+
+static const struct stereo_mandatory_mode *
+hdmi_find_stereo_mandatory_mode(const struct drm_display_mode *mode)
+{
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(stereo_mandatory_modes); i++)
+ if (stereo_match_mandatory(mode, &stereo_mandatory_modes[i]))
+ return &stereo_mandatory_modes[i];
+
+ return NULL;
+}
+
+static int add_hdmi_mandatory_stereo_modes(struct drm_connector *connector)
+{
+ struct drm_device *dev = connector->dev;
+ const struct drm_display_mode *mode;
+ struct list_head stereo_modes;
+ int modes = 0;
+
+ INIT_LIST_HEAD(&stereo_modes);
+
+ list_for_each_entry(mode, &connector->probed_modes, head) {
+ const struct stereo_mandatory_mode *mandatory;
+ u32 stereo_layouts, layout;
+
+ mandatory = hdmi_find_stereo_mandatory_mode(mode);
+ if (!mandatory)
+ continue;
+
+ stereo_layouts = mandatory->flags & DRM_MODE_FLAG_3D_MASK;
+ do {
+ struct drm_display_mode *new_mode;
+
+ layout = 1 << (ffs(stereo_layouts) - 1);
+ stereo_layouts &= ~layout;
+
+ new_mode = drm_mode_duplicate(dev, mode);
+ if (!new_mode)
+ continue;
+
+ new_mode->flags |= layout;
+ list_add_tail(&new_mode->head, &stereo_modes);
+ modes++;
+ } while (stereo_layouts);
+ }
+
+ list_splice_tail(&stereo_modes, &connector->probed_modes);
+
+ return modes;
+}
+
/*
* do_hdmi_vsdb_modes - Parse the HDMI Vendor Specific data block
* @connector: connector corresponding to the HDMI sink
* @db: start of the CEA vendor specific block
* @len: length of the CEA block payload, ie. one can access up to db[len]
*
- * Parses the HDMI VSDB looking for modes to add to @connector.
+ * Parses the HDMI VSDB looking for modes to add to @connector. This function
+ * also adds the stereo 3d modes when applicable.
*/
static int
do_hdmi_vsdb_modes(struct drm_connector *connector, const u8 *db, u8 len)
@@ -2585,10 +2667,15 @@ do_hdmi_vsdb_modes(struct drm_connector *connector,
const u8 *db, u8 len)
/* the declared length is not long enough for the 2 first bytes
* of additional video format capabilities */
- offset += 2;
- if (len < (8 + offset))
+ if (len < (8 + offset + 2))
goto out;
+ /* 3D_Present */
+ offset++;
+ if (db[8 + offset] & (1 << 7))
+ modes += add_hdmi_mandatory_stereo_modes(connector);
+
+ offset++;
vic_len = db[8 + offset] >> 5;
for (i = 0; i < vic_len && len >= (9 + offset + i); i++) {
@@ -2668,8 +2755,8 @@ static int
add_cea_modes(struct drm_connector *connector, struct edid *edid)
{
c
Re: [Intel-gfx] [PATCH 19/20] drm/i915: Prefer crtc_{h|v}display for pipe src dimensions
On Thu, Sep 19, 2013 at 05:40:34PM +0100, Damien Lespiau wrote: > Now that we ask to adjust the crtc timings for stereo modes, the correct > pipe_src_w and pipe_src_h can be found in crtc_vdisplay and crtc_hdisplay. > > Signed-off-by: Damien Lespiau > --- > drivers/gpu/drm/i915/intel_display.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_display.c > b/drivers/gpu/drm/i915/intel_display.c > index 0573036..69d7167 100644 > --- a/drivers/gpu/drm/i915/intel_display.c > +++ b/drivers/gpu/drm/i915/intel_display.c > @@ -8425,9 +8425,6 @@ intel_modeset_pipe_config(struct drm_crtc *crtc, > drm_mode_copy(&pipe_config->adjusted_mode, mode); > drm_mode_copy(&pipe_config->requested_mode, mode); > > - pipe_config->pipe_src_w = mode->hdisplay; > - pipe_config->pipe_src_h = mode->vdisplay; > - > pipe_config->cpu_transcoder = > (enum transcoder) to_intel_crtc(crtc)->pipe; > pipe_config->shared_dpll = DPLL_ID_PRIVATE; > @@ -8462,6 +8459,9 @@ encoder_retry: > /* Fill in default crtc timings, allow encoders to overwrite them. */ > drm_mode_set_crtcinfo(&pipe_config->adjusted_mode, CRTC_STEREO_DOUBLE); > I think a oneline comment here to explain the ordering would be nice. -Daniel > + pipe_config->pipe_src_w = pipe_config->adjusted_mode.crtc_hdisplay; > + pipe_config->pipe_src_h = pipe_config->adjusted_mode.crtc_vdisplay; > + > /* Pass our mode to the connectors and the CRTC to give them a chance to >* adjust it according to limitations or connector properties, and also >* a chance to reject the mode entirely. > -- > 1.8.3.1 > > ___ > Intel-gfx mailing list > intel-...@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 03/20] drm: Add a STEREO_3D capability to the SET_CLIENT_CAP ioctl
This capability allows user space to control the delivery of modes with
the 3D flags set. This is to not play games with current user space
users not knowing anything about stereo 3D flags and that could try
to set a mode with one or several of those bits set.
So, the plan is to remove the stereo modes from the list of modes we
give to DRM clients by default, and let them through if we are being
told otherwise.
stereo_allowed is bound to the drm_file structure to make it a
per-client setting, not a global one.
v2: Replace clearing 3D flags by discarding the stereo modes now that
they are regular modes.
v3: SET_CAP -> SET_CLIENT_CAP rename (Chris Wilson)
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/drm_crtc.c | 19 ++-
drivers/gpu/drm/drm_ioctl.c | 14 +-
include/drm/drmP.h | 3 +++
include/uapi/drm/drm.h | 9 +
4 files changed, 43 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index e79577c..454ac8a 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1581,6 +1581,19 @@ out:
return ret;
}
+static bool drm_mode_expose_to_userspace(const struct drm_display_mode *mode,
+const struct drm_file *file_priv)
+{
+ /*
+* If user-space hasn't configured the driver to expose the stereo 3D
+* modes, don't expose them.
+*/
+ if (!file_priv->stereo_allowed && drm_mode_is_stereo(mode))
+ return false;
+
+ return true;
+}
+
/**
* drm_mode_getconnector - get connector configuration
* @dev: drm device for the ioctl
@@ -1646,7 +1659,8 @@ int drm_mode_getconnector(struct drm_device *dev, void
*data,
/* delayed so we get modes regardless of pre-fill_modes state */
list_for_each_entry(mode, &connector->modes, head)
- mode_count++;
+ if (drm_mode_expose_to_userspace(mode, file_priv))
+ mode_count++;
out_resp->connector_id = connector->base.id;
out_resp->connector_type = connector->connector_type;
@@ -1668,6 +1682,9 @@ int drm_mode_getconnector(struct drm_device *dev, void
*data,
copied = 0;
mode_ptr = (struct drm_mode_modeinfo __user *)(unsigned
long)out_resp->modes_ptr;
list_for_each_entry(mode, &connector->modes, head) {
+ if (!drm_mode_expose_to_userspace(mode, file_priv))
+ continue;
+
drm_crtc_convert_to_umode(&u_mode, mode);
if (copy_to_user(mode_ptr + copied,
&u_mode, sizeof(u_mode))) {
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index 15da412..dffc836 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -308,7 +308,19 @@ int drm_getcap(struct drm_device *dev, void *data, struct
drm_file *file_priv)
int
drm_setclientcap(struct drm_device *dev, void *data, struct drm_file
*file_priv)
{
- return -EINVAL;
+ struct drm_set_client_cap *req = data;
+
+ switch (req->capability) {
+ case DRM_CLIENT_CAP_STEREO_3D:
+ if (req->value > 1)
+ return -EINVAL;
+ file_priv->stereo_allowed = req->value;
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ return 0;
}
/**
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 782433b..da08697 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -433,6 +433,9 @@ struct drm_file {
struct drm_master *master; /* master this node is currently associated
with
N.B. not always minor->master */
+ /* true when the client has asked us to expose stereo 3D mode flags */
+ bool stereo_allowed;
+
/**
* fbs - List of framebuffers associated with this file.
*
diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
index 526baed..9b24d65 100644
--- a/include/uapi/drm/drm.h
+++ b/include/uapi/drm/drm.h
@@ -627,6 +627,15 @@ struct drm_get_cap {
__u64 value;
};
+/**
+ * DRM_CLIENT_CAP_STEREO_3D
+ *
+ * if set to 1, the DRM core will expose the stereo 3D capabilities of the
+ * monitor by advertising the supported 3D layouts in the flags of struct
+ * drm_mode_modeinfo.
+ */
+#define DRM_CLIENT_CAP_STEREO_3D 1
+
/** DRM_IOCTL_SET_CLIENT_CAP ioctl argument type */
struct drm_set_client_cap {
__u64 capability;
--
1.8.3.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 12/20] drm: Remove synth_clock from struct drm_display_mode
This field is unused. Garbage collect it.
Signed-off-by: Damien Lespiau
---
include/drm/drm_crtc.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 011baaa..8e9716e 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -156,7 +156,6 @@ struct drm_display_mode {
int height_mm;
/* Actual mode we give to hw */
- int synth_clock;
int crtc_hdisplay;
int crtc_hblank_start;
int crtc_hblank_end;
--
1.8.3.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 08/20] drm: Make drm_match_cea_mode() return the underlying 2D VIC for 3d modes
When scanning out a stereo mode, the AVI infoframe vic field has to be
the underlyng 2D VIC. Before that commit, we weren't matching the CEA
mode because of the extra stereo flag and then were setting the VIC
field in the AVI infoframe to 0.
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/drm_edid.c | 4 ++--
drivers/gpu/drm/drm_modes.c | 18 --
include/drm/drm_crtc.h | 2 +-
3 files changed, 15 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 0bae76d..48f1746 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -2404,7 +2404,7 @@ u8 drm_match_cea_mode(const struct drm_display_mode
*to_match)
if ((KHZ2PICOS(to_match->clock) == KHZ2PICOS(clock1) ||
KHZ2PICOS(to_match->clock) == KHZ2PICOS(clock2)) &&
- drm_mode_equal_no_clocks(to_match, cea_mode))
+ drm_mode_equal_no_clocks_no_stereo(to_match, cea_mode))
return mode + 1;
}
return 0;
@@ -2453,7 +2453,7 @@ static u8 drm_match_hdmi_mode(const struct
drm_display_mode *to_match)
if ((KHZ2PICOS(to_match->clock) == KHZ2PICOS(clock1) ||
KHZ2PICOS(to_match->clock) == KHZ2PICOS(clock2)) &&
- drm_mode_equal_no_clocks(to_match, hdmi_mode))
+ drm_mode_equal_no_clocks_no_stereo(to_match, hdmi_mode))
return mode + 1;
}
return 0;
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index fc2adb6..c2cb2c8 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -830,12 +830,16 @@ bool drm_mode_equal(const struct drm_display_mode *mode1,
const struct drm_displ
} else if (mode1->clock != mode2->clock)
return false;
- return drm_mode_equal_no_clocks(mode1, mode2);
+ if ((mode1->flags & DRM_MODE_FLAG_3D_MASK) !=
+ (mode2->flags & DRM_MODE_FLAG_3D_MASK))
+ return false;
+
+ return drm_mode_equal_no_clocks_no_stereo(mode1, mode2);
}
EXPORT_SYMBOL(drm_mode_equal);
/**
- * drm_mode_equal_no_clocks - test modes for equality
+ * drm_mode_equal_no_clocks_no_stereo - test modes for equality
* @mode1: first mode
* @mode2: second mode
*
@@ -843,12 +847,13 @@ EXPORT_SYMBOL(drm_mode_equal);
* None.
*
* Check to see if @mode1 and @mode2 are equivalent, but
- * don't check the pixel clocks.
+ * don't check the pixel clocks nor the stereo layout.
*
* RETURNS:
* True if the modes are equal, false otherwise.
*/
-bool drm_mode_equal_no_clocks(const struct drm_display_mode *mode1, const
struct drm_display_mode *mode2)
+bool drm_mode_equal_no_clocks_no_stereo(const struct drm_display_mode *mode1,
+ const struct drm_display_mode *mode2)
{
if (mode1->hdisplay == mode2->hdisplay &&
mode1->hsync_start == mode2->hsync_start &&
@@ -860,12 +865,13 @@ bool drm_mode_equal_no_clocks(const struct
drm_display_mode *mode1, const struct
mode1->vsync_end == mode2->vsync_end &&
mode1->vtotal == mode2->vtotal &&
mode1->vscan == mode2->vscan &&
- mode1->flags == mode2->flags)
+ (mode1->flags & ~DRM_MODE_FLAG_3D_MASK) ==
+(mode2->flags & ~DRM_MODE_FLAG_3D_MASK))
return true;
return false;
}
-EXPORT_SYMBOL(drm_mode_equal_no_clocks);
+EXPORT_SYMBOL(drm_mode_equal_no_clocks_no_stereo);
/**
* drm_mode_validate_size - make sure modes adhere to size constraints
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 825d6fa..6b7f9c7 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -989,7 +989,7 @@ extern void drm_mode_config_reset(struct drm_device *dev);
extern void drm_mode_config_cleanup(struct drm_device *dev);
extern void drm_mode_set_name(struct drm_display_mode *mode);
extern bool drm_mode_equal(const struct drm_display_mode *mode1, const struct
drm_display_mode *mode2);
-extern bool drm_mode_equal_no_clocks(const struct drm_display_mode *mode1,
const struct drm_display_mode *mode2);
+extern bool drm_mode_equal_no_clocks_no_stereo(const struct drm_display_mode
*mode1, const struct drm_display_mode *mode2);
extern int drm_mode_width(const struct drm_display_mode *mode);
extern int drm_mode_height(const struct drm_display_mode *mode);
--
1.8.3.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 09/20] drm: Carry over the stereo flags when adding the alternate mode
This allows to expose the alternate clock versions of the stereo modes. Signed-off-by: Damien Lespiau --- drivers/gpu/drm/drm_edid.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index 48f1746..c24af1d 100644 --- a/drivers/gpu/drm/drm_edid.c +++ b/drivers/gpu/drm/drm_edid.c @@ -2507,6 +2507,9 @@ add_alternate_cea_modes(struct drm_connector *connector, struct edid *edid) if (!newmode) continue; + /* Carry over the stereo flags */ + newmode->flags |= mode->flags & DRM_MODE_FLAG_3D_MASK; + /* * The current mode could be either variant. Make * sure to pick the "other" clock for the new mode. -- 1.8.3.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 07/20] drm: Set the relevant infoframe field when scanning out a 3D mode
When scanning out a 3D mode on HDMI, we need to send an HDMI infoframe
with the corresponding layout to the sink.
v2: Make s3d_structure_from_display_mode() less subtle (Ville Syrjälä)
Reviewed-by: Ville Syrjälä
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/drm_edid.c | 40 ++--
1 file changed, 38 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 7366007..0bae76d 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -3421,6 +3421,33 @@ drm_hdmi_avi_infoframe_from_display_mode(struct
hdmi_avi_infoframe *frame,
}
EXPORT_SYMBOL(drm_hdmi_avi_infoframe_from_display_mode);
+static enum hdmi_3d_structure
+s3d_structure_from_display_mode(const struct drm_display_mode *mode)
+{
+ u32 layout = mode->flags & DRM_MODE_FLAG_3D_MASK;
+
+ switch (layout) {
+ case DRM_MODE_FLAG_3D_FRAME_PACKING:
+ return HDMI_3D_STRUCTURE_FRAME_PACKING;
+ case DRM_MODE_FLAG_3D_FIELD_ALTERNATIVE:
+ return HDMI_3D_STRUCTURE_FIELD_ALTERNATIVE;
+ case DRM_MODE_FLAG_3D_LINE_ALTERNATIVE:
+ return HDMI_3D_STRUCTURE_LINE_ALTERNATIVE;
+ case DRM_MODE_FLAG_3D_SIDE_BY_SIDE_FULL:
+ return HDMI_3D_STRUCTURE_SIDE_BY_SIDE_FULL;
+ case DRM_MODE_FLAG_3D_L_DEPTH:
+ return HDMI_3D_STRUCTURE_L_DEPTH;
+ case DRM_MODE_FLAG_3D_L_DEPTH_GFX_GFX_DEPTH:
+ return HDMI_3D_STRUCTURE_L_DEPTH_GFX_GFX_DEPTH;
+ case DRM_MODE_FLAG_3D_TOP_AND_BOTTOM:
+ return HDMI_3D_STRUCTURE_TOP_AND_BOTTOM;
+ case DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF:
+ return HDMI_3D_STRUCTURE_SIDE_BY_SIDE_HALF;
+ default:
+ return HDMI_3D_STRUCTURE_INVALID;
+ }
+}
+
/**
* drm_hdmi_vendor_infoframe_from_display_mode() - fill an HDMI infoframe with
* data from a DRM display mode
@@ -3438,20 +3465,29 @@ drm_hdmi_vendor_infoframe_from_display_mode(struct
hdmi_vendor_infoframe *frame,
const struct drm_display_mode *mode)
{
int err;
+ u32 s3d_flags;
u8 vic;
if (!frame || !mode)
return -EINVAL;
vic = drm_match_hdmi_mode(mode);
- if (!vic)
+ s3d_flags = mode->flags & DRM_MODE_FLAG_3D_MASK;
+
+ if (!vic && !s3d_flags)
+ return -EINVAL;
+
+ if (vic && s3d_flags)
return -EINVAL;
err = hdmi_vendor_infoframe_init(frame);
if (err < 0)
return err;
- frame->vic = vic;
+ if (vic)
+ frame->vic = vic;
+ else
+ frame->s3d_struct = s3d_structure_from_display_mode(mode);
return 0;
}
--
1.8.3.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 10/20] drm: Make exposing stereo modes a per-connector opt-in
Just like with interlaced or double scan modes, make stereo modes a
per-connector opt-in to give a chance to driver authors to make it work
before enabling it.
Suggested-by: Daniel Vetter
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/drm_crtc_helper.c | 8 +++-
include/drm/drm_crtc.h| 2 ++
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_crtc_helper.c
b/drivers/gpu/drm/drm_crtc_helper.c
index c722c3b..4280e37 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -76,7 +76,8 @@ static void drm_mode_validate_flag(struct drm_connector
*connector,
{
struct drm_display_mode *mode;
- if (flags == (DRM_MODE_FLAG_DBLSCAN | DRM_MODE_FLAG_INTERLACE))
+ if (flags == (DRM_MODE_FLAG_DBLSCAN | DRM_MODE_FLAG_INTERLACE |
+ DRM_MODE_FLAG_3D_MASK))
return;
list_for_each_entry(mode, &connector->modes, head) {
@@ -86,6 +87,9 @@ static void drm_mode_validate_flag(struct drm_connector
*connector,
if ((mode->flags & DRM_MODE_FLAG_DBLSCAN) &&
!(flags & DRM_MODE_FLAG_DBLSCAN))
mode->status = MODE_NO_DBLESCAN;
+ if ((mode->flags & DRM_MODE_FLAG_3D_MASK) &&
+ !(flags & DRM_MODE_FLAG_3D_MASK))
+ mode->status = MODE_NO_STEREO;
}
return;
@@ -175,6 +179,8 @@ int drm_helper_probe_single_connector_modes(struct
drm_connector *connector,
mode_flags |= DRM_MODE_FLAG_INTERLACE;
if (connector->doublescan_allowed)
mode_flags |= DRM_MODE_FLAG_DBLSCAN;
+ if (connector->stereo_allowed)
+ mode_flags |= DRM_MODE_FLAG_3D_MASK;
drm_mode_validate_flag(connector, mode_flags);
list_for_each_entry(mode, &connector->modes, head) {
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 6b7f9c7..1b69407 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -108,6 +108,7 @@ enum drm_mode_status {
MODE_ONE_HEIGHT,/* only one height is supported */
MODE_ONE_SIZE, /* only one resolution is supported */
MODE_NO_REDUCED,/* monitor doesn't accept reduced blanking */
+MODE_NO_STEREO,/* stereo modes not supported */
MODE_UNVERIFIED = -3, /* mode needs to reverified */
MODE_BAD = -2, /* unspecified reason */
MODE_ERROR = -1/* error condition */
@@ -611,6 +612,7 @@ struct drm_connector {
int connector_type_id;
bool interlace_allowed;
bool doublescan_allowed;
+ bool stereo_allowed;
struct list_head modes; /* list of modes on this connector */
enum drm_connector_status status;
--
1.8.3.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 16/20] drm/i915: Use crtc_clock with the adjusted mode
struct drm_mode_display now has a separate crtc_ version of the clock to
be used when we're talking about the timings given to the harwadre (was
far as the mode is concerned).
This commit is really the result of a git grep adjusted_mode.*clock and
replacing those by adjusted_mode.crtc_clock. No functional change.
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/intel_crt.c | 2 +-
drivers/gpu/drm/i915/intel_display.c | 36 ++--
drivers/gpu/drm/i915/intel_dp.c | 11 +++
drivers/gpu/drm/i915/intel_drv.h | 2 +-
drivers/gpu/drm/i915/intel_dvo.c | 2 +-
drivers/gpu/drm/i915/intel_hdmi.c| 6 +++---
drivers/gpu/drm/i915/intel_lvds.c| 2 +-
drivers/gpu/drm/i915/intel_pm.c | 36 +++-
drivers/gpu/drm/i915/intel_sdvo.c| 2 +-
drivers/gpu/drm/i915/intel_tv.c | 2 +-
10 files changed, 57 insertions(+), 44 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm/i915/intel_crt.c
index 6f101d5..6568d4b 100644
--- a/drivers/gpu/drm/i915/intel_crt.c
+++ b/drivers/gpu/drm/i915/intel_crt.c
@@ -110,7 +110,7 @@ static void intel_crt_get_config(struct intel_encoder
*encoder,
if (HAS_PCH_SPLIT(dev_priv->dev))
ironlake_check_encoder_dotclock(pipe_config, dotclock);
- pipe_config->adjusted_mode.clock = dotclock;
+ pipe_config->adjusted_mode.crtc_clock = dotclock;
}
/* Note: The caller is required to filter out dpms modes not supported by the
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index fb769fe..f868266 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -740,14 +740,14 @@ bool intel_crtc_active(struct drm_crtc *crtc)
/* Be paranoid as we can arrive here with only partial
* state retrieved from the hardware during setup.
*
-* We can ditch the adjusted_mode.clock check as soon
+* We can ditch the adjusted_mode.crtc_clock check as soon
* as Haswell has gained clock readout/fastboot support.
*
* We can ditch the crtc->fb check as soon as we can
* properly reconstruct framebuffers.
*/
return intel_crtc->active && crtc->fb &&
- intel_crtc->config.adjusted_mode.clock;
+ intel_crtc->config.adjusted_mode.crtc_clock;
}
enum transcoder intel_pipe_to_cpu_transcoder(struct drm_i915_private *dev_priv,
@@ -2914,7 +2914,7 @@ static void lpt_program_iclkip(struct drm_crtc *crtc)
{
struct drm_device *dev = crtc->dev;
struct drm_i915_private *dev_priv = dev->dev_private;
- int clock = to_intel_crtc(crtc)->config.adjusted_mode.clock;
+ int clock = to_intel_crtc(crtc)->config.adjusted_mode.crtc_clock;
u32 divsel, phaseinc, auxdiv, phasedir = 0;
u32 temp;
@@ -2938,8 +2938,8 @@ static void lpt_program_iclkip(struct drm_crtc *crtc)
phaseinc = 0x20;
} else {
/* The iCLK virtual clock root frequency is in MHz,
-* but the adjusted_mode->clock in in KHz. To get the divisors,
-* it is necessary to divide one by another, so we
+* but the adjusted_mode->crtc_clock in in KHz. To get the
+* divisors, it is necessary to divide one by another, so we
* convert the virtual clock precision to KHz here for higher
* precision.
*/
@@ -4101,7 +4101,7 @@ retry:
*/
link_bw = intel_fdi_link_freq(dev) * MHz(100)/KHz(1)/10;
- fdi_dotclock = adjusted_mode->clock;
+ fdi_dotclock = adjusted_mode->crtc_clock;
lane = ironlake_get_lanes_required(fdi_dotclock, link_bw,
pipe_config->pipe_bpp);
@@ -4157,12 +4157,12 @@ static int intel_crtc_compute_config(struct intel_crtc
*crtc,
* otherwise pipe A only.
*/
if ((crtc->pipe == PIPE_A || IS_I915G(dev)) &&
- adjusted_mode->clock > clock_limit * 9 / 10) {
+ adjusted_mode->crtc_clock > clock_limit * 9 / 10) {
clock_limit *= 2;
pipe_config->double_wide = true;
}
- if (adjusted_mode->clock > clock_limit * 9 / 10)
+ if (adjusted_mode->crtc_clock > clock_limit * 9 / 10)
return -EINVAL;
}
@@ -4822,7 +4822,7 @@ static void intel_crtc_mode_from_pipe_config(struct
intel_crtc *intel_crtc,
crtc->mode.flags = pipe_config->adjusted_mode.flags;
- crtc->mode.clock = pipe_config->adjusted_mode.clock;
+ crtc->mode.clock = pipe_config->adjusted_mode.crtc_clock;
crtc->mode.flags |= pipe_config->adjusted_mode.flags;
}
@@ -7462,7 +7462,7 @@ static void i9xx_crtc_clock_get(struct intel_crtc *crtc,
/*
* This va
[PATCH 19/20] drm/i915: Prefer crtc_{h|v}display for pipe src dimensions
Now that we ask to adjust the crtc timings for stereo modes, the correct pipe_src_w and pipe_src_h can be found in crtc_vdisplay and crtc_hdisplay. Signed-off-by: Damien Lespiau --- drivers/gpu/drm/i915/intel_display.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 0573036..69d7167 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -8425,9 +8425,6 @@ intel_modeset_pipe_config(struct drm_crtc *crtc, drm_mode_copy(&pipe_config->adjusted_mode, mode); drm_mode_copy(&pipe_config->requested_mode, mode); - pipe_config->pipe_src_w = mode->hdisplay; - pipe_config->pipe_src_h = mode->vdisplay; - pipe_config->cpu_transcoder = (enum transcoder) to_intel_crtc(crtc)->pipe; pipe_config->shared_dpll = DPLL_ID_PRIVATE; @@ -8462,6 +8459,9 @@ encoder_retry: /* Fill in default crtc timings, allow encoders to overwrite them. */ drm_mode_set_crtcinfo(&pipe_config->adjusted_mode, CRTC_STEREO_DOUBLE); + pipe_config->pipe_src_w = pipe_config->adjusted_mode.crtc_hdisplay; + pipe_config->pipe_src_h = pipe_config->adjusted_mode.crtc_vdisplay; + /* Pass our mode to the connectors and the CRTC to give them a chance to * adjust it according to limitations or connector properties, and also * a chance to reject the mode entirely. -- 1.8.3.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 20/20] drm/i915: Allow stereo modes on HDMI
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/intel_hdmi.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index f21a57f..0d4403e 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1228,6 +1228,7 @@ void intel_hdmi_init_connector(struct intel_digital_port
*intel_dig_port,
connector->interlace_allowed = 1;
connector->doublescan_allowed = 0;
+ connector->stereo_allowed = 1;
switch (port) {
case PORT_B:
--
1.8.3.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 43341] CoreBreach: Crash in r600_update_derived_state
https://bugs.freedesktop.org/show_bug.cgi?id=43341 Sven Arvidsson changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Sven Arvidsson --- This is no longer a problem with Mesa 9.2 and CoreBreach 1.1.5, not sure if it was fixed in the driver or the game but no reason to keep the bug open. -- 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 68235] Display freezes after login with kernel 3.11.0-rc5 on Cayman with dpm=1
https://bugs.freedesktop.org/show_bug.cgi?id=68235 --- Comment #43 from Alexandre Demers --- Created attachment 86168 --> https://bugs.freedesktop.org/attachment.cgi?id=86168&action=edit dmesg with 86147 -- 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 11/20] drm: Remove clock_index from struct drm_display_mode
On Fri, Sep 20, 2013 at 2:40 AM, Damien Lespiau
wrote:
> This field was only accessed by the nouveau driver, but never set. So
> concluded we can rid of this one.
>
> Cc: Ben Skeggs
> Signed-off-by: Damien Lespiau
Acked-by: Ben Skeggs
> ---
> drivers/gpu/drm/nouveau/dispnv04/crtc.c | 2 --
> include/drm/drm_crtc.h | 1 -
> 2 files changed, 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/dispnv04/crtc.c
> b/drivers/gpu/drm/nouveau/dispnv04/crtc.c
> index d4fbf11..0e3270c 100644
> --- a/drivers/gpu/drm/nouveau/dispnv04/crtc.c
> +++ b/drivers/gpu/drm/nouveau/dispnv04/crtc.c
> @@ -326,8 +326,6 @@ nv_crtc_mode_set_vga(struct drm_crtc *crtc, struct
> drm_display_mode *mode)
> regp->MiscOutReg = 0x23;/* +hsync +vsync */
> }
>
> - regp->MiscOutReg |= (mode->clock_index & 0x03) << 2;
> -
> /*
> * Time Sequencer
> */
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index 1b69407..011baaa 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -156,7 +156,6 @@ struct drm_display_mode {
> int height_mm;
>
> /* Actual mode we give to hw */
> - int clock_index;
> int synth_clock;
> int crtc_hdisplay;
> int crtc_hblank_start;
> --
> 1.8.3.1
>
> ___
> 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
[Bug 64810] EGL/Gles/Weston give segfault on RADEONSI with egl_gallium.so
https://bugs.freedesktop.org/show_bug.cgi?id=64810
Johannes Obermayr changed:
What|Removed |Added
Attachment #86034|0 |1
is obsolete||
--- Comment #26 from Johannes Obermayr ---
Created attachment 86169
--> https://bugs.freedesktop.org/attachment.cgi?id=86169&action=edit
New version.
I renamed r600_ functions to si_ in radeonsi to avoid duplicate symbols.
Some duplicate code is now in radeon/r600_{blit,texture}_common.{c,h}.
Tested on AMD Fusion [Radeon HD 6310].
Built with:
../configure --enable-xvmc --enable-vdpau --enable-texture-float --enable-debug
--with-dri-drivers="" --with-gallium-drivers=r600,radeonsi --enable-dri
--enable-glx --enable-osmesa --enable-gles1 --enable-gles2 --enable-openvg
--enable-gbm --enable-xa --enable-gallium-egl --enable-gallium-llvm
--enable-gallium-gbm --enable-r600-llvm-compiler --enable-opencl
--
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
linux-next: manual merge of the drm-intel tree with the drm-intel-fixes tree
Hi all,
Today's linux-next merge of the drm-intel tree got a conflict in
drivers/gpu/drm/i915/intel_display.c between commit cc173961a680
("drm/i915: do not update cursor in crtc mode set") from the
drm-intel-fixes tree and commit e9fd1c02aca7 ("drm/i915: don't enable
DPLL for DSI") from the drm-intel tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc drivers/gpu/drm/i915/intel_display.c
index d8a1d98,2ed974e..000
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@@ -4863,21 -4915,27 +4915,24 @@@ static int i9xx_crtc_mode_set(struct dr
refclk = i9xx_get_refclk(crtc, num_connectors);
- /*
-* Returns a set of divisors for the desired target clock with the given
-* refclk, or FALSE. The returned values represent the clock equation:
-* reflck * (5 * (m1 + 2) + (m2 + 2)) / (n + 2) / p1 / p2.
-*/
- limit = intel_limit(crtc, refclk);
- ok = dev_priv->display.find_dpll(limit, crtc,
-intel_crtc->config.port_clock,
-refclk, NULL, &clock);
- if (!ok && !intel_crtc->config.clock_set) {
- DRM_ERROR("Couldn't find PLL settings for mode!\n");
- return -EINVAL;
+ if (!is_dsi && !intel_crtc->config.clock_set) {
+ /*
+* Returns a set of divisors for the desired target clock with
+* the given refclk, or FALSE. The returned values represent
+* the clock equation: reflck * (5 * (m1 + 2) + (m2 + 2)) / (n +
+* 2) / p1 / p2.
+*/
+ limit = intel_limit(crtc, refclk);
+ ok = dev_priv->display.find_dpll(limit, crtc,
+intel_crtc->config.port_clock,
+refclk, NULL, &clock);
+ if (!ok && !intel_crtc->config.clock_set) {
+ DRM_ERROR("Couldn't find PLL settings for mode!\n");
+ return -EINVAL;
+ }
}
- if (is_lvds && dev_priv->lvds_downclock_avail) {
- /* Ensure that the cursor is valid for the new mode before changing...
*/
- intel_crtc_update_cursor(crtc, true);
-
+ if (!is_dsi && is_lvds && dev_priv->lvds_downclock_avail) {
/*
* Ensure we match the reduced clock's P to the target clock.
* If the clocks don't match, we can't switch the display clock
@@@ -8199,11 -8377,11 +8371,12 @@@ static void intel_dump_pipe_config(stru
pipe_config->gmch_pfit.control,
pipe_config->gmch_pfit.pgm_ratios,
pipe_config->gmch_pfit.lvds_border_bits);
- DRM_DEBUG_KMS("pch pfit: pos: 0x%08x, size: 0x%08x\n",
+ DRM_DEBUG_KMS("pch pfit: pos: 0x%08x, size: 0x%08x, %s\n",
pipe_config->pch_pfit.pos,
-pipe_config->pch_pfit.size);
+pipe_config->pch_pfit.size,
+pipe_config->pch_pfit.enabled ? "enabled" : "disabled");
DRM_DEBUG_KMS("ips: %i\n", pipe_config->ips_enabled);
+ DRM_DEBUG_KMS("double wide: %i\n", pipe_config->double_wide);
}
static bool check_encoder_cloning(struct drm_crtc *crtc)
pgp0SIXdb8jvg.pgp
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 68451] Texture flicker in native Dota2 in mesa 9.2.0rc1
https://bugs.freedesktop.org/show_bug.cgi?id=68451 --- Comment #20 from Peter Kraus --- Hello, I wont be able to test it until October. Will update then, unless someone else can test it instead. Peter -- 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: Regression: bisected: commit 7c510133d93 breaks video
> From: Paul Zimmerman > Sent: Thursday, September 19, 2013 11:21 AM > > > From: Dave Airlie [mailto:airl...@gmail.com] > > Sent: Wednesday, September 18, 2013 7:40 PM > > > > On Thu, Sep 19, 2013 at 12:02 PM, Paul Zimmerman > > wrote: > > > I have an ASUS P6X58D-Premium mobo with a GeForce 9400GT PCIe video card. > > > With kernel 3.12-rc1, I get scrambled video on boot. Kernel 3.11 works > > > fine. > > > > > > Bisecting this, I found 7c510133d93dd6f15ca040733ba7b2891ed61fd1 "drm: > > > mark context support as a legacy subsystem" is the guilty commit. If I > > > revert that commit, the video works fine. > > > > > > Is there any more info I can provide? > > > > Full dmesg, and what driver you are using. > > Driver is nouveau. > > The dmesg from a good boot with the commit reverted is attached. > > For the bad boot, the dmesg log is filled with messages like this: > > [ 15.871667] nouveau E[ PFB][:03:00.0] trapped write at > 0x01010010a0 on channel 0x0001fed0 > [unknown] BAR/PFIFO_WRITE/IN reason: PAGE_NOT_PRESENT > [ 15.871698] nouveau E[ PFB][:03:00.0] trapped write at > 0x010100b2e0 on channel 0x0001fed0 > [unknown] BAR/PFIFO_WRITE/IN reason: PAGE_NOT_PRESENT > [ 15.871781] nouveau E[ PFB][:03:00.0] trapped write at > 0x0101011600 on channel 0x0001fed0 > [unknown] BAR/PFIFO_WRITE/IN reason: PAGE_NOT_PRESENT > > I will try next with the patch series you sent to Linus yesterday, to > see if that happens to fix this. Nope, with your patch series from yesterday the problem still exists. -- Paul ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Regression: bisected: commit 7c510133d93 breaks video
> From: Dave Airlie [mailto:airlied at gmail.com] > Sent: Wednesday, September 18, 2013 7:40 PM > > On Thu, Sep 19, 2013 at 12:02 PM, Paul Zimmerman > wrote: > > I have an ASUS P6X58D-Premium mobo with a GeForce 9400GT PCIe video card. > > With kernel 3.12-rc1, I get scrambled video on boot. Kernel 3.11 works > > fine. > > > > Bisecting this, I found 7c510133d93dd6f15ca040733ba7b2891ed61fd1 "drm: > > mark context support as a legacy subsystem" is the guilty commit. If I > > revert that commit, the video works fine. > > > > Is there any more info I can provide? > > Full dmesg, and what driver you are using. Driver is nouveau. The dmesg from a good boot with the commit reverted is attached. For the bad boot, the dmesg log is filled with messages like this: [ 15.871667] nouveau E[ PFB][:03:00.0] trapped write at 0x01010010a0 on channel 0x0001fed0 [unknown] BAR/PFIFO_WRITE/IN reason: PAGE_NOT_PRESENT [ 15.871698] nouveau E[ PFB][:03:00.0] trapped write at 0x010100b2e0 on channel 0x0001fed0 [unknown] BAR/PFIFO_WRITE/IN reason: PAGE_NOT_PRESENT [ 15.871781] nouveau E[ PFB][:03:00.0] trapped write at 0x0101011600 on channel 0x0001fed0 [unknown] BAR/PFIFO_WRITE/IN reason: PAGE_NOT_PRESENT I will try next with the patch series you sent to Linus yesterday, to see if that happens to fix this. -- Paul -- next part -- A non-text attachment was scrubbed... Name: dmesg-good.log Type: application/octet-stream Size: 94912 bytes Desc: dmesg-good.log URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130919/28b8dda0/attachment-0001.obj>
Regression: bisected: commit 7c510133d93 breaks video
> From: Paul Zimmerman > Sent: Thursday, September 19, 2013 11:33 AM > > > From: Paul Zimmerman > > Sent: Thursday, September 19, 2013 11:21 AM > > > > > From: Dave Airlie [mailto:airlied at gmail.com] > > > Sent: Wednesday, September 18, 2013 7:40 PM > > > > > > On Thu, Sep 19, 2013 at 12:02 PM, Paul Zimmerman > > > wrote: > > > > I have an ASUS P6X58D-Premium mobo with a GeForce 9400GT PCIe video > > > > card. > > > > With kernel 3.12-rc1, I get scrambled video on boot. Kernel 3.11 works > > > > fine. > > > > > > > > Bisecting this, I found 7c510133d93dd6f15ca040733ba7b2891ed61fd1 "drm: > > > > mark context support as a legacy subsystem" is the guilty commit. If I > > > > revert that commit, the video works fine. > > > > > > > > Is there any more info I can provide? > > > > > > Full dmesg, and what driver you are using. > > > > Driver is nouveau. > > > > The dmesg from a good boot with the commit reverted is attached. > > > > For the bad boot, the dmesg log is filled with messages like this: > > > > [ 15.871667] nouveau E[ PFB][:03:00.0] trapped write at > > 0x01010010a0 on channel 0x0001fed0 > > [unknown] BAR/PFIFO_WRITE/IN reason: PAGE_NOT_PRESENT > > [ 15.871698] nouveau E[ PFB][:03:00.0] trapped write at > > 0x010100b2e0 on channel 0x0001fed0 > > [unknown] BAR/PFIFO_WRITE/IN reason: PAGE_NOT_PRESENT > > [ 15.871781] nouveau E[ PFB][:03:00.0] trapped write at > > 0x0101011600 on channel 0x0001fed0 > > [unknown] BAR/PFIFO_WRITE/IN reason: PAGE_NOT_PRESENT > > > > I will try next with the patch series you sent to Linus yesterday, to > > see if that happens to fix this. > > Nope, with your patch series from yesterday the problem still exists. For the bad boot, I found some boot messages in /var/log/messages. Truncated version attached. -- Paul -- next part -- A non-text attachment was scrubbed... Name: messages-bad.log Type: application/octet-stream Size: 96871 bytes Desc: messages-bad.log URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130919/19827837/attachment-0001.obj>
