Commit Graph

19 Commits

Author SHA1 Message Date
Pedro F. Giffuni
453130d9bf sys/dev: minor spelling fixes.
Most affect comments, very few have user-visible effects.
2016-05-03 03:41:25 +00:00
John Baldwin
c2a51a4b0e Remove compatibility shims for FreeBSD versions older than 8.0. 2015-06-04 20:36:16 +00:00
John Baldwin
7077c42623 Add a new file operations hook for mmap operations. File type-specific
logic is now placed in the mmap hook implementation rather than requiring
it to be placed in sys/vm/vm_mmap.c.  This hook allows new file types to
support mmap() as well as potentially allowing mmap() for existing file
types that do not currently support any mapping.

The vm_mmap() function is now split up into two functions.  A new
vm_mmap_object() function handles the "back half" of vm_mmap() and accepts
a referenced VM object to map rather than a (handle, handle_type) tuple.
vm_mmap() is now reduced to converting a (handle, handle_type) tuple to a
a VM object and then calling vm_mmap_object() to handle the actual mapping.
The vm_mmap() function remains for use by other parts of the kernel
(e.g. device drivers and exec) but now only supports mapping vnodes,
character devices, and anonymous memory.

The mmap() system call invokes vm_mmap_object() directly with a NULL object
for anonymous mappings.  For mappings using a file descriptor, the
descriptors fo_mmap() hook is invoked instead.  The fo_mmap() hook is
responsible for performing type-specific checks and adjustments to
arguments as well as possibly modifying mapping parameters such as flags
or the object offset.  The fo_mmap() hook routines then call
vm_mmap_object() to handle the actual mapping.

The fo_mmap() hook is optional.  If it is not set, then fo_mmap() will
fail with ENODEV.  A fo_mmap() hook is implemented for regular files,
character devices, and shared memory objects (created via shm_open()).

While here, consistently use the VM_PROT_* constants for the vm_prot_t
type for the 'prot' variable passed to vm_mmap() and vm_mmap_object()
as well as the vm_mmap_vnode() and vm_mmap_cdev() helper routines.
Previously some places were using the mmap()-specific PROT_* constants
instead.  While this happens to work because PROT_xx == VM_PROT_xx,
using VM_PROT_* is more correct.

Differential Revision:	https://reviews.freebsd.org/D2658
Reviewed by:	alc (glanced over), kib
MFC after:	1 month
Sponsored by:	Chelsio
2015-06-04 19:41:15 +00:00
Robert Noland
2ee6488c02 re-write scatter gather memory allocation yet again...
This time, abandon the use of busdma and start interacting with the VM
system directly.  Make use of the new kmem_alloc_attr() which allows us
to easily allocate non-contiguous pages to back the GART table.  This
should help a lot when starting or restarting X after the system has
been running for a while and memory has become fragmented.

MFC after:	2 weeks
2010-04-22 18:44:23 +00:00
Robert Noland
9c03c0d88c Rework how drm maps are handled.
* On 32 bit platforms we steal the upper 4 bits of the map handle
   to store a unique map id.
 * On 64 bit platforms we steal the upper 24 bits.

Resolves issues where the offsets that are handed to mmap may overlap the VRAM on some cards.

Tested on: radeon, intel, mga, and via.

This will break nouveau.  I will spin new patches shortly.
2010-04-22 18:21:25 +00:00
Robert Noland
f21c255c2a Clean up the locking in drm_alloc_resource()
MFC after:	2 weeks
2009-08-23 14:27:46 +00:00
Robert Noland
4949d88192 Don't panic if drm_rmmap is called with a NULL map pointer.
MFC after:	3 days
2009-06-20 16:37:24 +00:00
Robert Noland
a4501e547e Minor code cleanup
MFC after:	3 days
2009-03-17 03:46:37 +00:00
Robert Noland
162e0ab8c1 Use flsl() here rather than ffsl()
I discovered that we were computing page_order differently than linux.

MFC after:	3 days
2009-03-17 03:32:12 +00:00
Robert Noland
d3f8d87d33 There is no need to sync these buffers to swap.
MFC after:	3 days
2009-03-09 07:49:13 +00:00
Robert Noland
2a4f4fc196 Fix up some ioctl permissions issues long overlooked.
Submitted by:	jkim@
MFC after:	2 weeks
2009-02-27 06:01:42 +00:00
Robert Noland
f00755f06b Rework memory allocation to allocate memory with different type names. This
will ease the identification of memory leaks as the OS will be able to track
allocations for us by malloc type.  vmstat -m will show all of the
allocations.

