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 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
