Dave Airlie writes:
> >
> > I've made a patch against the DRM code in CVS adding a few pieces that
> > were missing.
> > The code works for me on both radeon and r128. I've also tried to test
> > mga however the mga code in CVS doesn't seem to work at all right now.
>
> My guess would be id
>
> I've made a patch against the DRM code in CVS adding a few pieces that
> were missing.
> The code works for me on both radeon and r128. I've also tried to test
> mga however the mga code in CVS doesn't seem to work at all right now.
My guess would be idr's changes might need some compat work .
Paul Mackerras writes:
> Based on Egbert's comments about the use of an idr structure
> restricting our choice of token values, I have taken an alternative
> approach where I put the user token in the drm_map_list_t structure,
> which is private to the kernel.
>
> This patch is against the c
On 7/3/05, Paul Mackerras <[EMAIL PROTECTED]> wrote:
> Jon Smirl writes:
>
> > drmMap never cares about the handle since drmMap turns into mmap and
> > mmap doesn't know about DRM maps.
>
> Huh? drm_mmap certainly does know about DRM maps.
I see now that drmMap is overriding mmap's offset to pa
Jon Smirl writes:
> drmMap never cares about the handle since drmMap turns into mmap and
> mmap doesn't know about DRM maps.
Huh? drm_mmap certainly does know about DRM maps.
The trouble with using the offset returned by drmGetMap is that if
your program is a 32-bit program running on a 64-bit
Keith Whitwell writes:
> Sounds good Paul. I think it's worthwhile to at least investigate this
> as it'd be a cleaner result all round at the end.
Based on Egbert's comments about the use of an idr structure
restricting our choice of token values, I have taken an alternative
approach where I p
I've attached my current diffs to DRM. I am coverting DRM so that the
server does not have to run as root. The attached code allows this.
Most of the changes are in AddMap.
1) sarea is prebuilt
2) agp maps are allowed from non-root master but checked to make sure
they are within allocated agp spa
Jon Smirl writes:
> Don't the maps always contain the physical address of the object? That
> would provide a unique handle.
No, for _DRM_SHM and _DRM_SCATTER_GATHER maps the offset is a kernel
virtual address (at least at present). It's only by luck that we
don't see collisions.
Also, using a p
Don't the maps always contain the physical address of the object? That
would provide a unique handle.
Where does the handle get used in user space? After I GetMap() to find
the map I need, I pass the offset back into drmMap() not the handle.
Offset is the physical address in most cases.
--
Jon S
Paul Mackerras writes:
> Keith Whitwell writes:
>
> > In general I'd prefer that the values passed to clients (and back again)
> > to be abstract tokens rather than actual addresses or offsets into some
> > unspecified address space.
> >
> > Which should mean that 32 bits is more than am
Paul Mackerras wrote:
Keith Whitwell writes:
In general I'd prefer that the values passed to clients (and back again)
to be abstract tokens rather than actual addresses or offsets into some
unspecified address space.
Which should mean that 32 bits is more than ample to contain them...
Th
Keith Whitwell writes:
> In general I'd prefer that the values passed to clients (and back again)
> to be abstract tokens rather than actual addresses or offsets into some
> unspecified address space.
>
> Which should mean that 32 bits is more than ample to contain them...
The problem that we
Paul Mackerras wrote:
Do either of you (or does anyone) have a good mental grasp of how
map handles and offsets are used and manipulated in the X server and
in DRI clients? In particular, I'm interested to know under what
circumstances map handles are generated by arithmetic on other map
handles
On 6/29/05, Jon Smirl <[EMAIL PROTECTED]> wrote:
> drmAgpAlloc() allocs drm_agp_mem structures which track the agp
> allocs. I could change the map system to allow a single map to be
> paired with each struct drm_agp_mem.
>
> The 2MB restricted you are using was allocated with a call to
> drmAgpAl
On 6/29/05, Paul Mackerras <[EMAIL PROTECTED]> wrote:
> Do either of you (or does anyone) have a good mental grasp of how
> map handles and offsets are used and manipulated in the X server and
> in DRI clients? In particular, I'm interested to know under what
> circumstances map handles are genera
On 6/29/05, Thomas Hellström <[EMAIL PROTECTED]> wrote:
> > Currently the drivers are AddMap'ing multiple little maps over the AGP
> > area, but the area is basically split into two area: private for the
> > master and public for the DRI clients to write to.
> >
> > So to get around the root priv r
Do either of you (or does anyone) have a good mental grasp of how
map handles and offsets are used and manipulated in the X server and
in DRI clients? In particular, I'm interested to know under what
circumstances map handles are generated by arithmetic on other map
handles, or obtained from a sou
Hi!
> On 6/28/05, Ian Romanick <[EMAIL PROTECTED]> wrote:
>> > 3) Can the driver pre-build the AGP/PCI gart maps? If these maps are
>> > marked differently it is way for my driver to tell AGP from PCI cards.
>>
>> I would advise against that. There are (rare) cases where user-mode
>> wants to sel
On 6/28/05, Ian Romanick <[EMAIL PROTECTED]> wrote:
> > 3) Can the driver pre-build the AGP/PCI gart maps? If these maps are
> > marked differently it is way for my driver to tell AGP from PCI cards.
>
> I would advise against that. There are (rare) cases where user-mode
> wants to select AGP par
On 6/28/05, Thomas Hellström <[EMAIL PROTECTED]> wrote:
> You got me wrong. Item 2 above states that the device specific code
> specifies the number of possible SAREAS and their sizes to main DRM as
> part of its initialization.
>
> typically for two sareas something like
>
> static uint32_t via_
Jon Smirl wrote:
On 6/28/05, Thomas Hellström <[EMAIL PROTECTED]> wrote:
Having thought a bit more about the SAREA problem, I'd like to see the
following solution:
1) AddMap returns an error if the flag CONTAINS_LOCK is not set. The
first SAREA otherwise for
backwards compatibility.
2) The
On 6/28/05, Thomas Hellström <[EMAIL PROTECTED]> wrote:
> Having thought a bit more about the SAREA problem, I'd like to see the
> following solution:
>
> 1) AddMap returns an error if the flag CONTAINS_LOCK is not set. The
> first SAREA otherwise for
> backwards compatibility.
> 2) The device-spe
Hi!
Some comments for current implementations of VIA chipsets:
Jon Smirl wrote:
We should discuss the design of DRM maps so that we don't work at
cross purposes.
The register map should be marked read only or root only. I don't need
access to the register map.
A lot of syncing is done usi
On 6/28/05, Ian Romanick <[EMAIL PROTECTED]> wrote:
> > 1) Should the maps be created once at driver load time or on
> > open/close? I can probably make the egl drivers work either way.
>
> I did it at neither time in the MGA driver. When I added support there
> for PCI cards, I added a DMA boot-
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jon Smirl wrote:
> We should discuss the design of DRM maps so that we don't work at
> cross purposes.
>
> I have a new requirement coming from the egl-driver work that my user
> space driver does not have root priv so it can't create the maps. This
>
25 matches
Mail list logo
