> > > >
> > > > Hi, I am the maintainer of V4L capture module for All-in-Wonder cards.
> > > > I need some help figuring out how to interface with drm.
> > > >
> > > > The problem: the module works fine, except that (at least Radeons) want
> > > > physical memory from AGP addressable range. So I can either write my own
> > > > memory allocation routines or interface with drm to do this. The second
> > > > being the more preferable.
> > > >
> > > > The problem is that
> > > > a) drm does not export headers to other modules (nothing in
> > > > /usr/include/linux/drmxxxx.h
> > > > b) looking at drm.h and drmP.h in the driver source does not yield
> > > > immediate answer either. All I want is to obtain an agp addressable memory
> > > > chunk of a certain size.
> > > > ba) What are those DRM() wrappers ?
> > > > bb) can I simply call DRM(alloc) or do I need to "acquire" drm in a
> > > > certain way ?
> > > >
> > > Take a look at the driver specific *_dri.c files. You can then use
> > > drmAddBufs with DRM_RESTRICTED (so 3D apps don't use it) and later use
> > > drmMap to map your area.
> >
> > Thanks for replying :))
> >
> > Unfortunately this wont work as I need to do this from inside a kernel
> > module so it is able to expose v4l interface.
>
> Can't you use the functions that are exported to userland as ioctls?
Inelegant. Why have a helper program running whose only purpose is to
export buffer addresses ? Besides, kernel trusting userspace with buffer
addresses is not the right thing to do.
>
>
> > Some more questions: I've looked around drm and agpgart sourcecode and
> > as far as I understand (at least on x86) the memory drm allocates is
> > obtained anywhere with alloc_page(GFP_KERNEL). And the intel specification
> > for AGP3.0 explicitly states that any physical address should be
> > accessible. So, where does the "maximum agp addressable
> > memory" calculation comes from ?
>
> I'm not sure but maybe this is related to the AGP aperture size as
> configured in the BIOS setup?
I found out what it is, but I do not know yet what to do about it.
Gareth - could you comment please ?
What happens is that Radeon has its internal view of physical space an
important part of which is the location of framebuffer - determined by
MC_FB_LOCATION register. Now it so happens that DRI sets this to start at
0. Hence when I try to DMA from the card it thinks that any small physical
address is a place in video ram and not system memory. So any attempt to
DMA into pages with small physical addresses fail.
I have tried resetting MC_FB_LOCATION to it's pci aperture as
recommended in the documentation. The problem is that at the minimum it
screws up display - so something else needs to be changed. Additionally I
get a hard lockup first chance DRI code kicks in.
Gareth, in radeon_cp.c I see the following code:
static void radeon_cp_init_ring_buffer( drm_device_t *dev,
drm_radeon_private_t *dev_priv )
{
u32 ring_start, cur_read_ptr;
u32 tmp;
/* Initialize the memory controller */
RADEON_WRITE( RADEON_MC_FB_LOCATION,
(dev_priv->agp_vm_start - 1) & 0xffff0000 );
if ( !dev_priv->is_pci ) {
RADEON_WRITE( RADEON_MC_AGP_LOCATION,
(((dev_priv->agp_vm_start - 1 +
dev_priv->agp_size) & 0xffff0000) |
(dev_priv->agp_vm_start >> 16)) );
}
How do you know that you will never need to use system ram with small
physical address ? I have looked at agpgart and it allocates memory with
alloc_page(GFP_KERNEL) and can, in principle, give you any kind of memory.
Was there any particular reason for this setting ?
thanks !
Vladimir Dergachev
>
>
> --
> Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer
> XFree86 and DRI project member / CS student, Free Software enthusiast
>
> _______________________________________________
> Dri-devel mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/dri-devel
>
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
