Re: [PATCH] vga: implements VGA arbitration on Linux
On Tue, 2009-08-11 at 16:17 -0700, Jesse Barnes wrote: > Ok, applied this to my linux-next branch, but I'd like to get Ben's > s-o-b before pushing it to Linus. Well, S-O-B is if the code went through my hands... though in this case I wrote the original version so I suppose it did :-) An ack for sure. Let me have a look, I'll come back to you asap. Cheers, Ben. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] vga: implements VGA arbitration on Linux
On Tue, 2009-08-11 at 15:52 +1000, Dave Airlie wrote:
> From: Tiago Vignatti
>
> Background:
> Graphic devices are accessed through ranges in I/O or memory space. While most
> modern devices allow relocation of such ranges, some "Legacy" VGA devices
> implemented on PCI will typically have the same "hard-decoded" addresses as
> they did on ISA. For more details see "PCI Bus Binding to IEEE Std 1275-1994
> Standard for Boot (Initialization Configuration) Firmware Revision 2.1"
> Section 7, Legacy Devices.
>
> The Resource Access Control (RAC) module inside the X server currently does
> the task of arbitration when more than one legacy device co-exists on the same
> machine. But the problem happens when these devices are trying to be accessed
> by different userspace clients (e.g. two server in parallel). Their address
> assignments conflict. Therefore an arbitration scheme _outside_ of the X
> server is needed to control the sharing of these resources. This document
> introduces the operation of the VGA arbiter implemented for Linux kernel.
>
> Signed-off-by: Tiago Vignatti
> Signed-off-by: Dave Airlie
Well, since I wrote a god deal of it:
Acked-by: Benjamin Herrenschmidt
---
Note that I do believe we still have some kind of race vs. the default
VGA device going away but it's rather minor, something to fix at some
stase though.
> ---
> drivers/gpu/Makefile |2 +-
> drivers/gpu/vga/Kconfig | 10 +
> drivers/gpu/vga/Makefile |1 +
> drivers/gpu/vga/vgaarb.c | 1206
> ++
> drivers/pci/pci.c| 44 ++
> drivers/video/Kconfig|2 +
> include/linux/pci.h |2 +
> include/linux/vgaarb.h | 195
> 8 files changed, 1461 insertions(+), 1 deletions(-)
> create mode 100644 drivers/gpu/vga/Kconfig
> create mode 100644 drivers/gpu/vga/Makefile
> create mode 100644 drivers/gpu/vga/vgaarb.c
> create mode 100644 include/linux/vgaarb.h
>
> diff --git a/drivers/gpu/Makefile b/drivers/gpu/Makefile
> index de566cf..30879df 100644
> --- a/drivers/gpu/Makefile
> +++ b/drivers/gpu/Makefile
> @@ -1 +1 @@
> -obj-y+= drm/
> +obj-y+= drm/ vga/
> diff --git a/drivers/gpu/vga/Kconfig b/drivers/gpu/vga/Kconfig
> new file mode 100644
> index 000..790e675
> --- /dev/null
> +++ b/drivers/gpu/vga/Kconfig
> @@ -0,0 +1,10 @@
> +config VGA_ARB
> + bool "VGA Arbitration" if EMBEDDED
> + default y
> + depends on PCI
> + help
> + Some "legacy" VGA devices implemented on PCI typically have the same
> + hard-decoded addresses as they did on ISA. When multiple PCI devices
> + are accessed at same time they need some kind of coordination. Please
> + see Documentation/vgaarbiter.txt for more details. Select this to
> + enable VGA arbiter.
> diff --git a/drivers/gpu/vga/Makefile b/drivers/gpu/vga/Makefile
> new file mode 100644
> index 000..7cc8c1e
> --- /dev/null
> +++ b/drivers/gpu/vga/Makefile
> @@ -0,0 +1 @@
> +obj-$(CONFIG_VGA_ARB) += vgaarb.o
> diff --git a/drivers/gpu/vga/vgaarb.c b/drivers/gpu/vga/vgaarb.c
> new file mode 100644
> index 000..199138f
> --- /dev/null
> +++ b/drivers/gpu/vga/vgaarb.c
> @@ -0,0 +1,1206 @@
> +/*
> + * vgaarb.c
> + *
> + * (C) Copyright 2005 Benjamin Herrenschmidt
> + * (C) Copyright 2007 Paulo R. Zanoni
> + * (C) Copyright 2007, 2009 Tiago Vignatti
> + *
> + * Implements the VGA arbitration. For details refer to
> + * Documentation/vgaarbiter.txt
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +
> +#include
> +
> +static void vga_arbiter_notify_clients(void);
> +/*
> + * We keep a list of all vga devices in the system to speed
> + * up the various operations of the arbiter
> + */
> +struct vga_device {
> + struct list_head list;
> + struct pci_dev *pdev;
> + unsigned int decodes; /* what does it decodes */
> + unsigned int owns; /* what does it owns */
> + unsigned int locks; /* what does it locks */
> + unsigned int io_lock_cnt; /* legacy IO lock count */
> + unsigned int mem_lock_cnt; /* legacy MEM lock count */
> + unsigned int io_norm_cnt; /* normal IO count */
> + unsigned int mem_norm_cnt; /* normal MEM count */
> +
> + /* allow IRQ enable/disable hook */
> + void *cookie;
> + void (*irq_set_state)(void *cookie, bool enable);
> + unsigned int (*set_vga_decode)(void *cookie, bool decode);
> +};
> +
> +static LIST_HEAD(vga_list);
> +static int vga_count, vga_decode_count;
> +static bool vga_arbiter_used;
> +static DEFINE_SPINLOCK(vga_lock);
> +static DECLARE_WAIT_QUEUE_HEAD(vga_wait_queue);
> +
> +
> +static const char *vga_iostate_to_str(unsigned int iostate)
> +{
> + /* Ignore VGA_RSRC_IO and VGA_RSRC_MEM */
> + iostate &= VGA_RSRC_LEGACY_IO | VGA_RSRC_LEGACY_MEM;
> + switch
RE: [Patch 2/3] Resubmit VIA Chrome9 DRM via_chrome9 for upstream - Header File
Hello Sirs/Madams:
As we are preparing the 64bit DRM, we have tested the DRM in both case of
32bit user space+32bit DRM and 64bit user space + 64 bit DRM. However, we have
a question relative to 32bit user space + 64bit DRM and request suggestion for
the solution. Our question is "How 32 bit user application save the 64bit
address got from the mapping from DRM (64bit kernel). For example: drmMap
function, how libdrm (32bits) save the 64bit virtual address into the void *p
(32bit in libdrm itself)"?
I would also like to update the status of VIA 2D source for public
releasing. It's almost done and has been released to few community people for
feedback collection. It will be released within these 2 weeks if no other issue
found. Thank you very much for your patience.
Thanks and Best Regards
=
Bruce C. Chang(???)
VIA Technologies, Inc.
Address: 1F, 531, Chung-Cheng Road, Hsin-Tien, 231 Taipei
Tel: +886-2-22185452 Ext 7323
Mobile: +886-968343824
Fax: +886-2-22186282
Skype: Bruce.C.Chang
Email: brucech...@via.com.tw
-Original Message-
From: Dave Airlie [mailto:airl...@gmail.com]
Sent: Friday, July 17, 2009 5:09 PM
To: Bruce Chang
Cc: dri-devel@lists.sourceforge.net; Joseph Chan; Benjamin Pan (Fremont);
Harald Welte; gre...@suse.de; Richard Lee
Subject: Re: [Patch 2/3] Resubmit VIA Chrome9 DRM via_chrome9 for upstream -
Header File
> 1. via_chrome9_3d_reg.h
> 2. via_chrome9_dma.h
> 3. via_chrome9_drm.h
> 4. via_chrome9_drv.h
> 5. via_chrome9_mm.h
> 6. via_chrome9_verifier.h
Is it possible to run a 64-bit Linux on a chrome9 chipset onnected to a 64-bit
processor? if so you'll have to fix a lot of these ioctls up.
> +
> +struct drm_via_chrome9_init {
> + enum {
> + VIA_CHROME9_INIT = 0x01,
> + VIA_CHROME9_CLEANUP = 0x02
> + } func;
> + int chip_agp;
> + int chip_index;
> + int chip_sub_index;
> + int usec_timeout;
> + unsigned int sarea_priv_offset;
> + unsigned int fb_cpp;
> + unsigned int front_offset;
> + unsigned int back_offset;
> + unsigned int depth_offset;
> + unsigned int mmio_handle;
> + unsigned int dma_handle;
> + unsigned int fb_handle;
> + unsigned int front_handle;
> + unsigned int back_handle;
> + unsigned int depth_handle;
> +
> + unsigned int fb_tex_offset;
> + unsigned int fb_tex_size;
> +
> + unsigned int agp_tex_size;
> + unsigned int agp_tex_handle;
> + unsigned int shadow_size;
> + unsigned int shadow_handle;
> + unsigned int garttable_size;
> + unsigned int garttable_offset;
> + unsigned long available_fb_size; <--- here
> + unsigned long fb_base_address; <--- here
> + unsigned int DMA_size;
> + unsigned long DMA_phys_address; <--- here
^^ unsigned long are bad in ioctls, as its undefined size you should use
__u64s in new ioctls and convert them in the kernel.
> + enum {
> + AGP_RING_BUFFER,
> + AGP_DOUBLE_BUFFER,
> + AGP_DISABLED
> + } agp_type;
> + unsigned int hostBlt_handle;
> +};
> +
> +enum dma_cmd_type {
> + flush_bci = 0,
> + flush_bci_and_wait,
> + dma_kickoff,
> + flush_dma_buffer,
> + flush_dma_and_wait
> +};
> +
> +struct drm_via_chrome9_flush {
> + enum dma_cmd_type dma_cmd_type;
> + /* command buffer index */
> + int cmd_idx;
> + /* command buffer offset */
> + int cmd_offset;
> + /* command dword size,command always from beginning */
> + int cmd_size;
> + /* if use dma kick off,it is dma kick off command */
> + unsigned long dma_kickoff[2];
> + /* user mode DMA buffer pointer */
> + unsigned int *usermode_dma_buf;
> +};
^^^ here also unsigned long and pointers. pointers also change
size on 32 vs 64-bit.
> +struct drm_via_chrome9_mem {
> + uint32_t context;
> + uint32_t type;
> + uint32_t size;
> + unsigned long index;
> + unsigned long offset;
> +};
here also
> +
> +struct drm_via_chrome9_aperture {
> + /*IN: The frame buffer offset of the surface. */
> + int surface_offset;
> + /*IN: Surface pitch in byte, */
> + int pitch;
> + /*IN: Surface width in pixel */
> + int width;
> + /*IN: Surface height in pixel */
> + int height;
> + /*IN: Surface color format, Columbia has more color formats */
> + int color_format;
> + /*IN: Rotation degrees, only for Columbia */
> + int rotation_degree;
> + /*IN Is the PCIE Video, for MATRIX support NONLOCAL Aperture
> +*/
> + int isPCIEVIDEO;
> + /*IN: Is the surface tilled, only for Columbia */
> + int is_tiled;
> + /*IN: Only allocate apertur, not hardware setup. */
> + int allocate
Re: [Nouveau] [PATCH 10/12] drm: Import driver for the ch7006 I2C TV encoder chip.
On Wed, 12 Aug 2009 02:15:06 +0200 Francisco Jerez wrote: > > Signed-off-by: Francisco Jerez > --- > drivers/gpu/drm/Kconfig | 14 + > drivers/gpu/drm/Makefile |1 + > drivers/gpu/drm/i2c/Makefile |3 + > drivers/gpu/drm/i2c/ch7006_drv.c | 479 > + > drivers/gpu/drm/i2c/ch7006_mode.c | 470 > drivers/gpu/drm/i2c/ch7006_priv.h | 332 + > include/drm/i2c/ch7006.h | 86 +++ > 7 files changed, 1385 insertions(+), 0 deletions(-) > create mode 100644 drivers/gpu/drm/i2c/Makefile > create mode 100644 drivers/gpu/drm/i2c/ch7006_drv.c > create mode 100644 drivers/gpu/drm/i2c/ch7006_mode.c > create mode 100644 drivers/gpu/drm/i2c/ch7006_priv.h > create mode 100644 include/drm/i2c/ch7006.h This patch should probably go in via dri-devel@ and airlied, like the other two DRM patches. Would that work? It would be unused without Nouveau, so it probably won't get to Linus' before Nouveau does. Airlied? Does Nouveau build and work otherwise without this patch? If we take it to the nouveau/linux-2.6 master branch, we would have to remember to revert it when submitting Nouveau upstream. OTOH, we could apply it to master-compat branch for testing. How's that sound? Thanks. -- Pekka Paalanen http://www.iki.fi/pq/ -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] vga: implements VGA arbitration on Linux
On Wed, Aug 12, 2009 at 01:21:03AM +0200, Jesse Barnes wrote: > Oh yeah, and we should get the documentation merged too. I can handle > that or you can send it to Randy. Tiago? Okay, I can handle this documentation pretty easy. But honestly I'm not sure we (or some future developer) will use it. The header (include/linux/vgaarb.h) is already very nice documented. So, tell me what do you think Jesse. Cheers, Tiago -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm: Update drm sysfs device handling.
This code wraps the struct device so that the drm class callbacks can
differentiate between different types of drm sysfs devices. It fixes a
case where a struct drm_connecor is cast to a struct drm_minor in the
drm_sysfs[suspend|resume] code.
It also opens up for adding driver-specific device entries to the drm
sysfs class, where the struct device need not be embedded within a
struct drm_minor. A new include "drm_sysfs.h" is added so that drivers
don't need to include the full drmP.h to access this feature.
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/drm_sysfs.c | 134 --
include/drm/drmP.h |3 +-
include/drm/drm_crtc.h |3 +-
include/drm/drm_sysfs.h | 37
4 files changed, 130 insertions(+), 47 deletions(-)
create mode 100644 include/drm/drm_sysfs.h
diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c
index adc1794..ba54b4c 100644
--- a/drivers/gpu/drm/drm_sysfs.c
+++ b/drivers/gpu/drm/drm_sysfs.c
@@ -16,11 +16,13 @@
#include
#include
+#include "drm_sysfs.h"
#include "drm_core.h"
#include "drmP.h"
-#define to_drm_minor(d) container_of(d, struct drm_minor, kdev)
-#define to_drm_connector(d) container_of(d, struct drm_connector, kdev)
+#define to_drm_minor(d) container_of(d, struct drm_minor, dsdev)
+#define to_drm_connector(d) container_of(d, struct drm_connector, dsdev)
+#define to_dsdev(d) container_of(d, struct drm_sysfs_device, kdev)
/**
* drm_sysfs_suspend - DRM class suspend hook
@@ -32,13 +34,23 @@
*/
static int drm_sysfs_suspend(struct device *dev, pm_message_t state)
{
- struct drm_minor *drm_minor = to_drm_minor(dev);
- struct drm_device *drm_dev = drm_minor->dev;
-
- if (drm_minor->type == DRM_MINOR_LEGACY &&
- !drm_core_check_feature(drm_dev, DRIVER_MODESET) &&
- drm_dev->driver->suspend)
- return drm_dev->driver->suspend(drm_dev, state);
+ struct drm_sysfs_device *dsdev = to_dsdev(dev);
+
+ BUG_ON(dsdev->type >= DRM_DEVICE_TYPE_NUM);
+ switch (dsdev->type) {
+ case DRM_DEVICE_TYPE_MINOR:
+ {
+ struct drm_minor *drm_minor = to_drm_minor(dsdev);
+ struct drm_device *drm_dev = drm_minor->dev;
+
+ if (drm_minor->type == DRM_MINOR_LEGACY &&
+ !drm_core_check_feature(drm_dev, DRIVER_MODESET) &&
+ drm_dev->driver->suspend)
+ return drm_dev->driver->suspend(drm_dev, state);
+ }
+ default:
+ break;
+ }
return 0;
}
@@ -52,16 +64,38 @@ static int drm_sysfs_suspend(struct device *dev,
pm_message_t state)
*/
static int drm_sysfs_resume(struct device *dev)
{
- struct drm_minor *drm_minor = to_drm_minor(dev);
- struct drm_device *drm_dev = drm_minor->dev;
+ struct drm_sysfs_device *dsdev = to_dsdev(dev);
+
+ BUG_ON(dsdev->type >= DRM_DEVICE_TYPE_NUM);
+ switch (dsdev->type) {
+ case DRM_DEVICE_TYPE_MINOR:
+ {
+ struct drm_minor *drm_minor = to_drm_minor(dsdev);
+ struct drm_device *drm_dev = drm_minor->dev;
+
+ if (drm_minor->type == DRM_MINOR_LEGACY &&
+ !drm_core_check_feature(drm_dev, DRIVER_MODESET) &&
+ drm_dev->driver->resume)
+ return drm_dev->driver->resume(drm_dev);
+ }
+ default:
+ break;
+ }
+ return 0;
+}
- if (drm_minor->type == DRM_MINOR_LEGACY &&
- !drm_core_check_feature(drm_dev, DRIVER_MODESET) &&
- drm_dev->driver->resume)
- return drm_dev->driver->resume(drm_dev);
+int drm_sysfs_device_register(struct drm_sysfs_device *dsdev)
+{
+ dsdev->kdev.class = drm_class;
+ return device_register(&dsdev->kdev);
+}
+EXPORT_SYMBOL(drm_sysfs_device_register);
- return 0;
+void drm_sysfs_device_unregister(struct drm_sysfs_device *dsdev)
+{
+ device_unregister(&dsdev->kdev);
}
+EXPORT_SYMBOL(drm_sysfs_device_unregister);
/* Display the version of drm_core. This doesn't work right in current design
*/
static ssize_t version_show(struct class *dev, char *buf)
@@ -150,7 +184,8 @@ static ssize_t status_show(struct device *device,
struct device_attribute *attr,
char *buf)
{
- struct drm_connector *connector = to_drm_connector(device);
+ struct drm_sysfs_device *dsdev = to_dsdev(device);
+ struct drm_connector *connector = to_drm_connector(dsdev);
enum drm_connector_status status;
status = connector->funcs->detect(connector);
@@ -162,7 +197,8 @@ static ssize_t dpms_show(struct device *device,
struct device_attribute *attr,
char *buf)
{
- struct drm_connector *connector = to_drm_connector(device);
+ struct drm_sysfs_device *dsdev = to_dsdev(device);
+
Re: [PATCH] vga: implements VGA arbitration on Linux
On Wed, Aug 12, 2009 at 08:48:08AM +0200, Benjamin Herrenschmidt wrote: > On Tue, 2009-08-11 at 16:17 -0700, Jesse Barnes wrote: > > > Ok, applied this to my linux-next branch, but I'd like to get Ben's > > s-o-b before pushing it to Linus. > > Well, S-O-B is if the code went through my hands... though in this case > I wrote the original version so I suppose it did :-) An ack for sure. > > Let me have a look, I'll come back to you asap. Ohh, I feel more comfortable if the patches come with Ben's authorship. Please do it Dave because it makes more sense (and S-O-B by me). Cheers, Tiago -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Nouveau] [PATCH 10/12] drm: Import driver for the ch7006 I2C TV encoder chip.
Pekka Paalanen writes: > On Wed, 12 Aug 2009 02:15:06 +0200 > Francisco Jerez wrote: > >> >> Signed-off-by: Francisco Jerez >> --- >> drivers/gpu/drm/Kconfig | 14 + >> drivers/gpu/drm/Makefile |1 + >> drivers/gpu/drm/i2c/Makefile |3 + >> drivers/gpu/drm/i2c/ch7006_drv.c | 479 >> + >> drivers/gpu/drm/i2c/ch7006_mode.c | 470 >> >> drivers/gpu/drm/i2c/ch7006_priv.h | 332 + >> include/drm/i2c/ch7006.h | 86 +++ >> 7 files changed, 1385 insertions(+), 0 deletions(-) >> create mode 100644 drivers/gpu/drm/i2c/Makefile >> create mode 100644 drivers/gpu/drm/i2c/ch7006_drv.c >> create mode 100644 drivers/gpu/drm/i2c/ch7006_mode.c >> create mode 100644 drivers/gpu/drm/i2c/ch7006_priv.h >> create mode 100644 include/drm/i2c/ch7006.h > > This patch should probably go in via dri-devel@ and airlied, like > the other two DRM patches. Would that work? > > It would be unused without Nouveau, so it probably won't get to > Linus' before Nouveau does. Airlied? > Right, as nouveau is its only user, I think it's fine for the nouveau tree to own ch7006.ko for now. > Does Nouveau build and work otherwise without this patch? > Yes. > If we take it to the nouveau/linux-2.6 master branch, we would > have to remember to revert it when submitting Nouveau upstream. > OTOH, we could apply it to master-compat branch for testing. > How's that sound? > > > Thanks. pgpWaLZzsmnNr.pgp Description: PGP signature -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 23106] mplayer -vo gl:yuv=6 segfaults r300_state.c:r300SetupTextures()
http://bugs.freedesktop.org/show_bug.cgi?id=23106 Thierry Vignaud changed: What|Removed |Added CC||xorg-driver-...@lists.x.org --- Comment #3 from Thierry Vignaud 2009-08-12 06:50:25 PST --- Trying to get in touch with developers... -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Doing better than CS ioctl ?
Dave, The big problem with the (second) radeon approach of state objects was that we defined those objects statically & encoded them into the kernel interface. That meant that when new hardware functionality was needed (or discovered) we had to rev the kernel interface, usually in a fairly ugly way. I think Jerome's approach could be a good improvement if the state objects it creates are defined by software at runtime, more like little display lists than pre-defined state atoms. The danger again is that you run into cases where you need to expand objects the verifier will allow userspace to create, but at least in doing so you won't be breaking existing users of the interface. I think the key is that there should be no pre-defined format for these state objects, simply that they should be a sequence of legal commands/register writes that the kernel validates once and userspace can execute multiple times. Keith On Sat, 2009-08-08 at 05:43 -0700, Dave Airlie wrote: > On Sat, Aug 8, 2009 at 7:51 AM, Jerome Glisse wrote: > > Investigating where time is spent in radeon/kms world when doing > > rendering leaded me to question the design of CS ioctl. As i am among > > the people behind it, i think i should give some historical background > > on the choice that were made. > > I think this sounds quite like the original radeon interface or maybe > even a bit like the second one. The original one stored the registers > in the sarea, and updated the context under the lock, and had the > kernel emit it. The sceond one had a bunch of state objects, containing > ranges of registers that were safe to emit. > > Maybe Keith Whitwell can point out why these were a good/bad idea, > not sure if anyone else remembers that far back. > > Dave. > > > > > The first motivation behind cs ioctl was to take common language > > btw userspace and kernel and btw kernel and device. Of course in > > an ideal world command submitted through cs ioctl could directly > > be forwarded to the GPU without much overhead. Thing is, the world > > we leave in isn't that good. There is 2 things the cs ioctl > > do before forwarding command: > > > > 1- First it must rewrite any packet which supply an offset to GPU > > with the address the memory manager validate the buffer object > > associated to this packet. We can't get rid of this with the cs > > ioctl (we might do somethings very clever like doing a new > > microcode for the cp so that cp can rewrite packet using some > > table of validated buffer offset but i am not even sure cp > > would be powerful enough to do that). > > 2- In order to provide a more advanced security than what we > > did have in the past i added a cs checker facility which is > > responsible to analyze the command stream and make sure that > > the GPU won't read or write outside the supplied buffer object > > list. DRI1 didn't offered such advanced checking. This feature > > was added with GPU sharing in mind where sensible application > > might run on the GPU and for which we might like to protect > > their memory. > > > > We can obviously avoid the second item and things would work > > but userspace would be able to abuse the GPU to access outside > > the GPU object its own (this doesn't means it will be able to > > access any system ram but rather any ram that is mapped to GPU > > which should for the time being only be pixmap, texture, vbo > > or things like that). > > > > Bottom line is that with cs ioctl we do 2 times a different > > work. In userspace we build a command stream under stable by the > > GPU and in kernel space we unencode this command stream to check > > it. Obviously this sounds wrong. > > > > That being said, CS ioctl isn't that bad, it doesn't consume much > > on benchmark i have done but i expect it might consume a more on > > older cpu or when many complex 3D apps run at the same time. So > > i am not proposing to trash it away but rather to discuss about > > a better interface we could add at latter point to slowly replace > > cs. CS is bringing today feature we needed yesterday so we should > > focus our effort on getting cs ioctl as smooth and good as possible. > > > > > > So as a pet project i have been thinking this last few days of > > what would be a better interface btw userspace and kernel and > > i come up with somethings in btw gallium state object and nvidia > > gpu object (well at least as far as i know each of this my > > design sounds close to that). > > > > Idea behind design is that whenever userspace allocate a bo, > > userspace knows about properties of the bo. If it's a texture > > userspace knows the size, the number of mipmap level, the > > border,... of the textur. If it's a vbo it's knows the layout > > the size, number of elements, ... same for rendering viewport > > it knows the size and associated properties > > > > Design 2 ioctl: > >create_object : > >supply : > >- object type id specific to asic > >
Re: drm sysfs questions
On Wed, 12 Aug 2009 08:21:24 +0200
Thomas Hellström wrote:
> Jesse Barnes wrote:
> > On Tue, 11 Aug 2009 20:29:39 +0200
> > Thomas Hellström wrote:
> >
> >
> >> Jesse Barnes wrote:
> >>
> >>> On Tue, 11 Aug 2009 11:23:09 +0200
> >>> Thomas Hellström wrote:
> >>>
> >>>
> >>>
> Hi!
>
> I'm wondering why we are using a struct device as a sysfs
> representation for connectors instead of a struct kobject?
>
> In particular, what stops the drm_sysfs_[suspend|resume]
> functions to get called for the connectors, having them cast to
> a struct drm_minor and sending the cpu to the bushes?
>
>
> >>> Hm, maybe we're just getting lucky that the drm minor check fails
> >>> for everything but the DRM core device.
> >>>
> >> Yes, I think that's actually the case.
> >>
> >>> kobjects might make sense to move
> >>> to, unless we can think of other things we'd like to do with a
> >>> full device (e.g. runtime power management or some sort of
> >>> per-connector suspend/resume).
> >>>
> >>>
> >> I can't really think of a case where the device owning the
> >> connector can't handle this?
> >> But we'd lose the /sys/drm/xxx symlinks to the connectors, and if
> >> that does matter, we'd need to recreate those manually.
> >>
> >> Anyway, I'd also like to be able to add a virtual ttm device to the
> >> drm sysfs hierarchy, the purpose of which would be to do the right
> >> thing with uncached / write-combined pages at suspend. The virtual
> >> device won't be wrapped in a drm minor so I'm wondering wether we
> >> could wrap the struct device like so:
> >>
> >> struct drm_sysfs_device {
> >> enum drm_sysfs_device_type type;
> >> struct device kdev;
> >> }
> >>
> >> This way the drm sysfs suspend / resume hooks can check the type of
> >> the structure embedding the struct device and only call the driver
> >> hooks for the relevand device types.
> >>
> >
> > Yeah, that could work, but it seems like an explicit callout from
> > drivers using TTM (or a callout from the core drm suspend/resume
> > routines conditional on a DRIVER_HAS_TTM check) would be a bit
> > simpler. Or did you have other TTM info you wanted to expose sysfs
> > as well?
> >
> >
> TTM nowadays is a set of optional subsystems rather than a complete
> set of features, so DRIVER_HAS_TTM can really mean a lot of things.
>
> The idea is to have a ttm subdir (representing the TTM virtual
> device) and in that sysfs directory, other TTM subsystems can
> register kobjects with various attributes. For example the memory
> accounting subsystem with settable / readable limits and readable
> status, but that will be code internal to TTM.
Ah ok, so the approach you suggested sounds pretty good. The only
thing that comes to mind is whether other class devices do something
similar; i.e. maybe this code belongs in the device core instead.
Greg? (See above for some background.)
--
Jesse Barnes, Intel Open Source Technology Center
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] vga: implements VGA arbitration on Linux
On Wed, 12 Aug 2009 10:35:16 +0300 "Vignatti Tiago (Nokia-D/Helsinki)" wrote: > On Wed, Aug 12, 2009 at 01:21:03AM +0200, Jesse Barnes wrote: > > Oh yeah, and we should get the documentation merged too. I can > > handle that or you can send it to Randy. Tiago? > > Okay, I can handle this documentation pretty easy. > > But honestly I'm not sure we (or some future developer) will use it. > The header (include/linux/vgaarb.h) is already very nice documented. > So, tell me what do you think Jesse. As long as it's still accurate we may as well include it. -- Jesse Barnes, Intel Open Source Technology Center -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] vga: implements VGA arbitration on Linux
On Wed, 12 Aug 2009 00:24:37 -0700 "Vignatti Tiago (Nokia-D/Helsinki)" wrote: > On Wed, Aug 12, 2009 at 08:48:08AM +0200, Benjamin Herrenschmidt > wrote: > > On Tue, 2009-08-11 at 16:17 -0700, Jesse Barnes wrote: > > > > > Ok, applied this to my linux-next branch, but I'd like to get > > > Ben's s-o-b before pushing it to Linus. > > > > Well, S-O-B is if the code went through my hands... though in this > > case I wrote the original version so I suppose it did :-) An ack > > for sure. > > > > Let me have a look, I'll come back to you asap. > > Ohh, I feel more comfortable if the patches come with Ben's > authorship. Please do it Dave because it makes more sense (and S-O-B > by me). Ok I amended the patch to make Ben the author, with s-o-bs from Dave and you since you both worked on the code. Dave, do you want me to apply the DRM patch too, just to avoid having a dependency? You could also pull my tree into yours; let me know if you do and I won't do anymore rebases before sending Linus a pull request. -- Jesse Barnes, Intel Open Source Technology Center -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 23172] Game is lagging very much with Mesa 7.5
http://bugs.freedesktop.org/show_bug.cgi?id=23172 --- Comment #2 from Simonas 2009-08-12 14:19:33 PST --- Created an attachment (id=28566) --> (http://bugs.freedesktop.org/attachment.cgi?id=28566) xorg.0.log my xorg.0.log file -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 23172] Game is lagging very much with Mesa 7.5
http://bugs.freedesktop.org/show_bug.cgi?id=23172 --- Comment #3 from Simonas 2009-08-12 14:21:41 PST --- Created an attachment (id=28567) --> (http://bugs.freedesktop.org/attachment.cgi?id=28567) LIBGL_DEBUG=verbose glxinfo 2>&1 output -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 23172] Game is lagging very much with Mesa 7.5
http://bugs.freedesktop.org/show_bug.cgi?id=23172 --- Comment #4 from Pauli 2009-08-12 15:18:36 PST --- (In reply to comment #3) > Created an attachment (id=28567) --> (http://bugs.freedesktop.org/attachment.cgi?id=28567) [details] > LIBGL_DEBUG=verbose glxinfo 2>&1 output > Is your user part of video group? ls -l /dev/dri/ ? -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm sysfs questions
On Wed, 12 Aug 2009 16:24:58 -0700
Greg KH wrote:
> On Wed, Aug 12, 2009 at 08:59:17AM -0700, Jesse Barnes wrote:
> > On Wed, 12 Aug 2009 08:21:24 +0200
> > Thomas Hellström wrote:
> >
> > > Jesse Barnes wrote:
> > > > On Tue, 11 Aug 2009 20:29:39 +0200
> > > > Thomas Hellström wrote:
> > > >
> > > >
> > > >> Jesse Barnes wrote:
> > > >>
> > > >>> On Tue, 11 Aug 2009 11:23:09 +0200
> > > >>> Thomas Hellström wrote:
> > > >>>
> > > >>>
> > > >>>
> > > Hi!
> > >
> > > I'm wondering why we are using a struct device as a sysfs
> > > representation for connectors instead of a struct kobject?
> > >
> > > In particular, what stops the drm_sysfs_[suspend|resume]
> > > functions to get called for the connectors, having them cast
> > > to a struct drm_minor and sending the cpu to the bushes?
> > >
> > >
> > > >>> Hm, maybe we're just getting lucky that the drm minor check
> > > >>> fails for everything but the DRM core device.
> > > >>>
> > > >> Yes, I think that's actually the case.
> > > >>
> > > >>> kobjects might make sense to move
> > > >>> to, unless we can think of other things we'd like to do with a
> > > >>> full device (e.g. runtime power management or some sort of
> > > >>> per-connector suspend/resume).
> > > >>>
> > > >>>
> > > >> I can't really think of a case where the device owning the
> > > >> connector can't handle this?
> > > >> But we'd lose the /sys/drm/xxx symlinks to the connectors, and
> > > >> if that does matter, we'd need to recreate those manually.
> > > >>
> > > >> Anyway, I'd also like to be able to add a virtual ttm device
> > > >> to the drm sysfs hierarchy, the purpose of which would be to
> > > >> do the right thing with uncached / write-combined pages at
> > > >> suspend. The virtual device won't be wrapped in a drm minor so
> > > >> I'm wondering wether we could wrap the struct device like so:
> > > >>
> > > >> struct drm_sysfs_device {
> > > >> enum drm_sysfs_device_type type;
> > > >> struct device kdev;
> > > >> }
> > > >>
> > > >> This way the drm sysfs suspend / resume hooks can check the
> > > >> type of the structure embedding the struct device and only
> > > >> call the driver hooks for the relevand device types.
> > > >>
> > > >
> > > > Yeah, that could work, but it seems like an explicit callout
> > > > from drivers using TTM (or a callout from the core drm
> > > > suspend/resume routines conditional on a DRIVER_HAS_TTM check)
> > > > would be a bit simpler. Or did you have other TTM info you
> > > > wanted to expose sysfs as well?
> > > >
> > > >
> > > TTM nowadays is a set of optional subsystems rather than a
> > > complete set of features, so DRIVER_HAS_TTM can really mean a lot
> > > of things.
> > >
> > > The idea is to have a ttm subdir (representing the TTM virtual
> > > device) and in that sysfs directory, other TTM subsystems can
> > > register kobjects with various attributes. For example the memory
> > > accounting subsystem with settable / readable limits and readable
> > > status, but that will be code internal to TTM.
>
> Don't use raw kobjects if at all possible please. Use a real struct
> device, it's much better in the long run for a wide variety of
> reasons, not the least being that you are dealing with virtual
> devices here.
>
> > Ah ok, so the approach you suggested sounds pretty good. The only
> > thing that comes to mind is whether other class devices do something
> > similar; i.e. maybe this code belongs in the device core instead.
> >
> > Greg? (See above for some background.)
>
> I'm sorry, but I fail to see how this concerns the driver core.
> Perhaps I'm just slow this afternoon... Anyone want to explain it
> better?
So right now we have a DRM class device. The various DRM devices are
registered with it... and now that I think about it we should probably
just restructure things so that they each have their own suspend/resume
routines? I'm not sure how that interacts with the class device
though; will both the class device suspend/resume get called along with
each device?
Thomas's thought was to identify each sub-device uniquely so we could
do the right thing in the class device suspend/resume routines, but it
seems like that wouldn't be necessary if moved things around a bit
more...
--
Jesse Barnes, Intel Open Source Technology Center
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm sysfs questions
2009/8/11 Thomas Hellström :
> Jesse Barnes wrote:
>> On Tue, 11 Aug 2009 11:23:09 +0200
>> Thomas Hellström wrote:
>>
>>
>>> Hi!
>>>
>>> I'm wondering why we are using a struct device as a sysfs
>>> representation for connectors instead of a struct kobject?
>>>
>>> In particular, what stops the drm_sysfs_[suspend|resume] functions to
>>> get called for the connectors, having them cast to a struct drm_minor
>>> and sending the cpu to the bushes?
>>>
>>
>> Hm, maybe we're just getting lucky that the drm minor check fails for
>> everything but the DRM core device.
>
> Yes, I think that's actually the case.
>> kobjects might make sense to move
>> to, unless we can think of other things we'd like to do with a full
>> device (e.g. runtime power management or some sort of per-connector
>> suspend/resume).
>>
>
> I can't really think of a case where the device owning the connector
> can't handle this?
> But we'd lose the /sys/drm/xxx symlinks to the connectors, and if that
> does matter, we'd need to recreate those manually.
>
> Anyway, I'd also like to be able to add a virtual ttm device to the drm
> sysfs hierarchy, the purpose of which would be to do the right thing
> with uncached / write-combined pages at suspend. The virtual device
> won't be wrapped in a drm minor so I'm wondering wether we could wrap
> the struct device like so:
>
> struct drm_sysfs_device {
> enum drm_sysfs_device_type type;
> struct device kdev;
> }
>
> This way the drm sysfs suspend / resume hooks can check the type of the
> structure embedding the struct device and only call the driver hooks for
> the relevand device types.
There is already a struct device_type mechanism for different types of
devices under a subsystem. I'm pretty sure that would be the rigth
thing to use, also for the connector devices. If we make those
different device_types, we can keep the connectors as devices. This
is useful in connection with libudev, since we can attach properties
to specific outputs this way. Like which seat they belong to etc.
cheers,
Kristian
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 22743] nexuiz game: missing weapons and enemies models
http://bugs.freedesktop.org/show_bug.cgi?id=22743 --- Comment #1 from Andre Maasikas 2009-08-12 23:48:44 PST --- Seems it fails the max_index check in drawrangeelements when rendering player models. e.g: Mesa warning: glDraw[Range]Elements(start 0, end 126, count 240, type 0x1403, indices=(nil)) index=126 is out of bounds (max=125) Element Buffer 85 (size 480) Mesa warning: glDraw[Range]Elements(start 6, end 1495, count 5130, type 0x1403, indices=0xfad0ac4) index=1495 is out of bounds (max=1494) Element Buffer 0 (size 0) You can try if commenting out the return statement in this check or inside the game using gldrawelements fixes it (open console shift->ESC type: gl_mesh_drawrangeelements 0). -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
