src-test2/sys/dev/drm2, branch release/11.0.0

MFC r302571,r302572,r302577,r302841:

2016-08-03T00:03:03Z

Approved by: re (gjb) r302571: Remove redundant declaration for radeon_pm_acpi_event_handler(..) to fix -Wredundant-decls warning PR: 209924 Tested with: devel/amd64-gcc (5.3.0) r302572: Remove redundant declarations for intel_fbc_enabled(..) and i915_gem_dump_object(..) to fix -Wredundant-decls warning PR: 209924 Tested with: devel/amd64-gcc (5.3.0) r302577: Add missing default case to capable(..) function definition By definition (enum __drm_capabilities), cases other than CAP_SYS_ADMIN aren't possible. Add in a KASSERT safety belt and return false in !INVARIANTS case if an invalid value is passed in, as it would be a programmer error. This fixes a -Wreturn-type error with gcc 5.3.0. r302841: Always panic if an invalid capability is passed to `capable(..)` instead of just with INVARIANTS rwatson's point was valid in the sense that if the data passed at runtime is invalid, it should always trip the invariant, not just in the debug case. This is a deterrent against malicious input, or input caused by hardware errors. Requested by: rwatson

[drm] fix up hex_dump_to_buffer to not overflow linebuf.

2016-06-03T05:01:35Z

That check wasn't enough to handle appending a two byte character following it. This prevented my T400 (Intel Core 2 Duo P8400) from attaching; it would panic from a stack overflow detection.

Don't repeat the the word 'the'

2016-05-17T12:52:31Z

(one manual change to fix grammar) Confirmed With: db Approved by: secteam (not really, but this is a comment typo fix)

Ensure waiting loops terminate during cold boot. This fixes boot with

2016-05-10T18:18:29Z

MacBookPro and i915kms_load="YES" in /boot/loader.conf. A lowlevel timeout in one of the display ports caused an infinite wait because a ticks/jiffies comparison was constant. The clock subsystem which makes ticks/jiffies increment is started after the initial driver probing is done. Refer to sys/kernel.h and SI_SUB_DRIVERS vs SI_SUB_CLOCKS . Discussed with: kmacy @

sys/dev: minor spelling fixes.

2016-05-03T03:41:25Z

Most affect comments, very few have user-visible effects.

Revert bus_get_cpus() for now.

2016-05-03T01:17:40Z

I really thought I had run this through the tinderbox before committing, but many places need -> for now.

Add a new bus method to fetch device-specific CPU sets.

2016-05-02T18:00:38Z

bus_get_cpus() returns a specified set of CPUs for a device. It accepts an enum for the second parameter that indicates the type of cpuset to request. Currently two valus are supported: - LOCAL_CPUS (on x86 this returns all the CPUs in the package closest to the device when DEVICE_NUMA is enabled) - INTR_CPUS (like LOCAL_CPUS but only returns 1 SMT thread for each core) For systems that do not support NUMA (or if it is not enabled in the kernel config), LOCAL_CPUS fails with EINVAL. INTR_CPUS is mapped to 'all_cpus' by default. The idea is that INTR_CPUS should always return a valid set. Device drivers which want to use per-CPU interrupts should start using INTR_CPUS instead of simply assigning interrupts to all available CPUs. In the future we may wish to add tunables to control the policy of INTR_CPUS (e.g. should it be local-only or global, should it ignore SMT threads or not). The x86 nexus driver exposes the internal set of interrupt CPUs from the the x86 interrupt code via INTR_CPUS. The ACPI bus driver and PCI bridge drivers use _PXM to return a suitable LOCAL_CPUS set when _PXM exists and DEVICE_NUMA is enabled. They also and the global INTR_CPUS set from the nexus driver with the per-domain set from _PXM to generate a local INTR_CPUS set for child devices. Reviewed by: wblock (manpage) Differential Revision: https://reviews.freebsd.org/D5519

etc: minor spelling fixes.

2016-05-02T16:47:28Z

Mostly comments but also some user-visible strings. MFC after: 2 weeks

i915kms: Fix memory leak if a CRT is detected

2016-04-20T03:48:57Z

Reported by: Coverity CID: 1090729 Sponsored by: EMC / Isilon Storage Division

drm2(4): Fix double-free in low-memory error path

2016-04-20T03:45:45Z

Reallocf frees 'block'; don't attempt to free it again. Reported by: Coverity CID: 1091165 Sponsored by: EMC / Isilon Storage Division