| Age | Commit message (Collapse) | Author |
|---|
|
o Uninitialzed fields in mailbox command structure
caused commands to time out randomly due to garbage
values so initialize it to zero.
Signed-off-by: Rajesh Borundia <rajesh.borundia@qlogic.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
If an MPLS packet requires segmentation then use mpls_features
to determine if the software implementation should be used.
As no driver advertises MPLS GSO segmentation this will always be
the case.
I had not noticed that this was necessary before as software MPLS GSO
segmentation was already being used in my test environment. I believe that
the reason for that is the skbs in question always had fragments and the
driver I used does not advertise NETIF_F_FRAGLIST (which seems to be the
case for most drivers). Thus software segmentation was activated by
skb_gso_ok().
This introduces the overhead of an extra call to skb_network_protocol()
in the case where where CONFIG_NET_MPLS_GSO is set and
skb->ip_summed == CHECKSUM_NONE.
Thanks to Jesse Gross for prompting me to investigate this.
Signed-off-by: Simon Horman <horms@verge.net.au>
Acked-by: YAMAMOTO Takashi <yamamoto@valinux.co.jp>
Acked-by: Thomas Graf <tgraf@suug.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Quoting David Miller:
"At the moment you call register_netdev() the device is visible, notifications
are sent to userspace, and userland tools can try to bring the interface up
and see the incorrect link state, before you do the netif_carrier_off().
Said another way, between the register_netdev() and netif_carrier_off() call,
userspace can see the device in an inconsistent state."
So call netif_carrier_off() prior to register_netdev().
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Tegra has been switching to intermediate frequency (pll_p_clk) forever.
CPUFreq core has better support for handling notifications for these
frequencies and so we can adapt Tegra's driver to it.
Also do a WARN() if clk_set_parent() fails while moving back to pll_x
as we should have atleast restored to earlier frequency on error.
Tested-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Reviewed-by: Doug Anderson <dianders@chromium.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Douglas Anderson, recently pointed out an interesting problem due to which
udelay() was expiring earlier than it should.
While transitioning between frequencies few platforms may temporarily switch to
a stable frequency, waiting for the main PLL to stabilize.
For example: When we transition between very low frequencies on exynos, like
between 200MHz and 300MHz, we may temporarily switch to a PLL running at 800MHz.
No CPUFREQ notification is sent for that. That means there's a period of time
when we're running at 800MHz but loops_per_jiffy is calibrated at between 200MHz
and 300MHz. And so udelay behaves badly.
To get this fixed in a generic way, introduce another set of callbacks
get_intermediate() and target_intermediate(), only for drivers with
target_index() and CPUFREQ_ASYNC_NOTIFICATION unset.
get_intermediate() should return a stable intermediate frequency platform wants
to switch to, and target_intermediate() should set CPU to that frequency,
before jumping to the frequency corresponding to 'index'. Core will take care of
sending notifications and driver doesn't have to handle them in
target_intermediate() or target_index().
NOTE: ->target_index() should restore to policy->restore_freq in case of
failures as core would send notifications for that.
Tested-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Reviewed-by: Doug Anderson <dianders@chromium.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Doing so allows the hotplug events generated by the connector to be
properly handled by the DRM poll helpers.
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
Calling the drm_helper_hpd_irq_event() helper can sleep, so instead of
invoking it directly from the interrupt handler, schedule a work queue
and run it from there.
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
Enable hardware cursor support on Tegra124. Earlier generations support
the hardware cursor to some degree as well, but not in a way that can be
generically exposed.
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
The DRM core can now cope with drivers that don't have an associated
struct drm_bus, so the host1x implementation is no longer useful.
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
With the recent addition of the drm_set_unique() function, devices can
now be registered without requiring a drm_bus. Add a brief description
to the DRM docbook to show how that can be achieved.
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
Describe how devices are registered using the drm_*_init() functions.
Adding this to docbook requires a largish set of changes to the comments
in drm_{pci,usb,platform}.c since they are doxygen-style rather than
proper kernel-doc and therefore mess with the docbook generation.
While at it, mark usage of drm_put_dev() as discouraged in favour of
calling drm_dev_unregister() and drm_dev_unref() directly.
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
Add a helper function that allows drivers to statically set the unique
name of the device. This will allow platform and USB drivers to get rid
of their DRM bus implementations and directly use drm_dev_alloc() and
drm_dev_register().
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
The internal host1x_{,un}register_client() functions can potentially be
confused with public the host1x_client_{,un}register() functions.
Rename them to host1x_{add,del}_client() to remove some of the possible
confusion.
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
The function is never used outside of the source file and therefore can
be locally scoped.
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
Tegra124 is mostly backwards-compatible with Tegra114. However, Tegra124
supports a few more features (e.g. interlacing, ...). Introduce a new
compatible string and TMDS tables to cope with these differences.
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
Accessing the CRC debugfs file will hang the system if the SOR is not
enabled, so make sure that it is stays enabled until the CRC has been
read.
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
In some cases the pixel clock used to not be correct, which is why it
had to be recomputed. It turns out that the reason why it wasn't correct
is that it was used wrongly. If used correctly there's not need for the
recomputation.
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
The shift clock divider is highly dependent on the type of output, so
push computation of it down into the output drivers. The old code used
to work merely by accident.
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
Program the shift clock divider in tegra_crtc_setup_clk() since that's
where the divider is computed, so passing it around can be avoided.
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
Assert the DSI controller's reset when the driver is unloaded to reduce
power consumption and to put the controller into a known state for
subsequent driver reloads.
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
When disabling the DSI controller, the code wasn't really doing what it
was supposed to.
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
To prevent the enable or disable operations to potentially be run
multiple times, add guards to return early when the output is already
in the targetted state.
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
The packet sequencer needs to be programmed depending on the video mode
of the attached peripheral. Add support for non-burst video modes with
sync events (as opposed to sync pulses) and select either sequence
depending on the video mode.
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
The DSI controllers are powered by a (typically 1.2V) regulator. Usually
this is always on, so there was no need to support enabling or disabling
it thus far. But in order not to consume any power when DSI is inactive,
give the driver a chance to enable or disable the supply as needed.
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
A bunch of registers are initialized to 0 upon during driver probe. It
turns out that none of these are actually needed, so they can simply be
dropped.
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
The pixel format enumeration values used by the Tegra DSI controller
don't match those defined by the DSI framework. Make sure to convert
them to the internal format before writing it to the register.
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
For some reason when the PW*_ENABLE and PM*_ENABLE fields are cleared
during disable, the HDMI output stops working properly. Resetting and
initializing doesn't help.
Comment out those accesses for now until it has been determined what to
do about them.
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
Disable LVDS mode according to register documentation. It seems like
this has no effect on the operation of HDMI, but it's probably a good
idea to do this anyway.
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
This reflects the power-up sequence as described in the documentation,
but it doesn't seem to be strictly necessary to get HDMI to work.
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
Clocks are never enabled or disabled in atomic context, so we can use
the clk_prepare_enable() and clk_disable_unprepare() helpers instead.
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
Schematics indicate that the AVDD_HDMI_PLL supply should be enabled
prior to the AVDD_HDMI supply.
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
The generic Tegra output code already sets up the clocks properly, so
there's no need to do it again when the HDMI output is enabled.
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
Revert commit 18ebc0f404d5 "drm/tegra: hdmi: Enable VDD earlier for
hotplug/DDC" and instead add a new supply for the +5V pin on the HDMI
connector.
The vdd-supply property refers to the regulator that supplies the
AVDD_HDMI input on Tegra, rather than the +5V HDMI connector pin. This
was never a problem before, because all boards had that pin hooked up to
a regulator that was always on. Starting with Dalmore and continuing
with Venice2, the +5V pin is controllable via a GPIO. For reasons
unknown, the GPIO ended up as the controlling GPIO of the AVDD_HDMI
supply in the Dalmore and Venice2 DTS files. But that's not correct.
Instead, a separate supply must be introduced so that the +5V pin can be
controlled separately from the supplies that feed the HDMI block within
Tegra.
A new hdmi-supply property is introduced that takes the place of the
vdd-supply and vdd-supply is only enabled when HDMI is enabled rather
than all the time.
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
For HDMI compliance both of these values need to be set to 1.
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
Setting the bits in this register is dependent on the output type driven
by the display controller. All output drivers already set these properly
so there is no need to do it here again.
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
The tegra_dc_format() and tegra_dc_setup_window() functions are only
used internally by the display controller driver. Move them upwards in
order to make them static and get rid of the function prototypes.
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
V_DIRECTION is the name of the field in the documentation, so use that
for consistency. Also add the H_DIRECTION field for completeness.
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
The SOR allows the computation of a 32 bit CRC of the content that it
transmits. This functionality is exposed via debugfs and is useful to
verify proper operation of the SOR.
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
YUYV is UYVY with swapped bytes. Luckily the Tegra DC hardware can swap
bytes during scan-out, so supporting YUYV is simply a matter of writing
the correct value to the byteswap register.
This patch modifies tegra_dc_format() to return the byte swap parameter
via an output parameter in addition to returning the pixel format. Many
other formats can potentially be supported in a similar way.
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
Remove extern keyword from function prototypes since it isn't needed and
drop an unnecessary forward declaration.
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
I've fumbled my own idea and enthusiastically wrapped all the
getconnector code with the connection_mutex. But we only need it to
chase the connector->encoder link. Even there it's not really needed
since races with userspace won't matter, but better paranoid and
consistent about this stuff.
If we grap it everywhere connector probe callbacks can't grab it
themselves, which means they'll deadlock. i915 does that for the load
detect pipe. Furthermore i915 needs to do a ww dance since we also
need to grab the mutex of the load detect crtc.
This is a regression from
commit 6e9f798d91c526982cca0026cd451e8fdbf18aaf
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Thu May 29 23:54:47 2014 +0200
drm: Split connection_mutex out of mode_config.mutex (v3)
Cc: Rob Clark <robdclark@gmail.com>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
Now that we're hoping to have resolved all of the problems with
video.use_native_backlight=1, make that the default at last.
Link: http://marc.info/?l=linux-acpi&m=139716088401106&w=2
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Laura's series removed the meminfo structure and its no longer available.
Update keystone code to remove the usage of it.
Reported-by: Russell King - ARM Linux <linux@arm.linux.org.uk>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip into next
Pull ARM64 EFI update from Peter Anvin:
"By agreement with the ARM64 EFI maintainers, we have agreed to make
-tip the upstream for all EFI patches. That is why this patchset
comes from me :)
This patchset enables EFI stub support for ARM64, like we already have
on x86"
* 'arm64-efi-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
arm64: efi: only attempt efi map setup if booting via EFI
efi/arm64: ignore dtb= when UEFI SecureBoot is enabled
doc: arm64: add description of EFI stub support
arm64: efi: add EFI stub
doc: arm: add UEFI support documentation
arm64: add EFI runtime services
efi: Add shared FDT related functions for ARM/ARM64
arm64: Add function to create identity mappings
efi: add helper function to get UEFI params from FDT
doc: efi-stub.txt updates for ARM
lib: add fdt_empty_tree.c
|
|
* Fix earlyprintk=efi,keep support by switching to an ioremap() mapping
of the framebuffer when early_ioremap() is no longer available and
dropping __init from functions that may be invoked after
free_initmem() - Dave Young
* We shouldn't be exporting the EFI runtime map in sysfs if not using
the new 1:1 EFI mapping code since in that case the mappings are not
static across a kexec reboot - Dave Young
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-next
Jeff Kirsher says:
====================
Intel Wired LAN Driver Updates 2014-06-05
This series contains updates to i40e and i40evf.
Jesse fixes an issue reported by Dave Jones where a couple of FD checks
ended up using bitwise OR where it should have been bitwise AND.
Neerav removes unused defines and macros for receive LRO. Fix the driver
from allowing the user to set a larger MTU size that the hardware was
being configured to support. Refactors send version which moves code in
two places into a small helper function.
Kamil modifies register diagnostics since register ranges can vary among
the different NVMs to avoid false test results. So now we try to identify
the full range and use it for a register test and if we fail to define the
proper register range, we will only test the first register from that
group. Then removes the check for large buffer since this was added in the
case this structure changed in the future, since the AQ definition is now
mature enough that this check is no longer necessary.
Mitch fixes i40evf driver to allocate descriptors in groups of 32 since the
hardware requires it. Also fixes a crash when the ring size changed because
it would change the count before deallocating resources, causing the driver
to either free nonexistent buffers or leak leftover buffers. Fixed the
driver to notify the VF for all types of resets so the VF can attempt a
graceful reinit.
Shannon refactors stats collection to create a unifying stats update routine
to call the various stat collection routines. Removes rx_errors and
rx_missed stats since they were removed from the chip design. Added
missing VSI statistics that the hardware offers but are not apart of the
standard netdev stats.
v2: dropped patch "i40e: Allow disabling of DCB via debugfs" from Neerav
based on feedback from David Miller.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull perf fixes from Ingo Molnar:
"Two last minute tooling fixes"
* 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
perf probe: Fix perf probe to find correct variable DIE
perf probe: Fix a segfault if asked for variable it doesn't find
|
|
Some drivers have different limits on what size a request should
optimally be, depending on the offset of the request. Similar to
dividing a device into chunks. Add a setting that allows the driver
to inform the block layer of such a chunk size. The block layer will
then prevent merging across the chunks.
This is needed to optimally support NVMe with a non-zero stripe size.
Signed-off-by: Jens Axboe <axboe@fb.com>
|
|
Merge futex fixes from Thomas Gleixner:
"So with more awake and less futex wreckaged brain, I went through my
list of points again and came up with the following 4 patches.
1) Prevent pi requeueing on the same futex
I kept Kees check for uaddr1 == uaddr2 as a early check for private
futexes and added a key comparison to both futex_requeue and
futex_wait_requeue_pi.
Sebastian, sorry for the confusion yesterday night. I really
misunderstood your question.
You are right the check is pointless for shared futexes where the
same physical address is mapped to two different virtual addresses.
2) Sanity check atomic acquisiton in futex_lock_pi_atomic
That's basically what Darren suggested.
I just simplified it to use futex_top_waiter() to find kernel
internal state. If state is found return -EINVAL and do not bother
to fix up the user space variable. It's corrupted already.
3) Ensure state consistency in futex_unlock_pi
The code is silly versus the owner died bit. There is no point to
preserve it on unlock when the user space thread owns the futex.
What's worse is that it does not update the user space value when
the owner died bit is set. So the kernel itself creates observable
inconsistency.
Another "optimization" is to retry an atomic unlock. That's
pointless as in a sane environment user space would not call into
that code if it could have unlocked it atomically. So we always
check whether there is kernel state around and only if there is
none, we do the unlock by setting the user space value to 0.
4) Sanitize lookup_pi_state
lookup_pi_state is ambigous about TID == 0 in the user space value.
This can be a valid state even if there is kernel state on this
uaddr, but we miss a few corner case checks.
I tried to come up with a smaller solution hacking the checks into
the current cruft, but it turned out to be ugly as hell and I got
more confused than I was before. So I rewrote the sanity checks
along the state documentation with awful lots of commentry"
* emailed patches from Thomas Gleixner <tglx@linutronix.de>:
futex: Make lookup_pi_state more robust
futex: Always cleanup owner tid in unlock_pi
futex: Validate atomic acquisition in futex_lock_pi_atomic()
futex-prevent-requeue-pi-on-same-futex.patch futex: Forbid uaddr == uaddr2 in futex_requeue(..., requeue_pi=1)
|
|
The current implementation of lookup_pi_state has ambigous handling of
the TID value 0 in the user space futex. We can get into the kernel
even if the TID value is 0, because either there is a stale waiters bit
or the owner died bit is set or we are called from the requeue_pi path
or from user space just for fun.
The current code avoids an explicit sanity check for pid = 0 in case
that kernel internal state (waiters) are found for the user space
address. This can lead to state leakage and worse under some
circumstances.
Handle the cases explicit:
Waiter | pi_state | pi->owner | uTID | uODIED | ?
[1] NULL | --- | --- | 0 | 0/1 | Valid
[2] NULL | --- | --- | >0 | 0/1 | Valid
[3] Found | NULL | -- | Any | 0/1 | Invalid
[4] Found | Found | NULL | 0 | 1 | Valid
[5] Found | Found | NULL | >0 | 1 | Invalid
[6] Found | Found | task | 0 | 1 | Valid
[7] Found | Found | NULL | Any | 0 | Invalid
[8] Found | Found | task | ==taskTID | 0/1 | Valid
[9] Found | Found | task | 0 | 0 | Invalid
[10] Found | Found | task | !=taskTID | 0/1 | Invalid
[1] Indicates that the kernel can acquire the futex atomically. We
came came here due to a stale FUTEX_WAITERS/FUTEX_OWNER_DIED bit.
[2] Valid, if TID does not belong to a kernel thread. If no matching
thread is found then it indicates that the owner TID has died.
[3] Invalid. The waiter is queued on a non PI futex
[4] Valid state after exit_robust_list(), which sets the user space
value to FUTEX_WAITERS | FUTEX_OWNER_DIED.
[5] The user space value got manipulated between exit_robust_list()
and exit_pi_state_list()
[6] Valid state after exit_pi_state_list() which sets the new owner in
the pi_state but cannot access the user space value.
[7] pi_state->owner can only be NULL when the OWNER_DIED bit is set.
[8] Owner and user space value match
[9] There is no transient state which sets the user space TID to 0
except exit_robust_list(), but this is indicated by the
FUTEX_OWNER_DIED bit. See [4]
[10] There is no transient state which leaves owner and user space
TID out of sync.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Kees Cook <keescook@chromium.org>
Cc: Will Drewry <wad@chromium.org>
Cc: Darren Hart <dvhart@linux.intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
