| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Right now a debug message looks like:
[drm:drm_ioctl], pid=860, dev=0xe200, auth=1, DRM_IOCTL_MODE_GETCRTC
That first comma looks weird as we already have ']' as a separator.
Remove it.
If anyone sees this commit message and also thinks that auth=1 isn't the
most useful info to have here, let's just say I'd happily review a patch
removing it. If I don't get annoyed enough to submit a patch, that is.
Signed-off-by: Damien Lespiau <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
This is always DRM_NAME, so we can just make it part of the format
string instead of asking prink to do it for us.
Signed-off-by: Damien Lespiau <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
The DRM_LOG* macros where the only sites where drm_ut_debug_printk was
called with NULL arguments for prefix and function_name. Now that they
are gone, we can remove that case.
Signed-off-by: Damien Lespiau <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
In the logging code, we are currently checking is we need to output in
drm_ut_debug_printk(). This is too late. The problem is that when we write
something like:
DRM_DEBUG_DRIVER("ELD on [CONNECTOR:%d:%s], [ENCODER:%d:%s]\n",
connector->base.id,
drm_get_connector_name(connector),
connector->encoder->base.id,
drm_get_encoder_name(connector->encoder));
We start by evaluating the arguments (so call drm_get_connector_name() and
drm_get_connector_name()) before ending up in drm_ut_debug_printk() which will
then does nothing.
This means we execute a lot of instructions (drm_get_connector_name(), in turn,
calls snprintf() for example) to happily discard them in the normal case,
drm.debug=0.
So, let's put the test on drm_debug earlier, in the macros themselves.
Sprinkle an unlikely() as well for good measure.
Signed-off-by: Damien Lespiau <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
Signed-off-by: Damien Lespiau <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
There are only a few users of the DRM_LOG_KMS() macro. We can simplify
the DRM code a bit by replacing them by DRM_DEBUG_KMS().
Cc: Philipp Zabel <[email protected]>
Cc: Lucas Stach <[email protected]>
Signed-off-by: Damien Lespiau <[email protected]>
Acked-by: Philipp Zabel <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
There are only a few users of the DRM_LOG_KMS() macro. We can simplify
the DRM code a bit by replacing them by DRM_DEBUG_KMS().
Signed-off-by: Damien Lespiau <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
There are only a few users of the DRM_LOG_KMS() macro. We can simplify
the DRM code a bit by replacing them by DRM_DEBUG_KMS().
Cc: Patrik Jakobsson <[email protected]>
Signed-off-by: Damien Lespiau <[email protected]>
Acked-by: Patrik Jakobsson <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
There are only a few users of the DRM_LOG_KMS() macro. We can simplify
the DRM code a bit by replacing them by DRM_DEBUG_KMS().
Cc: Inki Dae <[email protected]>
Signed-off-by: Damien Lespiau <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
This macro was trying to use the non existing DRM_UT_MODE debug category
and looks like it should be covered by DRM_LOG_KMS().
Signed-off-by: Damien Lespiau <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
That comment wasn't super-readable, so I tried to improve it:
- Put the comment before the values it's documenting
- Add a mention to PRIME
- Reword things a bit to be a lighter read
- Add a note about the option to set the debug value at run-time
Signed-off-by: Damien Lespiau <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
It apparently blows up on some machines. This functionally reverts
commit 828c79087cec61eaf4c76bb32c222fbe35ac3930
Author: Ben Widawsky <[email protected]>
Date: Wed Oct 16 09:21:30 2013 -0700
drm/i915: Disable GGTT PTEs on GEN6+ suspend
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=64841
Reported-and-Tested-by: Brad Jackson <[email protected]>
Cc: [email protected]
Cc: Takashi Iwai <[email protected]>
Cc: Paulo Zanoni <[email protected]>
Cc: Todd Previte <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
Same fix as for nouveau, when we fail with EINVAL, subsequent
gets fail hard, causing the device not to open.
Signed-off-by: Dave Airlie <[email protected]>
Reviewed-by: Alex Deucher <[email protected]>
|
|
The second parameter of __mlx4_init_one() is used to identify whether the
pci_dev is a PF or VF. Currently, when it is invoked in mlx4_pci_slot_reset()
this information is missed.
This patch match the pci_dev with mlx4_pci_table and passes the
pci_device_id.driver_data to __mlx4_init_one() in mlx4_pci_slot_reset().
Signed-off-by: Wei Yang <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
skb_zerocopy can copy elements of the frags array between skbs, but it doesn't
orphan them. Also, it doesn't handle errors, so this patch takes care of that
as well, and modify the callers accordingly. skb_tx_error() is also added to
the callers so they will signal the failed delivery towards the creator of the
skb.
Signed-off-by: Zoltan Kiss <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
Currently, if the card supports CTAG acceleration we do not
account for the vlan header even if we are configuring an
8021AD vlan. This may not be best since we'll do software
tagging for 8021AD which will cause data copy on skb head expansion
Configure the length based on available hw offload capabilities and
vlan protocol.
CC: Patrick McHardy <[email protected]>
Signed-off-by: Vlad Yasevich <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
This fixes a race which happens by freeing an object on the stack.
Quoting Julius:
> The issue is
> that it calls usbnet_terminate_urbs() before that, which temporarily
> installs a waitqueue in dev->wait in order to be able to wait on the
> tasklet to run and finish up some queues. The waiting itself looks
> okay, but the access to 'dev->wait' is totally unprotected and can
> race arbitrarily. I think in this case usbnet_bh() managed to succeed
> it's dev->wait check just before usbnet_terminate_urbs() sets it back
> to NULL. The latter then finishes and the waitqueue_t structure on its
> stack gets overwritten by other functions halfway through the
> wake_up() call in usbnet_bh().
The fix is to just not allocate the data structure on the stack.
As dev->wait is abused as a flag it also takes a runtime PM change
to fix this bug.
Signed-off-by: Oliver Neukum <[email protected]>
Reported-by: Grant Grundler <[email protected]>
Tested-by: Grant Grundler <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
Current error handling of virtqueue_kick() was wrong in two places:
- The skb were freed immediately when virtqueue_kick() fail during
xmit. This may lead double free since the skb was not detached from
the virtqueue.
- try_fill_recv() returns false when virtqueue_kick() fail. This will
lead unnecessary rescheduling of refill work.
Actually, it's safe to just ignore the kick failure in those two
places. So this patch fixes this by partially revert commit
67975901183799af8e93ec60e322f9e2a1940b9b.
Fixes 67975901183799af8e93ec60e322f9e2a1940b9b
(virtio_net: verify if virtqueue_kick() succeeded).
Cc: Heinz Graalfs <[email protected]>
Cc: Rusty Russell <[email protected]>
Cc: Michael S. Tsirkin <[email protected]>
Signed-off-by: Jason Wang <[email protected]>
Acked-by: Michael S. Tsirkin <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
Currently we allocated anon_inode_inode in anon_inodefs_mount. This is
somewhat fragile as if that function ever gets called again, it will
overwrite anon_inode_inode pointer. So move the initialization of
anon_inode_inode to anon_inode_init().
Signed-off-by: Jan Kara <[email protected]>
[ Further simplified on suggestion from Dave Jones ]
Signed-off-by: Linus Torvalds <[email protected]>
|
|
If we were on a non-optimus device, we'd return -EINVAL, this would
lead to the over engineered runtime pm system to go into an error
state, subsequent get_sync's would fail, so we'd never be able
to open the device again.
(like really get_sync shouldn't fail if the device isn't powered
down).
Signed-off-by: Dave Airlie <[email protected]>
Reviewed-by: Alex Deucher <[email protected]>
|
|
this stops the device from being deleted before all the dma-bufs
on it are freed, this fixes an oops when you unplug a udl device while
it has imported a buffer from another device.
Signed-off-by: Dave Airlie <[email protected]>
|
|
The recently added PTN3460 device driver uses interfaces that
are provided by the KMS helper infrastructure, so we should
explicitly select that to avoid this linker error:
ERROR: "drm_helper_probe_single_connector_modes" [drivers/gpu/drm/bridge/ptn3460.ko] undefined!
ERROR: "drm_helper_connector_dpms" [drivers/gpu/drm/bridge/ptn3460.ko] undefined!
We have to drop the I2C dependency to avoid a circular dependency
chain, but that's ok because DRM already selects I2C.
Signed-off-by: Arnd Bergmann <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
Some applications didn't expect recvmsg() on a non blocking socket
could return -EINTR. This possibility was added as a side effect
of commit b3ca9b02b00704 ("net: fix multithreaded signal handling in
unix recv routines").
To hit this bug, you need to be a bit unlucky, as the u->readlock
mutex is usually held for very small periods.
Fixes: b3ca9b02b00704 ("net: fix multithreaded signal handling in unix recv routines")
Signed-off-by: Eric Dumazet <[email protected]>
Cc: Rainer Weikusat <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
Thomas Petazzoni says:
====================
net: mvneta: fix usage as a module
The following set of two patches fix the usage of the mvneta driver
when built as a module, and used in RGMII configurations. It is
somewhat similar to a previous fix that was made by Arnaud Patard, but
which was limited to SGMII configurations.
====================
Signed-off-by: David S. Miller <[email protected]>
|
|
The mvneta driver currently uses of_iomap(), which has two drawbacks:
it doesn't request the resource, and it isn't devm-style so some error
handling is needed.
This commit switches to use devm_ioremap_resource() instead, which
automatically requests the resource (so the I/O registers region shows
up properly in /proc/iomem), and also is devm-style, which allows to
get rid of some error handling to unmap the I/O registers region.
Signed-off-by: Thomas Petazzoni <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
Commit 5445eaf309ff ('mvneta: Try to fix mvneta when compiled as
module') fixed the mvneta driver to make it work properly when loaded
as a module in SGMII configuration, which was tested successful by the
author on the Armada XP OpenBlocks AX3, which uses SGMII.
However, it turns out that the Armada XP GP, which uses RGMII, is
affected by a similar problem: its SERDES configuration is lost when
mvneta is loaded as a module, because this configuration is set by the
bootloader, and then lost because the clock is gated by the clock
framework until the mvneta driver is loaded again and the clock is
re-enabled.
However, it turns out that for the RGMII case, setting the SERDES
configuration is not sufficient: the PCS enable bit in the
MVNETA_GMAC_CTRL_2 register must also be set, like in the SGMII
configuration.
Therefore, this commit reworks the SGMII/RGMII initialization: the
only difference between the two now is a different SERDES
configuration, all the rest is identical.
In detail, to achieve this, the commit:
* Renames MVNETA_SGMII_SERDES_CFG to MVNETA_SERDES_CFG because it is
not specific to SGMII, but also used on RGMII configurations.
* Adds a MVNETA_RGMII_SERDES_PROTO definition, that must be used as
the MVNETA_SERDES_CFG value in RGMII configurations.
* Removes the mvneta_gmac_rgmii_set() and mvneta_port_sgmii_config()
functions, and instead directly do the SGMII/RGMII configuration in
mvneta_port_up(), from where those functions where called. It is
worth mentioning that mvneta_gmac_rgmii_set() had an 'enable'
parameter that was always passed as '1', so it was pretty useless.
* Reworks the mvneta_port_up() function to set the MVNETA_SERDES_CFG
register to the appropriate value depending on the RGMII vs. SGMII
configuration. It also unconditionally set the PCS_ENABLE bit (was
already done for SGMII, but is now also needed for RGMII), and sets
the PORT_RGMII bit (which was already done for both SGMII and
RGMII).
This commit was successfully tested with mvneta compiled as a module,
on both the OpenBlocks AX3 (SGMII configuration) and the Armada XP GP
(RGMII configuration).
Reported-by: Steve McIntyre <[email protected]>
Cc: [email protected] # 3.11.x: 5445eaf309ff mvneta: Try to fix mvneta when compiled as module
Signed-off-by: Thomas Petazzoni <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
Bit 3 of the MVNETA_GMAC_CTRL_2 is actually used to enable the PCS,
not the PSC: there was a typo in the name of the define, which this
commit fixes.
Cc: [email protected]
Signed-off-by: Thomas Petazzoni <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
The cypress PS/2 trackpad models supported by the cypress_ps2 driver
emulate BTN_RIGHT events in firmware based on the finger position, as part
of this no motion events are sent when the finger is in the button area.
The INPUT_PROP_BUTTONPAD property is there to indicate to userspace that
BTN_RIGHT events should be emulated in userspace, which is not necessary
in this case.
When INPUT_PROP_BUTTONPAD is advertised userspace will wait for a motion
event before propagating the button event higher up the stack, as it needs
current abs x + y data for its BTN_RIGHT emulation. Since in the
cypress_ps2 pads don't report motion events in the button area, this means
that clicks in the button area end up being ignored, so
INPUT_PROP_BUTTONPAD actually causes problems for these touchpads, and
removing it fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=76341
Reported-by: Adam Williamson <[email protected]>
Tested-by: Adam Williamson <[email protected]>
Reviewed-by: Peter Hutterer <[email protected]>
Signed-off-by: Hans de Goede <[email protected]>
Signed-off-by: Dmitry Torokhov <[email protected]>
|
|
Including hardware acceleration features in vlan_features breaks
stacked vlans (Q-in-Q) by marking the bottom vlan interface as
capable of acceleration. This causes one of the tags to be lost
and the packets are sent with a sing vlan header.
CC: Nithin Nayak Sujir <[email protected]>
CC: Michael Chan <[email protected]>
Signed-off-by: Vlad Yasevich <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
Commit 10ddceb22ba (ip_tunnel:multicast process cause panic due
to skb->_skb_refdst NULL pointer) removed dst-drop call from
ip-tunnel-recv.
Following commit reintroduce dst-drop and fix the original bug by
checking loopback packet before releasing dst.
Original bug: https://bugzilla.kernel.org/show_bug.cgi?id=70681
CC: Xin Long <[email protected]>
Signed-off-by: Pravin B Shelar <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace
Pull tracing fix from Steven Rostedt:
"While on my flight to Linux Collaboration Summit, I was working on my
slides for the event trigger tutorial. I booted a 3.14-rc7 kernel to
perform what I wanted to teach and cut and paste it into my slides.
When I tried the traceon event trigger with a condition attached to it
(turns tracing on only if a field of the trigger event matches a
condition set by the user), nothing happened. Tracing would not turn
on. I stopped working on my presentation in order to find what was
wrong.
It ended up being the way trace event triggers work when they have
conditions. Instead of copying the fields, the condition code just
looks at the fields that were copied into the ring buffer. This works
great, unless tracing is off. That's because when the event is
reserved on the ring buffer, the ring buffer returns a NULL pointer,
this tells the tracing code that the ring buffer is disabled. This
ends up being a problem for the traceon trigger if it is using this
information to check its condition.
Luckily the code that checks if tracing is on returns the ring buffer
to use (because the ring buffer is determined by the event file also
passed to that field). I was able to easily solve this bug by
checking in that helper function if the returned ring buffer entry is
NULL, and if so, also check the file flag if it has a trace event
trigger condition, and if so, to pass back a temp ring buffer to use.
This will allow the trace event trigger condition to still test the
event fields, but nothing will be recorded"
* tag 'trace-fixes-v3.14-rc7-v2' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace:
tracing: Fix traceon trigger condition to actually turn tracing on
|
|
git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-next
- first stage of (ongoing) gpu fault recovery work
- initial support for maxwell (binary driver fw needed)
- various random fixes across the board
* 'drm-nouveau-next' of git://anongit.freedesktop.org/git/nouveau/linux-2.6: (87 commits)
drm/nouveau: fix missing newline
drm/nouveau/bios: fetch the vbios from PROM using only aligned 32-bit accesses
drm/nouveau/therm: let the vbios decide on the automatic fan management mode
drm/nvd7/therm: handle another kind of PWM fans
drm/nouveau/pm/fan: drop the fan lock in fan_update() before rescheduling
drm/nouveau: fix small thinko in vblank timestamping.
drm/nouveau/therm: check for sensor presence with requested mode, not current
drm/nouveau/disp/dp: allow 540MHz data rate
drm/nouveau: recognise higher link rate for available dp bw calculations
drm/nouveau/disp: limit dp capabilities as per dcb
drm/nva3/fbram: restrict training pattern setup to GT218
drm/nva3/devinit: restrict script access to some PFB regs
drm/nouveau/devinit: add interface to check if a mmio access by scripts is ok
drm/nouveau/bios: have strap reads show on devinit spam debug level
drm/nv50/gpio: fixup reset for gpios >= 16
drm/nv50/gpio: exclude sense value from mask when changing registers
drm/gk104/gr: therm magic needed on some kepler boards
drm/gm107/gr: initial support
drm/gf100-/gf: fix a stupid typo, waiting on wrong signal for mmctx
drm/nouveau/bios: parsing of some random table needed to bring up gr
...
|
|
Add a missing newline at the end of a DRM_INFO message.
Signed-off-by: Alexandre Courbot <[email protected]>
Reviewed-by: Thierry Reding <[email protected]>
Signed-off-by: Ben Skeggs <[email protected]>
|
|
Other kind of accesses are unreliable on Kepler cards. As advised by NVIDIA,
let's only use 32-bit accesses to fetch the vbios from PROM.
This fixes vbios fetching on my nve7 which failed in certain specific
conditions.
I suggest we Cc stable, for all kernels they still maintain after the big
rewrite.
Suggested-by: Christian Zander <[email protected]>
Signed-off-by: Martin Peres <[email protected]>
Signed-off-by: Ben Skeggs <[email protected]>
|
|
This should fix automatic fan management on fermi cards who do not have
0x46 entries in the thermal table.
On my nve6, the blob sets the default linear range from 40°C to 100°C
but my nvcf's default values are 40°C to 85°C. Let's keep 85 as a default
for everyone.
Signed-off-by: Martin Peres <[email protected]>
Tested-by: Timothée Ravier <[email protected]>
Signed-off-by: Ben Skeggs <[email protected]>
|
|
This should fix fan management on many nvd7+ chipsets.
Signed-off-by: Martin Peres <[email protected]>
Tested-by: Timothée Ravier <[email protected]>
Signed-off-by: Ben Skeggs <[email protected]>
|
|
This should fix a deadlock that has been reported to us where fan_update()
would hold the fan lock and try to grab the alarm_program_lock to reschedule
an update. On an other CPU, the alarm_program_lock would have been taken
before calling fan_update(), leading to a deadlock.
We should Cc: <[email protected]> # 3.9+
Reported-by: Marcin Slusarz <[email protected]>
Tested-by: Timothée Ravier <[email protected]>
Tested-by: Boris Fersing (IRC nick fersingb, no public email address)
Signed-off-by: Martin Peres <[email protected]>
Signed-off-by: Ben Skeggs <[email protected]>
|
|
*hpos horizontal scanout position doesn't need to be corrected
to count the pixels between hactive end and htotal negative.
That is only needed for *vpos to count lines until end of
vblank for the vblank timestamping.
Use hpos as is without correction.
Removes occassional spikes in timestamps of up to 1 scanline
duration, thereby improves accuracy to about +/- 2 usecs instead
of +/- 12 usecs, wrt. true onset time as measured with high
precision equipment on NV-A5.
Signed-off-by: Mario Kleiner <[email protected]>
Signed-off-by: Ben Skeggs <[email protected]>
|
|
Signed-off-by: Ben Skeggs <[email protected]>
|
|
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76319
Signed-off-by: Ilia Mirkin <[email protected]>
Signed-off-by: Ben Skeggs <[email protected]>
|
|
I should resurrect/merge that cleanup branch to remove the weird
duplication.. One day.
Signed-off-by: Ben Skeggs <[email protected]>
|
|
Signed-off-by: Ben Skeggs <[email protected]>
|
|
It doesn't look like the others have the registers.
Signed-off-by: Ben Skeggs <[email protected]>
|
|
Signed-off-by: Ben Skeggs <[email protected]>
|
|
Signed-off-by: Ben Skeggs <[email protected]>
|
|
Signed-off-by: Ben Skeggs <[email protected]>
|
|
Signed-off-by: Ben Skeggs <[email protected]>
|
|
Shouldn't effect anything, was just momentarily confusing while looking
at traces.
Signed-off-by: Ben Skeggs <[email protected]>
|
|
Not needed everywhere, and potentially not safe to do depending on how
the rest of PTHERM is configured...
Signed-off-by: Ben Skeggs <[email protected]>
|
|
Our ucode only partially works at this point, so requiring binary fw
image for now.
Signed-off-by: Ben Skeggs <[email protected]>
|