[PATCH 2/2] drm/doc: Document the KMS property API

[Laurent Pinchart]

Hi Hans,

Thanks for the review.

On Saturday 22 June 2013 15:32:43 Hans Verkuil wrote:
> Hi Laurent,
> 
> Is this a hint to me that V4L2 should have a property API as well? :-)

Honestly, not at all, but I'm of course willing to discuss the subject ;-)

> Anyway, I found some typos below:

Thank you. I'll fix them in v2.

-- 
Regards,

Laurent Pinchart

[PATCH v2 2/2] drm/doc: Document the KMS property API

[Laurent Pinchart]

Signed-off-by: Laurent Pinchart 
Reviewed-by: Alex Deucher 
---
 Documentation/DocBook/drm.tmpl | 143 +
 1 file changed, 143 insertions(+)

diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
index cea420d..4d54ac8 100644
--- a/Documentation/DocBook/drm.tmpl
+++ b/Documentation/DocBook/drm.tmpl
@@ -1236,6 +1236,15 @@ int max_width, max_height;
   Miscellaneous
   
 
+  void (*set_property)(struct drm_crtc *crtc,
+ struct drm_property *property, uint64_t value);
+  
+Set the value of the given CRTC property to
+value. See 
+for more information about properties.
+  
+
+
   void (*gamma_set)(struct drm_crtc *crtc, u16 *r, u16 
*g, u16 *b,
 uint32_t start, uint32_t size);
   
@@ -1385,6 +1394,15 @@ int max_width, max_height;
   .
 
   
+  
+void (*set_property)(struct drm_plane *plane,
+ struct drm_property *property, uint64_t value);
+
+  Set the value of the given plane property to
+  value. See 
+  for more information about properties.
+
+  
 
   
 
@@ -1594,6 +1612,15 @@ int max_width, max_height;
   Miscellaneous
   
 
+  void (*set_property)(struct drm_connector *connector,
+ struct drm_property *property, uint64_t value);
+  
+Set the value of the given connector property to
+value. See 
+for more information about properties.
+  
+
+
   void (*destroy)(struct drm_connector 
*connector);
   
 Destroy the connector when not needed anymore. See
@@ -2187,6 +2214,122 @@ void intel_crt_init(struct drm_device *dev)
 
   

+  
+
+  
+KMS Properties
+
+  Drivers may need to expose additional parameters to applications than
+  those described in the previous sections. KMS supports attaching
+  properties to CRTCs, connectors and planes and offers a userspace API to
+  list, get and set the property values.
+
+
+  Properties are identified by a name that uniquely defines the property
+  purpose, and store an associated value. For all property types except 
blob
+  properties the value is a 64-bit unsigned integer.
+
+
+  KMS differentiates between properties and property instances. Drivers
+  first create properties and then create and associate individual 
instances
+  of those properties to objects. A property can be instantiated multiple
+  times and associated with different objects. Values are stored in 
property
+  instances, and all other property information are stored in the propery
+  and shared between all instances of the property.
+
+
+  Every property is created with a type that influences how the KMS core
+  handles the property. Supported property types are
+  
+
+  DRM_MODE_PROP_RANGE
+  Range properties report their minimum and maximum
+admissible values. The KMS core verifies that values set by
+application fit in that range.
+
+
+  DRM_MODE_PROP_ENUM
+  Enumerated properties take a numerical value that
+ranges from 0 to the number of enumerated values defined by the
+property minus one, and associate a free-formed string name to each
+value. Applications can retrieve the list of defined value-name 
pairs
+and use the numerical value to get and set property instance 
values.
+
+
+
+  DRM_MODE_PROP_BITMASK
+  Bitmask properties are enumeration properties that
+additionally restrict all enumerated values to the 0..63 range.
+Bitmask property instance values combine one or more of the
+enumerated bits defined by the property.
+
+
+  DRM_MODE_PROP_BLOB
+  Blob properties store a binary blob without any 
format
+restriction. The binary blobs are created as KMS standalone 
objects,
+and blob property instance values store the ID of their associated
+blob object.
+   Blob properties are only used for the connector EDID property
+   and cannot be created by drivers.
+
+  
+
+
+  To create a property drivers call one of the following functions 
depending
+  on the property type. All property creation functions take property flags
+  and name, as well as type-specific arguments.
+  
+
+  struct drm_property 

[PATCH v2 1/2] drm/doc: Remove outdated note about i915 driver not behaving properly

[Laurent Pinchart]

From: Laurent Pinchart 

The i915 driver has been fixed not to modify the mode argument of the
encoder mode_fixup operation. Remove the related comment from the
documentation.

Signed-off-by: Laurent Pinchart 
Reviewed-by: Alex Deucher 
---
 Documentation/DocBook/drm.tmpl | 4 
 1 file changed, 4 deletions(-)

diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
index a608094..cea420d 100644
--- a/Documentation/DocBook/drm.tmpl
+++ b/Documentation/DocBook/drm.tmpl
@@ -1868,10 +1868,6 @@ void intel_crt_init(struct drm_device *dev)
   bool (*mode_fixup)(struct drm_encoder *encoder,
const struct drm_display_mode *mode,
struct drm_display_mode *adjusted_mode);
-  
-FIXME: The mode argument be const, but the i915 driver modifies
-mode-clock in intel_dp_mode_fixup.
-  
   
 Let encoders adjust the requested mode or reject it completely. 
This
 operation returns true if the mode is accepted (possibly after 
being
-- 
1.8.1.5

[PATCH v2 0/2] Documentation improvements

[Laurent Pinchart]

Hello,

Here are two patches that improve the DRM documentation by documenting the KMS
property API, and removing an outdated note about the i915 driver.

Changes since v1:

- Fixed typos in patch 2/2

Laurent Pinchart (2):
  drm/doc: Remove outdated note about i915 driver not behaving properly
  drm/doc: Document the KMS property API

 Documentation/DocBook/drm.tmpl | 147 +++--
 1 file changed, 143 insertions(+), 4 deletions(-)

-- 
Regards,

Laurent Pinchart

[PATCH 2/2] drm/doc: Document the KMS property API

[Hans Verkuil]

Hi Laurent,

Is this a hint to me that V4L2 should have a property API as well? :-)

Anyway, I found some typos below:

On Sat June 22 2013 15:00:27 Laurent Pinchart wrote:
> Signed-off-by: Laurent Pinchart 
> ---
>  Documentation/DocBook/drm.tmpl | 143 
> +
>  1 file changed, 143 insertions(+)
> 
> diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
> index cea420d..9d4bb06 100644
> --- a/Documentation/DocBook/drm.tmpl
> +++ b/Documentation/DocBook/drm.tmpl
> @@ -1236,6 +1236,15 @@ int max_width, max_height;
>Miscellaneous
>
>  
> +  void (*set_property)(struct drm_crtc *crtc,
> + struct drm_property *property, uint64_t 
> value);
> +  
> +Set the value of the given CRTC property to
> +value. See  linkend="drm-kms-properties"/>
> +for more information about properties.
> +  
> +
> +
>void (*gamma_set)(struct drm_crtc *crtc, u16 *r, u16 
> *g, u16 *b,
>  uint32_t start, uint32_t size);
>
> @@ -1385,6 +1394,15 @@ int max_width, max_height;
>.
>  
>
> +  
> +void (*set_property)(struct drm_plane *plane,
> + struct drm_property *property, uint64_t 
> value);
> +
> +  Set the value of the given plane property to
> +  value. See  linkend="drm-kms-properties"/>
> +  for more information about properties.
> +
> +  
>  
>
>  
> @@ -1594,6 +1612,15 @@ int max_width, max_height;
>Miscellaneous
>
>  
> +  void (*set_property)(struct drm_connector *connector,
> + struct drm_property *property, uint64_t 
> value);
> +  
> +Set the value of the given connector property to
> +value. See  linkend="drm-kms-properties"/>
> +for more information about properties.
> +  
> +
> +
>void (*destroy)(struct drm_connector 
> *connector);
>
>  Destroy the connector when not needed anymore. See
> @@ -2187,6 +2214,122 @@ void intel_crt_init(struct drm_device *dev)
>  
>
>  
> +  
> +
> +  
> +KMS Properties
> +
> +  Drivers may need to expose additional parameters to applications than
> +  those described in the previous sections. KMS supports attaching
> +  properties to CRTCs, connectors and planes and offers a userspace API 
> to
> +  list, get and set the property values.
> +
> +
> +  Properties are identified by a name that uniquely defines the property
> +  purpose, and store an associated value. For all property types except 
> blob
> +  properties the value is a 64-bit unsigned integer.
> +
> +
> +  KMS differentiates between properties and property instances. Drivers
> +  first create properties and then create and associate individual 
> instances
> +  of those properties to objects. A property can be instantiated multiple
> +  times and associated with different objects. Values are stored in 
> property
> +  instances, and all other property information are stored in the propery
> +  and shared between all instances of the property.
> +
> +
> +  Every property is created with a type that influences how the KMS core
> +  handles the property. Supported property types are
> +  
> +
> +  DRM_MODE_PROP_RANGE
> +  Ranges properties report their minimum and maximum

s/Ranges/Range/

> +admissible values. The KMS core verifies that values set by
> +application fit in that range.
> +
> +
> +  DRM_MODE_PROP_ENUM
> +  Enumerated properties take a numerical value that
> +ranges from 0 to the number of enumered values defined by the

s/enumered/enumerated/

> +property minus one, and associate a free-formed string name to 
> each
> +value. Application can retrieve the list of define value-name 
> pairs

s/Application/Applications/
s/define/defined/

> +and use the numerical value to get and set property instance 
> values.
> +
> +
> +
> +  DRM_MODE_PROP_BITMASK
> +  Bitmask properties are enumeration properties that
> +additionally restrict all enumerated values to the 0..63 range.
> +Bitmask property instance values combine one or more of the
> +enumerated bits defined by the property.
> +
> +
> +  DRM_MODE_PROP_BLOB
> +  Blob properties store a binary blob without any 
> format
> +

Regression introduced by 90797e6d1ec0dfde6ba62a48b9ee3803887d6ed4 ("drm/i915: create compact dma scatter lists for gem objects") Was:Re: i915 mapping large (3MB) scatter list, hitting limits on certai

[Chris Wilson]

On Fri, Jun 21, 2013 at 10:03:43PM -0400, Konrad Rzeszutek Wilk wrote:
> On Fri, Jun 21, 2013 at 03:28:28PM -0400, Konrad Rzeszutek Wilk wrote:
> > Hey,
> 
> CC-ing Imre,
> 
> Imre, your patch 90797e6d1ec0dfde6ba62a48b9ee3803887d6ed4
> ("drm/i915: create compact dma scatter lists for gem objects") is the cause
> of the regression.
> 
> If I revert your patch it boots fine without any trouble.
> 
> I am not entirely sure why that is - as I added some debug code in
> lib/swiotlb.c to trigger when it can't find 3MB  area (which
> is what I thought initially was the issue) - but none of the debug
> code seems to be hit.
> 
> Any thoughts?