Convert the calls to drm_alloc() and friends, which are used in shared code
to static __inline__ while we are here.

Approved by:	jhb (mentor)
2008-10-13 18:03:27 +00:00
Robert Noland
4d3ad1c1a6 Change drm_order() to use ffsl()
pointed out by jhb@

Approved by:	jhb (mentor)
2008-10-04 14:45:34 +00:00
Robert Noland
4cd2e9581f resync to git master
This reverts a private patch which is causing issues with many Intel chipsets.
I will review that patch and see what we need to do to fix it up later, but
for the time being, we will just get these chips working again.

This update contains a lot of code cleanup and is post gem merge
(no, we don't have gem support).  It should prove much easier to read the
code now.  A lot of thanks goes to vehemens for that work.  I have adapted
the code to use cdevpriv for tracking per open file data.  That alleviates
the old ugly hack that we used to try and accomplish the task and helped to
clean up the open / close behavior a good bit.  This also replaces the hack
that was put in place a year or so ago to prevent radeons from locking up
with AIGLX enabled.  I have had a couple of radeon testers report that it
still works as expected, though I no longer have radeon hardware to test with
myself.  Other various fixes from the linux crew and Intel, many of
which are muddled in with the gem merge.

Approved by:	jhb (mentor)
Obtained from:	mesa/drm git master
MFC after:	2 weeks
2008-10-03 16:59:11 +00:00
Robert Noland
0020a2cded We should never call drm_pci_alloc() while holding locks, due the the
calls to bus_dma.  There were multiple paths that held different locks or
no locks at all. This patch ensures that all of the calling paths drop
their lock(s) before calling drm_pci_alloc().

Reviewed by:	kib
2008-09-09 02:05:03 +00:00
Robert Noland
a2a2d95441 Update drm kernel drivers.
This is a sync to mesa/drm pre-gem, with a few fixes on top of that.
It also contains one local patch supplied by kib@ that I can't apply to
git.master shared code.

Approved by:	flz
Obtained from:	mesa/drm git.master
MFC after:	2 weeks
2008-08-23 20:59:12 +00:00
Eric Anholt
9fb0767374 Update DRM to CVS snapshot as of 2005-11-28. Notable changes:
- S3 Savage driver ported.
- Added support for ATI_fragment_shader registers for r200.
- Improved r300 support, needed for latest r300 DRI driver.
- (possibly) r300 PCIE support, needs X.Org server from CVS.
- Added support for PCI Matrox cards.
- Software fallbacks fixed for Rage 128, which used to render badly or hang.
- Some issues reported by WITNESS are fixed.
- i915 module Makefile added, as the driver may now be working, but is untested.
- Added scripts for copying and preprocessing DRM CVS for inclusion in the
  kernel.  Thanks to Daniel Stone for getting me started on that.
2005-11-28 23:13:57 +00:00
Eric Anholt
7c26ccfd22 Fix a panic on X startup for drivers that don't init maps themselves by storing
the return value of drm_ioremap in the right place again.

Submitted by:	tegge
2005-04-24 19:03:32 +00:00
Eric Anholt
b8aa843c63 Update to DRM CVS as of 2005-04-12, bringing many changes:
- Split core DRM routines back into their own module, rather than using the
  nasty templated system like before.
- Development-class R300 support in radeon driver (requires userland pieces, of
  course).
- Mach64 driver (haven't tested in a while -- my mach64s no longer fit in the
  testbox).  Covers Rage Pros, Rage Mobility P/M, Rage XL, and some others.
- i915 driver files, which just need to get drm_drv.c fixed to allow attachment
  to the drmsub device.  Covers i830 through i915 integrated graphics.
- savage driver files, which should require minimal changes to work.  Covers the
  Savage3D, Savage IX/MX, Savage 4, ProSavage.
- Support for color and texture tiling and HyperZ features of Radeon.

Thanks to:	scottl (much p4 handholding)
		Jung-uk Kim (helpful prodding)
PR:		[1] kern/76879, [2] kern/72548
Submitted by:	[1] Alex, lesha at intercaf dot ru
		[2] Shaun Jurrens, shaun at shamz dot net
2005-04-16 03:44:47 +00:00