Re: [PATCH] staging: omapdrm: Fix DMM sparse warnings
On Thu, Aug 9, 2012 at 10:26 PM, Rob Clark wrote:
> On Thu, Aug 9, 2012 at 12:14 AM, Andy Gross wrote:
>> Fix the following sparse warnings:
>>
>> drivers/staging/omapdrm/omap_dmm_tiler.c:123:13:
>>warning: symbol 'omap_dmm_irq_handler' was not declared.
>>Should it be static?
>>
>> drivers/staging/omapdrm/omap_dmm_tiler.c:370:24:
>>warning: Using plain integer as NULL pointer
>>
>> Signed-off-by: Andy Gross
>
> Signed-off-by: Rob Clark
Reviewed-by: Sumit Semwal
>
>> ---
>> drivers/staging/omapdrm/omap_dmm_tiler.c |4 ++--
>> 1 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/staging/omapdrm/omap_dmm_tiler.c
>> b/drivers/staging/omapdrm/omap_dmm_tiler.c
>> index 8619783..ec7a5c8 100644
>> --- a/drivers/staging/omapdrm/omap_dmm_tiler.c
>> +++ b/drivers/staging/omapdrm/omap_dmm_tiler.c
>> @@ -120,7 +120,7 @@ static int wait_status(struct refill_engine *engine,
>> uint32_t wait_mask)
>> return 0;
>> }
>>
>> -irqreturn_t omap_dmm_irq_handler(int irq, void *arg)
>> +static irqreturn_t omap_dmm_irq_handler(int irq, void *arg)
>> {
>> struct dmm *dmm = arg;
>> uint32_t status = readl(dmm->base + DMM_PAT_IRQSTATUS);
>> @@ -367,7 +367,7 @@ struct tiler_block *tiler_reserve_1d(size_t size)
>> int num_pages = (size + PAGE_SIZE - 1) >> PAGE_SHIFT;
>>
>> if (!block)
>> - return 0;
>> + return ERR_PTR(-ENOMEM);
>>
>> block->fmt = TILFMT_PAGE;
>>
>> --
>> 1.7.5.4
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
> ___
> 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 41265] Radeon KMS does not work on thunderbolt media dock
https://bugs.freedesktop.org/show_bug.cgi?id=41265
--- Comment #25 from gy...@gmx.de 2012-08-10 12:11:40 UTC ---
i don't know why, but it don't get the VFCT Table.
this returns false:
(!ACPI_SUCCESS(acpi_get_table("VFCT", 1, &hdr)))
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- 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
[RFCv3 PATCH 2/8] V4L2 spec: document the new DV controls and ioctls.
Signed-off-by: Hans Verkuil --- Documentation/DocBook/media/v4l/biblio.xml | 40 +++ Documentation/DocBook/media/v4l/controls.xml | 161 ++ Documentation/DocBook/media/v4l/v4l2.xml |1 + 3 files changed, 202 insertions(+) diff --git a/Documentation/DocBook/media/v4l/biblio.xml b/Documentation/DocBook/media/v4l/biblio.xml index 1078e45..860626a 100644 --- a/Documentation/DocBook/media/v4l/biblio.xml +++ b/Documentation/DocBook/media/v4l/biblio.xml @@ -226,4 +226,44 @@ in the frequency range from 87,5 to 108,0 MHz VESA and Industry Standards and Guidelines for Computer Display Monitor Timing (DMT) + + EDID + + Video Electronics Standards Association +(http://www.vesa.org";>http://www.vesa.org) + + VESA Enhanced Extended Display Identification Data Standard + Release A, Revision 2 + + + + HDCP + + Digital Content Protection LLC +(http://www.digital-cp.com";>http://www.digital-cp.com) + + High-bandwidth Digital Content Protection System + Revision 1.3 + + + + HDMI + + HDMI Licensing LLC +(http://www.hdmi.org";>http://www.hdmi.org) + + High-Definition Multimedia Interface + Specification Version 1.4a + + + + DP + + Video Electronics Standards Association +(http://www.vesa.org";>http://www.vesa.org) + + VESA DisplayPort Standard + Version 1, Revision 2 + + diff --git a/Documentation/DocBook/media/v4l/controls.xml b/Documentation/DocBook/media/v4l/controls.xml index b0964fb..1b0b95e 100644 --- a/Documentation/DocBook/media/v4l/controls.xml +++ b/Documentation/DocBook/media/v4l/controls.xml @@ -4274,4 +4274,165 @@ interface and may change in the future. + + + Digital Video Control Reference + + + Experimental + + This is an experimental interface and may + change in the future. + + + + The Digital Video control class is intended to control receivers + and transmitters for http://en.wikipedia.org/wiki/Vga";>VGA, + http://en.wikipedia.org/wiki/Digital_Visual_Interface";>DVI + (Digital Visual Interface), HDMI () and DisplayPort (). + These controls are generally expected to be private to the receiver or transmitter + subdevice that implements them, so they are only exposed on the + /dev/v4l-subdev* device node. + + + Note that these devices can have multiple input or output pads which are + hooked up to e.g. HDMI connectors. Even though the subdevice will receive or + transmit video from/to only one of those pads, the other pads can still be + active when it comes to EDID (Extended Display Identification Data, + ) and HDCP (High-bandwidth Digital Content + Protection System, ) processing, allowing the device + to do the fairly slow EDID/HDCP handling in advance. This allows for quick + switching between connectors. + + These pads appear in several of the controls in this section as + bitmasks, one bit for each pad. Bit 0 corresponds to pad 0, bit 1 to pad 1, + etc. The maximum value of the control is the set of valid pads. + + + Digital Video Control IDs + + + + + + + + + + + ID + Type + Description + + + + + + V4L2_CID_DV_CLASS + class + + + The Digital Video class descriptor. + + + V4L2_CID_DV_TX_HOTPLUG + bitmask + + + Many connectors have a hotplug pin which is high + if EDID information is available from the source. This control shows the + state of the hotplug pin as seen by the transmitter. + Each bit corresponds to an output pad on the transmitter. If an output pad + does not have an associated hotplug pin, then the bit for that pad will be 0. + This read-only control is applicable to DVI-D, HDMI and DisplayPort connectors. + + + + V4L2_CID_DV_TX_RXSENSE + bitmask + + + Rx Sense is the detection of pull-ups on the TMDS +clock lines. This normally means that the sink has left/entered standby (i.e. + the transmitter can sense that the receiver is ready to receive video). + Each bit corresponds to an output pad on the transmitter. If an output pad + does not have an associated Rx Sense, then the bit for that pad will be 0. + This read-only control is applicable to DVI-D and HDMI devices. + + + + V4L2_CID_DV_TX_EDID_PRESENT + bitmask + + + When the transmitter sees the hotplug signal from the +
[PATCH] drm/usb: select USB_SUPPORT in Kconfig
DRM_USB selects USB. However, USB depends on USB_SUPPORT and USB_ARCH_HAS_HCD. Thus, selecting USB_SUPPORT in Kconfig avoids the following warning (detected when DisplayLink was selected using exynos4_defconfig): warning: (MOUSE_APPLETOUCH && MOUSE_BCM5974 && MOUSE_SYNAPTICS_USB && JOYSTICK_XPAD && TABLET_USB_ACECAD && TABLET_USB_AIPTEK && TABLET_USB_HANWANG && TABLET_USB_KBTAB && TABLET_USB_WACOM && TOUCHSCREEN_USB_COMPOSITE && INPUT_ATI_REMOTE2 && INPUT_KEYSPAN_REMOTE && INPUT_POWERMATE && INPUT_YEALINK && INPUT_CM109 && RC_ATI_REMOTE && IR_IMON && IR_MCEUSB && IR_REDRAT3 && IR_STREAMZAP && IR_IGUANA && DRM_USB) selects USB which has unmet direct dependencies (USB_SUPPORT && USB_ARCH_HAS_HCD) Signed-off-by: Sachin Kamat --- drivers/gpu/drm/Kconfig |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index 23120c0..45536db 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -23,6 +23,7 @@ config DRM_USB tristate depends on DRM select USB + select USB_SUPPORT config DRM_KMS_HELPER tristate -- 1.7.4.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFCv3 PATCH 1/8] v4l2 core: add the missing pieces to support DVI/HDMI/DisplayPort.
These new controls and two new ioctls make it possible to properly support
VGA, DVI-A/D/I, HDMI and DisplayPort connectors. All these controls and the
ioctls are all at the sub-device level. They are meant for V4L2 bridge/platform
drivers or to be accessed on embedded systems through /dev/v4l-subdev* device
nodes.
Signed-off-by: Hans Verkuil
---
include/linux/v4l2-subdev.h | 10 ++
include/linux/videodev2.h | 23 +++
2 files changed, 33 insertions(+)
diff --git a/include/linux/v4l2-subdev.h b/include/linux/v4l2-subdev.h
index 8c57ee9..a426a78 100644
--- a/include/linux/v4l2-subdev.h
+++ b/include/linux/v4l2-subdev.h
@@ -148,6 +148,14 @@ struct v4l2_subdev_selection {
__u32 reserved[8];
};
+struct v4l2_subdev_edid {
+ __u32 pad;
+ __u32 start_block;
+ __u32 blocks;
+ __u32 reserved[5];
+ __u8 __user *edid;
+};
+
#define VIDIOC_SUBDEV_G_FMT_IOWR('V', 4, struct v4l2_subdev_format)
#define VIDIOC_SUBDEV_S_FMT_IOWR('V', 5, struct v4l2_subdev_format)
#define VIDIOC_SUBDEV_G_FRAME_INTERVAL \
@@ -166,5 +174,7 @@ struct v4l2_subdev_selection {
_IOWR('V', 61, struct v4l2_subdev_selection)
#define VIDIOC_SUBDEV_S_SELECTION \
_IOWR('V', 62, struct v4l2_subdev_selection)
+#define VIDIOC_SUBDEV_G_EDID _IOWR('V', 63, struct v4l2_subdev_edid)
+#define VIDIOC_SUBDEV_S_EDID _IOWR('V', 64, struct v4l2_subdev_edid)
#endif
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 7a147c8..91939a7 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -1250,6 +1250,7 @@ struct v4l2_ext_controls {
#define V4L2_CTRL_CLASS_JPEG 0x009d/* JPEG-compression
controls */
#define V4L2_CTRL_CLASS_IMAGE_SOURCE 0x009e/* Image source
controls */
#define V4L2_CTRL_CLASS_IMAGE_PROC 0x009f /* Image processing controls */
+#define V4L2_CTRL_CLASS_DV 0x00a0 /* Digital Video controls */
#define V4L2_CTRL_ID_MASK(0x0fff)
#define V4L2_CTRL_ID2CLASS(id)((id) & 0x0fffUL)
@@ -1993,6 +1994,28 @@ enum v4l2_jpeg_chroma_subsampling {
#define V4L2_CID_LINK_FREQ (V4L2_CID_IMAGE_PROC_CLASS_BASE
+ 1)
#define V4L2_CID_PIXEL_RATE(V4L2_CID_IMAGE_PROC_CLASS_BASE
+ 2)
+/* DV-class control IDs defined by V4L2 */
+#define V4L2_CID_DV_CLASS_BASE (V4L2_CTRL_CLASS_DV | 0x900)
+#define V4L2_CID_DV_CLASS (V4L2_CTRL_CLASS_DV | 1)
+
+#defineV4L2_CID_DV_TX_HOTPLUG (V4L2_CID_DV_CLASS_BASE
+ 1)
+#defineV4L2_CID_DV_TX_RXSENSE (V4L2_CID_DV_CLASS_BASE
+ 2)
+#defineV4L2_CID_DV_TX_EDID_PRESENT (V4L2_CID_DV_CLASS_BASE
+ 3)
+#defineV4L2_CID_DV_TX_MODE (V4L2_CID_DV_CLASS_BASE
+ 4)
+enum v4l2_dv_tx_mode {
+ V4L2_DV_TX_MODE_DVI_D = 0,
+ V4L2_DV_TX_MODE_HDMI= 1,
+};
+#define V4L2_CID_DV_TX_RGB_RANGE (V4L2_CID_DV_CLASS_BASE + 5)
+enum v4l2_dv_rgb_range {
+ V4L2_DV_RGB_RANGE_AUTO= 0,
+ V4L2_DV_RGB_RANGE_LIMITED = 1,
+ V4L2_DV_RGB_RANGE_FULL= 2,
+};
+
+#defineV4L2_CID_DV_RX_POWER_PRESENT(V4L2_CID_DV_CLASS_BASE
+ 100)
+#define V4L2_CID_DV_RX_RGB_RANGE (V4L2_CID_DV_CLASS_BASE + 101)
+
/*
* T U N I N G
*/
--
1.7.10.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFCv3 PATCH 3/8] v4l2-subdev: add support for the new edid ioctls.
Signed-off-by: Hans Verkuil
---
drivers/media/video/v4l2-compat-ioctl32.c | 57 +
drivers/media/video/v4l2-ioctl.c | 13 +++
drivers/media/video/v4l2-subdev.c |6 +++
include/media/v4l2-subdev.h |2 +
4 files changed, 78 insertions(+)
diff --git a/drivers/media/video/v4l2-compat-ioctl32.c
b/drivers/media/video/v4l2-compat-ioctl32.c
index 9ebd5c5..e843705 100644
--- a/drivers/media/video/v4l2-compat-ioctl32.c
+++ b/drivers/media/video/v4l2-compat-ioctl32.c
@@ -16,6 +16,7 @@
#include
#include
#include
+#include
#include
#include
@@ -729,6 +730,44 @@ static int put_v4l2_event32(struct v4l2_event *kp, struct
v4l2_event32 __user *u
return 0;
}
+struct v4l2_subdev_edid32 {
+ __u32 pad;
+ __u32 start_block;
+ __u32 blocks;
+ __u32 reserved[5];
+ compat_caddr_t edid;
+};
+
+static int get_v4l2_subdev_edid32(struct v4l2_subdev_edid *kp, struct
v4l2_subdev_edid32 __user *up)
+{
+ u32 tmp;
+
+ if (!access_ok(VERIFY_READ, up, sizeof(struct v4l2_subdev_edid32)) ||
+ get_user(kp->pad, &up->pad) ||
+ get_user(kp->start_block, &up->start_block) ||
+ get_user(kp->blocks, &up->blocks) ||
+ get_user(tmp, &up->edid) ||
+ copy_from_user(kp->reserved, up->reserved,
sizeof(kp->reserved)))
+ return -EFAULT;
+ kp->edid = compat_ptr(tmp);
+ return 0;
+}
+
+static int put_v4l2_subdev_edid32(struct v4l2_subdev_edid *kp, struct
v4l2_subdev_edid32 __user *up)
+{
+ u32 tmp = (u32)((unsigned long)kp->edid);
+
+ if (!access_ok(VERIFY_WRITE, up, sizeof(struct v4l2_subdev_edid32)) ||
+ put_user(kp->pad, &up->pad) ||
+ put_user(kp->start_block, &up->start_block) ||
+ put_user(kp->blocks, &up->blocks) ||
+ put_user(tmp, &up->edid) ||
+ copy_to_user(kp->reserved, up->reserved, sizeof(kp->reserved)))
+ return -EFAULT;
+ return 0;
+}
+
+
#define VIDIOC_G_FMT32 _IOWR('V', 4, struct v4l2_format32)
#define VIDIOC_S_FMT32 _IOWR('V', 5, struct v4l2_format32)
#define VIDIOC_QUERYBUF32 _IOWR('V', 9, struct v4l2_buffer32)
@@ -738,6 +777,8 @@ static int put_v4l2_event32(struct v4l2_event *kp, struct
v4l2_event32 __user *u
#define VIDIOC_DQBUF32 _IOWR('V', 17, struct v4l2_buffer32)
#define VIDIOC_ENUMSTD32 _IOWR('V', 25, struct v4l2_standard32)
#define VIDIOC_ENUMINPUT32 _IOWR('V', 26, struct v4l2_input32)
+#define VIDIOC_SUBDEV_G_EDID32 _IOWR('V', 63, struct v4l2_subdev_edid32)
+#define VIDIOC_SUBDEV_S_EDID32 _IOWR('V', 64, struct v4l2_subdev_edid32)
#define VIDIOC_TRY_FMT32 _IOWR('V', 64, struct v4l2_format32)
#define VIDIOC_G_EXT_CTRLS32_IOWR('V', 71, struct v4l2_ext_controls32)
#define VIDIOC_S_EXT_CTRLS32_IOWR('V', 72, struct v4l2_ext_controls32)
@@ -765,6 +806,7 @@ static long do_video_ioctl(struct file *file, unsigned int
cmd, unsigned long ar
struct v4l2_ext_controls v2ecs;
struct v4l2_event v2ev;
struct v4l2_create_buffers v2crt;
+ struct v4l2_subdev_edid v2edid;
unsigned long vx;
int vi;
} karg;
@@ -797,6 +839,8 @@ static long do_video_ioctl(struct file *file, unsigned int
cmd, unsigned long ar
case VIDIOC_S_OUTPUT32: cmd = VIDIOC_S_OUTPUT; break;
case VIDIOC_CREATE_BUFS32: cmd = VIDIOC_CREATE_BUFS; break;
case VIDIOC_PREPARE_BUF32: cmd = VIDIOC_PREPARE_BUF; break;
+ case VIDIOC_SUBDEV_G_EDID32: cmd = VIDIOC_SUBDEV_G_EDID; break;
+ case VIDIOC_SUBDEV_S_EDID32: cmd = VIDIOC_SUBDEV_S_EDID; break;
}
switch (cmd) {
@@ -814,6 +858,12 @@ static long do_video_ioctl(struct file *file, unsigned int
cmd, unsigned long ar
compatible_arg = 0;
break;
+ case VIDIOC_SUBDEV_G_EDID:
+ case VIDIOC_SUBDEV_S_EDID:
+ err = get_v4l2_subdev_edid32(&karg.v2edid, up);
+ compatible_arg = 0;
+ break;
+
case VIDIOC_G_FMT:
case VIDIOC_S_FMT:
case VIDIOC_TRY_FMT:
@@ -906,6 +956,11 @@ static long do_video_ioctl(struct file *file, unsigned int
cmd, unsigned long ar
err = put_v4l2_event32(&karg.v2ev, up);
break;
+ case VIDIOC_SUBDEV_G_EDID:
+ case VIDIOC_SUBDEV_S_EDID:
+ err = put_v4l2_subdev_edid32(&karg.v2edid, up);
+ break;
+
case VIDIOC_G_FMT:
case VIDIOC_S_FMT:
case VIDIOC_TRY_FMT:
@@ -1026,6 +1081,8 @@ long v4l2_compat_ioctl32(struct file *file, unsigned int
cmd, unsigned long arg)
case VIDIOC_QUERY_DV_TIMINGS:
case VIDIOC_DV_TIMINGS_CAP:
case VIDIOC_ENUM_FREQ_BANDS:
+ case VIDIOC_SUBDEV_G_EDID32:
+ case VIDIOC_SUBDEV_S_EDID32:
ret = do
[RFCv3 PATCH 4/8] v4l2-ctrls.c: add support for the new DV controls.
Signed-off-by: Hans Verkuil
---
drivers/media/video/v4l2-ctrls.c | 39 ++
1 file changed, 39 insertions(+)
diff --git a/drivers/media/video/v4l2-ctrls.c b/drivers/media/video/v4l2-ctrls.c
index b6a2ee7..6a34c30 100644
--- a/drivers/media/video/v4l2-ctrls.c
+++ b/drivers/media/video/v4l2-ctrls.c
@@ -425,6 +425,18 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
"Gray",
NULL,
};
+ static const char * const dv_tx_mode[] = {
+ "DVI-D",
+ "HDMI",
+ NULL,
+ };
+ static const char * const dv_rgb_range[] = {
+ "Automatic",
+ "RGB limited range (16-235)",
+ "RGB full range (0-255)",
+ NULL,
+ };
+
switch (id) {
case V4L2_CID_MPEG_AUDIO_SAMPLING_FREQ:
@@ -502,6 +514,11 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
return mpeg4_profile;
case V4L2_CID_JPEG_CHROMA_SUBSAMPLING:
return jpeg_chroma_subsampling;
+ case V4L2_CID_DV_TX_MODE:
+ return dv_tx_mode;
+ case V4L2_CID_DV_TX_RGB_RANGE:
+ case V4L2_CID_DV_RX_RGB_RANGE:
+ return dv_rgb_range;
default:
return NULL;
@@ -733,6 +750,16 @@ const char *v4l2_ctrl_get_name(u32 id)
case V4L2_CID_LINK_FREQ:return "Link Frequency";
case V4L2_CID_PIXEL_RATE: return "Pixel Rate";
+ /* DV controls */
+ case V4L2_CID_DV_CLASS: return "Digital Video Controls";
+ case V4L2_CID_DV_TX_HOTPLUG:return "Hotplug Present";
+ case V4L2_CID_DV_TX_RXSENSE:return "RxSense Present";
+ case V4L2_CID_DV_TX_EDID_PRESENT: return "EDID Present";
+ case V4L2_CID_DV_TX_MODE: return "Transmit Mode";
+ case V4L2_CID_DV_TX_RGB_RANGE: return "Tx RGB Quantization
Range";
+ case V4L2_CID_DV_RX_POWER_PRESENT: return "Power Present";
+ case V4L2_CID_DV_RX_RGB_RANGE: return "Rx RGB Quantization
Range";
+
default:
return NULL;
}
@@ -832,6 +859,9 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum
v4l2_ctrl_type *type,
case V4L2_CID_ISO_SENSITIVITY_AUTO:
case V4L2_CID_EXPOSURE_METERING:
case V4L2_CID_SCENE_MODE:
+ case V4L2_CID_DV_TX_MODE:
+ case V4L2_CID_DV_TX_RGB_RANGE:
+ case V4L2_CID_DV_RX_RGB_RANGE:
*type = V4L2_CTRL_TYPE_MENU;
break;
case V4L2_CID_LINK_FREQ:
@@ -853,6 +883,7 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum
v4l2_ctrl_type *type,
case V4L2_CID_JPEG_CLASS:
case V4L2_CID_IMAGE_SOURCE_CLASS:
case V4L2_CID_IMAGE_PROC_CLASS:
+ case V4L2_CID_DV_CLASS:
*type = V4L2_CTRL_TYPE_CTRL_CLASS;
/* You can neither read not write these */
*flags |= V4L2_CTRL_FLAG_READ_ONLY | V4L2_CTRL_FLAG_WRITE_ONLY;
@@ -869,6 +900,10 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum
v4l2_ctrl_type *type,
case V4L2_CID_JPEG_ACTIVE_MARKER:
case V4L2_CID_3A_LOCK:
case V4L2_CID_AUTO_FOCUS_STATUS:
+ case V4L2_CID_DV_TX_HOTPLUG:
+ case V4L2_CID_DV_TX_RXSENSE:
+ case V4L2_CID_DV_TX_EDID_PRESENT:
+ case V4L2_CID_DV_RX_POWER_PRESENT:
*type = V4L2_CTRL_TYPE_BITMASK;
break;
case V4L2_CID_MIN_BUFFERS_FOR_CAPTURE:
@@ -933,6 +968,10 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum
v4l2_ctrl_type *type,
case V4L2_CID_FLASH_STROBE_STATUS:
case V4L2_CID_AUTO_FOCUS_STATUS:
case V4L2_CID_FLASH_READY:
+ case V4L2_CID_DV_TX_HOTPLUG:
+ case V4L2_CID_DV_TX_RXSENSE:
+ case V4L2_CID_DV_TX_EDID_PRESENT:
+ case V4L2_CID_DV_RX_POWER_PRESENT:
*flags |= V4L2_CTRL_FLAG_READ_ONLY;
break;
}
--
1.7.10.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFCv3 PATCH 0/8] V4L2: add missing pieces to support HDMI et al and add adv7604/ad9389b drivers
Hi all, This is the third version of this patch series. The second version can be found here: http://www.spinics.net/lists/linux-media/msg50413.html I made a pull request based on that and got some feedback: http://patchwork.linuxtv.org/patch/13442/ The feedback has been incorporated in this third version. One suggestion I got was to run this by the video devs as well so that they can take a look at the V4L2 EDID API, just in case I missed something, so that's why this is being cross-posted to the dri-devel mailinglist. Note that the EDID API at the moment is only meant to pass the EDID to userspace and vice versa. There is no parsing at the moment. If we ever need parsing in V4L2 (and I'm sure we will) then we will of course use shared EDID parsing code. The second patch documents the new V4L2 API additions. So that's a good one to review when it comes to the API. Regards, Hans ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFCv3 PATCH 5/8] v4l2-common: add v4l_match_dv_timings.
Add the v4l_match_dv_timings function that can be used to compare two
v4l2_dv_timings structs.
Signed-off-by: Hans Verkuil
---
drivers/media/video/v4l2-common.c | 33 +
include/media/v4l2-common.h |4
2 files changed, 37 insertions(+)
diff --git a/drivers/media/video/v4l2-common.c
b/drivers/media/video/v4l2-common.c
index 1baec83..38da47c 100644
--- a/drivers/media/video/v4l2-common.c
+++ b/drivers/media/video/v4l2-common.c
@@ -597,6 +597,39 @@ int v4l_fill_dv_preset_info(u32 preset, struct
v4l2_dv_enum_preset *info)
}
EXPORT_SYMBOL_GPL(v4l_fill_dv_preset_info);
+/**
+ * v4l_match_dv_timings - check if two timings match
+ * @t1 - compare this v4l2_dv_timings struct...
+ * @t2 - with this struct.
+ * @pclock_delta - the allowed pixelclock deviation.
+ *
+ * Compare t1 with t2 with a given margin of error for the pixelclock.
+ */
+bool v4l_match_dv_timings(const struct v4l2_dv_timings *t1,
+ const struct v4l2_dv_timings *t2,
+ unsigned pclock_delta)
+{
+ if (t1->type != t2->type || t1->type != V4L2_DV_BT_656_1120)
+ return false;
+ if (t1->bt.width == t2->bt.width &&
+ t1->bt.height == t2->bt.height &&
+ t1->bt.interlaced == t2->bt.interlaced &&
+ t1->bt.polarities == t2->bt.polarities &&
+ t1->bt.pixelclock >= t2->bt.pixelclock - pclock_delta &&
+ t1->bt.pixelclock <= t2->bt.pixelclock + pclock_delta &&
+ t1->bt.hfrontporch == t2->bt.hfrontporch &&
+ t1->bt.vfrontporch == t2->bt.vfrontporch &&
+ t1->bt.vsync == t2->bt.vsync &&
+ t1->bt.vbackporch == t2->bt.vbackporch &&
+ (!t1->bt.interlaced ||
+ (t1->bt.il_vfrontporch == t2->bt.il_vfrontporch &&
+t1->bt.il_vsync == t2->bt.il_vsync &&
+t1->bt.il_vbackporch == t2->bt.il_vbackporch)))
+ return true;
+ return false;
+}
+EXPORT_SYMBOL_GPL(v4l_match_dv_timings);
+
const struct v4l2_frmsize_discrete *v4l2_find_nearest_format(
const struct v4l2_discrete_probe *probe,
s32 width, s32 height)
diff --git a/include/media/v4l2-common.h b/include/media/v4l2-common.h
index a298ec4..b43b968 100644
--- a/include/media/v4l2-common.h
+++ b/include/media/v4l2-common.h
@@ -212,4 +212,8 @@ const struct v4l2_frmsize_discrete
*v4l2_find_nearest_format(
const struct v4l2_discrete_probe *probe,
s32 width, s32 height);
+bool v4l_match_dv_timings(const struct v4l2_dv_timings *t1,
+ const struct v4l2_dv_timings *t2,
+ unsigned pclock_delta);
+
#endif /* V4L2_COMMON_H_ */
--
1.7.10.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFCv3 PATCH 6/8] v4l2-common: add CVT and GTF detection functions.
These two helper functions detect whether the analog video timings detected
by the video receiver match the VESA CVT or GTF standards.
They basically do the inverse of the CVT and GTF modeline calculations.
This patch also adds a helper function that will determine the aspect ratio
based on the provided EDID values. This aspect ratio can be given to the GTF
helper function.
Signed-off-by: Hans Verkuil
---
drivers/media/video/v4l2-common.c | 325 +
include/media/v4l2-common.h |9 +
2 files changed, 334 insertions(+)
diff --git a/drivers/media/video/v4l2-common.c
b/drivers/media/video/v4l2-common.c
index 38da47c..33e57d8 100644
--- a/drivers/media/video/v4l2-common.c
+++ b/drivers/media/video/v4l2-common.c
@@ -630,6 +630,331 @@ bool v4l_match_dv_timings(const struct v4l2_dv_timings
*t1,
}
EXPORT_SYMBOL_GPL(v4l_match_dv_timings);
+/*
+ * CVT defines
+ * Based on Coordinated Video Timings Standard
+ * version 1.1 September 10, 2003
+ */
+
+#define CVT_PXL_CLK_GRAN 25 /* pixel clock granularity */
+
+/* Normal blanking */
+#define CVT_MIN_V_BPORCH 7 /* lines */
+#define CVT_MIN_V_PORCH_RND3 /* lines */
+#define CVT_MIN_VSYNC_BP 550 /* min time of vsync + back porch (us)
*/
+
+/* Normal blanking for CVT uses GTF to calculate horizontal blanking */
+#define CVT_CELL_GRAN 8 /* character cell granularity */
+#define CVT_M 600 /* blanking formula gradient */
+#define CVT_C 40 /* blanking formula offset */
+#define CVT_K 128 /* blanking formula scaling factor */
+#define CVT_J 20 /* blanking formula scaling factor */
+#define CVT_C_PRIME (((CVT_C - CVT_J) * CVT_K / 256) + CVT_J)
+#define CVT_M_PRIME (CVT_K * CVT_M / 256)
+
+/* Reduced Blanking */
+#define CVT_RB_MIN_V_BPORCH7 /* lines */
+#define CVT_RB_V_FPORCH3 /* lines */
+#define CVT_RB_MIN_V_BLANK 460 /* us */
+#define CVT_RB_H_SYNC 32 /* pixels */
+#define CVT_RB_H_BPORCH 80 /* pixels */
+#define CVT_RB_H_BLANK 160 /* pixels */
+
+/** v4l2_detect_cvt - detect if the given timings follow the CVT standard
+ * @frame_height - the total height of the frame (including blanking) in lines.
+ * @hfreq - the horizontal frequency in Hz.
+ * @vsync - the height of the vertical sync in lines.
+ * @polarities - the horizontal and vertical polarities (same as struct
+ * v4l2_bt_timings polarities).
+ * @fmt - the resulting timings.
+ *
+ * This function will attempt to detect if the given values correspond to a
+ * valid CVT format. If so, then it will return true, and fmt will be filled
+ * in with the found CVT timings.
+ */
+bool v4l2_detect_cvt(unsigned frame_height, unsigned hfreq, unsigned vsync,
+ u32 polarities, struct v4l2_dv_timings *fmt)
+{
+ int v_fp, v_bp, h_fp, h_bp, hsync;
+ int frame_width, image_height, image_width;
+ bool reduced_blanking;
+ unsigned pix_clk;
+
+ if (vsync < 4 || vsync > 7)
+ return false;
+
+ if (polarities == V4L2_DV_VSYNC_POS_POL)
+ reduced_blanking = false;
+ else if (polarities == V4L2_DV_HSYNC_POS_POL)
+ reduced_blanking = true;
+ else
+ return false;
+
+ /* Vertical */
+ if (reduced_blanking) {
+ v_fp = CVT_RB_V_FPORCH;
+ v_bp = (CVT_RB_MIN_V_BLANK * hfreq + 99) / 100;
+ v_bp -= vsync + v_fp;
+
+ if (v_bp < CVT_RB_MIN_V_BPORCH)
+ v_bp = CVT_RB_MIN_V_BPORCH;
+ } else {
+ v_fp = CVT_MIN_V_PORCH_RND;
+ v_bp = (CVT_MIN_VSYNC_BP * hfreq + 99) / 100 - vsync;
+
+ if (v_bp < CVT_MIN_V_BPORCH)
+ v_bp = CVT_MIN_V_BPORCH;
+ }
+ image_height = (frame_height - v_fp - vsync - v_bp + 1) & ~0x1;
+
+ /* Aspect ratio based on vsync */
+ switch (vsync) {
+ case 4:
+ image_width = (image_height * 4) / 3;
+ break;
+ case 5:
+ image_width = (image_height * 16) / 9;
+ break;
+ case 6:
+ image_width = (image_height * 16) / 10;
+ break;
+ case 7:
+ /* special case */
+ if (image_height == 1024)
+ image_width = (image_height * 5) / 4;
+ else if (image_height == 768)
+ image_width = (image_height * 15) / 9;
+ else
+ return false;
+ break;
+ default:
+ return false;
+ }
+
+ image_width = image_width & ~7;
+
+ /* Horizontal */
+ if (reduced_blanking) {
+ pix_clk = (image_width + CVT_RB_H_BLANK) * hfreq;
+ pix_clk = (pix_clk / CVT_PXL_CLK_GRAN) * CVT_PXL_
[RFCv3 PATCH 8/8] ad9389b: driver for the Analog Devices AD9389B video encoder.
Initial version of this driver.
The full datasheets are available from the Analog Devices website:
http://ez.analog.com/docs/DOC-1741
Not all features of the receiver are supported by this driver for various
reasons. Most notably:
- No CEC support (the CEC API needs a lot more discussion)
- No HDCP repeater support (we don't use that either)
I'm sure that there are more things missing, but this driver does work
well for our hardware.
Note that I am using the register addresses instead of register names: the
datasheet containing the register descriptions is organized by register
address. Using names would make the datasheet lookup very hard. An attempt
was made to try and document what is being done when registers are used
instead.
Signed-off-by: Hans Verkuil
---
drivers/media/video/Kconfig | 11 +
drivers/media/video/Makefile|1 +
drivers/media/video/ad9389b.c | 1328 +++
include/media/ad9389b.h | 49 ++
include/media/v4l2-chip-ident.h |3 +
5 files changed, 1392 insertions(+)
create mode 100644 drivers/media/video/ad9389b.c
create mode 100644 include/media/ad9389b.h
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index 6d92d2d..f2b623d 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -483,6 +483,17 @@ config VIDEO_ADV7393
To compile this driver as a module, choose M here: the
module will be called adv7393.
+config VIDEO_AD9389B
+ tristate "Analog Devices AD9389B encoder"
+ depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API
+ ---help---
+ Support for the Analog Devices AD9389B video encoder.
+
+ This is a Analog Devices HDMI transmitter.
+
+ To compile this driver as a module, choose M here: the
+ module will be called ad9389b.
+
config VIDEO_AK881X
tristate "AK8813/AK8814 video encoders"
depends on I2C
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index 133dd9b..7cb5cef 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -47,6 +47,7 @@ obj-$(CONFIG_VIDEO_ADV7183) += adv7183.o
obj-$(CONFIG_VIDEO_ADV7343) += adv7343.o
obj-$(CONFIG_VIDEO_ADV7393) += adv7393.o
obj-$(CONFIG_VIDEO_ADV7604) += adv7604.o
+obj-$(CONFIG_VIDEO_AD9389B) += ad9389b.o
obj-$(CONFIG_VIDEO_VPX3220) += vpx3220.o
obj-$(CONFIG_VIDEO_VS6624) += vs6624.o
obj-$(CONFIG_VIDEO_BT819) += bt819.o
diff --git a/drivers/media/video/ad9389b.c b/drivers/media/video/ad9389b.c
new file mode 100644
index 000..c2886b6
--- /dev/null
+++ b/drivers/media/video/ad9389b.c
@@ -0,0 +1,1328 @@
+/*
+ * Analog Devices AD9389B/AD9889B video encoder driver
+ *
+ * Copyright 2012 Cisco Systems, Inc. and/or its affiliates. All rights
reserved.
+ *
+ * This program is free software; you may redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
+ * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
+ * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+ * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+ * SOFTWARE.
+ */
+
+/*
+ * References (c = chapter, p = page):
+ * REF_01 - Analog Devices, Programming Guide, AD9889B/AD9389B,
+ * HDMI Transitter, Rev. A, October 2010
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+static int debug;
+module_param(debug, int, 0644);
+MODULE_PARM_DESC(debug, "debug level (0-2)");
+
+MODULE_DESCRIPTION("Analog Devices AD9389B/AD9889B video encoder driver");
+MODULE_AUTHOR("Hans Verkuil ");
+MODULE_AUTHOR("Martin Bugge ");
+MODULE_LICENSE("GPL");
+
+#define MASK_AD9389B_EDID_RDY_INT 0x04
+#define MASK_AD9389B_MSEN_INT 0x40
+#define MASK_AD9389B_HPD_INT0x80
+
+#define MASK_AD9389B_HPD_DETECT 0x40
+#define MASK_AD9389B_MSEN_DETECT0x20
+#define MASK_AD9389B_EDID_RDY 0x10
+
+#define EDID_MAX_RETRIES (8)
+#define EDID_DELAY 250
+#define EDID_MAX_SEGM 8
+
+/*
+**
+*
+* Arrays with configuration parameters for the AD9389B
+*
+**
+*/
+
+struct i2c_reg_value {
+ u8 reg;
+ u8 value;
+};
+
+struct ad9389b_state_edid {
+ /* total number of blocks */
+ u32 blocks;
+ /* Number of segments read */
+ u32 segments;
+ u8 data[EDID_MAX_SEGM * 256];
+ /* Number of EDID read retries left */
+ unsigned read_retries;
+};
+
+struct ad938
[Bug 41265] Radeon KMS does not work on thunderbolt media dock
https://bugs.freedesktop.org/show_bug.cgi?id=41265
--- Comment #26 from Alex Deucher 2012-08-10 13:50:54 UTC ---
(In reply to comment #25)
> i don't know why, but it don't get the VFCT Table.
> this returns false:
> (!ACPI_SUCCESS(acpi_get_table("VFCT", 1, &hdr)))
Then your system doesn't have the table.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- 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] drm/usb: select USB_SUPPORT in Kconfig
On Fri, Aug 10, 2012 at 11:00:25AM +0530, Sachin Kamat wrote: > DRM_USB selects USB. However, USB depends on USB_SUPPORT and USB_ARCH_HAS_HCD. > Thus, selecting USB_SUPPORT in Kconfig avoids the following warning > (detected when DisplayLink was selected using exynos4_defconfig): > > warning: (MOUSE_APPLETOUCH && MOUSE_BCM5974 && MOUSE_SYNAPTICS_USB && > JOYSTICK_XPAD && TABLET_USB_ACECAD && TABLET_USB_AIPTEK && TABLET_USB_HANWANG > && TABLET_USB_KBTAB && TABLET_USB_WACOM && TOUCHSCREEN_USB_COMPOSITE && > INPUT_ATI_REMOTE2 && INPUT_KEYSPAN_REMOTE && INPUT_POWERMATE && INPUT_YEALINK > && INPUT_CM109 && RC_ATI_REMOTE && IR_IMON && IR_MCEUSB && IR_REDRAT3 && > IR_STREAMZAP && IR_IGUANA && DRM_USB) selects USB which has unmet direct > dependencies (USB_SUPPORT && USB_ARCH_HAS_HCD) > > Signed-off-by: Sachin Kamat > --- > drivers/gpu/drm/Kconfig |1 + > 1 files changed, 1 insertions(+), 0 deletions(-) > > diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig > index 23120c0..45536db 100644 > --- a/drivers/gpu/drm/Kconfig > +++ b/drivers/gpu/drm/Kconfig > @@ -23,6 +23,7 @@ config DRM_USB > tristate > depends on DRM > select USB > + select USB_SUPPORT User visible options shouldn't be selected. So instead of selecting all dependencies this should rather be: depends on USB Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/4] dma-buf: remove fallback for !CONFIG_DMA_SHARED_BUFFER
Documentation says that code requiring dma-buf should add it to
select, so inline fallbacks are not going to be used. A link error
will make it obvious what went wrong, instead of silently doing
nothing at runtime.
Signed-off-by: Maarten Lankhorst
---
include/linux/dma-buf.h | 99 ---
1 file changed, 99 deletions(-)
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index eb48f38..bd2e52c 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -156,7 +156,6 @@ static inline void get_dma_buf(struct dma_buf *dmabuf)
get_file(dmabuf->file);
}
-#ifdef CONFIG_DMA_SHARED_BUFFER
struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf,
struct device *dev);
void dma_buf_detach(struct dma_buf *dmabuf,
@@ -184,103 +183,5 @@ int dma_buf_mmap(struct dma_buf *, struct vm_area_struct
*,
unsigned long);
void *dma_buf_vmap(struct dma_buf *);
void dma_buf_vunmap(struct dma_buf *, void *vaddr);
-#else
-
-static inline struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf,
- struct device *dev)
-{
- return ERR_PTR(-ENODEV);
-}
-
-static inline void dma_buf_detach(struct dma_buf *dmabuf,
- struct dma_buf_attachment *dmabuf_attach)
-{
- return;
-}
-
-static inline struct dma_buf *dma_buf_export(void *priv,
-const struct dma_buf_ops *ops,
-size_t size, int flags)
-{
- return ERR_PTR(-ENODEV);
-}
-
-static inline int dma_buf_fd(struct dma_buf *dmabuf, int flags)
-{
- return -ENODEV;
-}
-
-static inline struct dma_buf *dma_buf_get(int fd)
-{
- return ERR_PTR(-ENODEV);
-}
-
-static inline void dma_buf_put(struct dma_buf *dmabuf)
-{
- return;
-}
-
-static inline struct sg_table *dma_buf_map_attachment(
- struct dma_buf_attachment *attach, enum dma_data_direction write)
-{
- return ERR_PTR(-ENODEV);
-}
-
-static inline void dma_buf_unmap_attachment(struct dma_buf_attachment *attach,
- struct sg_table *sg, enum dma_data_direction dir)
-{
- return;
-}
-
-static inline int dma_buf_begin_cpu_access(struct dma_buf *dmabuf,
- size_t start, size_t len,
- enum dma_data_direction dir)
-{
- return -ENODEV;
-}
-
-static inline void dma_buf_end_cpu_access(struct dma_buf *dmabuf,
- size_t start, size_t len,
- enum dma_data_direction dir)
-{
-}
-
-static inline void *dma_buf_kmap_atomic(struct dma_buf *dmabuf,
- unsigned long pnum)
-{
- return NULL;
-}
-
-static inline void dma_buf_kunmap_atomic(struct dma_buf *dmabuf,
-unsigned long pnum, void *vaddr)
-{
-}
-
-static inline void *dma_buf_kmap(struct dma_buf *dmabuf, unsigned long pnum)
-{
- return NULL;
-}
-
-static inline void dma_buf_kunmap(struct dma_buf *dmabuf,
- unsigned long pnum, void *vaddr)
-{
-}
-
-static inline int dma_buf_mmap(struct dma_buf *dmabuf,
- struct vm_area_struct *vma,
- unsigned long pgoff)
-{
- return -ENODEV;
-}
-
-static inline void *dma_buf_vmap(struct dma_buf *dmabuf)
-{
- return NULL;
-}
-
-static inline void dma_buf_vunmap(struct dma_buf *dmabuf, void *vaddr)
-{
-}
-#endif /* CONFIG_DMA_SHARED_BUFFER */
#endif /* __DMA_BUF_H__ */
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/4] dma-fence: dma-buf synchronization (v8 )
A dma-fence can be attached to a buffer which is being filled or consumed
by hw, to allow userspace to pass the buffer without waiting to another
device. For example, userspace can call page_flip ioctl to display the
next frame of graphics after kicking the GPU but while the GPU is still
rendering. The display device sharing the buffer with the GPU would
attach a callback to get notified when the GPU's rendering-complete IRQ
fires, to update the scan-out address of the display, without having to
wake up userspace.
A dma-fence is transient, one-shot deal. It is allocated and attached
to one or more dma-buf's. When the one that attached it is done, with
the pending operation, it can signal the fence.
+ dma_fence_signal()
The dma-buf-mgr handles tracking, and waiting on, the fences associated
with a dma-buf.
TODO maybe need some helper fxn for simple devices, like a display-
only drm/kms device which simply wants to wait for exclusive fence to
be signaled, and then attach a non-exclusive fence while scanout is in
progress.
The one pending on the fence can add an async callback:
+ dma_fence_add_callback()
The callback can optionally be cancelled with remove_wait_queue()
Or wait synchronously (optionally with timeout or interruptible):
+ dma_fence_wait()
A default software-only implementation is provided, which can be used
by drivers attaching a fence to a buffer when they have no other means
for hw sync. But a memory backed fence is also envisioned, because it
is common that GPU's can write to, or poll on some memory location for
synchronization. For example:
fence = dma_buf_get_fence(dmabuf);
if (fence->ops == &bikeshed_fence_ops) {
dma_buf *fence_buf;
dma_bikeshed_fence_get_buf(fence, &fence_buf, &offset);
... tell the hw the memory location to wait on ...
} else {
/* fall-back to sw sync * /
dma_fence_add_callback(fence, my_cb);
}
On SoC platforms, if some other hw mechanism is provided for synchronizing
between IP blocks, it could be supported as an alternate implementation
with it's own fence ops in a similar way.
To facilitate other non-sw implementations, the enable_signaling callback
can be used to keep track if a device not supporting hw sync is waiting
on the fence, and in this case should arrange to call dma_fence_signal()
at some point after the condition has changed, to notify other devices
waiting on the fence. If there are no sw waiters, this can be skipped to
avoid waking the CPU unnecessarily. The handler of the enable_signaling
op should take a refcount until the fence is signaled, then release its ref.
The intention is to provide a userspace interface (presumably via eventfd)
later, to be used in conjunction with dma-buf's mmap support for sw access
to buffers (or for userspace apps that would prefer to do their own
synchronization).
v1: Original
v2: After discussion w/ danvet and mlankhorst on #dri-devel, we decided
that dma-fence didn't need to care about the sw->hw signaling path
(it can be handled same as sw->sw case), and therefore the fence->ops
can be simplified and more handled in the core. So remove the signal,
add_callback, cancel_callback, and wait ops, and replace with a simple
enable_signaling() op which can be used to inform a fence supporting
hw->hw signaling that one or more devices which do not support hw
signaling are waiting (and therefore it should enable an irq or do
whatever is necessary in order that the CPU is notified when the
fence is passed).
v3: Fix locking fail in attach_fence() and get_fence()
v4: Remove tie-in w/ dma-buf.. after discussion w/ danvet and mlankorst
we decided that we need to be able to attach one fence to N dma-buf's,
so using the list_head in dma-fence struct would be problematic.
v5: [ Maarten Lankhorst ] Updated for dma-bikeshed-fence and dma-buf-manager.
v6: [ Maarten Lankhorst ] I removed dma_fence_cancel_callback and some comments
about checking if fence fired or not. This is broken by design.
waitqueue_active during destruction is now fatal, since the signaller
should be holding a reference in enable_signalling until it signalled
the fence. Pass the original dma_fence_cb along, and call __remove_wait
in the dma_fence_callback handler, so that no cleanup needs to be
performed.
v7: [ Maarten Lankhorst ] Set cb->func and only enable sw signaling if
fence wasn't signaled yet, for example for hardware fences that may
choose to signal blindly.
v8: [ Maarten Lankhorst ] Tons of tiny fixes, moved __dma_fence_init to
header and fixed include mess. dma-fence.h now includes dma-buf.h
All members are now initialized, so kmalloc can be used for
allocating a dma-fence. More documentation added.
Signed-off-by: Maarten Lankhorst
---
Documentation/DocBook/device-drivers.tmpl |2
drivers/base/Makefile |2
drivers/base/dma-fence.c | 268 +
[PATCH 3/4] dma-seqno-fence: Hardware dma-buf implementation of fencing (v2)
This type of fence can be used with hardware synchronization for simple
hardware that can block execution until the condition
(dma_buf[offset] - value) >= 0 has been met.
A software fallback still has to be provided in case the fence is used
with a device that doesn't support this mechanism. It is useful to expose
this for graphics cards that have an op to support this.
Some cards like i915 can export those, but don't have an option to wait,
so they need the software fallback.
I extended the original patch by Rob Clark.
v1: Original
v2: Renamed from bikeshed to seqno, moved into dma-fence.c since
not much was left of the file. Lots of documentation added.
Signed-off-by: Maarten Lankhorst
---
drivers/base/dma-fence.c | 21 +++
include/linux/dma-fence.h | 61 +
2 files changed, 82 insertions(+)
diff --git a/drivers/base/dma-fence.c b/drivers/base/dma-fence.c
index 93448e4..4092a58 100644
--- a/drivers/base/dma-fence.c
+++ b/drivers/base/dma-fence.c
@@ -266,3 +266,24 @@ struct dma_fence *dma_fence_create(void *priv)
return fence;
}
EXPORT_SYMBOL_GPL(dma_fence_create);
+
+static int seqno_enable_signaling(struct dma_fence *fence)
+{
+ struct dma_seqno_fence *seqno_fence = to_seqno_fence(fence);
+ return seqno_fence->enable_signaling(seqno_fence);
+}
+
+static void seqno_release(struct dma_fence *fence)
+{
+ struct dma_seqno_fence *f = to_seqno_fence(fence);
+
+ if (f->release)
+ f->release(f);
+ dma_buf_put(f->sync_buf);
+}
+
+const struct dma_fence_ops dma_seqno_fence_ops = {
+ .enable_signaling = seqno_enable_signaling,
+ .release = seqno_release
+};
+EXPORT_SYMBOL_GPL(dma_seqno_fence_ops);
diff --git a/include/linux/dma-fence.h b/include/linux/dma-fence.h
index e0ceddd..3ef0da0 100644
--- a/include/linux/dma-fence.h
+++ b/include/linux/dma-fence.h
@@ -91,6 +91,19 @@ struct dma_fence_ops {
void (*release)(struct dma_fence *fence);
};
+struct dma_seqno_fence {
+ struct dma_fence base;
+
+ struct dma_buf *sync_buf;
+ uint32_t seqno_ofs;
+ uint32_t seqno;
+
+ int (*enable_signaling)(struct dma_seqno_fence *fence);
+ void (*release)(struct dma_seqno_fence *fence);
+};
+
+extern const struct dma_fence_ops dma_seqno_fence_ops;
+
struct dma_fence *dma_fence_create(void *priv);
/**
@@ -121,4 +134,52 @@ int dma_fence_wait(struct dma_fence *fence, bool intr,
unsigned long timeout);
int dma_fence_add_callback(struct dma_fence *fence, struct dma_fence_cb *cb,
dma_fence_func_t func, void *priv);
+/**
+ * to_seqno_fence - cast a dma_fence to a dma_seqno_fence
+ * @fence: dma_fence to cast to a dma_seqno_fence
+ *
+ * Returns NULL if the dma_fence is not a dma_seqno_fence,
+ * or the dma_seqno_fence otherwise.
+ */
+static inline struct dma_seqno_fence *
+to_seqno_fence(struct dma_fence *fence)
+{
+ if (fence->ops != &dma_seqno_fence_ops)
+ return NULL;
+ return container_of(fence, struct dma_seqno_fence, base);
+}
+
+/**
+ * dma_seqno_fence_init - initialize a seqno fence
+ * @fence: dma_seqno_fence to initialize
+ * @sync_buf: buffer containing the memory location to signal on
+ * @seqno_ofs: the offset within @sync_buf
+ * @seqno: the sequence # to signal on
+ * @priv: value of priv member
+ * @enable_signaling: callback which is called when some other device is
+ *waiting for sw notification of fence
+ * @release: callback called during destruction before object is freed.
+ *
+ * This function initializes a struct dma_seqno_fence with passed parameters,
+ * and takes a reference on sync_buf which is released on fence destruction.
+ */
+static inline void
+dma_seqno_fence_init(struct dma_seqno_fence *fence,
+ struct dma_buf *sync_buf,
+ uint32_t seqno_ofs, uint32_t seqno, void *priv,
+ int (*enable_signaling)(struct dma_seqno_fence *),
+ void (*release)(struct dma_seqno_fence *))
+{
+ BUG_ON(!fence || !sync_buf || !enable_signaling);
+
+ __dma_fence_init(&fence->base, &dma_seqno_fence_ops, priv);
+
+ get_dma_buf(sync_buf);
+ fence->sync_buf = sync_buf;
+ fence->seqno_ofs = seqno_ofs;
+ fence->seqno = seqno;
+ fence->enable_signaling = enable_signaling;
+ fence->release = release;
+}
+
#endif /* __DMA_FENCE_H__ */
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/4] dma-buf-mgr: multiple dma-buf synchronization (v3)
Signed-off-by: Maarten Lankhorst dma-buf-mgr handles the case of reserving single or multiple dma-bufs while trying to prevent deadlocks from buffers being reserved simultaneously. For this to happen extra functions have been introduced: + dma_buf_reserve() + dma_buf_unreserve() + dma_buf_wait_unreserved() Reserve a single buffer, optionally with a sequence to indicate this is part of a multi-dmabuf reservation. This function will return -EDEADLK and return immediately if reserving would cause a deadlock. In case a single buffer is being reserved, no sequence is needed, otherwise please use the dmabufmgr calls. If you want to attach a exclusive dma-fence, you have to wait until all shared fences have signalled completion. If there are none, or if a shared fence has to be attached, wait until last exclusive fence has signalled completion. The new fence has to be attached before unreserving the buffer, and in exclusive mode all previous fences will have be removed from the buffer, and unreffed when done with it. dmabufmgr methods: + dmabufmgr_validate_init() This function inits a dmabufmgr_validate structure and appends it to the tail of the list, with refcount set to 1. + dmabufmgr_validate_put() Convenience function to unref and free a dmabufmgr_validate structure. However if it's used for custom callback signalling, a custom function should be implemented. + dmabufmgr_reserve_buffers() This function takes a linked list of dmabufmgr_validate's, each one requires the following members to be set by the caller: - validate->head, list head - validate->bo, must be set to the dma-buf to reserve. - validate->shared, set to true if opened in shared mode. - validate->priv, can be used by the caller to identify this buffer. This function will then set the following members on succesful completion: - validate->num_fences, amount of valid fences to wait on before this buffer can be accessed. This can be 0. - validate->fences[0...num_fences-1] fences to wait on + dmabufmgr_backoff_reservation() This can be used when the caller encounters an error between reservation and usage. No new fence will be attached and all reservations will be undone without side effects. + dmabufmgr_fence_buffer_objects Upon successful completion a new fence will have to be attached. This function releases old fences and attaches the new one. + dmabufmgr_wait_completed_cpu A simple cpu waiter convenience function. Waits until all fences have signalled completion before returning. The rationale of refcounting dmabufmgr_validate lies in the wait dma_fence_cb wait member. Before calling dma_fence_add_callback you should increase the refcount on dmabufmgr_validate with dmabufmgr_validate_get, and on signal completion you should call kref_put(&val->refcount, custom_free_signal); after all callbacks have added you drop the refcount by 1 also, when refcount drops to 0 all callbacks have been signalled, and dmabufmgr_validate has been waited on and can be freed. Since this will require atomic spinlocks to unlink the list and signal completion, a deadlock could occur if you try to call add_callback otherwise, so the refcount is used as a means of preventing this from occuring by having your custom free function take a device specific lock, removing from list and freeing the data. The nice/evil part about this is that this will also guarantee no memory leaks can occur behind your back. This allows delays completion by moving the dmabufmgr_validate list to be a part of the committed reservation. v1: Original version v2: Use dma-fence v3: Added refcounting to dmabufmgr-validate v4: Fixed dmabufmgr_wait_completed_cpu prototype, added more documentation and added Documentation/dma-buf-synchronization.txt --- Documentation/DocBook/device-drivers.tmpl |2 Documentation/dma-buf-synchronization.txt | 197 + drivers/base/Makefile |2 drivers/base/dma-buf-mgr.c| 277 + drivers/base/dma-buf.c| 114 include/linux/dma-buf-mgr.h | 121 + include/linux/dma-buf.h | 24 +++ 7 files changed, 736 insertions(+), 1 deletion(-) create mode 100644 Documentation/dma-buf-synchronization.txt create mode 100644 drivers/base/dma-buf-mgr.c create mode 100644 include/linux/dma-buf-mgr.h diff --git a/Documentation/DocBook/device-drivers.tmpl b/Documentation/DocBook/device-drivers.tmpl index 36252ac..2fc050c 100644 --- a/Documentation/DocBook/device-drivers.tmpl +++ b/Documentation/DocBook/device-drivers.tmpl @@ -128,6 +128,8 @@ X!Edrivers/base/interface.c !Edrivers/base/dma-buf.c !Edrivers/base/dma-fence.c !Iinclude/linux/dma-fence.h +!Edrivers/base/dma-buf-mgr.c +!Iinclude/linux/dma-buf-mgr.h !Edrivers/base/dma-coherent.c !Edrivers/base/dma-mapping.c diff --git a/Documentation/dma-buf-synchronization.txt b/Documentation/dma-buf-synchronization.txt new
Re: [PATCH] staging: omapdrm: Remove unnecessary memcpy
On Thu, Aug 9, 2012 at 12:13 AM, Andy Gross wrote:
> Removed the unnecessary copy of the memory page addresses when
> programming the DMM/PAT and all support code for the lut copy.
> The original intent was to have this code in place for
> suspend/resume functionality w.r.t. DEVICE_OFF.
>
> Performance analysis showed that the extra copy from uncached memory
> led to a fairly hefty penalty when programming large 1D or 2D
> buffers. This can be implemented in a more efficient manner when we
> actually have to support DEVICE_OFF suspend/resume operations.
This patch itself is ok, but I'd like to wait a bit and merge this
together w/ a 2nd patch that handles saving the PAT state in the
suspend path.
BR,
-R
> Signed-off-by: Andy Gross
> ---
> drivers/staging/omapdrm/omap_dmm_priv.h |6 --
> drivers/staging/omapdrm/omap_dmm_tiler.c | 25 +
> 2 files changed, 1 insertions(+), 30 deletions(-)
>
> diff --git a/drivers/staging/omapdrm/omap_dmm_priv.h
> b/drivers/staging/omapdrm/omap_dmm_priv.h
> index 08b22e9..09ebc50 100644
> --- a/drivers/staging/omapdrm/omap_dmm_priv.h
> +++ b/drivers/staging/omapdrm/omap_dmm_priv.h
> @@ -141,9 +141,6 @@ struct refill_engine {
> /* only one trans per engine for now */
> struct dmm_txn txn;
>
> - /* offset to lut associated with container */
> - u32 *lut_offset;
> -
> wait_queue_head_t wait_for_refill;
>
> struct list_head idle_node;
> @@ -176,9 +173,6 @@ struct dmm {
> /* array of LUT - TCM containers */
> struct tcm **tcm;
>
> - /* LUT table storage */
> - u32 *lut;
> -
> /* allocation list and lock */
> struct list_head alloc_head;
> };
> diff --git a/drivers/staging/omapdrm/omap_dmm_tiler.c
> b/drivers/staging/omapdrm/omap_dmm_tiler.c
> index ec7a5c8..80d3f8a 100644
> --- a/drivers/staging/omapdrm/omap_dmm_tiler.c
> +++ b/drivers/staging/omapdrm/omap_dmm_tiler.c
> @@ -24,7 +24,6 @@
> #include
> #include
> #include
> -#include
> #include
> #include
> #include
> @@ -184,9 +183,6 @@ static int dmm_txn_append(struct dmm_txn *txn, struct
> pat_area *area,
> int columns = (1 + area->x1 - area->x0);
> int rows = (1 + area->y1 - area->y0);
> int i = columns*rows;
> - u32 *lut = omap_dmm->lut + (engine->tcm->lut_id * omap_dmm->lut_width
> *
> - omap_dmm->lut_height) +
> - (area->y0 * omap_dmm->lut_width) + area->x0;
>
> pat = alloc_dma(txn, sizeof(struct pat), &pat_pa);
>
> @@ -209,10 +205,6 @@ static int dmm_txn_append(struct dmm_txn *txn, struct
> pat_area *area,
> page_to_phys(pages[n]) : engine->dmm->dummy_pa;
> }
>
> - /* fill in lut with new addresses */
> - for (i = 0; i < rows; i++, lut += omap_dmm->lut_width)
> - memcpy(lut, &data[i*columns], columns * sizeof(u32));
> -
> txn->last_pat = pat;
>
> return 0;
> @@ -504,8 +496,6 @@ static int omap_dmm_remove(struct platform_device *dev)
> if (omap_dmm->dummy_page)
> __free_page(omap_dmm->dummy_page);
>
> - vfree(omap_dmm->lut);
> -
> if (omap_dmm->irq > 0)
> free_irq(omap_dmm->irq, omap_dmm);
>
> @@ -521,7 +511,7 @@ static int omap_dmm_probe(struct platform_device *dev)
> {
> int ret = -EFAULT, i;
> struct tcm_area area = {0};
> - u32 hwinfo, pat_geom, lut_table_size;
> + u32 hwinfo, pat_geom;
> struct resource *mem;
>
> omap_dmm = kzalloc(sizeof(*omap_dmm), GFP_KERNEL);
> @@ -593,16 +583,6 @@ static int omap_dmm_probe(struct platform_device *dev)
> */
> writel(0x7e7e7e7e, omap_dmm->base + DMM_PAT_IRQENABLE_SET);
>
> - lut_table_size = omap_dmm->lut_width * omap_dmm->lut_height *
> - omap_dmm->num_lut;
> -
> - omap_dmm->lut = vmalloc(lut_table_size * sizeof(*omap_dmm->lut));
> - if (!omap_dmm->lut) {
> - dev_err(&dev->dev, "could not allocate lut table\n");
> - ret = -ENOMEM;
> - goto fail;
> - }
> -
> omap_dmm->dummy_page = alloc_page(GFP_KERNEL | __GFP_DMA32);
> if (!omap_dmm->dummy_page) {
> dev_err(&dev->dev, "could not allocate dummy page\n");
> @@ -685,9 +665,6 @@ static int omap_dmm_probe(struct platform_device *dev)
> .p1.y = omap_dmm->container_height - 1,
> };
>
> - for (i = 0; i < lut_table_size; i++)
> - omap_dmm->lut[i] = omap_dmm->dummy_pa;
> -
> /* initialize all LUTs to dummy page entries */
> for (i = 0; i < omap_dmm->num_lut; i++) {
> area.tcm = omap_dmm->tcm[i];
> --
> 1.7.5.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo
[Bug 53348] [855gm] GPU hang whilst playing Imperialism 2 under wine
https://bugs.freedesktop.org/show_bug.cgi?id=53348 Chris Wilson changed: What|Removed |Added AssignedTo|dan...@ffwll.ch |dri-devel@lists.freedesktop ||.org Summary|wine game: |[855gm] GPU hang whilst |intel_do_flush_locked |playing Imperialism 2 under |failed: Input/output error |wine Product|DRI |Mesa Version|unspecified |8.0 Component|DRM/Intel |Drivers/DRI/i830 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 1/2] drm/radeon/dynpm: wait for fences on all rings when reclocking
From: Alex Deucher
1. Drop gui idle stuff, it's not as reliable as fences and only
covers the 3D engine.
2. Wait for fences on all rings. This makes sure all rings are
idle when reclocking.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_pm.c | 17 ++---
1 files changed, 6 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_pm.c
b/drivers/gpu/drm/radeon/radeon_pm.c
index 7ae6066..2c2c901 100644
--- a/drivers/gpu/drm/radeon/radeon_pm.c
+++ b/drivers/gpu/drm/radeon/radeon_pm.c
@@ -253,18 +253,13 @@ static void radeon_pm_set_clocks(struct radeon_device
*rdev)
down_write(&rdev->pm.mclk_lock);
mutex_lock(&rdev->ring_lock);
- /* gui idle int has issues on older chips it seems */
- if (rdev->family >= CHIP_R600) {
- if (rdev->irq.installed) {
- /* wait for GPU to become idle */
- radeon_irq_kms_wait_gui_idle(rdev);
- }
- } else {
- struct radeon_ring *ring =
&rdev->ring[RADEON_RING_TYPE_GFX_INDEX];
- if (ring->ready) {
- radeon_fence_wait_empty_locked(rdev,
RADEON_RING_TYPE_GFX_INDEX);
- }
+ /* wait for the rings to drain */
+ for (i = 0; i < RADEON_NUM_RINGS; i++) {
+ struct radeon_ring *ring = &rdev->ring[i];
+ if (ring->ready)
+ radeon_fence_wait_empty_locked(rdev, i);
}
+
radeon_unmap_vram_bos(rdev);
if (rdev->irq.installed) {
--
1.7.7.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/radeon: remove gui_idle interrupt infrastructure
From: Alex Deucher
It was only used for dynpm, but has been replaced with
a better implementation using fences. Remove it.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/evergreen.c |5
drivers/gpu/drm/radeon/r100.c | 19 -
drivers/gpu/drm/radeon/r600.c |5
drivers/gpu/drm/radeon/radeon.h |4 ---
drivers/gpu/drm/radeon/radeon_device.c |1 -
drivers/gpu/drm/radeon/radeon_irq_kms.c | 33 ---
drivers/gpu/drm/radeon/rs600.c | 19 -
drivers/gpu/drm/radeon/si.c |5
8 files changed, 0 insertions(+), 91 deletions(-)
diff --git a/drivers/gpu/drm/radeon/evergreen.c
b/drivers/gpu/drm/radeon/evergreen.c
index e93b80a..90293c1 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -2541,10 +2541,6 @@ int evergreen_irq_set(struct radeon_device *rdev)
DRM_DEBUG("evergreen_irq_set: hdmi 5\n");
afmt6 |= AFMT_AZ_FORMAT_WTRIG_MASK;
}
- if (rdev->irq.gui_idle) {
- DRM_DEBUG("gui idle\n");
- grbm_int_cntl |= GUI_IDLE_INT_ENABLE;
- }
if (rdev->family >= CHIP_CAYMAN) {
cayman_cp_int_cntl_setup(rdev, 0, cp_int_cntl);
@@ -3079,7 +3075,6 @@ restart_ih:
break;
case 233: /* GUI IDLE */
DRM_DEBUG("IH: GUI idle\n");
- wake_up(&rdev->irq.idle_queue);
break;
default:
DRM_DEBUG("Unhandled interrupt: %d %d\n", src_id,
src_data);
diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
index 8acb34f..4774e50 100644
--- a/drivers/gpu/drm/radeon/r100.c
+++ b/drivers/gpu/drm/radeon/r100.c
@@ -698,9 +698,6 @@ int r100_irq_set(struct radeon_device *rdev)
if (atomic_read(&rdev->irq.ring_int[RADEON_RING_TYPE_GFX_INDEX])) {
tmp |= RADEON_SW_INT_ENABLE;
}
- if (rdev->irq.gui_idle) {
- tmp |= RADEON_GUI_IDLE_MASK;
- }
if (rdev->irq.crtc_vblank_int[0] ||
atomic_read(&rdev->irq.pflip[0])) {
tmp |= RADEON_CRTC_VBLANK_MASK;
@@ -737,12 +734,6 @@ static uint32_t r100_irq_ack(struct radeon_device *rdev)
RADEON_CRTC_VBLANK_STAT | RADEON_CRTC2_VBLANK_STAT |
RADEON_FP_DETECT_STAT | RADEON_FP2_DETECT_STAT;
- /* the interrupt works, but the status bit is permanently asserted */
- if (rdev->irq.gui_idle && radeon_gui_idle(rdev)) {
- if (!rdev->irq.gui_idle_acked)
- irq_mask |= RADEON_GUI_IDLE_STAT;
- }
-
if (irqs) {
WREG32(RADEON_GEN_INT_STATUS, irqs);
}
@@ -754,9 +745,6 @@ int r100_irq_process(struct radeon_device *rdev)
uint32_t status, msi_rearm;
bool queue_hotplug = false;
- /* reset gui idle ack. the status bit is broken */
- rdev->irq.gui_idle_acked = false;
-
status = r100_irq_ack(rdev);
if (!status) {
return IRQ_NONE;
@@ -769,11 +757,6 @@ int r100_irq_process(struct radeon_device *rdev)
if (status & RADEON_SW_INT_TEST) {
radeon_fence_process(rdev, RADEON_RING_TYPE_GFX_INDEX);
}
- /* gui idle interrupt */
- if (status & RADEON_GUI_IDLE_STAT) {
- rdev->irq.gui_idle_acked = true;
- wake_up(&rdev->irq.idle_queue);
- }
/* Vertical blank interrupts */
if (status & RADEON_CRTC_VBLANK_STAT) {
if (rdev->irq.crtc_vblank_int[0]) {
@@ -803,8 +786,6 @@ int r100_irq_process(struct radeon_device *rdev)
}
status = r100_irq_ack(rdev);
}
- /* reset gui idle ack. the status bit is broken */
- rdev->irq.gui_idle_acked = false;
if (queue_hotplug)
schedule_work(&rdev->hotplug_work);
if (rdev->msi_enabled) {
diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index d79c639..459c251 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -3088,10 +3088,6 @@ int r600_irq_set(struct radeon_device *rdev)
DRM_DEBUG("r600_irq_set: hdmi 0\n");
hdmi1 |= HDMI0_AZ_FORMAT_WTRIG_MASK;
}
- if (rdev->irq.gui_idle) {
- DRM_DEBUG("gui idle\n");
- grbm_int_cntl |= GUI_IDLE_INT_ENABLE;
- }
WREG32(CP_INT_CNTL, cp_int_cntl);
WREG32(DxMODE_INT_MASK, mode_int);
@@ -3475,7 +3471,6 @@ restart_ih:
break;
case 233: /* GUI IDLE */
DRM_DEBUG("IH: GUI idle\n");
- wake_up(&rdev->irq.idle_queue);
break;
default:
[Bug 41265] Radeon KMS does not work on thunderbolt media dock
https://bugs.freedesktop.org/show_bug.cgi?id=41265 --- Comment #27 from Alexander E. Patrakov 2012-08-10 17:44:00 UTC --- My Sony VAIO currently boots via MBR, in BIOS mode. There is nothing about UEFI in the BIOS setup screen. I am willing to convert the system and test the patch only if someone provides instructions how to test beforehand whether UEFI booting is supported on my system at all, without downloading files larger than 20 megabytes total. I have a 4gb USB flash drive with no important data that can be used as a test boot device. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 41265] Radeon KMS does not work on thunderbolt media dock
https://bugs.freedesktop.org/show_bug.cgi?id=41265 --- Comment #28 from Alex Deucher 2012-08-10 17:46:32 UTC --- If you are not using UEFI and the system supports legacy mode, then there's no need to try the patch. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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
[pull] radeon drm-fixes-3.6
From: Alex Deucher Hi Dave, This is the current set of radeon fixes for 3.6. Nothing too major. Highlights: - various display fixes - some SI fixes - new SI pci ids - major VM fix - CS checker support for MSAA I've tested on a number of cards across generations and noticed no problems. There is also a patch to implement vbios fetching on legacy free UEFI systems: https://bugs.freedesktop.org/show_bug.cgi?id=26891 The patch is posted there, but I'm waiting to hear back from the author. Look for that in a future pull. The following changes since commit d323748a8e6df3fb91872b73766e29da2f68b025: drm/edid: Fix potential memory leak in edid_load() (2012-08-09 10:10:37 +1000) are available in the git repository at: git://people.freedesktop.org/~agd5f/linux drm-fixes-3.6 Alex Deucher (9): drm/radeon: fix handling for ddc type 5 on combios drm/radeon/dce4+: set a more reasonable cursor watermark drm/radeon: properly handle SS overrides on TN (v2) drm/radeon: properly handle crtc powergating drm/radeon: fix bank tiling parameters on evergreen drm/radeon: fix bank tiling parameters on cayman drm/radeon: fix ordering in pll picking on dce4+ drm/radeon: add some new SI pci ids drm/radeon: fix some missing parens in asic macros Christian König (1): drm/radeon: fix bank tiling parameters on SI Jerome Glisse (2): drm/radeon: do not reenable crtc after moving vram start address drm/radeon: fence virtual address and free it once idle v4 Marek Olšák (3): drm/radeon/kms: reorder code in r600_check_texture_resource drm/radeon/kms: add MSAA texture support for r600-evergreen drm/radeon/kms: implement timestamp userspace query (v2) drivers/gpu/drm/radeon/atombios_crtc.c | 22 ++-- drivers/gpu/drm/radeon/evergreen.c | 71 -- drivers/gpu/drm/radeon/evergreen_cs.c |7 +++ drivers/gpu/drm/radeon/ni.c | 14 - drivers/gpu/drm/radeon/r600.c | 20 drivers/gpu/drm/radeon/r600_cs.c| 59 -- drivers/gpu/drm/radeon/r600d.h |3 + drivers/gpu/drm/radeon/radeon.h | 12 +++-- drivers/gpu/drm/radeon/radeon_asic.h| 10 ++-- drivers/gpu/drm/radeon/radeon_atombios.c| 49 ++- drivers/gpu/drm/radeon/radeon_combios.c | 57 ++ drivers/gpu/drm/radeon/radeon_cs.c | 32 +++- drivers/gpu/drm/radeon/radeon_cursor.c |6 ++- drivers/gpu/drm/radeon/radeon_device.c |1 + drivers/gpu/drm/radeon/radeon_drv.c |4 +- drivers/gpu/drm/radeon/radeon_gart.c| 24 - drivers/gpu/drm/radeon/radeon_gem.c | 13 + drivers/gpu/drm/radeon/radeon_kms.c | 35 +++-- drivers/gpu/drm/radeon/radeon_legacy_crtc.c |4 ++ drivers/gpu/drm/radeon/radeon_mode.h|1 + drivers/gpu/drm/radeon/radeon_object.c |6 +-- drivers/gpu/drm/radeon/rv515.c | 13 - drivers/gpu/drm/radeon/si.c | 35 -- drivers/gpu/drm/radeon/sid.h|3 + include/drm/drm_pciids.h|3 + include/drm/radeon_drm.h|2 + 26 files changed, 319 insertions(+), 187 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 53348] [855gm] GPU hang whilst playing Imperialism 2 under wine
https://bugs.freedesktop.org/show_bug.cgi?id=53348 --- Comment #1 from Bruno 2012-08-10 18:39:27 UTC --- Created attachment 65396 --> https://bugs.freedesktop.org/attachment.cgi?id=65396 i915_error_state with linux 3.5.1 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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] drm: EDID quirk improvements
OK, so using a period as the "magic" character to clear the list turns out to be a disastrously bad idea. (It works great everywhere except on the kernel command line.) New patch coming that uses at sign (@) instead. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: EDID quirk improvements
Add ability for user to add or remove EDID quirks, via module parameter or sysfs. Also add two new quirk flags -- EDID_QUIRK_DISABLE_INFOFRAMES and EDID_QUIRK_NO_AUDIO -- and adds a quirk for the LG L246WP display. Document module parameter and sysfs interface. --- Documentation/EDID/edid_quirks.txt | 161 +++ drivers/gpu/drm/drm_drv.c | 2 + drivers/gpu/drm/drm_edid.c | 527 + drivers/gpu/drm/drm_stub.c | 5 + drivers/gpu/drm/drm_sysfs.c| 19 ++ include/drm/drmP.h | 10 + include/drm/drm_edid.h | 13 +- 7 files changed, 676 insertions(+), 61 deletions(-) create mode 100644 Documentation/EDID/edid_quirks.txt diff --git a/Documentation/EDID/edid_quirks.txt b/Documentation/EDID/edid_quirks.txt new file mode 100644 index 000..256ded0 --- /dev/null +++ b/Documentation/EDID/edid_quirks.txt @@ -0,0 +1,161 @@ + EDID Quirks + = + Ian Pilcher + August 8, 2012 + + +"EDID blocks out in the wild have a variety of bugs" +-- from drivers/gpu/drm/drm_edid.c + + +Overview + + +EDID quirks provide a mechanism for working around display hardware with buggy +EDID data. + +An individual EDID quirk maps a display type (identified by its EDID +manufacturer ID and product code[1]) to a set of flags. For example, the current +list of quirks built into the kernel is: + +ACR:0xad46:0x0001 +API:0x7602:0x0001 +ACR:0x0977:0x0020 +MAX:0x05ec:0x0001 +MAX:0x077e:0x0001 +EPI:0xe780:0x0002 +EPI:0x2028:0x0001 +FCM:0x3520:0x000c +LPL:0x:0x0010 +LPL:0x2a00:0x0010 +PHL:0xe014:0x0020 +PTS:0x02fd:0x0020 +SAM:0x021d:0x0040 +SAM:0x0254:0x0001 +SAM:0x027e:0x0001 +VSC:0x139c:0x0080 +GSM:0x563f:0x0300 + +The first field of each quirk is the manufacturer ID, the second field is the +product code, and the third field is the quirk flags. + +NOTE: All of the manufacturer IDs above are displayed as 3-character strings, +because they are conformant IDs that have been properly encoded: + +- The most-significant bit of the encoded ID is 0 +- They only contain ASCII characters in the range A-Z + +IDs that do not conform to these rules are displayed as "raw" hexadecimal +values. + +The current quirk flags are: + +/* First detailed mode wrong, use largest 60Hz mode */ +#define EDID_QUIRK_PREFER_LARGE_60 0x0001 + +/* Reported 135MHz pixel clock is too high, needs adjustment */ +#define EDID_QUIRK_135_CLOCK_TOO_HIGH 0x0002 + +/* Prefer the largest mode at 75 Hz */ +#define EDID_QUIRK_PREFER_LARGE_75 0x0004 + +/* Detail timing is in cm not mm */ +#define EDID_QUIRK_DETAILED_IN_CM 0x0008 + +/* Detailed timing descriptors have bogus size values, so just take the + * maximum size and use that. + */ +#define EDID_QUIRK_DETAILED_USE_MAXIMUM_SIZE0x0010 + +/* Monitor forgot to set the first detailed is preferred bit. */ +#define EDID_QUIRK_FIRST_DETAILED_PREFERRED 0x0020 + +/* use +hsync +vsync for detailed mode */ +#define EDID_QUIRK_DETAILED_SYNC_PP 0x0040 + +/* Force reduced-blanking timings for detailed modes */ +#define EDID_QUIRK_FORCE_REDUCED_BLANKING 0x0080 + +/* Display is confused by InfoFrames; don't sent any */ +#define EDID_QUIRK_DISABLE_INFOFRAMES 0x0100 + +/* Display doesn't have any audio output */ +#define EDID_QUIRK_NO_AUDIO 0x0200 + + +sysfs interface +=== + +The current EDID quirk list can be read from /sys/class/drm/edid_quirks. + +The number of total "slots" in the list can be read from +/sys/class/drm/edid_quirks_size. This total includes both occupied slots (i.e. +the current list) and any slots available for additional quirks. The number of +available slots can be calculated by subtracting the number of quirks in the +current list from the total number of slots. + +If a slot is available, an additional quirk can be added to the list by writing +it to edid_quirks: + +# echo FOO:0x:0x100 > /sys/class/drm/edid_quirks + +Manufacturer IDs can also be specified numerically. (This is the only way to +specify a nonconformant ID.) This command is equivalent to the previous one: + +# echo 0x19ef:0x:0x100 > /sys/class/drm/edid_quirks + +Numeric values can also be specified in decimal or octal formats; a number that +begins with a 0 is assumed to be octal: + +# echo FOO:65535:0400 > /sys/class/drm/edid_quirks + +An existing quirk can be replaced by writing a new set of flags: + +# echo FOO:0x:0x200 > /sys/class/drm/edid_
Re: [Linaro-mm-sig] [PATCH 1/4] dma-buf: remove fallback for !CONFIG_DMA_SHARED_BUFFER
On Fri, Aug 10, 2012 at 04:57:43PM +0200, Maarten Lankhorst wrote: > Documentation says that code requiring dma-buf should add it to > select, so inline fallbacks are not going to be used. A link error > will make it obvious what went wrong, instead of silently doing > nothing at runtime. > > Signed-off-by: Maarten Lankhorst I've botched it more than once to update these when creating new dma-buf code. Hence Reviewed-by: Daniel Vetter -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Linaro-mm-sig] [PATCH 3/4] dma-seqno-fence: Hardware dma-buf implementation of fencing (v2)
On Fri, Aug 10, 2012 at 04:57:58PM +0200, Maarten Lankhorst wrote:
> This type of fence can be used with hardware synchronization for simple
> hardware that can block execution until the condition
> (dma_buf[offset] - value) >= 0 has been met.
>
> A software fallback still has to be provided in case the fence is used
> with a device that doesn't support this mechanism. It is useful to expose
> this for graphics cards that have an op to support this.
>
> Some cards like i915 can export those, but don't have an option to wait,
> so they need the software fallback.
>
> I extended the original patch by Rob Clark.
>
> v1: Original
> v2: Renamed from bikeshed to seqno, moved into dma-fence.c since
> not much was left of the file. Lots of documentation added.
>
> Signed-off-by: Maarten Lankhorst
Patch looks good, two bikesheds inline. Either way
Reviewed-by: Daniel Vetter
> ---
> drivers/base/dma-fence.c | 21 +++
> include/linux/dma-fence.h | 61
> +
> 2 files changed, 82 insertions(+)
>
> diff --git a/drivers/base/dma-fence.c b/drivers/base/dma-fence.c
> index 93448e4..4092a58 100644
> --- a/drivers/base/dma-fence.c
> +++ b/drivers/base/dma-fence.c
> @@ -266,3 +266,24 @@ struct dma_fence *dma_fence_create(void *priv)
> return fence;
> }
> EXPORT_SYMBOL_GPL(dma_fence_create);
> +
> +static int seqno_enable_signaling(struct dma_fence *fence)
> +{
> + struct dma_seqno_fence *seqno_fence = to_seqno_fence(fence);
> + return seqno_fence->enable_signaling(seqno_fence);
> +}
> +
> +static void seqno_release(struct dma_fence *fence)
> +{
> + struct dma_seqno_fence *f = to_seqno_fence(fence);
> +
> + if (f->release)
> + f->release(f);
> + dma_buf_put(f->sync_buf);
> +}
> +
> +const struct dma_fence_ops dma_seqno_fence_ops = {
> + .enable_signaling = seqno_enable_signaling,
> + .release = seqno_release
> +};
> +EXPORT_SYMBOL_GPL(dma_seqno_fence_ops);
> diff --git a/include/linux/dma-fence.h b/include/linux/dma-fence.h
> index e0ceddd..3ef0da0 100644
> --- a/include/linux/dma-fence.h
> +++ b/include/linux/dma-fence.h
> @@ -91,6 +91,19 @@ struct dma_fence_ops {
> void (*release)(struct dma_fence *fence);
> };
>
> +struct dma_seqno_fence {
> + struct dma_fence base;
> +
> + struct dma_buf *sync_buf;
> + uint32_t seqno_ofs;
> + uint32_t seqno;
> +
> + int (*enable_signaling)(struct dma_seqno_fence *fence);
> + void (*release)(struct dma_seqno_fence *fence);
I think using dma_fence_ops here is the better color. We lose type-safety
at compile-time, but still keep type-safety at runtime (thanks to
to_dma_seqno_fence). In addition people seem to like to constify function
pointers, we'd save a pointer and if we extend the sw dma_fence interface.
> +};
> +
> +extern const struct dma_fence_ops dma_seqno_fence_ops;
> +
> struct dma_fence *dma_fence_create(void *priv);
>
> /**
> @@ -121,4 +134,52 @@ int dma_fence_wait(struct dma_fence *fence, bool intr,
> unsigned long timeout);
> int dma_fence_add_callback(struct dma_fence *fence, struct dma_fence_cb *cb,
> dma_fence_func_t func, void *priv);
>
> +/**
> + * to_seqno_fence - cast a dma_fence to a dma_seqno_fence
> + * @fence: dma_fence to cast to a dma_seqno_fence
> + *
> + * Returns NULL if the dma_fence is not a dma_seqno_fence,
> + * or the dma_seqno_fence otherwise.
> + */
> +static inline struct dma_seqno_fence *
> +to_seqno_fence(struct dma_fence *fence)
> +{
> + if (fence->ops != &dma_seqno_fence_ops)
> + return NULL;
> + return container_of(fence, struct dma_seqno_fence, base);
> +}
I think adding an is_dma_seqno_fence would be nice ...
> +
> +/**
> + * dma_seqno_fence_init - initialize a seqno fence
> + * @fence: dma_seqno_fence to initialize
> + * @sync_buf: buffer containing the memory location to signal on
> + * @seqno_ofs: the offset within @sync_buf
> + * @seqno: the sequence # to signal on
> + * @priv: value of priv member
> + * @enable_signaling: callback which is called when some other device is
> + *waiting for sw notification of fence
> + * @release: callback called during destruction before object is freed.
> + *
> + * This function initializes a struct dma_seqno_fence with passed parameters,
> + * and takes a reference on sync_buf which is released on fence destruction.
> + */
> +static inline void
> +dma_seqno_fence_init(struct dma_seqno_fence *fence,
> + struct dma_buf *sync_buf,
> + uint32_t seqno_ofs, uint32_t seqno, void *priv,
> + int (*enable_signaling)(struct dma_seqno_fence *),
> + void (*release)(struct dma_seqno_fence *))
> +{
> + BUG_ON(!fence || !sync_buf || !enable_signaling);
> +
> + __dma_fence_init(&fence->base, &dma_seqno_fence_ops, priv);
> +
> + get_dma_buf(sync_buf);
> + fence->sync_buf = sync_buf;
> + fence->seqno_ofs = seqno_ofs
[Bug 44800] Radeon HD 6450 CAICOS screen corruption and kernel crashes
https://bugs.freedesktop.org/show_bug.cgi?id=44800 --- Comment #10 from Alexandre Demers 2012-08-10 20:07:23 UTC --- May or may not be related, but I've seen similar corruption with CAYMAN related to bug 45018 from time to time. But about comment 3, I was tempted to point at bug 42373. Marko, if you are willing to try patches proposed in both mentionned bugs to see if it helps in any way, that could be interesting. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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: [Linaro-mm-sig] [PATCH 2/4] dma-fence: dma-buf synchronization (v8 )
On Fri, Aug 10, 2012 at 04:57:52PM +0200, Maarten Lankhorst wrote:
> A dma-fence can be attached to a buffer which is being filled or consumed
> by hw, to allow userspace to pass the buffer without waiting to another
> device. For example, userspace can call page_flip ioctl to display the
> next frame of graphics after kicking the GPU but while the GPU is still
> rendering. The display device sharing the buffer with the GPU would
> attach a callback to get notified when the GPU's rendering-complete IRQ
> fires, to update the scan-out address of the display, without having to
> wake up userspace.
>
> A dma-fence is transient, one-shot deal. It is allocated and attached
> to one or more dma-buf's. When the one that attached it is done, with
> the pending operation, it can signal the fence.
>
> + dma_fence_signal()
>
> The dma-buf-mgr handles tracking, and waiting on, the fences associated
> with a dma-buf.
>
> TODO maybe need some helper fxn for simple devices, like a display-
> only drm/kms device which simply wants to wait for exclusive fence to
> be signaled, and then attach a non-exclusive fence while scanout is in
> progress.
>
> The one pending on the fence can add an async callback:
> + dma_fence_add_callback()
> The callback can optionally be cancelled with remove_wait_queue()
>
> Or wait synchronously (optionally with timeout or interruptible):
> + dma_fence_wait()
>
> A default software-only implementation is provided, which can be used
> by drivers attaching a fence to a buffer when they have no other means
> for hw sync. But a memory backed fence is also envisioned, because it
> is common that GPU's can write to, or poll on some memory location for
> synchronization. For example:
>
> fence = dma_buf_get_fence(dmabuf);
> if (fence->ops == &bikeshed_fence_ops) {
> dma_buf *fence_buf;
> dma_bikeshed_fence_get_buf(fence, &fence_buf, &offset);
> ... tell the hw the memory location to wait on ...
> } else {
> /* fall-back to sw sync * /
> dma_fence_add_callback(fence, my_cb);
> }
>
> On SoC platforms, if some other hw mechanism is provided for synchronizing
> between IP blocks, it could be supported as an alternate implementation
> with it's own fence ops in a similar way.
>
> To facilitate other non-sw implementations, the enable_signaling callback
> can be used to keep track if a device not supporting hw sync is waiting
> on the fence, and in this case should arrange to call dma_fence_signal()
> at some point after the condition has changed, to notify other devices
> waiting on the fence. If there are no sw waiters, this can be skipped to
> avoid waking the CPU unnecessarily. The handler of the enable_signaling
> op should take a refcount until the fence is signaled, then release its ref.
>
> The intention is to provide a userspace interface (presumably via eventfd)
> later, to be used in conjunction with dma-buf's mmap support for sw access
> to buffers (or for userspace apps that would prefer to do their own
> synchronization).
I think the commit message should be cleaned up: Kill the TODO, rip out
the bikeshed_fence and otherwise update it to the latest code.
>
> v1: Original
> v2: After discussion w/ danvet and mlankhorst on #dri-devel, we decided
> that dma-fence didn't need to care about the sw->hw signaling path
> (it can be handled same as sw->sw case), and therefore the fence->ops
> can be simplified and more handled in the core. So remove the signal,
> add_callback, cancel_callback, and wait ops, and replace with a simple
> enable_signaling() op which can be used to inform a fence supporting
> hw->hw signaling that one or more devices which do not support hw
> signaling are waiting (and therefore it should enable an irq or do
> whatever is necessary in order that the CPU is notified when the
> fence is passed).
> v3: Fix locking fail in attach_fence() and get_fence()
> v4: Remove tie-in w/ dma-buf.. after discussion w/ danvet and mlankorst
> we decided that we need to be able to attach one fence to N dma-buf's,
> so using the list_head in dma-fence struct would be problematic.
> v5: [ Maarten Lankhorst ] Updated for dma-bikeshed-fence and dma-buf-manager.
> v6: [ Maarten Lankhorst ] I removed dma_fence_cancel_callback and some
> comments
> about checking if fence fired or not. This is broken by design.
> waitqueue_active during destruction is now fatal, since the signaller
> should be holding a reference in enable_signalling until it signalled
> the fence. Pass the original dma_fence_cb along, and call __remove_wait
> in the dma_fence_callback handler, so that no cleanup needs to be
> performed.
> v7: [ Maarten Lankhorst ] Set cb->func and only enable sw signaling if
> fence wasn't signaled yet, for example for hardware fences that may
> choose to signal blindly.
> v8: [ Maarten Lankhorst ] Tons of tiny fixes, moved __dma_fence_init to
> header and fixed
Re: [PATCH 1/2] drm/radeon/dynpm: wait for fences on all rings when reclocking
On Fri, Aug 10, 2012 at 1:29 PM, wrote:
> From: Alex Deucher
>
> 1. Drop gui idle stuff, it's not as reliable as fences and only
> covers the 3D engine.
> 2. Wait for fences on all rings. This makes sure all rings are
> idle when reclocking.
>
> Signed-off-by: Alex Deucher
Reviewed-by: Jerome Glisse
> ---
> drivers/gpu/drm/radeon/radeon_pm.c | 17 ++---
> 1 files changed, 6 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_pm.c
> b/drivers/gpu/drm/radeon/radeon_pm.c
> index 7ae6066..2c2c901 100644
> --- a/drivers/gpu/drm/radeon/radeon_pm.c
> +++ b/drivers/gpu/drm/radeon/radeon_pm.c
> @@ -253,18 +253,13 @@ static void radeon_pm_set_clocks(struct radeon_device
> *rdev)
> down_write(&rdev->pm.mclk_lock);
> mutex_lock(&rdev->ring_lock);
>
> - /* gui idle int has issues on older chips it seems */
> - if (rdev->family >= CHIP_R600) {
> - if (rdev->irq.installed) {
> - /* wait for GPU to become idle */
> - radeon_irq_kms_wait_gui_idle(rdev);
> - }
> - } else {
> - struct radeon_ring *ring =
> &rdev->ring[RADEON_RING_TYPE_GFX_INDEX];
> - if (ring->ready) {
> - radeon_fence_wait_empty_locked(rdev,
> RADEON_RING_TYPE_GFX_INDEX);
> - }
> + /* wait for the rings to drain */
> + for (i = 0; i < RADEON_NUM_RINGS; i++) {
> + struct radeon_ring *ring = &rdev->ring[i];
> + if (ring->ready)
> + radeon_fence_wait_empty_locked(rdev, i);
> }
> +
> radeon_unmap_vram_bos(rdev);
>
> if (rdev->irq.installed) {
> --
> 1.7.7.5
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/radeon: remove gui_idle interrupt infrastructure
On Fri, Aug 10, 2012 at 1:29 PM, wrote:
> From: Alex Deucher
>
> It was only used for dynpm, but has been replaced with
> a better implementation using fences. Remove it.
>
> Signed-off-by: Alex Deucher
Reviewed-by: Jerome Glisse
> ---
> drivers/gpu/drm/radeon/evergreen.c |5
> drivers/gpu/drm/radeon/r100.c | 19 -
> drivers/gpu/drm/radeon/r600.c |5
> drivers/gpu/drm/radeon/radeon.h |4 ---
> drivers/gpu/drm/radeon/radeon_device.c |1 -
> drivers/gpu/drm/radeon/radeon_irq_kms.c | 33
> ---
> drivers/gpu/drm/radeon/rs600.c | 19 -
> drivers/gpu/drm/radeon/si.c |5
> 8 files changed, 0 insertions(+), 91 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/evergreen.c
> b/drivers/gpu/drm/radeon/evergreen.c
> index e93b80a..90293c1 100644
> --- a/drivers/gpu/drm/radeon/evergreen.c
> +++ b/drivers/gpu/drm/radeon/evergreen.c
> @@ -2541,10 +2541,6 @@ int evergreen_irq_set(struct radeon_device *rdev)
> DRM_DEBUG("evergreen_irq_set: hdmi 5\n");
> afmt6 |= AFMT_AZ_FORMAT_WTRIG_MASK;
> }
> - if (rdev->irq.gui_idle) {
> - DRM_DEBUG("gui idle\n");
> - grbm_int_cntl |= GUI_IDLE_INT_ENABLE;
> - }
>
> if (rdev->family >= CHIP_CAYMAN) {
> cayman_cp_int_cntl_setup(rdev, 0, cp_int_cntl);
> @@ -3079,7 +3075,6 @@ restart_ih:
> break;
> case 233: /* GUI IDLE */
> DRM_DEBUG("IH: GUI idle\n");
> - wake_up(&rdev->irq.idle_queue);
> break;
> default:
> DRM_DEBUG("Unhandled interrupt: %d %d\n", src_id,
> src_data);
> diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
> index 8acb34f..4774e50 100644
> --- a/drivers/gpu/drm/radeon/r100.c
> +++ b/drivers/gpu/drm/radeon/r100.c
> @@ -698,9 +698,6 @@ int r100_irq_set(struct radeon_device *rdev)
> if (atomic_read(&rdev->irq.ring_int[RADEON_RING_TYPE_GFX_INDEX])) {
> tmp |= RADEON_SW_INT_ENABLE;
> }
> - if (rdev->irq.gui_idle) {
> - tmp |= RADEON_GUI_IDLE_MASK;
> - }
> if (rdev->irq.crtc_vblank_int[0] ||
> atomic_read(&rdev->irq.pflip[0])) {
> tmp |= RADEON_CRTC_VBLANK_MASK;
> @@ -737,12 +734,6 @@ static uint32_t r100_irq_ack(struct radeon_device *rdev)
> RADEON_CRTC_VBLANK_STAT | RADEON_CRTC2_VBLANK_STAT |
> RADEON_FP_DETECT_STAT | RADEON_FP2_DETECT_STAT;
>
> - /* the interrupt works, but the status bit is permanently asserted */
> - if (rdev->irq.gui_idle && radeon_gui_idle(rdev)) {
> - if (!rdev->irq.gui_idle_acked)
> - irq_mask |= RADEON_GUI_IDLE_STAT;
> - }
> -
> if (irqs) {
> WREG32(RADEON_GEN_INT_STATUS, irqs);
> }
> @@ -754,9 +745,6 @@ int r100_irq_process(struct radeon_device *rdev)
> uint32_t status, msi_rearm;
> bool queue_hotplug = false;
>
> - /* reset gui idle ack. the status bit is broken */
> - rdev->irq.gui_idle_acked = false;
> -
> status = r100_irq_ack(rdev);
> if (!status) {
> return IRQ_NONE;
> @@ -769,11 +757,6 @@ int r100_irq_process(struct radeon_device *rdev)
> if (status & RADEON_SW_INT_TEST) {
> radeon_fence_process(rdev,
> RADEON_RING_TYPE_GFX_INDEX);
> }
> - /* gui idle interrupt */
> - if (status & RADEON_GUI_IDLE_STAT) {
> - rdev->irq.gui_idle_acked = true;
> - wake_up(&rdev->irq.idle_queue);
> - }
> /* Vertical blank interrupts */
> if (status & RADEON_CRTC_VBLANK_STAT) {
> if (rdev->irq.crtc_vblank_int[0]) {
> @@ -803,8 +786,6 @@ int r100_irq_process(struct radeon_device *rdev)
> }
> status = r100_irq_ack(rdev);
> }
> - /* reset gui idle ack. the status bit is broken */
> - rdev->irq.gui_idle_acked = false;
> if (queue_hotplug)
> schedule_work(&rdev->hotplug_work);
> if (rdev->msi_enabled) {
> diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
> index d79c639..459c251 100644
> --- a/drivers/gpu/drm/radeon/r600.c
> +++ b/drivers/gpu/drm/radeon/r600.c
> @@ -3088,10 +3088,6 @@ int r600_irq_set(struct radeon_device *rdev)
> DRM_DEBUG("r600_irq_set: hdmi 0\n");
> hdmi1 |= HDMI0_AZ_FORMAT_WTRIG_MASK;
> }
> - if (rdev->irq.gui_idle) {
> - DRM_DEBUG("gui idle\n");
> - grbm_int_cntl |= GUI_IDLE_INT_ENABLE;
> - }
>
> WREG32(CP_INT_CNTL, cp_int_cntl);
> WREG32(DxMODE
[Bug 45018] [bisected] rendering regression and va conflicts since added support for virtual address space on cayman v11
https://bugs.freedesktop.org/show_bug.cgi?id=45018 --- Comment #118 from Alexandre Demers 2012-08-11 04:49:31 UTC --- Reproduced again with exactly the setup Alex told me to use (kernel 3.6-rc1+Jerome's patch v4 and latest mesa containing Christian's fix). To reproduce, I clicked repeatedly on Activities on top left corner of Gnome shell until it locked: Everything.log --- Aug 11 00:23:08 Xander kernel: [92926.580673] radeon :01:00.0: offset 0x20 is in reserved area 0x80 Aug 11 00:23:08 Xander kernel: [92926.587281] [drm:radeon_cs_parser_relocs] *ERROR* gem object lookup failed 0x11 Aug 11 00:23:08 Xander kernel: [92926.587291] [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -2! Aug 11 00:23:08 Xander kernel: [92926.597151] radeon :01:00.0: offset 0x20 is in reserved area 0x80 Aug 11 00:23:18 Xander kernel: [92937.073091] radeon :01:00.0: GPU lockup CP stall for more than 1msec Aug 11 00:23:18 Xander kernel: [92937.073105] radeon :01:00.0: GPU lockup (waiting for 0x0009ea1d last fence id 0x0009ea1c) Aug 11 00:23:18 Xander kernel: [92937.074236] radeon :01:00.0: Saved 15 dwords of commands on ring 0. Aug 11 00:23:18 Xander kernel: [92937.074243] radeon :01:00.0: GPU softreset Aug 11 00:23:18 Xander kernel: [92937.074248] radeon :01:00.0: GRBM_STATUS=0xF5700828 Aug 11 00:23:18 Xander kernel: [92937.074253] radeon :01:00.0: GRBM_STATUS_SE0=0xFC01 Aug 11 00:23:18 Xander kernel: [92937.074258] radeon :01:00.0: GRBM_STATUS_SE1=0xFC01 Aug 11 00:23:18 Xander kernel: [92937.074263] radeon :01:00.0: SRBM_STATUS=0x20020FC0 Aug 11 00:23:18 Xander kernel: [92937.074269] radeon :01:00.0: R_008674_CP_STALLED_STAT1 = 0x Aug 11 00:23:18 Xander kernel: [92937.074274] radeon :01:00.0: R_008678_CP_STALLED_STAT2 = 0x4000 Aug 11 00:23:18 Xander kernel: [92937.074279] radeon :01:00.0: R_00867C_CP_BUSY_STAT = 0x8004 Aug 11 00:23:18 Xander kernel: [92937.074284] radeon :01:00.0: R_008680_CP_STAT = 0x80228647 Aug 11 00:23:18 Xander kernel: [92937.074289] radeon :01:00.0: VM_CONTEXT0_PROTECTION_FAULT_ADDR 0x00074124 Aug 11 00:23:18 Xander kernel: [92937.074294] radeon :01:00.0: VM_CONTEXT0_PROTECTION_FAULT_STATUS 0x00071001 Aug 11 00:23:18 Xander kernel: [92937.074300] radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x21F1 Aug 11 00:23:18 Xander kernel: [92937.074305] radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x020A4004 Aug 11 00:23:19 Xander kernel: [92937.223150] radeon :01:00.0: Wait for MC idle timedout ! Aug 11 00:23:19 Xander kernel: [92937.223152] radeon :01:00.0: GRBM_SOFT_RESET=0xDF7B Aug 11 00:23:19 Xander kernel: [92937.223254] radeon :01:00.0: GRBM_STATUS=0x80103828 Aug 11 00:23:19 Xander kernel: [92937.223256] radeon :01:00.0: GRBM_STATUS_SE0=0x0407 Aug 11 00:23:19 Xander kernel: [92937.223257] radeon :01:00.0: GRBM_STATUS_SE1=0x0407 Aug 11 00:23:19 Xander kernel: [92937.223258] radeon :01:00.0: SRBM_STATUS=0x20020FC0 Aug 11 00:23:19 Xander kernel: [92937.223260] radeon :01:00.0: R_008674_CP_STALLED_STAT1 = 0x Aug 11 00:23:19 Xander kernel: [92937.223262] radeon :01:00.0: R_008678_CP_STALLED_STAT2 = 0x Aug 11 00:23:19 Xander kernel: [92937.223263] radeon :01:00.0: R_00867C_CP_BUSY_STAT = 0x Aug 11 00:23:19 Xander kernel: [92937.223264] radeon :01:00.0: R_008680_CP_STAT = 0x Aug 11 00:23:19 Xander kernel: [92937.224266] radeon :01:00.0: GPU reset succeeded, trying to resume Aug 11 00:23:19 Xander kernel: [92937.230003] [drm] probing gen 2 caps for device 1022:9603 = 2/0 Aug 11 00:23:19 Xander kernel: [92937.230004] [drm] enabling PCIE gen 2 link speeds, disable with radeon.pcie_gen2=0 Aug 11 00:23:19 Xander kernel: [92937.388426] radeon :01:00.0: Wait for MC idle timedout ! Aug 11 00:23:19 Xander kernel: [92937.546743] radeon :01:00.0: Wait for MC idle timedout ! Aug 11 00:23:19 Xander kernel: [92937.548662] [drm] PCIE GART of 512M enabled (table at 0x0004). Aug 11 00:23:19 Xander kernel: [92937.548751] radeon :01:00.0: WB enabled Aug 11 00:23:19 Xander kernel: [92937.548754] radeon :01:00.0: fence driver on ring 0 use gpu addr 0x4c00 and cpu addr 0x88022332dc00 Aug 11 00:23:19 Xander kernel: [92937.548755] radeon :01:00.0: fence driver on ring 1 use gpu addr 0x4c04 and cpu addr 0x88022332dc04 Aug 11 00:23:19 Xander kernel: [92937.548757] radeon :01:00.0: fence driver on ring 2 use gpu addr 0x4c08 and cpu addr 0x88022332dc08 Aug 11 00:23:19 Xander kernel: [92937.752374] [drm:r600_ring_test] *ERROR* radeon: ring 0 test failed (scratch(0x8504)=0xCAFEDEAD) Aug 11 00:23:19 Xander kernel: [92937.752377] [drm:cayman_resume] *ERROR* cayman startup failed on resume Could it be a previously hidden bug that patches from Jerome an
[PATCH] staging: omapdrm: Fix DMM sparse warnings
On Thu, Aug 9, 2012 at 10:26 PM, Rob Clark wrote:
> On Thu, Aug 9, 2012 at 12:14 AM, Andy Gross wrote:
>> Fix the following sparse warnings:
>>
>> drivers/staging/omapdrm/omap_dmm_tiler.c:123:13:
>>warning: symbol 'omap_dmm_irq_handler' was not declared.
>>Should it be static?
>>
>> drivers/staging/omapdrm/omap_dmm_tiler.c:370:24:
>>warning: Using plain integer as NULL pointer
>>
>> Signed-off-by: Andy Gross
>
> Signed-off-by: Rob Clark
Reviewed-by: Sumit Semwal
>
>> ---
>> drivers/staging/omapdrm/omap_dmm_tiler.c |4 ++--
>> 1 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/staging/omapdrm/omap_dmm_tiler.c
>> b/drivers/staging/omapdrm/omap_dmm_tiler.c
>> index 8619783..ec7a5c8 100644
>> --- a/drivers/staging/omapdrm/omap_dmm_tiler.c
>> +++ b/drivers/staging/omapdrm/omap_dmm_tiler.c
>> @@ -120,7 +120,7 @@ static int wait_status(struct refill_engine *engine,
>> uint32_t wait_mask)
>> return 0;
>> }
>>
>> -irqreturn_t omap_dmm_irq_handler(int irq, void *arg)
>> +static irqreturn_t omap_dmm_irq_handler(int irq, void *arg)
>> {
>> struct dmm *dmm = arg;
>> uint32_t status = readl(dmm->base + DMM_PAT_IRQSTATUS);
>> @@ -367,7 +367,7 @@ struct tiler_block *tiler_reserve_1d(size_t size)
>> int num_pages = (size + PAGE_SIZE - 1) >> PAGE_SHIFT;
>>
>> if (!block)
>> - return 0;
>> + return ERR_PTR(-ENOMEM);
>>
>> block->fmt = TILFMT_PAGE;
>>
>> --
>> 1.7.5.4
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
>> the body of a message to majordomo at vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 41265] Radeon KMS does not work on thunderbolt media dock
https://bugs.freedesktop.org/show_bug.cgi?id=41265
--- Comment #25 from gyhor at gmx.de 2012-08-10 12:11:40 UTC ---
i don't know why, but it don't get the VFCT Table.
this returns false:
(!ACPI_SUCCESS(acpi_get_table("VFCT", 1, &hdr)))
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
[PATCH] drm/usb: select USB_SUPPORT in Kconfig
DRM_USB selects USB. However, USB depends on USB_SUPPORT and USB_ARCH_HAS_HCD. Thus, selecting USB_SUPPORT in Kconfig avoids the following warning (detected when DisplayLink was selected using exynos4_defconfig): warning: (MOUSE_APPLETOUCH && MOUSE_BCM5974 && MOUSE_SYNAPTICS_USB && JOYSTICK_XPAD && TABLET_USB_ACECAD && TABLET_USB_AIPTEK && TABLET_USB_HANWANG && TABLET_USB_KBTAB && TABLET_USB_WACOM && TOUCHSCREEN_USB_COMPOSITE && INPUT_ATI_REMOTE2 && INPUT_KEYSPAN_REMOTE && INPUT_POWERMATE && INPUT_YEALINK && INPUT_CM109 && RC_ATI_REMOTE && IR_IMON && IR_MCEUSB && IR_REDRAT3 && IR_STREAMZAP && IR_IGUANA && DRM_USB) selects USB which has unmet direct dependencies (USB_SUPPORT && USB_ARCH_HAS_HCD) Signed-off-by: Sachin Kamat --- drivers/gpu/drm/Kconfig |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index 23120c0..45536db 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -23,6 +23,7 @@ config DRM_USB tristate depends on DRM select USB + select USB_SUPPORT config DRM_KMS_HELPER tristate -- 1.7.4.1
[RFCv3 PATCH 2/8] V4L2 spec: document the new DV controls and ioctls.
Signed-off-by: Hans Verkuil --- Documentation/DocBook/media/v4l/biblio.xml | 40 +++ Documentation/DocBook/media/v4l/controls.xml | 161 ++ Documentation/DocBook/media/v4l/v4l2.xml |1 + 3 files changed, 202 insertions(+) diff --git a/Documentation/DocBook/media/v4l/biblio.xml b/Documentation/DocBook/media/v4l/biblio.xml index 1078e45..860626a 100644 --- a/Documentation/DocBook/media/v4l/biblio.xml +++ b/Documentation/DocBook/media/v4l/biblio.xml @@ -226,4 +226,44 @@ in the frequency range from 87,5 to 108,0 MHz VESA and Industry Standards and Guidelines for Computer Display Monitor Timing (DMT) + + EDID + + Video Electronics Standards Association +(http://www.vesa.org";>http://www.vesa.org) + + VESA Enhanced Extended Display Identification Data Standard + Release A, Revision 2 + + + + HDCP + + Digital Content Protection LLC +(http://www.digital-cp.com";>http://www.digital-cp.com) + + High-bandwidth Digital Content Protection System + Revision 1.3 + + + + HDMI + + HDMI Licensing LLC +(http://www.hdmi.org";>http://www.hdmi.org) + + High-Definition Multimedia Interface + Specification Version 1.4a + + + + DP + + Video Electronics Standards Association +(http://www.vesa.org";>http://www.vesa.org) + + VESA DisplayPort Standard + Version 1, Revision 2 + + diff --git a/Documentation/DocBook/media/v4l/controls.xml b/Documentation/DocBook/media/v4l/controls.xml index b0964fb..1b0b95e 100644 --- a/Documentation/DocBook/media/v4l/controls.xml +++ b/Documentation/DocBook/media/v4l/controls.xml @@ -4274,4 +4274,165 @@ interface and may change in the future. + + + Digital Video Control Reference + + + Experimental + + This is an experimental interface and may + change in the future. + + + + The Digital Video control class is intended to control receivers + and transmitters for http://en.wikipedia.org/wiki/Vga";>VGA, + http://en.wikipedia.org/wiki/Digital_Visual_Interface";>DVI + (Digital Visual Interface), HDMI () and DisplayPort (). + These controls are generally expected to be private to the receiver or transmitter + subdevice that implements them, so they are only exposed on the + /dev/v4l-subdev* device node. + + + Note that these devices can have multiple input or output pads which are + hooked up to e.g. HDMI connectors. Even though the subdevice will receive or + transmit video from/to only one of those pads, the other pads can still be + active when it comes to EDID (Extended Display Identification Data, + ) and HDCP (High-bandwidth Digital Content + Protection System, ) processing, allowing the device + to do the fairly slow EDID/HDCP handling in advance. This allows for quick + switching between connectors. + + These pads appear in several of the controls in this section as + bitmasks, one bit for each pad. Bit 0 corresponds to pad 0, bit 1 to pad 1, + etc. The maximum value of the control is the set of valid pads. + + + Digital Video Control IDs + + + + + + + + + + + ID + Type + Description + + + + + + V4L2_CID_DV_CLASS + class + + + The Digital Video class descriptor. + + + V4L2_CID_DV_TX_HOTPLUG + bitmask + + + Many connectors have a hotplug pin which is high + if EDID information is available from the source. This control shows the + state of the hotplug pin as seen by the transmitter. + Each bit corresponds to an output pad on the transmitter. If an output pad + does not have an associated hotplug pin, then the bit for that pad will be 0. + This read-only control is applicable to DVI-D, HDMI and DisplayPort connectors. + + + + V4L2_CID_DV_TX_RXSENSE + bitmask + + + Rx Sense is the detection of pull-ups on the TMDS +clock lines. This normally means that the sink has left/entered standby (i.e. + the transmitter can sense that the receiver is ready to receive video). + Each bit corresponds to an output pad on the transmitter. If an output pad + does not have an associated Rx Sense, then the bit for that pad will be 0. + This read-only control is applicable to DVI-D and HDMI devices. + + + + V4L2_CID_DV_TX_EDID_PRESENT + bitmask + + + When the transmitter sees the hotplug signal from the +
[RFCv3 PATCH 1/8] v4l2 core: add the missing pieces to support DVI/HDMI/DisplayPort.
These new controls and two new ioctls make it possible to properly support
VGA, DVI-A/D/I, HDMI and DisplayPort connectors. All these controls and the
ioctls are all at the sub-device level. They are meant for V4L2 bridge/platform
drivers or to be accessed on embedded systems through /dev/v4l-subdev* device
nodes.
Signed-off-by: Hans Verkuil
---
include/linux/v4l2-subdev.h | 10 ++
include/linux/videodev2.h | 23 +++
2 files changed, 33 insertions(+)
diff --git a/include/linux/v4l2-subdev.h b/include/linux/v4l2-subdev.h
index 8c57ee9..a426a78 100644
--- a/include/linux/v4l2-subdev.h
+++ b/include/linux/v4l2-subdev.h
@@ -148,6 +148,14 @@ struct v4l2_subdev_selection {
__u32 reserved[8];
};
+struct v4l2_subdev_edid {
+ __u32 pad;
+ __u32 start_block;
+ __u32 blocks;
+ __u32 reserved[5];
+ __u8 __user *edid;
+};
+
#define VIDIOC_SUBDEV_G_FMT_IOWR('V', 4, struct v4l2_subdev_format)
#define VIDIOC_SUBDEV_S_FMT_IOWR('V', 5, struct v4l2_subdev_format)
#define VIDIOC_SUBDEV_G_FRAME_INTERVAL \
@@ -166,5 +174,7 @@ struct v4l2_subdev_selection {
_IOWR('V', 61, struct v4l2_subdev_selection)
#define VIDIOC_SUBDEV_S_SELECTION \
_IOWR('V', 62, struct v4l2_subdev_selection)
+#define VIDIOC_SUBDEV_G_EDID _IOWR('V', 63, struct v4l2_subdev_edid)
+#define VIDIOC_SUBDEV_S_EDID _IOWR('V', 64, struct v4l2_subdev_edid)
#endif
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 7a147c8..91939a7 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -1250,6 +1250,7 @@ struct v4l2_ext_controls {
#define V4L2_CTRL_CLASS_JPEG 0x009d/* JPEG-compression
controls */
#define V4L2_CTRL_CLASS_IMAGE_SOURCE 0x009e/* Image source
controls */
#define V4L2_CTRL_CLASS_IMAGE_PROC 0x009f /* Image processing controls */
+#define V4L2_CTRL_CLASS_DV 0x00a0 /* Digital Video controls */
#define V4L2_CTRL_ID_MASK(0x0fff)
#define V4L2_CTRL_ID2CLASS(id)((id) & 0x0fffUL)
@@ -1993,6 +1994,28 @@ enum v4l2_jpeg_chroma_subsampling {
#define V4L2_CID_LINK_FREQ (V4L2_CID_IMAGE_PROC_CLASS_BASE
+ 1)
#define V4L2_CID_PIXEL_RATE(V4L2_CID_IMAGE_PROC_CLASS_BASE
+ 2)
+/* DV-class control IDs defined by V4L2 */
+#define V4L2_CID_DV_CLASS_BASE (V4L2_CTRL_CLASS_DV | 0x900)
+#define V4L2_CID_DV_CLASS (V4L2_CTRL_CLASS_DV | 1)
+
+#defineV4L2_CID_DV_TX_HOTPLUG (V4L2_CID_DV_CLASS_BASE
+ 1)
+#defineV4L2_CID_DV_TX_RXSENSE (V4L2_CID_DV_CLASS_BASE
+ 2)
+#defineV4L2_CID_DV_TX_EDID_PRESENT (V4L2_CID_DV_CLASS_BASE
+ 3)
+#defineV4L2_CID_DV_TX_MODE (V4L2_CID_DV_CLASS_BASE
+ 4)
+enum v4l2_dv_tx_mode {
+ V4L2_DV_TX_MODE_DVI_D = 0,
+ V4L2_DV_TX_MODE_HDMI= 1,
+};
+#define V4L2_CID_DV_TX_RGB_RANGE (V4L2_CID_DV_CLASS_BASE + 5)
+enum v4l2_dv_rgb_range {
+ V4L2_DV_RGB_RANGE_AUTO= 0,
+ V4L2_DV_RGB_RANGE_LIMITED = 1,
+ V4L2_DV_RGB_RANGE_FULL= 2,
+};
+
+#defineV4L2_CID_DV_RX_POWER_PRESENT(V4L2_CID_DV_CLASS_BASE
+ 100)
+#define V4L2_CID_DV_RX_RGB_RANGE (V4L2_CID_DV_CLASS_BASE + 101)
+
/*
* T U N I N G
*/
--
1.7.10.4
[RFCv3 PATCH 3/8] v4l2-subdev: add support for the new edid ioctls.
Signed-off-by: Hans Verkuil
---
drivers/media/video/v4l2-compat-ioctl32.c | 57 +
drivers/media/video/v4l2-ioctl.c | 13 +++
drivers/media/video/v4l2-subdev.c |6 +++
include/media/v4l2-subdev.h |2 +
4 files changed, 78 insertions(+)
diff --git a/drivers/media/video/v4l2-compat-ioctl32.c
b/drivers/media/video/v4l2-compat-ioctl32.c
index 9ebd5c5..e843705 100644
--- a/drivers/media/video/v4l2-compat-ioctl32.c
+++ b/drivers/media/video/v4l2-compat-ioctl32.c
@@ -16,6 +16,7 @@
#include
#include
#include
+#include
#include
#include
@@ -729,6 +730,44 @@ static int put_v4l2_event32(struct v4l2_event *kp, struct
v4l2_event32 __user *u
return 0;
}
+struct v4l2_subdev_edid32 {
+ __u32 pad;
+ __u32 start_block;
+ __u32 blocks;
+ __u32 reserved[5];
+ compat_caddr_t edid;
+};
+
+static int get_v4l2_subdev_edid32(struct v4l2_subdev_edid *kp, struct
v4l2_subdev_edid32 __user *up)
+{
+ u32 tmp;
+
+ if (!access_ok(VERIFY_READ, up, sizeof(struct v4l2_subdev_edid32)) ||
+ get_user(kp->pad, &up->pad) ||
+ get_user(kp->start_block, &up->start_block) ||
+ get_user(kp->blocks, &up->blocks) ||
+ get_user(tmp, &up->edid) ||
+ copy_from_user(kp->reserved, up->reserved,
sizeof(kp->reserved)))
+ return -EFAULT;
+ kp->edid = compat_ptr(tmp);
+ return 0;
+}
+
+static int put_v4l2_subdev_edid32(struct v4l2_subdev_edid *kp, struct
v4l2_subdev_edid32 __user *up)
+{
+ u32 tmp = (u32)((unsigned long)kp->edid);
+
+ if (!access_ok(VERIFY_WRITE, up, sizeof(struct v4l2_subdev_edid32)) ||
+ put_user(kp->pad, &up->pad) ||
+ put_user(kp->start_block, &up->start_block) ||
+ put_user(kp->blocks, &up->blocks) ||
+ put_user(tmp, &up->edid) ||
+ copy_to_user(kp->reserved, up->reserved, sizeof(kp->reserved)))
+ return -EFAULT;
+ return 0;
+}
+
+
#define VIDIOC_G_FMT32 _IOWR('V', 4, struct v4l2_format32)
#define VIDIOC_S_FMT32 _IOWR('V', 5, struct v4l2_format32)
#define VIDIOC_QUERYBUF32 _IOWR('V', 9, struct v4l2_buffer32)
@@ -738,6 +777,8 @@ static int put_v4l2_event32(struct v4l2_event *kp, struct
v4l2_event32 __user *u
#define VIDIOC_DQBUF32 _IOWR('V', 17, struct v4l2_buffer32)
#define VIDIOC_ENUMSTD32 _IOWR('V', 25, struct v4l2_standard32)
#define VIDIOC_ENUMINPUT32 _IOWR('V', 26, struct v4l2_input32)
+#define VIDIOC_SUBDEV_G_EDID32 _IOWR('V', 63, struct v4l2_subdev_edid32)
+#define VIDIOC_SUBDEV_S_EDID32 _IOWR('V', 64, struct v4l2_subdev_edid32)
#define VIDIOC_TRY_FMT32 _IOWR('V', 64, struct v4l2_format32)
#define VIDIOC_G_EXT_CTRLS32_IOWR('V', 71, struct v4l2_ext_controls32)
#define VIDIOC_S_EXT_CTRLS32_IOWR('V', 72, struct v4l2_ext_controls32)
@@ -765,6 +806,7 @@ static long do_video_ioctl(struct file *file, unsigned int
cmd, unsigned long ar
struct v4l2_ext_controls v2ecs;
struct v4l2_event v2ev;
struct v4l2_create_buffers v2crt;
+ struct v4l2_subdev_edid v2edid;
unsigned long vx;
int vi;
} karg;
@@ -797,6 +839,8 @@ static long do_video_ioctl(struct file *file, unsigned int
cmd, unsigned long ar
case VIDIOC_S_OUTPUT32: cmd = VIDIOC_S_OUTPUT; break;
case VIDIOC_CREATE_BUFS32: cmd = VIDIOC_CREATE_BUFS; break;
case VIDIOC_PREPARE_BUF32: cmd = VIDIOC_PREPARE_BUF; break;
+ case VIDIOC_SUBDEV_G_EDID32: cmd = VIDIOC_SUBDEV_G_EDID; break;
+ case VIDIOC_SUBDEV_S_EDID32: cmd = VIDIOC_SUBDEV_S_EDID; break;
}
switch (cmd) {
@@ -814,6 +858,12 @@ static long do_video_ioctl(struct file *file, unsigned int
cmd, unsigned long ar
compatible_arg = 0;
break;
+ case VIDIOC_SUBDEV_G_EDID:
+ case VIDIOC_SUBDEV_S_EDID:
+ err = get_v4l2_subdev_edid32(&karg.v2edid, up);
+ compatible_arg = 0;
+ break;
+
case VIDIOC_G_FMT:
case VIDIOC_S_FMT:
case VIDIOC_TRY_FMT:
@@ -906,6 +956,11 @@ static long do_video_ioctl(struct file *file, unsigned int
cmd, unsigned long ar
err = put_v4l2_event32(&karg.v2ev, up);
break;
+ case VIDIOC_SUBDEV_G_EDID:
+ case VIDIOC_SUBDEV_S_EDID:
+ err = put_v4l2_subdev_edid32(&karg.v2edid, up);
+ break;
+
case VIDIOC_G_FMT:
case VIDIOC_S_FMT:
case VIDIOC_TRY_FMT:
@@ -1026,6 +1081,8 @@ long v4l2_compat_ioctl32(struct file *file, unsigned int
cmd, unsigned long arg)
case VIDIOC_QUERY_DV_TIMINGS:
case VIDIOC_DV_TIMINGS_CAP:
case VIDIOC_ENUM_FREQ_BANDS:
+ case VIDIOC_SUBDEV_G_EDID32:
+ case VIDIOC_SUBDEV_S_EDID32:
ret = do_vide
[RFCv3 PATCH 4/8] v4l2-ctrls.c: add support for the new DV controls.
Signed-off-by: Hans Verkuil
---
drivers/media/video/v4l2-ctrls.c | 39 ++
1 file changed, 39 insertions(+)
diff --git a/drivers/media/video/v4l2-ctrls.c b/drivers/media/video/v4l2-ctrls.c
index b6a2ee7..6a34c30 100644
--- a/drivers/media/video/v4l2-ctrls.c
+++ b/drivers/media/video/v4l2-ctrls.c
@@ -425,6 +425,18 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
"Gray",
NULL,
};
+ static const char * const dv_tx_mode[] = {
+ "DVI-D",
+ "HDMI",
+ NULL,
+ };
+ static const char * const dv_rgb_range[] = {
+ "Automatic",
+ "RGB limited range (16-235)",
+ "RGB full range (0-255)",
+ NULL,
+ };
+
switch (id) {
case V4L2_CID_MPEG_AUDIO_SAMPLING_FREQ:
@@ -502,6 +514,11 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
return mpeg4_profile;
case V4L2_CID_JPEG_CHROMA_SUBSAMPLING:
return jpeg_chroma_subsampling;
+ case V4L2_CID_DV_TX_MODE:
+ return dv_tx_mode;
+ case V4L2_CID_DV_TX_RGB_RANGE:
+ case V4L2_CID_DV_RX_RGB_RANGE:
+ return dv_rgb_range;
default:
return NULL;
@@ -733,6 +750,16 @@ const char *v4l2_ctrl_get_name(u32 id)
case V4L2_CID_LINK_FREQ:return "Link Frequency";
case V4L2_CID_PIXEL_RATE: return "Pixel Rate";
+ /* DV controls */
+ case V4L2_CID_DV_CLASS: return "Digital Video Controls";
+ case V4L2_CID_DV_TX_HOTPLUG:return "Hotplug Present";
+ case V4L2_CID_DV_TX_RXSENSE:return "RxSense Present";
+ case V4L2_CID_DV_TX_EDID_PRESENT: return "EDID Present";
+ case V4L2_CID_DV_TX_MODE: return "Transmit Mode";
+ case V4L2_CID_DV_TX_RGB_RANGE: return "Tx RGB Quantization
Range";
+ case V4L2_CID_DV_RX_POWER_PRESENT: return "Power Present";
+ case V4L2_CID_DV_RX_RGB_RANGE: return "Rx RGB Quantization
Range";
+
default:
return NULL;
}
@@ -832,6 +859,9 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum
v4l2_ctrl_type *type,
case V4L2_CID_ISO_SENSITIVITY_AUTO:
case V4L2_CID_EXPOSURE_METERING:
case V4L2_CID_SCENE_MODE:
+ case V4L2_CID_DV_TX_MODE:
+ case V4L2_CID_DV_TX_RGB_RANGE:
+ case V4L2_CID_DV_RX_RGB_RANGE:
*type = V4L2_CTRL_TYPE_MENU;
break;
case V4L2_CID_LINK_FREQ:
@@ -853,6 +883,7 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum
v4l2_ctrl_type *type,
case V4L2_CID_JPEG_CLASS:
case V4L2_CID_IMAGE_SOURCE_CLASS:
case V4L2_CID_IMAGE_PROC_CLASS:
+ case V4L2_CID_DV_CLASS:
*type = V4L2_CTRL_TYPE_CTRL_CLASS;
/* You can neither read not write these */
*flags |= V4L2_CTRL_FLAG_READ_ONLY | V4L2_CTRL_FLAG_WRITE_ONLY;
@@ -869,6 +900,10 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum
v4l2_ctrl_type *type,
case V4L2_CID_JPEG_ACTIVE_MARKER:
case V4L2_CID_3A_LOCK:
case V4L2_CID_AUTO_FOCUS_STATUS:
+ case V4L2_CID_DV_TX_HOTPLUG:
+ case V4L2_CID_DV_TX_RXSENSE:
+ case V4L2_CID_DV_TX_EDID_PRESENT:
+ case V4L2_CID_DV_RX_POWER_PRESENT:
*type = V4L2_CTRL_TYPE_BITMASK;
break;
case V4L2_CID_MIN_BUFFERS_FOR_CAPTURE:
@@ -933,6 +968,10 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum
v4l2_ctrl_type *type,
case V4L2_CID_FLASH_STROBE_STATUS:
case V4L2_CID_AUTO_FOCUS_STATUS:
case V4L2_CID_FLASH_READY:
+ case V4L2_CID_DV_TX_HOTPLUG:
+ case V4L2_CID_DV_TX_RXSENSE:
+ case V4L2_CID_DV_TX_EDID_PRESENT:
+ case V4L2_CID_DV_RX_POWER_PRESENT:
*flags |= V4L2_CTRL_FLAG_READ_ONLY;
break;
}
--
1.7.10.4
[RFCv3 PATCH 0/8] V4L2: add missing pieces to support HDMI et al and add adv7604/ad9389b drivers
Hi all, This is the third version of this patch series. The second version can be found here: http://www.spinics.net/lists/linux-media/msg50413.html I made a pull request based on that and got some feedback: http://patchwork.linuxtv.org/patch/13442/ The feedback has been incorporated in this third version. One suggestion I got was to run this by the video devs as well so that they can take a look at the V4L2 EDID API, just in case I missed something, so that's why this is being cross-posted to the dri-devel mailinglist. Note that the EDID API at the moment is only meant to pass the EDID to userspace and vice versa. There is no parsing at the moment. If we ever need parsing in V4L2 (and I'm sure we will) then we will of course use shared EDID parsing code. The second patch documents the new V4L2 API additions. So that's a good one to review when it comes to the API. Regards, Hans
[RFCv3 PATCH 5/8] v4l2-common: add v4l_match_dv_timings.
Add the v4l_match_dv_timings function that can be used to compare two
v4l2_dv_timings structs.
Signed-off-by: Hans Verkuil
---
drivers/media/video/v4l2-common.c | 33 +
include/media/v4l2-common.h |4
2 files changed, 37 insertions(+)
diff --git a/drivers/media/video/v4l2-common.c
b/drivers/media/video/v4l2-common.c
index 1baec83..38da47c 100644
--- a/drivers/media/video/v4l2-common.c
+++ b/drivers/media/video/v4l2-common.c
@@ -597,6 +597,39 @@ int v4l_fill_dv_preset_info(u32 preset, struct
v4l2_dv_enum_preset *info)
}
EXPORT_SYMBOL_GPL(v4l_fill_dv_preset_info);
+/**
+ * v4l_match_dv_timings - check if two timings match
+ * @t1 - compare this v4l2_dv_timings struct...
+ * @t2 - with this struct.
+ * @pclock_delta - the allowed pixelclock deviation.
+ *
+ * Compare t1 with t2 with a given margin of error for the pixelclock.
+ */
+bool v4l_match_dv_timings(const struct v4l2_dv_timings *t1,
+ const struct v4l2_dv_timings *t2,
+ unsigned pclock_delta)
+{
+ if (t1->type != t2->type || t1->type != V4L2_DV_BT_656_1120)
+ return false;
+ if (t1->bt.width == t2->bt.width &&
+ t1->bt.height == t2->bt.height &&
+ t1->bt.interlaced == t2->bt.interlaced &&
+ t1->bt.polarities == t2->bt.polarities &&
+ t1->bt.pixelclock >= t2->bt.pixelclock - pclock_delta &&
+ t1->bt.pixelclock <= t2->bt.pixelclock + pclock_delta &&
+ t1->bt.hfrontporch == t2->bt.hfrontporch &&
+ t1->bt.vfrontporch == t2->bt.vfrontporch &&
+ t1->bt.vsync == t2->bt.vsync &&
+ t1->bt.vbackporch == t2->bt.vbackporch &&
+ (!t1->bt.interlaced ||
+ (t1->bt.il_vfrontporch == t2->bt.il_vfrontporch &&
+t1->bt.il_vsync == t2->bt.il_vsync &&
+t1->bt.il_vbackporch == t2->bt.il_vbackporch)))
+ return true;
+ return false;
+}
+EXPORT_SYMBOL_GPL(v4l_match_dv_timings);
+
const struct v4l2_frmsize_discrete *v4l2_find_nearest_format(
const struct v4l2_discrete_probe *probe,
s32 width, s32 height)
diff --git a/include/media/v4l2-common.h b/include/media/v4l2-common.h
index a298ec4..b43b968 100644
--- a/include/media/v4l2-common.h
+++ b/include/media/v4l2-common.h
@@ -212,4 +212,8 @@ const struct v4l2_frmsize_discrete
*v4l2_find_nearest_format(
const struct v4l2_discrete_probe *probe,
s32 width, s32 height);
+bool v4l_match_dv_timings(const struct v4l2_dv_timings *t1,
+ const struct v4l2_dv_timings *t2,
+ unsigned pclock_delta);
+
#endif /* V4L2_COMMON_H_ */
--
1.7.10.4
[RFCv3 PATCH 6/8] v4l2-common: add CVT and GTF detection functions.
These two helper functions detect whether the analog video timings detected
by the video receiver match the VESA CVT or GTF standards.
They basically do the inverse of the CVT and GTF modeline calculations.
This patch also adds a helper function that will determine the aspect ratio
based on the provided EDID values. This aspect ratio can be given to the GTF
helper function.
Signed-off-by: Hans Verkuil
---
drivers/media/video/v4l2-common.c | 325 +
include/media/v4l2-common.h |9 +
2 files changed, 334 insertions(+)
diff --git a/drivers/media/video/v4l2-common.c
b/drivers/media/video/v4l2-common.c
index 38da47c..33e57d8 100644
--- a/drivers/media/video/v4l2-common.c
+++ b/drivers/media/video/v4l2-common.c
@@ -630,6 +630,331 @@ bool v4l_match_dv_timings(const struct v4l2_dv_timings
*t1,
}
EXPORT_SYMBOL_GPL(v4l_match_dv_timings);
+/*
+ * CVT defines
+ * Based on Coordinated Video Timings Standard
+ * version 1.1 September 10, 2003
+ */
+
+#define CVT_PXL_CLK_GRAN 25 /* pixel clock granularity */
+
+/* Normal blanking */
+#define CVT_MIN_V_BPORCH 7 /* lines */
+#define CVT_MIN_V_PORCH_RND3 /* lines */
+#define CVT_MIN_VSYNC_BP 550 /* min time of vsync + back porch (us)
*/
+
+/* Normal blanking for CVT uses GTF to calculate horizontal blanking */
+#define CVT_CELL_GRAN 8 /* character cell granularity */
+#define CVT_M 600 /* blanking formula gradient */
+#define CVT_C 40 /* blanking formula offset */
+#define CVT_K 128 /* blanking formula scaling factor */
+#define CVT_J 20 /* blanking formula scaling factor */
+#define CVT_C_PRIME (((CVT_C - CVT_J) * CVT_K / 256) + CVT_J)
+#define CVT_M_PRIME (CVT_K * CVT_M / 256)
+
+/* Reduced Blanking */
+#define CVT_RB_MIN_V_BPORCH7 /* lines */
+#define CVT_RB_V_FPORCH3 /* lines */
+#define CVT_RB_MIN_V_BLANK 460 /* us */
+#define CVT_RB_H_SYNC 32 /* pixels */
+#define CVT_RB_H_BPORCH 80 /* pixels */
+#define CVT_RB_H_BLANK 160 /* pixels */
+
+/** v4l2_detect_cvt - detect if the given timings follow the CVT standard
+ * @frame_height - the total height of the frame (including blanking) in lines.
+ * @hfreq - the horizontal frequency in Hz.
+ * @vsync - the height of the vertical sync in lines.
+ * @polarities - the horizontal and vertical polarities (same as struct
+ * v4l2_bt_timings polarities).
+ * @fmt - the resulting timings.
+ *
+ * This function will attempt to detect if the given values correspond to a
+ * valid CVT format. If so, then it will return true, and fmt will be filled
+ * in with the found CVT timings.
+ */
+bool v4l2_detect_cvt(unsigned frame_height, unsigned hfreq, unsigned vsync,
+ u32 polarities, struct v4l2_dv_timings *fmt)
+{
+ int v_fp, v_bp, h_fp, h_bp, hsync;
+ int frame_width, image_height, image_width;
+ bool reduced_blanking;
+ unsigned pix_clk;
+
+ if (vsync < 4 || vsync > 7)
+ return false;
+
+ if (polarities == V4L2_DV_VSYNC_POS_POL)
+ reduced_blanking = false;
+ else if (polarities == V4L2_DV_HSYNC_POS_POL)
+ reduced_blanking = true;
+ else
+ return false;
+
+ /* Vertical */
+ if (reduced_blanking) {
+ v_fp = CVT_RB_V_FPORCH;
+ v_bp = (CVT_RB_MIN_V_BLANK * hfreq + 99) / 100;
+ v_bp -= vsync + v_fp;
+
+ if (v_bp < CVT_RB_MIN_V_BPORCH)
+ v_bp = CVT_RB_MIN_V_BPORCH;
+ } else {
+ v_fp = CVT_MIN_V_PORCH_RND;
+ v_bp = (CVT_MIN_VSYNC_BP * hfreq + 99) / 100 - vsync;
+
+ if (v_bp < CVT_MIN_V_BPORCH)
+ v_bp = CVT_MIN_V_BPORCH;
+ }
+ image_height = (frame_height - v_fp - vsync - v_bp + 1) & ~0x1;
+
+ /* Aspect ratio based on vsync */
+ switch (vsync) {
+ case 4:
+ image_width = (image_height * 4) / 3;
+ break;
+ case 5:
+ image_width = (image_height * 16) / 9;
+ break;
+ case 6:
+ image_width = (image_height * 16) / 10;
+ break;
+ case 7:
+ /* special case */
+ if (image_height == 1024)
+ image_width = (image_height * 5) / 4;
+ else if (image_height == 768)
+ image_width = (image_height * 15) / 9;
+ else
+ return false;
+ break;
+ default:
+ return false;
+ }
+
+ image_width = image_width & ~7;
+
+ /* Horizontal */
+ if (reduced_blanking) {
+ pix_clk = (image_width + CVT_RB_H_BLANK) * hfreq;
+ pix_clk = (pix_clk / CVT_PXL_CLK_GRAN) * CVT_PXL_C
[RFCv3 PATCH 7/8] adv7604: driver for the Analog Devices ADV7604 video decoder.
Initial version of this driver.
The full datasheets are available from the Analog Devices website:
http://ez.analog.com/docs/DOC-1545
Not all features of the receiver are supported by this driver for various
reasons. Most notably:
- No CEC support (the CEC API needs a lot more discussion)
- Only port A of the four HDMI input ports is implemented (our hardware only
uses that port)
- No HDCP repeater support (we don't use that either)
And since there are some 600-odd pages of datasheet for this single device,
I'm sure that there are many more things missing, but this driver does work
well for our hardware.
Note that I am using the register addresses instead of register names: the
datasheet containing the register descriptions is organized by register
address. Using names would make the datasheet lookup very hard. An attempt
was made to try and document what is being done when registers are used
instead.
Signed-off-by: Hans Verkuil
---
drivers/media/video/Kconfig | 12 +
drivers/media/video/Makefile|1 +
drivers/media/video/adv7604.c | 1959 +++
include/media/adv7604.h | 153 +++
include/media/v4l2-chip-ident.h |3 +
5 files changed, 2128 insertions(+)
create mode 100644 drivers/media/video/adv7604.c
create mode 100644 include/media/adv7604.h
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index d5df1fd..6d92d2d 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -284,6 +284,18 @@ config VIDEO_ADV7183
To compile this driver as a module, choose M here: the
module will be called adv7183.
+config VIDEO_ADV7604
+ tristate "Analog Devices ADV7604 decoder"
+ depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API
+ ---help---
+ Support for the Analog Devices ADV7604 video decoder.
+
+ This is a Analog Devices Component/Graphics Digitizer
+ with 4:1 Multiplexed HDMI Receiver.
+
+ To compile this driver as a module, choose M here: the
+ module will be called adv7604.
+
config VIDEO_BT819
tristate "BT819A VideoStream decoder"
depends on VIDEO_V4L2 && I2C
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index b7ada61..133dd9b 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -46,6 +46,7 @@ obj-$(CONFIG_VIDEO_ADV7180) += adv7180.o
obj-$(CONFIG_VIDEO_ADV7183) += adv7183.o
obj-$(CONFIG_VIDEO_ADV7343) += adv7343.o
obj-$(CONFIG_VIDEO_ADV7393) += adv7393.o
+obj-$(CONFIG_VIDEO_ADV7604) += adv7604.o
obj-$(CONFIG_VIDEO_VPX3220) += vpx3220.o
obj-$(CONFIG_VIDEO_VS6624) += vs6624.o
obj-$(CONFIG_VIDEO_BT819) += bt819.o
diff --git a/drivers/media/video/adv7604.c b/drivers/media/video/adv7604.c
new file mode 100644
index 000..109bc9b
--- /dev/null
+++ b/drivers/media/video/adv7604.c
@@ -0,0 +1,1959 @@
+/*
+ * adv7604 - Analog Devices ADV7604 video decoder driver
+ *
+ * Copyright 2012 Cisco Systems, Inc. and/or its affiliates. All rights
reserved.
+ *
+ * This program is free software; you may redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
+ * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
+ * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+ * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+ * SOFTWARE.
+ *
+ */
+
+/*
+ * References (c = chapter, p = page):
+ * REF_01 - Analog devices, ADV7604, Register Settings Recommendations,
+ * Revision 2.5, June 2010
+ * REF_02 - Analog devices, Register map documentation, Documentation of
+ * the register maps, Software manual, Rev. F, June 2010
+ * REF_03 - Analog devices, ADV7604, Hardware Manual, Rev. F, August 2010
+ */
+
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+static int debug;
+module_param(debug, int, 0644);
+MODULE_PARM_DESC(debug, "debug level (0-2)");
+
+MODULE_DESCRIPTION("Analog Devices ADV7604 video decoder driver");
+MODULE_AUTHOR("Hans Verkuil ");
+MODULE_AUTHOR("Mats Randgaard ");
+MODULE_LICENSE("GPL");
+
+/* ADV7604 system clock frequency */
+#define ADV7604_fsc (28636360)
+
+#define DIGITAL_INPUT ((state->prim_mode == ADV7604_PRIM_MODE_HDMI_COMP) || \
+ (state->prim_mode == ADV7604_PRIM_MODE_HDMI_GR))
+
+/*
+ **
+ *
+ * Arrays with configuration parameters for the ADV7604
+ *
+
[RFCv3 PATCH 8/8] ad9389b: driver for the Analog Devices AD9389B video encoder.
Initial version of this driver.
The full datasheets are available from the Analog Devices website:
http://ez.analog.com/docs/DOC-1741
Not all features of the receiver are supported by this driver for various
reasons. Most notably:
- No CEC support (the CEC API needs a lot more discussion)
- No HDCP repeater support (we don't use that either)
I'm sure that there are more things missing, but this driver does work
well for our hardware.
Note that I am using the register addresses instead of register names: the
datasheet containing the register descriptions is organized by register
address. Using names would make the datasheet lookup very hard. An attempt
was made to try and document what is being done when registers are used
instead.
Signed-off-by: Hans Verkuil
---
drivers/media/video/Kconfig | 11 +
drivers/media/video/Makefile|1 +
drivers/media/video/ad9389b.c | 1328 +++
include/media/ad9389b.h | 49 ++
include/media/v4l2-chip-ident.h |3 +
5 files changed, 1392 insertions(+)
create mode 100644 drivers/media/video/ad9389b.c
create mode 100644 include/media/ad9389b.h
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index 6d92d2d..f2b623d 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -483,6 +483,17 @@ config VIDEO_ADV7393
To compile this driver as a module, choose M here: the
module will be called adv7393.
+config VIDEO_AD9389B
+ tristate "Analog Devices AD9389B encoder"
+ depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API
+ ---help---
+ Support for the Analog Devices AD9389B video encoder.
+
+ This is a Analog Devices HDMI transmitter.
+
+ To compile this driver as a module, choose M here: the
+ module will be called ad9389b.
+
config VIDEO_AK881X
tristate "AK8813/AK8814 video encoders"
depends on I2C
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index 133dd9b..7cb5cef 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -47,6 +47,7 @@ obj-$(CONFIG_VIDEO_ADV7183) += adv7183.o
obj-$(CONFIG_VIDEO_ADV7343) += adv7343.o
obj-$(CONFIG_VIDEO_ADV7393) += adv7393.o
obj-$(CONFIG_VIDEO_ADV7604) += adv7604.o
+obj-$(CONFIG_VIDEO_AD9389B) += ad9389b.o
obj-$(CONFIG_VIDEO_VPX3220) += vpx3220.o
obj-$(CONFIG_VIDEO_VS6624) += vs6624.o
obj-$(CONFIG_VIDEO_BT819) += bt819.o
diff --git a/drivers/media/video/ad9389b.c b/drivers/media/video/ad9389b.c
new file mode 100644
index 000..c2886b6
--- /dev/null
+++ b/drivers/media/video/ad9389b.c
@@ -0,0 +1,1328 @@
+/*
+ * Analog Devices AD9389B/AD9889B video encoder driver
+ *
+ * Copyright 2012 Cisco Systems, Inc. and/or its affiliates. All rights
reserved.
+ *
+ * This program is free software; you may redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
+ * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
+ * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+ * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+ * SOFTWARE.
+ */
+
+/*
+ * References (c = chapter, p = page):
+ * REF_01 - Analog Devices, Programming Guide, AD9889B/AD9389B,
+ * HDMI Transitter, Rev. A, October 2010
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+static int debug;
+module_param(debug, int, 0644);
+MODULE_PARM_DESC(debug, "debug level (0-2)");
+
+MODULE_DESCRIPTION("Analog Devices AD9389B/AD9889B video encoder driver");
+MODULE_AUTHOR("Hans Verkuil ");
+MODULE_AUTHOR("Martin Bugge ");
+MODULE_LICENSE("GPL");
+
+#define MASK_AD9389B_EDID_RDY_INT 0x04
+#define MASK_AD9389B_MSEN_INT 0x40
+#define MASK_AD9389B_HPD_INT0x80
+
+#define MASK_AD9389B_HPD_DETECT 0x40
+#define MASK_AD9389B_MSEN_DETECT0x20
+#define MASK_AD9389B_EDID_RDY 0x10
+
+#define EDID_MAX_RETRIES (8)
+#define EDID_DELAY 250
+#define EDID_MAX_SEGM 8
+
+/*
+**
+*
+* Arrays with configuration parameters for the AD9389B
+*
+**
+*/
+
+struct i2c_reg_value {
+ u8 reg;
+ u8 value;
+};
+
+struct ad9389b_state_edid {
+ /* total number of blocks */
+ u32 blocks;
+ /* Number of segments read */
+ u32 segments;
+ u8 data[EDID_MAX_SEGM * 256];
+ /* Number of EDID read retries left */
+ unsigned read_retries;
+};
+
+struct ad9389
[Bug 41265] Radeon KMS does not work on thunderbolt media dock
https://bugs.freedesktop.org/show_bug.cgi?id=41265
--- Comment #26 from Alex Deucher 2012-08-10 13:50:54 UTC
---
(In reply to comment #25)
> i don't know why, but it don't get the VFCT Table.
> this returns false:
> (!ACPI_SUCCESS(acpi_get_table("VFCT", 1, &hdr)))
Then your system doesn't have the table.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
[PATCH] drm/usb: select USB_SUPPORT in Kconfig
On Fri, Aug 10, 2012 at 11:00:25AM +0530, Sachin Kamat wrote: > DRM_USB selects USB. However, USB depends on USB_SUPPORT and USB_ARCH_HAS_HCD. > Thus, selecting USB_SUPPORT in Kconfig avoids the following warning > (detected when DisplayLink was selected using exynos4_defconfig): > > warning: (MOUSE_APPLETOUCH && MOUSE_BCM5974 && MOUSE_SYNAPTICS_USB && > JOYSTICK_XPAD && TABLET_USB_ACECAD && TABLET_USB_AIPTEK && TABLET_USB_HANWANG > && TABLET_USB_KBTAB && TABLET_USB_WACOM && TOUCHSCREEN_USB_COMPOSITE && > INPUT_ATI_REMOTE2 && INPUT_KEYSPAN_REMOTE && INPUT_POWERMATE && INPUT_YEALINK > && INPUT_CM109 && RC_ATI_REMOTE && IR_IMON && IR_MCEUSB && IR_REDRAT3 && > IR_STREAMZAP && IR_IGUANA && DRM_USB) selects USB which has unmet direct > dependencies (USB_SUPPORT && USB_ARCH_HAS_HCD) > > Signed-off-by: Sachin Kamat > --- > drivers/gpu/drm/Kconfig |1 + > 1 files changed, 1 insertions(+), 0 deletions(-) > > diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig > index 23120c0..45536db 100644 > --- a/drivers/gpu/drm/Kconfig > +++ b/drivers/gpu/drm/Kconfig > @@ -23,6 +23,7 @@ config DRM_USB > tristate > depends on DRM > select USB > + select USB_SUPPORT User visible options shouldn't be selected. So instead of selecting all dependencies this should rather be: depends on USB Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
[PATCH 1/4] dma-buf: remove fallback for !CONFIG_DMA_SHARED_BUFFER
Documentation says that code requiring dma-buf should add it to
select, so inline fallbacks are not going to be used. A link error
will make it obvious what went wrong, instead of silently doing
nothing at runtime.
Signed-off-by: Maarten Lankhorst
---
include/linux/dma-buf.h | 99 ---
1 file changed, 99 deletions(-)
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index eb48f38..bd2e52c 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -156,7 +156,6 @@ static inline void get_dma_buf(struct dma_buf *dmabuf)
get_file(dmabuf->file);
}
-#ifdef CONFIG_DMA_SHARED_BUFFER
struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf,
struct device *dev);
void dma_buf_detach(struct dma_buf *dmabuf,
@@ -184,103 +183,5 @@ int dma_buf_mmap(struct dma_buf *, struct vm_area_struct
*,
unsigned long);
void *dma_buf_vmap(struct dma_buf *);
void dma_buf_vunmap(struct dma_buf *, void *vaddr);
-#else
-
-static inline struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf,
- struct device *dev)
-{
- return ERR_PTR(-ENODEV);
-}
-
-static inline void dma_buf_detach(struct dma_buf *dmabuf,
- struct dma_buf_attachment *dmabuf_attach)
-{
- return;
-}
-
-static inline struct dma_buf *dma_buf_export(void *priv,
-const struct dma_buf_ops *ops,
-size_t size, int flags)
-{
- return ERR_PTR(-ENODEV);
-}
-
-static inline int dma_buf_fd(struct dma_buf *dmabuf, int flags)
-{
- return -ENODEV;
-}
-
-static inline struct dma_buf *dma_buf_get(int fd)
-{
- return ERR_PTR(-ENODEV);
-}
-
-static inline void dma_buf_put(struct dma_buf *dmabuf)
-{
- return;
-}
-
-static inline struct sg_table *dma_buf_map_attachment(
- struct dma_buf_attachment *attach, enum dma_data_direction write)
-{
- return ERR_PTR(-ENODEV);
-}
-
-static inline void dma_buf_unmap_attachment(struct dma_buf_attachment *attach,
- struct sg_table *sg, enum dma_data_direction dir)
-{
- return;
-}
-
-static inline int dma_buf_begin_cpu_access(struct dma_buf *dmabuf,
- size_t start, size_t len,
- enum dma_data_direction dir)
-{
- return -ENODEV;
-}
-
-static inline void dma_buf_end_cpu_access(struct dma_buf *dmabuf,
- size_t start, size_t len,
- enum dma_data_direction dir)
-{
-}
-
-static inline void *dma_buf_kmap_atomic(struct dma_buf *dmabuf,
- unsigned long pnum)
-{
- return NULL;
-}
-
-static inline void dma_buf_kunmap_atomic(struct dma_buf *dmabuf,
-unsigned long pnum, void *vaddr)
-{
-}
-
-static inline void *dma_buf_kmap(struct dma_buf *dmabuf, unsigned long pnum)
-{
- return NULL;
-}
-
-static inline void dma_buf_kunmap(struct dma_buf *dmabuf,
- unsigned long pnum, void *vaddr)
-{
-}
-
-static inline int dma_buf_mmap(struct dma_buf *dmabuf,
- struct vm_area_struct *vma,
- unsigned long pgoff)
-{
- return -ENODEV;
-}
-
-static inline void *dma_buf_vmap(struct dma_buf *dmabuf)
-{
- return NULL;
-}
-
-static inline void dma_buf_vunmap(struct dma_buf *dmabuf, void *vaddr)
-{
-}
-#endif /* CONFIG_DMA_SHARED_BUFFER */
#endif /* __DMA_BUF_H__ */
[PATCH 2/4] dma-fence: dma-buf synchronization (v8 )
A dma-fence can be attached to a buffer which is being filled or consumed
by hw, to allow userspace to pass the buffer without waiting to another
device. For example, userspace can call page_flip ioctl to display the
next frame of graphics after kicking the GPU but while the GPU is still
rendering. The display device sharing the buffer with the GPU would
attach a callback to get notified when the GPU's rendering-complete IRQ
fires, to update the scan-out address of the display, without having to
wake up userspace.
A dma-fence is transient, one-shot deal. It is allocated and attached
to one or more dma-buf's. When the one that attached it is done, with
the pending operation, it can signal the fence.
+ dma_fence_signal()
The dma-buf-mgr handles tracking, and waiting on, the fences associated
with a dma-buf.
TODO maybe need some helper fxn for simple devices, like a display-
only drm/kms device which simply wants to wait for exclusive fence to
be signaled, and then attach a non-exclusive fence while scanout is in
progress.
The one pending on the fence can add an async callback:
+ dma_fence_add_callback()
The callback can optionally be cancelled with remove_wait_queue()
Or wait synchronously (optionally with timeout or interruptible):
+ dma_fence_wait()
A default software-only implementation is provided, which can be used
by drivers attaching a fence to a buffer when they have no other means
for hw sync. But a memory backed fence is also envisioned, because it
is common that GPU's can write to, or poll on some memory location for
synchronization. For example:
fence = dma_buf_get_fence(dmabuf);
if (fence->ops == &bikeshed_fence_ops) {
dma_buf *fence_buf;
dma_bikeshed_fence_get_buf(fence, &fence_buf, &offset);
... tell the hw the memory location to wait on ...
} else {
/* fall-back to sw sync * /
dma_fence_add_callback(fence, my_cb);
}
On SoC platforms, if some other hw mechanism is provided for synchronizing
between IP blocks, it could be supported as an alternate implementation
with it's own fence ops in a similar way.
To facilitate other non-sw implementations, the enable_signaling callback
can be used to keep track if a device not supporting hw sync is waiting
on the fence, and in this case should arrange to call dma_fence_signal()
at some point after the condition has changed, to notify other devices
waiting on the fence. If there are no sw waiters, this can be skipped to
avoid waking the CPU unnecessarily. The handler of the enable_signaling
op should take a refcount until the fence is signaled, then release its ref.
The intention is to provide a userspace interface (presumably via eventfd)
later, to be used in conjunction with dma-buf's mmap support for sw access
to buffers (or for userspace apps that would prefer to do their own
synchronization).
v1: Original
v2: After discussion w/ danvet and mlankhorst on #dri-devel, we decided
that dma-fence didn't need to care about the sw->hw signaling path
(it can be handled same as sw->sw case), and therefore the fence->ops
can be simplified and more handled in the core. So remove the signal,
add_callback, cancel_callback, and wait ops, and replace with a simple
enable_signaling() op which can be used to inform a fence supporting
hw->hw signaling that one or more devices which do not support hw
signaling are waiting (and therefore it should enable an irq or do
whatever is necessary in order that the CPU is notified when the
fence is passed).
v3: Fix locking fail in attach_fence() and get_fence()
v4: Remove tie-in w/ dma-buf.. after discussion w/ danvet and mlankorst
we decided that we need to be able to attach one fence to N dma-buf's,
so using the list_head in dma-fence struct would be problematic.
v5: [ Maarten Lankhorst ] Updated for dma-bikeshed-fence and dma-buf-manager.
v6: [ Maarten Lankhorst ] I removed dma_fence_cancel_callback and some comments
about checking if fence fired or not. This is broken by design.
waitqueue_active during destruction is now fatal, since the signaller
should be holding a reference in enable_signalling until it signalled
the fence. Pass the original dma_fence_cb along, and call __remove_wait
in the dma_fence_callback handler, so that no cleanup needs to be
performed.
v7: [ Maarten Lankhorst ] Set cb->func and only enable sw signaling if
fence wasn't signaled yet, for example for hardware fences that may
choose to signal blindly.
v8: [ Maarten Lankhorst ] Tons of tiny fixes, moved __dma_fence_init to
header and fixed include mess. dma-fence.h now includes dma-buf.h
All members are now initialized, so kmalloc can be used for
allocating a dma-fence. More documentation added.
Signed-off-by: Maarten Lankhorst
---
Documentation/DocBook/device-drivers.tmpl |2
drivers/base/Makefile |2
drivers/base/dma-fence.c | 268 +
[PATCH 3/4] dma-seqno-fence: Hardware dma-buf implementation of fencing (v2)
This type of fence can be used with hardware synchronization for simple
hardware that can block execution until the condition
(dma_buf[offset] - value) >= 0 has been met.
A software fallback still has to be provided in case the fence is used
with a device that doesn't support this mechanism. It is useful to expose
this for graphics cards that have an op to support this.
Some cards like i915 can export those, but don't have an option to wait,
so they need the software fallback.
I extended the original patch by Rob Clark.
v1: Original
v2: Renamed from bikeshed to seqno, moved into dma-fence.c since
not much was left of the file. Lots of documentation added.
Signed-off-by: Maarten Lankhorst
---
drivers/base/dma-fence.c | 21 +++
include/linux/dma-fence.h | 61 +
2 files changed, 82 insertions(+)
diff --git a/drivers/base/dma-fence.c b/drivers/base/dma-fence.c
index 93448e4..4092a58 100644
--- a/drivers/base/dma-fence.c
+++ b/drivers/base/dma-fence.c
@@ -266,3 +266,24 @@ struct dma_fence *dma_fence_create(void *priv)
return fence;
}
EXPORT_SYMBOL_GPL(dma_fence_create);
+
+static int seqno_enable_signaling(struct dma_fence *fence)
+{
+ struct dma_seqno_fence *seqno_fence = to_seqno_fence(fence);
+ return seqno_fence->enable_signaling(seqno_fence);
+}
+
+static void seqno_release(struct dma_fence *fence)
+{
+ struct dma_seqno_fence *f = to_seqno_fence(fence);
+
+ if (f->release)
+ f->release(f);
+ dma_buf_put(f->sync_buf);
+}
+
+const struct dma_fence_ops dma_seqno_fence_ops = {
+ .enable_signaling = seqno_enable_signaling,
+ .release = seqno_release
+};
+EXPORT_SYMBOL_GPL(dma_seqno_fence_ops);
diff --git a/include/linux/dma-fence.h b/include/linux/dma-fence.h
index e0ceddd..3ef0da0 100644
--- a/include/linux/dma-fence.h
+++ b/include/linux/dma-fence.h
@@ -91,6 +91,19 @@ struct dma_fence_ops {
void (*release)(struct dma_fence *fence);
};
+struct dma_seqno_fence {
+ struct dma_fence base;
+
+ struct dma_buf *sync_buf;
+ uint32_t seqno_ofs;
+ uint32_t seqno;
+
+ int (*enable_signaling)(struct dma_seqno_fence *fence);
+ void (*release)(struct dma_seqno_fence *fence);
+};
+
+extern const struct dma_fence_ops dma_seqno_fence_ops;
+
struct dma_fence *dma_fence_create(void *priv);
/**
@@ -121,4 +134,52 @@ int dma_fence_wait(struct dma_fence *fence, bool intr,
unsigned long timeout);
int dma_fence_add_callback(struct dma_fence *fence, struct dma_fence_cb *cb,
dma_fence_func_t func, void *priv);
+/**
+ * to_seqno_fence - cast a dma_fence to a dma_seqno_fence
+ * @fence: dma_fence to cast to a dma_seqno_fence
+ *
+ * Returns NULL if the dma_fence is not a dma_seqno_fence,
+ * or the dma_seqno_fence otherwise.
+ */
+static inline struct dma_seqno_fence *
+to_seqno_fence(struct dma_fence *fence)
+{
+ if (fence->ops != &dma_seqno_fence_ops)
+ return NULL;
+ return container_of(fence, struct dma_seqno_fence, base);
+}
+
+/**
+ * dma_seqno_fence_init - initialize a seqno fence
+ * @fence: dma_seqno_fence to initialize
+ * @sync_buf: buffer containing the memory location to signal on
+ * @seqno_ofs: the offset within @sync_buf
+ * @seqno: the sequence # to signal on
+ * @priv: value of priv member
+ * @enable_signaling: callback which is called when some other device is
+ *waiting for sw notification of fence
+ * @release: callback called during destruction before object is freed.
+ *
+ * This function initializes a struct dma_seqno_fence with passed parameters,
+ * and takes a reference on sync_buf which is released on fence destruction.
+ */
+static inline void
+dma_seqno_fence_init(struct dma_seqno_fence *fence,
+ struct dma_buf *sync_buf,
+ uint32_t seqno_ofs, uint32_t seqno, void *priv,
+ int (*enable_signaling)(struct dma_seqno_fence *),
+ void (*release)(struct dma_seqno_fence *))
+{
+ BUG_ON(!fence || !sync_buf || !enable_signaling);
+
+ __dma_fence_init(&fence->base, &dma_seqno_fence_ops, priv);
+
+ get_dma_buf(sync_buf);
+ fence->sync_buf = sync_buf;
+ fence->seqno_ofs = seqno_ofs;
+ fence->seqno = seqno;
+ fence->enable_signaling = enable_signaling;
+ fence->release = release;
+}
+
#endif /* __DMA_FENCE_H__ */
[PATCH 4/4] dma-buf-mgr: multiple dma-buf synchronization (v3)
Signed-off-by: Maarten Lankhorst dma-buf-mgr handles the case of reserving single or multiple dma-bufs while trying to prevent deadlocks from buffers being reserved simultaneously. For this to happen extra functions have been introduced: + dma_buf_reserve() + dma_buf_unreserve() + dma_buf_wait_unreserved() Reserve a single buffer, optionally with a sequence to indicate this is part of a multi-dmabuf reservation. This function will return -EDEADLK and return immediately if reserving would cause a deadlock. In case a single buffer is being reserved, no sequence is needed, otherwise please use the dmabufmgr calls. If you want to attach a exclusive dma-fence, you have to wait until all shared fences have signalled completion. If there are none, or if a shared fence has to be attached, wait until last exclusive fence has signalled completion. The new fence has to be attached before unreserving the buffer, and in exclusive mode all previous fences will have be removed from the buffer, and unreffed when done with it. dmabufmgr methods: + dmabufmgr_validate_init() This function inits a dmabufmgr_validate structure and appends it to the tail of the list, with refcount set to 1. + dmabufmgr_validate_put() Convenience function to unref and free a dmabufmgr_validate structure. However if it's used for custom callback signalling, a custom function should be implemented. + dmabufmgr_reserve_buffers() This function takes a linked list of dmabufmgr_validate's, each one requires the following members to be set by the caller: - validate->head, list head - validate->bo, must be set to the dma-buf to reserve. - validate->shared, set to true if opened in shared mode. - validate->priv, can be used by the caller to identify this buffer. This function will then set the following members on succesful completion: - validate->num_fences, amount of valid fences to wait on before this buffer can be accessed. This can be 0. - validate->fences[0...num_fences-1] fences to wait on + dmabufmgr_backoff_reservation() This can be used when the caller encounters an error between reservation and usage. No new fence will be attached and all reservations will be undone without side effects. + dmabufmgr_fence_buffer_objects Upon successful completion a new fence will have to be attached. This function releases old fences and attaches the new one. + dmabufmgr_wait_completed_cpu A simple cpu waiter convenience function. Waits until all fences have signalled completion before returning. The rationale of refcounting dmabufmgr_validate lies in the wait dma_fence_cb wait member. Before calling dma_fence_add_callback you should increase the refcount on dmabufmgr_validate with dmabufmgr_validate_get, and on signal completion you should call kref_put(&val->refcount, custom_free_signal); after all callbacks have added you drop the refcount by 1 also, when refcount drops to 0 all callbacks have been signalled, and dmabufmgr_validate has been waited on and can be freed. Since this will require atomic spinlocks to unlink the list and signal completion, a deadlock could occur if you try to call add_callback otherwise, so the refcount is used as a means of preventing this from occuring by having your custom free function take a device specific lock, removing from list and freeing the data. The nice/evil part about this is that this will also guarantee no memory leaks can occur behind your back. This allows delays completion by moving the dmabufmgr_validate list to be a part of the committed reservation. v1: Original version v2: Use dma-fence v3: Added refcounting to dmabufmgr-validate v4: Fixed dmabufmgr_wait_completed_cpu prototype, added more documentation and added Documentation/dma-buf-synchronization.txt --- Documentation/DocBook/device-drivers.tmpl |2 Documentation/dma-buf-synchronization.txt | 197 + drivers/base/Makefile |2 drivers/base/dma-buf-mgr.c| 277 + drivers/base/dma-buf.c| 114 include/linux/dma-buf-mgr.h | 121 + include/linux/dma-buf.h | 24 +++ 7 files changed, 736 insertions(+), 1 deletion(-) create mode 100644 Documentation/dma-buf-synchronization.txt create mode 100644 drivers/base/dma-buf-mgr.c create mode 100644 include/linux/dma-buf-mgr.h diff --git a/Documentation/DocBook/device-drivers.tmpl b/Documentation/DocBook/device-drivers.tmpl index 36252ac..2fc050c 100644 --- a/Documentation/DocBook/device-drivers.tmpl +++ b/Documentation/DocBook/device-drivers.tmpl @@ -128,6 +128,8 @@ X!Edrivers/base/interface.c !Edrivers/base/dma-buf.c !Edrivers/base/dma-fence.c !Iinclude/linux/dma-fence.h +!Edrivers/base/dma-buf-mgr.c +!Iinclude/linux/dma-buf-mgr.h !Edrivers/base/dma-coherent.c !Edrivers/base/dma-mapping.c diff --git a/Documentation/dma-buf-synchronization.txt b/Documentation/dma-buf-synchronization.txt new
[PATCH] staging: omapdrm: Remove unnecessary memcpy
On Thu, Aug 9, 2012 at 12:13 AM, Andy Gross wrote:
> Removed the unnecessary copy of the memory page addresses when
> programming the DMM/PAT and all support code for the lut copy.
> The original intent was to have this code in place for
> suspend/resume functionality w.r.t. DEVICE_OFF.
>
> Performance analysis showed that the extra copy from uncached memory
> led to a fairly hefty penalty when programming large 1D or 2D
> buffers. This can be implemented in a more efficient manner when we
> actually have to support DEVICE_OFF suspend/resume operations.
This patch itself is ok, but I'd like to wait a bit and merge this
together w/ a 2nd patch that handles saving the PAT state in the
suspend path.
BR,
-R
> Signed-off-by: Andy Gross
> ---
> drivers/staging/omapdrm/omap_dmm_priv.h |6 --
> drivers/staging/omapdrm/omap_dmm_tiler.c | 25 +
> 2 files changed, 1 insertions(+), 30 deletions(-)
>
> diff --git a/drivers/staging/omapdrm/omap_dmm_priv.h
> b/drivers/staging/omapdrm/omap_dmm_priv.h
> index 08b22e9..09ebc50 100644
> --- a/drivers/staging/omapdrm/omap_dmm_priv.h
> +++ b/drivers/staging/omapdrm/omap_dmm_priv.h
> @@ -141,9 +141,6 @@ struct refill_engine {
> /* only one trans per engine for now */
> struct dmm_txn txn;
>
> - /* offset to lut associated with container */
> - u32 *lut_offset;
> -
> wait_queue_head_t wait_for_refill;
>
> struct list_head idle_node;
> @@ -176,9 +173,6 @@ struct dmm {
> /* array of LUT - TCM containers */
> struct tcm **tcm;
>
> - /* LUT table storage */
> - u32 *lut;
> -
> /* allocation list and lock */
> struct list_head alloc_head;
> };
> diff --git a/drivers/staging/omapdrm/omap_dmm_tiler.c
> b/drivers/staging/omapdrm/omap_dmm_tiler.c
> index ec7a5c8..80d3f8a 100644
> --- a/drivers/staging/omapdrm/omap_dmm_tiler.c
> +++ b/drivers/staging/omapdrm/omap_dmm_tiler.c
> @@ -24,7 +24,6 @@
> #include
> #include
> #include
> -#include
> #include
> #include
> #include
> @@ -184,9 +183,6 @@ static int dmm_txn_append(struct dmm_txn *txn, struct
> pat_area *area,
> int columns = (1 + area->x1 - area->x0);
> int rows = (1 + area->y1 - area->y0);
> int i = columns*rows;
> - u32 *lut = omap_dmm->lut + (engine->tcm->lut_id * omap_dmm->lut_width
> *
> - omap_dmm->lut_height) +
> - (area->y0 * omap_dmm->lut_width) + area->x0;
>
> pat = alloc_dma(txn, sizeof(struct pat), &pat_pa);
>
> @@ -209,10 +205,6 @@ static int dmm_txn_append(struct dmm_txn *txn, struct
> pat_area *area,
> page_to_phys(pages[n]) : engine->dmm->dummy_pa;
> }
>
> - /* fill in lut with new addresses */
> - for (i = 0; i < rows; i++, lut += omap_dmm->lut_width)
> - memcpy(lut, &data[i*columns], columns * sizeof(u32));
> -
> txn->last_pat = pat;
>
> return 0;
> @@ -504,8 +496,6 @@ static int omap_dmm_remove(struct platform_device *dev)
> if (omap_dmm->dummy_page)
> __free_page(omap_dmm->dummy_page);
>
> - vfree(omap_dmm->lut);
> -
> if (omap_dmm->irq > 0)
> free_irq(omap_dmm->irq, omap_dmm);
>
> @@ -521,7 +511,7 @@ static int omap_dmm_probe(struct platform_device *dev)
> {
> int ret = -EFAULT, i;
> struct tcm_area area = {0};
> - u32 hwinfo, pat_geom, lut_table_size;
> + u32 hwinfo, pat_geom;
> struct resource *mem;
>
> omap_dmm = kzalloc(sizeof(*omap_dmm), GFP_KERNEL);
> @@ -593,16 +583,6 @@ static int omap_dmm_probe(struct platform_device *dev)
> */
> writel(0x7e7e7e7e, omap_dmm->base + DMM_PAT_IRQENABLE_SET);
>
> - lut_table_size = omap_dmm->lut_width * omap_dmm->lut_height *
> - omap_dmm->num_lut;
> -
> - omap_dmm->lut = vmalloc(lut_table_size * sizeof(*omap_dmm->lut));
> - if (!omap_dmm->lut) {
> - dev_err(&dev->dev, "could not allocate lut table\n");
> - ret = -ENOMEM;
> - goto fail;
> - }
> -
> omap_dmm->dummy_page = alloc_page(GFP_KERNEL | __GFP_DMA32);
> if (!omap_dmm->dummy_page) {
> dev_err(&dev->dev, "could not allocate dummy page\n");
> @@ -685,9 +665,6 @@ static int omap_dmm_probe(struct platform_device *dev)
> .p1.y = omap_dmm->container_height - 1,
> };
>
> - for (i = 0; i < lut_table_size; i++)
> - omap_dmm->lut[i] = omap_dmm->dummy_pa;
> -
> /* initialize all LUTs to dummy page entries */
> for (i = 0; i < omap_dmm->num_lut; i++) {
> area.tcm = omap_dmm->tcm[i];
> --
> 1.7.5.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majord
[Bug 53348] [855gm] GPU hang whilst playing Imperialism 2 under wine
https://bugs.freedesktop.org/show_bug.cgi?id=53348 Chris Wilson changed: What|Removed |Added AssignedTo|daniel at ffwll.ch |dri-devel at lists.freedesktop ||.org Summary|wine game: |[855gm] GPU hang whilst |intel_do_flush_locked |playing Imperialism 2 under |failed: Input/output error |wine Product|DRI |Mesa Version|unspecified |8.0 Component|DRM/Intel |Drivers/DRI/i830 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH 1/2] drm/radeon/dynpm: wait for fences on all rings when reclocking
From: Alex Deucher
1. Drop gui idle stuff, it's not as reliable as fences and only
covers the 3D engine.
2. Wait for fences on all rings. This makes sure all rings are
idle when reclocking.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_pm.c | 17 ++---
1 files changed, 6 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_pm.c
b/drivers/gpu/drm/radeon/radeon_pm.c
index 7ae6066..2c2c901 100644
--- a/drivers/gpu/drm/radeon/radeon_pm.c
+++ b/drivers/gpu/drm/radeon/radeon_pm.c
@@ -253,18 +253,13 @@ static void radeon_pm_set_clocks(struct radeon_device
*rdev)
down_write(&rdev->pm.mclk_lock);
mutex_lock(&rdev->ring_lock);
- /* gui idle int has issues on older chips it seems */
- if (rdev->family >= CHIP_R600) {
- if (rdev->irq.installed) {
- /* wait for GPU to become idle */
- radeon_irq_kms_wait_gui_idle(rdev);
- }
- } else {
- struct radeon_ring *ring =
&rdev->ring[RADEON_RING_TYPE_GFX_INDEX];
- if (ring->ready) {
- radeon_fence_wait_empty_locked(rdev,
RADEON_RING_TYPE_GFX_INDEX);
- }
+ /* wait for the rings to drain */
+ for (i = 0; i < RADEON_NUM_RINGS; i++) {
+ struct radeon_ring *ring = &rdev->ring[i];
+ if (ring->ready)
+ radeon_fence_wait_empty_locked(rdev, i);
}
+
radeon_unmap_vram_bos(rdev);
if (rdev->irq.installed) {
--
1.7.7.5
[PATCH 2/2] drm/radeon: remove gui_idle interrupt infrastructure
From: Alex Deucher
It was only used for dynpm, but has been replaced with
a better implementation using fences. Remove it.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/evergreen.c |5
drivers/gpu/drm/radeon/r100.c | 19 -
drivers/gpu/drm/radeon/r600.c |5
drivers/gpu/drm/radeon/radeon.h |4 ---
drivers/gpu/drm/radeon/radeon_device.c |1 -
drivers/gpu/drm/radeon/radeon_irq_kms.c | 33 ---
drivers/gpu/drm/radeon/rs600.c | 19 -
drivers/gpu/drm/radeon/si.c |5
8 files changed, 0 insertions(+), 91 deletions(-)
diff --git a/drivers/gpu/drm/radeon/evergreen.c
b/drivers/gpu/drm/radeon/evergreen.c
index e93b80a..90293c1 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -2541,10 +2541,6 @@ int evergreen_irq_set(struct radeon_device *rdev)
DRM_DEBUG("evergreen_irq_set: hdmi 5\n");
afmt6 |= AFMT_AZ_FORMAT_WTRIG_MASK;
}
- if (rdev->irq.gui_idle) {
- DRM_DEBUG("gui idle\n");
- grbm_int_cntl |= GUI_IDLE_INT_ENABLE;
- }
if (rdev->family >= CHIP_CAYMAN) {
cayman_cp_int_cntl_setup(rdev, 0, cp_int_cntl);
@@ -3079,7 +3075,6 @@ restart_ih:
break;
case 233: /* GUI IDLE */
DRM_DEBUG("IH: GUI idle\n");
- wake_up(&rdev->irq.idle_queue);
break;
default:
DRM_DEBUG("Unhandled interrupt: %d %d\n", src_id,
src_data);
diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
index 8acb34f..4774e50 100644
--- a/drivers/gpu/drm/radeon/r100.c
+++ b/drivers/gpu/drm/radeon/r100.c
@@ -698,9 +698,6 @@ int r100_irq_set(struct radeon_device *rdev)
if (atomic_read(&rdev->irq.ring_int[RADEON_RING_TYPE_GFX_INDEX])) {
tmp |= RADEON_SW_INT_ENABLE;
}
- if (rdev->irq.gui_idle) {
- tmp |= RADEON_GUI_IDLE_MASK;
- }
if (rdev->irq.crtc_vblank_int[0] ||
atomic_read(&rdev->irq.pflip[0])) {
tmp |= RADEON_CRTC_VBLANK_MASK;
@@ -737,12 +734,6 @@ static uint32_t r100_irq_ack(struct radeon_device *rdev)
RADEON_CRTC_VBLANK_STAT | RADEON_CRTC2_VBLANK_STAT |
RADEON_FP_DETECT_STAT | RADEON_FP2_DETECT_STAT;
- /* the interrupt works, but the status bit is permanently asserted */
- if (rdev->irq.gui_idle && radeon_gui_idle(rdev)) {
- if (!rdev->irq.gui_idle_acked)
- irq_mask |= RADEON_GUI_IDLE_STAT;
- }
-
if (irqs) {
WREG32(RADEON_GEN_INT_STATUS, irqs);
}
@@ -754,9 +745,6 @@ int r100_irq_process(struct radeon_device *rdev)
uint32_t status, msi_rearm;
bool queue_hotplug = false;
- /* reset gui idle ack. the status bit is broken */
- rdev->irq.gui_idle_acked = false;
-
status = r100_irq_ack(rdev);
if (!status) {
return IRQ_NONE;
@@ -769,11 +757,6 @@ int r100_irq_process(struct radeon_device *rdev)
if (status & RADEON_SW_INT_TEST) {
radeon_fence_process(rdev, RADEON_RING_TYPE_GFX_INDEX);
}
- /* gui idle interrupt */
- if (status & RADEON_GUI_IDLE_STAT) {
- rdev->irq.gui_idle_acked = true;
- wake_up(&rdev->irq.idle_queue);
- }
/* Vertical blank interrupts */
if (status & RADEON_CRTC_VBLANK_STAT) {
if (rdev->irq.crtc_vblank_int[0]) {
@@ -803,8 +786,6 @@ int r100_irq_process(struct radeon_device *rdev)
}
status = r100_irq_ack(rdev);
}
- /* reset gui idle ack. the status bit is broken */
- rdev->irq.gui_idle_acked = false;
if (queue_hotplug)
schedule_work(&rdev->hotplug_work);
if (rdev->msi_enabled) {
diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index d79c639..459c251 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -3088,10 +3088,6 @@ int r600_irq_set(struct radeon_device *rdev)
DRM_DEBUG("r600_irq_set: hdmi 0\n");
hdmi1 |= HDMI0_AZ_FORMAT_WTRIG_MASK;
}
- if (rdev->irq.gui_idle) {
- DRM_DEBUG("gui idle\n");
- grbm_int_cntl |= GUI_IDLE_INT_ENABLE;
- }
WREG32(CP_INT_CNTL, cp_int_cntl);
WREG32(DxMODE_INT_MASK, mode_int);
@@ -3475,7 +3471,6 @@ restart_ih:
break;
case 233: /* GUI IDLE */
DRM_DEBUG("IH: GUI idle\n");
- wake_up(&rdev->irq.idle_queue);
break;
default:
[Bug 41265] Radeon KMS does not work on thunderbolt media dock
https://bugs.freedesktop.org/show_bug.cgi?id=41265 --- Comment #27 from Alexander E. Patrakov 2012-08-10 17:44:00 UTC --- My Sony VAIO currently boots via MBR, in BIOS mode. There is nothing about UEFI in the BIOS setup screen. I am willing to convert the system and test the patch only if someone provides instructions how to test beforehand whether UEFI booting is supported on my system at all, without downloading files larger than 20 megabytes total. I have a 4gb USB flash drive with no important data that can be used as a test boot device. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 41265] Radeon KMS does not work on thunderbolt media dock
https://bugs.freedesktop.org/show_bug.cgi?id=41265 --- Comment #28 from Alex Deucher 2012-08-10 17:46:32 UTC --- If you are not using UEFI and the system supports legacy mode, then there's no need to try the patch. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[pull] radeon drm-fixes-3.6
From: Alex Deucher Hi Dave, This is the current set of radeon fixes for 3.6. Nothing too major. Highlights: - various display fixes - some SI fixes - new SI pci ids - major VM fix - CS checker support for MSAA I've tested on a number of cards across generations and noticed no problems. There is also a patch to implement vbios fetching on legacy free UEFI systems: https://bugs.freedesktop.org/show_bug.cgi?id=26891 The patch is posted there, but I'm waiting to hear back from the author. Look for that in a future pull. The following changes since commit d323748a8e6df3fb91872b73766e29da2f68b025: drm/edid: Fix potential memory leak in edid_load() (2012-08-09 10:10:37 +1000) are available in the git repository at: git://people.freedesktop.org/~agd5f/linux drm-fixes-3.6 Alex Deucher (9): drm/radeon: fix handling for ddc type 5 on combios drm/radeon/dce4+: set a more reasonable cursor watermark drm/radeon: properly handle SS overrides on TN (v2) drm/radeon: properly handle crtc powergating drm/radeon: fix bank tiling parameters on evergreen drm/radeon: fix bank tiling parameters on cayman drm/radeon: fix ordering in pll picking on dce4+ drm/radeon: add some new SI pci ids drm/radeon: fix some missing parens in asic macros Christian K?nig (1): drm/radeon: fix bank tiling parameters on SI Jerome Glisse (2): drm/radeon: do not reenable crtc after moving vram start address drm/radeon: fence virtual address and free it once idle v4 Marek Ol??k (3): drm/radeon/kms: reorder code in r600_check_texture_resource drm/radeon/kms: add MSAA texture support for r600-evergreen drm/radeon/kms: implement timestamp userspace query (v2) drivers/gpu/drm/radeon/atombios_crtc.c | 22 ++-- drivers/gpu/drm/radeon/evergreen.c | 71 -- drivers/gpu/drm/radeon/evergreen_cs.c |7 +++ drivers/gpu/drm/radeon/ni.c | 14 - drivers/gpu/drm/radeon/r600.c | 20 drivers/gpu/drm/radeon/r600_cs.c| 59 -- drivers/gpu/drm/radeon/r600d.h |3 + drivers/gpu/drm/radeon/radeon.h | 12 +++-- drivers/gpu/drm/radeon/radeon_asic.h| 10 ++-- drivers/gpu/drm/radeon/radeon_atombios.c| 49 ++- drivers/gpu/drm/radeon/radeon_combios.c | 57 ++ drivers/gpu/drm/radeon/radeon_cs.c | 32 +++- drivers/gpu/drm/radeon/radeon_cursor.c |6 ++- drivers/gpu/drm/radeon/radeon_device.c |1 + drivers/gpu/drm/radeon/radeon_drv.c |4 +- drivers/gpu/drm/radeon/radeon_gart.c| 24 - drivers/gpu/drm/radeon/radeon_gem.c | 13 + drivers/gpu/drm/radeon/radeon_kms.c | 35 +++-- drivers/gpu/drm/radeon/radeon_legacy_crtc.c |4 ++ drivers/gpu/drm/radeon/radeon_mode.h|1 + drivers/gpu/drm/radeon/radeon_object.c |6 +-- drivers/gpu/drm/radeon/rv515.c | 13 - drivers/gpu/drm/radeon/si.c | 35 -- drivers/gpu/drm/radeon/sid.h|3 + include/drm/drm_pciids.h|3 + include/drm/radeon_drm.h|2 + 26 files changed, 319 insertions(+), 187 deletions(-)
[Bug 53348] [855gm] GPU hang whilst playing Imperialism 2 under wine
https://bugs.freedesktop.org/show_bug.cgi?id=53348 --- Comment #1 from Bruno 2012-08-10 18:39:27 UTC --- Created attachment 65396 --> https://bugs.freedesktop.org/attachment.cgi?id=65396 i915_error_state with linux 3.5.1 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH] drm: EDID quirk improvements
OK, so using a period as the "magic" character to clear the list turns out to be a disastrously bad idea. (It works great everywhere except on the kernel command line.) New patch coming that uses at sign (@) instead.
[PATCH] drm: EDID quirk improvements
Add ability for user to add or remove EDID quirks, via module parameter or sysfs. Also add two new quirk flags -- EDID_QUIRK_DISABLE_INFOFRAMES and EDID_QUIRK_NO_AUDIO -- and adds a quirk for the LG L246WP display. Document module parameter and sysfs interface. --- Documentation/EDID/edid_quirks.txt | 161 +++ drivers/gpu/drm/drm_drv.c | 2 + drivers/gpu/drm/drm_edid.c | 527 + drivers/gpu/drm/drm_stub.c | 5 + drivers/gpu/drm/drm_sysfs.c| 19 ++ include/drm/drmP.h | 10 + include/drm/drm_edid.h | 13 +- 7 files changed, 676 insertions(+), 61 deletions(-) create mode 100644 Documentation/EDID/edid_quirks.txt diff --git a/Documentation/EDID/edid_quirks.txt b/Documentation/EDID/edid_quirks.txt new file mode 100644 index 000..256ded0 --- /dev/null +++ b/Documentation/EDID/edid_quirks.txt @@ -0,0 +1,161 @@ + EDID Quirks + = + Ian Pilcher + August 8, 2012 + + +"EDID blocks out in the wild have a variety of bugs" +-- from drivers/gpu/drm/drm_edid.c + + +Overview + + +EDID quirks provide a mechanism for working around display hardware with buggy +EDID data. + +An individual EDID quirk maps a display type (identified by its EDID +manufacturer ID and product code[1]) to a set of flags. For example, the current +list of quirks built into the kernel is: + +ACR:0xad46:0x0001 +API:0x7602:0x0001 +ACR:0x0977:0x0020 +MAX:0x05ec:0x0001 +MAX:0x077e:0x0001 +EPI:0xe780:0x0002 +EPI:0x2028:0x0001 +FCM:0x3520:0x000c +LPL:0x:0x0010 +LPL:0x2a00:0x0010 +PHL:0xe014:0x0020 +PTS:0x02fd:0x0020 +SAM:0x021d:0x0040 +SAM:0x0254:0x0001 +SAM:0x027e:0x0001 +VSC:0x139c:0x0080 +GSM:0x563f:0x0300 + +The first field of each quirk is the manufacturer ID, the second field is the +product code, and the third field is the quirk flags. + +NOTE: All of the manufacturer IDs above are displayed as 3-character strings, +because they are conformant IDs that have been properly encoded: + +- The most-significant bit of the encoded ID is 0 +- They only contain ASCII characters in the range A-Z + +IDs that do not conform to these rules are displayed as "raw" hexadecimal +values. + +The current quirk flags are: + +/* First detailed mode wrong, use largest 60Hz mode */ +#define EDID_QUIRK_PREFER_LARGE_60 0x0001 + +/* Reported 135MHz pixel clock is too high, needs adjustment */ +#define EDID_QUIRK_135_CLOCK_TOO_HIGH 0x0002 + +/* Prefer the largest mode at 75 Hz */ +#define EDID_QUIRK_PREFER_LARGE_75 0x0004 + +/* Detail timing is in cm not mm */ +#define EDID_QUIRK_DETAILED_IN_CM 0x0008 + +/* Detailed timing descriptors have bogus size values, so just take the + * maximum size and use that. + */ +#define EDID_QUIRK_DETAILED_USE_MAXIMUM_SIZE0x0010 + +/* Monitor forgot to set the first detailed is preferred bit. */ +#define EDID_QUIRK_FIRST_DETAILED_PREFERRED 0x0020 + +/* use +hsync +vsync for detailed mode */ +#define EDID_QUIRK_DETAILED_SYNC_PP 0x0040 + +/* Force reduced-blanking timings for detailed modes */ +#define EDID_QUIRK_FORCE_REDUCED_BLANKING 0x0080 + +/* Display is confused by InfoFrames; don't sent any */ +#define EDID_QUIRK_DISABLE_INFOFRAMES 0x0100 + +/* Display doesn't have any audio output */ +#define EDID_QUIRK_NO_AUDIO 0x0200 + + +sysfs interface +=== + +The current EDID quirk list can be read from /sys/class/drm/edid_quirks. + +The number of total "slots" in the list can be read from +/sys/class/drm/edid_quirks_size. This total includes both occupied slots (i.e. +the current list) and any slots available for additional quirks. The number of +available slots can be calculated by subtracting the number of quirks in the +current list from the total number of slots. + +If a slot is available, an additional quirk can be added to the list by writing +it to edid_quirks: + +# echo FOO:0x:0x100 > /sys/class/drm/edid_quirks + +Manufacturer IDs can also be specified numerically. (This is the only way to +specify a nonconformant ID.) This command is equivalent to the previous one: + +# echo 0x19ef:0x:0x100 > /sys/class/drm/edid_quirks + +Numeric values can also be specified in decimal or octal formats; a number that +begins with a 0 is assumed to be octal: + +# echo FOO:65535:0400 > /sys/class/drm/edid_quirks + +An existing quirk can be replaced by writing a new set of flags: + +# echo FOO:0x:0x200 > /sys/class/drm/edid_
[Linaro-mm-sig] [PATCH 1/4] dma-buf: remove fallback for !CONFIG_DMA_SHARED_BUFFER
On Fri, Aug 10, 2012 at 04:57:43PM +0200, Maarten Lankhorst wrote: > Documentation says that code requiring dma-buf should add it to > select, so inline fallbacks are not going to be used. A link error > will make it obvious what went wrong, instead of silently doing > nothing at runtime. > > Signed-off-by: Maarten Lankhorst I've botched it more than once to update these when creating new dma-buf code. Hence Reviewed-by: Daniel Vetter -- Daniel Vetter Mail: daniel at ffwll.ch Mobile: +41 (0)79 365 57 48
[Linaro-mm-sig] [PATCH 3/4] dma-seqno-fence: Hardware dma-buf implementation of fencing (v2)
On Fri, Aug 10, 2012 at 04:57:58PM +0200, Maarten Lankhorst wrote:
> This type of fence can be used with hardware synchronization for simple
> hardware that can block execution until the condition
> (dma_buf[offset] - value) >= 0 has been met.
>
> A software fallback still has to be provided in case the fence is used
> with a device that doesn't support this mechanism. It is useful to expose
> this for graphics cards that have an op to support this.
>
> Some cards like i915 can export those, but don't have an option to wait,
> so they need the software fallback.
>
> I extended the original patch by Rob Clark.
>
> v1: Original
> v2: Renamed from bikeshed to seqno, moved into dma-fence.c since
> not much was left of the file. Lots of documentation added.
>
> Signed-off-by: Maarten Lankhorst
Patch looks good, two bikesheds inline. Either way
Reviewed-by: Daniel Vetter
> ---
> drivers/base/dma-fence.c | 21 +++
> include/linux/dma-fence.h | 61
> +
> 2 files changed, 82 insertions(+)
>
> diff --git a/drivers/base/dma-fence.c b/drivers/base/dma-fence.c
> index 93448e4..4092a58 100644
> --- a/drivers/base/dma-fence.c
> +++ b/drivers/base/dma-fence.c
> @@ -266,3 +266,24 @@ struct dma_fence *dma_fence_create(void *priv)
> return fence;
> }
> EXPORT_SYMBOL_GPL(dma_fence_create);
> +
> +static int seqno_enable_signaling(struct dma_fence *fence)
> +{
> + struct dma_seqno_fence *seqno_fence = to_seqno_fence(fence);
> + return seqno_fence->enable_signaling(seqno_fence);
> +}
> +
> +static void seqno_release(struct dma_fence *fence)
> +{
> + struct dma_seqno_fence *f = to_seqno_fence(fence);
> +
> + if (f->release)
> + f->release(f);
> + dma_buf_put(f->sync_buf);
> +}
> +
> +const struct dma_fence_ops dma_seqno_fence_ops = {
> + .enable_signaling = seqno_enable_signaling,
> + .release = seqno_release
> +};
> +EXPORT_SYMBOL_GPL(dma_seqno_fence_ops);
> diff --git a/include/linux/dma-fence.h b/include/linux/dma-fence.h
> index e0ceddd..3ef0da0 100644
> --- a/include/linux/dma-fence.h
> +++ b/include/linux/dma-fence.h
> @@ -91,6 +91,19 @@ struct dma_fence_ops {
> void (*release)(struct dma_fence *fence);
> };
>
> +struct dma_seqno_fence {
> + struct dma_fence base;
> +
> + struct dma_buf *sync_buf;
> + uint32_t seqno_ofs;
> + uint32_t seqno;
> +
> + int (*enable_signaling)(struct dma_seqno_fence *fence);
> + void (*release)(struct dma_seqno_fence *fence);
I think using dma_fence_ops here is the better color. We lose type-safety
at compile-time, but still keep type-safety at runtime (thanks to
to_dma_seqno_fence). In addition people seem to like to constify function
pointers, we'd save a pointer and if we extend the sw dma_fence interface.
> +};
> +
> +extern const struct dma_fence_ops dma_seqno_fence_ops;
> +
> struct dma_fence *dma_fence_create(void *priv);
>
> /**
> @@ -121,4 +134,52 @@ int dma_fence_wait(struct dma_fence *fence, bool intr,
> unsigned long timeout);
> int dma_fence_add_callback(struct dma_fence *fence, struct dma_fence_cb *cb,
> dma_fence_func_t func, void *priv);
>
> +/**
> + * to_seqno_fence - cast a dma_fence to a dma_seqno_fence
> + * @fence: dma_fence to cast to a dma_seqno_fence
> + *
> + * Returns NULL if the dma_fence is not a dma_seqno_fence,
> + * or the dma_seqno_fence otherwise.
> + */
> +static inline struct dma_seqno_fence *
> +to_seqno_fence(struct dma_fence *fence)
> +{
> + if (fence->ops != &dma_seqno_fence_ops)
> + return NULL;
> + return container_of(fence, struct dma_seqno_fence, base);
> +}
I think adding an is_dma_seqno_fence would be nice ...
> +
> +/**
> + * dma_seqno_fence_init - initialize a seqno fence
> + * @fence: dma_seqno_fence to initialize
> + * @sync_buf: buffer containing the memory location to signal on
> + * @seqno_ofs: the offset within @sync_buf
> + * @seqno: the sequence # to signal on
> + * @priv: value of priv member
> + * @enable_signaling: callback which is called when some other device is
> + *waiting for sw notification of fence
> + * @release: callback called during destruction before object is freed.
> + *
> + * This function initializes a struct dma_seqno_fence with passed parameters,
> + * and takes a reference on sync_buf which is released on fence destruction.
> + */
> +static inline void
> +dma_seqno_fence_init(struct dma_seqno_fence *fence,
> + struct dma_buf *sync_buf,
> + uint32_t seqno_ofs, uint32_t seqno, void *priv,
> + int (*enable_signaling)(struct dma_seqno_fence *),
> + void (*release)(struct dma_seqno_fence *))
> +{
> + BUG_ON(!fence || !sync_buf || !enable_signaling);
> +
> + __dma_fence_init(&fence->base, &dma_seqno_fence_ops, priv);
> +
> + get_dma_buf(sync_buf);
> + fence->sync_buf = sync_buf;
> + fence->seqno_ofs = seqno_ofs
[Bug 44800] Radeon HD 6450 CAICOS screen corruption and kernel crashes
https://bugs.freedesktop.org/show_bug.cgi?id=44800 --- Comment #10 from Alexandre Demers 2012-08-10 20:07:23 UTC --- May or may not be related, but I've seen similar corruption with CAYMAN related to bug 45018 from time to time. But about comment 3, I was tempted to point at bug 42373. Marko, if you are willing to try patches proposed in both mentionned bugs to see if it helps in any way, that could be interesting. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Linaro-mm-sig] [PATCH 2/4] dma-fence: dma-buf synchronization (v8 )
On Fri, Aug 10, 2012 at 04:57:52PM +0200, Maarten Lankhorst wrote:
> A dma-fence can be attached to a buffer which is being filled or consumed
> by hw, to allow userspace to pass the buffer without waiting to another
> device. For example, userspace can call page_flip ioctl to display the
> next frame of graphics after kicking the GPU but while the GPU is still
> rendering. The display device sharing the buffer with the GPU would
> attach a callback to get notified when the GPU's rendering-complete IRQ
> fires, to update the scan-out address of the display, without having to
> wake up userspace.
>
> A dma-fence is transient, one-shot deal. It is allocated and attached
> to one or more dma-buf's. When the one that attached it is done, with
> the pending operation, it can signal the fence.
>
> + dma_fence_signal()
>
> The dma-buf-mgr handles tracking, and waiting on, the fences associated
> with a dma-buf.
>
> TODO maybe need some helper fxn for simple devices, like a display-
> only drm/kms device which simply wants to wait for exclusive fence to
> be signaled, and then attach a non-exclusive fence while scanout is in
> progress.
>
> The one pending on the fence can add an async callback:
> + dma_fence_add_callback()
> The callback can optionally be cancelled with remove_wait_queue()
>
> Or wait synchronously (optionally with timeout or interruptible):
> + dma_fence_wait()
>
> A default software-only implementation is provided, which can be used
> by drivers attaching a fence to a buffer when they have no other means
> for hw sync. But a memory backed fence is also envisioned, because it
> is common that GPU's can write to, or poll on some memory location for
> synchronization. For example:
>
> fence = dma_buf_get_fence(dmabuf);
> if (fence->ops == &bikeshed_fence_ops) {
> dma_buf *fence_buf;
> dma_bikeshed_fence_get_buf(fence, &fence_buf, &offset);
> ... tell the hw the memory location to wait on ...
> } else {
> /* fall-back to sw sync * /
> dma_fence_add_callback(fence, my_cb);
> }
>
> On SoC platforms, if some other hw mechanism is provided for synchronizing
> between IP blocks, it could be supported as an alternate implementation
> with it's own fence ops in a similar way.
>
> To facilitate other non-sw implementations, the enable_signaling callback
> can be used to keep track if a device not supporting hw sync is waiting
> on the fence, and in this case should arrange to call dma_fence_signal()
> at some point after the condition has changed, to notify other devices
> waiting on the fence. If there are no sw waiters, this can be skipped to
> avoid waking the CPU unnecessarily. The handler of the enable_signaling
> op should take a refcount until the fence is signaled, then release its ref.
>
> The intention is to provide a userspace interface (presumably via eventfd)
> later, to be used in conjunction with dma-buf's mmap support for sw access
> to buffers (or for userspace apps that would prefer to do their own
> synchronization).
I think the commit message should be cleaned up: Kill the TODO, rip out
the bikeshed_fence and otherwise update it to the latest code.
>
> v1: Original
> v2: After discussion w/ danvet and mlankhorst on #dri-devel, we decided
> that dma-fence didn't need to care about the sw->hw signaling path
> (it can be handled same as sw->sw case), and therefore the fence->ops
> can be simplified and more handled in the core. So remove the signal,
> add_callback, cancel_callback, and wait ops, and replace with a simple
> enable_signaling() op which can be used to inform a fence supporting
> hw->hw signaling that one or more devices which do not support hw
> signaling are waiting (and therefore it should enable an irq or do
> whatever is necessary in order that the CPU is notified when the
> fence is passed).
> v3: Fix locking fail in attach_fence() and get_fence()
> v4: Remove tie-in w/ dma-buf.. after discussion w/ danvet and mlankorst
> we decided that we need to be able to attach one fence to N dma-buf's,
> so using the list_head in dma-fence struct would be problematic.
> v5: [ Maarten Lankhorst ] Updated for dma-bikeshed-fence and dma-buf-manager.
> v6: [ Maarten Lankhorst ] I removed dma_fence_cancel_callback and some
> comments
> about checking if fence fired or not. This is broken by design.
> waitqueue_active during destruction is now fatal, since the signaller
> should be holding a reference in enable_signalling until it signalled
> the fence. Pass the original dma_fence_cb along, and call __remove_wait
> in the dma_fence_callback handler, so that no cleanup needs to be
> performed.
> v7: [ Maarten Lankhorst ] Set cb->func and only enable sw signaling if
> fence wasn't signaled yet, for example for hardware fences that may
> choose to signal blindly.
> v8: [ Maarten Lankhorst ] Tons of tiny fixes, moved __dma_fence_init to
> header and fixed
[PATCH 1/2] drm/radeon/dynpm: wait for fences on all rings when reclocking
On Fri, Aug 10, 2012 at 1:29 PM, wrote:
> From: Alex Deucher
>
> 1. Drop gui idle stuff, it's not as reliable as fences and only
> covers the 3D engine.
> 2. Wait for fences on all rings. This makes sure all rings are
> idle when reclocking.
>
> Signed-off-by: Alex Deucher
Reviewed-by: Jerome Glisse
> ---
> drivers/gpu/drm/radeon/radeon_pm.c | 17 ++---
> 1 files changed, 6 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_pm.c
> b/drivers/gpu/drm/radeon/radeon_pm.c
> index 7ae6066..2c2c901 100644
> --- a/drivers/gpu/drm/radeon/radeon_pm.c
> +++ b/drivers/gpu/drm/radeon/radeon_pm.c
> @@ -253,18 +253,13 @@ static void radeon_pm_set_clocks(struct radeon_device
> *rdev)
> down_write(&rdev->pm.mclk_lock);
> mutex_lock(&rdev->ring_lock);
>
> - /* gui idle int has issues on older chips it seems */
> - if (rdev->family >= CHIP_R600) {
> - if (rdev->irq.installed) {
> - /* wait for GPU to become idle */
> - radeon_irq_kms_wait_gui_idle(rdev);
> - }
> - } else {
> - struct radeon_ring *ring =
> &rdev->ring[RADEON_RING_TYPE_GFX_INDEX];
> - if (ring->ready) {
> - radeon_fence_wait_empty_locked(rdev,
> RADEON_RING_TYPE_GFX_INDEX);
> - }
> + /* wait for the rings to drain */
> + for (i = 0; i < RADEON_NUM_RINGS; i++) {
> + struct radeon_ring *ring = &rdev->ring[i];
> + if (ring->ready)
> + radeon_fence_wait_empty_locked(rdev, i);
> }
> +
> radeon_unmap_vram_bos(rdev);
>
> if (rdev->irq.installed) {
> --
> 1.7.7.5
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/radeon: remove gui_idle interrupt infrastructure
On Fri, Aug 10, 2012 at 1:29 PM, wrote:
> From: Alex Deucher
>
> It was only used for dynpm, but has been replaced with
> a better implementation using fences. Remove it.
>
> Signed-off-by: Alex Deucher
Reviewed-by: Jerome Glisse
> ---
> drivers/gpu/drm/radeon/evergreen.c |5
> drivers/gpu/drm/radeon/r100.c | 19 -
> drivers/gpu/drm/radeon/r600.c |5
> drivers/gpu/drm/radeon/radeon.h |4 ---
> drivers/gpu/drm/radeon/radeon_device.c |1 -
> drivers/gpu/drm/radeon/radeon_irq_kms.c | 33
> ---
> drivers/gpu/drm/radeon/rs600.c | 19 -
> drivers/gpu/drm/radeon/si.c |5
> 8 files changed, 0 insertions(+), 91 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/evergreen.c
> b/drivers/gpu/drm/radeon/evergreen.c
> index e93b80a..90293c1 100644
> --- a/drivers/gpu/drm/radeon/evergreen.c
> +++ b/drivers/gpu/drm/radeon/evergreen.c
> @@ -2541,10 +2541,6 @@ int evergreen_irq_set(struct radeon_device *rdev)
> DRM_DEBUG("evergreen_irq_set: hdmi 5\n");
> afmt6 |= AFMT_AZ_FORMAT_WTRIG_MASK;
> }
> - if (rdev->irq.gui_idle) {
> - DRM_DEBUG("gui idle\n");
> - grbm_int_cntl |= GUI_IDLE_INT_ENABLE;
> - }
>
> if (rdev->family >= CHIP_CAYMAN) {
> cayman_cp_int_cntl_setup(rdev, 0, cp_int_cntl);
> @@ -3079,7 +3075,6 @@ restart_ih:
> break;
> case 233: /* GUI IDLE */
> DRM_DEBUG("IH: GUI idle\n");
> - wake_up(&rdev->irq.idle_queue);
> break;
> default:
> DRM_DEBUG("Unhandled interrupt: %d %d\n", src_id,
> src_data);
> diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
> index 8acb34f..4774e50 100644
> --- a/drivers/gpu/drm/radeon/r100.c
> +++ b/drivers/gpu/drm/radeon/r100.c
> @@ -698,9 +698,6 @@ int r100_irq_set(struct radeon_device *rdev)
> if (atomic_read(&rdev->irq.ring_int[RADEON_RING_TYPE_GFX_INDEX])) {
> tmp |= RADEON_SW_INT_ENABLE;
> }
> - if (rdev->irq.gui_idle) {
> - tmp |= RADEON_GUI_IDLE_MASK;
> - }
> if (rdev->irq.crtc_vblank_int[0] ||
> atomic_read(&rdev->irq.pflip[0])) {
> tmp |= RADEON_CRTC_VBLANK_MASK;
> @@ -737,12 +734,6 @@ static uint32_t r100_irq_ack(struct radeon_device *rdev)
> RADEON_CRTC_VBLANK_STAT | RADEON_CRTC2_VBLANK_STAT |
> RADEON_FP_DETECT_STAT | RADEON_FP2_DETECT_STAT;
>
> - /* the interrupt works, but the status bit is permanently asserted */
> - if (rdev->irq.gui_idle && radeon_gui_idle(rdev)) {
> - if (!rdev->irq.gui_idle_acked)
> - irq_mask |= RADEON_GUI_IDLE_STAT;
> - }
> -
> if (irqs) {
> WREG32(RADEON_GEN_INT_STATUS, irqs);
> }
> @@ -754,9 +745,6 @@ int r100_irq_process(struct radeon_device *rdev)
> uint32_t status, msi_rearm;
> bool queue_hotplug = false;
>
> - /* reset gui idle ack. the status bit is broken */
> - rdev->irq.gui_idle_acked = false;
> -
> status = r100_irq_ack(rdev);
> if (!status) {
> return IRQ_NONE;
> @@ -769,11 +757,6 @@ int r100_irq_process(struct radeon_device *rdev)
> if (status & RADEON_SW_INT_TEST) {
> radeon_fence_process(rdev,
> RADEON_RING_TYPE_GFX_INDEX);
> }
> - /* gui idle interrupt */
> - if (status & RADEON_GUI_IDLE_STAT) {
> - rdev->irq.gui_idle_acked = true;
> - wake_up(&rdev->irq.idle_queue);
> - }
> /* Vertical blank interrupts */
> if (status & RADEON_CRTC_VBLANK_STAT) {
> if (rdev->irq.crtc_vblank_int[0]) {
> @@ -803,8 +786,6 @@ int r100_irq_process(struct radeon_device *rdev)
> }
> status = r100_irq_ack(rdev);
> }
> - /* reset gui idle ack. the status bit is broken */
> - rdev->irq.gui_idle_acked = false;
> if (queue_hotplug)
> schedule_work(&rdev->hotplug_work);
> if (rdev->msi_enabled) {
> diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
> index d79c639..459c251 100644
> --- a/drivers/gpu/drm/radeon/r600.c
> +++ b/drivers/gpu/drm/radeon/r600.c
> @@ -3088,10 +3088,6 @@ int r600_irq_set(struct radeon_device *rdev)
> DRM_DEBUG("r600_irq_set: hdmi 0\n");
> hdmi1 |= HDMI0_AZ_FORMAT_WTRIG_MASK;
> }
> - if (rdev->irq.gui_idle) {
> - DRM_DEBUG("gui idle\n");
> - grbm_int_cntl |= GUI_IDLE_INT_ENABLE;
> - }
>
> WREG32(CP_INT_CNTL, cp_int_cntl);
> WREG32(DxMODE
[PATCH] Consistently name interlaced modes
At the moment, there is an inconsistency in the way modes are named.
Modes with timings parsed from the EDID information will call
drm_mode_set_name(), which will name the mode using this form:
x
eg, 1920x1080i for an interlaced mode, or 1920x1080 for a progressive
mode.
However, timings parsed using the tables in drm_edid_modes.h do not
have the 'i' suffix. You are left to deduce that they're interlaced
from xrandr's output by the lower vertical refresh frequencies.
This patch changes the interlaced mode names in drm_edid_modes.h to
follow the style set by drm_mode_set_name(), which makes it clear
in xrandr which modes are interlaced and which are not (as xrandr
groups the refresh rates on a line according to the name field.)
Signed-off-by: Russell King
---
drivers/gpu/drm/drm_edid_modes.h | 42 +++
1 file changed, 21 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid_modes.h b/drivers/gpu/drm/drm_edid_modes.h
index ff98a7e..57459b3 100644
--- a/drivers/gpu/drm/drm_edid_modes.h
+++ b/drivers/gpu/drm/drm_edid_modes.h
@@ -89,7 +89,7 @@ static const struct drm_display_mode drm_dmt_modes[] = {
976, 1088, 0, 480, 486, 494, 517, 0,
DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC) },
/* 1024x768 at 43Hz, interlace */
- { DRM_MODE("1024x768", DRM_MODE_TYPE_DRIVER, 44900, 1024, 1032,
+ { DRM_MODE("1024x768i", DRM_MODE_TYPE_DRIVER, 44900, 1024, 1032,
1208, 1264, 0, 768, 768, 772, 817, 0,
DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC |
DRM_MODE_FLAG_INTERLACE) },
@@ -395,7 +395,7 @@ static const struct drm_display_mode edid_est_modes[] = {
{ DRM_MODE("1024x768", DRM_MODE_TYPE_DRIVER, 65000, 1024, 1048,
1184, 1344, 0, 768, 771, 777, 806, 0,
DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC) }, /* 1024x768
at 60Hz */
- { DRM_MODE("1024x768", DRM_MODE_TYPE_DRIVER,44900, 1024, 1032,
+ { DRM_MODE("1024x768i", DRM_MODE_TYPE_DRIVER,44900, 1024, 1032,
1208, 1264, 0, 768, 768, 776, 817, 0,
DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC |
DRM_MODE_FLAG_INTERLACE) }, /* 1024x768 at 43Hz */
{ DRM_MODE("832x624", DRM_MODE_TYPE_DRIVER, 57284, 832, 864,
@@ -506,17 +506,17 @@ static const struct drm_display_mode edid_cea_modes[] = {
1430, 1650, 0, 720, 725, 730, 750, 0,
DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC) },
/* 5 - 1920x1080i at 60Hz */
- { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 74250, 1920, 2008,
+ { DRM_MODE("1920x1080i", DRM_MODE_TYPE_DRIVER, 74250, 1920, 2008,
2052, 2200, 0, 1080, 1084, 1094, 1125, 0,
DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC |
DRM_MODE_FLAG_INTERLACE) },
/* 6 - 1440x480i at 60Hz */
- { DRM_MODE("1440x480", DRM_MODE_TYPE_DRIVER, 27000, 1440, 1478,
+ { DRM_MODE("1440x480i", DRM_MODE_TYPE_DRIVER, 27000, 1440, 1478,
1602, 1716, 0, 480, 488, 494, 525, 0,
DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC |
DRM_MODE_FLAG_INTERLACE | DRM_MODE_FLAG_DBLCLK) },
/* 7 - 1440x480i at 60Hz */
- { DRM_MODE("1440x480", DRM_MODE_TYPE_DRIVER, 27000, 1440, 1478,
+ { DRM_MODE("1440x480i", DRM_MODE_TYPE_DRIVER, 27000, 1440, 1478,
1602, 1716, 0, 480, 488, 494, 525, 0,
DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC |
DRM_MODE_FLAG_INTERLACE | DRM_MODE_FLAG_DBLCLK) },
@@ -531,12 +531,12 @@ static const struct drm_display_mode edid_cea_modes[] = {
DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC |
DRM_MODE_FLAG_DBLCLK) },
/* 10 - 2880x480i at 60Hz */
- { DRM_MODE("2880x480", DRM_MODE_TYPE_DRIVER, 54000, 2880, 2956,
+ { DRM_MODE("2880x480i", DRM_MODE_TYPE_DRIVER, 54000, 2880, 2956,
3204, 3432, 0, 480, 488, 494, 525, 0,
DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC |
DRM_MODE_FLAG_INTERLACE) },
/* 11 - 2880x480i at 60Hz */
- { DRM_MODE("2880x480", DRM_MODE_TYPE_DRIVER, 54000, 2880, 2956,
+ { DRM_MODE("2880x480i", DRM_MODE_TYPE_DRIVER, 54000, 2880, 2956,
3204, 3432, 0, 480, 488, 494, 525, 0,
DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC |
DRM_MODE_FLAG_INTERLACE) },
@@ -573,17 +573,17 @@ static const struct drm_display_mode edid_cea_modes[] = {
1760, 1980, 0, 720, 725, 730, 750, 0,
DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC) },
/* 20 - 1920x1080i at 50Hz */
- { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 74250, 1920, 2448,
+ { DRM_MODE("1920x1080i", DRM_MODE_TYPE_DRIVER, 74250, 1920, 2448,
2492, 2640, 0
[RFC PATCH 3/5] drm/i915: register LVDS connector even if we can't get a panel mode
On Mon, Aug 06, 2012 at 07:44:16AM +1000, Dave Airlie wrote:
> >> The "correct" approach is clearly to just have the drm core change the
> >> i2c mux before requesting edid, but that's made difficult because of the
> >> absence of ordering guarantees in initialisation. I don't like quirking
> >> this, since we're then back to the situation of potentially having to
> >> add every new piece of related hardware to the quirk list.
> >
> > The "correct" approach of switching the mux before we fetch the edid is
> > actualy the one I fear will result in fragile code: Only run on few
> > machines, and as you say with tons of funky interactions with the init
> > sequence ordering. And I guess people will bitch&moan about the flickering
> > this will cause ;-)
> >
> > As long as it's only apple shipping multi-gpu machines with
> > broken/non-existing vbt, I'll happily stomach the quirk list entries.
> > They're bad, but imo the lesser evil.
>
> Well in theory you can switch the ddc lines without switching the other lines,
> so we could do a mutex protected mux switch around edid retrival,
>
> Of course someone would have to code it up first then we could see how
> ugly it would be.
I coded it up, and it's not really too bad. I've put a dump of my local
changes below. But there are a couple of problems.
First, I don't have a solution for the ordering of initialization. It
just happens to work out for me right now.
Even so, the code only works if I delay loading i915. apple-gmux is
definitely initializing first so the i2c mux should be getting switched,
but the transactions are failing.
[ 19.445658] [drm:gmbus_xfer], GMBUS [i915 gmbus panel] timed out after NAK
[ 19.445672] [drm:gmbus_xfer], GMBUS [i915 gmbus panel] NAK for addr: 0050
r(1)
But if I prevent i915 from being auto-loaded and load later on it works
fine. I haven't been able to figure out what's going on. Any ideas?
Thanks,
Seth
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index a8743c3..3f18e8a 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -31,6 +31,7 @@
#include
#include
#include
+#include
#include "drmP.h"
#include "drm_edid.h"
#include "drm_edid_modes.h"
@@ -82,6 +83,8 @@ struct detailed_mode_closure {
#define LEVEL_GTF2 2
#define LEVEL_CVT 3
+static DEFINE_MUTEX(drm_edid_mutex);
+
static struct edid_quirk {
char vendor[4];
int product_id;
@@ -395,12 +398,25 @@ struct edid *drm_get_edid(struct drm_connector *connector,
struct i2c_adapter *adapter)
{
struct edid *edid = NULL;
+ struct pci_dev *pdev = connector->dev->pdev;
+ struct pci_dev *active_pdev = NULL;
+
+ mutex_lock(&drm_edid_mutex);
+
+ if (pdev) {
+ active_pdev = vga_switcheroo_get_active_client();
+ vga_switcheroo_switch_ddc(pdev);
+ }
if (drm_probe_ddc(adapter))
edid = (struct edid *)drm_do_get_edid(connector, adapter);
+ if (active_pdev)
+ vga_switcheroo_switch_ddc(active_pdev);
+
connector->display_info.raw_edid = (char *)edid;
+ mutex_unlock(&drm_edid_mutex);
return edid;
}
diff --git a/drivers/gpu/vga/vga_switcheroo.c b/drivers/gpu/vga/vga_switcheroo.c
index e25cf31..e53f67d 100644
--- a/drivers/gpu/vga/vga_switcheroo.c
+++ b/drivers/gpu/vga/vga_switcheroo.c
@@ -205,6 +205,20 @@ find_active_client(struct list_head *head)
return NULL;
}
+struct pci_dev *vga_switcheroo_get_active_client(void)
+{
+ struct vga_switcheroo_client *client;
+ struct pci_dev *pdev = NULL;
+
+ mutex_lock(&vgasr_mutex);
+ client = find_active_client(&vgasr_priv.clients);
+ if (client)
+ pdev = client->pdev;
+ mutex_unlock(&vgasr_mutex);
+ return pdev;
+}
+EXPORT_SYMBOL(vga_switcheroo_get_active_client);
+
int vga_switcheroo_get_client_state(struct pci_dev *pdev)
{
struct vga_switcheroo_client *client;
@@ -252,6 +266,29 @@ void vga_switcheroo_client_fb_set(struct pci_dev *pdev,
}
EXPORT_SYMBOL(vga_switcheroo_client_fb_set);
+int vga_switcheroo_switch_ddc(struct pci_dev *pdev)
+{
+ int ret = 0;
+ int id;
+
+ mutex_lock(&vgasr_mutex);
+
+ if (!vgasr_priv.handler) {
+ ret = -ENODEV;
+ goto out;
+ }
+
+ if (vgasr_priv.handler->switch_ddc) {
+ id = vgasr_priv.handler->get_client_id(pdev);
+ ret = vgasr_priv.handler->switch_ddc(id);
+ }
+
+out:
+ mutex_unlock(&vgasr_mutex);
+ return ret;
+}
+EXPORT_SYMBOL(vga_switcheroo_switch_ddc);
+
static int vga_switcheroo_show(struct seq_file *m, void *v)
{
struct vga_switcheroo_client *client;
@@ -342,9 +379,15 @@ static int vga_switchto_stage2(struct
vga_switcheroo_client *new_client)
fb_notifier_call_chain(FB_EVENT_REMAP_ALL_CONSOLE, &event);
}
+ if (vgasr_priv.handler->switch_ddc) {
+