You should be hitting drivers/iommu/intel-iommu.c for the dma
translation. It looks like the contiguous 3MiB segment will be special
as it is the first sg that __domain_mapping() will attempt to allocate a
superpage (2MiB) for. What goes wrong at point, I am not sure, but I
would suggest peppering intel-iommu.c with printk to track down the error.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[PATCH 2/2] drm/doc: Document the KMS property API

[Laurent Pinchart]

Signed-off-by: Laurent Pinchart 
---
 Documentation/DocBook/drm.tmpl | 143 +
 1 file changed, 143 insertions(+)

diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
index cea420d..9d4bb06 100644
--- a/Documentation/DocBook/drm.tmpl
+++ b/Documentation/DocBook/drm.tmpl
@@ -1236,6 +1236,15 @@ int max_width, max_height;
   Miscellaneous
   
 
+  void (*set_property)(struct drm_crtc *crtc,
+ struct drm_property *property, uint64_t value);
+  
+Set the value of the given CRTC property to
+value. See 
+for more information about properties.
+  
+
+
   void (*gamma_set)(struct drm_crtc *crtc, u16 *r, u16 
*g, u16 *b,
 uint32_t start, uint32_t size);
   
@@ -1385,6 +1394,15 @@ int max_width, max_height;
   .
 
   
+  
+void (*set_property)(struct drm_plane *plane,
+ struct drm_property *property, uint64_t value);
+
+  Set the value of the given plane property to
+  value. See 
+  for more information about properties.
+
+  
 
   
 
@@ -1594,6 +1612,15 @@ int max_width, max_height;
   Miscellaneous
   
 
+  void (*set_property)(struct drm_connector *connector,
+ struct drm_property *property, uint64_t value);
+  
+Set the value of the given connector property to
+value. See 
+for more information about properties.
+  
+
+
   void (*destroy)(struct drm_connector 
*connector);
   
 Destroy the connector when not needed anymore. See
@@ -2187,6 +2214,122 @@ void intel_crt_init(struct drm_device *dev)
 
   

