summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2019-02-21Merge tag 'docs-5.0-fix' of git://git.lwn.net/linuxLinus Torvalds3-73/+78
Pull documentation fix from Jonathan Corbet: "A single patch from Arnd bringing some top-level docs into the 5.0 era" * tag 'docs-5.0-fix' of git://git.lwn.net/linux: Documentation: change linux-4.x references to 5.x
2019-02-21drm/amdgpu: disable bulk moves for nowChristian König1-0/+2
The changes to fix those are two invasive for backporting. Just disable the feature in 4.20 and 5.0. Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Christian König <christian.koenig@amd.com> Cc: <stable@vger.kernel.org> [4.20+] Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-02-21drm/amd/display: set clocks to 0 on suspend on dce80Bhawanpreet Lakha1-3/+16
[Why] When a dce80 asic was suspended, the clocks were not set to 0. Upon resume, the new clock was compared to the existing clock, they were found to be the same, and so the clock was not set. This resulted in a blackscreen. [How] In atomic commit, check to see if there are any active pipes. If no, set clocks to 0 Signed-off-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Reviewed-by: Nicholas Kazlauskas <Nicholas.Kazlauskas@amd.com> Acked-by: Leo Li <sunpeng.li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2019-02-21drm/amd/display: fix optimize_bandwidth func pointer for dce80Bhawanpreet Lakha2-1/+5
[Why] optimize_bandwidth was using dce100_prepare_bandwidth this is incorrect [How] change it to dce100_optimize_bandwidth Signed-off-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Reviewed-by: Charlene Liu <Charlene.Liu@amd.com> Acked-by: Leo Li <sunpeng.li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2019-02-21drm/amd/display: Fix negative cursor pos programmingNicholas Kazlauskas1-2/+2
[Why] If the cursor pos passed from DM is less than the plane_state->dst_rect top left corner then the unsigned cursor pos wraps around to a large positive number since cursor pos is a u32. There was an attempt to guard against this in hubp1_cursor_set_position by checking the src_x_offset and src_y_offset and offseting the cursor hotspot within hubp1_cursor_set_position. However, the cursor position itself is still being programmed incorrectly as a large value. This manifests itself visually as the cursor disappearing or containing strange artifacts near the middle of the screen on raven. [How] Don't subtract the destination rect top left corner from the pos but add it to the hotspot instead. This happens before the pos gets passed into hubp1_cursor_set_position. This achieves the same result but avoids the subtraction wrap around. With this fix the original cursor programming logic can be used again. Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Reviewed-by: Charlene Liu <Charlene.Liu@amd.com> Acked-by: Leo Li <sunpeng.li@amd.com> Acked-by: Murton Liu <Murton.Liu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-02-20drm/i915: Extend skl+ crc sources with more planesVille Syrjälä3-2/+87
On skl the crc registers were extended to provide plane crcs for up to 7 planes. Add the new crc sources. The current code uses the ivb+ register definitions for skl+ which does happen to work as the plane1, plane2, and dmux/pf bits happen the match what ivb+ had. So no bug in the current code. v2: Drop the unused set_wa parameter (DK) Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190214192219.3858-4-ville.syrjala@linux.intel.com Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2019-02-20drm/i915: Remove the broken DP CRC support for g4xVille Syrjälä1-69/+11
DP CRCs don't really work on g4x. If you want any CRCs on DP you must select the CRC source before the port is enabled, otherwise the CRC source select bits simply ignore any writes to them. And once the port is enabled we mustn't change the CRC source select until the port is disabled. That almost works, but not quite :( Eventually the CRC source select bits get permanently stuck one way or the other, and after that a reboot (or possibly a display reset) is needed to get working CRCs on that pipe (not matter which CRC source we try to use). Additionally the DFT scrambler reset bits we're trying to use don't seem to exist on g4x. There are some potentially relevant looking bits in the pipe registers, but when I tried it I got stable looking CRCs without setting any bits for this. If there is a way to make DP CRCs work reliably on g4x, I wasn't able to find it. So let's just remove the broken code we have. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190214192219.3858-3-ville.syrjala@linux.intel.com Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
2019-02-20drm/i915: Use named initializers for the crc source name arrayVille Syrjälä1-9/+9
We assume that the index of the string in the crc source names array matches the enum value for the crc source. Let's use named initializers to make sure that is indeed the case even if someone rearranges either the enum or the array. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190214192219.3858-2-ville.syrjala@linux.intel.com Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2019-02-20drm/i915: Remove the "pf" crc sourceVille Syrjälä2-5/+2
The "pipe" and "pf" crc sources are in fact the same thing. Remove the "pf" one. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190214192219.3858-1-ville.syrjala@linux.intel.com Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2019-02-20drm/i915: Reduce the RPS shockChris Wilson1-0/+12
Limit deboosting and boosting to keep ourselves at the extremes when in the respective power modes (i.e. slowly decrease frequencies while in the HIGH_POWER zone and slowly increase frequencies while in the LOW_POWER zone). On idle, we will hit the timeout and drop to the next level quickly, and conversely if busy we expect to hit a waitboost and rapidly switch into max power. This should improve the UX experience by keeping the GPU clocks higher than they ostensibly should be (based on simple busyness) by switching into the INTERACTIVE mode (due to waiting for pageflips) and increasing clocks via waitboosting. This will incur some additional power, our saving grace should be rc6 and powergating to keep the extra current draw in check. Food for future thought would be deadline scheduling? If we know certain contexts (high priority compositors) absolutely must hit the next vblank then we can raise the frequencies ahead of time. Part of this is covered by per-context frequencies, where userspace is given control over the frequency range they want the GPU to execute at (for largely the same problem as this, where the workload is very latency sensitive but at the EI level appears mostly idle). Indeed, the per-context series does extend the modeset boosting to include a frequency range tweak which seems applicable to solving this jittery UX behaviour. Reported-by: Lyude Paul <lyude@redhat.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109408 References: 0d55babc8392 ("drm/i915: Drop stray clearing of rps->last_adj") References: 60548c554be2 ("drm/i915: Interactive RPS mode") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Lyude Paul <lyude@redhat.com> Cc: Eero Tamminen <eero.t.tamminen@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Michel Thierry <michel.thierry@intel.com> Quoting Lyude Paul: > Before reverting 0d55babc8392754352f1058866dd4182ae587d11: [4.20] > > 35 measurements [of gnome-shell animations] > Average: 33.65657142857143 FPS > FPS observed: 20.8 - 46.87 FPS > Percentage under 60 FPS: 100.0% > Percentage under 55 FPS: 100.0% > Percentage under 50 FPS: 100.0% > Percentage under 45 FPS: 97.14285714285714% > Percentage under 40 FPS: 97.14285714285714% > Percentage under 35 FPS: 45.714285714285715% > Percentage under 30 FPS: 11.428571428571429% > Percentage under 25 FPS: 2.857142857142857% > > After reverting: [4.19 behaviour] > > 30 measurements > Average: 49.833666666666666 FPS > FPS observed: 33.85 - 60.0 FPS > Percentage under 60 FPS: 86.66666666666667% > Percentage under 55 FPS: 70.0% > Percentage under 50 FPS: 53.333333333333336% > Percentage under 45 FPS: 20.0% > Percentage under 40 FPS: 6.666666666666667% > Percentage under 35 FPS: 6.666666666666667% > Percentage under 30 FPS: 0% > Percentage under 25 FPS: 0% > > Patched: > 42 measurements > Average: 46.05428571428571 FPS > FPS observed: 1.82 - 59.98 FPS > Percentage under 60 FPS: 88.09523809523809% > Percentage under 55 FPS: 61.904761904761905% > Percentage under 50 FPS: 45.23809523809524% > Percentage under 45 FPS: 35.714285714285715% > Percentage under 40 FPS: 33.33333333333333% > Percentage under 35 FPS: 19.047619047619047% > Percentage under 30 FPS: 7.142857142857142% > Percentage under 25 FPS: 4.761904761904762% Tested-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190219122215.8941-13-chris@chris-wilson.co.uk
2019-02-20orangefs: remove two un-needed BUG_ONs...Mike Marshall1-4/+0
Signed-off-by: Mike Marshall <hubcap@omnibond.com>
2019-02-20drm/i915: Fix KBL HDCP2.2 encrypt status signallingRamalingam C1-0/+42
HDCP transmitter is supposed to indicate the HDCP encryption status of the link through enc_en signals in a window of time called "window of opportunity" defined by HDCP HDMI spec. But on KBL this timing of signalling has an issue. To fix the issue this WA of resetting the signalling is required. v2: WA is moved into the toggle_signalling [Daniel] v3: Commit msg is rewritten with more information v4: Reviewed-by Daniel. Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/1550338640-17470-17-git-send-email-ramalingam.c@intel.com
2019-02-20drm/i915: CP_IRQ handling for DP HDCP2.2 msgsRamalingam C3-15/+35
Implements the Waitqueue is created to wait for CP_IRQ Signaling the CP_IRQ arrival through atomic variable. For applicable DP HDCP2.2 msgs read wait for CP_IRQ. As per HDCP2.2 spec "HDCP Transmitters must process CP_IRQ interrupts when they are received from HDCP Receivers" Without CP_IRQ processing, DP HDCP2.2 H_Prime msg was getting corrupted while reading it based on corresponding status bit. This creates the random failures in reading the DP HDCP2.2 msgs. v2: CP_IRQ arrival is tracked based on the atomic val inc [daniel] Recording the reviewed-by Daniel from IRC. Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/1550338640-17470-16-git-send-email-ramalingam.c@intel.com
2019-02-20drm/i915: Implement the HDCP2.2 support for HDMIRamalingam C1-0/+189
Implements the HDMI adaptation specific HDCP2.2 operations. Basically these are DDC read and write for authenticating through HDCP2.2 messages. v2: Rebased. v3: No more special handling of Gmbus burst read for AKE_SEND_CERT. Style fixed with few naming. [Uma] %s/PARING/PAIRING v4: msg_sz is initialized at definition. Lookup table is defined for HDMI HDCP2.2 msgs [Daniel]. v5: Rebased. v6: Make a function as inline [Uma] %s/uintxx_t/uxx v7: Errors due to sinks are reported as DEBUG logs. Adjust to the new mei interface. v8: ARRAY_SIZE for the # of array members [Jon & Daniel]. hdcp adaptation is added as a const in the hdcp_shim [Daniel] Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/1550338640-17470-15-git-send-email-ramalingam.c@intel.com
2019-02-20drm/i915: Implement the HDCP2.2 support for DPRamalingam C1-0/+333
Implements the DP adaptation specific HDCP2.2 functions. These functions perform the DPCD read and write for communicating the HDCP2.2 auth message back and forth. v2: wait for cp_irq is merged with this patch. Rebased. v3: wait_queue is used for wait for cp_irq [Chris Wilson] v4: Style fixed. %s/PARING/PAIRING Few style fixes [Uma] v5: Lookup table for DP HDCP2.2 msg details [Daniel]. Extra lines are removed. v6: Rebased. v7: Fixed some regression introduced at v5. [Ankit] Macro HDCP_2_2_RX_CAPS_VERSION_VAL is reused [Uma] Converted a function to inline [Uma] %s/uintxx_t/uxx v8: Error due to the sinks are reported as DEBUG logs. Adjust to the new mei interface. v9: ARRAY_SIZE for no of array members [Jon & Daniel] return of the wait_for_cp_irq is made as void [Daniel] Wait for HDCP2.2 msg is done based on polling the reg bit than CP_IRQ based. [Daniel] hdcp adaptation is added as a const in the hdcp_shim [Daniel] v10: config_stream_type is redefined [Daniel] DP Errata specific defines are moved into intel_dp.c. Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Signed-off-by: Ankit K Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/1550338640-17470-14-git-send-email-ramalingam.c@intel.com
2019-02-20drm: removing the DP Errata msg and its msg idRamalingam C1-6/+0
Since DP ERRATA message is not defined at spec, those structure definition is removed from drm_hdcp.h Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Suggested-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Acked-by: Dave Airlie <airlied@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/1550338640-17470-13-git-send-email-ramalingam.c@intel.com
2019-02-20drm/i915: Handle HDCP2.2 downstream topology changeRamalingam C1-2/+18
When repeater notifies a downstream topology change, this patch reauthenticate the repeater alone without disabling the hdcp encryption. If that fails then complete reauthentication is executed. v2: Rebased. v3: Typo in commit msg is fixed [Uma] v4: Rebased as part of patch reordering. Minor style fixes. v5: Rebased. v6: Rebased. v7: Errors due to sinks are reported as DEBUG logs. Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/1550338640-17470-12-git-send-email-ramalingam.c@intel.com
2019-02-20drm/i915: Implement HDCP2.2 link integrity checkRamalingam C2-5/+93
Implements the link integrity check once in 500mSec. Once encryption is enabled, an ongoing Link Integrity Check is performed by the HDCP Receiver to check that cipher synchronization is maintained between the HDCP Transmitter and the HDCP Receiver. On the detection of synchronization lost, the HDCP Receiver must assert the corresponding bits of the RxStatus register. The Transmitter polls the RxStatus register and it may initiate re-authentication. v2: Rebased. v3: enum check_link_response is used check the link status [Uma] v4: Rebased as part of patch reordering. v5: Required members of intel_hdcp is defined [Sean Paul] v6: hdcp2_check_link is cancelled at required places. v7: Rebased for the component i/f changes. Errors due to the sinks are reported as DEBUG logs. v8: hdcp_check_work is used for both hdcp1 and hdcp2 check_link [Daniel] hdcp2.2 encryption status check is put under WARN_ON [Daniel] drm_hdcp.h changes are moved into separate patch [Daniel] v9: enum check_link_status is defined at intel_drv.h [Daniel] Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/1550338640-17470-11-git-send-email-ramalingam.c@intel.com
2019-02-20drm: HDCP2.2 link check periodRamalingam C1-0/+1
Time period for HDCP2.2 link check. Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Acked-by: Dave Airlie <airlied@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/1550338640-17470-10-git-send-email-ramalingam.c@intel.com
2019-02-20drm/i915: Implement HDCP2.2 repeater authenticationRamalingam C1-2/+123
Implements the HDCP2.2 repeaters authentication steps such as verifying the downstream topology and sending stream management information. v2: Rebased. v3: -EINVAL is returned for topology error and rollover scenario. Endianness conversion func from drm_hdcp.h is used [Uma] v4: Rebased as part of patches reordering. Defined the mei service functions [Daniel] v5: Redefined the mei service functions as per comp redesign. v6: %s/uintxx_t/uxx Check for comp_master is removed. v7: Adjust to the new mei interface. style issue fixed. v8: drm_hdcp.h change is moved into separate patch [Daniel] v9: %s/__swab16/cpu_to_be16. [Tomas] Reviewed-by Uma. Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/1550338640-17470-9-git-send-email-ramalingam.c@intel.com
2019-02-20drm/i915: Implement HDCP2.2 receiver authenticationRamalingam C2-15/+216
Implements HDCP2.2 authentication for hdcp2.2 receivers, with following steps: Authentication and Key exchange (AKE). Locality Check (LC). Session Key Exchange(SKE). DP Errata for stream type configuration for receivers. At AKE, the HDCP Receiver’s public key certificate is verified by the HDCP Transmitter. A Master Key k m is exchanged. At LC, the HDCP Transmitter enforces locality on the content by requiring that the Round Trip Time (RTT) between a pair of messages is not more than 20 ms. At SKE, The HDCP Transmitter exchanges Session Key ks with the HDCP Receiver. In DP HDCP2.2 encryption and decryption logics use the stream type as one of the parameter. So Before enabling the Encryption DP HDCP2.2 receiver needs to be communicated with stream type. This is added to spec as ERRATA. This generic implementation is complete only with the hdcp2 specific functions defined at hdcp_shim. v2: Rebased. v3: %s/PARING/PAIRING Coding style fixing [Uma] v4: Rebased as part of patch reordering. Defined the functions for mei services. [Daniel] v5: Redefined the mei service functions as per comp redesign. Required intel_hdcp members are defined [Sean Paul] v6: Typo of cipher is Fixed [Uma] %s/uintxx_t/uxx Check for comp_master is removed. v7: Adjust to the new interface. Avoid using bool structure members. [Tomas] v8: Rebased. v9: bool is used in struct intel_hdcp [Daniel] config_stream_type is redesigned [Daniel] Reviewed-by Uma. Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/1550338640-17470-8-git-send-email-ramalingam.c@intel.com
2019-02-20drm/i915: Enable and Disable of HDCP2.2Ramalingam C2-14/+205
Considering that HDCP2.2 is more secure than HDCP1.4, When a setup supports HDCP2.2 and HDCP1.4, HDCP2.2 will be enabled. When HDCP2.2 enabling fails and HDCP1.4 is supported, HDCP1.4 is enabled. This change implements a sequence of enabling and disabling of HDCP2.2 authentication and HDCP2.2 port encryption. v2: Included few optimization suggestions [Chris Wilson] Commit message is updated as per the rebased version. intel_wait_for_register is used instead of wait_for. [Chris Wilson] v3: Extra comment added and Style issue fixed [Uma] v4: Rebased as part of patch reordering. HDCP2 encryption status is tracked. HW state check is moved into WARN_ON [Daniel] v5: Redefined the mei service functions as per comp redesign. Merged patches related to hdcp2.2 enabling and disabling [Sean Paul]. Required shim functionality is defined [Sean Paul] v6: Return values are handles [Uma] Realigned the code. Check for comp_master is removed. v7: HDCP2.2 is attempted only if mei interface is up. Adjust to the new interface Avoid bool usage in struct [Tomas] v8: mei_binded status check is removed. %s/hdcp2_in_use/hdcp2_encrypted v9: bool is used in struct intel_hdcp. [Daniel] v10: panel is replaced with sink [Uma] Mei interface decided the hdcp2_capability. WARN_ON if hdcp_enable is called when hdcp state is ENABLED. Reviewed-by Uma. Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/1550338640-17470-7-git-send-email-ramalingam.c@intel.com
2019-02-20clk: at91: fix masterck nameAlexandre Belloni3-4/+4
The master clock is actually named masterck earlier in the driver. Having "mck" in the parent list means that it can never be selected. Fixes: 1eabdc2f9dd8 ("clk: at91: add at91sam9x5 PMCs driver") Fixes: a2038077de9a ("clk: at91: add sama5d2 PMC driver") Fixes: 084b696bb509 ("clk: at91: add sama5d4 pmc driver") Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com> Cc: <stable@vger.kernel.org> # v4.20+ Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2019-02-20drm/i915: hdcp1.4 CP_IRQ handling and SW encryption trackingRamalingam C3-22/+58
"hdcp_encrypted" flag is defined to denote the HDCP1.4 encryption status. This SW tracking is used to determine the need for real hdcp1.4 disable and hdcp_check_link upon CP_IRQ. On CP_IRQ we filter the CP_IRQ related to the states like Link failure and reauthentication req etc and handle them in hdcp_check_link. CP_IRQ corresponding to the authentication msg availability are ignored. WARN_ON is added for the abrupt stop of HDCP encryption of a port. v2: bool is used in struct for the cleaner coding. [Daniel] check_link work_fn is scheduled for cp_irq handling [Daniel] v3: rebased. Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/1550338640-17470-6-git-send-email-ramalingam.c@intel.com
2019-02-20drm/i915: MEI interface implementationRamalingam C6-1/+419
Defining the mei-i915 interface functions and initialization of the interface. v2: Adjust to the new interface changes. [Tomas] Added further debug logs for the failures at MEI i/f. port in hdcp_port data is equipped to handle -ve values. v3: mei comp is matched for global i915 comp master. [Daniel] In hdcp_shim hdcp_protocol() is replaced with const variable. [Daniel] mei wrappers are adjusted as per the i/f change [Daniel] v4: port initialization is done only at hdcp2_init only [Danvet] v5: I915 registers a subcomponent to be matched with mei_hdcp [Daniel] v6: HDCP_disable for all connectors incase of comp_unbind. Tear down HDCP comp interface at i915_unload [Daniel] v7: Component init and fini are moved out of connector ops [Daniel] hdcp_disable is not called from unbind. [Daniel] v8: subcomponent name is dropped as it is already merged. Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> [v11] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/1550338640-17470-5-git-send-email-ramalingam.c@intel.com
2019-02-20drm/i915: Initialize HDCP2.2Ramalingam C3-5/+40
Add the HDCP2.2 initialization to the existing HDCP1.4 stack. v2: mei interface handle is protected with mutex. [Chris Wilson] v3: Notifiers are used for the mei interface state. v4: Poll for mei client device state Error msg for out of mem [Uma] Inline req for init function removed [Uma] v5: Rebase as Part of reordering. Component is used for the I915 and MEI_HDCP interface [Daniel] v6: HDCP2.2 uses the I915 component master to communicate with mei_hdcp - [Daniel] Required HDCP2.2 variables defined [Sean Paul] v7: intel_hdcp2.2_init returns void [Uma] Realigning the codes. v8: Avoid using bool structure members. MEI interface related changes are moved into separate patch. Commit msg is updated accordingly. intel_hdcp_exit is defined and used from i915_unload v9: Movement of the hdcp_check_link is moved to new patch [Daniel] intel_hdcp2_exit is removed as mei_comp will be unbind in i915_unload. v10: bool is used in struct to make coding simpler. [Daniel] hdmi hdcp init is placed correctly after encoder attachment. v11: hdcp2_capability check is moved into hdcp.c [Tomas] Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/1550338640-17470-4-git-send-email-ramalingam.c@intel.com
2019-02-20drm/i915: Gathering the HDCP1.4 routines togetherRamalingam C1-59/+59
All HDCP1.4 routines are gathered together, followed by the generic functions those can be extended for HDCP2.2 too. Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Reviewed-by: Tomas Winkler <tomas.winkler@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/1550338640-17470-2-git-send-email-ramalingam.c@intel.com
2019-02-20clk: at91: fix at91sam9x5 peripheral clock numberAlexandre Belloni1-2/+1
nck() looks at the last id in an array and unfortunately, at91sam9x35_periphck has a sentinel, hence the id is 0 and the calculated number of peripheral clocks is 1 instead of a maximum of 31. Fixes: 1eabdc2f9dd8 ("clk: at91: add at91sam9x5 PMCs driver") Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com> Cc: <stable@vger.kernel.org> # v4.20+ Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2019-02-20net: dsa: fix unintended change of bridge interface STP stateRussell King1-3/+4
When a DSA port is added to a bridge and brought up, the resulting STP state programmed into the hardware depends on the order that these operations are performed. However, the Linux bridge code believes that the port is in disabled mode. If the DSA port is first added to a bridge and then brought up, it will be in blocking mode. If it is brought up and then added to the bridge, it will be in disabled mode. This difference is caused by DSA always setting the STP mode in dsa_port_enable() whether or not this port is part of a bridge. Since bridge always sets the STP state when the port is added, brought up or taken down, it is unnecessary for us to manipulate the STP state. Apparently, this code was copied from Rocker, and the very next day a similar fix for Rocker was merged but was not propagated to DSA. See e47172ab7e41 ("rocker: put port in FORWADING state after leaving bridge") Fixes: b73adef67765 ("net: dsa: integrate with SWITCHDEV for HW bridging") Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Vivien Didelot <vivien.didelot@gmail.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-02-20Merge tag 'sound-5.0' of ↵Linus Torvalds4-4/+56
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound Pull sound fixes from Takashi Iwai: "Here are a few last-minute fixes for 5.0. The most significant one is the OF-node refcount fix for ASoC simple-card, which could be triggered on many boards. Another fix for ASoC core is for the error handling in topology, while others are device-specific fixes for Samsung and HD-audio" * tag 'sound-5.0' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: ASoC: simple-card: fixup refcount_t underflow ASoC: topology: free created components in tplg load error ALSA: hda/realtek: Disable PC beep in passthrough on alc285 ALSA: hda/realtek - Headset microphone and internal speaker support for System76 oryp5 ASoC: samsung: i2s: Fix prescaler setting for the secondary DAI
2019-02-20Merge tag 'pinctrl-v5.0-3' of ↵Linus Torvalds2-2/+2
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl Pull pin control fixes from Linus Walleij: "Some final pin control fixes (I hope) to round off the v5.0 pin control development cycle. Only driver fixes, one for stable: - Meson8B fixup for the sdc pins - Fix SDC tile position for Qualcomm QCS404" * tag 'pinctrl-v5.0-3' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl: pinctrl: meson: meson8b: fix the sdxc_a data 1..3 pins pinctrl: qcom: qcs404: Correct SDC tile
2019-02-20Merge tag 'gpio-v5.0-4' of ↵Linus Torvalds2-10/+11
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio Pull GPIO fixes from Linus Walleij: "Two GPIO fixes for the v5.0 series: - Per-instance irqchip on the MT7621 - Avoid direction setting using pin control on MMP2" * tag 'gpio-v5.0-4' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio: gpio: pxa: avoid attempting to set pin direction via pinctrl on MMP2 gpio: MT7621: use a per instance irq_chip structure
2019-02-20Merge tag 'mtd/fixes-for-5.0-rc8' of git://git.infradead.org/linux-mtdLinus Torvalds2-1/+2
Pull MTD fixes from Boris Brezillon: - Don't add a digit to MTD-backed nvmem device names - Make sure powernv flash names are unique * tag 'mtd/fixes-for-5.0-rc8' of git://git.infradead.org/linux-mtd: mtd: powernv_flash: Fix device registration error mtd: Use mtd->name when registering nvmem device
2019-02-20Merge branch 'fixes-v5.1-rc6' of ↵Linus Torvalds10-97/+108
git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security Pull keys fixes from James Morris: - Handle quotas better, allowing full quota to be reached. - Fix the creation of shortcuts in the assoc_array internal representation when the index key needs to be an exact multiple of the machine word size. - Fix a dependency loop between the request_key contruction record and the request_key authentication key. The construction record isn't really necessary and can be dispensed with. - Set the timestamp on a new key rather than leaving it as 0. This would ordinarily be fine - provided the system clock is never set to a time before 1970 * 'fixes-v5.1-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security: keys: Timestamp new keys keys: Fix dependency loop between construction record and auth key assoc_array: Fix shortcut creation KEYS: allow reaching the keys quotas exactly
2019-02-20drm/i915: Avoid reset lock in writing fence registersChris Wilson1-10/+2
The idea of taking the reset lock around writing the fence register was to serialise the mmio write we also perform during the reset where those registers get clobbered. However, the lock is overkill as write tearing between reset and fence_update() is harmless; the final value of the fence register is the same. A race between revoke_fences() and fence_update() is also harmless at this point as on the fault path where this is necessary, we acquire the reset lock to coordinate ourselves in the upper layer. The danger of acquiring the reset lock again in fence_update() is that we may recurse from the shrinker along the i915_gem_fault() path. <4> [125.739646] ============================================ <4> [125.739652] WARNING: possible recursive locking detected <4> [125.739659] 5.0.0-rc6-ga6e4cbf00557-drmtip_223+ #1 Tainted: G U <4> [125.739666] -------------------------------------------- <4> [125.739672] gem_mmap_gtt/1017 is trying to acquire lock: <4> [125.739679] 00000000a730190a (&dev_priv->gpu_error.reset_backoff_srcu){+.+.}, at: i915_reset_trylock+0x0/0x310 [i915] <4> [125.739848] but task is already holding lock: <4> [125.739854] 00000000a730190a (&dev_priv->gpu_error.reset_backoff_srcu){+.+.}, at: i915_reset_trylock+0x192/0x310 [i915] <4> [125.739918] other info that might help us debug this: <4> [125.739925] Possible unsafe locking scenario: <4> [125.739930] CPU0 <4> [125.739934] ---- <4> [125.739937] lock(&dev_priv->gpu_error.reset_backoff_srcu); <4> [125.739944] lock(&dev_priv->gpu_error.reset_backoff_srcu); <4> [125.739950] *** DEADLOCK *** <4> [125.739958] May be due to missing lock nesting notation <4> [125.739966] 5 locks held by gem_mmap_gtt/1017: <4> [125.739972] #0: 00000000471f682c (&mm->mmap_sem){++++}, at: __do_page_fault+0x133/0x500 <4> [125.739987] #1: 0000000026542685 (&dev->struct_mutex){+.+.}, at: i915_gem_fault+0x1f6/0x860 [i915] <4> [125.740061] #2: 00000000a730190a (&dev_priv->gpu_error.reset_backoff_srcu){+.+.}, at: i915_reset_trylock+0x192/0x310 [i915] <4> [125.740126] #3: 00000000c828eb4f (fs_reclaim){+.+.}, at: fs_reclaim_acquire.part.25+0x0/0x30 <4> [125.740140] #4: 000000002d360d65 (shrinker_rwsem){++++}, at: shrink_slab+0x1cb/0x2c0 <4> [125.740151] stack backtrace: <4> [125.740159] CPU: 1 PID: 1017 Comm: gem_mmap_gtt Tainted: G U 5.0.0-rc6-ga6e4cbf00557-drmtip_223+ #1 <4> [125.740170] Hardware name: Dell Inc. OptiPlex 745 /0GW726, BIOS 2.3.1 05/21/2007 <4> [125.740180] Call Trace: <4> [125.740189] dump_stack+0x67/0x9b <4> [125.740199] __lock_acquire+0xc75/0x1b00 <4> [125.740209] ? arch_tlb_finish_mmu+0x2a/0xa0 <4> [125.740216] ? tlb_finish_mmu+0x1a/0x30 <4> [125.740222] ? zap_page_range_single+0xe2/0x130 <4> [125.740230] ? lock_acquire+0xa6/0x1c0 <4> [125.740237] lock_acquire+0xa6/0x1c0 <4> [125.740296] ? i915_clear_error_registers+0x280/0x280 [i915] <4> [125.740357] i915_reset_trylock+0x44/0x310 [i915] <4> [125.740417] ? i915_clear_error_registers+0x280/0x280 [i915] <4> [125.740426] ? lockdep_hardirqs_on+0xe0/0x1b0 <4> [125.740434] ? _raw_spin_unlock_irqrestore+0x39/0x60 <4> [125.740499] fence_update+0x218/0x470 [i915] <4> [125.740571] i915_vma_unbind+0xa6/0x550 [i915] <4> [125.740640] i915_gem_object_unbind+0xfa/0x190 [i915] <4> [125.740711] i915_gem_shrink+0x2dc/0x590 [i915] <4> [125.740722] ? ___preempt_schedule+0x16/0x18 <4> [125.740792] ? i915_gem_shrinker_scan+0xc9/0x130 [i915] <4> [125.740861] i915_gem_shrinker_scan+0xc9/0x130 [i915] <4> [125.740870] do_shrink_slab+0x143/0x3f0 <4> [125.740878] shrink_slab+0x228/0x2c0 <4> [125.740886] shrink_node+0x167/0x450 <4> [125.740894] do_try_to_free_pages+0xc4/0x340 <4> [125.740902] try_to_free_pages+0xdc/0x2e0 <4> [125.740911] __alloc_pages_nodemask+0x662/0x1110 <4> [125.740921] ? reacquire_held_locks+0xb5/0x1b0 <4> [125.740928] ? reacquire_held_locks+0xb5/0x1b0 <4> [125.740986] ? i915_reset_trylock+0x192/0x310 [i915] <4> [125.741045] ? i915_memcpy_init_early+0x30/0x30 [i915] <4> [125.741054] pte_alloc_one+0x12/0x70 <4> [125.741060] __pte_alloc+0x11/0xf0 <4> [125.741067] apply_to_page_range+0x37e/0x440 <4> [125.741127] remap_io_mapping+0x6c/0x100 [i915] <4> [125.741196] i915_gem_fault+0x5a9/0x860 [i915] <4> [125.741204] ? ptlock_alloc+0x15/0x30 <4> [125.741212] __do_fault+0x2c/0xb0 <4> [125.741218] __handle_mm_fault+0x8ee/0xfa0 <4> [125.741227] handle_mm_fault+0x196/0x3a0 <4> [125.741235] __do_page_fault+0x246/0x500 <4> [125.741243] ? page_fault+0x8/0x30 <4> [125.741250] page_fault+0x1e/0x30 <4> [125.741256] RIP: 0033:0x55d0cc456e12 <4> [125.741264] Code: b0 df ff ff 89 c2 8b 85 70 df ff ff 01 c2 8b 85 70 df ff ff 48 98 48 8d 0c 85 00 00 00 00 48 8b 85 e0 df ff ff 48 01 c8 f7 d2 <89> 10 83 85 70 df ff ff 01 81 bd 70 df ff ff ff 03 00 00 7e be 48 <4> [125.741280] RSP: 002b:00007ffc1bab7ab0 EFLAGS: 00010206 <4> [125.741287] RAX: 00007fc787cb6000 RBX: 0000000000000000 RCX: 0000000000000000 <4> [125.741295] RDX: 00000000ffffffff RSI: 0000000000005401 RDI: 0000000000000002 <4> [125.741303] RBP: 00007ffc1bab9b70 R08: 00007ffc1bab7920 R09: 000000000000001b <4> [125.741310] R10: 7165722074736554 R11: 0000000000000246 R12: 000055d0cc454a80 <4> [125.741318] R13: 00007ffc1bab9f60 R14: 0000000000000000 R15: 0000000000000000 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109665 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190219122215.8941-4-chris@chris-wilson.co.uk
2019-02-20drm/i915: Beware temporary wedging when determining -EIOChris Wilson19-52/+91
At a few points in our uABI, we check to see if the driver is wedged and report -EIO back to the user in that case. However, as we perform the check and reset asynchronously (where once before they were both serialised by the struct_mutex), we may instead see the temporary wedging used to cancel inflight rendering to avoid a deadlock during reset (caused by either us timing out in our reset handler, i915_wedge_on_timeout or with malice aforethought in intel_reset_prepare for a stuck modeset). If we suspect this is the case, that is we see a wedged driver *and* reset in progress, then wait until the reset is resolved before reporting upon the wedged status. v2: might_sleep() (Mika) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109580 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190220145637.23503-1-chris@chris-wilson.co.uk
2019-02-20ARM: tegra: Restore DT ABI on Tegra124 ChromebooksThierry Reding1-1/+16
Commit 482997699ef0 ("ARM: tegra: Fix unit_address_vs_reg DTC warnings for /memory") inadventently broke device tree ABI by adding a unit- address to the "/memory" node because the device tree compiler flagged the missing unit-address as a warning. Tegra124 Chromebooks (a.k.a. Nyan) use a bootloader that relies on the full name of the memory node in device tree being exactly "/memory". It can be argued whether this was a good decision or not, and some other bootloaders (such as U-Boot) do accept a unit-address in the name of the node, but the device tree is an ABI and we can't break existing setups just because the device tree compiler considers it bad practice to omit the unit-address nowadays. This partially reverts the offending commit and restores device tree ABI compatibility. Fixes: 482997699ef0 ("ARM: tegra: Fix unit_address_vs_reg DTC warnings for /memory") Reported-by: Tristan Bastian <tristan-c.bastian@gmx.de> Signed-off-by: Thierry Reding <treding@nvidia.com> Tested-by: Tristan Bastian <tristan-c.bastian@gmx.de> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2019-02-20arm64: Relax GIC version check during early bootVladimir Murzin1-2/+1
Updates to the GIC architecture allow ID_AA64PFR0_EL1.GIC to have values other than 0 or 1. At the moment, Linux is quite strict in the way it handles this field at early boot stage (cpufeature is fine) and will refuse to use the system register CPU interface if it doesn't find the value 1. Fixes: 021f653791ad17e03f98aaa7fb933816ae16f161 ("irqchip: gic-v3: Initial support for GICv3") Reported-by: Chase Conklin <Chase.Conklin@arm.com> Reviewed-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com>
2019-02-20drm/i915/fbdev: Actually configure untiled displaysChris Wilson1-5/+7
If we skipped all the connectors that were not part of a tile, we would leave conn_seq=0 and conn_configured=0, convincing ourselves that we had stagnated in our configuration attempts. Avoid this situation by starting conn_seq=ALL_CONNECTORS, and repeating until we find no more connectors to configure. Fixes: 754a76591b12 ("drm/i915/fbdev: Stop repeating tile configuration on stagnation") Reported-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190215123019.32283-1-chris@chris-wilson.co.uk Cc: <stable@vger.kernel.org> # v3.19+ (cherry picked from commit d9b308b1f8a1acc0c3279f443d4fe0f9f663252e) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2019-02-20drm/i915: Update DRIVER_DATE to 20190220Joonas Lahtinen1-2/+2
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2019-02-20Merge tag 'topic/mei-hdcp-2019-02-19' of ↵Joonas Lahtinen15-33/+493
git://anongit.freedesktop.org/drm/drm-intel into drm-intel-next-queued Prep patches + headers for the mei-hdcp/i915 component interfaces Also contains the prep work in the component helpers plus adjustements for the snd-hda/i915 component interface. Plus one small static inline in the drm_hdcp.h header that both i915 and mei_hdcp will need. Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> From: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20190219071619.GA11016@phenom.ffwll.local
2019-02-20Merge drm/drm-next into drm-intel-next-queuedJoonas Lahtinen2542-33141/+38008
Doing a backmerge to be able to merge topic/mei-hdcp-2019-02-19 PR. Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2019-02-20Merge https://gitlab.freedesktop.org/drm/msm into drm-nextDave Airlie29-873/+399
On the display side, cleanups and fixes to enabled modifiers (QCOM_COMPRESSED). And otherwise mostly misc fixes all around. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Rob Clark <robdclark@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/CAF6AEGuZ5uBKpf=fHvKpTiD10nychuEY8rnE+HeRz0QMvtY5_A@mail.gmail.com
2019-02-20Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/netLinus Torvalds41-244/+355
Pull networking fixes from David Miller: 1) Fix suspend and resume in mt76x0u USB driver, from Stanislaw Gruszka. 2) Missing memory barriers in xsk, from Magnus Karlsson. 3) rhashtable fixes in mac80211 from Herbert Xu. 4) 32-bit MIPS eBPF JIT fixes from Paul Burton. 5) Fix for_each_netdev_feature() on big endian, from Hauke Mehrtens. 6) GSO validation fixes from Willem de Bruijn. 7) Endianness fix for dwmac4 timestamp handling, from Alexandre Torgue. 8) More strict checks in tcp_v4_err(), from Eric Dumazet. 9) af_alg_release should NULL out the sk after the sock_put(), from Mao Wenan. 10) Missing unlock in mac80211 mesh error path, from Wei Yongjun. 11) Missing device put in hns driver, from Salil Mehta. * git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: (44 commits) sky2: Increase D3 delay again vhost: correctly check the return value of translate_desc() in log_used() net: netcp: Fix ethss driver probe issue net: hns: Fixes the missing put_device in positive leg for roce reset net: stmmac: Fix a race in EEE enable callback qed: Fix iWARP syn packet mac address validation. qed: Fix iWARP buffer size provided for syn packet processing. r8152: Add support for MAC address pass through on RTL8153-BD mac80211: mesh: fix missing unlock on error in table_path_del() net/mlx4_en: fix spelling mistake: "quiting" -> "quitting" net: crypto set sk to NULL when af_alg_release. net: Do not allocate page fragments that are not skb aligned mm: Use fixed constant in page_frag_alloc instead of size + 1 tcp: tcp_v4_err() should be more careful tcp: clear icsk_backoff in tcp_write_queue_purge() net: mv643xx_eth: disable clk on error path in mv643xx_eth_shared_probe() qmi_wwan: apply SET_DTR quirk to Sierra WP7607 net: stmmac: handle endianness in dwmac4_get_timestamp doc: Mention MSG_ZEROCOPY implementation for UDP mlxsw: __mlxsw_sp_port_headroom_set(): Fix a use of local variable ...
2019-02-20Merge branch 'linux-5.1' of git://github.com/skeggsb/linux into drm-nextDave Airlie134-1002/+4268
Various fixes/cleanups, along with initial support for SVM features utilising HMM address-space mirroring and device memory migration. There's a lot more work to do in these areas, both in terms of features and efficiency, but these can slowly trickle in later down the track. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Ben Skeggs <skeggsb@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/CACAvsv5bsB4rRY1Gqa_Bp_KAd-v_q1rGZ4nYmOAQhceL0Nr-Xg@mail.gmail.com
2019-02-20drm/nouveau/dmem: use dma addresses during migration copiesBen Skeggs1-106/+53
Removes the need for temporary VMM mappings. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2019-02-20drm/nouveau/dmem: use physical vram addresses during migration copiesBen Skeggs1-20/+4
Removes the need for temporary VMM mappings. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2019-02-20drm/nouveau/dmem: extend copy function to allow direct use of physical addressesBen Skeggs1-6/+50
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2019-02-20drm/nouveau/svm: new ioctl to migrate process memory to GPU memoryJérôme Glisse4-0/+147
This add an ioctl to migrate a range of process address space to the device memory. On platform without cache coherent bus (x86, ARM, ...) this means that CPU can not access that range directly, instead CPU will fault which will migrate the memory back to system memory. This is behind a staging flag so that we can evolve the API. Signed-off-by: Jérôme Glisse <jglisse@redhat.com>
2019-02-20drm/nouveau/dmem: device memory helpers for SVMJérôme Glisse7-0/+983
Device memory can be use in SVM, in which case we do not have any of the existing buffer object. This commit add infrastructure to allow use of device memory without nouveau_bo. Again this is a temporary solution until a rework of GPU memory management. Signed-off-by: Jérôme Glisse <jglisse@redhat.com>