Pass the device performing the probe so we can use a devm allocation for
the pfn superblock.
Cc: Ross Zwisler <ross.zwisler@linux.intel.com>
Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
We can derive the common namespace from other information. We also do
not need to cache it because all the usages are in slow paths.
Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
- scan_features() updates incorrect bits for REAL_LE from Anton Blanchard
- Update cpu_user_features2 in scan_features() from Anton Blanchard
- Update TM user feature bits in scan_features() from Anton Blanchard
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJXGfRfAAoJEFHr6jzI4aWAeCQP+wVdFa4Q+T0uFQf/lQBPfQLa
wDODtskmqwfWk2YqIv3LKTnrkubs8nGy2Vc5Tm27/G/x+uMPOrTD/eoBiG3DH8E3
eiX1tlqO+oM8dm+g/FxGSCbkWSoYKQrc1QQ1oWtADPPhSm1xU0GYdPqQrDyAfFEr
JEg5ifOkbTZ3VauuK2kXVxIgNHtwfPoeQfTEmKk7x1Pay0z3zNx65tKInGKmatL8
7dS+Y8gPNODUfky61M1Y0f/KDwOsBO7gyiIdkkJxnYW1IAqTTsvK90fKPVzSfM0Y
jnOBdlysIPsiXFNDjT0gBBBRm7McCZO/bZEjK7aSWUMP/FOWIR+HkB3+fpcB+o8u
tbmMJ8AfHvz4PXzf0h0TySOy6uhA65LJfBnssBoZcCQyxTzdIQC7crDH2639L+8q
djUYGzWXrplCq/r/uQrogY7a7Ff/UFW76mRMX1lj2hi8lpQEnr7sBPAqwEApgvtr
WRqBkUjyuTWnnDSnen0NR1QMfh9zMNNjHHBaU+UJv0gU3lBRL+VpmFizsdjVk8/E
0wC2l1lws3txxaWXGmpJNKve9P2+iEVfY5KAigkKO3yV5xUuwOhtED6sTKqTY5wR
kp3AC+7fjUxQFJ4g4BVohakie5RR6LkLZ7xCwB0LWPff3LUIiHGelsd+ii1kjxwm
/tiR9CYEO1O9KcKlwv8X
=woiB
-----END PGP SIGNATURE-----
Merge tag 'powerpc-4.6-3' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux
Pull powerpc fixes from Michael Ellerman:
"Three powerpc cpu feature fixes from Anton Blanchard:
- scan_features() updated incorrect bits for REAL_LE
- update cpu_user_features2 in scan_features()
- update TM user feature bits in scan_features()"
* tag 'powerpc-4.6-3' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux:
powerpc: Update TM user feature bits in scan_features()
powerpc: Update cpu_user_features2 in scan_features()
powerpc: scan_features() updates incorrect bits for REAL_LE
The fixes include:
* Two patches to revert the use of default domains in the ARM
SMMU driver. Enabling this caused regressions which need more
thorough fixing. So the regressions are fixed for now by
disabling the use of default domains.
* A fix for a v4.4 regression in the AMD IOMMU driver which
broke devices behind invisible PCIe-to-PCI bridges with IOMMU
enabled.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAABAgAGBQJXGfQRAAoJECvwRC2XARrjw8QP/1cnSlwlmrx6klaSaD0XlVe+
IoxU8USSunBojepKHIQiLmDrLvsan5LcqWqq7ExyiSV9hZuO81gcL7cVaZyh3cVt
0lYFxgJy7xOuprmP/8c/omTipyH/qciC0iVgZ3879j3KjJcEo5smSy3gvSEd1dE4
N14Yacz+frvBt6bsk+xXM4eOgO+RNmvHMuewd9Pi/Dd7yp5tcgYdWlyxYJPaFHd+
ayV40GtEdZd18tfpmKfOJG3yYpzDX0eD2bddYztmb6+xRiitQt2v5fgF2QEaFAyO
DqXPGgFSoSa/8EFqpP2JwwHDJezRZHWyBpylNKU4Pyu2dQ1JREUPS47JaXPmh7eI
zJecky9rA4Mz7pdlx/rH2BFhS9cSQmQRt9L++dy2iG8Gnw3WOFcncRINi725OOF3
mw3gKnYxtLAStRj2kjGEZJx2UG5K4N4oHs1lT2iWRqdp/t2V10trMmT4CSUYGnbq
5YnwFUSNotXRuLL/dNLjf0WOYzuHICwxaC/Czmcdz2AqtvNtnC8YyBUL4sMcr7fZ
0o6r+F376a8e4A7T/YUyfPbralyj/sdiuzQqTbtOdFZkYaKEqQmSVJBgCag6zns5
Ay1G+uuh2kCAb1gIGsQfKMOXIkTmP4lCZssR1rju4dKYVgPqjLn1+FDqfLW6z+tB
ggGp8Auv0n3DqzKD7HDr
=bCV6
-----END PGP SIGNATURE-----
Merge tag 'iommu-fixes-v4.6-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu
Pull IOMMU fixes from Joerg Roedel:
"The fixes include:
- Two patches to revert the use of default domains in the ARM SMMU
driver. Enabling this caused regressions which need more thorough
fixing. So the regressions are fixed for now by disabling the use
of default domains.
- A fix for a v4.4 regression in the AMD IOMMU driver which broke
devices behind invisible PCIe-to-PCI bridges with IOMMU enabled"
* tag 'iommu-fixes-v4.6-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu:
iommu/arm-smmu: Don't allocate resources for bypass domains
iommu/arm-smmu: Fix stream-match conflict with IOMMU_DOMAIN_DMA
iommu/amd: Fix checking of pci dma aliases
Pull drm fixes from Dave Airlie:
"i915, nouveau and amdgpu/radeon fixes in this:
nouveau:
Two fixes, one for a regression with dithering and one for a bug
hit by the userspace drivers.
i915:
A few fixes, mostly things heading for stable, two important
skylake GT3/4 hangs.
radeon/amdgpu:
Some audio, suspend/resume and some runtime PM fixes, along with
two patches to harden the userptr ABI a bit"
* 'drm-fixes' of git://people.freedesktop.org/~airlied/linux: (24 commits)
drm: Loongson-3 doesn't fully support wc memory
drm/nouveau/gr/gf100: select a stream master to fixup tfb offset queries
amdgpu/uvd: add uvd fw version for amdgpu
drm/amdgpu: forbid mapping of userptr bo through radeon device file
drm/radeon: forbid mapping of userptr bo through radeon device file
drm/amdgpu: bump the afmt limit for CZ, ST, Polaris
drm/amdgpu: use defines for CRTCs and AMFT blocks
drm/dp/mst: Validate port in drm_dp_payload_send_msg()
drm/nouveau/kms: fix setting of default values for dithering properties
drm/radeon: print a message if ATPX dGPU power control is missing
Revert "drm/radeon: disable runtime pm on PX laptops without dGPU power control"
drm/amdgpu/acp: fix resume on CZ systems with AZ audio
drm/radeon: add a quirk for a XFX R9 270X
drm/radeon: print pci revision as well as pci ids on driver load
drm/i915: Use fw_domains_put_with_fifo() on HSW
drm/i915: Force ringbuffers to not be at offset 0
drm/i915: Adjust size of PIPE_CONTROL used for gen8 render seqno write
drm/i915/skl: Fix spurious gpu hang with gt3/gt4 revs
drm/i915/skl: Fix rc6 based gpu/system hang
drm/i915/userptr: Hold mmref whilst calling get-user-pages
...
Somehow my SNB GT1 (Dell XPS 8300) gets very unhappy around
GPU hangs if the RPS EI/thresholds aren't suitably aligned.
It seems like scheduling/timer interupts stop working somehow
and things get stuck eg. in usleep_range().
I bisected the problem down to
commit 8a5864377b ("drm/i915/skl: Restructured the gen6_set_rps_thresholds function")
I observed that before all the values were at least multiples of 25,
but afterwards they are not. And rounding things up to the next multiple
of 25 does seem to help, so lets' do that. I also tried roundup(..., 5)
but that wasn't sufficient. Also I have no idea if we might need this sort of
thing on gen9+ as well.
These are the original EI/thresholds:
LOW_POWER
GEN6_RP_UP_EI 12500
GEN6_RP_UP_THRESHOLD 11800
GEN6_RP_DOWN_EI 25000
GEN6_RP_DOWN_THRESHOLD 21250
BETWEEN
GEN6_RP_UP_EI 10250
GEN6_RP_UP_THRESHOLD 9225
GEN6_RP_DOWN_EI 25000
GEN6_RP_DOWN_THRESHOLD 18750
HIGH_POWER
GEN6_RP_UP_EI 8000
GEN6_RP_UP_THRESHOLD 6800
GEN6_RP_DOWN_EI 25000
GEN6_RP_DOWN_THRESHOLD 15000
These are after 8a5864377b:
LOW_POWER
GEN6_RP_UP_EI 12500
GEN6_RP_UP_THRESHOLD 11875
GEN6_RP_DOWN_EI 25000
GEN6_RP_DOWN_THRESHOLD 21250
BETWEEN
GEN6_RP_UP_EI 10156
GEN6_RP_UP_THRESHOLD 9140
GEN6_RP_DOWN_EI 25000
GEN6_RP_DOWN_THRESHOLD 18750
HIGH_POWER
GEN6_RP_UP_EI 7812
GEN6_RP_UP_THRESHOLD 6640
GEN6_RP_DOWN_EI 25000
GEN6_RP_DOWN_THRESHOLD 15000
And these are what we have after this patch:
LOW_POWER
GEN6_RP_UP_EI 12500
GEN6_RP_UP_THRESHOLD 11875
GEN6_RP_DOWN_EI 25000
GEN6_RP_DOWN_THRESHOLD 21250
BETWEEN
GEN6_RP_UP_EI 10175
GEN6_RP_UP_THRESHOLD 9150
GEN6_RP_DOWN_EI 25000
GEN6_RP_DOWN_THRESHOLD 18750
HIGH_POWER
GEN6_RP_UP_EI 7825
GEN6_RP_UP_THRESHOLD 6650
GEN6_RP_DOWN_EI 25000
GEN6_RP_DOWN_THRESHOLD 15000
Cc: stable@vger.kernel.org
Cc: Akash Goel <akash.goel@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Testcase: igt/kms_pipe_crc_basic/hang-read-crc-pipe-B
Fixes: 8a5864377b ("drm/i915/skl: Restructured the gen6_set_rps_thresholds function")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1461159836-9108-1-git-send-email-ville.syrjala@linux.intel.com
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com>
This patch does the following:
- Fakes live status of HDMI as connected (even if that's not).
While testing certain (monitor + cable) combinations with
various intel platforms, it seems that live status register
doesn't work reliably on some older devices. So limit the
live_status check for HDMI detection, only for platforms
from gen7 onwards.
V2: restrict faking live_status to certain platforms
V3: (Ville)
- keep the debug message for !live_status case
- fix indentation of comment
- remove "warning" from the debug message
(Jani)
- Change format of fix details in the commit message
Fixes: 237ed86c69 ("drm/i915: Check live status before reading edid")
Cc: stable@vger.kernel.org # v4.4
Suggested-by: Ville Syrjala <ville.syrjala@linux.intel.com>
Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1461237606-16491-1-git-send-email-shashank.sharma@intel.com
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Again a relatively calm week without surprise: most of fixes are about
HD-audio, including fixes for Cirrus codec regression and a race over
regmap access. Although both change are slightly unintuitive, the
risk of further breakage is quite low, I hope.
Other than that, all the rest are trivial.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAABCAAGBQJXGeZhAAoJEGwxgFQ9KSmkOg4P/RWGLla59n6L6QCE2kNp3rQS
fPjVG2ctEHAqVi6lqLSletV2HkA1K6MY/tyawjtjG2Fs6JqbITasOWJmI10aDzDl
tmLWBlmJf4zRye2YbFmP4v5dE9VuRhU9ucMc4IqBT9+DgTEVNuCcQiW9amyj4kJ7
XcjT6z0tj/5MXe+hmjvHuEwc6qYk/4Z7HJDcKlNxsD7dQ9zoLhXmbEndw5600Os5
cMFzZzRPDofyRbvhooQrn1oJG143bilnseMV83O7WTwzJ+DSiZlJG8ibY7bPYsPL
qicr4keet5n96gZHbPXeZHvxlCzW4dStna1qPYOWTg8xy1kHGA7tAExznPG23f2h
ANTQ0lAN+A0I3PjB0S+MP6I2Uw+bkkKpo0w6ugSz8nmSfO1k9mkavK51RWAuQTef
ITdORv/HTkCHp7jyKBx2ArM+s3mckrNA4kNFOAHYpdXln3vQDPc0BnQkfq1LW6vf
RQVQSAoSBqZahefgfL2nuhHWa/QqZ+9XTPmxp1dA2YLmYLKtkGOZYuz0XkDYqSaC
JdnL+3Q7OmTbVvgPPOn595eq7R8VrH2vbQH1pJC+zRL+I9dVmZ7Et7KtBYCr0pON
G4S+ZieILnMTYdYsEK4jQkC0ZiWwpr+y2Lurz97qVm8yIbKSBEpxakxpVHNP5dDe
I/6ZrY3i3K4YqYbxPwEF
=wz0C
-----END PGP SIGNATURE-----
Merge tag 'sound-4.6-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
Pull sound fixes from Takashi Iwai:
"Again a relatively calm week without surprise: most of fixes are about
HD-audio, including fixes for Cirrus codec regression and a race over
regmap access. Although both change are slightly unintuitive, the
risk of further breakage is quite low, I hope.
Other than that, all the rest are trivial"
* tag 'sound-4.6-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound:
ALSA: hda - Fix possible race on regmap bypass flip
ALSA: pcxhr: Fix missing mutex unlock
ALSA: hda - add PCI ID for Intel Broxton-T
ALSA: hda - Keep powering up ADCs on Cirrus codecs
ALSA: hda/realtek - Add ALC3234 headset mode for Optiplex 9020m
ALSA - hda: hdmi check NULL pointer in hdmi_set_chmap
ALSA: hda - Don't trust the reported actual power state
* Correct preset_lpj calculation which may lead to too short delays
* Correct handling of optional clocks on r8a7791 to restore
access to the serial port the porter board
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJXGEtmAAoJENfPZGlqN0++aYIP/RCANWvI9Z7VH/Y/NQ1f5t4Y
l4Uv1/dSuIHJq44z0sLMD5gmDVKqP1NnCncfkZabDXceGm9Fk3DlFxeLd+ahMN+B
dBtDpf1AA9Mr1AEoBrXjNimWSupvJalatqk3nWfLnjpGHQJOKTZCekikQb9WBA5t
l5r5Pvu/leRfyg/wi10F3hq0a2drKbIbFDOzh37L7al9cvZTnyVZNcchb/vlqZmt
kAi90crLUXvQ9eOw357kFBmigQF5r/fD0X3f5sFYyDlNldZg3chkyghiluiOcXDL
eEc6TdHNT/a9hixqpW/Z1BinpvFF+vIjfUZBW9wXTRz0t9EX5Pxr9wSXWEY4+hmp
DrI9eiEAbX8ltfjOo3Q7LgHstjZ6AJyk3CZJBWk8i2DLK5SEt6eum/BvKRmakTa+
DLe+SES+uUfg1d35WEqhqPeO7JEybPAVyto++NrCRSkPeDeO32+h2O6yEsMBqEKC
HFoV/V86Ufqq8MCiZkQBZJGNYqcTeKMiXzvte23tcAXXYmxMct5Z4HLCiFEM4paw
yyThG9VZofe4pt03u9XqiZjEu23AopMpM9xDpUjK3CKYq6uaJxNoJcgJC6TBbkmT
D7kdmhhlWCLeyr3pqblbqiWdK7Bx9B65aFhm/nilX0y4p3vvT46vMLvG4SgfFojv
Ybr9ICHZMaTxJ1V32fty
=k7qU
-----END PGP SIGNATURE-----
Merge tag 'renesas-fixes-for-v4.6' of git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas into fixes
Merge "Renesas ARM Based SoC Fixes for v4.6" from Simon Horman:
Renesas ARM Based SoC Fixes for v4.6
* Correct preset_lpj calculation which may lead to too short delays
* Correct handling of optional clocks on r8a7791 to restore
access to the serial port the porter board
* tag 'renesas-fixes-for-v4.6' of git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas:
ARM: shmobile: timer: Fix preset_lpj leading to too short delays
Revert "ARM: dts: porter: Enable SCIF_CLK frequency and pins"
ARM: dts: r8a7791: Don't disable referenced optional clocks
Since we've fixed up drm_dp_dpcd_read() to allow for retries when things
timeout, there's no use for having this function anymore. Good riddens.
Signed-off-by: Lyude <cpaul@redhat.com>
Tested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1460559513-32280-5-git-send-email-cpaul@redhat.com
This is part of a patch series to migrate all of the workarounds for
commonly seen behavior from bad sinks in intel_dp_dpcd_read_wake() to drm's
DP helper.
Some sinks will just return garbage for the first aux tranaction they
receive when coming out of sleep mode, so we need to perform an additional
read before the actual read to workaround this.
Changes since v5
- If the throwaway read in drm_dp_dpcd_read() fails, return the error
from that instead of continuing. This follows the same logic we do in
drm_dp_dpcd_access() (e.g. the error from the first transaction may
differ from the errors that proceeding attempts might return).
Signed-off-by: Lyude <cpaul@redhat.com>
Tested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1460730335-5012-1-git-send-email-cpaul@redhat.com
This is part of a patch series to migrate all of the workarounds for
commonly seen behavior from bad sinks in intel_dp_dpcd_read_wake() to
drm's DP helper.
We cannot rely on sinks NACKing or deferring when they can't receive
transactions, nor can we rely on any other sort of consistent error to
know when we should stop retrying. As such, we need to just retry
unconditionally on errors. We also make sure here to return the error we
encountered during the first transaction, since it's possible that
retrying the transaction might return a different error then we had
originally.
This, along with the previous patch, work around a weird bug with the
ThinkPad T560's and it's dock. When resuming the laptop, it appears that
there's a short period of time where we're unable to complete any aux
transactions, as they all immediately timeout. The only machine I'm able
to reproduce this on is the T560 as other production Skylake models seem
to be fine. The period during which AUX transactions fail appears to be
around 22ms long. AFAIK, the dock for the T560 never actually turns off,
the only difference is that it's in SST mode at the start of the resume
process, so it's unclear as to why it would need so much time to come
back up.
There's been a discussion on this issue going on for a while on the
intel-gfx mailing list about this that has, in addition to including
developers from Intel, also had the correspondence of one of the
hardware engineers for Intel:
http://www.spinics.net/lists/intel-gfx/msg88831.htmlhttp://www.spinics.net/lists/intel-gfx/msg88410.html
We've already looked into a couple of possible explanations for the
problem:
- Calling intel_dp_mst_resume() before right fix.
intel_runtime_pm_enable_interrupts(). This was the first fix I tried,
and while it worked it definitely wasn't the right fix. This worked
because DP aux transactions don't actually require interrupts to work:
static uint32_t
intel_dp_aux_wait_done(struct intel_dp *intel_dp, bool has_aux_irq)
{
struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
struct drm_device *dev = intel_dig_port->base.base.dev;
struct drm_i915_private *dev_priv = dev->dev_private;
i915_reg_t ch_ctl = intel_dp->aux_ch_ctl_reg;
uint32_t status;
bool done;
#define C (((status = I915_READ_NOTRACE(ch_ctl)) & DP_AUX_CH_CTL_SEND_BUSY) == 0)
if (has_aux_irq)
done = wait_event_timeout(dev_priv->gmbus_wait_queue, C,
msecs_to_jiffies_timeout(10));
else
done = wait_for_atomic(C, 10) == 0;
if (!done)
DRM_ERROR("dp aux hw did not signal timeout (has irq: %i)!\n",
has_aux_irq);
#undef C
return status;
}
When there's no interrupts enabled, we end up timing out on the
wait_event_timeout() call, which causes us to check the DP status
register once to see if the transaction was successful or not. Since
this adds a 10ms delay to each aux transaction, it ends up adding a
long enough delay to the resume process for aux transactions to become
functional again. This gave us the illusion that enabling interrupts
had something to do with making things work again, and put me on the
wrong track for a while.
- Interrupts occurring when we try to perform the aux transactions
required to put the dock back into MST mode. This isn't the problem,
as the only interrupts I've observed that come during this timeout
period are from the snd_hda_intel driver, and disabling that driver
doesn't appear to change the behavior at all.
- Skylake's PSR block causing issues by performing aux transactions
while we try to bring the dock out of MST mode. Disabling PSR through
i915's command line options doesn't seem to change the behavior
either, nor does preventing the DMC firmware from being loaded.
Since this investigation went on for about 2 weeks, we decided it would
be better for the time being to just workaround this issue by making
sure AUX transactions wait a short period of time before retrying.
Signed-off-by: Lyude <cpaul@redhat.com>
Tested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1460559513-32280-3-git-send-email-cpaul@redhat.com
This is part of a patch series to migrate all of the workarounds for
commonly seen behavior from bad sinks in intel_dp_dpcd_read_wake() to
drm's DP helper.
Some sinks need some time during the process of resuming the system from
sleep before they're ready to handle transactions. While it would be
nice if they responded with NACKs in these scenarios, this isn't always
the case as a few sinks will just timeout on all of the transactions
they receive until they're ready.
Signed-off-by: Lyude <cpaul@redhat.com>
Tested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1460559513-32280-2-git-send-email-cpaul@redhat.com
that broke when we added runtime based SoC revision detection earlier.
It seems suspend worked earlier as things were only partially initialized,
while now we initialize things properly for dra7.
Note that the "ARM: OMAP: Catch callers of revision information prior
to it being populated" had to be reverted as it caused bogus warnings
for other SoCs because omap initcalls bail out based on revision being
set to 0 for other SoCs. These initcalls will mostly just disappear
when we drop support for omap3 legacy booting.
Also included is a fix for dra7 sys_32k_ck clock source that is not
enabled on boot making system fall back to using emulated clock.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJXFkmvAAoJEBvUPslcq6VzmakQAKmjDs+iS02No6sQaIkBvadJ
gAL8EvAPZ5QLt6OW+MvFLiE42kr9NZSbvyLNLzjjqKI9AmuYZnrci8tQJ9uOHMLM
SmScTjE6b7PvGo2jI+IXkoi1hVL1YP7FKuA0/25EwNaeMKoZ7JPFJ/jpPatvIEg7
2TB6wk0rdlpGaaSx8uFR2ohDE8lA0gDNRDiHx7G2d9tl9rLLXC2IvS1YhpvLcGw0
IkRgFGF6+WZ09DZ+B1pnKPrf5wWBGqI44IWBL4epOCsDGxOYFjMix5or7FiaTrcP
8BGfOVJCRKGjccBvAFJLSznjMQb8jeTHkFxWY8BgY2FSuTJlFrbkxIBraFaZMqG/
9IOxPvjCJDgJdhGxHuQUGKzbQ2o7D7H5xb5PCxbdscHTcwi2WR6AXI6q+5v2ykqu
moQXvAPS2GcfVrgXcuIthwvqENExILTwogcgME8/6DvS0l7LlJ7bf1G32jsCvI3M
mw0+8GKx9qW+7demu6uy0uLiVI5cHfcTWp2ocLnXwnRVmixU5XG4QaPRp/MhB/QV
F57UxJFHH398zeZ8OgJFzjYwIT+60KCJNU+qMHdBdd76hiJ7Dg0rMxqoxLpbaB4t
fPbhuE/eUWvZR5IeL1I1M4dDgpp6KThGR86K1wHSMwWkq8Og+XoYMoU3yn0tyqT9
IHyBWPFAVpKI44uAle7w
=0X4E
-----END PGP SIGNATURE-----
Merge tag 'omap-for-v4.6/fixes-rc2-v2-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into fixes
Merge "omap fixes against v4.6-rc2" from Tony Lindgren
Fixes for omaps against v4.6-rc2, mostly to fix suspend for beagle-x15
that broke when we added runtime based SoC revision detection earlier.
It seems suspend worked earlier as things were only partially initialized,
while now we initialize things properly for dra7.
Note that the "ARM: OMAP: Catch callers of revision information prior
to it being populated" had to be reverted as it caused bogus warnings
for other SoCs because omap initcalls bail out based on revision being
set to 0 for other SoCs. These initcalls will mostly just disappear
when we drop support for omap3 legacy booting.
Also included is a fix for dra7 sys_32k_ck clock source that is not
enabled on boot making system fall back to using emulated clock.
* tag 'omap-for-v4.6/fixes-rc2-v2-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap: (198 commits)
Revert "ARM: OMAP: Catch callers of revision information prior to it being populated"
ARM: OMAP: Catch callers of revision information prior to it being populated
ARM: dts: dra7: Correct clock tree for sys_32k_ck
ARM: OMAP: DRA7: Provide proper class to omap2_set_globals_tap
ARM: OMAP: DRA7: wakeupgen: Skip SAR save for wakeupgen
Linux 4.6-rc2
v4l2-mc: avoid warning about unused variable
Convert straggling drivers to new six-argument get_user_pages()
.mailmap: add Christophe Ricard
Make CONFIG_FHANDLE default y
mm/page_isolation.c: fix the function comments
oom, oom_reaper: do not enqueue task if it is on the oom_reaper_list head
mm/page_isolation: fix tracepoint to mirror check function behavior
mm/rmap: batched invalidations should use existing api
x86/mm: TLB_REMOTE_SEND_IPI should count pages
mm: fix invalid node in alloc_migrate_target()
include/linux/huge_mm.h: return NULL instead of false for pmd_trans_huge_lock()
mm, kasan: fix compilation for CONFIG_SLAB
MAINTAINERS: orangefs mailing list is subscribers-only
net: mvneta: fix changing MTU when using per-cpu processing
...
Maxim advertised the ramp rate of the rail with some recommended
design specification like output capacitance of rail should be
2.2uF. This make sure that current change in the rail is within
maximum current limit and hence meet the advertised ramp rate.
If there is variation in design which causes the rail current to
change more that maximum current limit then device applies the
current limit. In this case, ramp rate is different than advertised
ramp rate.
Add device specific settings for ramp rate which need to be configure
on device register when measure ramp rate on platform is deviated from
advertised ramp rate. In this case, all delay time calculation for
voltage change is done with measured ramp rate and device ramp rate
is used for configuring the device register.
If measured ramp rate in the platform is same as advertised ramp rate
then regulator-ramp-delay is used for the device register configuration
and ramp time calculation for voltage change.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
It is observed that the ramp rate measured on platform is not same as
advertised ramp rate due to platform design variation. On this case,
measured ramp rate is provided with property regulator-ramp-rate.
For such cases, add DT property for device specific configurations.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The expected MCLK frequency ranges and the associated dividers
are updated to improve PLL locking in a corner scenario, with low
MCLK frequency near an input divider change boundary.
Signed-off-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
We read one element beyond the end of the array when we access
"rdesc[i + 1]" so it causes a static checker warning. It's harmless
because we write over it again on the next line. But let's just silence
the warning.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Purna Chandra Mandal <purna.mandal@microchip.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Add support for board based on the popular Altera Cyclone V SoC.
This board has the following properties:
- 1 GiB of DRAM
- 1 Gigabit ethernet
- 1 USB gadget port
- 1 USB host port with an on-board hub
- 2 QSPI NORs connected to the Cadence QSPI core
- Multiple I2C EEPROMs and one I2C temperature sensor
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Dinh Nguyen <dinguyen@opensource.altera.com>
Signed-off-by: Dinh Nguyen <dinguyen@opensource.altera.com>
The SPI controller managed by the spi-orion is used on the new ARM64
Marvell Armada 7K/8K SoCs. In order to allow this driver to be built
for this platform, we allow it to be selected for ARCH_MVEBU=y
configurations.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
It's possible that BIOS enables PHY0, but it programmes only the first
channel on it. Since we program the PHYs only during driver loading this
is an incorrect configuration from the driver's point of view, since we
may use both channels eventually. Detect this scenario and force
reprogramming the PHY in this case.
The actual scenario for me was that the lane optimization for the second
channel in PHY0 was not setup by BIOS and so a state verification
warning was triggered. Everything else was setup properly.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1461174366-16758-4-git-send-email-imre.deak@intel.com
The exynos5 I2C controller driver always prepares and enables a clock
before using it and then disables unprepares it when the clock is not
used anymore.
But this can cause a possible ABBA deadlock in some scenarios since a
driver that uses regmap to access its I2C registers, will first grab
the regmap lock and then the I2C xfer function will grab the prepare
lock when preparing the I2C clock. But since the clock driver also
uses regmap for I2C accesses, preparing a clock will first grab the
prepare lock and then the regmap lock when using the regmap API.
An example of this happens on the Exynos5422 Odroid XU4 board where a
s2mps11 PMIC is used and both the s2mps11 regulators and clk drivers
share the same I2C regmap.
The possible deadlock is reported by the kernel lockdep:
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(sec_core:428:(regmap)->lock);
lock(prepare_lock);
lock(sec_core:428:(regmap)->lock);
lock(prepare_lock);
*** DEADLOCK ***
Fix it by leaving the code prepared on probe and use {en,dis}able in
the I2C transfer function.
This patch is similar to commit 34e81ad5f0 ("i2c: s3c2410: fix ABBA
deadlock by keeping clock prepared") that fixes the same bug in other
driver for an I2C controller found in Samsung SoCs.
Reported-by: Anand Moon <linux.amoon@gmail.com>
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Reviewed-by: Anand Moon <linux.amoon@gmail.com>
Reviewed-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Cc: stable@kernel.org
If we skipped PHY0 initialization because it was already enabled by
BIOS, we still have to wait for the PHY1 GRC calibration as that is
done as part of the PHY0 init.
v2:
- Use the actual PHY index in the debug message in
broxton_phy_wait_grc_done() (Ville)
CC: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1461255561-1644-1-git-send-email-imre.deak@intel.com
It's possible that BIOS enables PHY1 only to read out the GRC value from
it to be used in PHY0 and then disables PHY1. In this case we can't use
the PHY1 GRC value for state verification, so use instead the one in PHY0
always.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1461174366-16758-2-git-send-email-imre.deak@intel.com
Since commit ea8daa7b97 ("kbuild: Add option to turn incompatible
pointer check into error"), assignments from an incompatible pointer
types have become a hard error, eg:
drivers/i2c/busses/i2c-cpm.c:545:91: error: passing argument 3 of
'dma_alloc_coherent' from incompatible pointer type
Fix the build break by converting txdma & rxdma to dma_addr_t.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Cc: stable@kernel.org
Fixes: ea8daa7b97
Extend the set of possible HCI bus types with SPI and I2C.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
All i2c mux users are using an explicit i2c mux core, drop support
for implicit i2c mux cores.
Signed-off-by: Peter Rosin <peda@axentia.se>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Allocate an explicit i2c mux core to handle parent and child adapters
etc. Update the select op to be in terms of the i2c mux core instead
of the child adapter.
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Peter Rosin <peda@axentia.se>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Allocate an explicit i2c mux core to handle parent and child adapters
etc. Update the select op to be in terms of the i2c mux core instead
of the child adapter.
Tested-by: Antti Palosaari <crope@iki.fi>
Signed-off-by: Peter Rosin <peda@axentia.se>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Allocate an explicit i2c mux core to handle parent and child adapters
etc. Update the select/deselect ops to be in terms of the i2c mux core
instead of the child adapter.
Tested-by: Antti Palosaari <crope@iki.fi>
Reviewed-by: Antti Palosaari <crope@iki.fi>
Signed-off-by: Peter Rosin <peda@axentia.se>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Allocate an explicit i2c mux core to handle parent and child adapters
etc. Update the select/deselect ops to be in terms of the i2c mux core
instead of the child adapter.
Tested-by: Antti Palosaari <crope@iki.fi>
Reviewed-by: Antti Palosaari <crope@iki.fi>
Signed-off-by: Peter Rosin <peda@axentia.se>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Allocate an explicit i2c mux core to handle parent and child adapters
etc. Update the select op to be in terms of the i2c mux core instead
of the child adapter.
Tested-by: Antti Palosaari <crope@iki.fi>
Reviewed-by: Antti Palosaari <crope@iki.fi>
Signed-off-by: Peter Rosin <peda@axentia.se>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Allocate an explicit i2c mux core to handle parent and child adapters
etc. Update the select op to be in terms of the i2c mux core instead
of the child adapter.
Tested-by: Antti Palosaari <crope@iki.fi>
Reviewed-by: Antti Palosaari <crope@iki.fi>
Signed-off-by: Peter Rosin <peda@axentia.se>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Allocate an explicit i2c mux core to handle parent and child adapters
etc. Update the select/deselect ops to be in terms of the i2c mux core
instead of the child adapter.
Acked-by: Jonathan Cameron <jic23@kernel.org>
Tested-by: Crestez Dan Leonard <leonard.crestez@intel.com>
Signed-off-by: Peter Rosin <peda@axentia.se>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Allocate an explicit i2c mux core to handle parent and child adapters
etc. Update the select/deselect ops to be in terms of the i2c mux core
instead of the child adapter.
Signed-off-by: Peter Rosin <peda@axentia.se>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Allocate an explicit i2c mux core to handle parent and child adapters
etc. Update the select/deselect ops to be in terms of the i2c mux core
instead of the child adapter.
Add a mask to handle the case where not all child adapters should
cause a mux deselect to happen, now that there is a common deselect op
for all child adapters.
Signed-off-by: Peter Rosin <peda@axentia.se>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Allocate an explicit i2c mux core to handle parent and child adapters
etc. Update the select/deselect ops to be in terms of the i2c mux core
instead of the child adapter.
Signed-off-by: Peter Rosin <peda@axentia.se>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Allocate an explicit i2c mux core to handle parent and child adapters
etc. Update the select/deselect ops to be in terms of the i2c mux core
instead of the child adapter.
Signed-off-by: Peter Rosin <peda@axentia.se>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Allocate an explicit i2c mux core to handle parent and child adapters
etc. Update the select/deselect ops to be in terms of the i2c mux core
instead of the child adapter.
Signed-off-by: Peter Rosin <peda@axentia.se>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Allocate an explicit i2c mux core to handle parent and child adapters
etc. Update the select/deselect ops to be in terms of the i2c mux core
instead of the child adapter.
Signed-off-by: Peter Rosin <peda@axentia.se>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
All i2c-muxes have a parent adapter and one or many child
adapters. A mux also has some means of selection. Previously,
this was stored per child adapter, but it is only needed
to keep track of this per mux.
Add an i2c mux core, that keeps track of this consistently.
Also add some glue for users of the old interface, which will
create one implicit mux core per child adapter.
Signed-off-by: Peter Rosin <peda@axentia.se>
Tested-by: Antti Palosaari <crope@iki.fi>
Tested-by: Crestez Dan Leonard <leonard.crestez@intel.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
- The asm helpers for calling into irq tracer were missing
- Add calls to above helpers in low level assembly entry code for ARCv2
- irq_save() uses CLRI to disable interrupts and returns the prev interrupt
state (in STATUS32) in a specific encoding (and not the raw value of
STATUS32). This is usable with SETI in irq_restore(). However
save_flags() reads the raw value of STATUS32 which doesn't pair with
irq_save/restore() and thus needs fixing.
Signed-off-by: Evgeny Voevodin <evgeny.voevodin@intel.com>
[vgupta: updated changelog and also added some comments]
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
Remove dev local and use to_i915() in gen8_ppgtt_notify_vgt.
v2: use dev_priv directly for QUESTION_MACROS (Joonas Lahtinen)
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1461323365-21256-1-git-send-email-matthew.auld@intel.com
Right after runtime resume we know that we can re-enable DC5, since we
just disabled DC9 and power well 2 is disabled. So enable DC5 explicitly
instead of delaying this until the next time we disable power well 2.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Bob Paauwe <bob.j.paauwe@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1461173277-16090-5-git-send-email-imre.deak@intel.com
After suspend-to-ram or -disk we don't know what power state the display
HW will be, DC0 or DC9 are both possible states, so reset the software
DC state tracking in these cases. This gets rid of 'DC state mismatch'
error messages during resuming from ram or disk where we expected to be
in DC9 (as set by the suspend handler) but we are in DC0.
v2:
- Remove extra WS in gen9_sanitize_dc_state() (Bob)
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Bob Paauwe <bob.j.paauwe@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1461173277-16090-4-git-send-email-imre.deak@intel.com
Initially we thought that the platform specific suspend/resume sequences
can be shared between the runtime and system suspend/resume handlers.
This turned out to be not true, we have quite a few differences on most
of the platforms. This was realized already earlier by Paulo who
inlined the platform specific resume_prepare handlers. We have the
same problem with the corresponding suspend_complete handlers, there are
platform differences that make it unfeasible to share the code between
the runtime and system suspend paths. Also now we call functions that
need to be paired like hsw_enable_pc8()/hsw_disable_pc8() from different
levels of the call stack, which is confusing. Fix this by inlining the
suspend_complete handlers too.
This is also needed by the next patch that removes a redundant
uninit/init call during system suspend/resume on BXT.
No functional change.
CC: Paulo Zanoni <przanoni@gmail.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Bob Paauwe <bob.j.paauwe@intel.com>
[s/uninline/inline in the commit message]
Link: http://patchwork.freedesktop.org/patch/msgid/1461173277-16090-2-git-send-email-imre.deak@intel.com
PSL designers recommend a larger value for the mmio hang pulse, 256 us
instead of 1 us. The CAIA architecture states that it needs to be
smaller than 1/2 of the RTOS timeout set in the PHB for outbound
non-posted transactions, which is still (easily) the case here.
Signed-off-by: Frederic Barrat <fbarrat@linux.vnet.ibm.com>
Acked-by: Ian Munsie <imunsie@au1.ibm.com>
Tested-by: Frank Haverkamp <haver@linux.vnet.ibm.com>
Tested-by: Manoj Kumar <manoj@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Failure to synchronize the PSL timebase currently prevents the
initialization of the cxl card, thus rendering the card useless. This
is too extreme for a feature which is rarely used, if at all. No
hardware AFUs or software is currently using PSL timebase.
This patch still tries to synchronize the PSL timebase when the card
is initialized, but ignores the error if it can't. Instead, it reports
a status via /sys.
Signed-off-by: Frederic Barrat <fbarrat@linux.vnet.ibm.com>
Acked-by: Ian Munsie <imunsie@au1.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
