[PATCH v2 1/2] drm/mediatek: use correct device to import PRIME buffers
PRIME buffers should be imported using the DMA device. To this end, use
a custom import function that mimics drm_gem_prime_import_dev(), but
passes the correct device.
Fixes: 119f5173628aa ("drm/mediatek: Add DRM Driver for Mediatek SoC MT8173.")
Signed-off-by: Alexandre Courbot
---
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index 95fdbd0fbcac..8b18a00a58c7 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -320,6 +320,18 @@ static const struct file_operations mtk_drm_fops = {
.compat_ioctl = drm_compat_ioctl,
};
+/*
+ * We need to override this because the device used to import the memory is
+ * not dev->dev, as drm_gem_prime_import() expects.
+ */
+struct drm_gem_object *mtk_drm_gem_prime_import(struct drm_device *dev,
+ struct dma_buf *dma_buf)
+{
+ struct mtk_drm_private *private = dev->dev_private;
+
+ return drm_gem_prime_import_dev(dev, dma_buf, private->dma_dev);
+}
+
static struct drm_driver mtk_drm_driver = {
.driver_features = DRIVER_MODESET | DRIVER_GEM | DRIVER_PRIME |
DRIVER_ATOMIC,
@@ -331,7 +343,7 @@ static struct drm_driver mtk_drm_driver = {
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
.gem_prime_export = drm_gem_prime_export,
- .gem_prime_import = drm_gem_prime_import,
+ .gem_prime_import = mtk_drm_gem_prime_import,
.gem_prime_get_sg_table = mtk_gem_prime_get_sg_table,
.gem_prime_import_sg_table = mtk_gem_prime_import_sg_table,
.gem_prime_mmap = mtk_drm_gem_mmap_buf,
--
2.22.0.709.g102302147b-goog
Re: [PATCH] drm/mediatek: make imported PRIME buffers contiguous
On Wed, Jul 24, 2019 at 2:49 PM CK Hu wrote:
>
> Hi, Alexandre:
>
> On Tue, 2019-07-23 at 14:34 +0900, Alexandre Courbot wrote:
> > This driver requires imported PRIME buffers to appear contiguously in
> > its IO address space. Make sure this is the case by setting the maximum
> > DMA segment size to a better value than the default 64K on the DMA
> > device, and use said DMA device when importing PRIME buffers.
> >
> > Signed-off-by: Alexandre Courbot
> > ---
> > drivers/gpu/drm/mediatek/mtk_drm_drv.c | 47 --
> > drivers/gpu/drm/mediatek/mtk_drm_drv.h | 2 ++
> > 2 files changed, 46 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> > b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> > index 95fdbd0fbcac..4ad4770fab13 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> > @@ -213,6 +213,7 @@ static int mtk_drm_kms_init(struct drm_device *drm)
> > struct mtk_drm_private *private = drm->dev_private;
> > struct platform_device *pdev;
> > struct device_node *np;
> > + struct device *dma_dev;
> > int ret;
> >
> > if (!iommu_present(_bus_type))
> > @@ -275,7 +276,27 @@ static int mtk_drm_kms_init(struct drm_device *drm)
> > goto err_component_unbind;
> > }
> >
> > - private->dma_dev = >dev;
> > + dma_dev = >dev;
> > + private->dma_dev = dma_dev;
> > +
> > + /*
> > + * Configure the DMA segment size to make sure we get contiguous IOVA
> > + * when importing PRIME buffers.
> > + */
> > + if (!dma_dev->dma_parms) {
> > + private->dma_parms_allocated = true;
> > + dma_dev->dma_parms =
> > + devm_kzalloc(drm->dev, sizeof(*dma_dev->dma_parms),
> > + GFP_KERNEL);
> > + }
> > + if (!dma_dev->dma_parms)
> > + goto err_component_unbind;
>
> return with ret = 0?
Oops, indeed.
>
> > +
> > + ret = dma_set_max_seg_size(dma_dev, (unsigned int)DMA_BIT_MASK(32));
> > + if (ret) {
> > + dev_err(dma_dev, "Failed to set DMA segment size\n");
> > + goto err_unset_dma_parms;
> > + }
> >
> > /*
> >* We don't use the drm_irq_install() helpers provided by the DRM
> > @@ -285,13 +306,16 @@ static int mtk_drm_kms_init(struct drm_device *drm)
> > drm->irq_enabled = true;
> > ret = drm_vblank_init(drm, MAX_CRTC);
> > if (ret < 0)
> > - goto err_component_unbind;
> > + goto err_unset_dma_parms;
> >
> > drm_kms_helper_poll_init(drm);
> > drm_mode_config_reset(drm);
> >
> > return 0;
> >
> > +err_unset_dma_parms:
> > + if (private->dma_parms_allocated)
> > + dma_dev->dma_parms = NULL;
> > err_component_unbind:
> > component_unbind_all(drm->dev, drm);
> > err_config_cleanup:
> > @@ -302,9 +326,14 @@ static int mtk_drm_kms_init(struct drm_device *drm)
> >
> > static void mtk_drm_kms_deinit(struct drm_device *drm)
> > {
> > + struct mtk_drm_private *private = drm->dev_private;
> > +
> > drm_kms_helper_poll_fini(drm);
> > drm_atomic_helper_shutdown(drm);
> >
> > + if (private->dma_parms_allocated)
> > + private->dma_dev->dma_parms = NULL;
> > +
> > component_unbind_all(drm->dev, drm);
> > drm_mode_config_cleanup(drm);
> > }
> > @@ -320,6 +349,18 @@ static const struct file_operations mtk_drm_fops = {
> > .compat_ioctl = drm_compat_ioctl,
> > };
> >
> > +/*
> > + * We need to override this because the device used to import the memory is
> > + * not dev->dev, as drm_gem_prime_import() expects.
> > + */
> > +struct drm_gem_object *mtk_drm_gem_prime_import(struct drm_device *dev,
> > + struct dma_buf *dma_buf)
> > +{
> > + struct mtk_drm_private *private = dev->dev_private;
> > +
> > + return drm_gem_prime_import_dev(dev, dma_buf, private->dma_dev);
> > +}
> > +
>
> I think this part should be an independent patch which fixup
> 119f5173628aa ("drm/mediatek: Add DRM Driver for Mediatek SoC MT8173.")
I have split this patch and sent a v2.
Thanks,
Alex.
[PATCH v2 0/2] drm/mediatek: make imported PRIME buffers contiguous
The default DMA segment size was used when importing PRIME buffers, which resulted in a chance of them not being contiguous in the virtual IO space of the device and mtk_gem_prime_import_sg_table() complaining that the SG table was not contiguous as it expects. This series fixes this issue by 1) Using the correct DMA device when importing PRIME buffers, 2) Setting a more suitable DMA segment size on the DMA device than the default 64KB. Changes since v1: - Split into two patches, - Fixed an error path that would have returned 0. Alexandre Courbot (2): drm/mediatek: use correct device to import PRIME buffers drm/mediatek: set DMA max segment size drivers/gpu/drm/mediatek/mtk_drm_drv.c | 49 -- drivers/gpu/drm/mediatek/mtk_drm_drv.h | 2 ++ 2 files changed, 48 insertions(+), 3 deletions(-) -- 2.22.0.709.g102302147b-goog
[PATCH v2 2/2] drm/mediatek: set DMA max segment size
This driver requires imported PRIME buffers to appear contiguously in
its IO address space. Make sure this is the case by setting the maximum
DMA segment size to a more suitable value than the default 64KB.
Signed-off-by: Alexandre Courbot
Reviewed-by: Tomasz Figa
---
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 35 --
drivers/gpu/drm/mediatek/mtk_drm_drv.h | 2 ++
2 files changed, 35 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index 8b18a00a58c7..c021d4c8324f 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -213,6 +213,7 @@ static int mtk_drm_kms_init(struct drm_device *drm)
struct mtk_drm_private *private = drm->dev_private;
struct platform_device *pdev;
struct device_node *np;
+ struct device *dma_dev;
int ret;
if (!iommu_present(_bus_type))
@@ -275,7 +276,29 @@ static int mtk_drm_kms_init(struct drm_device *drm)
goto err_component_unbind;
}
- private->dma_dev = >dev;
+ dma_dev = >dev;
+ private->dma_dev = dma_dev;
+
+ /*
+* Configure the DMA segment size to make sure we get contiguous IOVA
+* when importing PRIME buffers.
+*/
+ if (!dma_dev->dma_parms) {
+ private->dma_parms_allocated = true;
+ dma_dev->dma_parms =
+ devm_kzalloc(drm->dev, sizeof(*dma_dev->dma_parms),
+GFP_KERNEL);
+ }
+ if (!dma_dev->dma_parms) {
+ ret = -ENOMEM;
+ goto err_component_unbind;
+ }
+
+ ret = dma_set_max_seg_size(dma_dev, (unsigned int)DMA_BIT_MASK(32));
+ if (ret) {
+ dev_err(dma_dev, "Failed to set DMA segment size\n");
+ goto err_unset_dma_parms;
+ }
/*
* We don't use the drm_irq_install() helpers provided by the DRM
@@ -285,13 +308,16 @@ static int mtk_drm_kms_init(struct drm_device *drm)
drm->irq_enabled = true;
ret = drm_vblank_init(drm, MAX_CRTC);
if (ret < 0)
- goto err_component_unbind;
+ goto err_unset_dma_parms;
drm_kms_helper_poll_init(drm);
drm_mode_config_reset(drm);
return 0;
+err_unset_dma_parms:
+ if (private->dma_parms_allocated)
+ dma_dev->dma_parms = NULL;
err_component_unbind:
component_unbind_all(drm->dev, drm);
err_config_cleanup:
@@ -302,9 +328,14 @@ static int mtk_drm_kms_init(struct drm_device *drm)
static void mtk_drm_kms_deinit(struct drm_device *drm)
{
+ struct mtk_drm_private *private = drm->dev_private;
+
drm_kms_helper_poll_fini(drm);
drm_atomic_helper_shutdown(drm);
+ if (private->dma_parms_allocated)
+ private->dma_dev->dma_parms = NULL;
+
component_unbind_all(drm->dev, drm);
drm_mode_config_cleanup(drm);
}
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.h
b/drivers/gpu/drm/mediatek/mtk_drm_drv.h
index 598ff3e70446..e03fea12ff59 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.h
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.h
@@ -51,6 +51,8 @@ struct mtk_drm_private {
} commit;
struct drm_atomic_state *suspend_state;
+
+ bool dma_parms_allocated;
};
extern struct platform_driver mtk_ddp_driver;
--
2.22.0.709.g102302147b-goog
[Bug 111244] amdgpu kernel 5.2 blank display after resume from suspend
https://bugs.freedesktop.org/show_bug.cgi?id=111244 --- Comment #2 from csp...@verizon.net --- Created attachment 144903 --> https://bugs.freedesktop.org/attachment.cgi?id=144903=edit second bisect log -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111244] amdgpu kernel 5.2 blank display after resume from suspend
https://bugs.freedesktop.org/show_bug.cgi?id=111244 --- Comment #1 from csp...@verizon.net --- Created attachment 144902 --> https://bugs.freedesktop.org/attachment.cgi?id=144902=edit first bisect log -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111244] amdgpu kernel 5.2 blank display after resume from suspend
https://bugs.freedesktop.org/show_bug.cgi?id=111244 Bug ID: 111244 Summary: amdgpu kernel 5.2 blank display after resume from suspend Product: DRI Version: DRI git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: csp...@verizon.net Created attachment 144901 --> https://bugs.freedesktop.org/attachment.cgi?id=144901=edit kernel log Model: Lenovo Ideapad S340 15" CPU: AMD Ryzen 5 3500U Starting with kernel 5.2, laptop has a blank display after resuming from suspend. Problem doesn't appear with recent kernels up to 5.1.16. Attached is a kernel log and git bisect logs. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 09/11] devfreq: exynos-bus: Add interconnect functionality to exynos-bus
Hi,
On 19. 7. 23. 오후 9:20, Artur Świgoń wrote:
> This patch adds interconnect functionality to the exynos-bus devfreq
> driver.
>
> The SoC topology is a graph (or, more specifically, a tree) and most of its
> edges are taken from the devfreq parent-child hierarchy (cf.
> Documentation/devicetree/bindings/devfreq/exynos-bus.txt). The previous
> patch adds missing edges to the DT (under the name 'parent'). Due to
> unspecified relative probing order, -EPROBE_DEFER may be propagated to
> guarantee that a child is probed before its parent.
>
> Each bus is now an interconnect provider and an interconnect node as well
> (cf. Documentation/interconnect/interconnect.rst), i.e. every bus registers
> itself as a node. Node IDs are not hardcoded but rather assigned at
> runtime, in probing order (subject to the above-mentioned exception
> regarding relative order). This approach allows for using this driver with
> various Exynos SoCs.
>
> The devfreq target() callback provided by exynos-bus now selects either the
> frequency calculated by the devfreq governor or the frequency requested via
> the interconnect API for the given node, whichever is higher.
Basically, I agree to support the QoS requirement between devices.
But, I think that need to consider the multiple cases.
1. When changing the devfreq governor by user,
For example of the connection between bus_dmc/leftbus/display on patch8,
there are possible multiple cases with various devfreq governor
which is changed on the runtime by user through sysfs interface.
If users changes the devfreq governor as following:
Before,
- bus_dmc (simple_ondemand, available frequency 100/200/300/400 MHz)
--> bus_leftbus(simple_ondemand, available frequency 100/200/300/400 MHz)
> bus_display(passive)
After changed governor of bus_dmc,
if the min_freq by interconnect requirement is 400Mhz,
- bus_dmc (powersave) : min_freq and max_freq and cur_freq is 100MHz
--> bus_leftbus(simple_ondemand) : cur_freq is 400Mhz
> bus_display(passive)
The final frequency is 400MHz of bus_dmc
even if the min_freq/max_freq/cur_freq is 100MHz.
It cannot show the correct min_freq/max_freq through
devfreq sysfs interface.
2. When disabling the some frequency by devfreq-thermal throttling,
This patch checks the min_freq of interconnect requirement
in the exynos_bus_target() and exynos_bus_passive_target().
Also, it cannot show the correct min_freq/max_freq through
devfreq sysfs interface.
For example of bus_dmc bus,
- The available frequencies are 100MHz, 200MHz, 300MHz, 400MHz
- Disable 400MHz by devfreq-thermal throttling
- min_freq is 100MHz
- max_freq is 300MHz
- min_freq of interconnect is 400MHz
In result, the final frequency is 400MHz by exynos_bus_target()
There are no problem for working. But, the user cannot know
reason why cur_freq is 400MHz even if max_freq is 300MHz.
Basically, update_devfreq() considers the all constraints
of min_freq/max_freq to decide the proper target frequency.
3.
I think that the exynos_bus_passive_target() is used for devfreq device
using 'passive' governor. The frequency already depends on the parent device.
If already the parent devfreq device like bus_leftbus consider
the minimum frequency of QoS requirement like interconnect,
it is not necessary. The next frequency of devfreq device
with 'passive' governor, it will apply the QoS requirement
without any additional code.
>
> Please note that it is not an error when CONFIG_INTERCONNECT is 'n', in
> which case all interconnect API functions are no-op.
>
> Signed-off-by: Artur Świgoń
> ---
> drivers/devfreq/exynos-bus.c | 145 +++
> 1 file changed, 145 insertions(+)
>
> diff --git a/drivers/devfreq/exynos-bus.c b/drivers/devfreq/exynos-bus.c
> index 412511ca7703..12fb7c84ae50 100644
> --- a/drivers/devfreq/exynos-bus.c
> +++ b/drivers/devfreq/exynos-bus.c
> @@ -14,6 +14,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -23,6 +24,8 @@
> #define DEFAULT_SATURATION_RATIO 40
> #define DEFAULT_VOLTAGE_TOLERANCE2
>
> +#define icc_units_to_hz(x) ((x) * 1000UL / 8)
> +
> struct exynos_bus {
> struct device *dev;
>
> @@ -31,12 +34,17 @@ struct exynos_bus {
> unsigned int edev_count;
> struct mutex lock;
>
> + unsigned long min_freq;
> unsigned long curr_freq;
>
> struct regulator *regulator;
> struct clk *clk;
> unsigned int voltage_tolerance;
> unsigned int ratio;
> +
> + /* One provider per bus, one node per provider */
> + struct icc_provider provider;
> + struct icc_node *node;
> };
>
> /*
> @@ -61,6 +69,13 @@ exynos_bus_ops_edev(enable_edev);
> exynos_bus_ops_edev(disable_edev);
> exynos_bus_ops_edev(set_event);
>
> +static int exynos_bus_next_id(void)
> +{
> + static int exynos_bus_node_id;
> +
> + return exynos_bus_node_id++;
> +}
> +
> static int exynos_bus_get_event(struct exynos_bus *bus,
>
Re: [RFC PATCH 08/11] arm: dts: exynos: Add parents and #interconnect-cells to Exynos4412
Hi,
On 19. 7. 26. 오후 9:02, Marek Szyprowski wrote:
> Hi
>
> On 2019-07-25 15:13, Chanwoo Choi wrote:
>> 2019년 7월 24일 (수) 오전 8:07, Artur Świgoń 님이 작성:
>>> This patch adds two fields tp the Exynos4412 DTS:
>>>- parent: to declare connections between nodes that are not in a
>>> parent-child relation in devfreq;
>>>- #interconnect-cells: required by the interconnect framework.
>>>
>>> Please note that #interconnect-cells is always zero and node IDs are not
>>> hardcoded anywhere.
>>>
>>> Signed-off-by: Artur Świgoń
>>> ---
>>> arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 1 +
>>> arch/arm/boot/dts/exynos4412.dtsi | 9 +
>>> 2 files changed, 10 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
>>> b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
>>> index ea55f377d17c..bdd61ae86103 100644
>>> --- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
>>> +++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
>>> @@ -106,6 +106,7 @@
>>> _leftbus {
>>> devfreq-events = <_leftbus_3>, <_rightbus_3>;
>>> vdd-supply = <_reg>;
>>> + parent = <_dmc>;
>> It is wrong. 'bus_leftbus' has not any h/w dependency of 'bus_dmc'
>> and 'bus_leftbus' is not child of 'bus_dmc'.
>>
>> Even it there are some PMQoS requirement between them,
>> it it not proper to tie both 'bus_leftbus' and 'bus_dmc'.
>
> There is strict dependency between them. DMC bus running at frequency
> lower than left (or right) bus really doesn't make much sense, because
> it will limit the left bus performance. This dependency should be
> modeled somehow.
I misunderstood new 'parent' prototype as the existing 'devfreq' property.
I didn't understand why use the 'devfreq' property because 'bus_dmc' and
'bus_leftbus' don't share the power line. Please ignore my previous comment.
Basically, I agree that it is necessary to support the QoS requirement
between buses or if possible, between bus and gpu.
To support the interconnect between bus_dmc, bus_leftbus and bus_display,
it used the either 'devfreq' or 'parent' properties to connect them.
In order to catch the meaning of 'devfreq' and 'parent' properties,
If possible, it would be separate the usage role of between 'devfreq'
or 'parent' properties. Because it is possible to connect the 'buses'
with only using 'parent' property if all buses in the path uses
the devfreq governors except for 'passive' governor.
- If 'devfreq' property is used between buses,
it indicates that there are requirement of shading of power line.
- If 'parent' property is used between buses,
it indicates that there are requirement of interconnect connection.
>
>>> status = "okay";
>>> };
>>>
>>> diff --git a/arch/arm/boot/dts/exynos4412.dtsi
>>> b/arch/arm/boot/dts/exynos4412.dtsi
>>> index d20db2dfe8e2..a70a671acacd 100644
>>> --- a/arch/arm/boot/dts/exynos4412.dtsi
>>> +++ b/arch/arm/boot/dts/exynos4412.dtsi
>>> @@ -390,6 +390,7 @@
>>> clocks = < CLK_DIV_DMC>;
>>> clock-names = "bus";
>>> operating-points-v2 = <_dmc_opp_table>;
>>> + #interconnect-cells = <0>;
>>> status = "disabled";
>>> };
>>>
>>> @@ -398,6 +399,7 @@
>>> clocks = < CLK_DIV_ACP>;
>>> clock-names = "bus";
>>> operating-points-v2 = <_acp_opp_table>;
>>> + #interconnect-cells = <0>;
>>> status = "disabled";
>>> };
>>>
>>> @@ -406,6 +408,7 @@
>>> clocks = < CLK_DIV_C2C>;
>>> clock-names = "bus";
>>> operating-points-v2 = <_dmc_opp_table>;
>>> + #interconnect-cells = <0>;
>>> status = "disabled";
>>> };
>>>
>>> @@ -459,6 +462,7 @@
>>> clocks = < CLK_DIV_GDL>;
>>> clock-names = "bus";
>>> operating-points-v2 = <_leftbus_opp_table>;
>>> + #interconnect-cells = <0>;
>>> status = "disabled";
>>> };
>>>
>>> @@ -467,6 +471,7 @@
>>> clocks = < CLK_DIV_GDR>;
>>> clock-names = "bus";
>>> operating-points-v2 = <_leftbus_opp_table>;
>>> + #interconnect-cells = <0>;
>>> status = "disabled";
>>> };
>>>
>>> @@ -475,6 +480,7 @@
>>> clocks = < CLK_ACLK160>;
>>> clock-names = "bus";
>>> operating-points-v2 = <_display_opp_table>;
>>> + #interconnect-cells = <0>;
>>> status = "disabled";
>>> };
>>>
>>> @@ -483,6 +489,7 @@
>>>
[Bug 110457] System resumes failed and hits [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout on Acer Aspire A315-21G
https://bugs.freedesktop.org/show_bug.cgi?id=110457 --- Comment #9 from redri...@gmail.com --- Created attachment 144900 --> https://bugs.freedesktop.org/attachment.cgi?id=144900=edit Thinkpad E585 log file with amdgpu errors I'm running into an issue that I think is related to this. Attached a journal file containing the traces from the last boot where it occurred. For some reason, it doesn't happen every time I try to resume from suspend, but when it does I have no choice but to hard reboot. This is a Thinkpad E585, uname -a "Linux thonkpad 5.2.3-arch1-1-ARCH #1 SMP PREEMPT Fri Jul 26 08:13:47 UTC 2019 x86_64 GNU/Linux" -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: linux-next: manual merge of the drm-intel tree with the kspp-gustavo tree
Hi all,
On Tue, 23 Jul 2019 11:03:31 +1000 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the drm-intel tree got a conflict in:
>
> drivers/gpu/drm/i915/display/intel_dp.c
>
> between commit:
>
> b6ac32eac063 ("drm/i915: Mark expected switch fall-throughs")
This is now commit
2defb94edb44 (""drm/i915: Mark expected switch fall-throughs")
from Linus' tree.
> from the kspp-gustavo tree and commit:
>
> bc85328ff431 ("drm/i915: Move the TypeC port handling code to a separate
> file")
> 4f36afb26cbe ("drm/i915: Sanitize the TypeC FIA lane configuration
> decoding")
>
> from the drm-intel tree.
>
> I fixed it up (bc85328ff431 moved the function updated by b6ac32eac063
> and 4f36afb26cbe added an equivalent fixup) and can carry the fix as
> necessary. This is now fixed as far as linux-next is concerned, but any
> non trivial conflicts should be mentioned to your upstream maintainer
> when your tree is submitted for merging. You may also want to consider
> cooperating with the maintainer of the conflicting tree to minimise any
> particularly complex conflicts.
--
Cheers,
Stephen Rothwell
pgpftMxVaHjFS.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109102] At dual monitor intel_do_flush_locked failed: Resource deadlock avoided
https://bugs.freedesktop.org/show_bug.cgi?id=109102 --- Comment #8 from Gert vd Kraats --- I am currently using Debian 10 Buster with Wayland. This problem is not existing anymore at this release. Wayland no longer uses an extra fence register if dual monitor is used. The wrong reservation of fence registers at intel_blit.c still exists, but does not harm, because the limit of 14 usable fence registers is very safe. A limit of 15 might be possible, if reservation at intel_blit.c is unbugged. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111243] Installation of 19.20 Fails
https://bugs.freedesktop.org/show_bug.cgi?id=111243 jacque8...@gmail.com changed: What|Removed |Added Hardware|Other |x86-64 (AMD64) OS|All |Linux (All) -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111243] Installation of 19.20 Fails
https://bugs.freedesktop.org/show_bug.cgi?id=111243 Bug ID: 111243 Summary: Installation of 19.20 Fails Product: DRI Version: unspecified Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu-pro Assignee: dri-devel@lists.freedesktop.org Reporter: jacque8...@gmail.com Created attachment 144899 --> https://bugs.freedesktop.org/attachment.cgi?id=144899=edit Logs Recommended by AMD deb [ trusted=yes ] file:/var/opt/amdgpu-pro-local/ ./ Get:1 file:/var/opt/amdgpu-pro-local ./ InRelease Ign:1 file:/var/opt/amdgpu-pro-local ./ InRelease Get:2 file:/var/opt/amdgpu-pro-local ./ Release [816 B] Get:2 file:/var/opt/amdgpu-pro-local ./ Release [816 B] Get:3 file:/var/opt/amdgpu-pro-local ./ Release.gpg Ign:3 file:/var/opt/amdgpu-pro-local ./ Release.gpg Hit:4 http://repo.steampowered.com/steam precise InRelease Hit:5 http://us.archive.ubuntu.com/ubuntu bionic InRelease Get:6 http://us.archive.ubuntu.com/ubuntu bionic-updates InRelease [88.7 kB] Get:7 http://security.ubuntu.com/ubuntu bionic-security InRelease [88.7 kB] Hit:8 http://ppa.launchpad.net/teejee2008/ppa/ubuntu bionic InRelease Get:9 http://us.archive.ubuntu.com/ubuntu bionic-backports InRelease [74.6 kB] Fetched 252 kB in 1s (294 kB/s) Reading package lists... Done Reading package lists... Done Building dependency tree Reading state information... Done amdgpu-pro-pin is already the newest version (19.20-812932). Selected version '19.20-812932' (localhost [all]) for 'amdgpu-pro-pin' 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. 3 not fully installed or removed. After this operation, 0 B of additional disk space will be used. Setting up libgl1-amdgpu-pro-ext-hwe:amd64 (19.20-812932) ... ln: failed to create symbolic link '/opt/amdgpu-pro/lib/xorg/modules/extensions/libglx.so': File e xists dpkg: error processing package libgl1-amdgpu-pro-ext-hwe:amd64 (--configure): installed libgl1-amdgpu-pro-ext-hwe:amd64 package post-installation script subprocess returned er ror exit status 1 dpkg: dependency problems prevent configuration of amdgpu-pro-hwe: amdgpu-pro-hwe depends on libgl1-amdgpu-pro-ext-hwe (= 19.20-812932); however: Package libgl1-amdgpu-pro-ext-hwe:amd64 is not configured yet. dpkg: error processing package amdgpu-pro-hwe (--configure): dependency problems - leaving unconfigured dpkg: dependency problems prevent configuration of amdgpu-pro-lib32: amdgpu-pro-lib32 depends on amdgpu-pro (= 19.20-812932) | amdgpu-pro-hwe (= 19.20-812932); howeve r: Package amdgpu-pro is not installed. Package amdgpu-pro-hwe is not configured yet. dpkg: error processing package amdgpu-pro-lib32 (--configure): dependency problems - leaving unconfigured No apport report written because the error message indicates its a followup error from a previous failure. No apport report written because the error message indicates its a followup error from a p revious failure. Errors were encountered while processing: libgl1-amdgpu-pro-ext-hwe:amd64 amdgpu-pro-hwe amdgpu-pro-lib32 E: Sub-process /usr/bin/dpkg returned an error code (1) -- You are receiving this mail because: You are the assignee for the
[Bug 111229] Unable to unbind GPU from amdgpu
https://bugs.freedesktop.org/show_bug.cgi?id=111229 --- Comment #6 from weden...@yandex.ru --- Seems to be a regression. I can unbind from amdgpu and bind to vfio-pci just fine on kernel 4.19.60-1-lts. I was able to unbind without previous error after: echo 0 > /sys/class/vtconsole/vtcon0/bind echo 0 > /sys/class/vtconsole/vtcon1/bind echo efi-framebuffer.0 > /sys/bus/platform/drivers/efi-framebuffer/unbind || true -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111241] Shadertoy shader causing hang
https://bugs.freedesktop.org/show_bug.cgi?id=111241 Bug ID: 111241 Summary: Shadertoy shader causing hang Product: Mesa Version: 19.1 Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel@lists.freedesktop.org Reporter: m...@felix-potthast.de QA Contact: dri-devel@lists.freedesktop.org When opening https://www.shadertoy.com/view/3lsXDB on my Desktop PC with Radeon HD 7870 Graphics card (Pitcairn) i get a freeze. It works fine on my Laptop with Intel Graphics. Both systems use Mesa 19.1.3 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC] Expanding drm_mode_modeinfo flags
On 2019-07-24 07:48, Sean Paul wrote: On Mon, Jul 22, 2019 at 04:50:43PM -0700, Jeykumar Sankaran wrote: On 2019-07-19 07:29, Sean Paul wrote: > On Fri, Jul 19, 2019 at 05:15:28PM +0300, Ville Syrjälä wrote: > > On Fri, Jul 19, 2019 at 09:55:58AM -0400, Sean Paul wrote: > > > On Fri, Jul 19, 2019 at 11:05:53AM +0200, Daniel Vetter wrote: > > > > On Thu, Jul 18, 2019 at 11:18:42AM -0700, Jeykumar Sankaran wrote: > > > > > On 2019-07-16 02:07, Daniel Vetter wrote: > > > > > > On Thu, Jul 11, 2019 at 11:46:44AM -0700, Jeykumar Sankaran wrote: > > /snip > > > > > > > > drm: add mode flags in uapi for seamless mode switch > > > > > > > > > > > > I think the uapi is the trivial part here, the real deal is how > > > > > > userspace > > > > > > uses this. Can you pls post the patches for your compositor? > > > > > > > > > > > > Also note that we already allow userspace to tell the kernel whether > > > > > > flickering is ok or not for a modeset. msm driver could use that to at > > > > > > least tell userspace whether a modeset change is possible. So you can > > > > > > already implement glitch-free modeset changes for at least video mode. > > > > > > -Daniel > > > > > > > > > > I believe you are referring to the below tv property of the connector. > > > > > > > > > > /** > > > > > * @tv_flicker_reduction_property: Optional TV property to control the > > > > > * flicker reduction mode. > > > > > */ > > > > > struct drm_property *tv_flicker_reduction_property; > > > > > > > > Not even close :-) > > > > > > > > I mean the DRM_MODE_ATOMIC_ALLOW_MODESET flag for the atomic ioctl. This > > > > is not a property of a mode, this is a property of a _transition_ between > > > > configurations. Some transitions can be done flicker free, others can't. > > > > > > Agree that an atomic flag on a commit is the way to accomplish this. It's pretty > > > similar to the psr transitions, where we want to reuse most of the atomic > > > circuitry, but in a specialized way. We'd also have to be careful to only > > > involve the drm objects which are seamless modeset aware (you could imagine > > > a bridge chain where the bridges downstream of the first bridge don't care). > > > > > > > > > > > There's then still the question of how to pick video vs command mode, but > > > > imo better to start with implementing the transition behaviour correctly > > > > first. > > > > > > Connector property? Possibly a terrible idea, but I wonder if we could [re]use > > > the vrr properties for command mode. The docs state that the driver has the > > > option of putting upper and lower bounds on the refresh rate. > > > > Not really sure why this needs new props and whatnot. This is kinda > > what > > the i915 "fastset" stuff already does: > > 1. userspace asks for something to be changed via atomic > > 2. driver calculates whether a modeset is actually required > > 3. atomic validates need_modeset() vs. DRM_MODE_ATOMIC_ALLOW_MODESET > > 4. if (need_modeset) heavyweight_commit() else lightweight_commit() > > > > Ie. why should userspace really care about anything except the > > "flickers are OK" vs. "flickers not wanted" thing? > > Agree, I don't think the seamless modeset (ie: changing resolution > without > flicker) needs a property. Just need to test the commit without > ALLOW_MODESET > and commit it if the test passes. > Agreed that a TEST_ONLY commit without ALLOW_MODESET flag can be used to check whether the modeset can be done seamless. But since there are no error code returns, the client cannot distinguish the test_only commit failures from other invalid config failures. Also, note that when the client sees two 1080p modes (vid/cmd) and it is interested only to do *only* seamless switches, without any additional flag it cannot distinguish between these two 1080p modes. The client has to invoke two test_only commits with these modes to identify the seamless one. Is that a preferred approach? Hi Jey! Yeah, pretty much. Stepping back a bit though, why is the kernel exposing 2 1080p modes in the first place? If you just expose one mode and then use a property to enter "low-latency operation" (or overloading vrr for cmd mode), you shouldn't need to do the mode switch, just flip the property and let the kernel figure out how to transition to video/cmd mode. Intel's "fastset" calculates the need for modeset internally based on the configuration and chooses the best commit path. But the requirement here is to expose the information up-front since the use case cannot afford to fall back to the normal modeset when it has requested for a seamless one. > > > > Also what's the benefit of using video mode if your panel supportes > > command mode? Can you turn off the memory in the panel and actually > > save power that way? And if there is a benefit can't the driver just > > automagically switch between the two based on how often things are > > getting updated? That would match how
[Bug 111235] radeonsi_drv_video.so should report support for packed headers
https://bugs.freedesktop.org/show_bug.cgi?id=111235 Scott Moreau changed: What|Removed |Added OS|All |Linux (All) Hardware|Other |x86-64 (AMD64) --- Comment #1 from Scott Moreau --- After chatting with Mark Thompson, I realize that the patch is incorrect because it advertises packed header support which is not implemented in the driver. Proper packed header support should be implemented to fix this problem. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110413] GPU crash and failed reset leading to deadlock on Polaris 22 XL [Radeon RX Vega M GL]
https://bugs.freedesktop.org/show_bug.cgi?id=110413 --- Comment #10 from Alex Behling --- >From my experience this seems to be a thermal problem. I have the exact same hardware configuration running latest Archlinux Kernel. $ uname -a Linux lexnote 5.2.3-arch1-1-ARCH #1 SMP PREEMPT Fri Jul 26 08:13:47 UTC 2019 x86_64 GNU/Linux If I leave leave the system with the default PM settings (Profile Performance or Balance doesn't matter) sooner or later I will get Lock-Ups in any game or application with higher GPU loads. EXAMPLE DMESG OUTPUT: [Do Jul 25 23:33:45 2019] amdgpu :01:00.0: GPU pci config reset [Do Jul 25 23:33:53 2019] [drm] PCIE GART of 256M enabled (table at 0x00F4). [Do Jul 25 23:33:53 2019] amdgpu :01:00.0: [drm:amdgpu_ring_test_helper [amdgpu]] *ERROR* ring gfx test failed (-110) [Do Jul 25 23:33:53 2019] [drm:amdgpu_device_ip_resume_phase2 [amdgpu]] *ERROR* resume of IP block failed -110 [Do Jul 25 23:33:53 2019] [drm:amdgpu_device_resume [amdgpu]] *ERROR* amdgpu_device_ip_resume failed (-110). [Do Jul 25 23:33:53 2019] [drm] schedsdma0 is not ready, skipping [Do Jul 25 23:33:53 2019] [drm] schedsdma1 is not ready, skipping [Do Jul 25 23:33:59 2019] WARNING: CPU: 1 PID: 20969 at drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:891 dm_suspend+0x4e/0x60 [amdgpu] [Do Jul 25 23:33:59 2019] Modules linked in: msr fuse 8021q garp mrp stp llc ccm snd_hda_codec_hdmi hid_sensor_gyro_3d hid_sensor_accel_3d hid_sensor_magn_3d hid_sensor_rotation hid_sensor_incl_3d hid_sensor_trigger industrialio_triggered_buffer kfifo_buf hid_sensor_iio_common industrialio hid_sensor_hub intel_ishtp_loader intel_ishtp_hid arc4 iwlmvm mousedev cdc_ether usbnet r8152 xpad ff_memless joydev mii mac80211 uvcvideo btusb videobuf2_vmalloc hid_logitech_hidpp videobuf2_memops btrtl btbcm nls_iso8859_1 videobuf2_v4l2 btintel nls_cp437 videobuf2_common bluetooth vfat fat videodev media spi_pxa2xx_platform ecdh_generic iTCO_wdt 8250_dw hid_multitouch ecc mei_hdcp iTCO_vendor_support iwlwifi intel_rapl hp_wmi x86_pkg_temp_thermal wmi_bmof intel_powerclamp intel_wmi_thunderbolt coretemp kvm_intel snd_hda_codec_realtek snd_hda_codec_generic ledtrig_audio kvm psmouse input_leds snd_hda_intel cfg80211 irqbypass intel_cstate snd_hda_codec snd_hda_core intel_uncore snd_hwdep intel_rapl_perf snd_pcm [Do Jul 25 23:33:59 2019] rtsx_pci_ms memstick snd_timer pcspkr mei_me intel_ish_ipc processor_thermal_device snd idma64 int3403_thermal ucsi_acpi i2c_i801 soundcore typec_ucsi rfkill intel_lpss_pci mei tpm_crb int340x_thermal_zone intel_pch_thermal intel_ishtp intel_soc_dts_iosf intel_lpss i2c_hid typec wmi tpm_tis tpm_tis_core tpm rng_core intel_vbtn battery sparse_keymap hp_wireless evdev mac_hid int3400_thermal acpi_thermal_rel ac pcc_cpufreq vboxnetflt(OE) vboxnetadp(OE) vboxpci(OE) vboxdrv(OE) sg crypto_user ip_tables x_tables ext4 crc32c_generic crc16 mbcache jbd2 algif_skcipher af_alg hid_logitech_dj hid_generic usbhid hid dm_crypt crct10dif_pclmul crc32_pclmul dm_mod crc32c_intel ghash_clmulni_intel rtsx_pci_sdmmc serio_raw mmc_core atkbd libps2 ahci libahci aesni_intel libata aes_x86_64 crypto_simd cryptd xhci_pci glue_helper scsi_mod xhci_hcd rtsx_pci i8042 serio amdgpu amd_iommu_v2 gpu_sched ttm i915 intel_gtt i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm [Do Jul 25 23:33:59 2019] agpgart [Do Jul 25 23:33:59 2019] CPU: 1 PID: 20969 Comm: kworker/1:2 Tainted: G OE 5.2.1-arch1-1-ARCH #1 [Do Jul 25 23:33:59 2019] Hardware name: HP HP Spectre x360 Convertible 15-ch0xx/83BB, BIOS F.24 11/06/2018 [Do Jul 25 23:33:59 2019] Workqueue: pm pm_runtime_work [Do Jul 25 23:33:59 2019] RIP: 0010:dm_suspend+0x4e/0x60 [amdgpu] [Do Jul 25 23:33:59 2019] Code: 00 48 89 83 70 e9 00 00 e8 9f fc ff ff 48 89 df e8 97 83 00 00 48 8b bb 70 cf 00 00 be 08 00 00 00 e8 b6 9a 08 00 31 c0 5b c3 <0f> 0b eb c1 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 0f 1f 44 00 [Do Jul 25 23:33:59 2019] RSP: 0018:b286869cfcb8 EFLAGS: 00010282 [Do Jul 25 23:33:59 2019] RAX: c0675ed0 RBX: a1b9e0d3 RCX: c073e980 [Do Jul 25 23:33:59 2019] RDX: 0080 RSI: 0001 RDI: a1b9e0d3 [Do Jul 25 23:33:59 2019] RBP: a1b9e0d3e998 R08: 0001 R09: 0018 [Do Jul 25 23:33:59 2019] R10: fefefefefefefeff R11: R12: a1b9e0d3 [Do Jul 25 23:33:59 2019] R13: R14: R15: a1b9ebc8bd80 [Do Jul 25 23:33:59 2019] FS: () GS:a1b9eea4() knlGS: [Do Jul 25 23:33:59 2019] CS: 0010 DS: ES: CR0: 80050033 [Do Jul 25 23:33:59 2019] CR2: 7f1d9c02b000 CR3: 000469058002 CR4: 003606e0 [Do Jul 25 23:33:59 2019] Call Trace: [Do Jul 25 23:33:59 2019] amdgpu_device_ip_suspend_phase1+0x8e/0xc0 [amdgpu] [Do Jul 25 23:33:59 2019] amdgpu_device_suspend+0x234/0x390 [amdgpu] [Do Jul 25 23:33:59 2019]
[Bug 111240] RX 560x is very slow
https://bugs.freedesktop.org/show_bug.cgi?id=111240 Bug ID: 111240 Summary: RX 560x is very slow Product: DRI Version: XOrg git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: major Priority: highest Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: alfabus...@gmail.com Created attachment 144897 --> https://bugs.freedesktop.org/attachment.cgi?id=144897=edit Unigine_Heaven-4.0 around 27 fps I have laptop ASUS TUF Gaming with Ubuntu 19.04, but graphics card rx 560x very slow on linux system. DRI_PRIME=1 glxinfo | grep OpenGL OpenGL vendor string: X.Org OpenGL renderer string: Radeon RX 560 Series (POLARIS11, DRM 3.27.0, 5.0.0-21-generic, LLVM 8.0.1) OpenGL core profile version string: 4.5 (Core Profile) Mesa 19.2.0-devel (git-2f92360 2019-07-26 disco-oibaf-ppa) OpenGL core profile shading language version string: 4.50 OpenGL core profile context flags: (none) OpenGL core profile profile mask: core profile OpenGL core profile extensions: OpenGL version string: 4.5 (Compatibility Profile) Mesa 19.2.0-devel (git-2f92360 2019-07-26 disco-oibaf-ppa) OpenGL shading language version string: 4.50 OpenGL context flags: (none) OpenGL profile mask: compatibility profile OpenGL extensions: OpenGL ES profile version string: OpenGL ES 3.2 Mesa 19.2.0-devel (git-2f92360 2019-07-26 disco-oibaf-ppa) OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20 OpenGL ES profile extensions: glxinfo | grep OpenGL OpenGL vendor string: X.Org OpenGL renderer string: AMD RAVEN (DRM 3.27.0, 5.0.0-21-generic, LLVM 8.0.1) OpenGL core profile version string: 4.5 (Core Profile) Mesa 19.2.0-devel (git-2f92360 2019-07-26 disco-oibaf-ppa) OpenGL core profile shading language version string: 4.50 OpenGL core profile context flags: (none) OpenGL core profile profile mask: core profile OpenGL core profile extensions: OpenGL version string: 4.5 (Compatibility Profile) Mesa 19.2.0-devel (git-2f92360 2019-07-26 disco-oibaf-ppa) OpenGL shading language version string: 4.50 OpenGL context flags: (none) OpenGL profile mask: compatibility profile OpenGL extensions: OpenGL ES profile version string: OpenGL ES 3.2 Mesa 19.2.0-devel (git-2f92360 2019-07-26 disco-oibaf-ppa) OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20 OpenGL ES profile extensions: I tried run Unigine_Heaven-4.0. I've got around 27 fps on basic preset... -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110199] [amdgpu] Screen flickering when using a 75Hz monitor paired with an RX 480 GPU
https://bugs.freedesktop.org/show_bug.cgi?id=110199 --- Comment #12 from jacobbrett+f...@jacobbrett.id.au --- (In reply to Bennet from comment #11) > Only kernel 4.19 works for me with 75hz , so probably seem to be a problem > related to Free Sync. I don't think it's Freesync-specific; I have Freesync turned off but suffer the same issue at 75 Hz; working fine at 60 Hz, though (RX 580). -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111238] firefox does not show the history
https://bugs.freedesktop.org/show_bug.cgi?id=111238 Andre Klapper changed: What|Removed |Added Product|DRI |Spam Status|NEW |RESOLVED Resolution|--- |INVALID Group||spam Component|DRM/amdkfd |Two --- Comment #1 from Andre Klapper --- Go away and test somewhere else. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111237] firefox does not show the history
https://bugs.freedesktop.org/show_bug.cgi?id=111237 Andre Klapper changed: What|Removed |Added Component|DRM/amdkfd |Two Group||spam Resolution|--- |INVALID Product|DRI |Spam Status|NEW |RESOLVED --- Comment #1 from Andre Klapper --- Go away and test somewhere else. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110199] [amdgpu] Screen flickering when using a 75Hz monitor paired with an RX 480 GPU
https://bugs.freedesktop.org/show_bug.cgi?id=110199 --- Comment #11 from Bennet --- Only kernel 4.19 works for me with 75hz , so probably seem to be a problem related to Free Sync. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110199] [amdgpu] Screen flickering when using a 75Hz monitor paired with an RX 480 GPU
https://bugs.freedesktop.org/show_bug.cgi?id=110199 --- Comment #10 from Bennet --- Can Confirm with my RX 580 and Asus VG245H -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111229] Unable to unbind GPU from amdgpu
https://bugs.freedesktop.org/show_bug.cgi?id=111229 --- Comment #5 from weden...@yandex.ru --- Created attachment 144896 --> https://bugs.freedesktop.org/attachment.cgi?id=144896=edit unbinding without X running I've attached a log of attempt to unbind without X running: systemctl stop sddm echo 0 > /sys/class/vtconsole/vtcon0/bind echo 0 > /sys/class/vtconsole/vtcon1/bind echo efi-framebuffer.0 > /sys/bus/platform/drivers/efi-framebuffer/unbind || true echo ":03:00.0" > /sys/bus/pci/devices/:03:00.0/driver/unbind Result is the same but backtrace seems a bit different. This was done with kernel 5.2.1. I've tried suspend to ram and another reset bug mitigation (which helps in other cases), but gpu is still unusable after this failed attempt to unbind. I still can't re-bind it to amdgpu or vfio-pci and clean shutdown is not happening. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/panel: s6d16d0: Support rotation
On Sun, Jul 28, 2019 at 12:52 PM Linus Walleij wrote: > Use the standard DT "rotation" attribute from > Documentation/devicetree/bindings/display/panel/panel.txt > to handle designs where the panel is mounted rotated > 90 (or 270) degrees as in the ST-Ericsson HREF520 > reference design. > > Signed-off-by: Linus Walleij Bah forget this ... this turned out to be a sony ACX424AKP panel. It just happened to work very similarly in command mode! I will write a proper panel driver for the Sony ACX424AKP. Yours, Linus Walleij ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/panel: s6d16d0: Support rotation
Use the standard DT "rotation" attribute from
Documentation/devicetree/bindings/display/panel/panel.txt
to handle designs where the panel is mounted rotated
90 (or 270) degrees as in the ST-Ericsson HREF520
reference design.
Signed-off-by: Linus Walleij
---
drivers/gpu/drm/panel/panel-samsung-s6d16d0.c | 38 ++-
1 file changed, 37 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panel/panel-samsung-s6d16d0.c
b/drivers/gpu/drm/panel/panel-samsung-s6d16d0.c
index f75bef24e050..d4c33781ade8 100644
--- a/drivers/gpu/drm/panel/panel-samsung-s6d16d0.c
+++ b/drivers/gpu/drm/panel/panel-samsung-s6d16d0.c
@@ -13,6 +13,7 @@
#include
#include
#include
+#include
#include
struct s6d16d0 {
@@ -20,6 +21,7 @@ struct s6d16d0 {
struct drm_panel panel;
struct regulator *supply;
struct gpio_desc *reset_gpio;
+ bool flipped;
};
/*
@@ -47,6 +49,28 @@ static const struct drm_display_mode samsung_s6d16d0_mode = {
.height_mm = 48,
};
+/* In the standing mode, things are just flipped around X/Y */
+static const struct drm_display_mode samsung_s6d16d0_standing_mode = {
+ /* HS clock, (htotal*vtotal*vrefresh)/1000 */
+ .clock = 420160,
+ .hdisplay = 480,
+ .hsync_start = 480 + 154,
+ .hsync_end = 480 + 154 + 16,
+ .htotal = 480 + 154 + 16 + 32,
+ .vdisplay = 864,
+ .vsync_start = 864 + 1,
+ .vsync_end = 864 + 1 + 1,
+ .vtotal = 864 + 1 + 1 + 1,
+ /*
+* This depends on the clocking HS vs LP rate, this value
+* is calculated as:
+* vrefresh = (clock * 1000) / (htotal*vtotal)
+*/
+ .vrefresh = 816,
+ .width_mm = 48,
+ .height_mm = 84,
+};
+
static inline struct s6d16d0 *panel_to_s6d16d0(struct drm_panel *panel)
{
return container_of(panel, struct s6d16d0, panel);
@@ -145,10 +169,16 @@ static int s6d16d0_disable(struct drm_panel *panel)
static int s6d16d0_get_modes(struct drm_panel *panel)
{
+ struct s6d16d0 *s6 = panel_to_s6d16d0(panel);
struct drm_connector *connector = panel->connector;
struct drm_display_mode *mode;
- mode = drm_mode_duplicate(panel->drm, _s6d16d0_mode);
+ if (s6->flipped)
+ mode = drm_mode_duplicate(panel->drm,
+ _s6d16d0_standing_mode);
+ else
+ mode = drm_mode_duplicate(panel->drm,
+ _s6d16d0_mode);
if (!mode) {
DRM_ERROR("bad mode or failed to add mode\n");
return -EINVAL;
@@ -176,6 +206,7 @@ static int s6d16d0_probe(struct mipi_dsi_device *dsi)
{
struct device *dev = >dev;
struct s6d16d0 *s6;
+ u32 rot_angle;
int ret;
s6 = devm_kzalloc(dev, sizeof(struct s6d16d0), GFP_KERNEL);
@@ -215,6 +246,11 @@ static int s6d16d0_probe(struct mipi_dsi_device *dsi)
return ret;
}
+ /* Support rotation of the display panel */
+ ret = of_property_read_u32(dev->of_node, "rotation", _angle);
+ if (!ret && (rot_angle == 90 || rot_angle == 270))
+ s6->flipped = true;
+
drm_panel_init(>panel);
s6->panel.dev = dev;
s6->panel.funcs = _drm_funcs;
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111238] firefox does not show the history
https://bugs.freedesktop.org/show_bug.cgi?id=111238 Bug ID: 111238 Summary: firefox does not show the history Product: DRI Version: unspecified Hardware: x86-64 (AMD64) OS: Windows (All) Status: NEW Severity: normal Priority: medium Component: DRM/amdkfd Assignee: dri-devel@lists.freedesktop.org Reporter: ahmadho...@gmail.com whenever i search for anything it does it perfectly but when it comes to check the searching history it gives an error -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/7] drm/msm/mdp4: Drop unused GPIO include
On Sat, Jun 29, 2019 at 3:01 PM Linus Walleij wrote: > This file is not using any symbols from so just > drop this include. > > Cc: Rob Clark > Cc: Sean Paul > Cc: linux-arm-...@vger.kernel.org > Cc: freedr...@lists.freedesktop.org > Signed-off-by: Linus Walleij Rob & friends: can this be merged to wherever you merge the MSM DRM patches? If it is in drm-misc I can apply it but I need some ACKs. Yours, Linus Walleij ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
