[PATCH v2 5/5] drm/exynos: Add plane support with fimd
The exynos fimd supports 5 window overlays. Only one window overlay of
fimd is used by the crtc, so we need plane feature to use the rest
window overlays.
This creates one ioctl exynos specific - DRM_EXYNOS_PLANE_SET_ZPOS, it
is the ioctl to decide for user to assign which window overlay.
Signed-off-by: Joonyoung Shim
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
v2: consider fixed point about src_x/src_y
drivers/gpu/drm/exynos/Makefile |3 +-
drivers/gpu/drm/exynos/exynos_drm_crtc.c|1 +
drivers/gpu/drm/exynos/exynos_drm_drv.c |9 ++
drivers/gpu/drm/exynos/exynos_drm_drv.h |8 +-
drivers/gpu/drm/exynos/exynos_drm_encoder.c | 26 -
drivers/gpu/drm/exynos/exynos_drm_encoder.h |2 +
drivers/gpu/drm/exynos/exynos_drm_fimd.c| 33 +--
drivers/gpu/drm/exynos/exynos_drm_plane.c | 156 +++
drivers/gpu/drm/exynos/exynos_drm_plane.h | 14 +++
include/drm/exynos_drm.h| 10 ++
10 files changed, 247 insertions(+), 15 deletions(-)
create mode 100644 drivers/gpu/drm/exynos/exynos_drm_plane.c
create mode 100644 drivers/gpu/drm/exynos/exynos_drm_plane.h
diff --git a/drivers/gpu/drm/exynos/Makefile b/drivers/gpu/drm/exynos/Makefile
index 0496d3f..c991272 100644
--- a/drivers/gpu/drm/exynos/Makefile
+++ b/drivers/gpu/drm/exynos/Makefile
@@ -5,7 +5,8 @@
ccflags-y := -Iinclude/drm -Idrivers/gpu/drm/exynos
exynosdrm-y := exynos_drm_drv.o exynos_drm_encoder.o exynos_drm_connector.o \
exynos_drm_crtc.o exynos_drm_fbdev.o exynos_drm_fb.o \
- exynos_drm_buf.o exynos_drm_gem.o exynos_drm_core.o
+ exynos_drm_buf.o exynos_drm_gem.o exynos_drm_core.o \
+ exynos_drm_plane.o
obj-$(CONFIG_DRM_EXYNOS) += exynosdrm.o
obj-$(CONFIG_DRM_EXYNOS_FIMD) += exynos_drm_fimd.o
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index a156f6c..7f22107 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -380,6 +380,7 @@ int exynos_drm_crtc_create(struct drm_device *dev, unsigned
int nr)
exynos_crtc->pipe = nr;
exynos_crtc->dpms = DRM_MODE_DPMS_OFF;
+ exynos_crtc->overlay.zpos = DEFAULT_ZPOS;
crtc = &exynos_crtc->drm_crtc;
private->crtc[nr] = crtc;
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index b86a04b..050684c 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -36,6 +36,7 @@
#include "exynos_drm_fbdev.h"
#include "exynos_drm_fb.h"
#include "exynos_drm_gem.h"
+#include "exynos_drm_plane.h"
#define DRIVER_NAME"exynos-drm"
#define DRIVER_DESC"Samsung SoC DRM"
@@ -77,6 +78,12 @@ static int exynos_drm_load(struct drm_device *dev, unsigned
long flags)
goto err_crtc;
}
+ for (nr = 0; nr < MAX_PLANE; nr++) {
+ ret = exynos_plane_init(dev, nr);
+ if (ret)
+ goto err_crtc;
+ }
+
ret = drm_vblank_init(dev, MAX_CRTC);
if (ret)
goto err_crtc;
@@ -163,6 +170,8 @@ static struct drm_ioctl_desc exynos_ioctls[] = {
DRM_AUTH),
DRM_IOCTL_DEF_DRV(EXYNOS_GEM_MMAP,
exynos_drm_gem_mmap_ioctl, DRM_UNLOCKED | DRM_AUTH),
+ DRM_IOCTL_DEF_DRV(EXYNOS_PLANE_SET_ZPOS, exynos_plane_set_zpos_ioctl,
+ DRM_UNLOCKED | DRM_AUTH),
};
static const struct file_operations exynos_drm_driver_fops = {
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index 8018798..8e8d8f0 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -33,6 +33,8 @@
#include "drm.h"
#define MAX_CRTC 2
+#define MAX_PLANE 5
+#define DEFAULT_ZPOS -1
struct drm_device;
struct exynos_drm_overlay;
@@ -57,8 +59,8 @@ enum exynos_drm_output_type {
struct exynos_drm_overlay_ops {
void (*mode_set)(struct device *subdrv_dev,
struct exynos_drm_overlay *overlay);
- void (*commit)(struct device *subdrv_dev);
- void (*disable)(struct device *subdrv_dev);
+ void (*commit)(struct device *subdrv_dev, int zpos);
+ void (*disable)(struct device *subdrv_dev, int zpos);
};
/*
@@ -83,6 +85,7 @@ struct exynos_drm_overlay_ops {
* @dma_addr: bus(accessed by dma) address to the memory region allocated
* for a overlay.
* @vaddr: virtual memory addresss to this overlay.
+ * @zpos: order of overlay layer(z position).
* @default_win: a window to be enabled.
* @color_key: color key on or off.
* @index_color: if using color key feature then this value would be used
@@ -111,6 +114,7 @@ struct exynos_drm_overlay {
unsigned int pitch;
dma_addr_t dma_addr;
void __iomem *vaddr;
+
Re: Black screen with AMD A4-3300 support
2011-12-13 14:03 keltezéssel, Joshua Roys írta: > On 12/13/2011 06:49 AM, Boszormenyi Zoltan wrote: >> I have a new ASUS K53TA notebook with AMD A4-3300 CPU >> and an extra Radeon HD6550M. I installed Fedora 16 on it but >> I get only black screen even during installation unless booted >> with nomodeset. But it's only VESA so there's no acceleration >> and there's no native LCD 1366x768 resolution, only 1024x768, >> so it's a bit blurry. >> > > Hello, > > Please see https://bugzilla.redhat.com/show_bug.cgi?id=753518 . (The HP > G4-1215DX also > has a AMD A4-3300.) After making the f16 kernel work, I ended up installing a > f17/rawhide kernel from > http://koji.fedoraproject.org/koji/packageinfo?packageID=8 to > fix other bugs, which will probably be the easiest solution for you. YES! Thankyouthankyouthankyou! :-) Now I have KMS. > I would be interested to hear if, after installing a newer kernel, > suspend/resume > worked for you. No, that doesn't work. I mean suspend works but not resume. There are a lot of reports in dmesg that looks like an Oops. Where should I report it? Here on the list or in RHBZ? Best regards, Zoltán Böszörményi ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: integer overflow in drm_mode_dirtyfb_ioctl()
- Original Message - > From: "Eugene Teo" > To: "Xi Wang" > Cc: "David Airlie" , dri-devel@lists.freedesktop.org, > linux-ker...@vger.kernel.org, > secur...@kernel.org, "Dave Airlie" > Sent: Wednesday, 14 December, 2011 1:16:49 PM > Subject: Re: [PATCH] drm: integer overflow in drm_mode_dirtyfb_ioctl() > > Cc'ed Dave's work email. This is already in Linus tree, went there a while ago. a5cd335165e31db9dbab636fd29895d41da55dd2 Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Black screen with AMD A4-3300 support
2011/12/14 Boszormenyi Zoltan : > 2011-12-13 14:03 keltezéssel, Joshua Roys írta: >> On 12/13/2011 06:49 AM, Boszormenyi Zoltan wrote: >>> I have a new ASUS K53TA notebook with AMD A4-3300 CPU >>> and an extra Radeon HD6550M. I installed Fedora 16 on it but >>> I get only black screen even during installation unless booted >>> with nomodeset. But it's only VESA so there's no acceleration >>> and there's no native LCD 1366x768 resolution, only 1024x768, >>> so it's a bit blurry. >>> >> >> Hello, >> >> Please see https://bugzilla.redhat.com/show_bug.cgi?id=753518 . (The HP >> G4-1215DX also >> has a AMD A4-3300.) After making the f16 kernel work, I ended up installing >> a >> f17/rawhide kernel from >> http://koji.fedoraproject.org/koji/packageinfo?packageID=8 to >> fix other bugs, which will probably be the easiest solution for you. > > YES! Thankyouthankyouthankyou! :-) Now I have KMS. > >> I would be interested to hear if, after installing a newer kernel, >> suspend/resume >> worked for you. > > No, that doesn't work. I mean suspend works but not resume. > There are a lot of reports in dmesg that looks like an Oops. > Where should I report it? Here on the list or in RHBZ? Please file a bug: https://bugs.freedesktop.org and select DRI, then DRM/Radeon. Alex ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [drm] [radeon] [3.1.4] slub memory corruption in drm_vblank_cleanup
On Wed, Dec 14, 2011 at 2:00 AM, batouzo wrote: > On 12/14/2011 12:47 AM, Jerome Glisse wrote: >> On Tue, Dec 13, 2011 at 6:46 PM, Jerome Glisse wrote: >>> On Tue, Dec 13, 2011 at 6:33 PM, batouzo wrote: On 12/14/2011 12:31 AM, Jerome Glisse wrote: >> Allocated in drm_vblank_init+0x139/0x260 [drm] + Freed in >> drm_vblank_cleanup+0x78/0x90 [drm] >> Allocated in drm_vblank_init+0xbe/0x260 [drm] + Freed in >> drm_vblank_cleanup+0x48/0x90 [drm] >> >> It is Amd Bulldozer computer, with Radeon card: >> 01:00.0 VGA compatible controller: ATI Technologies Inc Cedar PRO >> [Radeon HD 5450] >> >> messages: http://pastebin.com/NXN5EPtG >> config used: http://pastebin.com/AeVxEX7c > > Do you boot your kernel with kexec ? Does the patch help : Nope. Already seen that kexec bugfix on LKML but I start system normally not with kexec. > http://people.freedesktop.org/~glisse/0001-drm-radeon-disable-possible-GPU-writeback-early-v3.patch > If not please open bug on bugs.freedesktop.org against radeon driver. ok >>> >>> Note that this patch might also help non kexec case. >>> >>> Cheers, >>> Jerome >> >> Oh and try booting with radeon.no_wb=1 >> >> Cheers, >> Jerome > > Using that patch on 3.1.4 results in locking for 60 seconds on startup, > since it is now looking for firmware. > > This wait was not present without that patch. > > This looks familiar, like the 60 second wait when using netconsole > caused by netconsole attempt to look for NIC card firmware too early > (when / is not really mounted, just initramfs). > > I will report soon does it fix the crash; > > Though, the 60 second delay may influence the rarity of hitting BUG (it > was the case with netconsole's 60sec wait). > Should I just remove loading of this firmware? > Make sure the ucode is available in your initrd or kernel image or filesystem depending on how you are loading the driver. The driver has much more limited functionality without the ucode (no acceleration support, no interrupt support). You may not hit the bug at all due to the reduced functionality. Alex > > > > [ 1.386916] pci :03:06.0: calling quirk_usb_early_handoff+0x0/0x575 > [ 1.386918] pci :03:06.0: calling pci_fixup_video+0x0/0xa6 > [ 1.386925] PCI: CLS 64 bytes, default 64 > [ 1.387113] Unpacking initramfs... > [ 1.569824] Freeing initrd memory: 9080k freed > [ 1.572659] pci :00:00.2: PCI INT A -> GSI 55 (level, low) -> IRQ 55 > [ 1.572906] pci :00:00.2: irq 72 for MSI/MSI-X > [ 1.573088] AMD-Vi: Enabling IOMMU at :00:00.2 cap 0x40 > [ 1.634353] AMD-Vi: Lazy IO/TLB flushing enabled > [ 1.634387] PCI-DMA: Using software bounce buffering for IO (SWIOTLB) > [ 1.634421] Placing 64MB software IO TLB between 8800b9a5e000 - > 8800bda5e000 > [ 1.634456] software IO TLB at phys 0xb9a5e000 - 0xbda5e000 > [ 1.639283] audit: initializing netlink socket (disabled) > [ 1.639353] type=2000 audit(1323849178.636:1): initialized > [ 1.648286] HugeTLB registered 2 MB page size, pre-allocated 0 pages > [ 1.663115] VFS: Disk quotas dquot_6.5.2 > [ 1.663309] Dquot-cache hash table entries: 512 (order 0, 4096 bytes) > [ 1.663769] msgmni has been set to 7808 > [ 1.664318] Block layer SCSI generic (bsg) driver version 0.4 loaded > (major 253) > [ 1.664353] io scheduler noop registered > [ 1.664385] io scheduler deadline registered > [ 1.664684] io scheduler cfq registered (default) > [ 1.665691] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled > [ 1.667276] [drm] Initialized drm 1.1.0 20060810 > [ 1.667404] [drm] radeon defaulting to kernel modesetting. > [ 1.667436] [drm] radeon kernel modesetting enabled. > [ 1.667559] radeon :01:00.0: PCI INT A -> GSI 24 (level, low) -> > IRQ 24 > [ 1.667594] radeon :01:00.0: setting latency timer to 64 > [ 1.668367] [drm] initializing kernel modesetting (CEDAR > 0x1002:0x68F9 0x1458:0x21F1). > [ 1.668455] [drm] register mmio base: 0xFEA2 > [ 1.668487] [drm] register mmio size: 131072 > [ 1.668685] ATOM BIOS: GV > [ 1.668806] radeon :01:00.0: VRAM: 512M 0x - > 0x1FFF (512M used) > [ 1.668842] radeon :01:00.0: GTT: 512M 0x2000 - > 0x3FFF > [ 1.676059] [drm] Detected VRAM RAM=512M, BAR=256M > [ 1.676094] [drm] RAM width 64bits DDR > [ 1.676270] [TTM] Zone kernel: Available graphics memory: 1998922 kiB. > [ 1.676303] [TTM] Initializing pool allocator. > [ 1.676440] [drm] radeon: 512M of VRAM memory ready > [ 1.676476] [drm] radeon: 512M of GTT memory ready. > [ 1.676621] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). > [ 1.676655] [drm] Driver supports precise vblank timestamp query. > [ 1.676759] radeon :01:00.0: irq 73 for MSI/MSI-X > [ 1.676763] radeon :01:00.0: radeon: using MSI. > [ 1.676903] [drm
RE: [PATCH] drm: Enable reading 3D capabilities of 3D monitor
On Wed, 2011-12-14 at 13:04 +, Kavuri, Sateesh wrote:
> + /* Data block offset in CEA extension block */
> + start_offset = 4;
> + end_offset = edid_ext[2];
> +
> + /* 3D vars */
> + int multi_present = 0;
Pretty sure kernel style frowns upon mixed decls and code.
> + /*
> + * Because HDMI identifier is in Vendor Specific Block,
> + * search it from all data blocks of CEA extension.
> + */
> + for (i = start_offset; i < end_offset;
> + /* Increased by data block len */
> + i += ((edid_ext[i] & 0x1f) + 1)) {
> + /* Find vendor specific block */
> + /* 6'th bit is the VIDEO_PRESENT bit */
> + if ( ((edid_ext[i] >> 5) == VENDOR_BLOCK) &&
> + ((edid_ext[i+8] & 0x20) == MONITOR_VIDEO_PRESENT) ) {
This conditional will always be false:
if ((x == VENDOR_BLOCK) &&
((y & 0x20) == 0x01))
I suspect you want:
#define MONITOR_VIDEO_PRESENT (1 << 6)
...
if ((x == VENDOR_BLOCK) && (y & MONITOR_VIDEO_PRESENT)) {
...
> + hdmi_id = edid_ext[i + 1] | (edid_ext[i + 2] << 8) |
> + edid_ext[i + 3] << 16;
> + /* Find HDMI identifier */
> + if (hdmi_id == HDMI_IDENTIFIER)
> + is_hdmi = true;
> +
> + /* Check for the 3D_Present flag */
> + if ((edid_ext[i+13] >> 6) == PANEL_SUPPORTS_3D) {
> + caps = kmalloc(sizeof(struct
> drm_panel_3D_capabilities), GFP_KERNEL);
> + caps->panel_supports_3D = 1;
> + }
This will probably also not do what you want. Consider what happens if
edid_ext[i+13] has (1 << 7) set.
> + /* Check if 3D_Multi_present is set */
> + if ((edid_ext[i+13] & 0x60) == 0x0) {
> + multi_present = true;
> + }
Code and comment disagree.
> +
> + /* Collect 3D capabilities of the monitor */
> + int hdmi_3d_len = 0;
> + int hdmi_vic_len = 0;
> + hdmi_vic_len = (edid_ext[i+14] >> 0x05);
> + hdmi_3d_len = ((edid_ext[i+14] << 0x03) >>0x03);
> + int multi_val = edid_ext[i+13] & 0x6;
Note: multi_val can only have the values {0, 2, 4, 6} now.
> + if (multi_val == 0x0)
> + multi_present = NO_SPL_CAPS;
> + else if (multi_val == 0x1)
> + multi_present = STRUCTURE_PRESENT;
These two assignments (and the one above) are the only use of the
multi_present variable, it's never used in a subsequent conditional or
passed back to the caller.
The 'else' here can never be true, as noted above.
> + if ((multi_val == STRUCTURE_PRESENT) ||
> + (multi_val == STRUCTURE_MASK_PRESENT) ) {
> + if (edid_ext[i+15+hdmi_vic_len] & (1 << 0))
> + caps->format |= (1 << 0); /*
> FRAME_PACKING */
> + if (edid_ext[i+15+hdmi_vic_len] & (1 << 1))
> + caps->format |= (1 << 1);
> /*FIELD_ALTERNATIVE */
> + if (edid_ext[i+15+hdmi_vic_len] & (1 << 2))
> + caps->format |= (1 << 2); /*
> LINE_ALTERNATIVE */
> + if (edid_ext[i+15+hdmi_vic_len] & 0x3)
> + caps->format |= (1 << 3);
> /*SIDE_BY_SIDE_FULL */
> + if (edid_ext[i+15+hdmi_vic_len] & (1 << 4))
> + caps->format |= (1 << 4); /* L_DEPTH */
> + if (edid_ext[i+15+hdmi_vic_len] & 0x5)
> + caps->format |= (1 << 5); /*
> L_DEPTH_GFX_GFX_DEPTH */
> + if (edid_ext[i+15+hdmi_vic_len] & 0x6)
> + caps->format |= (1 << 6); /* TOP_BOTTOM
> */
> + if (edid_ext[i+14+hdmi_vic_len] & 0x7)
> + caps->format |= (1 << 7); /*
> S_BY_S_HALF */
> + if (edid_ext[i+14+hdmi_vic_len] & (1 << 8))
> + caps->format |= (1 << 8); /*
> S_BY_S_HALF_QUINCUNX */
> + }
Here you've made it clear that ->format is a bitfield, but the values
should be in a header (so drivers can use them) and this code should
only be using the symbolic names.
> @@ -1675,6 +1783,7 @@ static void drm_add_display_info(struct edid *edid,
> return;
>
> info->cea_rev = edid_ext[1];
> + info->caps_3D= drm_detect_3D_monitor(edid);
> }
>
> /**
Whitespace.
> +/* Pre-defined 3D formats as per HDMI spec */
> +enum s3d_format
[Bug 43829] New: Resuming my AMD A4-300 based laptop leaves the screen black
https://bugs.freedesktop.org/show_bug.cgi?id=43829 Bug #: 43829 Summary: Resuming my AMD A4-300 based laptop leaves the screen black Classification: Unclassified Product: DRI Version: XOrg CVS Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: DRM/Radeon AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: zbos...@pr.hu Created attachment 54422 --> https://bugs.freedesktop.org/attachment.cgi?id=54422 dmesg showing suspend/resume I have installed Fedora 16 on my new ASUS K53TA laptop that has these devices: # lspci 00:00.0 Host bridge: Advanced Micro Devices [AMD] Family 12h Processor Root Complex 00:01.0 VGA compatible controller: ATI Technologies Inc Device 9648 00:01.1 Audio device: ATI Technologies Inc Device 1714 00:02.0 PCI bridge: Advanced Micro Devices [AMD] Family 12h Processor Root Port 00:04.0 PCI bridge: Advanced Micro Devices [AMD] Family 12h Processor Root Port 00:05.0 PCI bridge: Advanced Micro Devices [AMD] Family 12h Processor Root Port 00:10.0 USB controller: Advanced Micro Devices [AMD] Hudson USB XHCI Controller (rev 03) 00:11.0 SATA controller: Advanced Micro Devices [AMD] Hudson SATA Controller [AHCI mode] (rev 40) 00:12.0 USB controller: Advanced Micro Devices [AMD] Hudson USB OHCI Controller (rev 11) 00:12.2 USB controller: Advanced Micro Devices [AMD] Hudson USB EHCI Controller (rev 11) 00:14.0 SMBus: Advanced Micro Devices [AMD] Hudson SMBus Controller (rev 13) 00:14.2 Audio device: Advanced Micro Devices [AMD] Hudson Azalia Controller (rev 01) 00:14.3 ISA bridge: Advanced Micro Devices [AMD] Hudson LPC Bridge (rev 11) 00:14.4 PCI bridge: Advanced Micro Devices [AMD] Hudson PCI Bridge (rev 40) 00:14.7 SD Host controller: Advanced Micro Devices [AMD] Hudson SD Flash Controller 00:18.0 Host bridge: Advanced Micro Devices [AMD] Family 12h/14h Processor Function 0 (rev 43) 00:18.1 Host bridge: Advanced Micro Devices [AMD] Family 12h/14h Processor Function 1 00:18.2 Host bridge: Advanced Micro Devices [AMD] Family 12h/14h Processor Function 2 00:18.3 Host bridge: Advanced Micro Devices [AMD] Family 12h/14h Processor Function 3 00:18.4 Host bridge: Advanced Micro Devices [AMD] Family 12h/14h Processor Function 4 00:18.5 Host bridge: Advanced Micro Devices [AMD] Family 12h/14h Processor Function 6 00:18.6 Host bridge: Advanced Micro Devices [AMD] Family 12h/14h Processor Function 5 00:18.7 Host bridge: Advanced Micro Devices [AMD] Family 12h/14h Processor Function 7 01:00.0 VGA compatible controller: ATI Technologies Inc Whistler [AMD Radeon HD 6600M Series] (rev ff) 02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 06) 03:00.0 Network controller: Atheros Communications Inc. AR9285 Wireless Network Adapter (PCI-Express) (rev 01) I had to install kernel-3.2.0-0.rc5.git1.1.fc17.x86_64 from Rawhide to make KMS work on the integrated video. I tried suspend/resume by closing the lid, suspend worked. Resume woke up the machine but left the screen black. dmesg for the suspend/resume is attached. -- 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: Black screen with AMD A4-3300 support
2011-12-14 15:02 keltezéssel, Alex Deucher írta: > 2011/12/14 Boszormenyi Zoltan : >> 2011-12-13 14:03 keltezéssel, Joshua Roys írta: >>> On 12/13/2011 06:49 AM, Boszormenyi Zoltan wrote: I have a new ASUS K53TA notebook with AMD A4-3300 CPU and an extra Radeon HD6550M. I installed Fedora 16 on it but I get only black screen even during installation unless booted with nomodeset. But it's only VESA so there's no acceleration and there's no native LCD 1366x768 resolution, only 1024x768, so it's a bit blurry. >>> Hello, >>> >>> Please see https://bugzilla.redhat.com/show_bug.cgi?id=753518 . (The HP >>> G4-1215DX also >>> has a AMD A4-3300.) After making the f16 kernel work, I ended up >>> installing a >>> f17/rawhide kernel from >>> http://koji.fedoraproject.org/koji/packageinfo?packageID=8 to >>> fix other bugs, which will probably be the easiest solution for you. >> YES! Thankyouthankyouthankyou! :-) Now I have KMS. >> >>> I would be interested to hear if, after installing a newer kernel, >>> suspend/resume >>> worked for you. >> No, that doesn't work. I mean suspend works but not resume. >> There are a lot of reports in dmesg that looks like an Oops. >> Where should I report it? Here on the list or in RHBZ? > Please file a bug: > https://bugs.freedesktop.org > and select DRI, then DRM/Radeon. > > Alex Done, bug #43829 Best regards, Zoltán Böszörményi ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [drm] [radeon] [3.1.4] slub memory corruption in drm_vblank_cleanup
On Wed, Dec 14, 2011 at 08:00:04AM +0100, batouzo wrote: > On 12/14/2011 12:47 AM, Jerome Glisse wrote: > > On Tue, Dec 13, 2011 at 6:46 PM, Jerome Glisse wrote: > >> On Tue, Dec 13, 2011 at 6:33 PM, batouzo wrote: > >>> On 12/14/2011 12:31 AM, Jerome Glisse wrote: > >>> > > Allocated in drm_vblank_init+0x139/0x260 [drm] + Freed in > > drm_vblank_cleanup+0x78/0x90 [drm] > > Allocated in drm_vblank_init+0xbe/0x260 [drm] + Freed in > > drm_vblank_cleanup+0x48/0x90 [drm] > > > > It is Amd Bulldozer computer, with Radeon card: > > 01:00.0 VGA compatible controller: ATI Technologies Inc Cedar PRO > > [Radeon HD 5450] > > > >messages: http://pastebin.com/NXN5EPtG > > config used: http://pastebin.com/AeVxEX7c > >>> > > Do you boot your kernel with kexec ? Does the patch help : > >>> > >>> Nope. Already seen that kexec bugfix on LKML but I start system normally > >>> not with kexec. > >>> > http://people.freedesktop.org/~glisse/0001-drm-radeon-disable-possible-GPU-writeback-early-v3.patch > If not please open bug on bugs.freedesktop.org against radeon driver. > >>> > >>> ok > >>> > >> > >> Note that this patch might also help non kexec case. > >> > >> Cheers, > >> Jerome > > > > Oh and try booting with radeon.no_wb=1 > > > > Cheers, > > Jerome > > Using that patch on 3.1.4 results in locking for 60 seconds on startup, > since it is now looking for firmware. > > This wait was not present without that patch. > > This looks familiar, like the 60 second wait when using netconsole > caused by netconsole attempt to look for NIC card firmware too early > (when / is not really mounted, just initramfs). > > I will report soon does it fix the crash; > > Though, the 60 second delay may influence the rarity of hitting BUG (it > was the case with netconsole's 60sec wait). > Should I just remove loading of this firmware? > That patch doesn't change anything in regard of firmware. You need firmware for GPU to be use otherwise kms is just a fancy framebuffer driver. Cheers, Jerome ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [drm] [radeon] [3.1.4] slub memory corruption in drm_vblank_cleanup
On 12/14/2011 03:10 PM, Alex Deucher wrote: >> Though, the 60 second delay may influence the rarity of hitting BUG (it >> was the case with netconsole's 60sec wait). >> Should I just remove loading of this firmware? >> > Make sure the ucode is available in your initrd or kernel image or > filesystem depending on how you are loading the driver. The driver > has much more limited functionality without the ucode (no acceleration > support, no interrupt support). You may not hit the bug at all due to > the reduced functionality. Actually, where is that file? Can't find CEDAR_pfp.bin or even any "*CEDAR*" in entire filesystem where I build the kernel. Also I tried CONFIG_FIRMWARE_IN_KERNEL=y but it didn't helped, hm. >> [ 62.347154] r600_cp: Failed to load firmware "radeon/CEDAR_pfp.bin" >> [ 62.347189] [drm:evergreen_startup] *ERROR* Failed to load firmware! >> [ 62.347222] radeon :01:00.0: disabling GPU acceleration ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [drm] [radeon] [3.1.4] slub memory corruption in drm_vblank_cleanup
On Wed, Dec 14, 2011 at 11:32 AM, batouzo wrote: > On 12/14/2011 03:10 PM, Alex Deucher wrote: > >>> Though, the 60 second delay may influence the rarity of hitting BUG (it >>> was the case with netconsole's 60sec wait). >>> Should I just remove loading of this firmware? >>> >> Make sure the ucode is available in your initrd or kernel image or >> filesystem depending on how you are loading the driver. The driver >> has much more limited functionality without the ucode (no acceleration >> support, no interrupt support). You may not hit the bug at all due to >> the reduced functionality. > > Actually, where is that file? Can't find CEDAR_pfp.bin or even any > "*CEDAR*" in entire filesystem where I build the kernel. > > Also I tried CONFIG_FIRMWARE_IN_KERNEL=y > but it didn't helped, hm. > You need to grab them from here: http://git.kernel.org/?p=linux/kernel/git/dwmw2/linux-firmware.git Alex > >>> [ 62.347154] r600_cp: Failed to load firmware "radeon/CEDAR_pfp.bin" >>> [ 62.347189] [drm:evergreen_startup] *ERROR* Failed to load firmware! >>> [ 62.347222] radeon :01:00.0: disabling GPU acceleration > > > ___ > 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 43835] New: System crashes when radeon firmware blob (R520_cp.bin) is installed
https://bugs.freedesktop.org/show_bug.cgi?id=43835
Bug #: 43835
Summary: System crashes when radeon firmware blob (R520_cp.bin)
is installed
Classification: Unclassified
Product: DRI
Version: XOrg CVS
Platform: Other
URL: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=65153
2
OS/Version: All
Status: NEW
Severity: normal
Priority: medium
Component: DRM/Radeon
AssignedTo: dri-devel@lists.freedesktop.org
ReportedBy: noela...@gmail.com
Created attachment 54426
--> https://bugs.freedesktop.org/attachment.cgi?id=54426
Logs ("dmesg" and "xorg.0.log" for kernels 3.2-rc4 and 3.1 with and without the
firmware installed)
1. Steps to reproduce the problem
Running Debian Wheezy, by installing the package "firmware-linux-nonfree" which
contains the firmware to enable 3D acceleration for the ATI card (M56P Radeon
Mobility X1600), when the system starts and user logins, the system crashes (no
specific action triggers the crash, is just about time to get it).
2. Symptoms
The user receives a "kernel oops" (kernel 3.1) or system hangs with a trace
(kernel 3.2-rc4) and system locks.
3. Tested kernels
The user has tested kernel 3.1 (Wheezy's stock kernel) and 3.2-rc4 (from
Debian's experimental branch). Both kernels expose the same result when
firmware is installed. On the other hand, both kernels work fine as soon as the
firmware package is unistalled.
4. Additional information
The crash has been tracked in Debian BTS #651532 (full link available in the
URL field).
5. Attached logs (4 files):
- "dmesg" and "Xorg.0.log" for kernels 3.2-rc4 and 3.1 when firmware is
installed.
- "dmesg" and "Xorg.0.log" for kernels 3.2-rc4 and 3.1 when firmware is not
installed.
6. Other considerations
Please, note that I am opening the this bug on behalf of another person who is
experiencing the crash. For this reason I'm CC'ing to him.
--
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: [drm] [radeon] [3.1.4] slub memory corruption in drm_vblank_cleanup
On 12/14/2011 05:40 PM, Alex Deucher wrote: > On Wed, Dec 14, 2011 at 11:32 AM, batouzo wrote: >> On 12/14/2011 03:10 PM, Alex Deucher wrote: >> Though, the 60 second delay may influence the rarity of hitting BUG (it was the case with netconsole's 60sec wait). Should I just remove loading of this firmware? >>> Make sure the ucode is available in your initrd or kernel image or >>> filesystem depending on how you are loading the driver. The driver >>> has much more limited functionality without the ucode (no acceleration >>> support, no interrupt support). You may not hit the bug at all due to >>> the reduced functionality. >> >> Actually, where is that file? Can't find CEDAR_pfp.bin or even any >> "*CEDAR*" in entire filesystem where I build the kernel. >> >> Also I tried CONFIG_FIRMWARE_IN_KERNEL=y >> but it didn't helped, hm. >> > > You need to grab them from here: > http://git.kernel.org/?p=linux/kernel/git/dwmw2/linux-firmware.git Ok I see. Is there a pubkey signed version of that available, or what is the safe-download procedure (as with kernl.org .tar's + .sign for kernels)? ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: integer overflow in drm_mode_dirtyfb_ioctl()
On Wed, Dec 14, 2011 at 08:34:29AM -0500, David Airlie wrote: > > - Original Message - > > From: "Eugene Teo" > > To: "Xi Wang" > > Cc: "David Airlie" , dri-devel@lists.freedesktop.org, > > linux-ker...@vger.kernel.org, > > secur...@kernel.org, "Dave Airlie" > > Sent: Wednesday, 14 December, 2011 1:16:49 PM > > Subject: Re: [PATCH] drm: integer overflow in drm_mode_dirtyfb_ioctl() > > > > Cc'ed Dave's work email. > > This is already in Linus tree, went there a while ago. > > a5cd335165e31db9dbab636fd29895d41da55dd2 And it was in the 3.0.13 and 3.1.5 kernel releases. greg k-h ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 43835] System crashes when radeon firmware blob (R520_cp.bin) is installed
https://bugs.freedesktop.org/show_bug.cgi?id=43835 --- Comment #1 from Alex Deucher 2011-12-14 09:19:34 PST --- In the future, please attach the dmesg and log files directly. It looks like it's a problem with acceleration (which is available without the firmware). I don't see any oops or backtraces in the logs. Can you attach the oops or get a picture of it? Does setting: Option "NoAccel" "True" in the device section of your xorg.conf fix the problem? -- 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: [drm] [radeon] [3.1.4] slub memory corruption in drm_vblank_cleanup
On Wed, Dec 14, 2011 at 12:12 PM, batouzo wrote: > On 12/14/2011 05:40 PM, Alex Deucher wrote: >> On Wed, Dec 14, 2011 at 11:32 AM, batouzo wrote: >>> On 12/14/2011 03:10 PM, Alex Deucher wrote: >>> > Though, the 60 second delay may influence the rarity of hitting BUG (it > was the case with netconsole's 60sec wait). > Should I just remove loading of this firmware? > Make sure the ucode is available in your initrd or kernel image or filesystem depending on how you are loading the driver. The driver has much more limited functionality without the ucode (no acceleration support, no interrupt support). You may not hit the bug at all due to the reduced functionality. >>> >>> Actually, where is that file? Can't find CEDAR_pfp.bin or even any >>> "*CEDAR*" in entire filesystem where I build the kernel. >>> >>> Also I tried CONFIG_FIRMWARE_IN_KERNEL=y >>> but it didn't helped, hm. >>> >> >> You need to grab them from here: >> http://git.kernel.org/?p=linux/kernel/git/dwmw2/linux-firmware.git > > Ok I see. > > Is there a pubkey signed version of that available, or what is the > safe-download procedure (as with kernl.org .tar's + .sign for kernels)? > You can download/compare with my tree: http://people.freedesktop.org/~agd5f/radeon_ucode/ Alex > ___ > 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 43835] System crashes when radeon firmware blob (R520_cp.bin) is installed
https://bugs.freedesktop.org/show_bug.cgi?id=43835 --- Comment #2 from Alex Deucher 2011-12-14 09:22:37 PST --- which is NOT available without the firmware -- 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 v2 5/5] drm/exynos: Add plane support with fimd
On Wed, 14 Dec 2011 19:00:15 +0900 Joonyoung Shim wrote: > The exynos fimd supports 5 window overlays. Only one window overlay of > fimd is used by the crtc, so we need plane feature to use the rest > window overlays. > > This creates one ioctl exynos specific - DRM_EXYNOS_PLANE_SET_ZPOS, it > is the ioctl to decide for user to assign which window overlay. > > Signed-off-by: Joonyoung Shim > Signed-off-by: Inki Dae > Signed-off-by: Kyungmin Park > --- > v2: consider fixed point about src_x/src_y Looks pretty good; the only thing that jumped out was that you don't seem to be validating the zpos ioctl parameters for sanity. Not sure if there's much to do, but it may be worth checking for a max zpos or something... -- Jesse Barnes, Intel Open Source Technology Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[git pull] drm fixes
Hi Linus, simple one just one pci ids patch from Alex, I know Keith has some patches outstanding in his queue and I know they are probably more than you'll want to merge at this point, I'm off until next week, so Keith if you do send a pull request you may as well send to Linus, since I know Linus can be more lenient on pulls which make the hw he uses suck less :-) The following changes since commit 45e713efe2fa574b6662e7fb63fae9497c5e03d4: Merge branch 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip (2011-12-05 16:54:15 -0800) are available in the git repository at: git://people.freedesktop.org/~airlied/linux drm-fixes Alex Deucher (1): drm/radeon/kms: fix return type for radeon_encoder_get_dp_bridge_encoder_id Daniel Vetter (1): drm/i915: fix infinite recursion on unbind due to ilk vt-d w/a Thomas Meyer (1): vmwgfx: Use kcalloc instead of kzalloc to allocate array drivers/gpu/drm/i915/i915_gem.c |7 ++- drivers/gpu/drm/radeon/radeon_encoders.c |7 +++ drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c|4 ++-- 3 files changed, 11 insertions(+), 7 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [drm] [radeon] [3.1.4] slub memory corruption in drm_vblank_cleanup
On 12/14/2011 06:21 PM, Alex Deucher wrote: > On Wed, Dec 14, 2011 at 12:12 PM, batouzo wrote: >> On 12/14/2011 05:40 PM, Alex Deucher wrote: >>> On Wed, Dec 14, 2011 at 11:32 AM, batouzo wrote: On 12/14/2011 03:10 PM, Alex Deucher wrote: >> Though, the 60 second delay may influence the rarity of hitting BUG (it >> was the case with netconsole's 60sec wait). >> Should I just remove loading of this firmware? >> > Make sure the ucode is available in your initrd or kernel image or > filesystem depending on how you are loading the driver. The driver > has much more limited functionality without the ucode (no acceleration > support, no interrupt support). You may not hit the bug at all due to > the reduced functionality. Actually, where is that file? Can't find CEDAR_pfp.bin or even any "*CEDAR*" in entire filesystem where I build the kernel. Also I tried CONFIG_FIRMWARE_IN_KERNEL=y but it didn't helped, hm. >>> >>> You need to grab them from here: >>> http://git.kernel.org/?p=linux/kernel/git/dwmw2/linux-firmware.git >> >> Ok I see. >> >> Is there a pubkey signed version of that available, or what is the >> safe-download procedure (as with kernl.org .tar's + .sign for kernels)? >> > > You can download/compare with my tree: > http://people.freedesktop.org/~agd5f/radeon_ucode/ > > Alex > > >> ___ >> dri-devel mailing list >> dri-devel@lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/dri-devel Thanks. Is this firmware a closed source binary blob? Or open source, only uploaded to the card on init? Who develops it / where to get the source code, and how to build that file from sources? This means that entire firmeware of GFX card is flashed on bootup? Btw this is a form of virus protection you could say (or anyway such firmware is volatile and lost on reboot?) ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm fixes
(ignore original, this one comes with a believable changelog). > Hi Linus, > > simple one just one pci ids patch from Alex, > > I know Keith has some patches outstanding in his queue and I know they are > probably more than you'll want to merge at this point, I'm off until next > week, so Keith if you do send a pull request you may as well send to > Linus, since I know Linus can be more lenient on pulls which make the hw > he uses suck less :-) > The following changes since commit 373da0a2a33018d560afcb2c77f8842985d79594: Merge branch 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip (2011-12-13 15:02:31 -0800) are available in the git repository at: git://people.freedesktop.org/~airlied/linux drm-fixes Alex Deucher (1): drm/radeon/kms: add some new pci ids include/drm/drm_pciids.h | 10 ++ 1 files changed, 10 insertions(+), 0 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [drm] [radeon] [3.1.4] slub memory corruption in drm_vblank_cleanup
On Wed, Dec 14, 2011 at 12:27 PM, batouzo wrote: > On 12/14/2011 06:21 PM, Alex Deucher wrote: >> On Wed, Dec 14, 2011 at 12:12 PM, batouzo wrote: >>> On 12/14/2011 05:40 PM, Alex Deucher wrote: On Wed, Dec 14, 2011 at 11:32 AM, batouzo wrote: > On 12/14/2011 03:10 PM, Alex Deucher wrote: > >>> Though, the 60 second delay may influence the rarity of hitting BUG (it >>> was the case with netconsole's 60sec wait). >>> Should I just remove loading of this firmware? >>> >> Make sure the ucode is available in your initrd or kernel image or >> filesystem depending on how you are loading the driver. The driver >> has much more limited functionality without the ucode (no acceleration >> support, no interrupt support). You may not hit the bug at all due to >> the reduced functionality. > > Actually, where is that file? Can't find CEDAR_pfp.bin or even any > "*CEDAR*" in entire filesystem where I build the kernel. > > Also I tried CONFIG_FIRMWARE_IN_KERNEL=y > but it didn't helped, hm. > You need to grab them from here: http://git.kernel.org/?p=linux/kernel/git/dwmw2/linux-firmware.git >>> >>> Ok I see. >>> >>> Is there a pubkey signed version of that available, or what is the >>> safe-download procedure (as with kernl.org .tar's + .sign for kernels)? >>> >> >> You can download/compare with my tree: >> http://people.freedesktop.org/~agd5f/radeon_ucode/ >> >> Alex >> >> >>> ___ >>> dri-devel mailing list >>> dri-devel@lists.freedesktop.org >>> http://lists.freedesktop.org/mailman/listinfo/dri-devel > > Thanks. > > Is this firmware a closed source binary blob? > Or open source, only uploaded to the card on init? > It's closed source and only uploaded to the card on init. > Who develops it / where to get the source code, and how to build that > file from sources? AMD develops and releases the ucode images. No source is available. > > This means that entire firmeware of GFX card is flashed on bootup? > Btw this is a form of virus protection you could say (or anyway such > firmware is volatile and lost on reboot?) The ucode is volatile and is lost on reboot. The different ucode images are used for different things. The PFP and ME ucode images provide the acceleration API and the RLC ucode is required to make the interrupt controller work. On newer asics, the MC ucode is used for the gddr5 controller on the chip and is required to link train the memory so it will run at full speed. Alex > > ___ > 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: [drm] [radeon] [3.1.4] slub memory corruption in drm_vblank_cleanup
On 12/14/2011 06:40 PM, Alex Deucher wrote: > On Wed, Dec 14, 2011 at 12:27 PM, batouzo wrote: > AMD develops and releases the ucode images. No source is available. > >> >> This means that entire firmeware of GFX card is flashed on bootup? >> Btw this is a form of virus protection you could say (or anyway such >> firmware is volatile and lost on reboot?) > > The ucode is volatile and is lost on reboot. The different ucode > images are used for different things. The PFP and ME ucode images > provide the acceleration API and the RLC ucode is required to make the > interrupt controller work. On newer asics, the MC ucode is used for > the gddr5 controller on the chip and is required to link train the > memory so it will run at full speed. Thanks for explanation. I hoped using radeon and KMS I'm choosing the "good" (secure / FOSS philosophy etc) solution, but it seems to not be the case then. What should one do to have 100% opensource, maximally secure X on radeon cards? Maybe I should disable firmware to achieve this goal at cost of performance - or may disabling firmware actually introduce any security/stability problems? Would Intel build-in card be better for this use? Any particular family? ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 43835] System crashes when radeon firmware blob (R520_cp.bin) is installed
https://bugs.freedesktop.org/show_bug.cgi?id=43835 --- Comment #3 from Camaleón 2011-12-14 09:56:05 PST --- (In reply to comment #1) > In the future, please attach the dmesg and log files directly. Will do, sorry. > It looks like it's a problem with acceleration (which is available without > the firmware). I don't see any oops or backtraces in the logs. Can you > attach the oops or get a picture of it? Kernel oops and backtrace are available at Debian bug. Direct links: - Kernel 3.1 (syslog) http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=5;filename=20111209_syslog_kernel_oops.txt;att=1;bug=651532 (snapshot) http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=5;filename=20111209_snapshot_kernel_oops.jpg;att=4;bug=651532 - Kernel 3.2-rc4 (syslog) http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=21;filename=20111212_syslog_kernel_3_2_rc3;att=2;bug=651532 (snapshot) http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=21;filename=20111212_snapshot_kernel_trace.jpg;att=1;bug=651532 I can attach the files to this bug report if you find it convenient. > Does setting: > Option "NoAccel" "True" > in the device section of your xorg.conf fix the problem? I have asked the user to try with this option while having the firmware package installed, will report back as soon as I get the results. -- 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: [drm] [radeon] [3.1.4] slub memory corruption in drm_vblank_cleanup
On Wed, Dec 14, 2011 at 12:49 PM, batouzo wrote: > On 12/14/2011 06:40 PM, Alex Deucher wrote: >> On Wed, Dec 14, 2011 at 12:27 PM, batouzo wrote: > >> AMD develops and releases the ucode images. No source is available. >> >>> >>> This means that entire firmeware of GFX card is flashed on bootup? >>> Btw this is a form of virus protection you could say (or anyway such >>> firmware is volatile and lost on reboot?) >> >> The ucode is volatile and is lost on reboot. The different ucode >> images are used for different things. The PFP and ME ucode images >> provide the acceleration API and the RLC ucode is required to make the >> interrupt controller work. On newer asics, the MC ucode is used for >> the gddr5 controller on the chip and is required to link train the >> memory so it will run at full speed. > > Thanks for explanation. > > I hoped using radeon and KMS I'm choosing the "good" (secure / FOSS > philosophy etc) solution, but it seems to not be the case then. > > What should one do to have 100% opensource, maximally secure X on radeon > cards? > Maybe I should disable firmware to achieve this goal at cost of > performance - or may disabling firmware actually introduce any > security/stability problems? I don't want to get into a philosophical discussion about firmware. It's required for proper operation on radeon cards. Not using it will disable acceleration and interrupts and is overall not well tested/supported. On newer asics that require the MC ucode, the MC ucode is required to use the card at all as the boot up state is only enough to light up the screen. Alex ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/omap: drm API update: addfb2
On Tue, Dec 13, 2011 at 08:18:03PM -0600, Rob Clark wrote: > On Mon, Dec 12, 2011 at 6:56 PM, Greg KH wrote: > > On Mon, Dec 12, 2011 at 06:49:44PM -0600, Rob Clark wrote: > >> From: Rob Clark > >> > >> Update to reflect changes in: > >> "drm: add an fb creation ioctl that takes a pixel format v5" > > > > This one I'm going to have to wait for the drm api merges to happen, so > > I'll just wait for them to go into Linus's tree before taking them, ok? > > oh, heh.. I found a couple small cleanups to this patch (adding a > "const" to a table, and such).. since this can't be applied until > drm-next is merged, if you don't mind I'd like to resend this one in a > patchset along with the patches adding drm_plane support, which I'm > pretty close to ready to send. Ok, I've dropped it from my queue now. greg k-h ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 43698] On PPC, OpenGL programs use incorrect texture colors.
https://bugs.freedesktop.org/show_bug.cgi?id=43698 --- Comment #7 from GhostlyDeath 2011-12-14 11:11:21 PST --- This only affects textures, whether they were created with image loading or if they were created with PBOs. Anything that does not use textures, appear how they are supposed to appear. -- 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 43698] On PPC, OpenGL programs use incorrect texture colors.
https://bugs.freedesktop.org/show_bug.cgi?id=43698 Alex Deucher changed: What|Removed |Added Attachment #54302|application/octet-stream|text/plain mime type|| Attachment #54302|0 |1 is 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
[Bug 41668] Screen locks up at random points when using a 3D compositing wm (gnome-shell) on an rv515 (radeon mobility x1300)
https://bugs.freedesktop.org/show_bug.cgi?id=41668 --- Comment #16 from Przemyslaw Kochanski 2011-12-14 17:38:59 PST --- Created attachment 54445 --> https://bugs.freedesktop.org/attachment.cgi?id=54445 output of glxinfo I'm experiencing the same issue on Ubuntu 11.10. I'm ready to provide all necessary backtrace. I'm attaching gnome-shell backtrace and glxinfo output. Same issue is reported on gnome-shell bugtracker: https://bugzilla.gnome.org/show_bug.cgi?id=650857 but they claim its either X or the drivers fault. -- 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 41668] Screen locks up at random points when using a 3D compositing wm (gnome-shell) on an rv515 (radeon mobility x1300)
https://bugs.freedesktop.org/show_bug.cgi?id=41668 --- Comment #17 from Przemyslaw Kochanski 2011-12-14 17:39:45 PST --- Created attachment 54446 --> https://bugs.freedesktop.org/attachment.cgi?id=54446 gdb gnome-shell backtrace -- 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 v2 5/5] drm/exynos: Add plane support with fimd
On 12/15/2011 02:26 AM, Jesse Barnes wrote: On Wed, 14 Dec 2011 19:00:15 +0900 Joonyoung Shim wrote: The exynos fimd supports 5 window overlays. Only one window overlay of fimd is used by the crtc, so we need plane feature to use the rest window overlays. This creates one ioctl exynos specific - DRM_EXYNOS_PLANE_SET_ZPOS, it is the ioctl to decide for user to assign which window overlay. Signed-off-by: Joonyoung Shim Signed-off-by: Inki Dae Signed-off-by: Kyungmin Park --- v2: consider fixed point about src_x/src_y Looks pretty good; the only thing that jumped out was that you don't seem to be validating the zpos ioctl parameters for sanity. Not sure if there's much to do, but it may be worth checking for a max zpos or something... OK, i added to check to be validating the zpos ioctl parameter. Thanks. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 5/5] drm/exynos: Add plane support with fimd
The exynos fimd supports 5 window overlays. Only one window overlay of
fimd is used by the crtc, so we need plane feature to use the rest
window overlays.
This creates one ioctl exynos specific - DRM_EXYNOS_PLANE_SET_ZPOS, it
is the ioctl to decide for user to assign which window overlay.
Signed-off-by: Joonyoung Shim
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
v2: consider fixed point about src_x/src_y
v3: check to be validating the zpos ioctl parameter
drivers/gpu/drm/exynos/Makefile |3 +-
drivers/gpu/drm/exynos/exynos_drm_crtc.c|1 +
drivers/gpu/drm/exynos/exynos_drm_drv.c |9 ++
drivers/gpu/drm/exynos/exynos_drm_drv.h |8 +-
drivers/gpu/drm/exynos/exynos_drm_encoder.c | 26 -
drivers/gpu/drm/exynos/exynos_drm_encoder.h |2 +
drivers/gpu/drm/exynos/exynos_drm_fimd.c| 33 --
drivers/gpu/drm/exynos/exynos_drm_plane.c | 163 +++
drivers/gpu/drm/exynos/exynos_drm_plane.h | 14 +++
include/drm/exynos_drm.h| 10 ++
10 files changed, 254 insertions(+), 15 deletions(-)
create mode 100644 drivers/gpu/drm/exynos/exynos_drm_plane.c
create mode 100644 drivers/gpu/drm/exynos/exynos_drm_plane.h
diff --git a/drivers/gpu/drm/exynos/Makefile b/drivers/gpu/drm/exynos/Makefile
index 0496d3f..c991272 100644
--- a/drivers/gpu/drm/exynos/Makefile
+++ b/drivers/gpu/drm/exynos/Makefile
@@ -5,7 +5,8 @@
ccflags-y := -Iinclude/drm -Idrivers/gpu/drm/exynos
exynosdrm-y := exynos_drm_drv.o exynos_drm_encoder.o exynos_drm_connector.o \
exynos_drm_crtc.o exynos_drm_fbdev.o exynos_drm_fb.o \
- exynos_drm_buf.o exynos_drm_gem.o exynos_drm_core.o
+ exynos_drm_buf.o exynos_drm_gem.o exynos_drm_core.o \
+ exynos_drm_plane.o
obj-$(CONFIG_DRM_EXYNOS) += exynosdrm.o
obj-$(CONFIG_DRM_EXYNOS_FIMD) += exynos_drm_fimd.o
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index a156f6c..7f22107 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -380,6 +380,7 @@ int exynos_drm_crtc_create(struct drm_device *dev, unsigned
int nr)
exynos_crtc->pipe = nr;
exynos_crtc->dpms = DRM_MODE_DPMS_OFF;
+ exynos_crtc->overlay.zpos = DEFAULT_ZPOS;
crtc = &exynos_crtc->drm_crtc;
private->crtc[nr] = crtc;
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index b86a04b..050684c 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -36,6 +36,7 @@
#include "exynos_drm_fbdev.h"
#include "exynos_drm_fb.h"
#include "exynos_drm_gem.h"
+#include "exynos_drm_plane.h"
#define DRIVER_NAME"exynos-drm"
#define DRIVER_DESC"Samsung SoC DRM"
@@ -77,6 +78,12 @@ static int exynos_drm_load(struct drm_device *dev, unsigned
long flags)
goto err_crtc;
}
+ for (nr = 0; nr < MAX_PLANE; nr++) {
+ ret = exynos_plane_init(dev, nr);
+ if (ret)
+ goto err_crtc;
+ }
+
ret = drm_vblank_init(dev, MAX_CRTC);
if (ret)
goto err_crtc;
@@ -163,6 +170,8 @@ static struct drm_ioctl_desc exynos_ioctls[] = {
DRM_AUTH),
DRM_IOCTL_DEF_DRV(EXYNOS_GEM_MMAP,
exynos_drm_gem_mmap_ioctl, DRM_UNLOCKED | DRM_AUTH),
+ DRM_IOCTL_DEF_DRV(EXYNOS_PLANE_SET_ZPOS, exynos_plane_set_zpos_ioctl,
+ DRM_UNLOCKED | DRM_AUTH),
};
static const struct file_operations exynos_drm_driver_fops = {
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index 8018798..8e8d8f0 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -33,6 +33,8 @@
#include "drm.h"
#define MAX_CRTC 2
+#define MAX_PLANE 5
+#define DEFAULT_ZPOS -1
struct drm_device;
struct exynos_drm_overlay;
@@ -57,8 +59,8 @@ enum exynos_drm_output_type {
struct exynos_drm_overlay_ops {
void (*mode_set)(struct device *subdrv_dev,
struct exynos_drm_overlay *overlay);
- void (*commit)(struct device *subdrv_dev);
- void (*disable)(struct device *subdrv_dev);
+ void (*commit)(struct device *subdrv_dev, int zpos);
+ void (*disable)(struct device *subdrv_dev, int zpos);
};
/*
@@ -83,6 +85,7 @@ struct exynos_drm_overlay_ops {
* @dma_addr: bus(accessed by dma) address to the memory region allocated
* for a overlay.
* @vaddr: virtual memory addresss to this overlay.
+ * @zpos: order of overlay layer(z position).
* @default_win: a window to be enabled.
* @color_key: color key on or off.
* @index_color: if using color key feature then this value would be used
@@ -111,6 +114,7 @@ struct exynos_drm_overlay {
unsigned int pitch;
dma_
Re: [PATCH] modetest: add drm_plane support
On Tue, Dec 13, 2011 at 8:55 PM, Rob Clark wrote:
> From: Rob Clark
>
> Signed-off-by: Rob Clark
> ---
> tests/modetest/modetest.c | 166
> ++---
> 1 files changed, 157 insertions(+), 9 deletions(-)
>
> diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
> index 1e4ec91..22ac620 100644
> --- a/tests/modetest/modetest.c
> +++ b/tests/modetest/modetest.c
> @@ -51,6 +51,7 @@
>
> #include "xf86drm.h"
> #include "xf86drmMode.h"
> +#include "drm_fourcc.h"
> #include "libkms.h"
>
> #ifdef HAVE_CAIRO
> @@ -267,6 +268,49 @@ void dump_framebuffers(void)
> printf("\n");
> }
>
> +static void dump_planes(void)
> +{
> + drmModePlaneRes *plane_resources;
> + drmModePlane *ovr;
> + int i, j;
> +
> + plane_resources = drmModeGetPlaneResources(fd);
> + if (!plane_resources) {
> + fprintf(stderr, "drmModeGetPlaneResources failed: %s\n",
> + strerror(errno));
> + return;
> + }
> +
> + printf("Planes:\n");
> + printf("id\tcrtc\tfb\tCRTC x,y\tx,y\tgamma size\n");
> + for (i = 0; i < plane_resources->count_planes; i++) {
> + ovr = drmModeGetPlane(fd, plane_resources->planes[i]);
> + if (!ovr) {
> + fprintf(stderr, "drmModeGetPlane failed: %s\n",
> + strerror(errno));
> + continue;
> + }
> +
> + printf("%d\t%d\t%d\t%d,%d\t\t%d,%d\t%d\n",
> + ovr->plane_id, ovr->crtc_id, ovr->fb_id,
> + ovr->crtc_x, ovr->crtc_y, ovr->x, ovr->y,
> + ovr->gamma_size);
> +
> + if (!ovr->count_formats)
> + continue;
> +
> + printf(" formats:");
> + for (j = 0; j < ovr->count_formats; j++)
> + printf(" %4.4s", (char *)&ovr->formats[j]);
> + printf("\n");
> +
> + drmModeFreePlane(ovr);
> + }
> + printf("\n");
> +
> + return;
> +}
> +
> /*
> * Mode setting with the kernel interfaces is a bit of a chore.
> * First you have to find the connector in question and make sure the
> @@ -280,11 +324,18 @@ struct connector {
> drmModeModeInfo *mode;
> drmModeEncoder *encoder;
> int crtc;
> + int pipe;
> unsigned int fb_id[2], current_fb_id;
> struct timeval start;
>
> int swap_count;
> -};
> +};
> +
> +struct plane {
> + uint32_t con_id; /* the id of connector to bind to */
> + uint32_t w, h;
> + unsigned int fb_id;
> +};
>
> static void
> connector_find_mode(struct connector *c)
> @@ -351,6 +402,15 @@ connector_find_mode(struct connector *c)
>
> if (c->crtc == -1)
> c->crtc = c->encoder->crtc_id;
> +
> + /* and figure out which crtc index it is: */
> + for (i = 0; i < resources->count_crtcs; i++) {
> + if (c->crtc == resources->crtcs[i]) {
> + c->pipe = i;
> + break;
> + }
> + }
> +
> }
>
> static struct kms_bo *
> @@ -534,13 +594,83 @@ page_flip_handler(int fd, unsigned int frame,
> }
> }
>
> +static int
> +set_plane(struct kms_driver *kms, struct connector *c, struct plane *p)
> +{
> + drmModePlaneRes *plane_resources;
> + drmModePlane *ovr;
> + uint32_t handles[4], pitches[4], offsets[4]; /* we only use [0] */
opps, passing unitialized offset values to drmModeAddFB2() causes
problems when the driver doesn't actually ignore the offset..
don't merge this yet.. I'm fixing and also adding some test code for
multi-planar YUV (which will need Joonyoung Shim's fix)
BR,
-R
> + uint32_t plane_id = 0;
> + struct kms_bo *plane_bo;
> + uint32_t plane_flags = 0;
> + int i, crtc_x, crtc_y, crtc_w, crtc_h;
> +
> + /* find an unused plane which can be connected to our crtc */
> + plane_resources = drmModeGetPlaneResources(fd);
> + if (!plane_resources) {
> + fprintf(stderr, "drmModeGetPlaneResources failed: %s\n",
> + strerror(errno));
> + return -1;
> + }
> +
> + for (i = 0; i < plane_resources->count_planes && !plane_id; i++) {
> + ovr = drmModeGetPlane(fd, plane_resources->planes[i]);
> + if (!ovr) {
> + fprintf(stderr, "drmModeGetPlane failed: %s\n",
> + strerror(errno));
> + return -1;
> + }
> +
> + if ((ovr->possible_crtcs & (1 << c->pipe)) && !ovr->crtc_id)
> + plane_id = ovr->plane_id;
> +
> + drmModeFreePlane(ovr);
> + }
> +
> + if (!plane_id) {
> + fprintf(stderr, "failed to find plane!\n");
> + return -1;
> + }
> +
> + /* TODO.. would be nice t
Re: [PATCH] libdrm: fix sizes of memcpy to the drmModeAddFB2()
On Wed, Dec 14, 2011 at 1:15 AM, Joonyoung Shim wrote: > The variables(bo_handles, pitches and offsets) are the array having 4 > elementary of uint32_t type. The their memcpy size is sizeof(uint32_t) * > 4. > > Signed-off-by: Joonyoung Shim Tested-by: Rob Clark > --- > xf86drmMode.c | 6 +++--- > 1 files changed, 3 insertions(+), 3 deletions(-) > > diff --git a/xf86drmMode.c b/xf86drmMode.c > index ffa6dc4..8065f20 100644 > --- a/xf86drmMode.c > +++ b/xf86drmMode.c > @@ -267,9 +267,9 @@ int drmModeAddFB2(int fd, uint32_t width, uint32_t height, > f.height = height; > f.pixel_format = pixel_format; > f.flags = flags; > - memcpy(f.handles, bo_handles, sizeof(bo_handles)); > - memcpy(f.pitches, pitches, sizeof(pitches)); > - memcpy(f.offsets, offsets, sizeof(offsets)); > + memcpy(f.handles, bo_handles, sizeof(uint32_t) * 4); > + memcpy(f.pitches, pitches, sizeof(uint32_t) * 4); > + memcpy(f.offsets, offsets, sizeof(uint32_t) * 4); > > if ((ret = DRM_IOCTL(fd, DRM_IOCTL_MODE_ADDFB2, &f))) > return ret; > -- > 1.7.5.4 > > ___ > 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
[PATCH 1/2] modetest: add drm_plane support
From: Rob Clark
Signed-off-by: Rob Clark
---
tests/modetest/modetest.c | 166 ++---
1 files changed, 157 insertions(+), 9 deletions(-)
diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
index 1e4ec91..2936de0 100644
--- a/tests/modetest/modetest.c
+++ b/tests/modetest/modetest.c
@@ -51,6 +51,7 @@
#include "xf86drm.h"
#include "xf86drmMode.h"
+#include "drm_fourcc.h"
#include "libkms.h"
#ifdef HAVE_CAIRO
@@ -267,6 +268,49 @@ void dump_framebuffers(void)
printf("\n");
}
+static void dump_planes(void)
+{
+ drmModePlaneRes *plane_resources;
+ drmModePlane *ovr;
+ int i, j;
+
+ plane_resources = drmModeGetPlaneResources(fd);
+ if (!plane_resources) {
+ fprintf(stderr, "drmModeGetPlaneResources failed: %s\n",
+ strerror(errno));
+ return;
+ }
+
+ printf("Planes:\n");
+ printf("id\tcrtc\tfb\tCRTC x,y\tx,y\tgamma size\n");
+ for (i = 0; i < plane_resources->count_planes; i++) {
+ ovr = drmModeGetPlane(fd, plane_resources->planes[i]);
+ if (!ovr) {
+ fprintf(stderr, "drmModeGetPlane failed: %s\n",
+ strerror(errno));
+ continue;
+ }
+
+ printf("%d\t%d\t%d\t%d,%d\t\t%d,%d\t%d\n",
+ ovr->plane_id, ovr->crtc_id, ovr->fb_id,
+ ovr->crtc_x, ovr->crtc_y, ovr->x, ovr->y,
+ ovr->gamma_size);
+
+ if (!ovr->count_formats)
+ continue;
+
+ printf(" formats:");
+ for (j = 0; j < ovr->count_formats; j++)
+ printf(" %4.4s", (char *)&ovr->formats[j]);
+ printf("\n");
+
+ drmModeFreePlane(ovr);
+ }
+ printf("\n");
+
+ return;
+}
+
/*
* Mode setting with the kernel interfaces is a bit of a chore.
* First you have to find the connector in question and make sure the
@@ -280,11 +324,18 @@ struct connector {
drmModeModeInfo *mode;
drmModeEncoder *encoder;
int crtc;
+ int pipe;
unsigned int fb_id[2], current_fb_id;
struct timeval start;
int swap_count;
-};
+};
+
+struct plane {
+ uint32_t con_id; /* the id of connector to bind to */
+ uint32_t w, h;
+ unsigned int fb_id;
+};
static void
connector_find_mode(struct connector *c)
@@ -351,6 +402,15 @@ connector_find_mode(struct connector *c)
if (c->crtc == -1)
c->crtc = c->encoder->crtc_id;
+
+ /* and figure out which crtc index it is: */
+ for (i = 0; i < resources->count_crtcs; i++) {
+ if (c->crtc == resources->crtcs[i]) {
+ c->pipe = i;
+ break;
+ }
+ }
+
}
static struct kms_bo *
@@ -534,13 +594,83 @@ page_flip_handler(int fd, unsigned int frame,
}
}
+static int
+set_plane(struct kms_driver *kms, struct connector *c, struct plane *p)
+{
+ drmModePlaneRes *plane_resources;
+ drmModePlane *ovr;
+ uint32_t handles[4], pitches[4], offsets[4] = {0}; /* we only use [0] */
+ uint32_t plane_id = 0;
+ struct kms_bo *plane_bo;
+ uint32_t plane_flags = 0;
+ int i, crtc_x, crtc_y, crtc_w, crtc_h;
+
+ /* find an unused plane which can be connected to our crtc */
+ plane_resources = drmModeGetPlaneResources(fd);
+ if (!plane_resources) {
+ fprintf(stderr, "drmModeGetPlaneResources failed: %s\n",
+ strerror(errno));
+ return -1;
+ }
+
+ for (i = 0; i < plane_resources->count_planes && !plane_id; i++) {
+ ovr = drmModeGetPlane(fd, plane_resources->planes[i]);
+ if (!ovr) {
+ fprintf(stderr, "drmModeGetPlane failed: %s\n",
+ strerror(errno));
+ return -1;
+ }
+
+ if ((ovr->possible_crtcs & (1 << c->pipe)) && !ovr->crtc_id)
+ plane_id = ovr->plane_id;
+
+ drmModeFreePlane(ovr);
+ }
+
+ if (!plane_id) {
+ fprintf(stderr, "failed to find plane!\n");
+ return -1;
+ }
+
+ /* TODO.. would be nice to test YUV overlays.. */
+ if (create_test_buffer(kms, p->w, p->h, &pitches[0], &plane_bo))
+ return -1;
+
+ kms_bo_get_prop(plane_bo, KMS_HANDLE, &handles[0]);
+
+ /* just use single plane format for now.. */
+ if (drmModeAddFB2(fd, p->w, p->h, DRM_FORMAT_XRGB,
+ handles, pitches, offsets, &p->fb_id, plane_flags)) {
+ fprintf(stderr, "failed to add fb: %s\n", strerror(errno));
+ return -1;
+ }
+
+ /* ok, boring.. but for now put in middle of screen: */
+ crt
[PATCH 2/2] modetest: add YUV and multi-planar support
From: Rob Clark
Signed-off-by: Rob Clark
---
This one is a bit f-ugly.. kms_bo_create() and dumb-scanout alloc only
really knows about allocating 4byte/pixel buffers, so we just allocate
oversized buffers and use the part we need. It is functional enough
to test the driver (or at least omapdrm), but I'm not sure about how
best to deal w/ kms_bo_create(). (Or perhaps I should only test YUV
support in omapdrmtest tree, and not try to use generic kms_bo_create()?)
tests/modetest/modetest.c | 151 ++---
1 files changed, 142 insertions(+), 9 deletions(-)
diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
index 2936de0..36bdfff 100644
--- a/tests/modetest/modetest.c
+++ b/tests/modetest/modetest.c
@@ -335,6 +335,7 @@ struct plane {
uint32_t con_id; /* the id of connector to bind to */
uint32_t w, h;
unsigned int fb_id;
+ char format_str[5]; /* need to leave room for terminating \0 */
};
static void
@@ -594,6 +595,63 @@ page_flip_handler(int fd, unsigned int frame,
}
}
+/* swap these for big endian.. */
+#define RED 2
+#define GREEN 1
+#define BLUE 0
+
+static void
+fill420(unsigned char *y, unsigned char *u, unsigned char *v,
+ int cs /*chroma pixel stride */,
+ int n, int width, int height, int stride)
+{
+ int i, j;
+
+ /* paint the buffer with colored tiles, in blocks of 2x2 */
+ for (j = 0; j < height; j+=2) {
+ unsigned char *y1p = y + j * stride;
+ unsigned char *y2p = y1p + stride;
+ unsigned char *up = u + (j/2) * stride * cs / 2;
+ unsigned char *vp = v + (j/2) * stride * cs / 2;
+
+ for (i = 0; i < width; i+=2) {
+ div_t d = div(n+i+j, width);
+ uint32_t rgb = 0x00130502 * (d.quot >> 6) + 0x000a1120
* (d.rem >> 6);
+ unsigned char *rgbp = (unsigned char *)&rgb;
+ unsigned char y = (0.299 * rgbp[RED]) + (0.587 *
rgbp[GREEN]) + (0.114 * rgbp[BLUE]);
+
+ *(y2p++) = *(y1p++) = y;
+ *(y2p++) = *(y1p++) = y;
+
+ *up = (rgbp[BLUE] - y) * 0.565 + 128;
+ *vp = (rgbp[RED] - y) * 0.713 + 128;
+ up += cs;
+ vp += cs;
+ }
+ }
+}
+
+static void
+fill422(unsigned char *virtual, int n, int width, int height, int stride)
+{
+ int i, j;
+ /* paint the buffer with colored tiles */
+ for (j = 0; j < height; j++) {
+ uint8_t *ptr = (uint8_t*)((char*)virtual + j * stride);
+ for (i = 0; i < width; i++) {
+ div_t d = div(n+i+j, width);
+ uint32_t rgb = 0x00130502 * (d.quot >> 6) + 0x000a1120
* (d.rem >> 6);
+ unsigned char *rgbp = (unsigned char *)&rgb;
+ unsigned char y = (0.299 * rgbp[RED]) + (0.587 *
rgbp[GREEN]) + (0.114 * rgbp[BLUE]);
+
+ *(ptr++) = y;
+ *(ptr++) = (rgbp[BLUE] - y) * 0.565 + 128;
+ *(ptr++) = y;
+ *(ptr++) = (rgbp[RED] - y) * 0.713 + 128;
+ }
+ }
+}
+
static int
set_plane(struct kms_driver *kms, struct connector *c, struct plane *p)
{
@@ -602,8 +660,8 @@ set_plane(struct kms_driver *kms, struct connector *c,
struct plane *p)
uint32_t handles[4], pitches[4], offsets[4] = {0}; /* we only use [0] */
uint32_t plane_id = 0;
struct kms_bo *plane_bo;
- uint32_t plane_flags = 0;
- int i, crtc_x, crtc_y, crtc_w, crtc_h;
+ uint32_t plane_flags = 0, format;
+ int i, ret, crtc_x, crtc_y, crtc_w, crtc_h;
/* find an unused plane which can be connected to our crtc */
plane_resources = drmModeGetPlaneResources(fd);
@@ -627,19 +685,87 @@ set_plane(struct kms_driver *kms, struct connector *c,
struct plane *p)
drmModeFreePlane(ovr);
}
+ fprintf(stderr, "testing %dx%d@%s overlay plane\n",
+ p->w, p->h, p->format_str);
+
if (!plane_id) {
fprintf(stderr, "failed to find plane!\n");
return -1;
}
- /* TODO.. would be nice to test YUV overlays.. */
- if (create_test_buffer(kms, p->w, p->h, &pitches[0], &plane_bo))
- return -1;
+ if (!strcmp(p->format_str, "XR24")) {
+ if (create_test_buffer(kms, p->w, p->h, &pitches[0], &plane_bo))
+ return -1;
+ kms_bo_get_prop(plane_bo, KMS_HANDLE, &handles[0]);
+ format = DRM_FORMAT_XRGB;
+ } else {
+ void *virtual;
+
+ /* TODO: this always allocates a buffer for 32bpp RGB.. but for
+* YUV formats, we don't use all of it.. since 4bytes/pixel is
+* worst
[PATCH 0/3] drm/omap: updates for addfb2 and plane support
From: Rob Clark The first patch updates omapdrm for API changes introduced when addfb2 support (for multi-planar fb's) was added (in drm-next). The next patch adds drm plane (overlay) support, with CRTCs using private plane objects to avoid code duplication between the CRTC and plane. (This depends on the "drm: add support for private planes" patch.) The final patch adds support for YUV and multi-planar YUV formats. Rob Clark (3): drm/omap: drm API update: addfb2 drm/omap: add drm_plane support drm/omap: multiplanar and YUV support drivers/staging/omapdrm/Makefile |1 + drivers/staging/omapdrm/omap_crtc.c | 191 +--- drivers/staging/omapdrm/omap_drv.c | 53 -- drivers/staging/omapdrm/omap_drv.h | 69 +++- drivers/staging/omapdrm/omap_fb.c| 224 +-- drivers/staging/omapdrm/omap_fbdev.c | 53 -- drivers/staging/omapdrm/omap_gem.c |5 + drivers/staging/omapdrm/omap_plane.c | 329 ++ drivers/staging/omapdrm/omap_priv.h | 12 +- 9 files changed, 687 insertions(+), 250 deletions(-) create mode 100644 drivers/staging/omapdrm/omap_plane.c -- 1.7.5.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/3] drm/omap: drm API update: addfb2
From: Rob Clark
Update to reflect changes in:
"drm: add an fb creation ioctl that takes a pixel format v5"
Signed-off-by: Rob Clark
---
drivers/staging/omapdrm/omap_drv.h | 53 +-
drivers/staging/omapdrm/omap_fb.c| 99 ++---
drivers/staging/omapdrm/omap_fbdev.c | 53 ---
3 files changed, 163 insertions(+), 42 deletions(-)
diff --git a/drivers/staging/omapdrm/omap_drv.h
b/drivers/staging/omapdrm/omap_drv.h
index 8dd7d74..bc8daa7 100644
--- a/drivers/staging/omapdrm/omap_drv.h
+++ b/drivers/staging/omapdrm/omap_drv.h
@@ -76,9 +76,9 @@ void omap_connector_flush(struct drm_connector *connector,
void omap_connector_dpms(struct drm_connector *connector, int mode);
struct drm_framebuffer *omap_framebuffer_create(struct drm_device *dev,
- struct drm_file *file, struct drm_mode_fb_cmd *mode_cmd);
+ struct drm_file *file, struct drm_mode_fb_cmd2 *mode_cmd);
struct drm_framebuffer *omap_framebuffer_init(struct drm_device *dev,
- struct drm_mode_fb_cmd *mode_cmd, struct drm_gem_object *bo);
+ struct drm_mode_fb_cmd2 *mode_cmd, struct drm_gem_object **bos);
struct drm_gem_object *omap_framebuffer_bo(struct drm_framebuffer *fb);
int omap_framebuffer_get_buffer(struct drm_framebuffer *fb, int x, int y,
void **vaddr, dma_addr_t *paddr, unsigned int *screen_width);
@@ -128,4 +128,53 @@ static inline int align_pitch(int pitch, int width, int
bpp)
return ALIGN(pitch, 8 * bytespp);
}
+/* should these be made into common util helpers?
+ */
+
+static inline int num_planes(uint32_t pixel_format)
+{
+ switch (pixel_format) {
+ default:
+ return 1;
+ case DRM_FORMAT_NV12:
+ case DRM_FORMAT_NV21:
+ case DRM_FORMAT_NV16:
+ case DRM_FORMAT_NV61:
+ return 2;
+ case DRM_FORMAT_YUV410:
+ case DRM_FORMAT_YVU410:
+ case DRM_FORMAT_YUV411:
+ case DRM_FORMAT_YVU411:
+ case DRM_FORMAT_YUV420:
+ case DRM_FORMAT_YVU420:
+ case DRM_FORMAT_YUV422:
+ case DRM_FORMAT_YVU422:
+ case DRM_FORMAT_YUV444:
+ case DRM_FORMAT_YVU444:
+ return 3;
+ }
+}
+
+static inline int objects_lookup(struct drm_device *dev,
+ struct drm_file *filp, uint32_t pixel_format,
+ struct drm_gem_object **bos, uint32_t *handles)
+{
+ int i, n = num_planes(pixel_format);
+
+ for (i = 0; i < n; i++) {
+ bos[i] = drm_gem_object_lookup(dev, filp, handles[i]);
+ if (!bos[i]) {
+ goto fail;
+ }
+ }
+
+ return 0;
+
+fail:
+ while (--i > 0) {
+ drm_gem_object_unreference_unlocked(bos[i]);
+ }
+ return -ENOENT;
+}
+
#endif /* __OMAP_DRV_H__ */
diff --git a/drivers/staging/omapdrm/omap_fb.c
b/drivers/staging/omapdrm/omap_fb.c
index 0b50c5b..0d3a15e 100644
--- a/drivers/staging/omapdrm/omap_fb.c
+++ b/drivers/staging/omapdrm/omap_fb.c
@@ -22,11 +22,43 @@
#include "drm_crtc.h"
#include "drm_crtc_helper.h"
-
/*
* framebuffer funcs
*/
+/* per-format info: */
+struct format {
+ enum omap_color_mode dss_format;
+ uint32_t pixel_format;
+ struct {
+ int stride_bpp; /* this times width is stride */
+ int sub_y;/* sub-sample in y dimension */
+ } planes[4];
+ bool yuv;
+};
+
+static const struct format formats[] = {
+ /* 16bpp [A]RGB: */
+ { OMAP_DSS_COLOR_RGB16, DRM_FORMAT_RGB565, {{2, 1}}, false },
/* RGB16-565 */
+ { OMAP_DSS_COLOR_RGB12U, DRM_FORMAT_RGBX, {{2, 1}}, false },
/* RGB12x- */
+ { OMAP_DSS_COLOR_RGBX16, DRM_FORMAT_XRGB, {{2, 1}}, false },
/* xRGB12- */
+ { OMAP_DSS_COLOR_RGBA16, DRM_FORMAT_RGBA, {{2, 1}}, false },
/* RGBA12- */
+ { OMAP_DSS_COLOR_ARGB16, DRM_FORMAT_ABGR, {{2, 1}}, false },
/* ARGB16- */
+ { OMAP_DSS_COLOR_XRGB16_1555, DRM_FORMAT_XRGB1555, {{2, 1}}, false },
/* xRGB15-1555 */
+ { OMAP_DSS_COLOR_ARGB16_1555, DRM_FORMAT_ARGB1555, {{2, 1}}, false },
/* ARGB16-1555 */
+ /* 24bpp RGB: */
+ { OMAP_DSS_COLOR_RGB24P, DRM_FORMAT_RGB888, {{3, 1}}, false },
/* RGB24-888 */
+ /* 32bpp [A]RGB: */
+ { OMAP_DSS_COLOR_RGBX32, DRM_FORMAT_RGBX, {{4, 1}}, false },
/* RGBx24- */
+ { OMAP_DSS_COLOR_RGB24U, DRM_FORMAT_XRGB, {{4, 1}}, false },
/* xRGB24- */
+ { OMAP_DSS_COLOR_RGBA32, DRM_FORMAT_RGBA, {{4, 1}}, false },
/* RGBA32- */
+ { OMAP_DSS_COLOR_ARGB32, DRM_FORMAT_ARGB, {{4, 1}}, false },
/* ARGB32- */
+ /* YUV: */
+ { OMAP_DSS_COLOR_NV12,DRM_FORMAT_NV12, {{1, 1}, {1, 2}},
true },
+ { OMAP_DSS_COLOR_YUV2,DRM_FORMAT_YUYV, {{2, 1}}, true },
+ { OMAP_DSS_COLOR_UYVY,
[PATCH 2/3] drm/omap: add drm_plane support
From: Rob Clark
Because framebuffer layer and overlay scanout video pipes are basically
thing in OMAP display subsystem (the only difference being that the first
video pipe does not support scaling or YUV formats), much of the CRTC
code is pulled into the plane implementation, and a private plane object
is used by the CRTC object. This avoids code duplication between the
plane and CRTC.
Signed-off-by: Rob Clark
---
drivers/staging/omapdrm/Makefile |1 +
drivers/staging/omapdrm/omap_crtc.c | 189 +
drivers/staging/omapdrm/omap_drv.c | 53 ---
drivers/staging/omapdrm/omap_drv.h |8 +-
drivers/staging/omapdrm/omap_plane.c | 308 ++
drivers/staging/omapdrm/omap_priv.h | 12 +-
6 files changed, 403 insertions(+), 168 deletions(-)
create mode 100644 drivers/staging/omapdrm/omap_plane.c
diff --git a/drivers/staging/omapdrm/Makefile b/drivers/staging/omapdrm/Makefile
index 275054a..467aba3 100644
--- a/drivers/staging/omapdrm/Makefile
+++ b/drivers/staging/omapdrm/Makefile
@@ -6,6 +6,7 @@
ccflags-y := -Iinclude/drm -Werror
omapdrm-y := omap_drv.o \
omap_crtc.o \
+ omap_plane.o \
omap_encoder.o \
omap_connector.o \
omap_fb.o \
diff --git a/drivers/staging/omapdrm/omap_crtc.c
b/drivers/staging/omapdrm/omap_crtc.c
index cffdf5e..a91c788 100644
--- a/drivers/staging/omapdrm/omap_crtc.c
+++ b/drivers/staging/omapdrm/omap_crtc.c
@@ -27,196 +27,95 @@
struct omap_crtc {
struct drm_crtc base;
- struct omap_overlay *ovl;
- struct omap_overlay_info info;
+ struct drm_plane *plane;
+ const char *name;
int id;
- /* if there is a pending flip, this will be non-null: */
+ /* if there is a pending flip, these will be non-null: */
struct drm_pending_vblank_event *event;
+ struct drm_framebuffer *old_fb;
};
-/* push changes down to dss2 */
-static int commit(struct drm_crtc *crtc)
-{
- struct drm_device *dev = crtc->dev;
- struct omap_crtc *omap_crtc = to_omap_crtc(crtc);
- struct omap_overlay *ovl = omap_crtc->ovl;
- struct omap_overlay_info *info = &omap_crtc->info;
- int ret;
-
- DBG("%s", omap_crtc->ovl->name);
- DBG("%dx%d -> %dx%d (%d)", info->width, info->height, info->out_width,
- info->out_height, info->screen_width);
- DBG("%d,%d %08x", info->pos_x, info->pos_y, info->paddr);
-
- /* NOTE: do we want to do this at all here, or just wait
-* for dpms(ON) since other CRTC's may not have their mode
-* set yet, so fb dimensions may still change..
-*/
- ret = ovl->set_overlay_info(ovl, info);
- if (ret) {
- dev_err(dev->dev, "could not set overlay info\n");
- return ret;
- }
-
- /* our encoder doesn't necessarily get a commit() after this, in
-* particular in the dpms() and mode_set_base() cases, so force the
-* manager to update:
-*
-* could this be in the encoder somehow?
-*/
- if (ovl->manager) {
- ret = ovl->manager->apply(ovl->manager);
- if (ret) {
- dev_err(dev->dev, "could not apply settings\n");
- return ret;
- }
- }
-
- if (info->enabled) {
- omap_framebuffer_flush(crtc->fb, crtc->x, crtc->y,
- crtc->fb->width, crtc->fb->height);
- }
-
- return 0;
-}
-
-/* update parameters that are dependent on the framebuffer dimensions and
- * position within the fb that this crtc scans out from. This is called
- * when framebuffer dimensions or x,y base may have changed, either due
- * to our mode, or a change in another crtc that is scanning out of the
- * same fb.
- */
-static void update_scanout(struct drm_crtc *crtc)
-{
- struct omap_crtc *omap_crtc = to_omap_crtc(crtc);
- dma_addr_t paddr;
- unsigned int screen_width;
-
- omap_framebuffer_get_buffer(crtc->fb, crtc->x, crtc->y,
- NULL, &paddr, &screen_width);
-
- DBG("%s: %d,%d: %08x (%d)", omap_crtc->ovl->name,
- crtc->x, crtc->y, (u32)paddr, screen_width);
-
- omap_crtc->info.paddr = paddr;
- omap_crtc->info.screen_width = screen_width;
-}
-
static void omap_crtc_gamma_set(struct drm_crtc *crtc,
u16 *red, u16 *green, u16 *blue, uint32_t start, uint32_t size)
{
- struct omap_crtc *omap_crtc = to_omap_crtc(crtc);
- DBG("%s", omap_crtc->ovl->name);
+ /* not supported.. at least not yet */
}
static void omap_crtc_destroy(struct drm_crtc *crtc)
{
struct omap_crtc *omap_crtc = to_omap_crtc(crtc);
- DBG("%s", omap_crtc->ovl->name);
+ omap_crtc->plane->funcs->destroy(omap_crtc->plane);
drm_crtc_cleanup(crtc);
kfree(omap_crtc);
}
static void omap_crtc_dpms(struct drm_crtc *crt
[PATCH 3/3] drm/omap: multiplanar and YUV support
From: Rob Clark
Add support in framebuffer objects for other color formats and multi-
planar YUV (NV12). Since this requires changing the API between the
plane and fb for getting scanout information (paddr, etc), take
advantage of the opportunity and put in place a way to allow fb's to
be unpinned when they are not being scanned out. Now, before start
of scanout the plane calls omap_framebuffer_pin() which takes care
to pin all the backing bo's, then omap_framebuffer_update_scanout()
however many times to update the scanout address(es), etc, and then
when finished omap_framebuffer_unpin().
Signed-off-by: Rob Clark
---
drivers/staging/omapdrm/omap_crtc.c |2 +-
drivers/staging/omapdrm/omap_drv.h |8 +-
drivers/staging/omapdrm/omap_fb.c| 149 +++---
drivers/staging/omapdrm/omap_gem.c |5 +
drivers/staging/omapdrm/omap_plane.c | 53 +
5 files changed, 149 insertions(+), 68 deletions(-)
diff --git a/drivers/staging/omapdrm/omap_crtc.c
b/drivers/staging/omapdrm/omap_crtc.c
index a91c788..3cee04e 100644
--- a/drivers/staging/omapdrm/omap_crtc.c
+++ b/drivers/staging/omapdrm/omap_crtc.c
@@ -168,7 +168,7 @@ static int omap_crtc_page_flip_locked(struct drm_crtc *crtc,
omap_crtc->event = event;
crtc->fb = fb;
- omap_gem_op_async(omap_framebuffer_bo(fb), OMAP_GEM_READ,
+ omap_gem_op_async(omap_framebuffer_bo(fb, 0), OMAP_GEM_READ,
page_flip_cb, crtc);
return 0;
diff --git a/drivers/staging/omapdrm/omap_drv.h
b/drivers/staging/omapdrm/omap_drv.h
index 0394f17..d29d7cb 100644
--- a/drivers/staging/omapdrm/omap_drv.h
+++ b/drivers/staging/omapdrm/omap_drv.h
@@ -85,9 +85,11 @@ struct drm_framebuffer *omap_framebuffer_create(struct
drm_device *dev,
struct drm_file *file, struct drm_mode_fb_cmd2 *mode_cmd);
struct drm_framebuffer *omap_framebuffer_init(struct drm_device *dev,
struct drm_mode_fb_cmd2 *mode_cmd, struct drm_gem_object **bos);
-struct drm_gem_object *omap_framebuffer_bo(struct drm_framebuffer *fb);
-int omap_framebuffer_get_buffer(struct drm_framebuffer *fb, int x, int y,
- void **vaddr, dma_addr_t *paddr, unsigned int *screen_width);
+struct drm_gem_object *omap_framebuffer_bo(struct drm_framebuffer *fb, int p);
+int omap_framebuffer_pin(struct drm_framebuffer *fb);
+void omap_framebuffer_unpin(struct drm_framebuffer *fb);
+void omap_framebuffer_update_scanout(struct drm_framebuffer *fb, int x, int y,
+ struct omap_overlay_info *info);
struct drm_connector *omap_framebuffer_get_next_connector(
struct drm_framebuffer *fb, struct drm_connector *from);
void omap_framebuffer_flush(struct drm_framebuffer *fb,
diff --git a/drivers/staging/omapdrm/omap_fb.c
b/drivers/staging/omapdrm/omap_fb.c
index 0d3a15e..e1f97d8 100644
--- a/drivers/staging/omapdrm/omap_fb.c
+++ b/drivers/staging/omapdrm/omap_fb.c
@@ -59,14 +59,20 @@ static const struct format formats[] = {
{ OMAP_DSS_COLOR_UYVY,DRM_FORMAT_UYVY, {{2, 1}}, true },
};
+/* per-plane info for the fb: */
+struct plane {
+ struct drm_gem_object *bo;
+ uint32_t pitch;
+ uint32_t offset;
+ dma_addr_t paddr;
+};
+
#define to_omap_framebuffer(x) container_of(x, struct omap_framebuffer, base)
struct omap_framebuffer {
struct drm_framebuffer base;
- struct drm_gem_object *bo;
- int size;
- dma_addr_t paddr;
const struct format *format;
+ struct plane planes[4];
};
static int omap_framebuffer_create_handle(struct drm_framebuffer *fb,
@@ -74,22 +80,23 @@ static int omap_framebuffer_create_handle(struct
drm_framebuffer *fb,
unsigned int *handle)
{
struct omap_framebuffer *omap_fb = to_omap_framebuffer(fb);
-return drm_gem_handle_create(file_priv, omap_fb->bo, handle);
+ return drm_gem_handle_create(file_priv,
+ omap_fb->planes[0].bo, handle);
}
static void omap_framebuffer_destroy(struct drm_framebuffer *fb)
{
- struct drm_device *dev = fb->dev;
struct omap_framebuffer *omap_fb = to_omap_framebuffer(fb);
+ int i, n = num_planes(omap_fb->format->pixel_format);
DBG("destroy: FB ID: %d (%p)", fb->base.id, fb);
drm_framebuffer_cleanup(fb);
- if (omap_fb->bo) {
- if (omap_fb->paddr && omap_gem_put_paddr(omap_fb->bo))
- dev_err(dev->dev, "could not unmap!\n");
- drm_gem_object_unreference_unlocked(omap_fb->bo);
+ for (i = 0; i < n; i++) {
+ struct plane *plane = &omap_fb->planes[i];
+ if (plane->bo)
+ drm_gem_object_unreference_unlocked(plane->bo);
}
kfree(omap_fb);
@@ -116,37 +123,76 @@ static const struct drm_framebuffer_funcs
omap_framebuffer_funcs = {
.dirty = omap_framebuffer_dirty,
};
-/* returns the buffer size */
-int omap_fr
Patches queued to drm-intel-fixes
Hi Keith, I've noticed that you merged my patch "rm/i915: properly prefault for pread/pwrite" into your -fixes branch (which I assume is headed for 3.2). Please remove that from your queue again for the following reasons: - The right thing to do is to fix up the prefault handlers in pagemap.h - It's really ugly code (which Chris Wilson later on complained about), so ugly actually that it confused you while reviewing it. - It changes the semantics of pread/pwrite in funny ways (something you actually complained about in review a while ago, too). - This bug has been lying around for almost half a year already, so I don't see the need for a rush now. - It only papers over the underlying issue, the real minimal and proper fix is queued up (and reviewed) in my-next in my own git repo for 3.3. - I actually managed to blow things up while playing with the prefault stuff, so it's imo not really risk-free. - But most important this late in the -rc cylce: It doesn't fix a regression. I've also noticed that you have my patch "drm/i915: check ACTHD of all rings" queued up in -fixes. I wouldn't have minded this getting merged a few weeks ago into an early -rc but again I think it's too late for this one for the following reasons: - It touches on the hangcheck code, one of the most important pieces to be able to debug issues and hence support users of our driver, but also one of the least tested ones (we essentially only test it when hitting actual hangs). - A similar patch by Ben Widawsky actually blew things up for Chris Wilson. - Again it doesn't fix a regression. Dave, please reject a pull request for 3.2 containing these patches - I've already embarrassed myself with the vt-d oneliner (which should imo have been merged about 4 weeks ago, but mea culpa). Yours, Daniel -- Daniel Vetter daniel.vetter at ffwll.ch - +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[drm] [radeon] [3.1.4] slub memory corruption in drm_vblank_cleanup
On 12/14/2011 12:31 AM, Jerome Glisse wrote: >> Allocated in drm_vblank_init+0x139/0x260 [drm] + Freed in >> drm_vblank_cleanup+0x78/0x90 [drm] >> Allocated in drm_vblank_init+0xbe/0x260 [drm] + Freed in >> drm_vblank_cleanup+0x48/0x90 [drm] >> >> It is Amd Bulldozer computer, with Radeon card: >> 01:00.0 VGA compatible controller: ATI Technologies Inc Cedar PRO >> [Radeon HD 5450] >> >>messages: http://pastebin.com/NXN5EPtG >> config used: http://pastebin.com/AeVxEX7c > > Do you boot your kernel with kexec ? Does the patch help : Nope. Already seen that kexec bugfix on LKML but I start system normally not with kexec. > http://people.freedesktop.org/~glisse/0001-drm-radeon-disable-possible-GPU-writeback-early-v3.patch > If not please open bug on bugs.freedesktop.org against radeon driver. ok
[Bug 43655] Latest radeon dri driver on HD6950 with kernel 3.2 flickers
https://bugs.freedesktop.org/show_bug.cgi?id=43655 --- Comment #4 from Alexandre Demers 2011-12-13 17:48:47 PST --- Strangely, when rebisecting, I found commit a34815b96f9a21b3a2e2912dfd0d994acd2855e3 to be the bad one... It is really near to the first one. So, I'm retesting both to be sure. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[drm] [radeon] [3.1.4] slub memory corruption in drm_vblank_cleanup
On 12/14/2011 12:47 AM, Jerome Glisse wrote: > On Tue, Dec 13, 2011 at 6:46 PM, Jerome Glisse wrote: >> On Tue, Dec 13, 2011 at 6:33 PM, batouzo wrote: >>> On 12/14/2011 12:31 AM, Jerome Glisse wrote: >>> > Allocated in drm_vblank_init+0x139/0x260 [drm] + Freed in > drm_vblank_cleanup+0x78/0x90 [drm] > Allocated in drm_vblank_init+0xbe/0x260 [drm] + Freed in > drm_vblank_cleanup+0x48/0x90 [drm] > > It is Amd Bulldozer computer, with Radeon card: > 01:00.0 VGA compatible controller: ATI Technologies Inc Cedar PRO > [Radeon HD 5450] > >messages: http://pastebin.com/NXN5EPtG > config used: http://pastebin.com/AeVxEX7c >>> Do you boot your kernel with kexec ? Does the patch help : >>> >>> Nope. Already seen that kexec bugfix on LKML but I start system normally >>> not with kexec. >>> http://people.freedesktop.org/~glisse/0001-drm-radeon-disable-possible-GPU-writeback-early-v3.patch If not please open bug on bugs.freedesktop.org against radeon driver. >>> >>> ok >>> >> >> Note that this patch might also help non kexec case. >> >> Cheers, >> Jerome > > Oh and try booting with radeon.no_wb=1 > > Cheers, > Jerome Using that patch on 3.1.4 results in locking for 60 seconds on startup, since it is now looking for firmware. This wait was not present without that patch. This looks familiar, like the 60 second wait when using netconsole caused by netconsole attempt to look for NIC card firmware too early (when / is not really mounted, just initramfs). I will report soon does it fix the crash; Though, the 60 second delay may influence the rarity of hitting BUG (it was the case with netconsole's 60sec wait). Should I just remove loading of this firmware? [1.386916] pci :03:06.0: calling quirk_usb_early_handoff+0x0/0x575 [1.386918] pci :03:06.0: calling pci_fixup_video+0x0/0xa6 [1.386925] PCI: CLS 64 bytes, default 64 [1.387113] Unpacking initramfs... [1.569824] Freeing initrd memory: 9080k freed [1.572659] pci :00:00.2: PCI INT A -> GSI 55 (level, low) -> IRQ 55 [1.572906] pci :00:00.2: irq 72 for MSI/MSI-X [1.573088] AMD-Vi: Enabling IOMMU at :00:00.2 cap 0x40 [1.634353] AMD-Vi: Lazy IO/TLB flushing enabled [1.634387] PCI-DMA: Using software bounce buffering for IO (SWIOTLB) [1.634421] Placing 64MB software IO TLB between 8800b9a5e000 - 8800bda5e000 [1.634456] software IO TLB at phys 0xb9a5e000 - 0xbda5e000 [1.639283] audit: initializing netlink socket (disabled) [1.639353] type=2000 audit(1323849178.636:1): initialized [1.648286] HugeTLB registered 2 MB page size, pre-allocated 0 pages [1.663115] VFS: Disk quotas dquot_6.5.2 [1.663309] Dquot-cache hash table entries: 512 (order 0, 4096 bytes) [1.663769] msgmni has been set to 7808 [1.664318] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253) [1.664353] io scheduler noop registered [1.664385] io scheduler deadline registered [1.664684] io scheduler cfq registered (default) [1.665691] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled [1.667276] [drm] Initialized drm 1.1.0 20060810 [1.667404] [drm] radeon defaulting to kernel modesetting. [1.667436] [drm] radeon kernel modesetting enabled. [1.667559] radeon :01:00.0: PCI INT A -> GSI 24 (level, low) -> IRQ 24 [1.667594] radeon :01:00.0: setting latency timer to 64 [1.668367] [drm] initializing kernel modesetting (CEDAR 0x1002:0x68F9 0x1458:0x21F1). [1.668455] [drm] register mmio base: 0xFEA2 [1.668487] [drm] register mmio size: 131072 [1.668685] ATOM BIOS: GV [1.668806] radeon :01:00.0: VRAM: 512M 0x - 0x1FFF (512M used) [1.668842] radeon :01:00.0: GTT: 512M 0x2000 - 0x3FFF [1.676059] [drm] Detected VRAM RAM=512M, BAR=256M [1.676094] [drm] RAM width 64bits DDR [1.676270] [TTM] Zone kernel: Available graphics memory: 1998922 kiB. [1.676303] [TTM] Initializing pool allocator. [1.676440] [drm] radeon: 512M of VRAM memory ready [1.676476] [drm] radeon: 512M of GTT memory ready. [1.676621] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [1.676655] [drm] Driver supports precise vblank timestamp query. [1.676759] radeon :01:00.0: irq 73 for MSI/MSI-X [1.676763] radeon :01:00.0: radeon: using MSI. [1.676903] [drm] radeon: irq initialized. [1.676941] [drm] GART: num cpu pages 131072, num gpu pages 131072 [1.677602] [drm] Loading CEDAR Microcode [2.636773] Refined TSC clocksource calibration: 3110.391 MHz. [2.636809] Switching to clocksource tsc [ 62.347154] r600_cp: Failed to load firmware "radeon/CEDAR_pfp.bin" [ 62.347189] [drm:evergreen_startup] *ERROR* Failed to load firmware! [ 62.347222] radeon :01:00.0: disabling GPU acceleration [ 62.348334] radeon :01:00.0: 8801364be9a0 unpin not necessar
[PATCH] libdrm: fix sizes of memcpy to the drmModeAddFB2()
The variables(bo_handles, pitches and offsets) are the array having 4 elementary of uint32_t type. The their memcpy size is sizeof(uint32_t) * 4. Signed-off-by: Joonyoung Shim --- xf86drmMode.c |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/xf86drmMode.c b/xf86drmMode.c index ffa6dc4..8065f20 100644 --- a/xf86drmMode.c +++ b/xf86drmMode.c @@ -267,9 +267,9 @@ int drmModeAddFB2(int fd, uint32_t width, uint32_t height, f.height = height; f.pixel_format = pixel_format; f.flags = flags; - memcpy(f.handles, bo_handles, sizeof(bo_handles)); - memcpy(f.pitches, pitches, sizeof(pitches)); - memcpy(f.offsets, offsets, sizeof(offsets)); + memcpy(f.handles, bo_handles, sizeof(uint32_t) * 4); + memcpy(f.pitches, pitches, sizeof(uint32_t) * 4); + memcpy(f.offsets, offsets, sizeof(uint32_t) * 4); if ((ret = DRM_IOCTL(fd, DRM_IOCTL_MODE_ADDFB2, &f))) return ret; -- 1.7.5.4
[PATCH v2 5/5] drm/exynos: Add plane support with fimd
The exynos fimd supports 5 window overlays. Only one window overlay of
fimd is used by the crtc, so we need plane feature to use the rest
window overlays.
This creates one ioctl exynos specific - DRM_EXYNOS_PLANE_SET_ZPOS, it
is the ioctl to decide for user to assign which window overlay.
Signed-off-by: Joonyoung Shim
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
v2: consider fixed point about src_x/src_y
drivers/gpu/drm/exynos/Makefile |3 +-
drivers/gpu/drm/exynos/exynos_drm_crtc.c|1 +
drivers/gpu/drm/exynos/exynos_drm_drv.c |9 ++
drivers/gpu/drm/exynos/exynos_drm_drv.h |8 +-
drivers/gpu/drm/exynos/exynos_drm_encoder.c | 26 -
drivers/gpu/drm/exynos/exynos_drm_encoder.h |2 +
drivers/gpu/drm/exynos/exynos_drm_fimd.c| 33 +--
drivers/gpu/drm/exynos/exynos_drm_plane.c | 156 +++
drivers/gpu/drm/exynos/exynos_drm_plane.h | 14 +++
include/drm/exynos_drm.h| 10 ++
10 files changed, 247 insertions(+), 15 deletions(-)
create mode 100644 drivers/gpu/drm/exynos/exynos_drm_plane.c
create mode 100644 drivers/gpu/drm/exynos/exynos_drm_plane.h
diff --git a/drivers/gpu/drm/exynos/Makefile b/drivers/gpu/drm/exynos/Makefile
index 0496d3f..c991272 100644
--- a/drivers/gpu/drm/exynos/Makefile
+++ b/drivers/gpu/drm/exynos/Makefile
@@ -5,7 +5,8 @@
ccflags-y := -Iinclude/drm -Idrivers/gpu/drm/exynos
exynosdrm-y := exynos_drm_drv.o exynos_drm_encoder.o exynos_drm_connector.o \
exynos_drm_crtc.o exynos_drm_fbdev.o exynos_drm_fb.o \
- exynos_drm_buf.o exynos_drm_gem.o exynos_drm_core.o
+ exynos_drm_buf.o exynos_drm_gem.o exynos_drm_core.o \
+ exynos_drm_plane.o
obj-$(CONFIG_DRM_EXYNOS) += exynosdrm.o
obj-$(CONFIG_DRM_EXYNOS_FIMD) += exynos_drm_fimd.o
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index a156f6c..7f22107 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -380,6 +380,7 @@ int exynos_drm_crtc_create(struct drm_device *dev, unsigned
int nr)
exynos_crtc->pipe = nr;
exynos_crtc->dpms = DRM_MODE_DPMS_OFF;
+ exynos_crtc->overlay.zpos = DEFAULT_ZPOS;
crtc = &exynos_crtc->drm_crtc;
private->crtc[nr] = crtc;
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index b86a04b..050684c 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -36,6 +36,7 @@
#include "exynos_drm_fbdev.h"
#include "exynos_drm_fb.h"
#include "exynos_drm_gem.h"
+#include "exynos_drm_plane.h"
#define DRIVER_NAME"exynos-drm"
#define DRIVER_DESC"Samsung SoC DRM"
@@ -77,6 +78,12 @@ static int exynos_drm_load(struct drm_device *dev, unsigned
long flags)
goto err_crtc;
}
+ for (nr = 0; nr < MAX_PLANE; nr++) {
+ ret = exynos_plane_init(dev, nr);
+ if (ret)
+ goto err_crtc;
+ }
+
ret = drm_vblank_init(dev, MAX_CRTC);
if (ret)
goto err_crtc;
@@ -163,6 +170,8 @@ static struct drm_ioctl_desc exynos_ioctls[] = {
DRM_AUTH),
DRM_IOCTL_DEF_DRV(EXYNOS_GEM_MMAP,
exynos_drm_gem_mmap_ioctl, DRM_UNLOCKED | DRM_AUTH),
+ DRM_IOCTL_DEF_DRV(EXYNOS_PLANE_SET_ZPOS, exynos_plane_set_zpos_ioctl,
+ DRM_UNLOCKED | DRM_AUTH),
};
static const struct file_operations exynos_drm_driver_fops = {
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index 8018798..8e8d8f0 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -33,6 +33,8 @@
#include "drm.h"
#define MAX_CRTC 2
+#define MAX_PLANE 5
+#define DEFAULT_ZPOS -1
struct drm_device;
struct exynos_drm_overlay;
@@ -57,8 +59,8 @@ enum exynos_drm_output_type {
struct exynos_drm_overlay_ops {
void (*mode_set)(struct device *subdrv_dev,
struct exynos_drm_overlay *overlay);
- void (*commit)(struct device *subdrv_dev);
- void (*disable)(struct device *subdrv_dev);
+ void (*commit)(struct device *subdrv_dev, int zpos);
+ void (*disable)(struct device *subdrv_dev, int zpos);
};
/*
@@ -83,6 +85,7 @@ struct exynos_drm_overlay_ops {
* @dma_addr: bus(accessed by dma) address to the memory region allocated
* for a overlay.
* @vaddr: virtual memory addresss to this overlay.
+ * @zpos: order of overlay layer(z position).
* @default_win: a window to be enabled.
* @color_key: color key on or off.
* @index_color: if using color key feature then this value would be used
@@ -111,6 +114,7 @@ struct exynos_drm_overlay {
unsigned int pitch;
dma_addr_t dma_addr;
void __iomem *vaddr;
+ int zp
Black screen with AMD A4-3300 support
2011-12-13 14:03 keltez?ssel, Joshua Roys ?rta: > On 12/13/2011 06:49 AM, Boszormenyi Zoltan wrote: >> I have a new ASUS K53TA notebook with AMD A4-3300 CPU >> and an extra Radeon HD6550M. I installed Fedora 16 on it but >> I get only black screen even during installation unless booted >> with nomodeset. But it's only VESA so there's no acceleration >> and there's no native LCD 1366x768 resolution, only 1024x768, >> so it's a bit blurry. >> > > Hello, > > Please see https://bugzilla.redhat.com/show_bug.cgi?id=753518 . (The HP > G4-1215DX also > has a AMD A4-3300.) After making the f16 kernel work, I ended up installing a > f17/rawhide kernel from > http://koji.fedoraproject.org/koji/packageinfo?packageID=8 to > fix other bugs, which will probably be the easiest solution for you. YES! Thankyouthankyouthankyou! :-) Now I have KMS. > I would be interested to hear if, after installing a newer kernel, > suspend/resume > worked for you. No, that doesn't work. I mean suspend works but not resume. There are a lot of reports in dmesg that looks like an Oops. Where should I report it? Here on the list or in RHBZ? Best regards, Zolt?n B?sz?rm?nyi
[PATCH] drm: integer overflow in drm_mode_dirtyfb_ioctl()
- Original Message - > From: "Eugene Teo" > To: "Xi Wang" > Cc: "David Airlie" , dri-devel at lists.freedesktop.org, > linux-kernel at vger.kernel.org, > security at kernel.org, "Dave Airlie" > Sent: Wednesday, 14 December, 2011 1:16:49 PM > Subject: Re: [PATCH] drm: integer overflow in drm_mode_dirtyfb_ioctl() > > Cc'ed Dave's work email. This is already in Linus tree, went there a while ago. a5cd335165e31db9dbab636fd29895d41da55dd2 Dave.
Black screen with AMD A4-3300 support
2011/12/14 Boszormenyi Zoltan : > 2011-12-13 14:03 keltez?ssel, Joshua Roys ?rta: >> On 12/13/2011 06:49 AM, Boszormenyi Zoltan wrote: >>> I have a new ASUS K53TA notebook with AMD A4-3300 CPU >>> and an extra Radeon HD6550M. I installed Fedora 16 on it but >>> I get only black screen even during installation unless booted >>> with nomodeset. But it's only VESA so there's no acceleration >>> and there's no native LCD 1366x768 resolution, only 1024x768, >>> so it's a bit blurry. >>> >> >> Hello, >> >> Please see https://bugzilla.redhat.com/show_bug.cgi?id=753518 . ?(The HP >> G4-1215DX also >> has a AMD A4-3300.) ?After making the f16 kernel work, I ended up installing >> a >> f17/rawhide kernel from >> http://koji.fedoraproject.org/koji/packageinfo?packageID=8 to >> fix other bugs, which will probably be the easiest solution for you. > > YES! Thankyouthankyouthankyou! :-) Now I have KMS. > >> ? I would be interested to hear if, after installing a newer kernel, >> suspend/resume >> worked for you. > > No, that doesn't work. I mean suspend works but not resume. > There are a lot of reports in dmesg that looks like an Oops. > Where should I report it? Here on the list or in RHBZ? Please file a bug: https://bugs.freedesktop.org and select DRI, then DRM/Radeon. Alex
[drm] [radeon] [3.1.4] slub memory corruption in drm_vblank_cleanup
On Wed, Dec 14, 2011 at 2:00 AM, batouzo wrote: > On 12/14/2011 12:47 AM, Jerome Glisse wrote: >> On Tue, Dec 13, 2011 at 6:46 PM, Jerome Glisse wrote: >>> On Tue, Dec 13, 2011 at 6:33 PM, batouzo wrote: On 12/14/2011 12:31 AM, Jerome Glisse wrote: >> Allocated in drm_vblank_init+0x139/0x260 [drm] + Freed in >> drm_vblank_cleanup+0x78/0x90 [drm] >> Allocated in drm_vblank_init+0xbe/0x260 [drm] + Freed in >> drm_vblank_cleanup+0x48/0x90 [drm] >> >> It is Amd Bulldozer computer, with Radeon card: >> 01:00.0 VGA compatible controller: ATI Technologies Inc Cedar PRO >> [Radeon HD 5450] >> >> ? ?messages: http://pastebin.com/NXN5EPtG >> config used: http://pastebin.com/AeVxEX7c > > Do you boot your kernel with kexec ? Does the patch help : Nope. Already seen that kexec bugfix on LKML but I start system normally not with kexec. > http://people.freedesktop.org/~glisse/0001-drm-radeon-disable-possible-GPU-writeback-early-v3.patch > If not please open bug on bugs.freedesktop.org against radeon driver. ok >>> >>> Note that this patch might also help non kexec case. >>> >>> Cheers, >>> Jerome >> >> Oh and try booting with radeon.no_wb=1 >> >> Cheers, >> Jerome > > Using that patch on 3.1.4 results in locking for 60 seconds on startup, > since it is now looking for firmware. > > This wait was not present without that patch. > > This looks familiar, like the 60 second wait when using netconsole > caused by netconsole attempt to look for NIC card firmware too early > (when / is not really mounted, just initramfs). > > I will report soon does it fix the crash; > > Though, the 60 second delay may influence the rarity of hitting BUG (it > was the case with netconsole's 60sec wait). > Should I just remove loading of this firmware? > Make sure the ucode is available in your initrd or kernel image or filesystem depending on how you are loading the driver. The driver has much more limited functionality without the ucode (no acceleration support, no interrupt support). You may not hit the bug at all due to the reduced functionality. Alex > > > > [ ? ?1.386916] pci :03:06.0: calling quirk_usb_early_handoff+0x0/0x575 > [ ? ?1.386918] pci :03:06.0: calling pci_fixup_video+0x0/0xa6 > [ ? ?1.386925] PCI: CLS 64 bytes, default 64 > [ ? ?1.387113] Unpacking initramfs... > [ ? ?1.569824] Freeing initrd memory: 9080k freed > [ ? ?1.572659] pci :00:00.2: PCI INT A -> GSI 55 (level, low) -> IRQ 55 > [ ? ?1.572906] pci :00:00.2: irq 72 for MSI/MSI-X > [ ? ?1.573088] AMD-Vi: Enabling IOMMU at :00:00.2 cap 0x40 > [ ? ?1.634353] AMD-Vi: Lazy IO/TLB flushing enabled > [ ? ?1.634387] PCI-DMA: Using software bounce buffering for IO (SWIOTLB) > [ ? ?1.634421] Placing 64MB software IO TLB between 8800b9a5e000 - > 8800bda5e000 > [ ? ?1.634456] software IO TLB at phys 0xb9a5e000 - 0xbda5e000 > [ ? ?1.639283] audit: initializing netlink socket (disabled) > [ ? ?1.639353] type=2000 audit(1323849178.636:1): initialized > [ ? ?1.648286] HugeTLB registered 2 MB page size, pre-allocated 0 pages > [ ? ?1.663115] VFS: Disk quotas dquot_6.5.2 > [ ? ?1.663309] Dquot-cache hash table entries: 512 (order 0, 4096 bytes) > [ ? ?1.663769] msgmni has been set to 7808 > [ ? ?1.664318] Block layer SCSI generic (bsg) driver version 0.4 loaded > (major 253) > [ ? ?1.664353] io scheduler noop registered > [ ? ?1.664385] io scheduler deadline registered > [ ? ?1.664684] io scheduler cfq registered (default) > [ ? ?1.665691] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled > [ ? ?1.667276] [drm] Initialized drm 1.1.0 20060810 > [ ? ?1.667404] [drm] radeon defaulting to kernel modesetting. > [ ? ?1.667436] [drm] radeon kernel modesetting enabled. > [ ? ?1.667559] radeon :01:00.0: PCI INT A -> GSI 24 (level, low) -> > IRQ 24 > [ ? ?1.667594] radeon :01:00.0: setting latency timer to 64 > [ ? ?1.668367] [drm] initializing kernel modesetting (CEDAR > 0x1002:0x68F9 0x1458:0x21F1). > [ ? ?1.668455] [drm] register mmio base: 0xFEA2 > [ ? ?1.668487] [drm] register mmio size: 131072 > [ ? ?1.668685] ATOM BIOS: GV > [ ? ?1.668806] radeon :01:00.0: VRAM: 512M 0x - > 0x1FFF (512M used) > [ ? ?1.668842] radeon :01:00.0: GTT: 512M 0x2000 - > 0x3FFF > [ ? ?1.676059] [drm] Detected VRAM RAM=512M, BAR=256M > [ ? ?1.676094] [drm] RAM width 64bits DDR > [ ? ?1.676270] [TTM] Zone ?kernel: Available graphics memory: 1998922 kiB. > [ ? ?1.676303] [TTM] Initializing pool allocator. > [ ? ?1.676440] [drm] radeon: 512M of VRAM memory ready > [ ? ?1.676476] [drm] radeon: 512M of GTT memory ready. > [ ? ?1.676621] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). > [ ? ?1.676655] [drm] Driver supports precise vblank timestamp query. > [ ? ?1.676759] radeon :01:00.0: irq 73 for MSI/MSI-X > [ ? ?1.676763] radeon :01:00.0: radeon: using MSI. > [ ? ?1.676903] [drm
[PATCH] drm: Enable reading 3D capabilities of 3D monitor
UINCUNX */
> + }
Here you've made it clear that ->format is a bitfield, but the values
should be in a header (so drivers can use them) and this code should
only be using the symbolic names.
> @@ -1675,6 +1783,7 @@ static void drm_add_display_info(struct edid *edid,
> return;
>
> info->cea_rev = edid_ext[1];
> + info->caps_3D= drm_detect_3D_monitor(edid);
> }
>
> /**
Whitespace.
> +/* Pre-defined 3D formats as per HDMI spec */
> +enum s3d_formats {
> +FRAME_PACKING = 0x0,
> +FIELD_ALTERNATIVE = 0x1,
> +LINE_ALTERNATIVE= 0x2,
> +SIDE_BY_SIDE_FULL = 0x3,
> +L_DEPTH = 0x4,
> +L_DEPTH_GFX_GFX_DEPTH = 0x5,
> +TOP_BOTTOM = 0x6, /* 0x7 is reserved for future */
> +SIDE_BY_SIDE_HALF = 0x8 /* 0x9 onwards is reserved for future
> */
> +};
These don't match the bit shifts you used earlier.
- ajax
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20111214/cb789388/attachment.pgp>
[Bug 43829] New: Resuming my AMD A4-300 based laptop leaves the screen black
https://bugs.freedesktop.org/show_bug.cgi?id=43829 Bug #: 43829 Summary: Resuming my AMD A4-300 based laptop leaves the screen black Classification: Unclassified Product: DRI Version: XOrg CVS Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: DRM/Radeon AssignedTo: dri-devel at lists.freedesktop.org ReportedBy: zboszor at pr.hu Created attachment 54422 --> https://bugs.freedesktop.org/attachment.cgi?id=54422 dmesg showing suspend/resume I have installed Fedora 16 on my new ASUS K53TA laptop that has these devices: # lspci 00:00.0 Host bridge: Advanced Micro Devices [AMD] Family 12h Processor Root Complex 00:01.0 VGA compatible controller: ATI Technologies Inc Device 9648 00:01.1 Audio device: ATI Technologies Inc Device 1714 00:02.0 PCI bridge: Advanced Micro Devices [AMD] Family 12h Processor Root Port 00:04.0 PCI bridge: Advanced Micro Devices [AMD] Family 12h Processor Root Port 00:05.0 PCI bridge: Advanced Micro Devices [AMD] Family 12h Processor Root Port 00:10.0 USB controller: Advanced Micro Devices [AMD] Hudson USB XHCI Controller (rev 03) 00:11.0 SATA controller: Advanced Micro Devices [AMD] Hudson SATA Controller [AHCI mode] (rev 40) 00:12.0 USB controller: Advanced Micro Devices [AMD] Hudson USB OHCI Controller (rev 11) 00:12.2 USB controller: Advanced Micro Devices [AMD] Hudson USB EHCI Controller (rev 11) 00:14.0 SMBus: Advanced Micro Devices [AMD] Hudson SMBus Controller (rev 13) 00:14.2 Audio device: Advanced Micro Devices [AMD] Hudson Azalia Controller (rev 01) 00:14.3 ISA bridge: Advanced Micro Devices [AMD] Hudson LPC Bridge (rev 11) 00:14.4 PCI bridge: Advanced Micro Devices [AMD] Hudson PCI Bridge (rev 40) 00:14.7 SD Host controller: Advanced Micro Devices [AMD] Hudson SD Flash Controller 00:18.0 Host bridge: Advanced Micro Devices [AMD] Family 12h/14h Processor Function 0 (rev 43) 00:18.1 Host bridge: Advanced Micro Devices [AMD] Family 12h/14h Processor Function 1 00:18.2 Host bridge: Advanced Micro Devices [AMD] Family 12h/14h Processor Function 2 00:18.3 Host bridge: Advanced Micro Devices [AMD] Family 12h/14h Processor Function 3 00:18.4 Host bridge: Advanced Micro Devices [AMD] Family 12h/14h Processor Function 4 00:18.5 Host bridge: Advanced Micro Devices [AMD] Family 12h/14h Processor Function 6 00:18.6 Host bridge: Advanced Micro Devices [AMD] Family 12h/14h Processor Function 5 00:18.7 Host bridge: Advanced Micro Devices [AMD] Family 12h/14h Processor Function 7 01:00.0 VGA compatible controller: ATI Technologies Inc Whistler [AMD Radeon HD 6600M Series] (rev ff) 02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 06) 03:00.0 Network controller: Atheros Communications Inc. AR9285 Wireless Network Adapter (PCI-Express) (rev 01) I had to install kernel-3.2.0-0.rc5.git1.1.fc17.x86_64 from Rawhide to make KMS work on the integrated video. I tried suspend/resume by closing the lid, suspend worked. Resume woke up the machine but left the screen black. dmesg for the suspend/resume is attached. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Black screen with AMD A4-3300 support
2011-12-14 15:02 keltez?ssel, Alex Deucher ?rta: > 2011/12/14 Boszormenyi Zoltan : >> 2011-12-13 14:03 keltez?ssel, Joshua Roys ?rta: >>> On 12/13/2011 06:49 AM, Boszormenyi Zoltan wrote: I have a new ASUS K53TA notebook with AMD A4-3300 CPU and an extra Radeon HD6550M. I installed Fedora 16 on it but I get only black screen even during installation unless booted with nomodeset. But it's only VESA so there's no acceleration and there's no native LCD 1366x768 resolution, only 1024x768, so it's a bit blurry. >>> Hello, >>> >>> Please see https://bugzilla.redhat.com/show_bug.cgi?id=753518 . (The HP >>> G4-1215DX also >>> has a AMD A4-3300.) After making the f16 kernel work, I ended up >>> installing a >>> f17/rawhide kernel from >>> http://koji.fedoraproject.org/koji/packageinfo?packageID=8 to >>> fix other bugs, which will probably be the easiest solution for you. >> YES! Thankyouthankyouthankyou! :-) Now I have KMS. >> >>> I would be interested to hear if, after installing a newer kernel, >>> suspend/resume >>> worked for you. >> No, that doesn't work. I mean suspend works but not resume. >> There are a lot of reports in dmesg that looks like an Oops. >> Where should I report it? Here on the list or in RHBZ? > Please file a bug: > https://bugs.freedesktop.org > and select DRI, then DRM/Radeon. > > Alex Done, bug #43829 Best regards, Zolt?n B?sz?rm?nyi
[drm] [radeon] [3.1.4] slub memory corruption in drm_vblank_cleanup
On Wed, Dec 14, 2011 at 08:00:04AM +0100, batouzo wrote: > On 12/14/2011 12:47 AM, Jerome Glisse wrote: > > On Tue, Dec 13, 2011 at 6:46 PM, Jerome Glisse > > wrote: > >> On Tue, Dec 13, 2011 at 6:33 PM, batouzo wrote: > >>> On 12/14/2011 12:31 AM, Jerome Glisse wrote: > >>> > > Allocated in drm_vblank_init+0x139/0x260 [drm] + Freed in > > drm_vblank_cleanup+0x78/0x90 [drm] > > Allocated in drm_vblank_init+0xbe/0x260 [drm] + Freed in > > drm_vblank_cleanup+0x48/0x90 [drm] > > > > It is Amd Bulldozer computer, with Radeon card: > > 01:00.0 VGA compatible controller: ATI Technologies Inc Cedar PRO > > [Radeon HD 5450] > > > >messages: http://pastebin.com/NXN5EPtG > > config used: http://pastebin.com/AeVxEX7c > >>> > > Do you boot your kernel with kexec ? Does the patch help : > >>> > >>> Nope. Already seen that kexec bugfix on LKML but I start system normally > >>> not with kexec. > >>> > http://people.freedesktop.org/~glisse/0001-drm-radeon-disable-possible-GPU-writeback-early-v3.patch > If not please open bug on bugs.freedesktop.org against radeon driver. > >>> > >>> ok > >>> > >> > >> Note that this patch might also help non kexec case. > >> > >> Cheers, > >> Jerome > > > > Oh and try booting with radeon.no_wb=1 > > > > Cheers, > > Jerome > > Using that patch on 3.1.4 results in locking for 60 seconds on startup, > since it is now looking for firmware. > > This wait was not present without that patch. > > This looks familiar, like the 60 second wait when using netconsole > caused by netconsole attempt to look for NIC card firmware too early > (when / is not really mounted, just initramfs). > > I will report soon does it fix the crash; > > Though, the 60 second delay may influence the rarity of hitting BUG (it > was the case with netconsole's 60sec wait). > Should I just remove loading of this firmware? > That patch doesn't change anything in regard of firmware. You need firmware for GPU to be use otherwise kms is just a fancy framebuffer driver. Cheers, Jerome
[drm] [radeon] [3.1.4] slub memory corruption in drm_vblank_cleanup
On 12/14/2011 03:10 PM, Alex Deucher wrote: >> Though, the 60 second delay may influence the rarity of hitting BUG (it >> was the case with netconsole's 60sec wait). >> Should I just remove loading of this firmware? >> > Make sure the ucode is available in your initrd or kernel image or > filesystem depending on how you are loading the driver. The driver > has much more limited functionality without the ucode (no acceleration > support, no interrupt support). You may not hit the bug at all due to > the reduced functionality. Actually, where is that file? Can't find CEDAR_pfp.bin or even any "*CEDAR*" in entire filesystem where I build the kernel. Also I tried CONFIG_FIRMWARE_IN_KERNEL=y but it didn't helped, hm. >> [ 62.347154] r600_cp: Failed to load firmware "radeon/CEDAR_pfp.bin" >> [ 62.347189] [drm:evergreen_startup] *ERROR* Failed to load firmware! >> [ 62.347222] radeon :01:00.0: disabling GPU acceleration
[drm] [radeon] [3.1.4] slub memory corruption in drm_vblank_cleanup
On Wed, Dec 14, 2011 at 11:32 AM, batouzo wrote: > On 12/14/2011 03:10 PM, Alex Deucher wrote: > >>> Though, the 60 second delay may influence the rarity of hitting BUG (it >>> was the case with netconsole's 60sec wait). >>> Should I just remove loading of this firmware? >>> >> Make sure the ucode is available in your initrd or kernel image or >> filesystem depending on how you are loading the driver. ?The driver >> has much more limited functionality without the ucode (no acceleration >> support, no interrupt support). ?You may not hit the bug at all due to >> the reduced functionality. > > Actually, where is that file? Can't find CEDAR_pfp.bin or even any > "*CEDAR*" in entire filesystem where I build the kernel. > > Also I tried CONFIG_FIRMWARE_IN_KERNEL=y > but it didn't helped, hm. > You need to grab them from here: http://git.kernel.org/?p=linux/kernel/git/dwmw2/linux-firmware.git Alex > >>> [ ? 62.347154] r600_cp: Failed to load firmware "radeon/CEDAR_pfp.bin" >>> [ ? 62.347189] [drm:evergreen_startup] *ERROR* Failed to load firmware! >>> [ ? 62.347222] radeon :01:00.0: disabling GPU acceleration > > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 43835] New: System crashes when radeon firmware blob (R520_cp.bin) is installed
https://bugs.freedesktop.org/show_bug.cgi?id=43835
Bug #: 43835
Summary: System crashes when radeon firmware blob (R520_cp.bin)
is installed
Classification: Unclassified
Product: DRI
Version: XOrg CVS
Platform: Other
URL: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=65153
2
OS/Version: All
Status: NEW
Severity: normal
Priority: medium
Component: DRM/Radeon
AssignedTo: dri-devel at lists.freedesktop.org
ReportedBy: noelamac at gmail.com
Created attachment 54426
--> https://bugs.freedesktop.org/attachment.cgi?id=54426
Logs ("dmesg" and "xorg.0.log" for kernels 3.2-rc4 and 3.1 with and without the
firmware installed)
1. Steps to reproduce the problem
Running Debian Wheezy, by installing the package "firmware-linux-nonfree" which
contains the firmware to enable 3D acceleration for the ATI card (M56P Radeon
Mobility X1600), when the system starts and user logins, the system crashes (no
specific action triggers the crash, is just about time to get it).
2. Symptoms
The user receives a "kernel oops" (kernel 3.1) or system hangs with a trace
(kernel 3.2-rc4) and system locks.
3. Tested kernels
The user has tested kernel 3.1 (Wheezy's stock kernel) and 3.2-rc4 (from
Debian's experimental branch). Both kernels expose the same result when
firmware is installed. On the other hand, both kernels work fine as soon as the
firmware package is unistalled.
4. Additional information
The crash has been tracked in Debian BTS #651532 (full link available in the
URL field).
5. Attached logs (4 files):
- "dmesg" and "Xorg.0.log" for kernels 3.2-rc4 and 3.1 when firmware is
installed.
- "dmesg" and "Xorg.0.log" for kernels 3.2-rc4 and 3.1 when firmware is not
installed.
6. Other considerations
Please, note that I am opening the this bug on behalf of another person who is
experiencing the crash. For this reason I'm CC'ing to him.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
[drm] [radeon] [3.1.4] slub memory corruption in drm_vblank_cleanup
On 12/14/2011 05:40 PM, Alex Deucher wrote: > On Wed, Dec 14, 2011 at 11:32 AM, batouzo wrote: >> On 12/14/2011 03:10 PM, Alex Deucher wrote: >> Though, the 60 second delay may influence the rarity of hitting BUG (it was the case with netconsole's 60sec wait). Should I just remove loading of this firmware? >>> Make sure the ucode is available in your initrd or kernel image or >>> filesystem depending on how you are loading the driver. The driver >>> has much more limited functionality without the ucode (no acceleration >>> support, no interrupt support). You may not hit the bug at all due to >>> the reduced functionality. >> >> Actually, where is that file? Can't find CEDAR_pfp.bin or even any >> "*CEDAR*" in entire filesystem where I build the kernel. >> >> Also I tried CONFIG_FIRMWARE_IN_KERNEL=y >> but it didn't helped, hm. >> > > You need to grab them from here: > http://git.kernel.org/?p=linux/kernel/git/dwmw2/linux-firmware.git Ok I see. Is there a pubkey signed version of that available, or what is the safe-download procedure (as with kernl.org .tar's + .sign for kernels)?
[PATCH] drm: integer overflow in drm_mode_dirtyfb_ioctl()
On Wed, Dec 14, 2011 at 08:34:29AM -0500, David Airlie wrote: > > - Original Message - > > From: "Eugene Teo" > > To: "Xi Wang" > > Cc: "David Airlie" , dri-devel at > > lists.freedesktop.org, linux-kernel at vger.kernel.org, > > security at kernel.org, "Dave Airlie" > > Sent: Wednesday, 14 December, 2011 1:16:49 PM > > Subject: Re: [PATCH] drm: integer overflow in drm_mode_dirtyfb_ioctl() > > > > Cc'ed Dave's work email. > > This is already in Linus tree, went there a while ago. > > a5cd335165e31db9dbab636fd29895d41da55dd2 And it was in the 3.0.13 and 3.1.5 kernel releases. greg k-h
[Bug 43835] System crashes when radeon firmware blob (R520_cp.bin) is installed
https://bugs.freedesktop.org/show_bug.cgi?id=43835 --- Comment #1 from Alex Deucher 2011-12-14 09:19:34 PST --- In the future, please attach the dmesg and log files directly. It looks like it's a problem with acceleration (which is available without the firmware). I don't see any oops or backtraces in the logs. Can you attach the oops or get a picture of it? Does setting: Option "NoAccel" "True" in the device section of your xorg.conf fix the problem? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[drm] [radeon] [3.1.4] slub memory corruption in drm_vblank_cleanup
On Wed, Dec 14, 2011 at 12:12 PM, batouzo wrote: > On 12/14/2011 05:40 PM, Alex Deucher wrote: >> On Wed, Dec 14, 2011 at 11:32 AM, batouzo wrote: >>> On 12/14/2011 03:10 PM, Alex Deucher wrote: >>> > Though, the 60 second delay may influence the rarity of hitting BUG (it > was the case with netconsole's 60sec wait). > Should I just remove loading of this firmware? > Make sure the ucode is available in your initrd or kernel image or filesystem depending on how you are loading the driver. ?The driver has much more limited functionality without the ucode (no acceleration support, no interrupt support). ?You may not hit the bug at all due to the reduced functionality. >>> >>> Actually, where is that file? Can't find CEDAR_pfp.bin or even any >>> "*CEDAR*" in entire filesystem where I build the kernel. >>> >>> Also I tried CONFIG_FIRMWARE_IN_KERNEL=y >>> but it didn't helped, hm. >>> >> >> You need to grab them from here: >> http://git.kernel.org/?p=linux/kernel/git/dwmw2/linux-firmware.git > > Ok I see. > > Is there a pubkey signed version of that available, or what is the > safe-download procedure (as with kernl.org .tar's + .sign for kernels)? > You can download/compare with my tree: http://people.freedesktop.org/~agd5f/radeon_ucode/ Alex > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 43835] System crashes when radeon firmware blob (R520_cp.bin) is installed
https://bugs.freedesktop.org/show_bug.cgi?id=43835 --- Comment #2 from Alex Deucher 2011-12-14 09:22:37 PST --- which is NOT available without the firmware -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH v2 5/5] drm/exynos: Add plane support with fimd
On Wed, 14 Dec 2011 19:00:15 +0900 Joonyoung Shim wrote: > The exynos fimd supports 5 window overlays. Only one window overlay of > fimd is used by the crtc, so we need plane feature to use the rest > window overlays. > > This creates one ioctl exynos specific - DRM_EXYNOS_PLANE_SET_ZPOS, it > is the ioctl to decide for user to assign which window overlay. > > Signed-off-by: Joonyoung Shim > Signed-off-by: Inki Dae > Signed-off-by: Kyungmin Park > --- > v2: consider fixed point about src_x/src_y Looks pretty good; the only thing that jumped out was that you don't seem to be validating the zpos ioctl parameters for sanity. Not sure if there's much to do, but it may be worth checking for a max zpos or something... -- Jesse Barnes, Intel Open Source Technology Center
[git pull] drm fixes
Hi Linus, simple one just one pci ids patch from Alex, I know Keith has some patches outstanding in his queue and I know they are probably more than you'll want to merge at this point, I'm off until next week, so Keith if you do send a pull request you may as well send to Linus, since I know Linus can be more lenient on pulls which make the hw he uses suck less :-) The following changes since commit 45e713efe2fa574b6662e7fb63fae9497c5e03d4: Merge branch 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip (2011-12-05 16:54:15 -0800) are available in the git repository at: git://people.freedesktop.org/~airlied/linux drm-fixes Alex Deucher (1): drm/radeon/kms: fix return type for radeon_encoder_get_dp_bridge_encoder_id Daniel Vetter (1): drm/i915: fix infinite recursion on unbind due to ilk vt-d w/a Thomas Meyer (1): vmwgfx: Use kcalloc instead of kzalloc to allocate array drivers/gpu/drm/i915/i915_gem.c |7 ++- drivers/gpu/drm/radeon/radeon_encoders.c |7 +++ drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c|4 ++-- 3 files changed, 11 insertions(+), 7 deletions(-)
[drm] [radeon] [3.1.4] slub memory corruption in drm_vblank_cleanup
On 12/14/2011 06:21 PM, Alex Deucher wrote: > On Wed, Dec 14, 2011 at 12:12 PM, batouzo wrote: >> On 12/14/2011 05:40 PM, Alex Deucher wrote: >>> On Wed, Dec 14, 2011 at 11:32 AM, batouzo wrote: On 12/14/2011 03:10 PM, Alex Deucher wrote: >> Though, the 60 second delay may influence the rarity of hitting BUG (it >> was the case with netconsole's 60sec wait). >> Should I just remove loading of this firmware? >> > Make sure the ucode is available in your initrd or kernel image or > filesystem depending on how you are loading the driver. The driver > has much more limited functionality without the ucode (no acceleration > support, no interrupt support). You may not hit the bug at all due to > the reduced functionality. Actually, where is that file? Can't find CEDAR_pfp.bin or even any "*CEDAR*" in entire filesystem where I build the kernel. Also I tried CONFIG_FIRMWARE_IN_KERNEL=y but it didn't helped, hm. >>> >>> You need to grab them from here: >>> http://git.kernel.org/?p=linux/kernel/git/dwmw2/linux-firmware.git >> >> Ok I see. >> >> Is there a pubkey signed version of that available, or what is the >> safe-download procedure (as with kernl.org .tar's + .sign for kernels)? >> > > You can download/compare with my tree: > http://people.freedesktop.org/~agd5f/radeon_ucode/ > > Alex > > >> ___ >> dri-devel mailing list >> dri-devel at lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/dri-devel Thanks. Is this firmware a closed source binary blob? Or open source, only uploaded to the card on init? Who develops it / where to get the source code, and how to build that file from sources? This means that entire firmeware of GFX card is flashed on bootup? Btw this is a form of virus protection you could say (or anyway such firmware is volatile and lost on reboot?)
[git pull] drm fixes
(ignore original, this one comes with a believable changelog). > Hi Linus, > > simple one just one pci ids patch from Alex, > > I know Keith has some patches outstanding in his queue and I know they are > probably more than you'll want to merge at this point, I'm off until next > week, so Keith if you do send a pull request you may as well send to > Linus, since I know Linus can be more lenient on pulls which make the hw > he uses suck less :-) > The following changes since commit 373da0a2a33018d560afcb2c77f8842985d79594: Merge branch 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip (2011-12-13 15:02:31 -0800) are available in the git repository at: git://people.freedesktop.org/~airlied/linux drm-fixes Alex Deucher (1): drm/radeon/kms: add some new pci ids include/drm/drm_pciids.h | 10 ++ 1 files changed, 10 insertions(+), 0 deletions(-)
[drm] [radeon] [3.1.4] slub memory corruption in drm_vblank_cleanup
On Wed, Dec 14, 2011 at 12:27 PM, batouzo wrote: > On 12/14/2011 06:21 PM, Alex Deucher wrote: >> On Wed, Dec 14, 2011 at 12:12 PM, batouzo wrote: >>> On 12/14/2011 05:40 PM, Alex Deucher wrote: On Wed, Dec 14, 2011 at 11:32 AM, batouzo wrote: > On 12/14/2011 03:10 PM, Alex Deucher wrote: > >>> Though, the 60 second delay may influence the rarity of hitting BUG (it >>> was the case with netconsole's 60sec wait). >>> Should I just remove loading of this firmware? >>> >> Make sure the ucode is available in your initrd or kernel image or >> filesystem depending on how you are loading the driver. ?The driver >> has much more limited functionality without the ucode (no acceleration >> support, no interrupt support). ?You may not hit the bug at all due to >> the reduced functionality. > > Actually, where is that file? Can't find CEDAR_pfp.bin or even any > "*CEDAR*" in entire filesystem where I build the kernel. > > Also I tried CONFIG_FIRMWARE_IN_KERNEL=y > but it didn't helped, hm. > You need to grab them from here: http://git.kernel.org/?p=linux/kernel/git/dwmw2/linux-firmware.git >>> >>> Ok I see. >>> >>> Is there a pubkey signed version of that available, or what is the >>> safe-download procedure (as with kernl.org .tar's + .sign for kernels)? >>> >> >> You can download/compare with my tree: >> http://people.freedesktop.org/~agd5f/radeon_ucode/ >> >> Alex >> >> >>> ___ >>> dri-devel mailing list >>> dri-devel at lists.freedesktop.org >>> http://lists.freedesktop.org/mailman/listinfo/dri-devel > > Thanks. > > Is this firmware a closed source binary blob? > Or open source, only uploaded to the card on init? > It's closed source and only uploaded to the card on init. > Who develops it / where to get the source code, and how to build that > file from sources? AMD develops and releases the ucode images. No source is available. > > This means that entire firmeware of GFX card is flashed on bootup? > Btw this is a form of virus protection you could say (or anyway such > firmware is volatile and lost on reboot?) The ucode is volatile and is lost on reboot. The different ucode images are used for different things. The PFP and ME ucode images provide the acceleration API and the RLC ucode is required to make the interrupt controller work. On newer asics, the MC ucode is used for the gddr5 controller on the chip and is required to link train the memory so it will run at full speed. Alex > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
[drm] [radeon] [3.1.4] slub memory corruption in drm_vblank_cleanup
On 12/14/2011 06:40 PM, Alex Deucher wrote: > On Wed, Dec 14, 2011 at 12:27 PM, batouzo wrote: > AMD develops and releases the ucode images. No source is available. > >> >> This means that entire firmeware of GFX card is flashed on bootup? >> Btw this is a form of virus protection you could say (or anyway such >> firmware is volatile and lost on reboot?) > > The ucode is volatile and is lost on reboot. The different ucode > images are used for different things. The PFP and ME ucode images > provide the acceleration API and the RLC ucode is required to make the > interrupt controller work. On newer asics, the MC ucode is used for > the gddr5 controller on the chip and is required to link train the > memory so it will run at full speed. Thanks for explanation. I hoped using radeon and KMS I'm choosing the "good" (secure / FOSS philosophy etc) solution, but it seems to not be the case then. What should one do to have 100% opensource, maximally secure X on radeon cards? Maybe I should disable firmware to achieve this goal at cost of performance - or may disabling firmware actually introduce any security/stability problems? Would Intel build-in card be better for this use? Any particular family?
[Bug 43835] System crashes when radeon firmware blob (R520_cp.bin) is installed
https://bugs.freedesktop.org/show_bug.cgi?id=43835 --- Comment #3 from Camale?n 2011-12-14 09:56:05 PST --- (In reply to comment #1) > In the future, please attach the dmesg and log files directly. Will do, sorry. > It looks like it's a problem with acceleration (which is available without > the firmware). I don't see any oops or backtraces in the logs. Can you > attach the oops or get a picture of it? Kernel oops and backtrace are available at Debian bug. Direct links: - Kernel 3.1 (syslog) http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=5;filename=20111209_syslog_kernel_oops.txt;att=1;bug=651532 (snapshot) http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=5;filename=20111209_snapshot_kernel_oops.jpg;att=4;bug=651532 - Kernel 3.2-rc4 (syslog) http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=21;filename=20111212_syslog_kernel_3_2_rc3;att=2;bug=651532 (snapshot) http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=21;filename=20111212_snapshot_kernel_trace.jpg;att=1;bug=651532 I can attach the files to this bug report if you find it convenient. > Does setting: > Option "NoAccel" "True" > in the device section of your xorg.conf fix the problem? I have asked the user to try with this option while having the firmware package installed, will report back as soon as I get the results. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[drm] [radeon] [3.1.4] slub memory corruption in drm_vblank_cleanup
On Wed, Dec 14, 2011 at 12:49 PM, batouzo wrote: > On 12/14/2011 06:40 PM, Alex Deucher wrote: >> On Wed, Dec 14, 2011 at 12:27 PM, batouzo wrote: > >> AMD develops and releases the ucode images. ?No source is available. >> >>> >>> This means that entire firmeware of GFX card is flashed on bootup? >>> Btw this is a form of virus protection you could say (or anyway such >>> firmware is volatile and lost on reboot?) >> >> The ucode is volatile and is lost on reboot. ?The different ucode >> images are used for different things. ?The PFP and ME ucode images >> provide the acceleration API and the RLC ucode is required to make the >> interrupt controller work. ?On newer asics, the MC ucode is used for >> the gddr5 controller on the chip and is required to link train the >> memory so it will run at full speed. > > Thanks for explanation. > > I hoped using radeon and KMS I'm choosing the "good" (secure / FOSS > philosophy etc) solution, but it seems to not be the case then. > > What should one do to have 100% opensource, maximally secure X on radeon > cards? > Maybe I should disable firmware to achieve this goal at cost of > performance - or may disabling firmware actually introduce any > security/stability problems? I don't want to get into a philosophical discussion about firmware. It's required for proper operation on radeon cards. Not using it will disable acceleration and interrupts and is overall not well tested/supported. On newer asics that require the MC ucode, the MC ucode is required to use the card at all as the boot up state is only enough to light up the screen. Alex
[PATCH 2/2] drm/omap: drm API update: addfb2
On Tue, Dec 13, 2011 at 08:18:03PM -0600, Rob Clark wrote: > On Mon, Dec 12, 2011 at 6:56 PM, Greg KH wrote: > > On Mon, Dec 12, 2011 at 06:49:44PM -0600, Rob Clark wrote: > >> From: Rob Clark > >> > >> Update to reflect changes in: > >> "drm: add an fb creation ioctl that takes a pixel format v5" > > > > This one I'm going to have to wait for the drm api merges to happen, so > > I'll just wait for them to go into Linus's tree before taking them, ok? > > oh, heh.. I found a couple small cleanups to this patch (adding a > "const" to a table, and such).. since this can't be applied until > drm-next is merged, if you don't mind I'd like to resend this one in a > patchset along with the patches adding drm_plane support, which I'm > pretty close to ready to send. Ok, I've dropped it from my queue now. greg k-h
[Bug 43698] On PPC, OpenGL programs use incorrect texture colors.
https://bugs.freedesktop.org/show_bug.cgi?id=43698 --- Comment #7 from GhostlyDeath 2011-12-14 11:11:21 PST --- This only affects textures, whether they were created with image loading or if they were created with PBOs. Anything that does not use textures, appear how they are supposed to appear. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 43698] On PPC, OpenGL programs use incorrect texture colors.
https://bugs.freedesktop.org/show_bug.cgi?id=43698 Alex Deucher changed: What|Removed |Added Attachment #54302|application/octet-stream|text/plain mime type|| Attachment #54302|0 |1 is patch|| -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH] modetest: add drm_plane support
On Tue, Dec 13, 2011 at 8:55 PM, Rob Clark wrote:
> From: Rob Clark
>
> Signed-off-by: Rob Clark
> ---
> ?tests/modetest/modetest.c | ?166
> ++---
> ?1 files changed, 157 insertions(+), 9 deletions(-)
>
> diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
> index 1e4ec91..22ac620 100644
> --- a/tests/modetest/modetest.c
> +++ b/tests/modetest/modetest.c
> @@ -51,6 +51,7 @@
>
> ?#include "xf86drm.h"
> ?#include "xf86drmMode.h"
> +#include "drm_fourcc.h"
> ?#include "libkms.h"
>
> ?#ifdef HAVE_CAIRO
> @@ -267,6 +268,49 @@ void dump_framebuffers(void)
> ? ? ? ?printf("\n");
> ?}
>
> +static void dump_planes(void)
> +{
> + ? ? ? drmModePlaneRes *plane_resources;
> + ? ? ? drmModePlane *ovr;
> + ? ? ? int i, j;
> +
> + ? ? ? plane_resources = drmModeGetPlaneResources(fd);
> + ? ? ? if (!plane_resources) {
> + ? ? ? ? ? ? ? fprintf(stderr, "drmModeGetPlaneResources failed: %s\n",
> + ? ? ? ? ? ? ? ? ? ? ? strerror(errno));
> + ? ? ? ? ? ? ? return;
> + ? ? ? }
> +
> + ? ? ? printf("Planes:\n");
> + ? ? ? printf("id\tcrtc\tfb\tCRTC x,y\tx,y\tgamma size\n");
> + ? ? ? for (i = 0; i < plane_resources->count_planes; i++) {
> + ? ? ? ? ? ? ? ovr = drmModeGetPlane(fd, plane_resources->planes[i]);
> + ? ? ? ? ? ? ? if (!ovr) {
> + ? ? ? ? ? ? ? ? ? ? ? fprintf(stderr, "drmModeGetPlane failed: %s\n",
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? strerror(errno));
> + ? ? ? ? ? ? ? ? ? ? ? continue;
> + ? ? ? ? ? ? ? }
> +
> + ? ? ? ? ? ? ? printf("%d\t%d\t%d\t%d,%d\t\t%d,%d\t%d\n",
> + ? ? ? ? ? ? ? ? ? ? ?ovr->plane_id, ovr->crtc_id, ovr->fb_id,
> + ? ? ? ? ? ? ? ? ? ? ?ovr->crtc_x, ovr->crtc_y, ovr->x, ovr->y,
> + ? ? ? ? ? ? ? ? ? ? ?ovr->gamma_size);
> +
> + ? ? ? ? ? ? ? if (!ovr->count_formats)
> + ? ? ? ? ? ? ? ? ? ? ? continue;
> +
> + ? ? ? ? ? ? ? printf(" ?formats:");
> + ? ? ? ? ? ? ? for (j = 0; j < ovr->count_formats; j++)
> + ? ? ? ? ? ? ? ? ? ? ? printf(" %4.4s", (char *)&ovr->formats[j]);
> + ? ? ? ? ? ? ? printf("\n");
> +
> + ? ? ? ? ? ? ? drmModeFreePlane(ovr);
> + ? ? ? }
> + ? ? ? printf("\n");
> +
> + ? ? ? return;
> +}
> +
> ?/*
> ?* Mode setting with the kernel interfaces is a bit of a chore.
> ?* First you have to find the connector in question and make sure the
> @@ -280,11 +324,18 @@ struct connector {
> ? ? ? ?drmModeModeInfo *mode;
> ? ? ? ?drmModeEncoder *encoder;
> ? ? ? ?int crtc;
> + ? ? ? int pipe;
> ? ? ? ?unsigned int fb_id[2], current_fb_id;
> ? ? ? ?struct timeval start;
>
> ? ? ? ?int swap_count;
> -};
> +};
> +
> +struct plane {
> + ? ? ? uint32_t con_id; ?/* the id of connector to bind to */
> + ? ? ? uint32_t w, h;
> + ? ? ? unsigned int fb_id;
> +};
>
> ?static void
> ?connector_find_mode(struct connector *c)
> @@ -351,6 +402,15 @@ connector_find_mode(struct connector *c)
>
> ? ? ? ?if (c->crtc == -1)
> ? ? ? ? ? ? ? ?c->crtc = c->encoder->crtc_id;
> +
> + ? ? ? /* and figure out which crtc index it is: */
> + ? ? ? for (i = 0; i < resources->count_crtcs; i++) {
> + ? ? ? ? ? ? ? if (c->crtc == resources->crtcs[i]) {
> + ? ? ? ? ? ? ? ? ? ? ? c->pipe = i;
> + ? ? ? ? ? ? ? ? ? ? ? break;
> + ? ? ? ? ? ? ? }
> + ? ? ? }
> +
> ?}
>
> ?static struct kms_bo *
> @@ -534,13 +594,83 @@ page_flip_handler(int fd, unsigned int frame,
> ? ? ? ?}
> ?}
>
> +static int
> +set_plane(struct kms_driver *kms, struct connector *c, struct plane *p)
> +{
> + ? ? ? drmModePlaneRes *plane_resources;
> + ? ? ? drmModePlane *ovr;
> + ? ? ? uint32_t handles[4], pitches[4], offsets[4]; /* we only use [0] */
opps, passing unitialized offset values to drmModeAddFB2() causes
problems when the driver doesn't actually ignore the offset..
don't merge this yet.. I'm fixing and also adding some test code for
multi-planar YUV (which will need Joonyoung Shim's fix)
BR,
-R
> + ? ? ? uint32_t plane_id = 0;
> + ? ? ? struct kms_bo *plane_bo;
> + ? ? ? uint32_t plane_flags = 0;
> + ? ? ? int i, crtc_x, crtc_y, crtc_w, crtc_h;
> +
> + ? ? ? /* find an unused plane which can be connected to our crtc */
> + ? ? ? plane_resources = drmModeGetPlaneResources(fd);
> + ? ? ? if (!plane_resources) {
> + ? ? ? ? ? ? ? fprintf(stderr, "drmModeGetPlaneResources failed: %s\n",
> + ? ? ? ? ? ? ? ? ? ? ? strerror(errno));
> + ? ? ? ? ? ? ? return -1;
> + ? ? ? }
> +
> + ? ? ? for (i = 0; i < plane_resources->count_planes && !plane_id; i++) {
> + ? ? ? ? ? ? ? ovr = drmModeGetPlane(fd, plane_resources->planes[i]);
> + ? ? ? ? ? ? ? if (!ovr) {
> + ? ? ? ? ? ? ? ? ? ? ? fprintf(stderr, "drmModeGetPlane failed: %s\n",
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? strerror(errno));
> + ? ? ? ? ? ? ? ? ? ? ? return -1;
> + ? ? ? ? ? ? ? }
> +
> + ? ? ? ? ? ? ? if ((ovr->possible_crtcs & (1 << c->pipe)) && !ovr->crtc_id)
> + ? ? ? ? ? ? ? ? ? ? ? plane_id = ovr->plane_id;
> +
> + ? ? ? ? ? ? ? drmModeFreePlane(ovr);
> + ? ? ? }
> +
> + ? ? ? if (!plane_id) {
> + ? ? ? ? ? ? ? fprintf(stderr, "failed to find plane!\n");
> + ? ? ? ? ? ? ? return -1;
> + ? ? ? }
> +
> + ? ? ? /* TODO.. would be nice t
[PATCH] libdrm: fix sizes of memcpy to the drmModeAddFB2()
On Wed, Dec 14, 2011 at 1:15 AM, Joonyoung Shim wrote: > The variables(bo_handles, pitches and offsets) are the array having 4 > elementary of uint32_t type. The their memcpy size is sizeof(uint32_t) * > 4. > > Signed-off-by: Joonyoung Shim Tested-by: Rob Clark > --- > ?xf86drmMode.c | ? ?6 +++--- > ?1 files changed, 3 insertions(+), 3 deletions(-) > > diff --git a/xf86drmMode.c b/xf86drmMode.c > index ffa6dc4..8065f20 100644 > --- a/xf86drmMode.c > +++ b/xf86drmMode.c > @@ -267,9 +267,9 @@ int drmModeAddFB2(int fd, uint32_t width, uint32_t height, > ? ? ? ?f.height = height; > ? ? ? ?f.pixel_format = pixel_format; > ? ? ? ?f.flags = flags; > - ? ? ? memcpy(f.handles, bo_handles, sizeof(bo_handles)); > - ? ? ? memcpy(f.pitches, pitches, sizeof(pitches)); > - ? ? ? memcpy(f.offsets, offsets, sizeof(offsets)); > + ? ? ? memcpy(f.handles, bo_handles, sizeof(uint32_t) * 4); > + ? ? ? memcpy(f.pitches, pitches, sizeof(uint32_t) * 4); > + ? ? ? memcpy(f.offsets, offsets, sizeof(uint32_t) * 4); > > ? ? ? ?if ((ret = DRM_IOCTL(fd, DRM_IOCTL_MODE_ADDFB2, &f))) > ? ? ? ? ? ? ? ?return ret; > -- > 1.7.5.4 > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] modetest: add drm_plane support
From: Rob Clark
Signed-off-by: Rob Clark
---
tests/modetest/modetest.c | 166 ++---
1 files changed, 157 insertions(+), 9 deletions(-)
diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
index 1e4ec91..2936de0 100644
--- a/tests/modetest/modetest.c
+++ b/tests/modetest/modetest.c
@@ -51,6 +51,7 @@
#include "xf86drm.h"
#include "xf86drmMode.h"
+#include "drm_fourcc.h"
#include "libkms.h"
#ifdef HAVE_CAIRO
@@ -267,6 +268,49 @@ void dump_framebuffers(void)
printf("\n");
}
+static void dump_planes(void)
+{
+ drmModePlaneRes *plane_resources;
+ drmModePlane *ovr;
+ int i, j;
+
+ plane_resources = drmModeGetPlaneResources(fd);
+ if (!plane_resources) {
+ fprintf(stderr, "drmModeGetPlaneResources failed: %s\n",
+ strerror(errno));
+ return;
+ }
+
+ printf("Planes:\n");
+ printf("id\tcrtc\tfb\tCRTC x,y\tx,y\tgamma size\n");
+ for (i = 0; i < plane_resources->count_planes; i++) {
+ ovr = drmModeGetPlane(fd, plane_resources->planes[i]);
+ if (!ovr) {
+ fprintf(stderr, "drmModeGetPlane failed: %s\n",
+ strerror(errno));
+ continue;
+ }
+
+ printf("%d\t%d\t%d\t%d,%d\t\t%d,%d\t%d\n",
+ ovr->plane_id, ovr->crtc_id, ovr->fb_id,
+ ovr->crtc_x, ovr->crtc_y, ovr->x, ovr->y,
+ ovr->gamma_size);
+
+ if (!ovr->count_formats)
+ continue;
+
+ printf(" formats:");
+ for (j = 0; j < ovr->count_formats; j++)
+ printf(" %4.4s", (char *)&ovr->formats[j]);
+ printf("\n");
+
+ drmModeFreePlane(ovr);
+ }
+ printf("\n");
+
+ return;
+}
+
/*
* Mode setting with the kernel interfaces is a bit of a chore.
* First you have to find the connector in question and make sure the
@@ -280,11 +324,18 @@ struct connector {
drmModeModeInfo *mode;
drmModeEncoder *encoder;
int crtc;
+ int pipe;
unsigned int fb_id[2], current_fb_id;
struct timeval start;
int swap_count;
-};
+};
+
+struct plane {
+ uint32_t con_id; /* the id of connector to bind to */
+ uint32_t w, h;
+ unsigned int fb_id;
+};
static void
connector_find_mode(struct connector *c)
@@ -351,6 +402,15 @@ connector_find_mode(struct connector *c)
if (c->crtc == -1)
c->crtc = c->encoder->crtc_id;
+
+ /* and figure out which crtc index it is: */
+ for (i = 0; i < resources->count_crtcs; i++) {
+ if (c->crtc == resources->crtcs[i]) {
+ c->pipe = i;
+ break;
+ }
+ }
+
}
static struct kms_bo *
@@ -534,13 +594,83 @@ page_flip_handler(int fd, unsigned int frame,
}
}
+static int
+set_plane(struct kms_driver *kms, struct connector *c, struct plane *p)
+{
+ drmModePlaneRes *plane_resources;
+ drmModePlane *ovr;
+ uint32_t handles[4], pitches[4], offsets[4] = {0}; /* we only use [0] */
+ uint32_t plane_id = 0;
+ struct kms_bo *plane_bo;
+ uint32_t plane_flags = 0;
+ int i, crtc_x, crtc_y, crtc_w, crtc_h;
+
+ /* find an unused plane which can be connected to our crtc */
+ plane_resources = drmModeGetPlaneResources(fd);
+ if (!plane_resources) {
+ fprintf(stderr, "drmModeGetPlaneResources failed: %s\n",
+ strerror(errno));
+ return -1;
+ }
+
+ for (i = 0; i < plane_resources->count_planes && !plane_id; i++) {
+ ovr = drmModeGetPlane(fd, plane_resources->planes[i]);
+ if (!ovr) {
+ fprintf(stderr, "drmModeGetPlane failed: %s\n",
+ strerror(errno));
+ return -1;
+ }
+
+ if ((ovr->possible_crtcs & (1 << c->pipe)) && !ovr->crtc_id)
+ plane_id = ovr->plane_id;
+
+ drmModeFreePlane(ovr);
+ }
+
+ if (!plane_id) {
+ fprintf(stderr, "failed to find plane!\n");
+ return -1;
+ }
+
+ /* TODO.. would be nice to test YUV overlays.. */
+ if (create_test_buffer(kms, p->w, p->h, &pitches[0], &plane_bo))
+ return -1;
+
+ kms_bo_get_prop(plane_bo, KMS_HANDLE, &handles[0]);
+
+ /* just use single plane format for now.. */
+ if (drmModeAddFB2(fd, p->w, p->h, DRM_FORMAT_XRGB,
+ handles, pitches, offsets, &p->fb_id, plane_flags)) {
+ fprintf(stderr, "failed to add fb: %s\n", strerror(errno));
+ return -1;
+ }
+
+ /* ok, boring.. but for now put in middle of screen: */
+ crtc_x = c-
[PATCH 2/2] modetest: add YUV and multi-planar support
From: Rob Clark
Signed-off-by: Rob Clark
---
This one is a bit f-ugly.. kms_bo_create() and dumb-scanout alloc only
really knows about allocating 4byte/pixel buffers, so we just allocate
oversized buffers and use the part we need. It is functional enough
to test the driver (or at least omapdrm), but I'm not sure about how
best to deal w/ kms_bo_create(). (Or perhaps I should only test YUV
support in omapdrmtest tree, and not try to use generic kms_bo_create()?)
tests/modetest/modetest.c | 151 ++---
1 files changed, 142 insertions(+), 9 deletions(-)
diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
index 2936de0..36bdfff 100644
--- a/tests/modetest/modetest.c
+++ b/tests/modetest/modetest.c
@@ -335,6 +335,7 @@ struct plane {
uint32_t con_id; /* the id of connector to bind to */
uint32_t w, h;
unsigned int fb_id;
+ char format_str[5]; /* need to leave room for terminating \0 */
};
static void
@@ -594,6 +595,63 @@ page_flip_handler(int fd, unsigned int frame,
}
}
+/* swap these for big endian.. */
+#define RED 2
+#define GREEN 1
+#define BLUE 0
+
+static void
+fill420(unsigned char *y, unsigned char *u, unsigned char *v,
+ int cs /*chroma pixel stride */,
+ int n, int width, int height, int stride)
+{
+ int i, j;
+
+ /* paint the buffer with colored tiles, in blocks of 2x2 */
+ for (j = 0; j < height; j+=2) {
+ unsigned char *y1p = y + j * stride;
+ unsigned char *y2p = y1p + stride;
+ unsigned char *up = u + (j/2) * stride * cs / 2;
+ unsigned char *vp = v + (j/2) * stride * cs / 2;
+
+ for (i = 0; i < width; i+=2) {
+ div_t d = div(n+i+j, width);
+ uint32_t rgb = 0x00130502 * (d.quot >> 6) + 0x000a1120
* (d.rem >> 6);
+ unsigned char *rgbp = (unsigned char *)&rgb;
+ unsigned char y = (0.299 * rgbp[RED]) + (0.587 *
rgbp[GREEN]) + (0.114 * rgbp[BLUE]);
+
+ *(y2p++) = *(y1p++) = y;
+ *(y2p++) = *(y1p++) = y;
+
+ *up = (rgbp[BLUE] - y) * 0.565 + 128;
+ *vp = (rgbp[RED] - y) * 0.713 + 128;
+ up += cs;
+ vp += cs;
+ }
+ }
+}
+
+static void
+fill422(unsigned char *virtual, int n, int width, int height, int stride)
+{
+ int i, j;
+ /* paint the buffer with colored tiles */
+ for (j = 0; j < height; j++) {
+ uint8_t *ptr = (uint8_t*)((char*)virtual + j * stride);
+ for (i = 0; i < width; i++) {
+ div_t d = div(n+i+j, width);
+ uint32_t rgb = 0x00130502 * (d.quot >> 6) + 0x000a1120
* (d.rem >> 6);
+ unsigned char *rgbp = (unsigned char *)&rgb;
+ unsigned char y = (0.299 * rgbp[RED]) + (0.587 *
rgbp[GREEN]) + (0.114 * rgbp[BLUE]);
+
+ *(ptr++) = y;
+ *(ptr++) = (rgbp[BLUE] - y) * 0.565 + 128;
+ *(ptr++) = y;
+ *(ptr++) = (rgbp[RED] - y) * 0.713 + 128;
+ }
+ }
+}
+
static int
set_plane(struct kms_driver *kms, struct connector *c, struct plane *p)
{
@@ -602,8 +660,8 @@ set_plane(struct kms_driver *kms, struct connector *c,
struct plane *p)
uint32_t handles[4], pitches[4], offsets[4] = {0}; /* we only use [0] */
uint32_t plane_id = 0;
struct kms_bo *plane_bo;
- uint32_t plane_flags = 0;
- int i, crtc_x, crtc_y, crtc_w, crtc_h;
+ uint32_t plane_flags = 0, format;
+ int i, ret, crtc_x, crtc_y, crtc_w, crtc_h;
/* find an unused plane which can be connected to our crtc */
plane_resources = drmModeGetPlaneResources(fd);
@@ -627,19 +685,87 @@ set_plane(struct kms_driver *kms, struct connector *c,
struct plane *p)
drmModeFreePlane(ovr);
}
+ fprintf(stderr, "testing %dx%d@%s overlay plane\n",
+ p->w, p->h, p->format_str);
+
if (!plane_id) {
fprintf(stderr, "failed to find plane!\n");
return -1;
}
- /* TODO.. would be nice to test YUV overlays.. */
- if (create_test_buffer(kms, p->w, p->h, &pitches[0], &plane_bo))
- return -1;
+ if (!strcmp(p->format_str, "XR24")) {
+ if (create_test_buffer(kms, p->w, p->h, &pitches[0], &plane_bo))
+ return -1;
+ kms_bo_get_prop(plane_bo, KMS_HANDLE, &handles[0]);
+ format = DRM_FORMAT_XRGB;
+ } else {
+ void *virtual;
+
+ /* TODO: this always allocates a buffer for 32bpp RGB.. but for
+* YUV formats, we don't use all of it.. since 4bytes/pixel is
+* worst case,
[PATCH] drm: Enable reading 3D capabilities of 3D monitor
Thanks for the comments. Fixed most of the issues with the earlier patch.
Sending out a
new one. Comments inline below.
> -Original Message-
> From: Adam Jackson [mailto:ajax at redhat.com]
> Sent: Tuesday, December 13, 2011 9:51 PM
> To: Kavuri, Sateesh
> Cc: dri-devel at lists.freedesktop.org
> Subject: Re: [PATCH] drm: Enable reading 3D capabilities of 3D monitor
>
> On Fri, 2011-12-09 at 11:46 +, Kavuri, Sateesh wrote:
>
> > + if ((multi_val == STRUCTURE_PRESENT) ||
> > + (multi_val == STRUCTURE_MASK_PRESENT) ) {
> > + if ((edid_ext[i+15+hdmi_vic_len] & 0x01) ==
> 0x01)
> > + caps->format |= 0x0; /*
> FRAME_PACKING */
> > + if ((edid_ext[i+15+hdmi_vic_len] & 0x02) ==
> 0x02)
> > + caps->format |= 0x1;
> /*FIELD_ALTERNATIVE */
> > + if ((edid_ext[i+15+hdmi_vic_len] & 0x04) ==
> 0x04)
> > + caps->format |= 0x2; /*
> LINE_ALTERNATIVE */
> > + if ((edid_ext[i+15+hdmi_vic_len] & 0x08) ==
> 0x08)
> > + caps->format |= 0x3;
> /*SIDE_BY_SIDE_FULL */
> > + if ((edid_ext[i+15+hdmi_vic_len] & 0x10) ==
> 0x10)
> > + caps->format |= 0x4; /* L_DEPTH */
> > + if ((edid_ext[i+15+hdmi_vic_len] & 0x20) ==
> 0x20)
> > + caps->format |= 0x5; /*
> L_DEPTH_GFX_GFX_DEPTH */
> > + if ((edid_ext[i+15+hdmi_vic_len] & 0x40) ==
> 0x40)
> > + caps->format |= 0x6; /* TOP_BOTTOM */
> > + if ((edid_ext[i+14+hdmi_vic_len] & 0x01) ==
> 0x01)
> > + caps->format |= 0x7; /* S_BY_S_HALF */
> > + if ((edid_ext[i+14+hdmi_vic_len] & 0x80) ==
> 0x80)
> > + caps->format |= 0x8; /*
> S_BY_S_HALF_QUINCUNX */
> > + }
>
> This reads poorly, which makes me think it's wrong. Is format supposed to be
> a
> bitfield or an enum?
>
> > +EXPORT_SYMBOL(drm_detect_3D_monitor);
>
> I suspect this is poorly named. There exist 3D displays which are not HDMI.
I want to integrate the other interfaces (eDP, DP, MIPI) panel detection in
this method
itself. Started off with implementing the HDMI part.
>
> > +#define VSIF_RESET_INDEX 0xFFF8
> > +#define VSIF_RESET_BIT_22 0xFFBF
> > +#define VSIF_SET_BIT_19 0x8
> > +#define VSIF_RESET_BIT_20 0xFFEF
> > +#define VSIF_RESET_BIT_17 0x1
> > +#define VSIF_SET_BIT_16 0xFFFD
> > +#define VSIF_SET_MASTER_BIT 0x40
>
> i915 style is usually to write these as (1 << 22) I think.
These I have fixed. Patch with these fixes below.
>
> More importantly, use semantic names for register contents. "Bit 17"
> doesn't mean anything.
>
> > diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h index
> > 8020798..5b4d09c 100644
> > --- a/include/drm/drm_crtc.h
> > +++ b/include/drm/drm_crtc.h
> > @@ -798,6 +798,8 @@ extern int drm_mode_gamma_set_ioctl(struct
> > drm_device *dev, extern u8 *drm_find_cea_extension(struct edid
> > *edid); extern bool drm_detect_hdmi_monitor(struct edid *edid);
> > extern bool drm_detect_monitor_audio(struct edid *edid);
> > +extern bool drm_detect_3D_monitor(struct edid *edid); //extern struct
> > +panel_3d_caps* drm_detect_3D_monitor(struct edid *edid);
>
> Well, which is it?
>
> > +enum s3d_formats {
> > + FRAME_PACKING = 0x0,
> > + FIELD_ALTERNATIVE = 0x1,
> > + LINE_ALTERNATIVE= 0x2,
> > + SIDE_BY_SIDE_FULL = 0x3,
> > + L_DEPTH = 0x4,
> > + L_DEPTH_GFX_GFX_DEPTH = 0x5,
> > + TOP_BOTTOM = 0x6, /* 0x7 is reserved for future */
> > + SIDE_BY_SIDE_HALF = 0x8 /* 0x9 onwards is reserved for future */
> > +};
>
> If format is supposed to be an enum, why aren't you using these symbolic
> values?
I fixed the part to use a u16 integer value to represent the format.
>
> - ajax
[PATCH] drm: integer overflow in drm_mode_dirtyfb_ioctl()
Cc'ed Dave's work email.
On Wed, Nov 23, 2011 at 2:12 PM, Xi Wang wrote:
> There is a potential integer overflow in drm_mode_dirtyfb_ioctl()
> if userspace passes in a large num_clips. ?The call to kmalloc would
> allocate a small buffer, and the call to fb->funcs->dirty may result
> in a memory corruption.
>
> Reported-by: Haogang Chen
> Signed-off-by: Xi Wang
> ---
> ?drivers/gpu/drm/drm_crtc.c | ? ?4
> ?include/drm/drm_mode.h ? ? | ? ?2 ++
> ?2 files changed, 6 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 405c63b..8323fc3 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -1873,6 +1873,10 @@ int drm_mode_dirtyfb_ioctl(struct drm_device *dev,
> ? ? ? ?}
>
> ? ? ? ?if (num_clips && clips_ptr) {
> + ? ? ? ? ? ? ? if (num_clips < 0 || num_clips > DRM_MODE_FB_DIRTY_MAX_CLIPS)
> {
> + ? ? ? ? ? ? ? ? ? ? ? ret = -EINVAL;
> + ? ? ? ? ? ? ? ? ? ? ? goto out_err1;
> + ? ? ? ? ? ? ? }
> ? ? ? ? ? ? ? ?clips = kzalloc(num_clips * sizeof(*clips), GFP_KERNEL);
> ? ? ? ? ? ? ? ?if (!clips) {
> ? ? ? ? ? ? ? ? ? ? ? ?ret = -ENOMEM;
> diff --git a/include/drm/drm_mode.h b/include/drm/drm_mode.h
> index d30bedf..ddd46db 100644
> --- a/include/drm/drm_mode.h
> +++ b/include/drm/drm_mode.h
> @@ -235,6 +235,8 @@ struct drm_mode_fb_cmd {
> ?#define DRM_MODE_FB_DIRTY_ANNOTATE_FILL 0x02
> ?#define DRM_MODE_FB_DIRTY_FLAGS ? ? ? ? 0x03
>
> +#define DRM_MODE_FB_DIRTY_MAX_CLIPS ? ? 256
> +
> ?/*
> ?* Mark a region of a framebuffer as dirty.
> ?*
> --
> 1.7.5.4
>
