markj [Mon, 17 Feb 2014 14:52:06 +0000 (14:52 +0000)]
MFC r260051:
When clearing relocations to __dtrace* symbols, handle both SHT_REL and
SHT_RELA sections properly instead of assuming that the relocation section
is of type SHT_REL.
avg [Mon, 17 Feb 2014 14:48:23 +0000 (14:48 +0000)]
MFC r258625: sdt: add support for solaris/illumos style DTRACE_PROBE macros
Note: in head KDTRACE_HOOKS is defined in opt_global.h and thus there is
no need to explicitly include any header to check that option.
In this branch we have to include opt_kdtrace.h and, so, this commit
carries additional changes to accomodate for that difference.
dim [Wed, 12 Feb 2014 07:51:14 +0000 (07:51 +0000)]
MFC r261680:
Pull in r200899 from upstream clang trunk:
Allow transformation of VariableArray to ConstantArray.
In the following code:
struct A { static const int sz; };
template<class T> void f() { T arr[A::sz]; }
the array 'arr' is represented as a variable size array in the template.
If 'A::sz' gets value below in the translation unit, the array in
instantiation can turn into constant size array.
dumbbell [Sun, 9 Feb 2014 20:17:40 +0000 (20:17 +0000)]
MFC r259717:
drm: Lower priority of "EDID checksum is invalid" message
The priority goes from "error" to "debug".
Connectors are polled every 10 seconds. Reading EDID is part of this
polling. However, when an invalid EDID is returned, this error message
is logged. When using Newcons for instance, having a kernel message
every 10 seconds is getting annoying.
Now that it's a debug message, it'll be logged only if hw.dri.debug is
enabled. This fix console spamming for some users.
dumbbell [Sun, 9 Feb 2014 20:08:16 +0000 (20:08 +0000)]
MFC r258549:
drm: Dereference pointers given to qsort_r()'s cmp callback
drm_le_cmp() (qsort_r()'s callback) receives pointers to elements in the
array passed to qsort_r(), not the elements themselves.
Before this fix, the use of qsort_r() shuffled the array, not sorted it,
because the compare callback accessed random memory locations, not the
expected elements.
This bug triggered an infinite loop in KDE/xserver:
1. KDE has a kded module called "randrmonitor" which queries xserver
for current monitors at startup and then listens to RandR
notifications from xserver.
2. xserver handles the query from "randrmonitor" by polling the
video device using the "drm_mode_getconnector()" ioctl. This
ioctl returns a list of connectors and, for those with a
connected monitor, the available modes. Each modes list is sorted
by the kernel before returning. When xserver gets the connectors
list, it sorts the modes lists again.
In the case of this bug, when two modes are equal (in xserver's
compare function PoV), their order is kept stable (ie. the
kernel order is kept for those two modes). And because the list
was shuffled by the kernel, the order of two equal modes was
frequently changed in the final modes list in xserver.
3. xserver compares the returned connectors list with the list
obtained earlier. In particular, it compares the sorted
modes lists for each connector. If a property of a connector
changes (eg. modes), xserver sends a "RRNotify_OutputChange"
notification.
Because of the change of order between equal modes, xserver sent
a notification after each polling of the connectors.
4. "randrmonitor" receives a notification, triggered by its query. The
notification doesn't contain the new connectors list, therefore, it
asks for the new list using the same function: go back to step #2.
dumbbell [Sun, 9 Feb 2014 19:54:39 +0000 (19:54 +0000)]
MFC r258262:
drm: Support DRM_CAP_TIMESTAMP_MONOTONIC capability
This fixes DPMS with KDE and radeonkms. Without this, the display would
freeze when the monitor is put into sleep state, and only resumes after
several dozens of minutes once the monitor is powered on again.
dumbbell [Sun, 9 Feb 2014 19:36:27 +0000 (19:36 +0000)]
MFC r254852:
drm: Update drm_pciids.h based on Linux 3.8
This header can be easily updated using the new "gen-drm_pciids" script,
available in tools/tools/drm. The script uses the Linux' drm_pciids.h
header for new IDs, the FreeBSD's one because we add the name of the
device to each IDs, and the PCI IDs database (misc/pciids port) to fill
this name automatically for new IDS.
To call the script:
tools/tools/drm/gen-drm_pciids \
/path/to/linux/drm_pciids.h \
/path/to/freebsd/drm_pciids.h \
/path/to/pciids/pci.ids
Author: Shirish S <s.shirish@samsung.com>
Date: Thu Aug 30 07:04:06 2012 +0000
drm: edid: add support for E-DDC
The current logic for probing ddc is limited to
2 blocks (256 bytes), this patch adds support
for the 4 block (512) data.
To do this, a single 8-bit segment index is
passed to the display via the I2C address 30h.
Data from the selected segment is then immediately
read via the regular DDC2 address using a repeated
I2C 'START' signal.
Signed-off-by: Shirish S <s.shirish@samsung.com> Reviewed-by: Jean Delvare <jdelvare@suse.de> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Ville Syrjala <ville.syrjala@linux.intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
git-svn-id: svn://svn.freebsd.org/base/stable/9@261660 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
dumbbell [Sun, 9 Feb 2014 14:02:39 +0000 (14:02 +0000)]
MFC r254819:
drm: Don't delete already deleted iicbus child from drm_iic_dp_aux
The iic_dp_aux_detach callback is therefore useless: it's replaced by
bus_generic_detach. This fixes a "General protection fault" panic during
second (incorrect) deletion of the child.
dim [Sun, 9 Feb 2014 00:37:16 +0000 (00:37 +0000)]
MFC r255093 (by theraven):
Don't use _Unwind_Backtrace() on ARM as it's currently missing from
our libgcc_s. andrew@ has patches to add it, so this can be reverted
and sync'd with upstream later.
MFC r255815 (by theraven):
Import a new libcxxrt. This fixes some potential crashing in the
demangler.
MFC r260553 (by theraven):
Add missing C++11 typeinfos to the libcxxrt version script.
kib [Sat, 8 Feb 2014 15:51:42 +0000 (15:51 +0000)]
MFC r261354:
In _pthread_kill(), if passed pthread is current thread, do not send
the signal second time, by adding the missed else before if statement.
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Mon Jun 4 18:39:20 2012 +0200
drm/i915: adjusted_mode->clock in the dp mode_fixup
... instead of changing mode->clock, which we should leave as-is.
After the previous patch we only touch that if it's a panel, and then
adjusted mode->clock equals adjusted_mode->clock. Outside of
intel_dp.c we only use ajusted_mode->clock in the mode_set functions.
Within intel_dp.c we only use it to calculate the dp dithering
and link bw parameters, so that's the only thing we need to fix
up.
As a temporary ugliness (until the cleanup in the next patch) we
pass the adjusted_mode into dp_dither for both parameters (because
that one still looks at mode->clock).
Note that we do overwrite adjusted_mode->clock with the selected dp
link clock, but that only happens after we've calculated everything we
need based on the dotclock of the adjusted output configuration.
Outside of intel_dp.c only intel_display.c uses adjusted_mode->clock,
and that stays the same after this patch (still equals the selected dp
link clock). intel_display.c also needs the actual dotclock (as
target_clock), but that has been fixed up in the previous patch.
v2: Adjust the debug message to also use adjusted_mode->clock.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
git-svn-id: svn://svn.freebsd.org/base/stable/9@261630 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
dumbbell [Sat, 8 Feb 2014 08:16:38 +0000 (08:16 +0000)]
MFC r259679:
vga_pci: Improve boot display detection
The previous code was checking the "VGA Enable" bit on the video card's
parent PCI-to-PCI bridge only. This didn't work for the case where the
video card is attached to the root PCI bus (ie. the card has no parent
PCI-to-PCI bridge).
Now, the new code:
1. checks the "VGA Enable" bit on the parent bridge only if it's a
PCI-to-PCI bridge;
2. always checks the "I/O" and "Memory address space decoding" bits
on the video card itself.
However, vendor-specific bits are not used.
This fixes the use of many integrated Radeon cards: without this patch,
we fail to detect them as the boot display and, when radeonkms looks for
the Video BIOS, it skips the shadow copy made by the System BIOS. It
then fails to fully initialize the card, because the shadow copy is the
only way to read the Video BIOS in these situations. A workaround was to
force the boot display selection using the "hw.pci.default_vgapci_unit"
tunable.
A previous version of this patch added a new function doing the checks.
Now, the vga_pci_is_boot_display() function is used to perform the
checks (only until the boot display is found) and return if the given
device is the boot display or not.
Furthermore, vga_pci_attach() logs "Boot video device" if the card being
attached it the Chosen One:
vgapci0: <VGA-compatible display> [...]
vgapci0: Boot video device
dumbbell [Sat, 8 Feb 2014 07:53:39 +0000 (07:53 +0000)]
MFC r254882, r254883, r255571:
vga_pci: Add API to map the Video BIOS
Here are two new functions to map and unmap the Video BIOS:
void * vga_pci_map_bios(device_t dev, size_t *size);
void vga_pci_unmap_bios(device_t dev, void *bios);
The BIOS is either taken from the shadow copy made by the System BIOS at
boot time if the given device was used for the default display (i386,
amd64 and ia64 only), or from the PCI expansion ROM.
Additionally, one can determine if a given device was the default
display at boot time using the following new function:
int vga_pci_is_boot_display(device_t dev);
hselasky [Fri, 7 Feb 2014 07:31:54 +0000 (07:31 +0000)]
MFC r244535, r245995, r261505 and r258961:
- Use a boundary of zero, hence a PAGE_SIZE boundary
is implied by all memory allocations.
- Fix an external compiler warning about write-only
assigned variable.
projects / FreeBSD / stable / 9.git / log