Hi,
On Fri, 2019-09-20 at 11:14 +0900, Chanwoo Choi wrote:
> Hi Artur,
>
> I tried to just build this patch on mainline kernel or linux-next.
> But, when I applied them, merge conflict happens. You didn't develop
> them on latest version. Please rebase them based on latest mainline kernel.
I
Hi,
On Fri, 2019-09-20 at 11:15 +0900, Chanwoo Choi wrote:
> Hi,
>
> As I already replied on v1, patch1/2/3 clean-up code
> for readability without any behavior changes.
>
> I think that you better to merge patch1/2/3 to one patch.
Yes, when writing the cover letter I think I forgot to
In vmw_context_define if vmw_context_init fails the allocated resource
should be unreferenced. The goto label was fixed.
Signed-off-by: Navid Emamdoost
---
drivers/gpu/drm/vmwgfx/vmwgfx_context.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
In vmw_cmdbuf_res_add if drm_ht_insert_item fails the allocated memory
for cres should be released.
Signed-off-by: Navid Emamdoost
---
drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf_res.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf_res.c
On Mon, Sep 23, 2019 at 05:03:55PM +0300, Dan Carpenter wrote:
> I wish you would think more about the error codes that you're returning.
> Most functions do "ret |= frob()." which ORs the error codes together,
> and results in a nonsense negative error code. But then some functions
> return 1 on
In komeda_wb_connector_add if drm_writeback_connector_init fails the
allocated memory for kwb_conn should be released.
Signed-off-by: Navid Emamdoost
---
drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git
https://bugs.freedesktop.org/show_bug.cgi?id=111792
--- Comment #4 from Alex Deucher ---
The commit was fixed by:
commit 0079f82e710caf3e821267917af9517ac0fca83d
Author: Alex Deucher
Date: Tue Jun 11 09:45:51 2019 -0500
drm/amdgpu: return 0 by default in amdgpu_pm_load_smu_firmware
https://bugs.freedesktop.org/show_bug.cgi?id=111808
Bug ID: 111808
Summary: [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx
timeout cause process into Disk sleep state
Product: DRI
Version: DRI git
Hardware: ARM
https://bugs.freedesktop.org/show_bug.cgi?id=111807
Bug ID: 111807
Summary: [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx
timeout cause process into Disk sleep state
Product: DRI
Version: DRI git
Hardware: ARM
https://bugs.freedesktop.org/show_bug.cgi?id=111792
--- Comment #3 from Sylvain BERTRAND ---
This bisection is kind of a pain, as usual on the 'rebase breakage'. I had to
start manually to find a "segment" with good enough good/bad data for bisect.
On this bisected segment, amd-staging-drm-next
https://bugs.freedesktop.org/show_bug.cgi?id=111806
Bug ID: 111806
Summary: VDPAU broken in radeonsi by commit
0692ae34e939845e5185d3bdd33ddfe4afcdb995
Product: Mesa
Version: git
Hardware: Other
OS: All
From: Srinivasan S
This patch avoids DP MST payload error message in dmesg, as it is trying
to update the payload to the disconnected DP MST device. After DP MST
device is disconnected we should not be updating the payload and
hence remove the error.
v2: Removed the connector status check and
On Tue, Sep 24, 2019 at 3:24 PM Rob Herring wrote:
>
> On Tue, Sep 24, 2019 at 4:29 PM John Stultz wrote:
> >
> > This patch removes the deprecated Android.mk files and replaces
> > them with Android.bp files, used in Android N and newer
> > releases.
> >
> > This is needed in order to build
On Tue, 24 Sep 2019 21:53:30 +0800
Jason Wang wrote:
> This patch implements basic support for mdev driver that supports
> virtio transport for kernel virtio driver.
>
> Signed-off-by: Jason Wang
> ---
> include/linux/mdev.h| 2 +
> include/linux/virtio_mdev.h | 145
On Tue, 24 Sep 2019 21:53:29 +0800
Jason Wang wrote:
> Currently, except for the create and remove, the rest of
> mdev_parent_ops is designed for vfio-mdev driver only and may not help
> for kernel mdev driver. With the help of class id, this patch
> introduces device specific callbacks inside
On Tue, 24 Sep 2019 21:53:26 +0800
Jason Wang wrote:
> Mdev bus only supports vfio driver right now, so it doesn't implement
> match method. But in the future, we may add drivers other than vfio,
> the first driver could be virtio-mdev. This means we need to add
> device class id support in bus
From: Srinivasan S
This patch avoids DP MST payload error message in dmesg, as it is trying
to update the payload to the disconnected DP MST device. After DP MST
device is disconnected we should not be updating the payload and
hence remove the error.
v2: Removed the connector status check and
On Tue, Sep 24, 2019 at 4:29 PM John Stultz wrote:
>
> This patch removes the deprecated Android.mk files and replaces
> them with Android.bp files, used in Android N and newer
> releases.
>
> This is needed in order to build libdrm/master against recent
> Android releases and AOSP/master, as
On Tue, Sep 24, 2019 at 1:12 PM Nicolas Saenz Julienne
wrote:
>
> Hi All,
> this series tries to address one of the issues blocking us from
> upstreaming Broadcom's STB PCIe controller[1]. Namely, the fact that
> devices not represented in DT which sit behind a PCI bus fail to get the
> bus' DMA
Thanks for submitting this.
Acked-by: Robert Foss
On 24.09.19 23:29, John Stultz wrote:
This patch removes the deprecated Android.mk files and replaces
them with Android.bp files, used in Android N and newer
releases.
This is needed in order to build libdrm/master against recent
Android
This patch removes the deprecated Android.mk files and replaces
them with Android.bp files, used in Android N and newer
releases.
This is needed in order to build libdrm/master against recent
Android releases and AOSP/master, as some of the Treble build
options required since Android O cannot be
Jean,
On 9/18/19 4:57 PM, Jean-Jacques Hiblot wrote:
> If the LED is acquired by a consumer device with devm_led_get(), it is
> automatically released when the device is detached.
>
> Signed-off-by: Jean-Jacques Hiblot
> Acked-by: Pavel Machek
> ---
> drivers/leds/led-class.c | 51
Hi Jean,
Thank you for the patch.
I have one nit below.
On 9/18/19 4:57 PM, Jean-Jacques Hiblot wrote:
> From: Tomi Valkeinen
>
> This patch adds basic support for a kernel driver to get a LED device.
> This will be used by the led-backlight driver.
>
> Only OF version is implemented for
https://bugs.freedesktop.org/show_bug.cgi?id=111804
--- Comment #7 from Chernovsky Oleg ---
Can confirm, have same issue with Vega 64 and gaming (both native and Wine +
DXVK). Surprisingly, the dmesg stack mentions Slack electron app, which indeed
was running in background.
dmesg stack:
https://bugzilla.kernel.org/show_bug.cgi?id=204987
Frank Steinborn (stei...@nognu.de) changed:
What|Removed |Added
Regression|No |Yes
--
You are
https://bugzilla.kernel.org/show_bug.cgi?id=204987
Bug ID: 204987
Summary: general protection fault in
amdgpu_dm_atomic_commit_tail (Vega64)
Product: Drivers
Version: 2.5
Kernel Version: 5.3.1
Hardware: x86-64
Jani Nikula writes:
> Allow better abstraction of the drm_debug global variable in the
> future. No functional changes.
>
> Cc: Francisco Jerez
> Signed-off-by: Jani Nikula
Reviewed-by: Francisco Jerez
> ---
> drivers/gpu/drm/i2c/sil164_drv.c | 2 +-
> 1 file changed, 1 insertion(+), 1
https://bugs.freedesktop.org/show_bug.cgi?id=111789
--- Comment #3 from Vlado Plaga ---
Cool, thank you, "usual user"! Your "cma=256M@2G" works for me. No more
"command buffer outside valid memory window", and I could start Weston with
weston-launch! The terminal there had a nice shadow, and I
https://bugs.freedesktop.org/show_bug.cgi?id=111803
--- Comment #6 from mikhail.v.gavri...@gmail.com ---
Created attachment 145502
--> https://bugs.freedesktop.org/attachment.cgi?id=145502=edit
./umr -O many,bits -r *.*.mmCP_PFP_HEADER_DUMP
--
You are receiving this mail because:
You are the
https://bugs.freedesktop.org/show_bug.cgi?id=111803
--- Comment #7 from mikhail.v.gavri...@gmail.com ---
Created attachment 145503
--> https://bugs.freedesktop.org/attachment.cgi?id=145503=edit
./umr -O many,bits -r *.*.mmCP_ME_HEADER_DUMP
--
You are receiving this mail because:
You are the
https://bugs.freedesktop.org/show_bug.cgi?id=111803
--- Comment #5 from mikhail.v.gavri...@gmail.com ---
Created attachment 145501
--> https://bugs.freedesktop.org/attachment.cgi?id=145501=edit
./umr -O many,bits -r *.*.mmCP_EOP_*
--
You are receiving this mail because:
You are the assignee
https://bugs.freedesktop.org/show_bug.cgi?id=111803
--- Comment #4 from mikhail.v.gavri...@gmail.com ---
Ups, when I uploaded the previous file, happened yet another hung on the
machine where I filling this bugreport. This machine has also Vega 20 GPU
aboard.
--
You are receiving this mail
On Tue, Sep 24, 2019 at 1:56 PM Rob Herring wrote:
>
> On Mon, Sep 23, 2019 at 8:45 AM Adam Ford wrote:
> >
> > This patch adds documentation of device tree bindings for the WVGA panel
> > Logic PD Type 28 display.
> >
> > Signed-off-by: Adam Ford
> > ---
> > V2: Use YAML instead of TXT for
https://bugs.freedesktop.org/show_bug.cgi?id=111804
--- Comment #6 from mikhail.v.gavri...@gmail.com ---
Created attachment 145500
--> https://bugs.freedesktop.org/attachment.cgi?id=145500=edit
./umr -O many,bits -r *.*.mmCP_ME_HEADER_DUMP
--
You are receiving this mail because:
You are the
https://bugs.freedesktop.org/show_bug.cgi?id=111804
--- Comment #5 from mikhail.v.gavri...@gmail.com ---
Created attachment 145499
--> https://bugs.freedesktop.org/attachment.cgi?id=145499=edit
./umr -O many,bits -r *.*.mmCP_PFP_HEADER_DUMP
--
You are receiving this mail because:
You are the
On Mon, Sep 23, 2019 at 8:45 AM Adam Ford wrote:
>
> This patch adds documentation of device tree bindings for the WVGA panel
> Logic PD Type 28 display.
>
> Signed-off-by: Adam Ford
> ---
> V2: Use YAML instead of TXT for binding
Fails to build with 'make dt_binding_check':
https://bugs.freedesktop.org/show_bug.cgi?id=111804
--- Comment #4 from mikhail.v.gavri...@gmail.com ---
Created attachment 145498
--> https://bugs.freedesktop.org/attachment.cgi?id=145498=edit
./umr -O many,bits -r *.*.mmCP_EOP_*
--
You are receiving this mail because:
You are the assignee
https://bugs.freedesktop.org/show_bug.cgi?id=111804
--- Comment #3 from mikhail.v.gavri...@gmail.com ---
Created attachment 145497
--> https://bugs.freedesktop.org/attachment.cgi?id=145497=edit
./umr -O many,bits -r *.*.mmGRBM_STATUS*
--
You are receiving this mail because:
You are the
https://bugs.freedesktop.org/show_bug.cgi?id=111804
--- Comment #2 from mikhail.v.gavri...@gmail.com ---
Created attachment 145496
--> https://bugs.freedesktop.org/attachment.cgi?id=145496=edit
./umr -R gfx[.]
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=111804
--- Comment #1 from mikhail.v.gavri...@gmail.com ---
Created attachment 145495
--> https://bugs.freedesktop.org/attachment.cgi?id=145495=edit
./umr -O halt_waves -wa
--
You are receiving this mail because:
You are the assignee for the
Hi Flora,
FYI, the error/warning still remains.
tree: git://people.freedesktop.org/~agd5f/linux.git amd-mainline-dkms-5.0
head: 71c434dfdbe847b6d8a645cb90ae2685f284b092
commit: f460c248a3f0bca3a875602cf40693de672485c4 [3697/3778] drm/amd/autoconf:
refactor dma_fence header check
config:
https://bugs.freedesktop.org/show_bug.cgi?id=111804
Bug ID: 111804
Summary: Annoying GPU stucks are continued on Vega 20 with
Kernel 5.4 + mesa 9.2.0 RC4 + llvm 9.0.0
[drm:drm_atomic_helper_wait_for_flip_done
On Mon, Sep 23, 2019 at 9:14 AM Laurentiu Palcu wrote:
>
> Add bindings for iMX8MQ Display Controller Subsystem.
>
> Signed-off-by: Laurentiu Palcu
> ---
> .../bindings/display/imx/nxp,imx8mq-dcss.yaml | 86
> ++
> 1 file changed, 86 insertions(+)
> create mode 100644
'len' in of_dma_get_range() is used to check the 'dma-ranges' property
length. After the fact, some calculations are run on the variable to be
then left unused.
Signed-off-by: Nicolas Saenz Julienne
---
drivers/of/address.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git
Master PCI devices might not appear in the device tree, yet they still
need to get the underlying cells properties in order to calculate the
bus DMA constraints. This conflicts with of_n_*_cells() as it's designed
under the assumption it'll receive a device OF node.
Create __of_n_*_cells_parent()
qoriq-mc's dpmacs DMA configuration is inherited from their parent node,
which acts a bus in this regard. So far it maked all devices as
dma-coherent but no dma-ranges recommendation is made.
The truth is that the underlying interconnect has DMA constraints, so
add an empty dma-ranges in
The function was only available locally to of/address.c, make it
available to the OF subsystem.
Signed-off-by: Nicolas Saenz Julienne
---
drivers/of/address.c| 18 --
drivers/of/base.c | 25 +
drivers/of/of_private.h | 2 ++
3 files changed,
Some devices don't have their own OF node, and are stuck passing their
bus node. Adapt the function for this use case.
Signed-off-by: Nicolas Saenz Julienne
---
drivers/of/address.c | 33 +++--
drivers/of/device.c| 3 ++-
include/linux/of_address.h |
Devices not represented in DT, placed behind a bus that autodetects
them, pass of_dma_configure() their bus' DT node. This misses that bus'
'dma-ranges' property as the function's implementation expects the DT
node to be one of a device.
Create of_dma_configure_parent() which takes the given DT
The widespread use case for of_dma_config() highlights a redundant
argument. Most callers provide both 'dev' and 'dev->of_node'. The rest
of users use it to copy some device's DMA configuration into a device
not represented in DT.
In order to simplify the common use case, and make code a little
Hi All,
this series tries to address one of the issues blocking us from
upstreaming Broadcom's STB PCIe controller[1]. Namely, the fact that
devices not represented in DT which sit behind a PCI bus fail to get the
bus' DMA addressing constraints.
This is due to the fact that of_dma_configure()
Some devices might not have a DT node of their own, but might still need
to translate DMA addresses based on their bus DT node.
Update of_translate_dma_address() to only depend on the parent DT node.
Rename it to of_translate_dma_address_parent(). The later will be still
available as a wrapper
It's not longer advised to use notifiers in order to setup custom DMA
ops.
Signed-off-by: Nicolas Saenz Julienne
---
drivers/of/device.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/of/device.c b/drivers/of/device.c
index 267b509df517..018c52688546 100644
---
The function provides the cell sizes for a specific bus type. Instead of
passing it the device DT node sitting on top of that bus we directly
pass its parent which is the actual node the function will start looking
from.
Signed-off-by: Nicolas Saenz Julienne
---
drivers/of/address.c | 18
The bus behind the board's PCIe core has DMA addressing limitations. Add
an empty 'dma-ranges' property on all PCIe bus descriptions to inform
the OF core that a translation is due further down the line.
Signed-off-by: Nicolas Saenz Julienne
---
arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi |
https://bugs.freedesktop.org/show_bug.cgi?id=111803
--- Comment #2 from mikhail.v.gavri...@gmail.com ---
Created attachment 145492
--> https://bugs.freedesktop.org/attachment.cgi?id=145492=edit
./umr -R gfx[.]
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=111803
--- Comment #3 from mikhail.v.gavri...@gmail.com ---
Created attachment 145493
--> https://bugs.freedesktop.org/attachment.cgi?id=145493=edit
./umr -O many,bits -r *.*.mmGRBM_STATUS*
--
You are receiving this mail because:
You are the
https://bugs.freedesktop.org/show_bug.cgi?id=111803
--- Comment #1 from mikhail.v.gavri...@gmail.com ---
Created attachment 145491
--> https://bugs.freedesktop.org/attachment.cgi?id=145491=edit
./umr -O halt_waves -wa
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=111803
Bug ID: 111803
Summary: Annoying GPU stucks are continued on Vega 20 with
Kernel 5.4 + mesa 9.3.0 + llvm 9.0.0
[drm:amdgpu_dm_atomic_commit_tail [amdgpu]] *ERROR*
On Tue, Sep 24, 2019 at 8:59 AM Jani Nikula wrote:
>
> Add helper to check if a drm debug category is enabled. Convert drm core
> to use it. No functional changes.
>
> v2: Move unlikely() to drm_debug_enabled() (Eric)
>
> Signed-off-by: Jani Nikula
Acked-by: Alex Deucher
> ---
>
On Tue, Sep 24, 2019 at 9:00 AM Jani Nikula wrote:
>
> drm_debug_enabled() is the way to check. __drm_debug is now reserved for
> drm print code only. No functional changes.
>
> v2: Rebase on move unlikely() to drm_debug_enabled()
>
> Signed-off-by: Jani Nikula
Acked-by: Alex Deucher
> ---
>
On Tue, Sep 24, 2019 at 8:59 AM Jani Nikula wrote:
>
> Move drm_debug variable declaration and definition to where they are
> relevant and needed. No functional changes.
>
> Signed-off-by: Jani Nikula
Acked-by: Alex Deucher
> ---
> drivers/gpu/drm/drm_drv.c | 17 -
>
On Tue, Sep 24, 2019 at 9:00 AM Jani Nikula wrote:
>
> Allow better abstraction of the drm_debug global variable in the
> future. No functional changes.
>
> Cc: Alex Deucher
> Cc: Christian König
> Cc: David (ChunMing) Zhou
> Cc: amd-...@lists.freedesktop.org
> Signed-off-by: Jani Nikula
Reviving this thread from the context of the below conversion:
https://lore.kernel.org/linux-arm-msm/db26145b-3f64-a334-f698-76f972332...@baylibre.com/T/#u
On 2018-10-05 01:19, Neil Armstrong wrote:
On 05/10/2018 09:58, Daniel Vetter wrote:
On Fri, Oct 5, 2018 at 9:39 AM Neil Armstrong
On Mon, Sep 23, 2019 at 3:08 PM Brian Starkey wrote:
> One miniscule nit from me below, but whether you change it or not, you
> can add my r-b:
>
> Reviewed-by: Brian Starkey
>
> Thanks for pushing this through!
Thanks again for the review! I'll address your issues and resubmit.
thanks
-john
https://bugs.freedesktop.org/show_bug.cgi?id=110729
GitLab Migration User changed:
What|Removed |Added
Resolution|--- |MOVED
Status|NEW
https://bugs.freedesktop.org/show_bug.cgi?id=101837
GitLab Migration User changed:
What|Removed |Added
Status|NEW |RESOLVED
https://bugs.freedesktop.org/show_bug.cgi?id=108068
GitLab Migration User changed:
What|Removed |Added
Resolution|--- |MOVED
Status|NEW
https://bugs.freedesktop.org/show_bug.cgi?id=100077
GitLab Migration User changed:
What|Removed |Added
Status|NEW |RESOLVED
https://bugs.freedesktop.org/show_bug.cgi?id=109063
GitLab Migration User changed:
What|Removed |Added
Status|NEW |RESOLVED
https://bugs.freedesktop.org/show_bug.cgi?id=107940
GitLab Migration User changed:
What|Removed |Added
Status|NEW |RESOLVED
https://bugs.freedesktop.org/show_bug.cgi?id=108069
GitLab Migration User changed:
What|Removed |Added
Status|NEW |RESOLVED
https://bugs.freedesktop.org/show_bug.cgi?id=109150
GitLab Migration User changed:
What|Removed |Added
Status|NEW |RESOLVED
https://bugs.freedesktop.org/show_bug.cgi?id=107013
GitLab Migration User changed:
What|Removed |Added
Resolution|--- |MOVED
Status|NEW
https://bugs.freedesktop.org/show_bug.cgi?id=86043
GitLab Migration User changed:
What|Removed |Added
Resolution|--- |MOVED
Status|NEW
https://bugs.freedesktop.org/show_bug.cgi?id=105142
GitLab Migration User changed:
What|Removed |Added
Resolution|--- |MOVED
Status|NEW
https://bugs.freedesktop.org/show_bug.cgi?id=106775
GitLab Migration User changed:
What|Removed |Added
Status|NEW |RESOLVED
https://bugs.freedesktop.org/show_bug.cgi?id=94951
GitLab Migration User changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=99581
GitLab Migration User changed:
What|Removed |Added
Status|NEEDINFO|RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=72425
GitLab Migration User changed:
What|Removed |Added
Resolution|--- |MOVED
Status|NEW
https://bugs.freedesktop.org/show_bug.cgi?id=77204
GitLab Migration User changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=66332
GitLab Migration User changed:
What|Removed |Added
Resolution|--- |MOVED
Status|NEW
https://bugs.freedesktop.org/show_bug.cgi?id=61269
GitLab Migration User changed:
What|Removed |Added
Resolution|--- |MOVED
Status|NEW
https://bugs.freedesktop.org/show_bug.cgi?id=48894
GitLab Migration User changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=41373
GitLab Migration User changed:
What|Removed |Added
Resolution|--- |MOVED
Status|NEW
https://bugs.freedesktop.org/show_bug.cgi?id=26708
GitLab Migration User changed:
What|Removed |Added
Resolution|--- |MOVED
Status|NEW
https://bugs.freedesktop.org/show_bug.cgi?id=35721
GitLab Migration User changed:
What|Removed |Added
Resolution|--- |MOVED
Status|NEW
https://bugs.freedesktop.org/show_bug.cgi?id=48599
GitLab Migration User changed:
What|Removed |Added
Resolution|--- |MOVED
Status|NEW
https://bugs.freedesktop.org/show_bug.cgi?id=39534
GitLab Migration User changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=49782
GitLab Migration User changed:
What|Removed |Added
Resolution|--- |MOVED
Status|NEW
https://bugs.freedesktop.org/show_bug.cgi?id=43288
GitLab Migration User changed:
What|Removed |Added
Resolution|--- |MOVED
Status|NEW
From: Jean Delvare
[ Upstream commit 77efe48a729588527afb4d5811b9e0acb29f5e51 ]
Comparing adev->family with CHIP constants is not correct.
adev->family can only be compared with AMDGPU_FAMILY constants and
adev->asic_type is the struct member to compare with CHIP constants.
They are separate
From: Marko Kohtala
[ Upstream commit dd9782834dd9dde3624ff1acea8859f3d3e792d4 ]
The page_offset was only applied to the end of the page range. This caused
the display updates to cause a scrolling effect on the display because the
amount of data written to the display did not match the range
From: Ahzo
[ Upstream commit f659bb6dae58c113805f92822e4c16ddd3156b79 ]
This fixes screen corruption/flickering on 75 Hz displays.
v2: make print statement debug only (Alex)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102646
Reviewed-by: Evan Quan
Signed-off-by: Ahzo
From: Jia-Ju Bai
[ Upstream commit f3eb9b8f67bc28783eddc142ad805ebdc53d6339 ]
In radeon_connector_set_property(), there is an if statement on line 743
to check whether connector->encoder is NULL:
if (connector->encoder)
When connector->encoder is NULL, it is used on line 755:
if
From: Jia-Ju Bai
[ Upstream commit f3eb9b8f67bc28783eddc142ad805ebdc53d6339 ]
In radeon_connector_set_property(), there is an if statement on line 743
to check whether connector->encoder is NULL:
if (connector->encoder)
When connector->encoder is NULL, it is used on line 755:
if
From: KyleMahlkuch
[ Upstream commit 6f7fe9a93e6c09bf988c5059403f5f88e17e21e6 ]
During kexec some adapters hit an EEH since they are not properly
shut down in the radeon_pci_shutdown() function. Adding
radeon_suspend_kms() fixes this issue.
Signed-off-by: KyleMahlkuch
Signed-off-by: Alex
From: Andrey Smirnov
[ Upstream commit e0655feaec62d5139b6b13a7b1bbb1ab8f1c2d83 ]
According to the datasheet tc358767 can transfer up to 16 bytes via
its AUX channel, so the artificial limit of 8 appears to be too
low. However only up to 15-bytes seem to be actually supported and
trying to use
From: Marko Kohtala
[ Upstream commit dd9782834dd9dde3624ff1acea8859f3d3e792d4 ]
The page_offset was only applied to the end of the page range. This caused
the display updates to cause a scrolling effect on the display because the
amount of data written to the display did not match the range
From: Chris Wilson
[ Upstream commit d3c6dd1fb30d3853c2012549affe75c930f4a2f9 ]
During release of the syncpt, we remove it from the list of syncpt and
the tree, but only if it is not already been removed. However, during
signaling, we first remove the syncpt from the list. So, if we
1 - 100 of 266 matches
Mail list logo
