| Age | Commit message (Collapse) | Author |
|---|
|
a277ca7dc01d should've been a no-functional-change commit, but it
removed the initialization of the dpll_hw_state for HDMI outputs,
resulting in state mismatches and a failed modeset with blank
screen. Fix this by reinstating the dpll_hw_state initialization.
v2:
- Make bxt_ddi_hdmi_set_dpll_hw_state() static.
Cc: Manasi Navare <manasi.d.navare@intel.com>
Cc: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Cc: Durgadoss R <durgadoss.r@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Fixes: a277ca7dc01d ("drm/i915: Split bxt_ddi_pll_select()")
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1474901671-22719-1-git-send-email-imre.deak@intel.com
(cherry picked from commit a04139c4cf289119cdfb6081af602f7a452fb7c2)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
We forgot the "res_blocks += y_tile_minimum" that's described on step
V of our documentation.
Again, this should only affect the Y tiling cases.
It looks like the relevant code was introduced in 0fda65680e92, but
there's always the possibility that it matched our specification when
it was introduced, and then the specification changed while the code
stayed the same. So we can't really say this was a regression, but
let's try to add a "Fixes" tag anyway to help backporting.
v2: Try to add a "Fixes" tag (Maarten).
Fixes: 0fda65680e92 ("drm/i915/skl: Update watermarks for Y tiling")
Cc: stable@vger.kernel.org
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Lyude <cpaul@redhat.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1474578035-424-8-git-send-email-paulo.r.zanoni@intel.com
(cherry picked from commit 75676ed423a6acf9e2b1df52fbc036a51e11fb7a)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
The confusing thing is that plane_blocks_per_line is listed as part of
the method 2 calculation but is also used for other things. We
calculated it in two different places and different ways: one inside
skl_wm_method2() and the other inside skl_compute_plane_wm(). The
skl_wm_method2() implementation is the one that matches the
specification.
With this patch we fix the skl_compute_plane_wm() calculation and just
pass it as a parameter to skl_wm_method2(). We also take care to not
modify the value of plane_bytes_per_line since we're going to rely on
it having a correct value in later patches.
This should affect the watermarks for Linear and Y-tiled.
From my analysis, it looks like the two plane_blocks_per_line
variables got out of sync on 0fda65680e92, but we can't really say
that commit was a regression, it looks like just an incomplete fix.
There's always the possibility that 0fda65680e92 matched our
specification at that time, and then later the specification changed.
v2: Try to add a "Fixes" tag (Maarten).
Fixes: 0fda65680e92 ("drm/i915/skl: Update watermarks for Y tiling")
Cc: stable@vger.kernel.org
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Lyude <cpaul@redhat.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1474578035-424-7-git-send-email-paulo.r.zanoni@intel.com
(cherry picked from commit 7a1a8aed67e0a60772defe3f6499eb340da48634)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
During watermarks calculations, this value is used in 3 different
places. Only one of them was not using a hardcoded 4. Move the code up
so everybody can benefit from the actual value.
This should only help on situations with Y tiling + 90/270 rotation +
1 or 2 bpp or NV12.
Cc: stable@vger.kernel.org
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1474578035-424-6-git-send-email-paulo.r.zanoni@intel.com
(cherry picked from commit 1186fa85eb9b3cc0589990fbc39617e50e38759a)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
Bspec says:
"The mailbox response data may not account for memory read latency.
If the mailbox response data for level 0 is 0us, add 2 microseconds
to the result for each valid level."
This means we should only do the +2 in case wm[0] == 0, not always.
So split the sanitizing implementation from the WA implementation and
fix the WA implementation.
v2: Add Fixes tag (Maarten).
Fixes: 367294be7c25 ("drm/i915/gen9: Add 2us read latency to WM level")
Cc: stable@vger.kernel.org
Cc: Vandana Kannan <vandana.kannan@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1474578035-424-5-git-send-email-paulo.r.zanoni@intel.com
(cherry picked from commit 0727e40a48a1d08cf54ce2c01e120864b92e59bf)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
According to BSpec, it's the "core CPUs" that need the code, which
means SKL and KBL, but not BXT.
I don't have a KBL to test this patch on it.
v2: Only SKL should have I915_SAGV_NOT_CONTROLLED.
Cc: stable@vger.kernel.org
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1474578035-424-4-git-send-email-paulo.r.zanoni@intel.com
(cherry picked from commit 6e3100ec21e7c774a0fc01e36a1e0739530c2f71)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
And use it to move knowledge about the SAGV-supporting platforms from
the callers to the SAGV code.
We'll add more platforms to intel_has_sagv(), so IMHO it makes more
sense to move all this to a single function instead of patching all
the callers every time we add SAGV support to a new platform.
v2: Move I915_SAGV_NOT_CONTROLLED to the new function (Lyude).
Cc: stable@vger.kernel.org
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1474578035-424-3-git-send-email-paulo.r.zanoni@intel.com
(cherry picked from commit 56feca91973459d0b62cbb2610b62d341025ed89)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
The plan is to introduce intel_has_sagv() and then use it to discover
which platforms actually support it.
I thought about keeping the functions with their current skl names,
but found two problems: (i) skl_has_sagv() would become a very
confusing name, and (ii) intel_atomic_commit_tail() doesn't seem to be
calling any functions whose name start with a platform name, so the
"intel_" naming scheme seems make more sense than the "firstplatorm_"
naming scheme here.
Cc: stable@vger.kernel.org
Reviewed-by: Lyude <cpaul@redhat.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1474578035-424-2-git-send-email-paulo.r.zanoni@intel.com
(cherry picked from commit 16dcdc4edbcf5cb130004737f2548401776170f1)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
We never remembered to set it (so it was zero), but this was not a
problem in the past due to the way handled the hardware registers.
Unfortunately we changed how we set the hardware and forgot to set
intel_crtc->dspaddr_offset.
This started to reflect on a few kms_frontbuffer_tracking subtests
that relied on page flips with CRTCs that don't point to the x:0,y:0
coordinates of the frontbuffer. After the page flip the CRTC was
showing the x:0,y:0 coordinate of the frontbuffer instead of
x:500,y:500. This problem is present even if we don't enable FBC or
PSR.
While trying to bisect it I realized that the first bad commit
actually just gives me a black screen for the mentioned tests instead
of showing the wrong x:0,y:0 offsets. A few commits later the black
screen problem goes away and we get to the point where the code is
today, but I'll consider the black screen as the first bad commit
since it's the point where the IGT subtests start to fail.
Fixes: 6687c9062c46 ("drm/i915: Rewrite fb rotation GTT handling")
Testcase: kms_frontbuffer_tracking/fbc-1p-primscrn-shrfb-pgflip-blt
Testcase: kms_frontbuffer_tracking/fbc-1p-primscrn-shrfb-evflip-blt
Testcase: kms_frontbuffer_tracking/fbc-1p-shrfb-fliptrack
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Sivakumar Thulasimani <sivakumar.thulasimani@intel.com>
Cc: drm-intel-fixes@lists.freedesktop.org
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1471644203-23463-1-git-send-email-paulo.r.zanoni@intel.com
(cherry picked from commit 4c0b8a8bc49c477be9467f614b6b4ec479736019)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
At the point of creating the hibernation image, the runtime power manage
core is disabled - and using the rpm functions triggers a warn.
i915_gem_shrink_all() tries to unbind objects, which requires device
access and so tries to how an rpm reference triggering a warning:
[ 44.235420] ------------[ cut here ]------------
[ 44.235424] WARNING: CPU: 2 PID: 2199 at drivers/gpu/drm/i915/intel_runtime_pm.c:2688 intel_runtime_pm_get_if_in_use+0xe6/0xf0
[ 44.235426] WARN_ON_ONCE(ret < 0)
[ 44.235445] Modules linked in: ctr ccm arc4 rt2800usb rt2x00usb rt2800lib rt2x00lib crc_ccitt mac80211 cmac cfg80211 btusb rfcomm bnep btrtl btbcm btintel bluetooth dcdbas x86_pkg_temp_thermal intel_powerclamp coretemp snd_hda_codec_realtek crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_hda_codec_generic aesni_intel snd_hda_codec_hdmi aes_x86_64 lrw gf128mul snd_hda_intel glue_helper ablk_helper cryptd snd_hda_codec hid_multitouch joydev snd_hda_core binfmt_misc i2c_hid serio_raw snd_pcm acpi_pad snd_timer snd i2c_designware_platform 8250_dw nls_iso8859_1 i2c_designware_core lpc_ich mfd_core soundcore usbhid hid psmouse ahci libahci
[ 44.235447] CPU: 2 PID: 2199 Comm: kworker/u8:8 Not tainted 4.8.0-rc5+ #130
[ 44.235447] Hardware name: Dell Inc. XPS 13 9343/0310JH, BIOS A07 11/11/2015
[ 44.235450] Workqueue: events_unbound async_run_entry_fn
[ 44.235453] 0000000000000000 ffff8801b2f7fb98 ffffffff81306c2f ffff8801b2f7fbe8
[ 44.235454] 0000000000000000 ffff8801b2f7fbd8 ffffffff81056c01 00000a801f50ecc0
[ 44.235456] ffff88020ce50000 ffff88020ce59b60 ffffffff81a60b5c ffffffff81414840
[ 44.235456] Call Trace:
[ 44.235459] [<ffffffff81306c2f>] dump_stack+0x4d/0x6e
[ 44.235461] [<ffffffff81056c01>] __warn+0xd1/0xf0
[ 44.235464] [<ffffffff81414840>] ? i915_pm_suspend_late+0x30/0x30
[ 44.235465] [<ffffffff81056c6f>] warn_slowpath_fmt+0x4f/0x60
[ 44.235468] [<ffffffff814e73ce>] ? pm_runtime_get_if_in_use+0x6e/0xa0
[ 44.235469] [<ffffffff81433526>] intel_runtime_pm_get_if_in_use+0xe6/0xf0
[ 44.235471] [<ffffffff81458a26>] i915_gem_shrink+0x306/0x360
[ 44.235473] [<ffffffff81343fd4>] ? pci_platform_power_transition+0x24/0x90
[ 44.235475] [<ffffffff81414840>] ? i915_pm_suspend_late+0x30/0x30
[ 44.235476] [<ffffffff81458dfb>] i915_gem_shrink_all+0x1b/0x30
[ 44.235478] [<ffffffff814560b3>] i915_gem_freeze_late+0x33/0x90
[ 44.235479] [<ffffffff81414877>] i915_pm_freeze_late+0x37/0x40
[ 44.235481] [<ffffffff814e9b8e>] dpm_run_callback+0x4e/0x130
[ 44.235483] [<ffffffff814ea5db>] __device_suspend_late+0xdb/0x1f0
[ 44.235484] [<ffffffff814ea70f>] async_suspend_late+0x1f/0xa0
[ 44.235486] [<ffffffff81077557>] async_run_entry_fn+0x37/0x150
[ 44.235488] [<ffffffff8106f518>] process_one_work+0x148/0x3f0
[ 44.235490] [<ffffffff8106f8eb>] worker_thread+0x12b/0x490
[ 44.235491] [<ffffffff8106f7c0>] ? process_one_work+0x3f0/0x3f0
[ 44.235492] [<ffffffff81074d09>] kthread+0xc9/0xe0
[ 44.235495] [<ffffffff816e257f>] ret_from_fork+0x1f/0x40
[ 44.235496] [<ffffffff81074c40>] ? kthread_park+0x60/0x60
[ 44.235497] ---[ end trace e438706b97c7f132 ]---
Alternatively, to actually shrink everything we have to do so slightly
earlier in the hibernation process.
To keep lockdep silent, we need to take struct_mutex for the shrinker
even though we know that we are the only user during the freeze.
Fixes: 7aab2d534e35 ("drm/i915: Shrink objects prior to hibernation")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20160921135108.29574-2-chris@chris-wilson.co.uk
(cherry picked from commit 6a800eabba34945c2986d70114b41d564bad52a8)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
Following commit 821ed7df6e2a ("drm/i915: Update reset path to fix
incomplete requests") we no longer mark the context as lost on reset as
we keep the requests (and contexts) alive. However, RPS remains reset
and we need to restore the current state to match the in-flight
requests.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97824
Fixes: 821ed7df6e2a ("drm/i915: Update reset path to fix incomplete requests")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Arun Siluvery <arun.siluvery@linux.intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20160921135108.29574-1-chris@chris-wilson.co.uk
(cherry picked from commit f2a91d1a6f5960c08f1ca60bd076f4dc020c50c6)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
Reapply the PPS register unlock workaround after GPU reset on platforms
where the reset clobbers the display HW state. This at least gets rid of
the related WARN during LVDS encoder enabling on PNV.
Fixes: ed6143b8f75 ("drm/i915/lvds: Restore initial HW state during encoder enabling")
Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1473847453-4771-1-git-send-email-imre.deak@intel.com
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
(cherry picked from commit 51f592050a523fc5882f9b8b4e9259422e41e848)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
Backlight enable is supposed to do a full setup of the backlight. We
were missing the PWM alternate increment bit in the south chicken
registers on lpt+ pch. This potentially caused a PWM frequency change
when the chicken register value was lost e.g. on suspend.
v2 by Jani, rebase on the patch caching alt increment
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97486
References: https://bugs.freedesktop.org/show_bug.cgi?id=67454
Cc: Cooper Chiou <cooper.chiou@intel.com>
Cc: Wei Shun Chen <wei.shun.chang@intel.com>
Cc: Gary C Wang <gary.c.wang@intel.com>
Cc: stable@vger.kernel.org # v4.4+ 16e1203db8ab drm/i915/backlight: setup and cache...
Cc: stable@vger.kernel.org # v4.4+
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Shawn Lee <shawn.c.lee@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/8265f5935bd31c039ddfc82819d26c2ca1ae9cba.1474281249.git.jani.nikula@intel.com
(cherry picked from commit e29aff05f239f8dd24e9ee7816fd96726e20105a)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
This will also be needed later on when setting up the alternate
increment in backlight enable.
Cc: Shawn Lee <shawn.c.lee@intel.com>
Cc: <stable@vger.kernel.org>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/9984b20bc59aee90b83caf59ce91f3fb122c9627.1474281249.git.jani.nikula@intel.com
(cherry picked from commit 32b421e79e6b546da1d469f1229403ac9142d695)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
Some Intel controllers (e.g. BXT) might fail to set bus power after a
D3 -> D0 transition due to the present state not yet having propagated.
Retry for up to 2 milliseconds.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
|
|
Let devices define their own sdhci_ops so that device-specific variations
can be implemented without adding quirks.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
|
|
Unlike other cases, sdhci_set_power() does not reflect the default
implementation of the ->set_power() callback. Rename it and create
sdhci_set_power() that is the default implementation.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Cc: Jisheng Zhang <jszhang@marvell.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
|
|
Multi-block data transfers can specify the number of blocks either using a
Set Block Count command (CMD23) or by sending a STOP command (CMD12) after
the required number of blocks has transferred. CMD23 is preferred, but some
cards don't support it. CMD12 with R1b response is used for writes, and
R1 response for reads.
Some SDHCI host controllers give a Transfer Complete (TC) interrupt for the
STOP command (CMD12) whether or not a R1b response has been specified. The
quirk SDHCI_QUIRK2_STOP_WITH_TC identifies those host controllers, but the
implementation only considers the case where the TC interrupt arrives at
the same time as the Command Complete (CC) interrupt. However,
occasionally TC arrives before CC. That is harmless, but does generate an
error message "Got data interrupt 0x00000002 even though no data operation
was in progress".
A simpler approach is to force R1b response onto all STOP commands, because
SDHCI will handle TC before CC in the general case, so do that.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
|
|
Commit f68381a70bb2 (mmc: block: fix packed command header endianness)
correctly fixed endianness handling of packed_cmd_hdr in
mmc_blk_packed_hdr_wrq_prep.
But now, sparse complains about incorrect types:
drivers/mmc/card/block.c:1613:27: sparse: incorrect type in assignment (different base types)
drivers/mmc/card/block.c:1613:27: expected unsigned int [unsigned] [usertype] <noident>
drivers/mmc/card/block.c:1613:27: got restricted __le32 [usertype] <noident>
...
So annotate cmd_hdr properly using __le32 to make everyone happy.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Fixes: f68381a70bb2 (mmc: block: fix packed command header endianness)
Cc: stable@vger.kernel.org
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
|
|
Per the vendor's requirement, we shouldn't do any setting for
1.8V Signaling Enable, otherwise the interaction/behaviour between
phy and controller will be undefined. Mostly it works fine if we do
that, but we still see failures. Anyway, let's fix it to meet the
vendor's requirement. The error log looks like:
[ 93.405085] mmc1: unexpected status 0x800900 after switch
[ 93.408474] mmc1: switch to bus width 1 failed
[ 93.408482] mmc1: mmc_select_hs200 failed, error -110
[ 93.408492] mmc1: error -110 during resume (card was removed?)
[ 93.408705] PM: resume of devices complete after 213.453 msecs
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
|
|
Per JESD84-B51 P49, Host need to change frequency to <=52MHz
after setting HS_TIMING to 0x1, and host may changes frequency
to <= 200MHz after setting HS_TIMING to 0x3. That means the card
expects the clock rate to increase from the current used f_init
(which is less than 400KHz, but still being less than 52MHz) to
52MHz, otherwise we find some eMMC devices significantly report
failure when sending status.
Reported-by: Xiao Yao <xiaoyao@rock-chips.com>
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
|
|
When introducing hs400es, I didn't notice that we haven't
switched voltage to 1V2 or 1V8 for it. That happens to work
as the first controller claiming to support hs400es, arasan(5.1),
which is designed to only support 1V8. So the voltage is fixed to 1V8.
But it actually is wrong, and will not fit for other host controllers.
Let's fix it.
Fixes: commit 81ac2af65793ecf ("mmc: core: implement enhanced strobe support")
Cc: <stable@vger.kernel.org>
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
|
|
We get 1 warning when building kernel with W=1:
drivers/mmc/card/block.c:2147:5: warning: no previous prototype for
'mmc_blk_issue_rq' [-Wmissing-prototypes]
In fact, this function is declared in drivers/mmc/card/block.h, so this
patch adds missing header dependencies.
Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
|
|
Fixes the following sparse warning:
drivers/mmc/host/sdhci-of-arasan.c:253:6: warning:
symbol 'sdhci_arasan_reset' was not declared. Should it be static?
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Acked-by: Sören Brinkmann <soren.brinkmann@xilinx.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
|
|
The commit c039aaa77a7d1d9375665a8b59ec16dc7d23e259 was incomplete,
missing part of the setup for Live. This makes also audio input work,
in addition to audio output.
Fixes: c039aaa77a7d1d9375665a8b59ec16dc7d23e259
Reported-by: Eddi De Pieri <eddi@depieri.net>
Signed-off-by: Andrej Krutak <dev@andree.sk>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
There is no late_unregister(), it looks like the comment meant
late_register(). Also fix a typo while at it.
Signed-off-by: Grazvydas Ignotas <notasas@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1476032820-3275-1-git-send-email-notasas@gmail.com
|
|
We should use 'ida_simple_remove()' instead of 'ida_remove()' when freeing
resources allocated with 'ida_simple_get()'.
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1475825261-7735-1-git-send-email-christophe.jaillet@wanadoo.fr
|
|
I hit send before completing a make htmldoc, and lo I forgot to fix up
the cut'n'paste.
Fixes: a4fce9cb782a ("drm/prime: Take a ref on the drm_dev when exporting...")
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20161005174056.29869-1-chris@chris-wilson.co.uk
|
|
directly
Drop unneeded drm_connector_unregister() and remove the unnecessary
wrapper functions around drm_connector_cleanup().
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20161005143133.5549-1-marex@denx.de
|
|
Fix invalid sphinx markup in the comment for the newly added
DRM_FB_HELPER_DEFAULT_OPS.
Signed-off-by: Stefan Christ <contact@stefanchrist.eu>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1475692454-11543-1-git-send-email-contact@stefanchrist.eu
|
|
The Akai MIDImix (09e8:0031) is a MIDI fader controller that speaks
regular MIDI and works well with Linux. However, initialization gets
delayed due to reports timeout:
[3643645.631124] hid-generic 0003:09E8:0031.0020: timeout initializing reports
[3643645.632416] hid-generic 0003:09E8:0031.0020: hiddev0: USB HID v1.11 Device [AKAI MIDI Mix] on usb-0000:00:14.0-2/input0
Adding "usbhid.quirks=0x09e8:0x0031:0x20000000" on the kernel
command line makes the issues go away.
Signed-off-by: Steinar H. Gunderson <sgunderson@bigfoot.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
|
This reverts commit 18339f59c3a6 ("HID: dragonrise: fix HID...") because it
breaks certain dragonrise 0079:0006 gamepads. While it may fix a breakage
caused by commit 79346d620e9d ("HID: input: force generic axis to be mapped
to their user space axis"), it is probable that the manufacturer released
different hardware with the same PID so this fix works for only a subset
and breaks the other gamepads sharing the PID.
What is needed is another more generic solution which fixes 79346d620e9d
("HID: input: force generic axis ...") breakage for this controller: we
need to add an exception for this driver to make it keep the old behaviour
previous to the initial breakage (this is done in patch 2 of this series).
Signed-off-by: Ioan-Adrian Ratiu <adi@adirat.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
|
Commit 79346d620e9d ("HID: input: force generic axis to be mapped to their
user space axis") made mapping generic axes to their userspace equivalents
mandatory and some lower end gamepads which were depending on the previous
behaviour suffered severe regressions because they were reusing axes and
expecting hid-input to multiplex their map to the respective userspace axis
by always searching for and using the next available axis.
One solution is to add a hid quirk for this type of "previous" behaviour in
hid-input to bypass the new axes policy in favour of the old one, but since
only one hardware vendor seems to be affected negatively we're better off
making and exception and mapping in the driver for now; if more vendors or
drivers turn out to experience the problem we should reconsider the quirk
solution.
Signed-off-by: Ioan-Adrian Ratiu <adi@adirat.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
|
The hid-led driver works fine under 4.8.0, however with the next
kernel from today I get this:
------------[ cut here ]------------
WARNING: CPU: 0 PID: 2578 at drivers/usb/core/hcd.c:1584 usb_hcd_map_urb_for_dma+0x373/0x550 [usbcore]
transfer buffer not dma capable
Modules linked in: hid_led(+) usbhid vfat fat ir_sony_decoder iwlmvm led_class mac80211 snd_hda_codec_realtek snd_hda_codec_generic x86_pkg_temp_thermal iwlwifi crc32c_intel snd_hda_codec_hdmi i2c_i801 i2c_smbus snd_hda_intel cfg80211 snd_hda_codec snd_hda_core snd_pcm r8169 snd_timer mei_me mii snd mei ir_lirc_codec lirc_dev nuvoton_cir rc_core btusb btintel bluetooth rfkill usb_storage efivarfs ipv6 ehci_pci ehci_hcd xhci_pci xhci_hcd usbcore usb_common ext4 jbd2 mbcache ahci libahci libata
CPU: 0 PID: 2578 Comm: systemd-udevd Not tainted 4.8.0-rc8-next-20161003 #1
Hardware name: ZOTAC ZBOX-CI321NANO/ZBOX-CI321NANO, BIOS B246P105 06/01/2015
ffffc90003dbb7e0 ffffffff81280425 ffffc90003dbb830 0000000000000000
ffffc90003dbb820 ffffffff8105b086 0000063003dbb800 ffff88006f374480
0000000000000000 0000000000000000 0000000000000001 ffff880079544000
Call Trace:
[<ffffffff81280425>] dump_stack+0x68/0x93
[<ffffffff8105b086>] __warn+0xc6/0xe0
[<ffffffff8105b0ea>] warn_slowpath_fmt+0x4a/0x50
[<ffffffffa0143a43>] usb_hcd_map_urb_for_dma+0x373/0x550 [usbcore]
[<ffffffffa01441b6>] usb_hcd_submit_urb+0x316/0x9c0 [usbcore]
[<ffffffff810bce80>] ? rcu_read_lock_sched_held+0x40/0x80
[<ffffffff810e0043>] ? module_assert_mutex_or_preempt+0x13/0x50
[<ffffffff810e0c07>] ? __module_address+0x27/0xf0
[<ffffffffa01456e4>] usb_submit_urb+0x2c4/0x520 [usbcore]
[<ffffffffa0145fea>] usb_start_wait_urb+0x5a/0xe0 [usbcore]
[<ffffffffa014612c>] usb_control_msg+0xbc/0xf0 [usbcore]
[<ffffffff810e0c07>] ? __module_address+0x27/0xf0
[<ffffffffa079a724>] usbhid_raw_request+0xa4/0x180 [usbhid]
[<ffffffffa07a93b1>] hidled_recv+0x71/0xe0 [hid_led]
[<ffffffffa07a947d>] thingm_init+0x2d/0x50 [hid_led]
[<ffffffffa07a969b>] hidled_probe+0xcb/0x24a [hid_led]
[<ffffffff814d96f2>] hid_device_probe+0xd2/0x150
[<ffffffff8146023d>] driver_probe_device+0x1fd/0x2c0
[<ffffffff8146039a>] __driver_attach+0x9a/0xa0
[<ffffffff81460300>] ? driver_probe_device+0x2c0/0x2c0
[<ffffffff8145e25d>] bus_for_each_dev+0x5d/0x90
[<ffffffff8145fa79>] driver_attach+0x19/0x20
[<ffffffff8145f5ff>] bus_add_driver+0x11f/0x220
[<ffffffffa07ac000>] ? 0xffffffffa07ac000
[<ffffffff8146086b>] driver_register+0x5b/0xd0
[<ffffffffa07ac000>] ? 0xffffffffa07ac000
[<ffffffff814d83d1>] __hid_register_driver+0x61/0xa0
[<ffffffffa07ac01e>] hidled_driver_init+0x1e/0x20 [hid_led]
[<ffffffff81000408>] do_one_initcall+0x38/0x150
[<ffffffff810bce80>] ? rcu_read_lock_sched_held+0x40/0x80
[<ffffffff81194ca0>] ? kmem_cache_alloc_trace+0x1d0/0x230
[<ffffffff811342f9>] do_init_module+0x5a/0x1cb
[<ffffffff810e3862>] load_module+0x1e42/0x2530
[<ffffffff810e0990>] ? __symbol_put+0x50/0x50
[<ffffffff810dfc50>] ? show_coresize+0x30/0x30
[<ffffffff811ad650>] ? kernel_read_file+0x100/0x190
[<ffffffff811ad794>] ? kernel_read_file_from_fd+0x44/0x70
[<ffffffff810e415a>] SYSC_finit_module+0xba/0xc0
[<ffffffff810e4179>] SyS_finit_module+0x9/0x10
[<ffffffff815e082a>] entry_SYSCALL_64_fastpath+0x18/0xad
---[ end trace c9e6ea27003ecf9e ]---
Fix this by using a kmalloc'ed buffer when calling hid_hw_raw_request.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
|
into drm-next
Just some misc bug fixes for 4.9.
* 'drm-next-4.9' of git://people.freedesktop.org/~agd5f/linux:
drm/amdgpu: revert "use more than 64KB fragment size if possible"
drm/amdgpu: warn if dp aux is still attached on free
drm/amdgpu/dce11: add missing drm_mode_config_cleanup call
drm/amdgpu: also track late init state
drm/amdgpu/virtual_dce: adjust config ifdef
drm/amdgpu/vce: add support for hw config packet (v2)
drm/amdgpu: clean up to set fw_offset as 0 twice
drm/amdgpu: remove DRM_AMD_POWERPLAY
drm/radeon: Prevent races on pre DCE4 between flip submission and completion.
drm/radeon: Slightly more robust flip completion handling for < DCE-4
|
|
git://anongit.freedesktop.org/drm-intel into drm-next
Another attempt, this time rebased and without the pipe crc patches:
- display_info cleanups from Ville
- make prime/gem lookups faster with rbtrees (Chris)
- misc stuff all over
* tag 'topic/drm-misc-2016-10-05' of git://anongit.freedesktop.org/drm-intel:
drm/rockchip: analogix_dp: Refuse to enable PSR if panel doesn't support it
drm/bridge: analogix_dp: Add analogix_dp_psr_supported
drm/fb-helper: add DRM_FB_HELPER_DEFAULT_OPS for fb_ops
drm: Document caveats around atomic event handling
uapi: add missing install of sync_file.h
drm: Simplify drm_printk to reduce object size quite a bit
drm/i915: Account for sink max TMDS clock when checking the port clock
drm/i915: Replace a bunch of connector->base.display_info with a local variable
drm/edid: Move dvi_dual/max_tmds_clock parsing out from drm_edid_to_eld()
drm/edid: Clear the old cea_rev when there's no CEA extension in the new EDID
drm/edid: Reduce the number of times we parse the CEA extension block
drm/edid: Don't pass around drm_display_info needlessly
drm/edid: Move dvi_dual/max_tmds_clock to drm_display_info
drm/edid: Make max_tmds_clock kHz instead of MHz
drm/edid: Clear old dvi_dual/max_tmds_clock before parsing the new EDID
drm/edid: Clear old audio latency values before parsing the new EDID
drm: Convert prime dma-buf <-> handle to rbtree
drm/mediatek: mark symbols static where possible
drm/rockchip: mark symbols static where possible
drm/rockchip: add missing header dependencies
|
|
drm-next
This pull request brings in several fixes for drm-next, mostly for
HDMI.
* tag 'drm-vc4-next-2016-10-06' of https://github.com/anholt/linux:
drm/vc4: Add support for double-clocked modes.
drm/vc4: Set up the AVI and SPD infoframes.
drm/vc4: Fix support for interlaced modes on HDMI.
drm/vc4: Increase timeout for HDMI_SCHEDULER_CONTROL changes.
drm/vc4: Fall back to using an EDID probe in the absence of a GPIO.
drm/vc4: Enable limited range RGB output on HDMI with CEA modes.
drm/vc4: Fix races when the CS reads from render targets.
drm/vc4: cleanup with list_first_entry_or_null()
|
|
The error handling in xfs_refcount_recover_cow_leftovers is confused
and can potentially leak memory, so rework it to release resources
correctly on error.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reported-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
|
|
Since we can only turn on the rt flag if there are no data extents,
we can safely turn off the reflink flag if the rt flag is being
turned on.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reported-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
|
|
Eric Sandeen reported a gcc complaint about uninitialized error
variables, so fix that.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reported-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
|
|
Since we don't unlock anything on the way out, change the label.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reported-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
|
|
Now that fallocate has an explicit unshare flag again, let's try
to remove the inode reflink flag whenever the user unshares any
part of a file since checking is cheap compared to the CoW.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reported-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
|
|
The loop in _reflink_clear_inode_flag isn't necessary since we
jump out if any part of any extent is shared. Remove the loop
and we no longer need two maps, so we can save some stack use.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reported-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
|
|
There are a couple of places where we don't check the inode's
reflink flag before calling into the reflink code. Fix those,
and add some asserts so we don't make this mistake again.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reported-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
|
|
Some boards have an entirely passive RGB to VGA bridge, based on DACs
implemented by resistor ladders.
Those might or might not have an i2c bus routed to the VGA connector in
order to access the screen EDIDs.
Add a bridge that doesn't do anything but expose the modes available on the
screen, either based on the EDIDs if available, or based on the XGA
standards.
Acked-by: Rob Herring <robh@kernel.org>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Tested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Link: http://patchwork.freedesktop.org/patch/msgid/20160930143709.1388-3-maxime.ripard@free-electrons.com
|
|
Merge the crypto tree to pull in vmx ghash fix.
|
|
Pull blk-mq CPU hotplug update from Jens Axboe:
"This is the conversion of blk-mq to the new hotplug state machine"
* 'for-4.9/block-smp' of git://git.kernel.dk/linux-block:
blk-mq: fixup "Convert to new hotplug state machine"
blk-mq: Convert to new hotplug state machine
blk-mq/cpu-notif: Convert to new hotplug state machine
|
|
Pull blk-mq irq/cpu mapping updates from Jens Axboe:
"This is the block-irq topic branch for 4.9-rc. It's mostly from
Christoph, and it allows drivers to specify their own mappings, and
more importantly, to share the blk-mq mappings with the IRQ affinity
mappings. It's a good step towards making this work better out of the
box"
* 'for-4.9/block-irq' of git://git.kernel.dk/linux-block:
blk_mq: linux/blk-mq.h does not include all the headers it depends on
blk-mq: kill unused blk_mq_create_mq_map()
blk-mq: get rid of the cpumask in struct blk_mq_tags
nvme: remove the post_scan callout
nvme: switch to use pci_alloc_irq_vectors
blk-mq: provide a default queue mapping for PCI device
blk-mq: allow the driver to pass in a queue mapping
blk-mq: remove ->map_queue
blk-mq: only allocate a single mq_map per tag_set
blk-mq: don't redistribute hardware queues on a CPU hotplug event
|
|
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
On some platforms with ACPI4 variable speed fan, reading cur_state from
cooling device returns "invalid value" error. This confuses user space
applications.
This issue occurs as the current driver doesn't take account of
"FineGrainControl" from _FIF(Fan Information). When the "FineGrainControl"
is set, _FSL(FSL Set Level) takes argument as a percent, which doesn't
have to match from any control value from _FPS(Fan Performance States).
It is also possible that the Fan is not actually running at the requested
speed returning a lower speed.
On some platforms the BIOS is setting fan speed to a level during boot,
which will not have an exact match to _FPS control values. The current
implementation will treat this level as invalid value.
The simple change is to atleast return state corresponding to a maximum
control value in the _FPS compared to the current level.
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
