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 =0xAAAAAAAA */
> + /* 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 {
> + enum {
> + VIA_CHROME9_INIT_DMA = 0x01,
> + VIA_CHROME9_CLEANUP_DMA = 0x02,
> + VIA_CHROME9_DMA_INITIALIZED = 0x03
> + } func;
> +
> + unsigned long offset;
> + unsigned long size;
> + unsigned long reg_pause_addr;
> +};
> +
more unsignde longs.
> +struct drm_via_chrome9_cmdbuffer {
> + char __user *buf;
> + unsigned long size;
> +};
and more. I think you can figure out the rest :-)
basically ioctls need defined sizes for 32/64 bit compat.
Dave.
------------------------------------------------------------------------------
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
