- 27 Sep, 2018 15 commits
-
-
Leo Li authored
[Why] The work struct's schedule call was removed a while ago, making this useless. [How] Remove it. Signed-off-by:
Leo Li <sunpeng.li@amd.com> Reviewed-by:
David Francis <David.Francis@amd.com> Acked-by:
Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com>
-
Nicholas Kazlauskas authored
[Why] During suspend under some hardware configurations can result in a series of atomic commits with a NULL stream status - which causes a NULL pointer dereference. This should be guarded. [How] Exit early from the function - if we can't access the stream then there isn't anything that can be done here. Signed-off-by:
Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Reviewed-by:
Harry Wentland <Harry.Wentland@amd.com> Acked-by:
-
Eric Bernstein authored
[Why] Need to add strere 3D information in VSC [How] Update mod_build_vsc_infopacket with stereo info Signed-off-by:
Eric Bernstein <eric.bernstein@amd.com> Reviewed-by:
Charlene Liu <Charlene.Liu@amd.com> Acked-by:
-
Tony Cheng authored
Signed-off-by:
Tony Cheng <tony.cheng@amd.com> Reviewed-by:
Steven Chiu <Steven.Chiu@amd.com> Acked-by:
-
Su Sung Chung authored
[WHY] There are two different variables used to calculate v_update and v_ready, one for validation and the other for performance parameter calculation. Before the variable for validation was used which caused underflow on 1080edp with vsr enabled [HOW] program v_update and v_ready with the variables for performance parameter calculation Signed-off-by:
Su Sung Chung <su.chung@amd.com> Reviewed-by:
Dmytro Laktyushkin <Dmytro.Laktyushkin@amd.com> Acked-by:
-
SivapiriyanKumarasamy authored
Parse the native color bit and send it to freesync module for future use Signed-off-by:
SivapiriyanKumarasamy <sivapiriyan.kumarasamy@amd.com> Reviewed-by:
Anthony Koo <Anthony.Koo@amd.com> Acked-by:
-
Charlene Liu authored
add pp_smu NULL ptr check Signed-off-by:
-
Samson Tam authored
Use link->link_index as index to pipe_ctx[] to get proper link information instead of using index 0 to avoid potential miss matches. Signed-off-by:
Samson Tam <Samson.Tam@amd.com> Reviewed-by:
-
Nikola Cornij authored
FPGA doesn't program backend, so we don't need certain link settings (audio stream for example). Signed-off-by:
Nikola Cornij <nikola.cornij@amd.com> Reviewed-by:
-
Rex Zhu authored
this can avoid hard hang and be useful for debug. Reviewed-by:
Rex Zhu <Rex.Zhu@amd.com> Signed-off-by:
-
Rex Zhu authored
Honour display's request for min engine clock/memory clock. Reviewed-by:
-
Rex Zhu authored
Revert "drm/amd/display: Remove call to amdgpu_pm_compute_clocks" This reverts commit dcd473770e86517543691bdb227103d6c781cd0a. when display configuration changes, dc need to update the changes to powerplay, also need to trigger a power state task. amdgpu_pm_compute_clocks is the interface to set power state task either dpm enabled or powerplay enabled Acked-by:
-
Dave Airlie authored
Sean Paul requested an -rc5 backmerge from some sun4i fixes. Signed-off-by:Dave Airlie <airlied@redhat.com>
-
Dave Airlie authored
- A crash fix founded in recent linux-next from John Garry - One sparse warning fix from Souptick Joarder - Some xxx_unref cleanup from Thomas Zimmermann Signed-off-by:
-
git://linuxtv.org/pinchartl/mediaDave Airlie authored
R-Car DU support for the D3 and E3 SoCs (v4.20) Signed-off-by:
-
- 26 Sep, 2018 6 commits
-
-
Thomas Zimmermann authored
The function ttm_bo_put releases a reference to a TTM buffer object. The function's name is more aligned to the Linux kernel convention of naming ref-counting function _get and _put. A call to ttm_bo_unref takes the address of the TTM BO object's pointer and clears the pointer's value to NULL. This is not necessary in most cases and sometimes even worked around by the calling code. A call to ttm_bo_put only releases the reference without clearing the pointer. The current behaviour of cleaning the pointer is kept in the calling code, but should be removed if not required in a later patch. Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by:
Xinliang Liu <z.liuxinliang@hisilicon.com> Signed-off-by:
-
Thomas Zimmermann authored
This patch unifies the naming of DRM functions for reference counting of struct drm_device. The resulting code is more aligned with the rest of the Linux kernel interfaces. Signed-off-by:
-
Souptick Joarder authored
convert drm_atomic_helper_suspend/resume() to use drm_mode_config_helper_suspend/resume(). Fixed one sparse warning by making hibmc_drm_interrupt static. Signed-off-by:
Ajit Negi <ajitn.linux@gmail.com> Signed-off-by:
Souptick Joarder <jrdr.linux@gmail.com> Reviewed-by:
-
John Garry authored
Switch to use Huawei PCI vendor ID macro from pci_ids.h file. In addition, switch to use PCI_VDEVICE() instead of open coding. Signed-off-by:
John Garry <john.garry@huawei.com> Reviewed-by:
-
John Garry authored
Currently the driver overwrites the surface depth provided by the fb helper to give an invalid bpp/surface depth combination. This has been exposed by commit 70109354 ("drm: Reject unknown legacy bpp and depth for drm_mode_addfb ioctl"), which now causes the driver to fail to probe. Fix by not overwriting the surface depth. Fixes: d1667b86 ("drm/hisilicon/hibmc: Add support for frame buffer") Signed-off-by:
-
John Garry authored
In hibmc_drm_fb_create(), when the call to hibmc_framebuffer_init() fails with error, do not store the error code in the HiBMC device frame-buffer pointer, as this will be later checked for non-zero value in hibmc_fbdev_destroy() when our intention is to check for a valid function pointer. This fixes the following crash: [ 9.699791] Unable to handle kernel NULL pointer dereference at virtual address 000000000000001a [ 9.708672] Mem abort info: [ 9.711489] ESR = 0x96000004 [ 9.714570] Exception class = DABT (current EL), IL = 32 bits [ 9.720551] SET = 0, FnV = 0 [ 9.723631] EA = 0, S1PTW = 0 [ 9.726799] Data abort info: [ 9.729702] ISV = 0, ISS = 0x00000004 [ 9.733573] CM = 0, WnR = 0 [ 9.736566] [000000000000001a] user address but active_mm is swapper [ 9.742987] Internal error: Oops: 96000004 [#1] PREEMPT SMP [ 9.748614] Modules linked in: [ 9.751694] CPU: 16 PID: 293 Comm: kworker/16:1 Tainted: G W 4.19.0-rc4-next-20180920-00001-g9b0012c #322 [ 9.762681] Hardware name: Huawei Taishan 2280 /D05, BIOS Hisilicon D05 IT21 Nemo 2.0 RC0 04/18/2018 [ 9.771915] Workqueue: events work_for_cpu_fn [ 9.776312] pstate: 60000005 (nZCv daif -PAN -UAO) [ 9.781150] pc : drm_mode_object_put+0x0/0x20 [ 9.785547] lr : hibmc_fbdev_fini+0x40/0x58 [ 9.789767] sp : ffff00000af1bcf0 [ 9.793108] x29: ffff00000af1bcf0 x28: 0000000000000000 [ 9.798473] x27: 0000000000000000 x26: ffff000008f66630 [ 9.803838] x25: 0000000000000000 x24: ffff0000095abb98 [ 9.809203] x23: ffff8017db92fe00 x22: ffff8017d2b13000 [ 9.814568] x21: ffffffffffffffea x20: ffff8017d2f80018 [ 9.819933] x19: ffff8017d28a0018 x18: ffffffffffffffff [ 9.825297] x17: 0000000000000000 x16: 0000000000000000 [ 9.830662] x15: ffff0000092296c8 x14: ffff00008939970f [ 9.836026] x13: ffff00000939971d x12: ffff000009229940 [ 9.841391] x11: ffff0000085f8fc0 x10: ffff00000af1b9a0 [ 9.846756] x9 : 000000000000000d x8 : 6620657a696c6169 [ 9.852121] x7 : ffff8017d3340580 x6 : ffff8017d4168000 [ 9.857486] x5 : 0000000000000000 x4 : ffff8017db92fb20 [ 9.862850] x3 : 0000000000002690 x2 : ffff8017d3340480 [ 9.868214] x1 : 0000000000000028 x0 : 0000000000000002 [ 9.873580] Process kworker/16:1 (pid: 293, stack limit = 0x(____ptrval____)) [ 9.880788] Call trace: [ 9.883252] drm_mode_object_put+0x0/0x20 [ 9.887297] hibmc_unload+0x1c/0x80 [ 9.890815] hibmc_pci_probe+0x170/0x3c8 [ 9.894773] local_pci_probe+0x3c/0xb0 [ 9.898555] work_for_cpu_fn+0x18/0x28 [ 9.902337] process_one_work+0x1e0/0x318 [ 9.906382] worker_thread+0x228/0x450 [ 9.910164] kthread+0x128/0x130 [ 9.913418] ret_from_fork+0x10/0x18 [ 9.917024] Code: a94153f3 a8c27bfd d65f03c0 d503201f (f9400c01) [ 9.923180] ---[ end trace 2695ffa0af5be375 ]--- Fixes: d1667b86 ("drm/hisilicon/hibmc: Add support for frame buffer") Signed-off-by:
-
- 24 Sep, 2018 11 commits
-
-
Ulrich Hecht authored
Add support for the R-Car D3 (R8A77995) and E3 (R8A77990) SoCs to the R-Car DU driver. The two SoCs instantiate compatible DUs, so a single information structure is enough. Signed-off-by:
Ulrich Hecht <uli+renesas@fpond.eu> [Add support for R8A77990] Signed-off-by:
Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Tested-by:
Jacopo Mondi <jacopo+renesas@jmondi.org> Reviewed-by:
Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
-
Laurent Pinchart authored
The official way to stop the display is to clear the display enable (DEN) bit in the DSYSR register, but that operates at a group level and affects the two channels in the group. To disable channels selectively, the driver uses TV sync mode that stops display operation on the channel and turns output signals into inputs. While TV sync mode is available in all DU models currently supported, the D3 and E3 DUs don't support it. We will thus need to find an alternative way to turn channels off. In the meantime, condition the switch to TV sync mode to the availability of the feature, to avoid writing an invalid value to the DSYSR register. When the feature is unavailable the display output will turn blank as all planes are disabled when stopping the CRTC. Signed-off-by:
-
Laurent Pinchart authored
DSYSR is a DU channel register that also contains group fields. It is thus written to by both the group and CRTC code, using read-update-write sequences. As the register isn't initialized explicitly at startup time, this can lead to invalid or otherwise unexpected values being written to some of the fields if they have been modified by the firmware or just not reset properly. To fix this we can write a fully known value to the DSYSR register when turning a channel's functional clock on. However, the mix of group and channel fields complicate this. A simpler solution is to cache the register and initialize the cached value to the desired hardware defaults. Signed-off-by:
-
Laurent Pinchart authored
All Gen3 SoCs supported so far have a fixed association between DPAD0 and DU channels, which led to hardcoding that association when writing the corresponding hardware register. The D3 and E3 will break that mechanism as DPAD0 can be dynamically connected to either DU0 or DU1. Make DPAD0 routing dynamic on Gen3. To ensure a valid hardware configuration when the DU starts without the RGB output enabled, DPAD0 is associated at initialization time to the first DU channel that it can be connected to. This makes no change on Gen2 as all Gen2 SoCs can connected DPAD0 to DU0, which is the current implicit default value. As the DPAD0 source is always 0 when a single source is possible on Gen2, we can also simplify the Gen2 code in the same function to remove a conditional check. Signed-off-by:
-
Laurent Pinchart authored
On selected SoCs, the DU can use the clock output by the LVDS encoder PLL as its input dot clock. This feature is optional, but on the D3 and E3 SoC it is often the only way to obtain a precise dot clock frequency, as the other available clocks (CPG-generated clock and external clock) usually have fixed rates. Add a DU model information field to describe which DU channels can use the LVDS PLL output clock as their input clock, and configure clock routing accordingly. This feature is available on H2, M2-W, M2-N, D3 and E3 SoCs, with D3 and E3 being the primary targets. It is left disabled in this commit, and will be enabled per-SoC after careful testing. At the hardware level, clock routing is configured at runtime in two steps, first selecting an internal dot clock between the LVDS PLL clock and the external DOTCLKIN clock, and then selecting between the internal dot clock and the CPG-generated clock. The first part requires stopping the whole DU group in order for the change to take effect, thus causing flickering on the screen. For this reason we currently hardcode the clock source to the LVDS PLL clock if available, and allow flicker-free selection of the external DOTCLKIN clock or CPG-generated clock otherwise. A more dynamic clock selection process can be implemented later if the need arises. Signed-off-by:
-
Laurent Pinchart authored
The rcar_du_crtc_get() function is always immediately followed by a call to rcar_du_crtc_setup(). Call the later from the former to simplify the code, and add a comment to explain how the get and put calls are balanced. Signed-off-by:
-
Laurent Pinchart authored
The LVDS encoders in the D3 and E3 SoCs differ significantly from those in the other R-Car Gen3 family members: - The LVDS PLL architecture is more complex and requires computing PLL parameters manually. - The PLL uses external clocks as inputs, which need to be retrieved from DT. - In addition to the different PLL setup, the startup sequence has changed *again* (seems someone had trouble making his/her mind). Supporting all this requires DT bindings extensions for external clocks, brand new PLL setup code, and a few quirks to handle the differences in the startup sequence. The implementation doesn't support all hardware features yet, namely - Using the LV[01] clocks generated by the CPG as PLL input. - Providing the LVDS PLL clock to the DU for use with the RGB output. Those features can be added later when the need will arise. Signed-off-by:
-
Laurent Pinchart authored
The THC63LVD1024 is restricted to a pixel clock frequency in the range of 8 to 135 MHz. Implement the bridge .mode_valid() operation accordingly. Signed-off-by:
Andrzej Hajda <a.hajda@samsung.com> Tested-by:
-
Laurent Pinchart authored
On the D3 and E3 SoCs, the LVDS encoder can derive its internal pixel clock from an externally supplied clock, either through the EXTAL pin or through one of the DU_DOTCLKINx pins. Add corresponding clocks to the DT bindings. To retain backward compatibility with DT that don't specify the clock-names property, the functional clock must always be specified first, and the clock-names property is optional when only the functional clock is specified. Signed-off-by:
-
Laurent Pinchart authored
The E3 (r8a77990) supports two LVDS channels. Extend the binding to support them. Signed-off-by:
Rob Herring <robh@kernel.org> Reviewed-by:
-
Laurent Pinchart authored
Document the E3 (r8a77990) SoC in the R-Car DU bindings. Signed-off-by:
-
- 23 Sep, 2018 7 commits
-
-
Greg Kroah-Hartman authored
-
git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfdGreg Kroah-Hartman authored
Lee writes: "MFD fixes for v4.19 - Fix Dialog DA9063 regulator constraints issue causing failure in probe - Fix OMAP Device Tree compatible strings to match DT" * tag 'mfd-fixes-4.19' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd: mfd: omap-usb-host: Fix dts probe of children mfd: da9063: Fix DT probing with constraints -
git://git.kernel.org/pub/scm/linux/kernel/git/xen/tipGreg Kroah-Hartman authored
Juergen writes: "xen: Two small fixes for xen drivers." * tag 'for-linus-4.19d-rc5-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip: xen: issue warning message when out of grant maptrack entries xen/x86/vpmu: Zero struct pt_regs before calling into sample handling code
-
git://git.kernel.dk/linux-blockGreg Kroah-Hartman authored
Jens writes: "Just a single fix in this pull request, fixing a regression in /proc/diskstats caused by the unification of timestamps." * tag 'for-linus-20180922' of git://git.kernel.dk/linux-block: block: use nanosecond resolution for iostat
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipGreg Kroah-Hartman authored
Thomas writes: "A set of fixes for x86: - Resolve the kvmclock regression on AMD systems with memory encryption enabled. The rework of the kvmclock memory allocation during early boot results in encrypted storage, which is not shareable with the hypervisor. Create a new section for this data which is mapped unencrypted and take care that the later allocations for shared kvmclock memory is unencrypted as well. - Fix the build regression in the paravirt code introduced by the recent spectre v2 updates. - Ensure that the initial static page tables cover the fixmap space correctly so early console always works. This worked so far by chance, but recent modifications to the fixmap layout can - depending on kernel configuration - move the relevant entries to a different place which is not covered by the initial static page tables. - Address the regressions and issues which got introduced with the recent extensions to the Intel Recource Director Technology code. - Update maintainer entries to document reality" * 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/mm: Expand static page table for fixmap space MAINTAINERS: Add X86 MM entry x86/intel_rdt: Add Reinette as co-maintainer for RDT MAINTAINERS: Add Borislav to the x86 maintainers x86/paravirt: Fix some warning messages x86/intel_rdt: Fix incorrect loop end condition x86/intel_rdt: Fix exclusive mode handling of MBA resource x86/intel_rdt: Fix incorrect loop end condition x86/intel_rdt: Do not allow pseudo-locking of MBA resource x86/intel_rdt: Fix unchecked MSR access x86/intel_rdt: Fix invalid mode warning when multiple resources are managed x86/intel_rdt: Global closid helper to support future fixes x86/intel_rdt: Fix size reporting of MBA resource x86/intel_rdt: Fix data type in parsing callbacks x86/kvm: Use __bss_decrypted attribute in shared variables x86/mm: Add .bss..decrypted section to hold shared variables -
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipGreg Kroah-Hartman authored
Thomas writes: "- Provide a strerror_r wrapper so lib/bpf can be built on systems without _GNU_SOURCE - Unbreak the man page generator when building out of tree" * 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: perf Documentation: Fix out-of-tree asciidoctor man page generation tools lib bpf: Provide wrapper for strerror_r to build in !_GNU_SOURCE systems -
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipGreg Kroah-Hartman authored
Thomas writes: "Make the EFI arm stub device tree loader default on to unbreak existing EFI boot loaders which do not have DTB support." * 'efi-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: efi/libstub/arm: default EFI_ARMSTUB_DTB_LOADER to y
-
- 22 Sep, 2018 1 commit
-
-
Omar Sandoval authored
Klaus Kusche reported that the I/O busy time in /proc/diskstats was not updating properly on 4.18. This is because we started using ktime to track elapsed time, and we convert nanoseconds to jiffies when we update the partition counter. However, this gets rounded down, so any I/Os that take less than a jiffy are not accounted for. Previously in this case, the value of jiffies would sometimes increment while we were doing I/O, so at least some I/Os were accounted for. Let's convert the stats to use nanoseconds internally. We still report milliseconds as before, now more accurately than ever. The value is still truncated to 32 bits for backwards compatibility. Fixes: 522a7775 ("block: consolidate struct request timestamp fields") Cc: stable@vger.kernel.org Reported-by:
Klaus Kusche <klaus.kusche@computerix.info> Signed-off-by:
Omar Sandoval <osandov@fb.com> Signed-off-by:
Jens Axboe <axboe@kernel.dk>
-
