- 02 11月, 2018 2 次提交
-
-
git://people.freedesktop.org/~agd5f/linux由 Dave Airlie 提交于
- Fix flickering at low backlight levels on some systems - Fix some overclocking regressions - Vega20 updates for - GPU recovery fixes - Disable gfxoff on RV as some sbios/fw combinations are not stable yet Signed-off-by: NDave Airlie <airlied@redhat.com> From: Alex Deucher <alexdeucher@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181101151939.2828-1-alexander.deucher@amd.com
-
由 Dave Airlie 提交于
Merge tag 'drm-misc-next-fixes-2018-10-31' of git://anongit.freedesktop.org/drm/drm-misc into drm-next - Properly label Innolux TV123WAM as P120ZDG-BF1 (Doug) - Add optional delay for panels without hpd hooked up (which solves the mystery delay for TI SN65DSI86 bridge) (Doug) - Another 6bpc quirk for BOE panel 0x0771 (Shawn) Cc: Doug Anderson <dianders@chromium.org> Cc: Lee, Shawn C <shawn.c.lee@intel.com> Signed-off-by: NDave Airlie <airlied@redhat.com> From: Sean Paul <sean@poorly.run> Link: https://patchwork.freedesktop.org/patch/msgid/20181031201944.GA262020@art_vandelay
-
- 01 11月, 2018 6 次提交
-
-
由 Christian König 提交于
This is still completely breaking my Raven system. This reverts commit cdf2f910fa969adca1b0e3ad2b487821233dc038. Revert until we sort out the sbios and firmware combinations that work correctly. bug: https://bugs.freedesktop.org/show_bug.cgi?id=108606 Cc: stable@vger.kernel.org # v4.19 Reviewed-by: NAlex Deucher <alexander.deucher@amd.com> Signed-off-by: NChristian König <christian.koenig@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Rex Zhu 提交于
print warning in dmesg to notify user the setting for sclk_od/mclk_od out of range that vbios can support Reviewed-by: NAlex Deucher <alexander.deucher@amd.com> Signed-off-by: NRex Zhu <Rex.Zhu@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Rex Zhu 提交于
not update dpm table with user's setting. Reviewed-by: NAlex Deucher <alexander.deucher@amd.com> Signed-off-by: NRex Zhu <Rex.Zhu@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Rex Zhu 提交于
not update the dpm table with user's setting Acked-by: NAlex Deucher <alexander.deucher@amd.com> Signed-off-by: NRex Zhu <Rex.Zhu@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Evan Quan 提交于
As MGPU fan boost feature will be definitely not needed when DPM is disabled. So, there is no need to error out. Signed-off-by: NEvan Quan <evan.quan@amd.com> Reviewed-by: NAlex Deucher <alexander.deucher@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Andrey Grodzovsky 提交于
Problem: During GPU recover DAL would hang in amdgpu_pm_compute_clocks->amdgpu_fence_wait_empty Fix: Turns out there was a typo introduced by 3320b8d2 drm/amdgpu: remove job->ring which caused skipping amdgpu_fence_driver_force_completion and so the hangged job was never force signaled and this would cause the hang later in DAL. Signed-off-by: NAndrey Grodzovsky <andrey.grodzovsky@amd.com> Reviewed-by: NChristian König <christian.koenig@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
- 31 10月, 2018 2 次提交
-
-
由 Evan Quan 提交于
Tell the version numbers when the pptable versions do not match. Signed-off-by: NEvan Quan <evan.quan@amd.com> Reviewed-by: NAlex Deucher <alexander.deucher@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Guttula, Suresh 提交于
This patch will work as workaround for silicon limitation related to PWM dutycycle when the backlight level goes to 0. Actually PWM value is 16 bit value and valid range from 1-65535. when ever user requested to set this PWM value to 0 which is not fall in the range, in VBIOS taken care this by limiting to 1. This patch here will do the same. Either driver or VBIOS can not pass 0 value as it is not a valid range for PWM and it will give a high PWM pulse which is not the intended behaviour as per HW constraints. Signed-off-by: Nsuresh guttula <suresh.guttula@amd.com> Reviewed-by: NHarry Wentland <harry.wentland@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
- 29 10月, 2018 7 次提交
-
-
由 Douglas Anderson 提交于
As far as I can tell the panel that was added in commit da50bd42 ("drm/panel: simple: Add Innolux TV123WAM panel driver support") wasn't actually an Innolux TV123WAM but was actually an Innolux P120ZDG-BF1. As far as I can tell the Innolux TV123WAM isn't a real panel and but it's a mosh between the TI TV123WAM and the Innolux P120ZDG-BF1. Let's unmosh. Here's my evidence: * Searching for TV123WAM on the Internet turns up a TI panel. While it's possible that an Innolux panel has the same model number as the TI Panel, it seems a little doubtful. Looking up the datasheet from the TI Panel shows that it's 1920 x 1280 and 259.2 mm x 172.8 mm. * As far as I know, the patch adding the Innolux Panel was supposed to be for the board that's sitting in front of me as I type this (support for that board is not yet upstream). On the back of that panel I see Innolux P120ZDZ-EZ1 rev B1. * Someone pointed me at a datasheet that's supposed to be for the panel in front of me (sorry, I can't share the datasheet). That datasheet has the string "p120zdg-bf1" * If I search for "P120ZDG-BF1" on the Internet I get hits for panels that are 2160x1440. They don't have datasheets, but the fact that the resolution matches is a good sign. In any case, let's update the name and also the physical size to match the correct panel. Fixes: da50bd42 ("drm/panel: simple: Add Innolux TV123WAM panel driver support") Cc: Sandeep Panda <spanda@codeaurora.org> Reviewed-by: NAbhinav Kumar <abhinavk@codeaurora.org> Reviewed-by: NSean Paul <sean@poorly.run> Signed-off-by: NDouglas Anderson <dianders@chromium.org> Signed-off-by: NSean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20181025222134.174583-6-dianders@chromium.org
-
由 Douglas Anderson 提交于
As far as I can tell the bindings that were added in commit 9c04400f ("dt-bindings: drm/panel: Document Innolux TV123WAM panel bindings") weren't actually for Innolux TV123WAM but were actually for Innolux P120ZDG-BF1. As far as I can tell the Innolux TV123WAM isn't a real panel and but it's a mosh between the TI TV123WAM and the Innolux P120ZDG-BF1. Let's unmosh. Here's my evidence: * Searching for TV123WAM on the Internet turns up a TI panel. While it's possible that an Innolux panel has the same model number as the TI Panel, it seems a little doubtful. Looking up the datasheet from the TI Panel shows that it's 1920 x 1280 and 259.2 mm x 172.8 mm. * As far as I know, the patch adding the Innolux Panel was supposed to be for the board that's sitting in front of me as I type this (support for that board is not yet upstream). On the back of that panel I see Innolux P120ZDZ-EZ1 rev B1. * Someone pointed me at a datasheet that's supposed to be for the panel in front of me (sorry, I can't share the datasheet). That datasheet has the string "p120zdg-bf1" * If I search for "P120ZDG-BF1" on the Internet I get hits for panels that are 2160x1440. They don't have datasheets, but the fact that the resolution matches is a good sign. While we doing the rename, also mention that no-hpd can be used with this panel. See the previous patch in this series ("drm/panel: simple: Add "no-hpd" delay for Innolux TV123WAM"). Fixes: 9c04400f ("dt-bindings: drm/panel: Document Innolux TV123WAM panel bindings") Cc: Sandeep Panda <spanda@codeaurora.org> Reviewed-by: NRob Herring <robh@kernel.org> Reviewed-by: NAndrzej Hajda <a.hajda@samsung.com> Signed-off-by: NDouglas Anderson <dianders@chromium.org> Signed-off-by: NSean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20181025222134.174583-5-dianders@chromium.org
-
由 Douglas Anderson 提交于
Let's solve the mystery of commit bf1178c9 ("drm/bridge: ti-sn65dsi86: Add mystery delay to enable()"). Specifically the reason we needed that mystery delay is that we weren't paying attention to HPD. Looking at the datasheet for the same panel that was tested for the original commit, I see there's a timing "t3" that times from power on to the aux channel being operational. This time is specced as 0 - 200 ms. The datasheet says that the aux channel is operational at exactly the same time that HPD is asserted. Scoping the signals on this board showed that HPD was asserted 84 ms after power was asserted. That very closely matches the magic 70 ms delay that we had. ...and actually, in my testing the 70 ms wasn't quite enough of a delay and some percentage of the time the display didn't come up until I bumped it to 100 ms (presumably 84 ms would have worked too). To solve this, we tried to hook up the HPD signal in the bridge. ...but in doing so we found that that the bridge didn't report that HPD was asserted until ~280 ms after we powered it (!). This is explained by looking at the sn65dsi86 datasheet section "8.4.5.1 HPD (Hot Plug/Unplug Detection)". Reading there we see that the bridge isn't even intended to report HPD until 100 ms after it's asserted. ...but that would have left us at 184 ms. The extra 100 ms (presumably) comes from this part in the datasheet: > The HPD state machine operates off an internal ring oscillator. The > ring oscillator frequency will vary [ ... ]. The min/max range in > the HPD State Diagram refers to the possible times based off > variation in the ring oscillator frequency. Given that the 280 ms we'll end up delaying if we hook up HPD is _slower_ than the 200 ms we could just hardcode, for now we'll solve the problem by just hardcoding a 200 ms delay in the panel driver using the patch in this series ("drm/panel: simple: Support panels with HPD where HPD isn't connected"). If we later find a panel that needs to use this bridge where we need HPD then we'll have to come up with some new code to handle it. Given the silly debouncing in the bridge chip, though, it seems unlikely. One last note is that I tried to solve this through another way: In ti_sn_bridge_enable() I tried to use various combinations of dp_dpcd_writeb() and dp_dpcd_readb() to detect when the aux channel was up. In theory that would let me detect _exactly_ when I could continue and do link training. Unfortunately even if I did an aux transfer w/out waiting I couldn't see any errors. Possibly I could keep looping over link training until it came back with success, but that seemed a little overly hacky to me. Reviewed-by: NSean Paul <sean@poorly.run> Reviewed-by: NAndrzej Hajda <a.hajda@samsung.com> Signed-off-by: NDouglas Anderson <dianders@chromium.org> Signed-off-by: NSean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20181025222134.174583-4-dianders@chromium.org
-
由 Douglas Anderson 提交于
If the HPD signal isn't hooked up to this panel we need a 200 ms delay. In the datasheet this is shown as the maximum time that HPD will take to be asserted after power is given to the panel. Reviewed-by: NSean Paul <sean@poorly.run> Signed-off-by: NDouglas Anderson <dianders@chromium.org> Signed-off-by: NSean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20181025222134.174583-3-dianders@chromium.org
-
由 Douglas Anderson 提交于
Some eDP panels that are designed to be always connected to a board use their HPD signal to signal that they've finished powering on and they're ready to be talked to. However, for various reasons it's possible that the HPD signal from the panel isn't actually hooked up. In the case where the HPD isn't hooked up you can look at the timing diagram on the panel datasheet and insert a delay for the maximum amount of time that the HPD might take to come up. Let's add support in simple-panel for this concept. At the moment we will co-opt the existing "prepare" delay to keep track of the delay and we'll use a boolean to specify that a given panel should only apply the delay if the "no-hpd" property was specified. Reviewed-by: NSean Paul <sean@poorly.run> Signed-off-by: NDouglas Anderson <dianders@chromium.org> Signed-off-by: NSean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20181025222134.174583-2-dianders@chromium.org
-
由 Douglas Anderson 提交于
Some eDP panels that are designed to be always connected to a board use their HPD signal to signal that they've finished powering on and they're ready to be talked to. However, for various reasons it's possible that the HPD signal from the panel isn't actually hooked up. In the case where the HPD isn't hooked up you can look at the timing diagram on the panel datasheet and insert a delay for the maximum amount of time that the HPD might take to come up. Let's add a property in the device tree for this concept. Reviewed-by: NSean Paul <sean@poorly.run> Reviewed-by: NRob Herring <robh@kernel.org> Signed-off-by: NDouglas Anderson <dianders@chromium.org> Signed-off-by: NSean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20181025222134.174583-1-dianders@chromium.org
-
由 Lee, Shawn C 提交于
BOE panel (ID: 0x0771) that reports "DFP 1.x compliant TMDS". But it's 6bpc panel only instead of 8 bpc. Add panel ID to edid quirk list and set 6 bpc as default to work around this issue. Cc: Jani Nikula <jani.nikula@intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Gustavo Padovan <gustavo@padovan.org> Cc: Cooper Chiou <cooper.chiou@intel.com> Signed-off-by: NLee, Shawn C <shawn.c.lee@intel.com>> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/1540792173-7288-1-git-send-email-shawn.c.lee@intel.com
-
- 27 10月, 2018 3 次提交
-
-
由 Shirish S 提交于
Currently send_msg_to_smc_async() only report which message failed, but the actual failing message is the previous one, which SMU is unable to service. This patch reads the contents of register where the SMU is stuck and report appropriately. v2: fix the build (Alex) Signed-off-by: NShirish S <shirish.s@amd.com> Reviewed-by: NRex Zhu <Rex.Zhu@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Andrey Grodzovsky 提交于
Problem: After GPU reset on dGPUs with gfx8 compute ring 1.0.0 fails to pass the ring test. Ring registers inspection shows that it's active and no hang is observed (rptr == wptr) No significant diffs were observed between CP_HQD* registers for the ring in good and bad shape. Fix: No clear reason why but reversing the order of ring tests fixes the problem. Signed-off-by: NAndrey Grodzovsky <andrey.grodzovsky@amd.com> Acked-by: NChristian König <christian.koenig@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Christian König 提交于
Make sure we don't try to go down further after the leave walk already ended. This fixes a crash with a new VM test. Signed-off-by: NChristian König <christian.koenig@amd.com> Reviewed-by: NFelix Kuehling <Felix.Kuehling@amd.com> Acked-by: NAlex Deucher <alexander.deucher@amd.com> Tested-by: Rex Zhu Rex.Zhu@amd.com Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
- 26 10月, 2018 3 次提交
-
-
由 Christian König 提交于
We should not remove mappings in rbtree_postorder_for_each_entry_safe because that rebalances the tree. Signed-off-by: NChristian König <christian.koenig@amd.com> Reviewed-by: NChunming Zhou <david1.zhou@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Evan Quan 提交于
So that it can be shared between all clocks. Signed-off-by: NEvan Quan <evan.quan@amd.com> Reviewed-by: Feifei Xu<Feifei.Xu@amd.com> Reviewed-by: NRex Zhu <Rex.Zhu@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Evan Quan 提交于
Currently the clocks reported are in 10Khz unit. Correct them as Khz unit as DAL wanted. Signed-off-by: NEvan Quan <evan.quan@amd.com> Reviewed-by: Feifei Xu<Feifei.Xu@amd.com> Reviewed-by: NRex Zhu <Rex.Zhu@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
- 25 10月, 2018 4 次提交
-
-
由 David Francis 提交于
[Why] Carrizo and Stoney have severe corruption when trying to power 4k 60 monitors over HDMI connectors that support 4k 60. Carrizo and Stoney require retimers and redrivers to support 4k 60 over HDMI. This driver does not currently support these. Thus, 4k 60 HDMI (and all other modes requiring over 300MHz) should be disabled. [How] Reduce the dce11 HDMI pixel clock cap to 300000kHz. Signed-off-by: NDavid Francis <David.Francis@amd.com> Reviewed-by: NRoman Li <Roman.Li@amd.com> Acked-by: NBhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Rex Zhu 提交于
need to check adev->powerplay.pp_funcs first, becasue from AI, the smu ip can be disabled by user, and the pp_handle is null in this case. Reviewed-by: NAlex Deucher <alexander.deucher@amd.com> Signed-off-by: NRex Zhu <Rex.Zhu@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Rex Zhu 提交于
from AI, SMU Ip is not indispensable to driver and can be disabled by user via module parameter ip_block_mask. so the pp_handle may be NULL. Reviewed-by: NAlex Deucher <alexander.deucher@amd.com> Signed-off-by: NRex Zhu <Rex.Zhu@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Evan Quan 提交于
This can suppress the error reported on driver loading. Also these are empty APIs as Vega12/Vega20 has no performance levels. Signed-off-by: NEvan Quan <evan.quan@amd.com> Reviewed-by: NFeifei Xu <Feifei.Xu@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
- 23 10月, 2018 6 次提交
-
-
由 Evan Quan 提交于
As the matching VBIOS is already ready. Also drop the temporary workarounds applied before. Signed-off-by: NEvan Quan <evan.quan@amd.com> Reviewed-by: NFeifei Xu <Feifei.Xu@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Evan Quan 提交于
The UCLK is forced to highest at the start of display configuration change. Downgrade the UCLK from highest after display configuration change. Otherwise, we may see the UCLK stuck in the highest in some cases. Signed-off-by: NEvan Quan <evan.quan@amd.com> Acked-by: NAlex Deucher <alexander.deucher@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Joseph Greathouse 提交于
OverDrive mode allows users to increase the maximum SCLK and MCLK frequencies beyond the default on the GPU. However, this may not results in large performance gains if the GPU then runs into its TDP power limit. This patch adds the capability to increase the power limit of a GPU above its default maximum. This is only allowed when overdrive is enabled in the ppfeaturemask, since this is an overdrive feature. The TDPODLimit value from the VBIOS describes how how much higher the TDP should be allowed to go over its default, in percentage. v2: Moved dereference of hwmgr to after its validity check Signed-off-by: NJoseph Greathouse <Joseph.Greathouse@amd.com> Reviewed-by: NAlex Deucher <alexander.deucher@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 David Francis 提交于
In a refactor, the watermark clock inputs to powerplay from DC were changed from units of 10kHz to kHz clocks. One division by 100 was not converted into a division by 1000. Signed-off-by: NDavid Francis <David.Francis@amd.com> Reviewed-by: NHarry Wentland <harry.wentland@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Emily Deng 提交于
Need to check adev->powerplay.pp_funcs. Signed-off-by: NEmily Deng <Emily.Deng@amd.com> Reviewed-by: NHuang Rui <ray.huang@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Evan Quan 提交于
Forcing clock level is supported under manual dpm mode only. Error out when trying to set under manual mode. Instead of doing nothing and reporting success. V2: update for mclk/pcie clock level settings also Signed-off-by: NEvan Quan <evan.quan@amd.com> Reviewed-by: NAlex Deucher <alexander.deucher@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
- 19 10月, 2018 1 次提交
-
-
由 Dave Airlie 提交于
Merge tag 'drm-intel-next-fixes-2018-10-18' of git://anongit.freedesktop.org/drm/drm-intel into drm-next - Fix GPU hang on MacBook2,1 when booting in EFI mode (Bugzilla #105637) - Fix garbled console on Y tiled BIOS framebuffer configs (Bugzilla #108264) - Fix black screen on certain eDP panels eg. Dell XPS 9350 (Bugzilla #107489 and #105338) - MST fixes that Rodrigo dropped from drm-intel-fixes and bunch of Icelake fixes - Then assorted proactive code fixes caught by CI or developers Signed-off-by: NDave Airlie <airlied@redhat.com> From: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181018165725.GA2281@jlahtine-desk.ger.corp.intel.com
-
- 18 10月, 2018 6 次提交
-
-
由 Anusha Srivatsa 提交于
Add missing MODULE_FIRMWARE while loading DMC ICL. v2: Add Fixes tag. (Rodrigo) v3: Rebase by Rodrigo after commit 7fe78985 ("drm/i915/csr: restructure CSR firmware definition macros") v4: Rodrigo fixing his own mess on commit mentioning on v3 comment above. Fixes: 4445930f ("firmware/dmc/icl: load v1.07 on icelake.") Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: NAnusha Srivatsa <anusha.srivatsa@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> (v2) Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Tested-by: NPaulo Zanoni <paulo.r.zanoni@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181004223613.19938-1-rodrigo.vivi@intel.com (cherry picked from commit 00e5d8b1) Signed-off-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
-
由 Rodrigo Vivi 提交于
Since when it was introduced we forgot to add this case so ICL was using a wrong signal_levels as reference. Fixes: fb5c8e9d ("drm/i915/icl: Implement voltage swing programming sequence for Combo PHY DDI") Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: NManasi Navare <manasi.d.navare@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181017215652.26841-1-rodrigo.vivi@intel.com (cherry picked from commit 61cdfb9e) Signed-off-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
-
由 Mahesh Kumar 提交于
DDI/TC clock-off bits are not equally distanced. TC1-3 bits are from offset 12 & TC4 is at offset 21. Create a function to choose correct clk-off bit. v2: Add fixes tag (Lucas) Fixes: c27e917e ("drm/i915/icl: add basic support for the ICL clocks") Signed-off-by: NMahesh Kumar <mahesh1.kumar@intel.com> Signed-off-by: NVandita Kulkarni <vandita.kulkarni@intel.com> Reviewed-by: NLucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181016023752.9285-1-lucas.demarchi@intel.com (cherry picked from commit bb1c7edc) Signed-off-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
-
由 Mahesh Kumar 提交于
This patch creates a function/wrapper to check if port is combophy port instead of explicitly comparing ports. Changes since V1: - keep all intel_port_is_* helper together (Lucas) Signed-off-by: NMahesh Kumar <mahesh1.kumar@intel.com> Cc: Madhav Chauhan <madhav.chauhan@intel.com> Cc: Manasi Navare <manasi.d.navare@intel.com> Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: NLucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181004085043.10154-1-mahesh1.kumar@intel.com (cherry picked from commit 176597a1) Signed-off-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
-
git://people.freedesktop.org/~agd5f/linux由 Dave Airlie 提交于
Fixes for 4.20. Highlights: - VCN DPG fixes for Picasso - Add support for the latest vega20 vbios - Scheduler timeout fix - License fixes for radeon and amdgpu - Misc other fixes Signed-off-by: NDave Airlie <airlied@redhat.com> From: Alex Deucher <alexdeucher@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181017215427.2804-1-alexander.deucher@amd.com
-
由 Dave Airlie 提交于
Merge tag 'drm-misc-next-fixes-2018-10-17' of git://anongit.freedesktop.org/drm/drm-misc into drm-next - Add quirk to fix orientation of Acer One 10 (S1003) panel (Hans) Cc: Hans de Goede <hdegoede@redhat.com> Signed-off-by: NDave Airlie <airlied@redhat.com> From: Sean Paul <sean@poorly.run> Link: https://patchwork.freedesktop.org/patch/msgid/20181017200741.GA240649@art_vandelay
-