| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
This patch fix a lockdep in the at86rf230 driver, otherwise we get:
[ 30.206517] =================================
[ 30.211078] [ INFO: inconsistent lock state ]
[ 30.215647] 3.14.0-20140108-1-00994-g32e9426 #163 Not tainted
[ 30.221660] ---------------------------------
[ 30.226222] inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage.
[ 30.232514] systemd-udevd/157 [HC1[1]:SC0[0]:HE0:SE1] takes:
[ 30.238439] (&(&lp->lock)->rlock){?.+...}, at: [<c03600f8>] at86rf230_isr+0x18/0x44
[ 30.246621] {HARDIRQ-ON-W} state was registered at:
[ 30.251728] [<c0061ce4>] __lock_acquire+0x7a4/0x18d8
[ 30.257135] [<c0063500>] lock_acquire+0x68/0x7c
[ 30.262071] [<c0588820>] _raw_spin_lock+0x28/0x38
[ 30.267203] [<c0361240>] at86rf230_xmit+0x1c/0x144
[ 30.272412] [<c057ba6c>] mac802154_xmit_worker+0x88/0x148
[ 30.278271] [<c0047844>] process_one_work+0x274/0x404
[ 30.283761] [<c00484c0>] worker_thread+0x228/0x374
[ 30.288971] [<c004cfb8>] kthread+0xd0/0xe4
[ 30.293455] [<c000dac8>] ret_from_fork+0x14/0x2c
[ 30.298493] irq event stamp: 8948
[ 30.301963] hardirqs last enabled at (8947): [<c00cb290>] __kmalloc+0xb4/0x110
[ 30.309636] hardirqs last disabled at (8948): [<c00115d4>] __irq_svc+0x34/0x5c
[ 30.317215] softirqs last enabled at (8452): [<c0037324>] __do_softirq+0x1dc/0x264
[ 30.325243] softirqs last disabled at (8439): [<c0037638>] irq_exit+0x80/0xf4
We use the lp->lock inside the isr of at86rf230, that's why we need the
irqsave spinlock calls.
Signed-off-by: Alexander Aring <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
When mlx4_en_stop_port() is called, we need to deregister also the
tunnel steering rules that relate to multicast.
Signed-off-by: Or Gerlitz <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
We have two paths that try to reset the forcewake registers back to
known good values, with slightly different semantics and levels of
paranoia. Combine the two by passing a parameter to either restore the
forcewake status or to clear our bookkeeping, and raise the paranoia
level to max.
Signed-off-by: Chris Wilson <[email protected]>
Reviewed-by: Mika Kuoppala <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
Since commit d25f06ea466e "vmxnet3: fix netpoll race condition",
the vmxnet3 driver fails to build when CONFIG_PCI_MSI is disabled,
because it unconditionally references the vmxnet3_msix_rx()
function.
To fix this, use the same #ifdef in the caller that exists around
the function definition.
Signed-off-by: Arnd Bergmann <[email protected]>
Cc: Neil Horman <[email protected]>
Cc: Shreyas Bhatewara <[email protected]>
Cc: "VMware, Inc." <[email protected]>
Cc: "David S. Miller" <[email protected]>
Cc: [email protected]
Acked-by: Neil Horman <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
Add it to NETWORKING [GENERAL] to make sure patches for selftests
go to the netdev list as well.
Signed-off-by: Daniel Borkmann <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
It's been in there since forever, and no one cared. Doesn't put a too
good light onto our bug handling and QA efforts really ...
References: https://bugs.freedesktop.org/attachment.cgi?id=90970
Signed-off-by: Daniel Vetter <[email protected]>
|
|
- Standardized on "Returns:" Block.
- Sprinkle missing kerneldoc over all exported functions and all
ioctls.
- Add a stern warning that driver's really shouldn't use
drm_mode_group_init_legacy_group.
- Usual attempt at more consistency.
- Add warnings that drm_mode_object_get/put don't do refcounting,
despite what the names might lead to believe.
- Try to clarify the framebuffer setup/cleanup functions wrt driver
private framebuffers - I've fallen recently over this when reviewing
i915 fbdev patches.
- Align function parameters where the kerneldoc has been updated.
- Most of the drm_get_*_name functions aren't thread safe. Add stern
warnings where this is the case.
Since a lot of the functions in drm_crtc.c are boilerplate to handle
properties and create default sets of them it might be useful to
extract all that code into a new file drm_property.c. Especially since
properties will be used a lot more in the future.
Reviewed-by: Alex Deucher <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
Most of this is newly added kerneldoc for the hotplug and output
polling code. But I've also thrown in a bit lesser polish, most of it
is tuning down the shouting RETURN: headers.
Overview documentation for the output probing and mode setting support
code will be added in later patches.
Reviewed-by: Alex Deucher <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
No driver cares, and it should generally work. Add a big comment
when drivers can't use this for recompense.
Reviewed-by: Alex Deucher <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
- It yells.
- WARNing about incorrect locking is harder to ignore, so better
than kerneldoc.
- Since those have been written per-crtc locks were added ...
So remove them and replace them by appropriate WARNs.
Reviewed-by: Alex Deucher <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
Rightfully no driver ever checked this - it can't fail.
Reviewed-by: Alex Deucher <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
Oops. This is a regression from
commit 5d7a951537927555fa1286a338e1b91c3b8b7445
Author: Daniel Vetter <[email protected]>
Date: Fri Jan 4 22:31:20 2013 +0100
drm/doc: updates for new framebuffer lifetime rules
Reviewed-by: Alex Deucher <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
It' unused and there's also not really any way to make it work with
the current code. So better rip it out.
Reviewed-by: Alex Deucher <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
- Tune down yelling RETURNS.
- OCD align all the parameters the same.
- Add missing kerneldoc, which also means that we need to include the
kerneldoc from the drm_modes.h header now.
- Add missing Returns: sections.
- General polish and clarification - especially the kerneldoc for the
mode creation helpers seems to have been some good specimen of
copypasta gone wrong.
All actual code changes have all been extracted into prep patches
since there was simply too much to polish.
v2: More polish for the command line modeline functions.
Reviewed-by: Alex Deucher <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
Totally unused and actually redundant with maxX for display mode
validation. The fb helper otoh needs to check pitch limits,
but that is delegated into drivers instead.
Reviewed-by: Alex Deucher <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
It never fails and no one ever checked anyway.
Reviewed-by: Alex Deucher <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
There's a neat FIXME asking whether this is really need. I'd
say really no.
Reviewed-by: Alex Deucher <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
I want to also include kerneldoc from the header (for static inline
functions and structs), but fishing the right pieces out of a giant
header is a real pain. So split things out.
Note that it's not a really clean header with sane include orders, but
given's drm historical knack for giant headers detangling this is a
major task.
v2: Also extract struct drm_cmdline_mode.
Reviewed-by: Alex Deucher <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
Makes more sense and gives better grouping in the DocBook function
reference sections. To make this possible we need to expose two
functions from drm_crtc.c though. To avoid further namespace pollution
in the system wide headers create a new internal header for such drm
internal symbols.
I expect that longer-term we'll add tons more, but since my goal here
is to polish the kerneldoc that's for another day.
Reviewed-by: Alex Deucher <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
There's not really any value in stating that no locking is needed. And
even if the comment is useful, a check for the right mutex at the
beginning of the function is better since that can't be ingored as
easily as a bit of documentation.
Note that drm_mode_probed_add in drm_crtc.c is also changed, the next
patch will move this into drm_modes.c
v2: Don't add locking WARN_ONs where it is not strictly required (i.e.
the two functions to validate/prune mode lists).
Reviewed-by: Alex Deucher <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
And clean it up so that there's no kerneldoc warnings. There's still a
lot to do with this one here.
Reviewed-by: Alex Deucher <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
It's only used by imx, and that one gets it wrong - there's no need
to deteach the encoder before removing it.
And really, neither current drm modesetting code nor all the userspace
we have can handle dynamic changes in the set of possible encoders for
a given connector. So let's just remove this before someone starts
doing something really nasty with it.
As a plus, one less kerneldoc comment to write.
Cc: Sascha Hauer <[email protected]>
Cc: Russell King <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Reviewed-by: Alex Deucher <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
While at it do a tiny bit of interface cleanup and convert boolean
return values to bool. With this patch all exported functions and inline
helpers which are part of the drm_mm public interface are documented.
Also drop superflous extern function modifiers since most of drm_mm.h
doesn't use them - more consistent that way.
Reviewed-by: Alex Deucher <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
kerneldoc polish will follow in the next patch.
Hopefully documenting the lru scan support a bit better spurs someone
to give this a shot in the ttm eviction code. At least in i915 it
helped quite a lot with memory thrashing on platforms where eviction
was (we've fixed that too meanwhile) fairly expensive.
Reviewed-by: Alex Deucher <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
This was missed in
commit c700c67bae6698fbc6bd20e2ae5dc62ddd367b3b
Author: David Herrmann <[email protected]>
Date: Sat Jul 27 13:39:28 2013 +0200
drm/mm: remove unused API
Cc: David Herrmann <[email protected]>
Reviewed-by: Alex Deucher <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
I've done quite a bit of cleanups, clarifications and mostly
integrating kerneldoc. So I guess I should add myself.
Also split up the copyright notices per holder to make it clear which
year ranges are covered.
Reviewed-by: Alex Deucher <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
For giant hilarity the DocBook reference overview is only generated
when in a level 2 section, not in a level 3 section. So we need to
move this up a bit as a side-by-side section to the main PRIME
documentation.
Whatever.
To have a complete set of references add the missing kerneldoc for all
functions exported to modules with the exception of the file private
init/destroy functions - drivers have no business calling those, so
let's just drop the EXPORT_SYMBOL instead.
Also reflow the function parameters to align correctly and break at 80
chars - my OCD couldn't stand them while writing the kerneldoc ;-)
Reviewed-by: Alex Deucher <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
PRIME fds aren't actually GEM fds but are (like the modeset API)
independent of the underlying buffer manager, as long as that one uses
uint32_t as handles. So move that entire section out of the GEM
section and reword it a bit to clarify which parts of PRIME are
generic, and which are the mandatory pieces for GEM drivers to
correctly implement the GEM lifetime rules. The rewording mostly
consists of not mixing up GEM, PRIME and DRM.
I've considered adding some blurbs to the GEM object lifetime section
about interactions with dma-bufs, but then dropped that. As long as
drivers use the right helpers they should have this all implemented
correctly and hence can be regarded as an implementation detail of the
PRIME/GEM helpers. So no need to confuse driver writers with those
tricky interactions.
Reviewed-by: Alex Deucher <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
Thierry created such nice kerneldocs, it's a shame we've left them
lingering!
For the fun of it also add a bit of kerneldoc to the header so that we
can also include that. Just in case someone adds kerneldoc in there.
Cc: Thierry Reding <[email protected]>
Reviewed-by: Alex Deucher <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
By consolidating them all into one section at the very end. And to
make double-sure that no one gets confused start with a stern warning
against any use of them. And prefix all subsections with "Legacy".
Reviewed-by: Alex Deucher <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
Stumbled over while reviewing all occurences in the DRM doc talking
about suspend/resume.
Reviewed-by: Alex Deucher <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
Those all died with
commit 0111be42186fc5461b9e9d579014c70869ab3152
Author: Ville Syrjälä <[email protected]>
Date: Fri Oct 4 14:53:41 2013 +0300
drm: Kill drm perf counter leftovers
Reviewed-by: Alex Deucher <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
This should be done in the driver chapter instead.
Reviewed-by: Alex Deucher <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
Currently it's sitting in the mode setting helper section, which isn't
quite right. Looks much better in the memory management section next
to TTM and GEM.
Cc: David Herrmann <[email protected]>
Reviewed-by: Alex Deucher <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
Split up the DocBook into the core drm part and a 2nd part for
driver documentation. As an example add a very (very!) basic
skeleton for i915.
v1: Typo fixes from Dieter.
Cc: Dieter Nützel <[email protected]>
Reviewed-by: Alex Deucher <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
The stylesheet doesn't allow this in normal paragraphs.
Cc: David Herrmann <[email protected]>
Acked-by: David Herrmann <[email protected]>
Reviewed-by: Alex Deucher <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
Fairly incomplete, but at least a start.
Reviewed-by: Alex Deucher <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
v2: Also do s/RETURNS/Returns/, less yelling in docs is always good.
Reviewed-by: Alex Deucher <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
- This is _not_ a generic interface to create gem objects, but just an
interface to make early boot services (like boot splash) with a
generic KMS userspace driver possible. Hence it's better to move
the documentation for this from the GEM section to the KMS section,
next to the creation of framebuffer objects.
- Make it really clear that the returned handle isn't necessarily a
GEM object (it can also be e.g. a TTM handle when running on top of
vmwgfx).
- Add a paragraph to make it clear that this is just for unaccelarated
userspace - gpu drivers need to have their own buffer object
creation ioctl which is hardware specific.
v2: Clarify that the documentation doesn't just apply to GEM-based
drivers only but is now generally valid, as suggested by David.
v3: Polish the intro sentence a bit and one s/objects/handles/ for
clarification, both suggested by Laurent.
v4: More text polish from Laurent's review.
v5: More typo fixes from Dieter.
Cc: Dieter Nützel <[email protected]>
Cc: David Herrmann <[email protected]>
Cc: Laurent Pinchart <[email protected]>
Acked-by: Laurent Pinchart <[email protected]>
Reviewed-by: Alex Deucher <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
Now that we regularly defer the forcewake dance to a timer func, it is
likely to fire after we disable the device during suspend. This
generates an oops as we detect inconsistency in the hardware state. So
before suspend, we want to complete the outstanding dance and generally
sanitize the registers before handing back to the BIOS.
Signed-off-by: Chris Wilson <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
neighbours
When we change the cache_level for an object we need to make sure
we don't put differing types of snoopable memory too close to each
other on non-LLC machines.
Currently i915_gem_object_set_cache_level() will stop looking when
it finds just one vma that has such a conflict. Drop the bogus break
statement to make sure it will unbind all vmas which need to be moved
around to avoid the conflict.
I suppose this is a theoretical issue as currently we don't enable
ppgtt on non-LLC machines, so each object can only have one vma.
Signed-off-by: Ville Syrjälä <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
We will call ppgtt_bind_vma() with flags != 0, so the WARN_ON(flags)
is bogus. Kill it.
Signed-off-by: Ville Syrjälä <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
git://people.freedesktop.org/~thomash/linux into drm-fixes
Second pull request of 2014-03-12. The first one was requested to be canceled.
Rob's fix for oops on invalidate_caches() and a fix for a
performance regression.
* tag 'ttm-fixes-3.14-2014-03-12' of git://people.freedesktop.org/~thomash/linux:
drm/ttm: don't oops if no invalidate_caches()
drm/ttm: Work around performance regression with VM_PFNMAP
|
|
into drm-fixes
A few more radeon fixes.
* 'drm-fixes-3.14' of git://people.freedesktop.org/~agd5f/linux:
drm/radeon/cik: properly set compute ring status on disable
drm/radeon/cik: stop the sdma engines in the enable() function
drm/radeon/cik: properly set sdma ring status on disable
drm/radeon: fix runpm disabling on non-PX harder
|
|
git://people.freedesktop.org/~thomash/linux into drm-fixes
Pull request of 2014-03-13
one minor fix for new hw
* tag 'vmwgfx-fixes-3.14-2014-03-13' of git://people.freedesktop.org/~thomash/linux:
drm/vmwgfx: Fix a surface reference corner-case in legacy emulation mode
|
|
If running on a gb-object capable device with a non-gb capable surface
exporter (X server) and a gb capable surface referencing client (GL driver),
the referencing client expects to find a shareable backing buffer attached to
the surface at reference time. This may not be the case if the surface has
not yet been validated. This would cause the surface reference IOCTL to
return an error.
Signed-off-by: Thomas Hellstrom <[email protected]>
Reviewed-by: Jakob Bornecrantz <[email protected]>
|
|
While wandering in the spec, I noticed that BDW removes those 2 bits
from INSTPM. I couldn't find any direct way to invalidate the TLB (ie
without the ring working already). Maybe someone will be more lucky.
At least, we now know we may be a problem.
Signed-off-by: Damien Lespiau <[email protected]>
Reviewed-by: Ben Widawsky <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci
Pull PCI fixes from Bjorn Helgaas:
"These are two important regression fixes for bugs we've introduced so
far in v3.14.
One of the resource allocation changes from the merge window is broken
for 32-bit kernels where we don't use _CRS for PCI host bridges
(mostly pre-2008 machines), so there's a fix for that.
The INTx enable change we put in after the merge window turned out to
break pciehp because we re-enable INTx on the hotplug bridge, which
apparently breaks MSI for future hotplug events"
* tag 'pci-v3.14-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci:
PCI: Don't check resource_size() in pci_bus_alloc_resource()
PCI: Enable INTx in pci_reenable_device() only when MSI/MSI-X not enabled
|
|
Pull KVM fixes from Paolo Bonzini:
"The ARM patch fixes a build breakage with randconfig. The x86 one
fixes Windows guests on AMD processors"
* tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm:
KVM: SVM: fix cr8 intercept window
ARM: KVM: fix non-VGIC compilation
|
|
Commit 73f7d1ca3263 (ACPI / init: Run acpi_early_init() before
timekeeping_init()) optimistically moved the early ACPI initialization
before timekeeping_init(), but that didn't work, because it broke fast
TSC calibration for Julian Wollrath on Thinkpad x121e (and most likely
for others too). The reason is that acpi_early_init() enables the SCI
and that interferes with the fast TSC calibration mechanism.
Thus follow the original idea to execute acpi_early_init() before
efi_enter_virtual_mode() to help the EFI people for now and we can
revisit the other problem that commit 73f7d1ca3263 attempted to
address in the future (if really necessary).
Fixes: 73f7d1ca3263 (ACPI / init: Run acpi_early_init() before timekeeping_init())
Reported-by: Julian Wollrath <[email protected]>
Reviewed-by: Thomas Gleixner <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>
|