+  
+
+  
+KMS Properties
+
+  Drivers may need to expose additional parameters to applications than
+  those described in the previous sections. KMS supports attaching
+  properties to CRTCs, connectors and planes and offers a userspace API to
+  list, get and set the property values.
+
+
+  Properties are identified by a name that uniquely defines the property
+  purpose, and store an associated value. For all property types except 
blob
+  properties the value is a 64-bit unsigned integer.
+
+
+  KMS differentiates between properties and property instances. Drivers
+  first create properties and then create and associate individual 
instances
+  of those properties to objects. A property can be instantiated multiple
+  times and associated with different objects. Values are stored in 
property
+  instances, and all other property information are stored in the propery
+  and shared between all instances of the property.
+
+
+  Every property is created with a type that influences how the KMS core
+  handles the property. Supported property types are
+  
+
+  DRM_MODE_PROP_RANGE
+  Ranges properties report their minimum and maximum
+admissible values. The KMS core verifies that values set by
+application fit in that range.
+
+
+  DRM_MODE_PROP_ENUM
+  Enumerated properties take a numerical value that
+ranges from 0 to the number of enumered values defined by the
+property minus one, and associate a free-formed string name to each
+value. Application can retrieve the list of define value-name pairs
+and use the numerical value to get and set property instance 
values.
+
+
+
+  DRM_MODE_PROP_BITMASK
+  Bitmask properties are enumeration properties that
+additionally restrict all enumerated values to the 0..63 range.
+Bitmask property instance values combine one or more of the
+enumerated bits defined by the property.
+
+
+  DRM_MODE_PROP_BLOB
+  Blob properties store a binary blob without any 
format
+restriction. The binary blobs are created as KMS standalone 
objects,
+and blob property instance values store the ID of their associated
+blob object.
+   Blocb properties are only used for the connector EDID property
+   and cannot be created by drivers.
+
+  
+
+
+  To create a property drivers call one of the following functions 
depending
+  on the property type. All property creation functions take property flags
+  and name, as well as type-specific arguments.
+  
+
+  struct drm_property *drm_property_create_range(struct 

[PATCH 1/2] drm/doc: Remove outdated note about i915 driver not behaving properly

[Laurent Pinchart]

From: Laurent Pinchart 

The i915 driver has been fixed not to modify the mode argument of the
encoder mode_fixup operation. Remove the related comment from the
documentation.

Signed-off-by: Laurent Pinchart 
---
 Documentation/DocBook/drm.tmpl | 4 
 1 file changed, 4 deletions(-)

diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
index a608094..cea420d 100644
--- a/Documentation/DocBook/drm.tmpl
+++ b/Documentation/DocBook/drm.tmpl
@@ -1868,10 +1868,6 @@ void intel_crt_init(struct drm_device *dev)
   bool (*mode_fixup)(struct drm_encoder *encoder,
const struct drm_display_mode *mode,
struct drm_display_mode *adjusted_mode);
-  
-FIXME: The mode argument be const, but the i915 driver modifies
-mode-clock in intel_dp_mode_fixup.
-  
   
 Let encoders adjust the requested mode or reject it completely. 
This
 operation returns true if the mode is accepted (possibly after 
being
-- 
1.8.1.5

[PATCH 0/2] Documentation improvements

[Laurent Pinchart]

Hello,

Here are two patches that improve the DRM documentation by documenting the KMS
property API, and removing an outdated note about the i915 driver.

Laurent Pinchart (2):
  drm/doc: Remove outdated note about i915 driver not behaving properly
  drm/doc: Document the KMS property API

 Documentation/DocBook/drm.tmpl | 147 +++--
 1 file changed, 143 insertions(+), 4 deletions(-)

-- 
Regards,

Laurent Pinchart

[PATCH 2/2] drm: Convert drm class driver from legacy pm ops to dev_pm_ops

[Shuah Khan]

Convert drivers/gpu/drm class to use dev_pm_ops for power management and
remove Legacy PM ops hooks. With this change, drm class registers
suspend/resume callbacks via class->pm (dev_pm_ops) instead of Legacy
class->suspend/resume. When __device_suspend() runs call-backs, it will
find class->pm ops for the drm class.

Signed-off-by: Shuah Khan 
---
 drivers/gpu/drm/drm_sysfs.c |   13 +
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c
index 0229665..8d94778 100644
--- a/drivers/gpu/drm/drm_sysfs.c
+++ b/drivers/gpu/drm/drm_sysfs.c
@@ -37,7 +37,7 @@ static struct device_type drm_sysfs_device_minor = {
  * Just figures out what the actual struct drm_device associated with
  * @dev is and calls its suspend hook, if present.
  */
-static int drm_class_suspend(struct device *dev, pm_message_t state)
+static int drm_class_suspend(struct device *dev)
 {
if (dev->type == _sysfs_device_minor) {
struct drm_minor *drm_minor = to_drm_minor(dev);
@@ -46,7 +46,8 @@ static int drm_class_suspend(struct device *dev, pm_message_t 
state)
if (drm_minor->type == DRM_MINOR_LEGACY &&
!drm_core_check_feature(drm_dev, DRIVER_MODESET) &&
drm_dev->driver->suspend)
-   return drm_dev->driver->suspend(drm_dev, state);
+   return drm_dev->driver->suspend(drm_dev,
+   get_pm_transition());
}
return 0;
 }
@@ -72,6 +73,11 @@ static int drm_class_resume(struct device *dev)
return 0;
 }

+static const struct dev_pm_ops drm_class_dev_pm_ops = {
+   .suspend= drm_class_suspend,
+   .resume = drm_class_resume,
+};
+
 static char *drm_devnode(struct device *dev, umode_t *mode)
 {
return kasprintf(GFP_KERNEL, "dri/%s", dev_name(dev));
@@ -106,8 +112,7 @@ struct class *drm_sysfs_create(struct module *owner, char 
*name)
goto err_out;
}

-   class->suspend = drm_class_suspend;
-   class->resume = drm_class_resume;
+   class->pm = _class_dev_pm_ops;

err = class_create_file(class, _attr_version.attr);
if (err)
-- 
1.7.10.4

[PATCH 1/2] power: add new interface to return pm_transition state

[Shuah Khan]

Add a new interface get_pm_transition() to return pm_transition state.
This interface is intended to be used from dev_pm_ops class and type
suspend interfaces that call legacy pm ops driver suspend interfaces.
Legacy suspend pm_ops take pm_message_t as a parameter.

e.g: drm_class_suspend() calls into driver suspend routines
via drm_dev->driver->suspend(drm_dev, state).

Once drm_class_suspend() is converted to dev_pm_ops, it will no longer
have access to pm_transition which it has to pass into driver legacy
suspend calls. get_pm_transition() interface addresses this need.

Signed-off-by: Shuah Khan 
---
 drivers/base/power/main.c |   17 +
 include/linux/pm.h|3 +++
 2 files changed, 20 insertions(+)

diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c
index c2132b8..3e2e09d 100644
--- a/drivers/base/power/main.c
+++ b/drivers/base/power/main.c
@@ -57,6 +57,23 @@ static pm_message_t pm_transition;
 static int async_error;

 /**
+ * get_pm_transition - return pm_transition state.
+ * This interface is intended to be used from dev_pm_ops class and type
+ * suspend interfaces that call legacy pm ops driver suspend interfaces.
+ * Legacy suspend pm_ops take pm_message_t as a parameter.
+ * e.g: drm_class_suspend() calls into driver suspend routines
+ * via drm_dev->driver->suspend(drm_dev, state).
+ * Once drm_class_suspend() is converted to dev_pm_ops, it will no longer
+ * have access to pm_transition which it has to pass into driver legacy
+ * suspend calls. get_pm_transition() interface addresses this need.
+*/
+pm_message_t get_pm_transition()
+{
+   return pm_transition;
+}
+EXPORT_SYMBOL_GPL(get_pm_transition);
+
+/**
  * device_pm_sleep_init - Initialize system suspend-related device fields.
  * @dev: Device object being initialized.
  */
diff --git a/include/linux/pm.h b/include/linux/pm.h
index a224c7f..46f3252 100644
--- a/include/linux/pm.h
+++ b/include/linux/pm.h
@@ -63,6 +63,9 @@ typedef struct pm_message {
int event;
 } pm_message_t;

+/* drivers/base/power/main.c */
+extern pm_message_t get_pm_transition(void);
+
 /**
  * struct dev_pm_ops - device PM callbacks
  *
-- 
1.7.10.4

[PATCH v2] drm: Improve manual IRQ installation documentation

[Laurent Pinchart]

Signed-off-by: Laurent Pinchart 
---
 Documentation/DocBook/drm.tmpl | 118 -
 1 file changed, 70 insertions(+), 48 deletions(-)

Changes since v1:

- Document manual IRQ registration

diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
index 91ee107..a608094 100644
--- a/Documentation/DocBook/drm.tmpl
+++ b/Documentation/DocBook/drm.tmpl
@@ -186,11 +186,12 @@
   
 DRIVER_HAVE_IRQDRIVER_IRQ_SHARED
 
-  DRIVER_HAVE_IRQ indicates whether the driver has an IRQ handler. 
The
-  DRM core will automatically register an interrupt handler when 
the
-  flag is set. DRIVER_IRQ_SHARED indicates whether the device 
-  handler support shared IRQs (note that this is required of PCI
-  drivers).
+  DRIVER_HAVE_IRQ indicates whether the driver has an IRQ handler
+  managed by the DRM Core. The core will support simple IRQ handler
+  installation when the flag is set. The installation process is
+  described in .
+  DRIVER_IRQ_SHARED indicates whether the device  
handler
+  support shared IRQs (note that this is required of PCI  drivers).
 
   
   
@@ -344,50 +345,71 @@ char *date;
   The DRM core tries to facilitate IRQ handler registration and
   unregistration by providing drm_irq_install and
   drm_irq_uninstall functions. Those functions 
only
-  support a single interrupt per device.
-
-  
-
-  Both functions get the device IRQ by calling
-  drm_dev_to_irq. This inline function will call a
-  bus-specific operation to retrieve the IRQ number. For platform 
devices,
-  platform_get_irq(..., 0) is used to retrieve the
-  IRQ number.
-
-
-  drm_irq_install starts by calling the
-  irq_preinstall driver operation. The 
operation
-  is optional and must make sure that the interrupt will not get fired 
by
-  clearing all pending interrupt flags or disabling the interrupt.
-
-
-  The IRQ will then be requested by a call to
-  request_irq. If the DRIVER_IRQ_SHARED driver
-  feature flag is set, a shared (IRQF_SHARED) IRQ handler will be
-  requested.
-
-
-  The IRQ handler function must be provided as the mandatory 
irq_handler
-  driver operation. It will get passed directly to
-  request_irq and thus has the same prototype as 
all
-  IRQ handlers. It will get called with a pointer to the DRM device as 
the
-  second argument.
-
-
-  Finally the function calls the optional
-  irq_postinstall driver operation. The 
operation
-  usually enables interrupts (excluding the vblank interrupt, which is
-  enabled separately), but drivers may choose to enable/disable 
interrupts
-  at a different time.
-
-
-  drm_irq_uninstall is similarly used to 
uninstall an
-  IRQ handler. It starts by waking up all processes waiting on a vblank
-  interrupt to make sure they don't hang, and then calls the optional
-  irq_uninstall driver operation. The 
operation
-  must disable all hardware interrupts. Finally the function frees the 
IRQ
-  by calling free_irq.
+  support a single interrupt per device, devices that use more than one
+  IRQs need to be handled manually.
 
+
+  Managed IRQ Registration
+  
+Both the drm_irq_install and
+   drm_irq_uninstall functions get the device IRQ 
by
+   calling drm_dev_to_irq. This inline function 
will
+   call a bus-specific operation to retrieve the IRQ number. For 
platform
+   devices, platform_get_irq(..., 0) is used to
+   retrieve the IRQ number.
+  
+  
+drm_irq_install starts by calling the
+irq_preinstall driver operation. The 
operation
+is optional and must make sure that the interrupt will not get 
fired by
+clearing all pending interrupt flags or disabling the interrupt.
+  
+  
+The IRQ will then be requested by a call to
+request_irq. If the DRIVER_IRQ_SHARED driver
+feature flag is set, a shared (IRQF_SHARED) IRQ handler will be
+requested.
+  
+  
+The IRQ handler function must be provided as the mandatory 
irq_handler
+driver operation. It will get passed directly to
+request_irq and thus has the same prototype 
as all
+IRQ handlers. It will get called with a pointer to the DRM device 
as the
+second argument.
+  
+  
+  

[PULL] drm-tegra-fixes

[Thierry Reding]

On Thu, Jun 20, 2013 at 11:07:11PM +0200, Thierry Reding wrote:
> On Fri, Jun 21, 2013 at 06:37:30AM +1000, Dave Airlie wrote:
> > >   git://anongit.freedesktop.org/tegra/linux.git drm/fixes
> > >
> > > for you to fetch changes up to 2b15aa0fd466a4b2defdfd84c0b5168804b3eb33:
> > >
> > >   gpu: host1x: Rework CPU syncpoint increment (2013-06-20 12:21:38 +0200)
> > >
> > > I know this comes awfully late and is much bigger than I'd like. It's
> > > all my fault, though, since I've been travelling a lot lately and just
> > > didn't find the time to prepare this earlier. I did want to sort out
> > > patches that didn't warrant to go in before the final 3.10 release, but
> > > all met the criteria as far as I could tell.
> > >
> > 
> > Don't think I want to submit this to Linus, its way too much at this point,
> > 
> > User visible oops or regressions is all you get now really.
> 
> Okay, I understand. Can you take this pull request for 3.11 instead?

Scratch that. I'll send a proper pull request for 3.11.

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130622/2640a62a/attachment.pgp>

'Timed out waiting for forcewake old ack to clear' and hangup on IvyBridge system

[Guenter Roeck]

On Sat, Jun 22, 2013 at 12:16:46PM -0700, Jesse Barnes wrote:
> On Fri, 21 Jun 2013 23:58:08 -0700
> Guenter Roeck  wrote:
> 
> > Hi all,
> > 
> > after upgrading one of my servers to 3.8, then 3.9.7 and 3.10-rc6, I 
> > started to
> > see lots of "Timed out waiting for forcewake old ack to clear" error 
> > messages,
> > including hang-ups especially if the system was highly loaded. With 3.5.24
> > everything was fine.
> > 
> > After backing out commit 36ec8f877 (drm/i915: unconditionally use mt 
> > forcewake
> > on hsw/ivb), everything is back to normal. The log message is still there, 
> > but
> > only once during boot, and the system runs stable.
> > 
> > CPU is "Intel(R) Core(TM) i7-3770K CPU @ 3.50GHz", mainboard is Supermicro
> > C7H61, BIOS version 2.00 dated 11/02/2012. Configuration file is whatever
> > comes with Ubuntu; I'll be happy to provide a copy if anyone thinks it might
> > help.
> > 
> > Any idea what else I can do besides using a special kernel with the backed 
> > out
> > commit ? Is it possible that others have the same problem ?
> 
> Ouch, so a BIOS that uses the other forcewake mechanism seems to have
> escaped.  Is there a newer one available for your system?  I'm hoping
> it'll fix the issue, otherwise we may have to introduce both methods
> for IVB again...
> 
I installed the latest BIOS version (2.00b), but it did not fix the problem.

Is there some info (such as an Intel document describing what needs to be done)
which I could pass on to Supermicro ?

I think it would be helpful if the condition was detected and reported, if that
is possible. I spent two days so far tracking this down. It would be nice
if others would not have to go through the same experience.

Thanks,
Guenter

[PATCH] drm: Improve manual IRQ installation documentation

[Thierry Reding]

gt; > > > > That's only needed if DRIVER_HAVE_IRQ is set, otherwise the
> > > > > drm_wait_vblank() function skips the irq_enabled check.
> > > > 
> > > > Not quite. There's another check for dev->irq_enabled in the
> > > > DRM_WAIT_ON() so it'll never actually block.
> > > 
> > > Indeed.
> > > 
> > > > Arguably this could be solved by making the DRM_WAIT_ON() condition 
> > > > drop the
> > > > !dev->irq_enabled in case DRIVER_HAVE_IRQ isn't set.
> > > 
> > > Or we could force drivers to set drm->irq_enabled, I'm fine with that as 
> > > well. 
> > > I can fix the documentation if that would be the preferred solution.
> > 
> > Thinking about it some more, the latter seems more appropriate. Consider
> > some driver that doesn't set DRIVER_HAVE_IRQ but also doesn't initialize
> > interrupts manually. If so it'll cause DRM_IOCTL_WAIT_VBLANK to block
> > indefinitely.
> > 
> > On the other hand perhaps the check at the beginning of drm_wait_vblank
> > should be improved. Maybe make it something like this:
> > 
> > if (drm_core_check_feature(dev, DRIVER_HAVE_IRQ))
> > if (!drm_dev_to_irq(dev))
> > return -EINVAL;
> > 
> > if (!dev->irq_enabled)
> > return -EINVAL;
> 
> I think the vblank subsystem is ripe for rework, and I have a few plans
> for that.

Would you mind sharing those plans so that maybe others can help out?

> But till that happens I guess we could just roll forward with
> whatever hacks we currently have ...

So that means the above sounds like a reasonable interim solution?

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130622/0a0dc7ba/attachment.pgp>

[PATCH] drm: always provide debugfs function prototypes

[Thierry Reding]

On Sat, Jun 22, 2013 at 12:38:16AM +0200, Arnd Bergmann wrote:
> It is generally considered bad style to enclose function prototypes
> in header files in #ifdef. This case illustrates why that is:
> The tegra host1x driver calls into the debugfs functions if
> CONFIG_DEBUG_FS is enabled, but that code is otherwise already
> discarded by the compiler, so leaving the prototype in place
> actually makes everything work.
> 
> drivers/gpu/host1x/drm/dc.c: In function 'tegra_dc_debugfs_init':
> drivers/gpu/host1x/drm/dc.c:1004:2: error: implicit declaration of function 
> 'drm_debugfs_create_files' [-Werror=implicit-function-declaration]
> drivers/gpu/host1x/drm/dc.c: In function 'tegra_dc_debugfs_exit': 
> drivers/gpu/host1x/drm/dc.c:1026:2: error: implicit declaration of function 
> 'drm_debugfs_remove_files' [-Werror=implicit-function-declaration]
> 
> Signed-off-by: Arnd Bergmann 
> Cc: Ben Gamari 
> Cc: Dave Airlie 
> 
> diff --git a/include/drm/drmP.h b/include/drm/drmP.h
> index 63d17ee..8bc105e 100644
> --- a/include/drm/drmP.h
> +++ b/include/drm/drmP.h
> @@ -1551,7 +1551,7 @@ extern int drm_proc_init(struct drm_minor *minor, 
> struct proc_dir_entry *root);
>  extern int drm_proc_cleanup(struct drm_minor *minor, struct proc_dir_entry 
> *root);
>  
>   /* Debugfs support */
> -#if defined(CONFIG_DEBUG_FS)
> +

I don't know what good the blank line does here, but apart from that
this patch looks good to me:

Reviewed-by: Thierry Reding 
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130622/d59c469a/attachment.pgp>

[Bug 65968] Massive memory corruption in Planetary Annihilation Alpha

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

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

--- Comment #6 from Andreas Ringlstetter  ---
RADEON_DEBUG=noopt is not possible, the pixel shader programs are to big to be
loaded without size optimizations.
Hard limit of 512 instruction slots per pixel shader:
http://developer.amd.com/wordpress/media/2012/10/Radeon_X1x00_Programming_Guide.pdf
page 13
This limit is exceeded by far due to all the virtual texturing code, the
optimized shader barely fits.

I did try it in 9.0 and 9.1 with noopt and I did get past the segfault in
peephole_mul_omod() this way, but it did fail then because the resulting shader
program was to big.

Deactivating hyper-z has no measurable impact, and it didn't prevent the
corruption either.

Antialiasing hasn't even been enabled in the application by default, so turning
it off makes no difference at all.

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

'Timed out waiting for forcewake old ack to clear' and hangup on IvyBridge system

[Jesse Barnes]

On Fri, 21 Jun 2013 23:58:08 -0700
Guenter Roeck  wrote:

> Hi all,
> 
> after upgrading one of my servers to 3.8, then 3.9.7 and 3.10-rc6, I started 
> to
> see lots of "Timed out waiting for forcewake old ack to clear" error messages,
> including hang-ups especially if the system was highly loaded. With 3.5.24
> everything was fine.
> 
> After backing out commit 36ec8f877 (drm/i915: unconditionally use mt forcewake
> on hsw/ivb), everything is back to normal. The log message is still there, but
> only once during boot, and the system runs stable.
> 
> CPU is "Intel(R) Core(TM) i7-3770K CPU @ 3.50GHz", mainboard is Supermicro
> C7H61, BIOS version 2.00 dated 11/02/2012. Configuration file is whatever
> comes with Ubuntu; I'll be happy to provide a copy if anyone thinks it might
> help.
> 
> Any idea what else I can do besides using a special kernel with the backed out
> commit ? Is it possible that others have the same problem ?

Ouch, so a BIOS that uses the other forcewake mechanism seems to have
escaped.  Is there a newer one available for your system?  I'm hoping
it'll fix the issue, otherwise we may have to introduce both methods
for IVB again...

-- 
Jesse Barnes, Intel Open Source Technology Center

[Bug 65968] Massive memory corruption in Planetary Annihilation Alpha

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

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

Andreas Boll  changed:

   What|Removed |Added

  Component|Drivers/DRI/r300|Drivers/Gallium/r300

--- Comment #5 from Andreas Boll  ---
You could try setting the env var RADEON_DEBUG=noopt, maybe it helps.
Additionally you should be able to test 9.0 and 9.1 with this env var.

RADEON_DEBUG=help prints some other debug flags you could try.
E.g disable hyper-z or msaa

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

[RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization framework

[Inki Dae]

chronization with the other, sees a sync
>> object as a file descriptor like dma-buf does. The below shows simple
>> my idea about it:
>>
>> ioctl(dmabuf_fd, DMA_BUF_IOC_OPEN_SYNC, );
>>
>> flock(sync->fd, LOCK_SH); <- LOCK_SH means a shared lock.
>> CPU access for read
>> flock(sync->fd, LOCK_UN);
>>
>> Or
>>
>> flock(sync->fd, LOCK_EX); <- LOCK_EX means an exclusive lock
>> CPU access for write
>> flock(sync->fd, LOCK_UN);
>>
>> close(sync->fd);
>>
>> As you know, that's similar to dmabuf export feature.
>>
>> In addition, a more simple idea,
>> flock(dmabuf_fd, LOCK_SH/EX);
>> CPU access for read/write
>> flock(dmabuf_fd, LOCK_UN);
>>
>> However, I'm not sure that the above examples could be worked well,
>> and there are no problems yet: actually, I don't fully understand
>> flock mechanism, so looking into it.
>>
>>>
>>>>
>>>> And to get back to my original point: if you have more than
>>>> one task
>>>> operating together on a buffer you absolutely need some kind
>>>> of real IPC
>>>> to sync them up and do something useful. Both you syncpoints
>>>> and the
>>>> proposed dma-fences only protect the buffer accesses to make
>>>> sure
>>>> different task don't stomp on each other. There is nothing in
>>>> there to
>>>> make sure that the output of your pipeline is valid. You have
>>>> to take
>>>> care of that yourself in userspace. I'll reuse your example to
>>>> make it
>>>> clear what I mean:
>>>>
>>>> Task A Task B
>>>> -- ---
>>>> dma_buf_sync_lock(buf1)
>>>> CPU write buf1
>>>> dma_buf_sync_unlock(buf1)
>>>> -schedule Task A again---
>>>> dma_buf_sync_lock(buf1)
>>>> CPU write buf1
>>>> dma_buf_sync_unlock(buf1)
>>>> -schedule Task B-
>>>> qbuf(buf1)
>>>>
>>>> dma_buf_sync_lock(buf1)
>>>> 
>>>>
>>>> This is what can happen if you don't take care of proper
>>>> syncing. Task A
>>>> writes something to the buffer in expectation that Task B will
>>>> take care
>>>> of it, but before Task B even gets scheduled Task A overwrites
>>>> the
>>>> buffer again. Not what you wanted, isn't it?
>>>>
>>>> Exactly wrong example. I had already mentioned about that. "In case
>>>> that data flow goes from A to B, it needs some kind of IPC between the
>>>> two tasks every time" So again, your example would have no any
>>>> problem in case that *two tasks share the same buffer but these tasks
>>>> access the buffer(buf1) as write, and data of the buffer(buf1) isn't
>>>> needed to be shared*. They just need to use the buffer as *storage*.
>>>> So All they want is to avoid stomping on the buffer in this case.
>>>>
>>> Sorry, but I don't see the point. If no one is interested in the data of
>>> the buffer, why are you sharing it in the first place?
>>>
>>
>> Just used as a storage. i.e., Task A fills the buffer with "AA"
>> using CPU, And Task B fills the buffer with "BB" using DMA. They
>> don't share data of the buffer, but they share *memory region* of the
>> buffer. That would be very useful for the embedded systems with very
>> small size system memory.
>
> Just so i understand. You want to share backing memory, you don't want
> to share content ie you want to do memory management in userspace.
> This sounds wrong on so many level (not even considering the security
> implication).
>
> If Task A need memory and then can release it for Task B usage that
> should be the role of kernel memory management which of course needs
> synchronization btw A and B. But in no case this should be done using
> dma-buf. dma-buf is for sharing content btw different devices not
> sharing resources.
>

Just simply let's think of the case that a user process doesn't want for
anyone, other CPU or DMA, to access a shared buffer while he is accessing
the shared buffer. In this case, useful.

Thanks,
Inki Dae

>
> Also don't over complicate the vram case, just consider desktop gpu as
> using system memory directly. They can do it and they do it. Migration
> to vram is orthogonal to all this, it's an optimization so to speak.
>
> Cheers,
> Jerome.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130622/8fe34092/attachment-0001.html>

[PATCH 0/2] Documentation improvements

[Alex Deucher]

On Sat, Jun 22, 2013 at 9:00 AM, Laurent Pinchart
 wrote:
> Hello,
>
> Here are two patches that improve the DRM documentation by documenting the KMS
> property API, and removing an outdated note about the i915 driver.
>
> Laurent Pinchart (2):
>   drm/doc: Remove outdated note about i915 driver not behaving properly
>   drm/doc: Document the KMS property API

Looks good.  For the series:

Reviewed-by: Alex Deucher 

>
>  Documentation/DocBook/drm.tmpl | 147 
> +++--
>  1 file changed, 143 insertions(+), 4 deletions(-)
>
> --
> Regards,
>
> Laurent Pinchart
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization framework

[Inki Dae]

2013/6/21 Lucas Stach :
> Hi Inki,
>
> please refrain from sending HTML Mails, it makes proper quoting without
> messing up the layout everywhere pretty hard.
>

Sorry about that. I should have used text mode.

> Am Freitag, den 21.06.2013, 20:01 +0900 schrieb Inki Dae:
> [...]
>
>> Yeah, you'll some knowledge and understanding about the API
>> you are
>> working with to get things right. But I think it's not an
>> unreasonable
>> thing to expect the programmer working directly with kernel
>> interfaces
>> to read up on how things work.
>>
>> Second thing: I'll rather have *one* consistent API for every
>> subsystem,
>> even if they differ from each other than having to implement
>> this
>> syncpoint thing in every subsystem. Remember: a single execbuf
>> in DRM
>> might reference both GEM objects backed by dma-buf as well
>> native SHM or
>> CMA backed objects. The dma-buf-mgr proposal already allows
>> you to
>> handle dma-bufs much the same way during validation than
>> native GEM
>> objects.
>>
>> Actually, at first I had implemented a fence helper framework based on
>> reservation and dma fence to provide easy-use-interface for device
>> drivers. However, that was wrong implemention: I had not only
>> customized the dma fence but also not considered dead lock issue.
>> After that, I have reimplemented it as dmabuf sync to solve dead
>> issue, and at that time, I realized that we first need to concentrate
>> on the most basic thing: the fact CPU and CPU, CPU and DMA, or DMA and
>> DMA can access a same buffer, And the fact simple is the best, and the
>> fact we need not only kernel side but also user side interfaces. After
>> that, I collected what is the common part for all subsystems, and I
>> have devised this dmabuf sync framework for it. I'm not really
>> specialist in Desktop world. So question. isn't the execbuf used only
>> for the GPU? the gpu has dedicated video memory(VRAM) so it needs
>> migration mechanism between system memory and the dedicated video
>> memory, and also to consider ordering issue while be migrated.
>>
>
> Yeah, execbuf is pretty GPU specific, but I don't see how this matters
> for this discussion. Also I don't see a big difference between embedded
> and desktop GPUs. Buffer migration is more of a detail here. Both take
> command stream that potentially reference other buffers, which might be
> native GEM or dma-buf backed objects. Both have to make sure the buffers
> are in the right domain (caches cleaned and address mappings set up) and
> are available for the desired operation, meaning you have to sync with
> other DMA engines and maybe also with CPU.

Yeah, right. Then, in case of desktop gpu, does't it need additional
something to do when a buffer/s is/are migrated from system memory to
video memory domain, or from video memory to system memory domain? I
guess the below members does similar thing, and all other DMA devices
would not need them:
struct fence {
  ...
  unsigned int context, seqno;
  ...
};

And,
   struct seqno_fence {
 ...
 uint32_t seqno_ofs;
 ...
   };

>
> The only case where sync isn't clearly defined right now by the current
> API entrypoints is when you access memory through the dma-buf fallback
> mmap support, which might happen with some software processing element
> in a video pipeline or something. I agree that we will need a userspace
> interface here, but I think this shouldn't be yet another sync object,
> but rather more a prepare/fini_cpu_access ioctl on the dma-buf which
> hooks into the existing dma-fence and reservation stuff.

I think we don't need addition ioctl commands for that. I am thinking
of using existing resources as possible. My idea also is similar in
using the reservation stuff to your idea because my approach also
should use the dma-buf resource. However, My idea is that a user
process, that wants buffer synchronization with the other, sees a sync
object as a file descriptor like dma-buf does. The below shows simple
my idea about it:

ioctl(dmabuf_fd, DMA_BUF_IOC_OPEN_SYNC, );

flock(sync->fd, LOCK_SH); <- LOCK_SH means a shared lock.
CPU access for read
flock(sync->fd, LOCK_UN);

Or

flock(sync->fd, LOCK_EX); <- LOCK_EX means an exclusive lock
CPU access for write
flock(sync->fd, LOCK_UN);

close(sync->fd);

As you know, that's similar to dmabuf export feature.

In addition, a more simple idea,
flock(dmabuf_fd, LOCK_SH/EX);
CPU access for read/write
flock(dmabuf_fd, LOCK_UN);

However, I'm not sure that the above examples could be worked well,
and there are no problems yet: actually, I don't fully understand
flock mechanism, so looking into it.

>
>>
>> And to get back to my original point: if you have more than
>> one task
>>   

[PATCH] drm: always provide debugfs function prototypes

[Arnd Bergmann]

It is generally considered bad style to enclose function prototypes
in header files in #ifdef. This case illustrates why that is:
The tegra host1x driver calls into the debugfs functions if
CONFIG_DEBUG_FS is enabled, but that code is otherwise already
discarded by the compiler, so leaving the prototype in place
actually makes everything work.

drivers/gpu/host1x/drm/dc.c: In function 'tegra_dc_debugfs_init':
drivers/gpu/host1x/drm/dc.c:1004:2: error: implicit declaration of function 
'drm_debugfs_create_files' [-Werror=implicit-function-declaration]
drivers/gpu/host1x/drm/dc.c: In function 'tegra_dc_debugfs_exit': 
drivers/gpu/host1x/drm/dc.c:1026:2: error: implicit declaration of function 
'drm_debugfs_remove_files' [-Werror=implicit-function-declaration]

Signed-off-by: Arnd Bergmann 
Cc: Ben Gamari 
Cc: Dave Airlie 

diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 63d17ee..8bc105e 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -1551,7 +1551,7 @@ extern int drm_proc_init(struct drm_minor *minor, struct 
proc_dir_entry *root);
 extern int drm_proc_cleanup(struct drm_minor *minor, struct proc_dir_entry 
*root);

/* Debugfs support */
-#if defined(CONFIG_DEBUG_FS)
+
 extern int drm_debugfs_init(struct drm_minor *minor, int minor_id,
struct dentry *root);
 extern int drm_debugfs_create_files(struct drm_info_list *files, int count,
@@ -1559,7 +1559,6 @@ extern int drm_debugfs_create_files(struct drm_info_list 
*files, int count,
 extern int drm_debugfs_remove_files(struct drm_info_list *files, int count,
 struct drm_minor *minor);
 extern int drm_debugfs_cleanup(struct drm_minor *minor);
-#endif

/* Info file support */
 extern int drm_name_info(struct seq_file *m, void *data);

'Timed out waiting for forcewake old ack to clear' and hangup on IvyBridge system

[Guenter Roeck]

Hi all,

after upgrading one of my servers to 3.8, then 3.9.7 and 3.10-rc6, I started to
see lots of "Timed out waiting for forcewake old ack to clear" error messages,
including hang-ups especially if the system was highly loaded. With 3.5.24
everything was fine.

After backing out commit 36ec8f877 (drm/i915: unconditionally use mt forcewake
on hsw/ivb), everything is back to normal. The log message is still there, but
only once during boot, and the system runs stable.

CPU is "Intel(R) Core(TM) i7-3770K CPU @ 3.50GHz", mainboard is Supermicro
C7H61, BIOS version 2.00 dated 11/02/2012. Configuration file is whatever
comes with Ubuntu; I'll be happy to provide a copy if anyone thinks it might
help.

Any idea what else I can do besides using a special kernel with the backed out
commit ? Is it possible that others have the same problem ?

Thanks,
Guenter

Re: [PATCH] drm: always provide debugfs function prototypes

[Thierry Reding]

On Sat, Jun 22, 2013 at 12:38:16AM +0200, Arnd Bergmann wrote:
 It is generally considered bad style to enclose function prototypes
 in header files in #ifdef. This case illustrates why that is:
 The tegra host1x driver calls into the debugfs functions if
 CONFIG_DEBUG_FS is enabled, but that code is otherwise already
 discarded by the compiler, so leaving the prototype in place
 actually makes everything work.
 
 drivers/gpu/host1x/drm/dc.c: In function 'tegra_dc_debugfs_init':
 drivers/gpu/host1x/drm/dc.c:1004:2: error: implicit declaration of function 
 'drm_debugfs_create_files' [-Werror=implicit-function-declaration]
 drivers/gpu/host1x/drm/dc.c: In function 'tegra_dc_debugfs_exit': 
 drivers/gpu/host1x/drm/dc.c:1026:2: error: implicit declaration of function 
 'drm_debugfs_remove_files' [-Werror=implicit-function-declaration]
 
 Signed-off-by: Arnd Bergmann a...@arndb.de
 Cc: Ben Gamari bgam...@gmail.com
 Cc: Dave Airlie airl...@redhat.com
 
 diff --git a/include/drm/drmP.h b/include/drm/drmP.h
 index 63d17ee..8bc105e 100644
 --- a/include/drm/drmP.h
 +++ b/include/drm/drmP.h
 @@ -1551,7 +1551,7 @@ extern int drm_proc_init(struct drm_minor *minor, 
 struct proc_dir_entry *root);
  extern int drm_proc_cleanup(struct drm_minor *minor, struct proc_dir_entry 
 *root);
  
   /* Debugfs support */
 -#if defined(CONFIG_DEBUG_FS)
 +

I don't know what good the blank line does here, but apart from that
this patch looks good to me:

Reviewed-by: Thierry Reding thierry.red...@gmail.com


pgpJ7IAkMrJBK.pgp
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: Improve manual IRQ installation documentation

[Thierry Reding]

On Thu, Jun 20, 2013 at 04:55:03PM +0200, Daniel Vetter wrote:
 On Thu, Jun 20, 2013 at 01:00:36PM +0200, Thierry Reding wrote:
  On Thu, Jun 20, 2013 at 12:46:21PM +0200, Laurent Pinchart wrote:
   Hi Thierry,
   
   On Thursday 20 June 2013 12:40:26 Thierry Reding wrote:
On Thu, Jun 20, 2013 at 12:17:25PM +0200, Laurent Pinchart wrote:
 On Thursday 20 June 2013 12:10:47 Thierry Reding wrote:
  On Wed, Jun 19, 2013 at 02:00:45PM +0200, Laurent Pinchart wrote:
   Signed-off-by: Laurent Pinchart
   laurent.pinchart+rene...@ideasonboard.com
   ---
   
Documentation/DocBook/drm.tmpl | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
   
   diff --git a/Documentation/DocBook/drm.tmpl
   b/Documentation/DocBook/drm.tmpl index f9df3b8..738b727 100644
   --- a/Documentation/DocBook/drm.tmpl
   +++ b/Documentation/DocBook/drm.tmpl
   @@ -186,11 +186,12 @@
   
  varlistentry
  

   termDRIVER_HAVE_IRQ/termtermDRIVER_IRQ_SHARED/term

listitempara
   
   -  DRIVER_HAVE_IRQ indicates whether the driver has 
   an IRQ
   handler. The -  DRM core will automatically register 
   an
   interrupt handler when the -  flag is set.
   DRIVER_IRQ_SHARED
   indicates whether the device amp; -  handler support
   shared
   IRQs (note that this is required of PCI -  drivers).
   +  DRIVER_HAVE_IRQ indicates whether the driver has 
   an IRQ
   handler +  managed by the DRM Core. The core will 
   support
   simple IRQ handler +  installation when the flag is 
   set.
   The
   installation process is +  described in xref
   linkend=drm-irq-registration/./para +
   paraDRIVER_IRQ_SHARED indicates whether the device amp; 
   handler +
   
   support shared IRQs (note that this is required of PCI 
   drivers).
   
/para/listitem
  
  /varlistentry
  varlistentry
   
   @@ -344,7 +345,8 @@ char *date;/synopsis
   
  The DRM core tries to facilitate IRQ handler 
   registration
  and
  unregistration by providing
  functiondrm_irq_install/function and
  functiondrm_irq_uninstall/function functions. Those
  functions only
   
   -  support a single interrupt per device.
   +  support a single interrupt per device, devices that use
   more
   than one +  IRQs need to be handled manually.
  
  Perhaps this should mention that if you handle IRQ installation 
  manually
  you also need to manually set drm-irq_enabled = 1, as otherwise 
  things
  like DRM_IOCTL_WAIT_VBLANK won't work properly.
 
 That's only needed if DRIVER_HAVE_IRQ is set, otherwise the
 drm_wait_vblank() function skips the irq_enabled check.

Not quite. There's another check for dev-irq_enabled in the
DRM_WAIT_ON() so it'll never actually block.
   
   Indeed.
   
Arguably this could be solved by making the DRM_WAIT_ON() condition 
drop the
!dev-irq_enabled in case DRIVER_HAVE_IRQ isn't set.
   
   Or we could force drivers to set drm-irq_enabled, I'm fine with that as 
   well. 
   I can fix the documentation if that would be the preferred solution.
  
  Thinking about it some more, the latter seems more appropriate. Consider
  some driver that doesn't set DRIVER_HAVE_IRQ but also doesn't initialize
  interrupts manually. If so it'll cause DRM_IOCTL_WAIT_VBLANK to block
  indefinitely.
  
  On the other hand perhaps the check at the beginning of drm_wait_vblank
  should be improved. Maybe make it something like this:
  
  if (drm_core_check_feature(dev, DRIVER_HAVE_IRQ))
  if (!drm_dev_to_irq(dev))
  return -EINVAL;
  
  if (!dev-irq_enabled)
  return -EINVAL;
 
 I think the vblank subsystem is ripe for rework, and I have a few plans
 for that.

Would you mind sharing those plans so that maybe others can help out?

 But till that happens I guess we could just roll forward with
 whatever hacks we currently have ...

So that means the above sounds like a reasonable interim solution?

Thierry


pgp4b1Fz0RO3h.pgp
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PULL] drm-tegra-fixes

[Thierry Reding]

On Thu, Jun 20, 2013 at 11:07:11PM +0200, Thierry Reding wrote:
 On Fri, Jun 21, 2013 at 06:37:30AM +1000, Dave Airlie wrote:
 git://anongit.freedesktop.org/tegra/linux.git drm/fixes
  
   for you to fetch changes up to 2b15aa0fd466a4b2defdfd84c0b5168804b3eb33:
  
 gpu: host1x: Rework CPU syncpoint increment (2013-06-20 12:21:38 +0200)
  
   I know this comes awfully late and is much bigger than I'd like. It's
   all my fault, though, since I've been travelling a lot lately and just
   didn't find the time to prepare this earlier. I did want to sort out
   patches that didn't warrant to go in before the final 3.10 release, but
   all met the criteria as far as I could tell.
  
  
  Don't think I want to submit this to Linus, its way too much at this point,
  
  User visible oops or regressions is all you get now really.
 
 Okay, I understand. Can you take this pull request for 3.11 instead?

Scratch that. I'll send a proper pull request for 3.11.

Thierry


pgpbLqUgMWnPT.pgp
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2] drm: Improve manual IRQ installation documentation

[Laurent Pinchart]

Signed-off-by: Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com
---
 Documentation/DocBook/drm.tmpl | 118 -
 1 file changed, 70 insertions(+), 48 deletions(-)

Changes since v1:

- Document manual IRQ registration

diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
index 91ee107..a608094 100644
--- a/Documentation/DocBook/drm.tmpl
+++ b/Documentation/DocBook/drm.tmpl
@@ -186,11 +186,12 @@
   varlistentry
 termDRIVER_HAVE_IRQ/termtermDRIVER_IRQ_SHARED/term
 listitempara
-  DRIVER_HAVE_IRQ indicates whether the driver has an IRQ handler. 
The
-  DRM core will automatically register an interrupt handler when 
the
-  flag is set. DRIVER_IRQ_SHARED indicates whether the device amp;
-  handler support shared IRQs (note that this is required of PCI
-  drivers).
+  DRIVER_HAVE_IRQ indicates whether the driver has an IRQ handler
+  managed by the DRM Core. The core will support simple IRQ handler
+  installation when the flag is set. The installation process is
+  described in xref linkend=drm-irq-registration/./para
+  paraDRIVER_IRQ_SHARED indicates whether the device amp; 
handler
+  support shared IRQs (note that this is required of PCI  drivers).
 /para/listitem
   /varlistentry
   varlistentry
@@ -344,50 +345,71 @@ char *date;/synopsis
   The DRM core tries to facilitate IRQ handler registration and
   unregistration by providing functiondrm_irq_install/function and
   functiondrm_irq_uninstall/function functions. Those functions 
only
-  support a single interrupt per device.
-/para
-  !--!Fdrivers/char/drm/drm_irq.c drm_irq_install--
-para
-  Both functions get the device IRQ by calling
-  functiondrm_dev_to_irq/function. This inline function will call a
-  bus-specific operation to retrieve the IRQ number. For platform 
devices,
-  functionplatform_get_irq/function(..., 0) is used to retrieve the
-  IRQ number.
-/para
-para
-  functiondrm_irq_install/function starts by calling the
-  methodnameirq_preinstall/methodname driver operation. The 
operation
-  is optional and must make sure that the interrupt will not get fired 
by
-  clearing all pending interrupt flags or disabling the interrupt.
-/para
-para
-  The IRQ will then be requested by a call to
-  functionrequest_irq/function. If the DRIVER_IRQ_SHARED driver
-  feature flag is set, a shared (IRQF_SHARED) IRQ handler will be
-  requested.
-/para
-para
-  The IRQ handler function must be provided as the mandatory 
irq_handler
-  driver operation. It will get passed directly to
-  functionrequest_irq/function and thus has the same prototype as 
all
-  IRQ handlers. It will get called with a pointer to the DRM device as 
the
-  second argument.
-/para
-para
-  Finally the function calls the optional
-  methodnameirq_postinstall/methodname driver operation. The 
operation
-  usually enables interrupts (excluding the vblank interrupt, which is
-  enabled separately), but drivers may choose to enable/disable 
interrupts
-  at a different time.
-/para
-para
-  functiondrm_irq_uninstall/function is similarly used to 
uninstall an
-  IRQ handler. It starts by waking up all processes waiting on a vblank
-  interrupt to make sure they don't hang, and then calls the optional
-  methodnameirq_uninstall/methodname driver operation. The 
operation
-  must disable all hardware interrupts. Finally the function frees the 
IRQ
-  by calling functionfree_irq/function.
+  support a single interrupt per device, devices that use more than one
+  IRQs need to be handled manually.
 /para
+sect4
+  titleManaged IRQ Registration/title
+  para
+Both the functiondrm_irq_install/function and
+   functiondrm_irq_uninstall/function functions get the device IRQ 
by
+   calling functiondrm_dev_to_irq/function. This inline function 
will
+   call a bus-specific operation to retrieve the IRQ number. For 
platform
+   devices, functionplatform_get_irq/function(..., 0) is used to
+   retrieve the IRQ number.
+  /para
+  para
+functiondrm_irq_install/function starts by calling the
+methodnameirq_preinstall/methodname driver operation. The 
operation
+is optional and must make sure that the interrupt will not get 
fired by
+clearing all pending interrupt flags or disabling the interrupt.
+  /para
+   

[Bug 65968] Massive memory corruption in Planetary Annihilation Alpha

[bugzilla-daemon]

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

--- Comment #6 from Andreas Ringlstetter andreas.ringlstet...@gmail.com ---
RADEON_DEBUG=noopt is not possible, the pixel shader programs are to big to be
loaded without size optimizations.
Hard limit of 512 instruction slots per pixel shader:
http://developer.amd.com/wordpress/media/2012/10/Radeon_X1x00_Programming_Guide.pdf
page 13
This limit is exceeded by far due to all the virtual texturing code, the
optimized shader barely fits.

I did try it in 9.0 and 9.1 with noopt and I did get past the segfault in
peephole_mul_omod() this way, but it did fail then because the resulting shader
program was to big.

Deactivating hyper-z has no measurable impact, and it didn't prevent the
corruption either.

Antialiasing hasn't even been enabled in the application by default, so turning
it off makes no difference at all.

-- 
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 0/2] Documentation improvements

[Laurent Pinchart]

Hello,

Here are two patches that improve the DRM documentation by documenting the KMS
property API, and removing an outdated note about the i915 driver.

Laurent Pinchart (2):
  drm/doc: Remove outdated note about i915 driver not behaving properly
  drm/doc: Document the KMS property API

 Documentation/DocBook/drm.tmpl | 147 +++--
 1 file changed, 143 insertions(+), 4 deletions(-)

-- 
Regards,

Laurent Pinchart

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

[PATCH 1/2] drm/doc: Remove outdated note about i915 driver not behaving properly

[Laurent Pinchart]

From: Laurent Pinchart laurent.pinch...@ideasonboard.com

The i915 driver has been fixed not to modify the mode argument of the
encoder mode_fixup operation. Remove the related comment from the
documentation.

Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
 Documentation/DocBook/drm.tmpl | 4 
 1 file changed, 4 deletions(-)

diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
index a608094..cea420d 100644
--- a/Documentation/DocBook/drm.tmpl
+++ b/Documentation/DocBook/drm.tmpl
@@ -1868,10 +1868,6 @@ void intel_crt_init(struct drm_device *dev)
   synopsisbool (*mode_fixup)(struct drm_encoder *encoder,
const struct drm_display_mode *mode,
struct drm_display_mode *adjusted_mode);/synopsis
-  notepara
-FIXME: The mode argument be const, but the i915 driver modifies
-mode-gt;clock in functionintel_dp_mode_fixup/function.
-  /para/note
   para
 Let encoders adjust the requested mode or reject it completely. 
This
 operation returns true if the mode is accepted (possibly after 
being
-- 
1.8.1.5

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

[PATCH 2/2] drm/doc: Document the KMS property API

[Laurent Pinchart]

Signed-off-by: Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com
---
 Documentation/DocBook/drm.tmpl | 143 +
 1 file changed, 143 insertions(+)

diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
index cea420d..9d4bb06 100644
--- a/Documentation/DocBook/drm.tmpl
+++ b/Documentation/DocBook/drm.tmpl
@@ -1236,6 +1236,15 @@ int max_width, max_height;/synopsis
   titleMiscellaneous/title
   itemizedlist
 listitem
+  synopsisvoid (*set_property)(struct drm_crtc *crtc,
+ struct drm_property *property, uint64_t value);/synopsis
+  para
+Set the value of the given CRTC property to
+parametervalue/parameter. See xref 
linkend=drm-kms-properties/
+for more information about properties.
+  /para
+/listitem
+listitem
   synopsisvoid (*gamma_set)(struct drm_crtc *crtc, u16 *r, u16 
*g, u16 *b,
 uint32_t start, uint32_t size);/synopsis
   para
@@ -1385,6 +1394,15 @@ int max_width, max_height;/synopsis
   xref linkend=drm-kms-init/.
 /para
   /listitem
+  listitem
+synopsisvoid (*set_property)(struct drm_plane *plane,
+ struct drm_property *property, uint64_t value);/synopsis
+para
+  Set the value of the given plane property to
+  parametervalue/parameter. See xref 
linkend=drm-kms-properties/
+  for more information about properties.
+/para
+  /listitem
 /itemizedlist
   /sect3
 /sect2
@@ -1594,6 +1612,15 @@ int max_width, max_height;/synopsis
   titleMiscellaneous/title
   itemizedlist
 listitem
+  synopsisvoid (*set_property)(struct drm_connector *connector,
+ struct drm_property *property, uint64_t value);/synopsis
+  para
+Set the value of the given connector property to
+parametervalue/parameter. See xref 
linkend=drm-kms-properties/
+for more information about properties.
+  /para
+/listitem
+listitem
   synopsisvoid (*destroy)(struct drm_connector 
*connector);/synopsis
   para
 Destroy the connector when not needed anymore. See
@@ -2187,6 +2214,122 @@ void intel_crt_init(struct drm_device *dev)
 /sect2
   /sect1
 
+  !-- Internals: kms properties --
+
+  sect1 id=drm-kms-properties
+titleKMS Properties/title
+para
+  Drivers may need to expose additional parameters to applications than
+  those described in the previous sections. KMS supports attaching
+  properties to CRTCs, connectors and planes and offers a userspace API to
+  list, get and set the property values.
+/para
+para
+  Properties are identified by a name that uniquely defines the property
+  purpose, and store an associated value. For all property types except 
blob
+  properties the value is a 64-bit unsigned integer.
+/para
+para
+  KMS differentiates between properties and property instances. Drivers
+  first create properties and then create and associate individual 
instances
+  of those properties to objects. A property can be instantiated multiple
+  times and associated with different objects. Values are stored in 
property
+  instances, and all other property information are stored in the propery
+  and shared between all instances of the property.
+/para
+para
+  Every property is created with a type that influences how the KMS core
+  handles the property. Supported property types are
+  variablelist
+varlistentry
+  termDRM_MODE_PROP_RANGE/term
+  listitemparaRanges properties report their minimum and maximum
+admissible values. The KMS core verifies that values set by
+application fit in that range./para/listitem
+/varlistentry
+varlistentry
+  termDRM_MODE_PROP_ENUM/term
+  listitemparaEnumerated properties take a numerical value that
+ranges from 0 to the number of enumered values defined by the
+property minus one, and associate a free-formed string name to each
+value. Application can retrieve the list of define value-name pairs
+and use the numerical value to get and set property instance 
values.
+/para/listitem
+/varlistentry
+varlistentry
+  termDRM_MODE_PROP_BITMASK/term
+  listitemparaBitmask properties are enumeration properties that
+additionally restrict all enumerated values to the 0..63 range.
+Bitmask property instance values combine one or more of the
+enumerated bits defined by the 

Re: [PATCH 2/2] drm/doc: Document the KMS property API

[Hans Verkuil]

Hi Laurent,

Is this a hint to me that V4L2 should have a property API as well? :-)

Anyway, I found some typos below:

On Sat June 22 2013 15:00:27 Laurent Pinchart wrote:
 Signed-off-by: Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com
 ---
  Documentation/DocBook/drm.tmpl | 143 
 +
  1 file changed, 143 insertions(+)
 
 diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
 index cea420d..9d4bb06 100644
 --- a/Documentation/DocBook/drm.tmpl
 +++ b/Documentation/DocBook/drm.tmpl
 @@ -1236,6 +1236,15 @@ int max_width, max_height;/synopsis
titleMiscellaneous/title
itemizedlist
  listitem
 +  synopsisvoid (*set_property)(struct drm_crtc *crtc,
 + struct drm_property *property, uint64_t 
 value);/synopsis
 +  para
 +Set the value of the given CRTC property to
 +parametervalue/parameter. See xref 
 linkend=drm-kms-properties/
 +for more information about properties.
 +  /para
 +/listitem
 +listitem
synopsisvoid (*gamma_set)(struct drm_crtc *crtc, u16 *r, u16 
 *g, u16 *b,
  uint32_t start, uint32_t size);/synopsis
para
 @@ -1385,6 +1394,15 @@ int max_width, max_height;/synopsis
xref linkend=drm-kms-init/.
  /para
/listitem
 +  listitem
 +synopsisvoid (*set_property)(struct drm_plane *plane,
 + struct drm_property *property, uint64_t 
 value);/synopsis
 +para
 +  Set the value of the given plane property to
 +  parametervalue/parameter. See xref 
 linkend=drm-kms-properties/
 +  for more information about properties.
 +/para
 +  /listitem
  /itemizedlist
/sect3
  /sect2
 @@ -1594,6 +1612,15 @@ int max_width, max_height;/synopsis
titleMiscellaneous/title
itemizedlist
  listitem
 +  synopsisvoid (*set_property)(struct drm_connector *connector,
 + struct drm_property *property, uint64_t 
 value);/synopsis
 +  para
 +Set the value of the given connector property to
 +parametervalue/parameter. See xref 
 linkend=drm-kms-properties/
 +for more information about properties.
 +  /para
 +/listitem
 +listitem
synopsisvoid (*destroy)(struct drm_connector 
 *connector);/synopsis
para
  Destroy the connector when not needed anymore. See
 @@ -2187,6 +2214,122 @@ void intel_crt_init(struct drm_device *dev)
  /sect2
/sect1
  
 +  !-- Internals: kms properties --
 +
 +  sect1 id=drm-kms-properties
 +titleKMS Properties/title
 +para
 +  Drivers may need to expose additional parameters to applications than
 +  those described in the previous sections. KMS supports attaching
 +  properties to CRTCs, connectors and planes and offers a userspace API 
 to
 +  list, get and set the property values.
 +/para
 +para
 +  Properties are identified by a name that uniquely defines the property
 +  purpose, and store an associated value. For all property types except 
 blob
 +  properties the value is a 64-bit unsigned integer.
 +/para
 +para
 +  KMS differentiates between properties and property instances. Drivers
 +  first create properties and then create and associate individual 
 instances
 +  of those properties to objects. A property can be instantiated multiple
 +  times and associated with different objects. Values are stored in 
 property
 +  instances, and all other property information are stored in the propery
 +  and shared between all instances of the property.
 +/para
 +para
 +  Every property is created with a type that influences how the KMS core
 +  handles the property. Supported property types are
 +  variablelist
 +varlistentry
 +  termDRM_MODE_PROP_RANGE/term
 +  listitemparaRanges properties report their minimum and maximum

s/Ranges/Range/

 +admissible values. The KMS core verifies that values set by
 +application fit in that range./para/listitem
 +/varlistentry
 +varlistentry
 +  termDRM_MODE_PROP_ENUM/term
 +  listitemparaEnumerated properties take a numerical value that
 +ranges from 0 to the number of enumered values defined by the

s/enumered/enumerated/

 +property minus one, and associate a free-formed string name to 
 each
 +value. Application can retrieve the list of define value-name 
 pairs

s/Application/Applications/
s/define/defined/

 +and use the numerical value to get and set property instance 
 values.
 +  

[PATCH v2 0/2] Documentation improvements

[Laurent Pinchart]

Hello,

Here are two patches that improve the DRM documentation by documenting the KMS
property API, and removing an outdated note about the i915 driver.

Changes since v1:

- Fixed typos in patch 2/2

Laurent Pinchart (2):
  drm/doc: Remove outdated note about i915 driver not behaving properly
  drm/doc: Document the KMS property API

 Documentation/DocBook/drm.tmpl | 147 +++--
 1 file changed, 143 insertions(+), 4 deletions(-)

-- 
Regards,

Laurent Pinchart

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

[PATCH v2 1/2] drm/doc: Remove outdated note about i915 driver not behaving properly

[Laurent Pinchart]

From: Laurent Pinchart laurent.pinch...@ideasonboard.com

The i915 driver has been fixed not to modify the mode argument of the
encoder mode_fixup operation. Remove the related comment from the
documentation.

Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Reviewed-by: Alex Deucher alexander.deuc...@amd.com
---
 Documentation/DocBook/drm.tmpl | 4 
 1 file changed, 4 deletions(-)

diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
index a608094..cea420d 100644
--- a/Documentation/DocBook/drm.tmpl
+++ b/Documentation/DocBook/drm.tmpl
@@ -1868,10 +1868,6 @@ void intel_crt_init(struct drm_device *dev)
   synopsisbool (*mode_fixup)(struct drm_encoder *encoder,
const struct drm_display_mode *mode,
struct drm_display_mode *adjusted_mode);/synopsis
-  notepara
-FIXME: The mode argument be const, but the i915 driver modifies
-mode-gt;clock in functionintel_dp_mode_fixup/function.
-  /para/note
   para
 Let encoders adjust the requested mode or reject it completely. 
This
 operation returns true if the mode is accepted (possibly after 
being
-- 
1.8.1.5

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

[PATCH v2 2/2] drm/doc: Document the KMS property API

[Laurent Pinchart]

Signed-off-by: Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com
Reviewed-by: Alex Deucher alexander.deuc...@amd.com
---
 Documentation/DocBook/drm.tmpl | 143 +
 1 file changed, 143 insertions(+)

diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
index cea420d..4d54ac8 100644
--- a/Documentation/DocBook/drm.tmpl
+++ b/Documentation/DocBook/drm.tmpl
@@ -1236,6 +1236,15 @@ int max_width, max_height;/synopsis
   titleMiscellaneous/title
   itemizedlist
 listitem
+  synopsisvoid (*set_property)(struct drm_crtc *crtc,
+ struct drm_property *property, uint64_t value);/synopsis
+  para
+Set the value of the given CRTC property to
+parametervalue/parameter. See xref 
linkend=drm-kms-properties/
+for more information about properties.
+  /para
+/listitem
+listitem
   synopsisvoid (*gamma_set)(struct drm_crtc *crtc, u16 *r, u16 
*g, u16 *b,
 uint32_t start, uint32_t size);/synopsis
   para
@@ -1385,6 +1394,15 @@ int max_width, max_height;/synopsis
   xref linkend=drm-kms-init/.
 /para
   /listitem
+  listitem
+synopsisvoid (*set_property)(struct drm_plane *plane,
+ struct drm_property *property, uint64_t value);/synopsis
+para
+  Set the value of the given plane property to
+  parametervalue/parameter. See xref 
linkend=drm-kms-properties/
+  for more information about properties.
+/para
+  /listitem
 /itemizedlist
   /sect3
 /sect2
@@ -1594,6 +1612,15 @@ int max_width, max_height;/synopsis
   titleMiscellaneous/title
   itemizedlist
 listitem
+  synopsisvoid (*set_property)(struct drm_connector *connector,
+ struct drm_property *property, uint64_t value);/synopsis
+  para
+Set the value of the given connector property to
+parametervalue/parameter. See xref 
linkend=drm-kms-properties/
+for more information about properties.
+  /para
+/listitem
+listitem
   synopsisvoid (*destroy)(struct drm_connector 
*connector);/synopsis
   para
 Destroy the connector when not needed anymore. See
@@ -2187,6 +2214,122 @@ void intel_crt_init(struct drm_device *dev)
 /sect2
   /sect1
 
+  !-- Internals: kms properties --
+
+  sect1 id=drm-kms-properties
+titleKMS Properties/title
+para
+  Drivers may need to expose additional parameters to applications than
+  those described in the previous sections. KMS supports attaching
+  properties to CRTCs, connectors and planes and offers a userspace API to
+  list, get and set the property values.
+/para
+para
+  Properties are identified by a name that uniquely defines the property
+  purpose, and store an associated value. For all property types except 
blob
+  properties the value is a 64-bit unsigned integer.
+/para
+para
+  KMS differentiates between properties and property instances. Drivers
+  first create properties and then create and associate individual 
instances
+  of those properties to objects. A property can be instantiated multiple
+  times and associated with different objects. Values are stored in 
property
+  instances, and all other property information are stored in the propery
+  and shared between all instances of the property.
+/para
+para
+  Every property is created with a type that influences how the KMS core
+  handles the property. Supported property types are
+  variablelist
+varlistentry
+  termDRM_MODE_PROP_RANGE/term
+  listitemparaRange properties report their minimum and maximum
+admissible values. The KMS core verifies that values set by
+application fit in that range./para/listitem
+/varlistentry
+varlistentry
+  termDRM_MODE_PROP_ENUM/term
+  listitemparaEnumerated properties take a numerical value that
+ranges from 0 to the number of enumerated values defined by the
+property minus one, and associate a free-formed string name to each
+value. Applications can retrieve the list of defined value-name 
pairs
+and use the numerical value to get and set property instance 
values.
+/para/listitem
+/varlistentry
+varlistentry
+  termDRM_MODE_PROP_BITMASK/term
+  listitemparaBitmask properties are enumeration properties that
+additionally restrict all enumerated values to the 0..63 range.
+Bitmask property instance values combine one or more of the

Re: [PATCH 2/2] drm/doc: Document the KMS property API

[Laurent Pinchart]

Hi Hans,

Thanks for the review.

On Saturday 22 June 2013 15:32:43 Hans Verkuil wrote:
 Hi Laurent,
 
 Is this a hint to me that V4L2 should have a property API as well? :-)

Honestly, not at all, but I'm of course willing to discuss the subject ;-)

 Anyway, I found some typos below:

Thank you. I'll fix them in v2.

-- 
Regards,

Laurent Pinchart

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

Re: Regression introduced by 90797e6d1ec0dfde6ba62a48b9ee3803887d6ed4 (drm/i915: create compact dma scatter lists for gem objects) Was:Re: i915 mapping large (3MB) scatter list, hitting limits on ce

[Chris Wilson]

On Fri, Jun 21, 2013 at 10:03:43PM -0400, Konrad Rzeszutek Wilk wrote:
 On Fri, Jun 21, 2013 at 03:28:28PM -0400, Konrad Rzeszutek Wilk wrote:
  Hey,
 
 CC-ing Imre,
 
 Imre, your patch 90797e6d1ec0dfde6ba62a48b9ee3803887d6ed4
 (drm/i915: create compact dma scatter lists for gem objects) is the cause
 of the regression.
 
 If I revert your patch it boots fine without any trouble.
 
 I am not entirely sure why that is - as I added some debug code in
 lib/swiotlb.c to trigger when it can't find 3MB  area (which
 is what I thought initially was the issue) - but none of the debug
 code seems to be hit.
 
 Any thoughts?

You should be hitting drivers/iommu/intel-iommu.c for the dma
translation. It looks like the contiguous 3MiB segment will be special
as it is the first sg that __domain_mapping() will attempt to allocate a
superpage (2MiB) for. What goes wrong at point, I am not sure, but I
would suggest peppering intel-iommu.c with printk to track down the error.
-Chris

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

'Timed out waiting for forcewake old ack to clear' and hangup on IvyBridge system

[Guenter Roeck]

Hi all,

after upgrading one of my servers to 3.8, then 3.9.7 and 3.10-rc6, I started to
see lots of Timed out waiting for forcewake old ack to clear error messages,
including hang-ups especially if the system was highly loaded. With 3.5.24
everything was fine.

After backing out commit 36ec8f877 (drm/i915: unconditionally use mt forcewake
on hsw/ivb), everything is back to normal. The log message is still there, but
only once during boot, and the system runs stable.

CPU is Intel(R) Core(TM) i7-3770K CPU @ 3.50GHz, mainboard is Supermicro
C7H61, BIOS version 2.00 dated 11/02/2012. Configuration file is whatever
comes with Ubuntu; I'll be happy to provide a copy if anyone thinks it might
help.

Any idea what else I can do besides using a special kernel with the backed out
commit ? Is it possible that others have the same problem ?

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

Re: 'Timed out waiting for forcewake old ack to clear' and hangup on IvyBridge system

[Jesse Barnes]

On Fri, 21 Jun 2013 23:58:08 -0700
Guenter Roeck li...@roeck-us.net wrote:

 Hi all,
 
 after upgrading one of my servers to 3.8, then 3.9.7 and 3.10-rc6, I started 
 to
 see lots of Timed out waiting for forcewake old ack to clear error messages,
 including hang-ups especially if the system was highly loaded. With 3.5.24
 everything was fine.
 
 After backing out commit 36ec8f877 (drm/i915: unconditionally use mt forcewake
 on hsw/ivb), everything is back to normal. The log message is still there, but
 only once during boot, and the system runs stable.
 
 CPU is Intel(R) Core(TM) i7-3770K CPU @ 3.50GHz, mainboard is Supermicro
 C7H61, BIOS version 2.00 dated 11/02/2012. Configuration file is whatever
 comes with Ubuntu; I'll be happy to provide a copy if anyone thinks it might
 help.
 
 Any idea what else I can do besides using a special kernel with the backed out
 commit ? Is it possible that others have the same problem ?

Ouch, so a BIOS that uses the other forcewake mechanism seems to have
escaped.  Is there a newer one available for your system?  I'm hoping
it'll fix the issue, otherwise we may have to introduce both methods
for IVB again...

-- 
Jesse Barnes, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/2] power: add new interface to return pm_transition state

