Re: [Patch 2/3] Resubmit VIA Chrome9 DRM via_chrome9 for upstream - Header File
On Wed, Aug 12, 2009 at 11:46 AM, brucech...@via.com.tw wrote:
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)?
You shouldn't be passing back 64-bit addresses for userspace to be
using, generally we use handles to do this.
drmMap takes a drm_handle_t and mmap returns a void *, which is a user
sized pointer.
Dave.
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
Re: drm sysfs questions
Jesse Barnes wrote:
On Tue, 11 Aug 2009 20:29:39 +0200
Thomas Hellström tho...@shipmail.org wrote:
Jesse Barnes wrote:
On Tue, 11 Aug 2009 11:23:09 +0200
Thomas Hellström tho...@shipmail.org 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.
/Thomas
--
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 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 tiago.vigna...@nokia.com
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 tiago.vigna...@nokia.com
Signed-off-by: Dave Airlie airl...@redhat.com
Well, since I wrote a god deal of it:
Acked-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
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 b...@kernel.crashing.org
+ * (C) Copyright 2007 Paulo R. Zanoni przan...@gmail.com
+ * (C) Copyright 2007, 2009 Tiago Vignatti vigna...@freedesktop.org
+ *
+ * Implements the VGA arbitration. For details refer to
+ * Documentation/vgaarbiter.txt
+ */
+
+#include linux/module.h
+#include linux/kernel.h
+#include linux/pci.h
+#include linux/errno.h
+#include linux/init.h
+#include linux/list.h
+#include linux/sched.h
+#include linux/wait.h
+#include linux/spinlock.h
+#include linux/poll.h
+#include linux/miscdevice.h
+
+#include linux/uaccess.h
+
+#include linux/vgaarb.h
+
+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);
+
+
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_only;
+ /* OUT: linear address for aperture */
+ unsigned int *aperture_linear_address;
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 curroje...@riseup.net wrote: Signed-off-by: Francisco Jerez curroje...@riseup.net --- 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
[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 thellst...@vmware.com
---
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 linux/kdev_t.h
#include linux/err.h
+#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);
+ struct
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 p...@iki.fi writes: On Wed, 12 Aug 2009 02:15:06 +0200 Francisco Jerez curroje...@riseup.net wrote: Signed-off-by: Francisco Jerez curroje...@riseup.net --- 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 tvign...@mandriva.com changed: What|Removed |Added CC||xorg-driver-...@lists.x.org --- Comment #3 from Thierry Vignaud tvign...@mandriva.com 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 Glissegli...@freedesktop.org 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 - object structure associated to type id, fully describing the object
Re: drm sysfs questions
On Wed, 12 Aug 2009 08:21:24 +0200
Thomas Hellström tho...@shipmail.org wrote:
Jesse Barnes wrote:
On Tue, 11 Aug 2009 20:29:39 +0200
Thomas Hellström tho...@shipmail.org wrote:
Jesse Barnes wrote:
On Tue, 11 Aug 2009 11:23:09 +0200
Thomas Hellström tho...@shipmail.org 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) tiago.vigna...@nokia.com 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) tiago.vigna...@nokia.com 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 obuol...@gmail.com 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 obuol...@gmail.com 2009-08-12 14:21:41 PST --- Created an attachment (id=28567) -- (http://bugs.freedesktop.org/attachment.cgi?id=28567) LIBGL_DEBUG=verbose glxinfo 21 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 suok...@gmail.com 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 21 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 g...@kroah.com 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 tho...@shipmail.org wrote:
Jesse Barnes wrote:
On Tue, 11 Aug 2009 20:29:39 +0200
Thomas Hellström tho...@shipmail.org wrote:
Jesse Barnes wrote:
On Tue, 11 Aug 2009 11:23:09 +0200
Thomas Hellström tho...@shipmail.org 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 tho...@shipmail.org:
Jesse Barnes wrote:
On Tue, 11 Aug 2009 11:23:09 +0200
Thomas Hellström tho...@shipmail.org 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
