RE: [Patch 2/3] Resubmit VIA Chrome9 DRM via_chrome9 for upstream - Header File
Hello Sirs/Madams:
Please kindly be advised that the 2D source code from VIA is available for
download at
http://linux.via.com.tw/support/beginDownload.action?eleid=306fid=601. Please
use
Option AccelMethod EXA
in Section Device for verifying DRM with EXA architecture enabled.
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: Bruce Chang
Sent: Wednesday, August 12, 2009 9:47 AM
To: dri-devel@lists.sourceforge.net
Cc: Joseph Chan; Benjamin Pan (Fremont); Harald Welte; gre...@suse.de; Richard
Lee; 'Dave Airlie'
Subject: 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
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: [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: [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;
+ /*OUT: The pitch of the aperture,for CPU write not for GE */
+ int aperture_pitch;
+ /*OUT: The index of the aperture */
+ int aperture_handle;
+ int apertureID;
+ /* always =0x */
+ /* Aligned surface's width(in pixel) */
+ int width_aligned;
+ /* Aligned surface's height(in pixel) */
+ int height_aligned;
+};
+
+/*
+ Some fileds of this data structure has no meaning now since
+ we have managed heap based on mechanism provided by DRM
+ Remain what it was to keep consistent with 3D driver interface.
+*/
+struct drm_via_chrome9_memory_alloc {
+ enum {
+ memory_heap_video = 0,
+ memory_heap_agp,
+ memory_heap_pcie_video,
+ memory_heap_pcie,
+ max_memory_heaps
+ } heap_type;
+ struct {
+ void *lpL1Node;
+ unsigned int alcL1Tag;
+ unsigned int usageCount;
+ unsigned int dwVersion;
+ unsigned int dwResHandle;
+ unsigned int dwProcessID;
+ } heap_info;
+ unsigned int flags;
+ unsigned int size;
+ unsigned int physaddress;
+ unsigned int offset;
+ unsigned int align;
+ void *linearaddress;
+};
pointers again.
+
+struct drm_via_chrome9_dma_init {
+
RE: [Patch 2/3] Resubmit VIA Chrome9 DRM via_chrome9 for upstream - Header File
Hello Dave:
Thank you very much for your suggestion. Let me request engineer to modify
it.
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;
+ /*OUT: The pitch of the aperture,for CPU write not for GE */
+ int aperture_pitch;
+ /*OUT: The index of the aperture */
+ int aperture_handle;
+ int apertureID;
+ /* always =0x */
+ /* Aligned surface's width(in pixel) */
+ int width_aligned;
+ /* Aligned surface's height(in pixel) */
+ int height_aligned;
+};
+
+/*
+ Some fileds of this data structure has no meaning now since
+ we have managed heap based on mechanism provided by DRM
+ Remain what it was to keep consistent with 3D driver interface.
+*/ struct drm_via_chrome9_memory_alloc {
+ enum {
+ memory_heap_video = 0
Re: [Patch 2/3] Resubmit VIA Chrome9 DRM via_chrome9 for upstream - Header File
Hi Dave, thanks for your review. On Fri, Jul 17, 2009 at 07:08:33PM +1000, Dave Airlie wrote: 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. Yes, very much so. the Chrome9 graphics core exists in the VX800/820 and VX855/875 chipsets, all of which exclusively support VIA's own CPUs. The VIA Nano CPU fully supports x86_64, so we have all combinations of: 32bit kernel + 32bit userspace 64bit kernel + 32bit userspace 64bit kernel + 64bit userspace So yes, this driver will need quite a bit of fixing esp. for the 64bit kernel / 32bit userspace case. Bruce / Joseph: If you need more details on what to do, I am happy to explain. Regards, Harald -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