[Rafael J. Wysocki]

On Saturday, June 22, 2013 02:11:14 PM Shuah Khan wrote:
 Add a new interface get_pm_transition() to return pm_transition state.
 This interface is intended to be used from dev_pm_ops class and type
 suspend interfaces that call legacy pm ops driver suspend interfaces.
 Legacy suspend pm_ops take pm_message_t as a parameter.
 
 e.g: drm_class_suspend() calls into driver suspend routines
 via drm_dev-driver-suspend(drm_dev, state).
 
 Once drm_class_suspend() is converted to dev_pm_ops, it will no longer
 have access to pm_transition which it has to pass into driver legacy
 suspend calls. get_pm_transition() interface addresses this need.

That shouldn't be necessary because each transition has its own callback
in strict dev_pm_ops.

Thanks,
Rafael


 Signed-off-by: Shuah Khan shuah...@samsung.com
 ---
  drivers/base/power/main.c |   17 +
  include/linux/pm.h|3 +++
  2 files changed, 20 insertions(+)
 
 diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c
 index c2132b8..3e2e09d 100644
 --- a/drivers/base/power/main.c
 +++ b/drivers/base/power/main.c
 @@ -57,6 +57,23 @@ static pm_message_t pm_transition;
  static int async_error;
  
  /**
 + * get_pm_transition - return pm_transition state.
 + * This interface is intended to be used from dev_pm_ops class and type
 + * suspend interfaces that call legacy pm ops driver suspend interfaces.
 + * Legacy suspend pm_ops take pm_message_t as a parameter.
 + * e.g: drm_class_suspend() calls into driver suspend routines
 + * via drm_dev-driver-suspend(drm_dev, state).
 + * Once drm_class_suspend() is converted to dev_pm_ops, it will no longer
 + * have access to pm_transition which it has to pass into driver legacy
 + * suspend calls. get_pm_transition() interface addresses this need.
 +*/
 +pm_message_t get_pm_transition()
 +{
 + return pm_transition;
 +}
 +EXPORT_SYMBOL_GPL(get_pm_transition);
 +
 +/**
   * device_pm_sleep_init - Initialize system suspend-related device fields.
   * @dev: Device object being initialized.
   */
 diff --git a/include/linux/pm.h b/include/linux/pm.h
 index a224c7f..46f3252 100644
 --- a/include/linux/pm.h
 +++ b/include/linux/pm.h
 @@ -63,6 +63,9 @@ typedef struct pm_message {
   int event;
  } pm_message_t;
  
 +/* drivers/base/power/main.c */
 +extern pm_message_t get_pm_transition(void);
 +
  /**
   * struct dev_pm_ops - device PM callbacks
   *
 
-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 66064] New: ATI Mobility FireGL V5250 hardware incorrectly matched with RV530 dri settings in r_300.dri

[bugzilla-daemon]

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

  Priority: medium
Bug ID: 66064
  Assignee: dri-devel@lists.freedesktop.org
   Summary: ATI Mobility FireGL V5250 hardware incorrectly matched
with RV530 dri settings in r_300.dri
  Severity: normal
Classification: Unclassified
OS: Linux (All)
  Reporter: belfrancis2...@yahoo.ca
  Hardware: x86 (IA32)
Status: NEW
   Version: XOrg 6.7.0
 Component: DRM/Radeon
   Product: DRI

Running Fedora 18 linux distribution with untainted kernel version 3.9.6-200 on
a Lenovo Thinkpad T60p with an ATI Mobility FireGL V5250 graphics card a video
information mismatch was discovered by running the following command:

$ LIB_GL=verbose glxinfo

The following lines in the output indicates a mismatch:

OpenGL vendor string: X.Org R300 Project
OpenGL renderer string: Gallium 0.4 on ATI RV530
OpenGL version string: 2.1 Mesa 9.2.0
OpenGL shading language version string: 1.20

... but the ATI Mobility FireGL V5250 graphics card has always been matched
with the RV350 graphics set.  This mismatch might be causing some video
glitches and visual artefacts from font rendering mistakes to malformed window
decorations.

In addition, if you run the following command:

$ dmesg | grep RV

you will get the following line:

[1.793445] [drm] initializing kernel modesetting (RV530 0x1002:0x71D4
0x17AA:0x20A4).

Again should the modesetting be using RV350 specs in this case?

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

stereoscopic: 3D over standard 1080p using remote to switch into 3D mode.

[Mike Mestnik]

Hello,
  I've successfully done a few tests using Chrome and WebGL to render
two images side by side and having the TV compose the images into
stereoscopic 3D.  I don't know why there was a notion that one needed to
send special HDMI commands.  Well perhaps to reach full 1080p these
commands might be necessary, although it looks like most TVs can figure
out what to do if they are given the right modeline and I feel that
these special HDMI commands may simply be cosmetic after reading
2010_03_04_3DExtraction_HDMI_Spec1.4a.pdf and only necessary if you want
to do something out of the ordinary.

Currently the display hardware is vary far ahead of the software and
frankly it's unavailable for novices like myself.  While my tests were
conclusive using different shapes altogether in each eye, I was unable
to line things up to my satisfaction to produce anything usable.  I just
got really board with this project because of my skill level.

One area I find interesting is that we will once again have a half
frame, as the technology of my set uses shutter glasses it would seem
appropriate to render things in a fashion much like what's done for
interlaced content.  In that an object moving horizontally would be
drawn in 2 places for each eye so that the position of the object is
consistent for when the user sees it.

I'm looking into upgrading to a 4K set, now that they are affordable...
 I plan to sit right up next to it and use it like any other monitor, so
I'm not concerned about that oddly irrelevant debates that those
resolutions are not usable.  It's like a web developer refusing to
accept anything greater then 800x600, ppl should just move past there
preconceptions an opinions...  That said the TVs I'm looking at use
another technology that uses even and odd rows for each eye, so the
previously mentioned half frames are out and we bring in a concept
similar to sub-pixel ordering which while not offering any great
challenges or rewards it may produce a loss in quality if not handled
correctly.

It's clear that to fully support these technologies a great deal of work
would be needed.  Leaving one vary big question worth asking...

What's important and what course of action are ppl thinking?

Currently Gnome has a UI for tweaking font rendering.  How, if at all,
should stereoscopic hardware be configured?  Especially with regard to
technology type and perhaps future displays capable of multiple
technologies?  There are also glassless stereoscopic technologies as
possibilities.

I'm most concerned with what ppl are waiting for, I've moved from a CTR
to this rig because I didn't think till now that there were any displays
that were fast enough for me.  That and I noticed that I rarely used the
interlaced modes to deinterlace content made for TV.  Now with 4K I can
finally have big size and high resolution, it'll be nice to have two 55
displays side by side.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 66067] New: Trine 2 color problems on Radeon HD 6770 (Juniper)

[bugzilla-daemon]

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

  Priority: medium
Bug ID: 66067
  Assignee: dri-devel@lists.freedesktop.org
   Summary: Trine 2 color problems on Radeon HD 6770 (Juniper)
  Severity: normal
Classification: Unclassified
OS: All
  Reporter: nmi...@gmail.com
  Hardware: Other
Status: NEW
   Version: git
 Component: Drivers/DRI/R600
   Product: Mesa

Created attachment 81244
  -- https://bugs.freedesktop.org/attachment.cgi?id=81244action=edit
rendering with Mesa d282f4ea9b99e4eefec8ce0664cdf49d53d7b052

Trine 2 colors/lighting are wrong with Mesa 9.2 and current git
(d282f4ea9b99e4eefec8ce0664cdf49d53d7b052) on a Radeon HD 6770 Juniper XT.
Game renders correctly using the Catalyst drivers.

Colors are wrong enough to make some puzzles unsolvable because portions of the
screen are too dark to see.

Sample apitrace is at
https://docs.google.com/file/d/0B8G3Ivdx_-JNTV96YjgyNWplZ0U/edit?usp=sharing

Attached screenshots were generated using glretrace -b -S 5670984

-- 
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 66067] Trine 2 color problems on Radeon HD 6770 (Juniper)

[bugzilla-daemon]

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

--- Comment #1 from Nicholas Miell nmi...@gmail.com ---
Created attachment 81245
  -- https://bugs.freedesktop.org/attachment.cgi?id=81245action=edit
rendering with Catalyst

-- 
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 66067] Trine 2 color problems on Radeon HD 6770 (Juniper)

[bugzilla-daemon]

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

Nicholas Miell nmi...@gmail.com changed:

   What|Removed |Added

  Attachment #81244|text/plain  |image/png
  mime type||

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