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;
> + /*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.
------------------------------------------------------------------------------
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
