On 7/29/19 7:28 AM, Christoph Hellwig wrote:
Factor out the repeated device memory address calculation into
a helper.
Signed-off-by: Christoph Hellwig
Reviewed-by: Ralph Campbell
---
drivers/gpu/drm/nouveau/nouveau_dmem.c | 42 +++---
1 file changed, 17
Series is Reviewed-by: José Roberto de Souza
On Mon, 2019-07-15 at 11:53 -0700, Lucas De Marchi wrote:
> From: Rodrigo Vivi
>
> Add the PCI ID import for EHL.
>
> Cc: Rodrigo Vivi
> Signed-off-by: James Ausmus
> Signed-off-by: Lucas De Marchi
> ---
> intel/intel_chipset.c | 1 +
> 1 file
Reviewed-by: Yan Zhao
> -Original Message-
> From: intel-gvt-dev [mailto:intel-gvt-dev-boun...@lists.freedesktop.org] On
> Behalf Of Zhenyu Wang
> Sent: Wednesday, June 12, 2019 11:23 AM
> To: Hariprasad Kelam
> Cc: David Airlie ; intel-...@lists.freedesktop.org; Joonas
> Lahtinen ;
On 7/29/19 7:28 AM, Christoph Hellwig wrote:
No one ever checks this flag, and we could easily get that information
from the page if needed.
Signed-off-by: Christoph Hellwig
Reviewed-by: Ralph Campbell
---
drivers/gpu/drm/nouveau/nouveau_dmem.c | 3 +--
include/linux/migrate.h
On Mon, Jul 29, 2019 at 05:28:35PM +0300, Christoph Hellwig wrote:
> There isn't any good reason to pass callbacks to migrate_vma. Instead
> we can just export the three steps done by this function to drivers and
> let them sequence the operation without callbacks. This removes a lot
> of
Signed-off-by: Pei-Hsuan Hung
Acked-by: Liviu Dudau
Cc: triv...@kernel.org
---
Hi Liviu, thanks for your reply.
This patch is generated by a script so at first I didn't notice there is
also a typo in the word coefficient. I've fixed the typo in this
version.
arch/powerpc/kernel/eeh.c
On 7/29/19 7:28 AM, Christoph Hellwig wrote:
We don't use this flag anymore, so remove it.
Signed-off-by: Christoph Hellwig
Reviewed-by: Ralph Campbell
---
include/linux/migrate.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/include/linux/migrate.h b/include/linux/migrate.h
On 7/29/19 7:28 AM, Christoph Hellwig wrote:
Factor the main copy page to vram routine out into a helper that acts
on a single page and which doesn't require the nouveau_dmem_migrate
structure for argument passing. As an added benefit the new version
only allocates the dma address array once
On Mon, Jul 29, 2019 at 05:28:43PM +0300, Christoph Hellwig wrote:
> The MIGRATE_PFN_WRITE is only used locally in migrate_vma_collect_pmd,
> where it can be replaced with a simple boolean local variable.
>
> Signed-off-by: Christoph Hellwig
NAK that flag is useful, for instance a anonymous vma
On Mon, Jul 29, 2019 at 8:23 AM Torsten Duwe wrote:
>
> On Fri, Jul 26, 2019 at 06:36:01PM +0200, Maxime Ripard wrote:
> > > +
> > > + dvdd12-supply:
> > > +maxItems: 1
> > > +description: Regulator for 1.2V digital core power.
> > > +$ref: /schemas/types.yaml#/definitions/phandle
>
Hi Yue,
Thank you for the patch.
On Mon, Jul 29, 2019 at 05:05:20PM +0800, YueHaibing wrote:
> If CONFIG_DRM_TOSHIBA_TC358764=y but CONFIG_DRM_KMS_HELPER=m,
> building fails:
>
> drivers/gpu/drm/bridge/tc358764.o:(.rodata+0x228): undefined reference to
> `drm_atomic_helper_connector_reset'
>
https://bugzilla.kernel.org/show_bug.cgi?id=204145
Michael Ellerman (mich...@ellerman.id.au) changed:
What|Removed |Added
Status|RESOLVED|CLOSED
---
On 7/29/19 7:28 AM, Christoph Hellwig wrote:
Factor the main copy page to ram routine out into a helper that acts on
a single page and which doesn't require the nouveau_dmem_fault
structure for argument passing. Also remove the loop over multiple
pages as we only handle one at the moment,
https://bugs.freedesktop.org/show_bug.cgi?id=111243
--- Comment #2 from jacque8...@gmail.com ---
That fixed the problem. Thank you so much.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
On 7/29/19 7:28 AM, Christoph Hellwig wrote:
The MIGRATE_PFN_WRITE is only used locally in migrate_vma_collect_pmd,
where it can be replaced with a simple boolean local variable.
Signed-off-by: Christoph Hellwig
Reviewed-by: Ralph Campbell
---
include/linux/migrate.h | 1 -
On Mon, Jul 29, 2019 at 04:52:30PM -0700, Jose Souza wrote:
Series is Reviewed-by: José Roberto de Souza
Thanks, applied.
Lucas De Marchi
On Mon, 2019-07-15 at 11:53 -0700, Lucas De Marchi wrote:
From: Rodrigo Vivi
Add the PCI ID import for EHL.
Cc: Rodrigo Vivi
Signed-off-by: James
On 7/29/19 7:28 AM, Christoph Hellwig wrote:
When we start a new batch of dma_map operations we need to reset dma_nr,
as we start filling a newly allocated array.
Signed-off-by: Christoph Hellwig
Reviewed-by: Ralph Campbell
---
drivers/gpu/drm/nouveau/nouveau_dmem.c | 1 +
1 file
On Fri, Jul 26, 2019 at 08:47:21AM -0300, Mauro Carvalho Chehab wrote:
> Some files got renamed but probably due to some merge conflicts,
> a few references still point to the old locations.
>
> Signed-off-by: Mauro Carvalho Chehab
> Acked-by: Wolfram Sang # I2C part
> Reviewed-by: Jerry
https://bugs.freedesktop.org/show_bug.cgi?id=111232
--- Comment #2 from bibitocarlos ---
(In reply to Alex Deucher from comment #1)
> Can you bisect?
I'm gonna try ^^, never did it before and leave to holydays Friday.
I'm gonna start with RC, then whith commits.
You think it's a proper way ?
On Mon, Jul 29, 2019 at 04:42:01PM -0700, Ralph Campbell wrote:
>
> On 7/29/19 7:28 AM, Christoph Hellwig wrote:
> > The MIGRATE_PFN_WRITE is only used locally in migrate_vma_collect_pmd,
> > where it can be replaced with a simple boolean local variable.
> >
> > Signed-off-by: Christoph Hellwig
Some fields are deleted from intel_memory_region in favor of instead
using the new nested drm_mem_region structure.
Note, this is based upon unmerged i915 series [1] in order to show how
i915 might begin to integrate the proposed drm_mem_region.
[1]
[ By request, resending to include amd-gfx + intel-gfx. Since resending,
I fixed the nit with ordering of header includes that Sam noted. ]
This RFC series is first implementation of some ideas expressed
earlier on dri-devel [1].
Some of the goals (open for much debate) are:
- Create common
Introduce DRM memory region types to be common for both drivers using
TTM and for i915. For now, TTM continues to define it's own set but
uses the DRM base definitions.
Signed-off-by: Brian Welty
---
include/drm/drm_mm.h| 8
include/drm/ttm/ttm_placement.h | 8
2
Move basic members of ttm_mem_type_manager into a new DRM memory region
structure. The idea is for this base structure to be nested inside
the TTM structure and later in Intel's proposed intel_memory_region.
As comments in the code suggest, the following future work can extend
the usefulness of
On 7/29/19 7:28 AM, Christoph Hellwig wrote:
There isn't any good reason to pass callbacks to migrate_vma. Instead
we can just export the three steps done by this function to drivers and
let them sequence the operation without callbacks. This removes a lot
of boilerplate code as-is, and will
https://bugs.freedesktop.org/show_bug.cgi?id=111234
--- Comment #3 from Michael J Evans ---
After looking at the linked bug and your description of my environment (dual
screen and yes KDE / Plasma as a compositor potentially exposing whatever
corner case this is in the kernel driver):
I agree
Mark switch cases where we are expecting to fall through.
This patch fixes the following warning (Building: arm):
drivers/gpu/drm/sti/sti_hdmi.c: In function ‘hdmi_audio_configure’:
drivers/gpu/drm/sti/sti_hdmi.c:851:13: warning: this statement may fall through
[-Wimplicit-fallthrough=]
On 7/29/19 7:28 AM, Christoph Hellwig wrote:
Factor out the end of fencing logic from the two migration routines.
Signed-off-by: Christoph Hellwig
Reviewed-by: Ralph Campbell
---
drivers/gpu/drm/nouveau/nouveau_dmem.c | 33 --
1 file changed, 15 insertions(+),
https://bugs.freedesktop.org/show_bug.cgi?id=110637
--- Comment #11 from Alex Deucher ---
(In reply to Alexander Mezin from comment #10)
> (In reply to Alex Deucher from comment #3)
> > More likely a bug in the mesa OpenCL code. If you want functional OpenCL,
> > you should use the ROCm OpenCL
https://bugs.freedesktop.org/show_bug.cgi?id=110637
--- Comment #10 from Alexander Mezin ---
(In reply to Alex Deucher from comment #3)
> More likely a bug in the mesa OpenCL code. If you want functional OpenCL,
> you should use the ROCm OpenCL packages.
Do you mean "Mesa OpenCL is not
https://bugs.freedesktop.org/show_bug.cgi?id=110674
--- Comment #54 from ReddestDream ---
(In reply to Peter Hercek from comment #52)
> I'm getting hangs-up with kernels 5.2.3 (often) and 5.1.15 (less often).
> Radeon VII with 3 monitors. Each monitor connected through DP.
I hear that 5.0.0.13
On Mon, Jul 29, 2019 at 12:58 PM Oleksandr Suvorov
wrote:
>
> On Thu, Jul 25, 2019 at 5:41 PM maxime.rip...@free-electrons.com
> wrote:
> >
> > On Thu, Jul 25, 2019 at 11:05:23AM +, Oleksandr Suvorov wrote:
> > >
> > > Even in source code of this driver there is an author's description:
> >
If CONFIG_DRM_LVDS_ENCODER=y but CONFIG_DRM_KMS_HELPER=m,
build fails:
drivers/gpu/drm/bridge/lvds-encoder.o: In function `lvds_encoder_probe':
lvds-encoder.c:(.text+0x155): undefined reference to `devm_drm_panel_bridge_add'
Reported-by: Hulk Robot
Fixes: dbb58bfd9ae6 drm/bridge: ("Fix
If DRM_LVDS_ENCODER=y but CONFIG_DRM_KMS_HELPER=m,
build fails:
drivers/gpu/drm/bridge/lvds-encoder.o: In function `lvds_encoder_probe':
lvds-encoder.c:(.text+0x155): undefined reference to `devm_drm_panel_bridge_add'
drivers/gpu/drm/bridge/tc358764.o:(.rodata+0x228): undefined reference to
Hello,
I am happy to see this discussion.
I like Noralf's late work to move mipi_dbi to drm/ and remove tinydrm.
This helps to simplify implementation and maintenance of drivers for
displays that conform to MIPI_DBI set of commands,
no matter if they use MIPI_DBI to transfer the image data or
On Wed, Jul 24, 2019 at 4:24 PM John Stultz wrote:
>
> On Wed, Jul 24, 2019 at 1:18 PM John Stultz wrote:
> >
> > On Wed, Jul 24, 2019 at 12:36 PM Laura Abbott wrote:
> > >
> > > On 7/17/19 12:31 PM, Alexander Popov wrote:
> > > > Hello!
> > > >
> > > > The syzkaller [1] has a trouble with
On 25-07-19, 18:02, Paul Cercueil wrote:
> The newer and better JZ4780 driver is now used to provide DMA
> functionality on the JZ4740.
Please change subjetc to dmaengine: xxx
After that
Acked-by: Vinod Koul
--
~Vinod
___
dri-devel mailing list
On Thu, Jul 25, 2019 at 05:56:48PM -0700, Ralph Campbell wrote:
> hmm_range_fault() calls find_vma() and walk_page_range() in a loop.
> This is unnecessary duplication since walk_page_range() calls find_vma()
> in a loop already.
> Simplify hmm_range_fault() by defining a walk_test() callback
When fall-through warnings was enabled by default the following warning
was starting to show up:
../drivers/gpu/drm/msm/adreno/a6xx_gpu.c: In function ‘a6xx_submit’:
../drivers/gpu/drm/msm/adreno/a6xx_gpu.c:116:7: warning: this statement may fall
through [-Wimplicit-fallthrough=]
if
Hi!
Dne petek, 26. julij 2019 ob 19:23:14 CEST je Andrzej Pietrasiewicz
napisal(a):
> Use the ddc pointer provided by the generic connector.
>
> Signed-off-by: Andrzej Pietrasiewicz
Acked-by: Jernej Skrabec
Thanks!
Best regards,
Jernej
> ---
> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c |
CONFIG_PREEMPTION is selected by CONFIG_PREEMPT and by
CONFIG_PREEMPT_RT. Both PREEMPT and PREEMPT_RT require the same
functionality which today depends on CONFIG_PREEMPT.
Change the Kconfig dependency of i810 to !CONFIG_PREEMPTION so the driver
is not accidentally built on a RT kernel.
On Thu, Jul 25, 2019 at 05:56:43PM -0700, Ralph Campbell wrote:
> Here are seven more patches for things I found to clean up.
> This was based on top of Christoph's seven patches:
> "hmm_range_fault related fixes and legacy API removal v3".
> I assume this will go into Jason's tree since there
On Thu, Jul 25, 2019 at 06:12:14PM +0100, Kevin Brodsky wrote:
> It is unclear why max-memory-bandwidth should be set for CLCD on the
> fast model. Removing that property allows allocating and using 32bpp
> buffers, which may be desirable on certain platforms such as
> Android.
>
> Reported-by:
Pls drop this one, will resend new.
On 2019/7/29 14:35, YueHaibing wrote:
> If CONFIG_DRM_LVDS_ENCODER=y but CONFIG_DRM_KMS_HELPER=m,
> build fails:
>
> drivers/gpu/drm/bridge/lvds-encoder.o: In function `lvds_encoder_probe':
> lvds-encoder.c:(.text+0x155): undefined reference to
>
When fall-through warnings was enabled by default the following warning
was starting to show up:
../drivers/gpu/drm/msm/adreno/adreno_gpu.c: In function ‘adreno_submit’:
../drivers/gpu/drm/msm/adreno/adreno_gpu.c:429:7: warning: this statement may
fall
through [-Wimplicit-fallthrough=]
if
On 25/07/2019 18:40, Alyssa Rosenzweig wrote:
Sorry, I was being sloppy again![1] I meant CPU mmapped.
No worries, just wanted to check :)
Apparently the blob in some cases creates a SAME_VA GROW_ON_GPF buffer -
since SAME_VA means permanently mapped on the CPU this translated to
mmapping a
When fall-through warnings was enabled by default the following warning
was starting to show up:
../drivers/gpu/drm/msm/adreno/a5xx_gpu.c: In function ‘a5xx_submit’:
../drivers/gpu/drm/msm/adreno/a5xx_gpu.c:150:7: warning: this statement may fall
through [-Wimplicit-fallthrough=]
if
On Sat, 27 Jul 2019, Daniel Vetter wrote:
> On Fri, Jul 26, 2019 at 10:25 PM Thomas Gleixner wrote:
> >
> > CONFIG_PREEMPTION is selected by CONFIG_PREEMPT and by
> > CONFIG_PREEMPT_RT. Both PREEMPT and PREEMPT_RT require the same
> > functionality which today depends on CONFIG_PREEMPT.
> >
> >
When fall-through warnings was enabled by default, commit d93512ef0f0e
("Makefile: Globally enable fall-through warning"), the following
warnings was starting to show up:
../drivers/gpu/drm/arm/malidp_hw.c: In function ‘malidp_format_get_bpp’:
../drivers/gpu/drm/arm/malidp_hw.c:387:8: warning:
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_process.c: In function
restore_process_worker:
drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_process.c:949:29: warning:
variable pdd set but not used [-Wunused-but-set-variable]
It is not used since
commit
Hi
On Wed, Jul 24, 2019 at 11:05 AM Maxime Ripard
wrote:
>
> On Mon, Jul 22, 2019 at 03:51:04PM +0530, Jagan Teki wrote:
> > Hi Maxime,
> >
> > On Sat, Jul 20, 2019 at 3:02 PM Maxime Ripard
> > wrote:
> > >
> > > On Sat, Jul 20, 2019 at 12:46:27PM +0530, Jagan Teki wrote:
> > > > On Sat, Jul
If DRM_LVDS_ENCODER=y but CONFIG_DRM_KMS_HELPER=m,
build fails:
drivers/gpu/drm/bridge/lvds-encoder.o: In function `lvds_encoder_probe':
lvds-encoder.c:(.text+0x155): undefined reference to `devm_drm_panel_bridge_add'
Reported-by: Hulk Robot
Fixes: dbb58bfd9ae6 ("drm/bridge: Fix lvds-encoder
On Tue, 23 Jul 2019, Kai-Heng Feng wrote:
> Hi,
>
> Currently, OLED panel brightness [1] is not supported.
As a general statement this is not true, and not backed up by the
referenced bug. We just don't know how brightness is controlled on that
particular laptop, because it apparently uses a
https://bugs.freedesktop.org/show_bug.cgi?id=111229
Michel Dänzer changed:
What|Removed |Added
Attachment #144878|text/x-log |text/plain
mime type|
Hi Pei,
On Sat, Jul 27, 2019 at 10:21:09PM +0800, Pei Hsuan Hung wrote:
> Signed-off-by: Pei Hsuan Hung
> Cc: triv...@kernel.org
> ---
> arch/powerpc/kernel/eeh.c | 2 +-
> arch/powerpc/platforms/cell/spufs/switch.c | 4 ++--
> drivers/extcon/extcon-rt8973a.c
On Mon, 29 Jul 2019, Kai-Heng Feng wrote:
> at 16:26, Jani Nikula wrote:
>
>> On Tue, 23 Jul 2019, Kai-Heng Feng wrote:
>>> Hi,
>>>
>>> Currently, OLED panel brightness [1] is not supported.
>>
>> As a general statement this is not true, and not backed up by the
>> referenced bug. We just don't
On 7/29/19 4:58 AM, Liviu Dudau wrote:
>> case MW_RESTART:
>> drm_writeback_signal_completion(>mw_connector,
>> 0);
>> -/* fall through to a new start */
>
> It's a shame that the compiler throws a warning here, it would've been really
>
Hi,
On Thu, Jul 25, 2019 at 06:02:12PM -0400, Paul Cercueil wrote:
> It has been replaced with the more mature ingenic-battery driver.
>
> Signed-off-by: Paul Cercueil
> Tested-by: Artur Rojek
> ---
Acked-by: Sebastian Reichel
-- Sebastian
> drivers/power/supply/Kconfig | 11 -
>
It is normal that binary syncobj replaces the underlying fence.
Signed-off-by: Chunming Zhou
---
drivers/gpu/drm/drm_syncobj.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index 929f7c64f9a2..bc7ec1679e4d 100644
---
On Wed, 24 Jul 2019, Andrzej Pietrasiewicz wrote:
> Allow passing ddc adapter pointer to the init function. Even if
> drm_connector_init() sometime in the future decides to e.g. memset() all
> connector fields to zeros, the newly added function ensures that at its
> completion the ddc member of
https://bugs.freedesktop.org/show_bug.cgi?id=111244
--- Comment #4 from csp...@verizon.net ---
The first bisect pointed to a merge commit so the second was done to bisect
within the merged commits.
--
You are receiving this mail because:
You are the assignee for the
On Thu, Jul 25, 2019 at 5:41 PM maxime.rip...@free-electrons.com
wrote:
>
> On Thu, Jul 25, 2019 at 11:05:23AM +, Oleksandr Suvorov wrote:
> >
> > Even in source code of this driver there is an author's description:
> > /*
> > * Even if we have an I2C bus, we can't assume that the
On Thu, 25 Jul 2019, Daniel Vetter wrote:
> On Thu, Jul 25, 2019 at 03:35:40PM +0800, Kai-Heng Feng wrote:
>> The next question is, how do we change the brightness level for OLED
>> displays? Is changing gamma value a good way to do it?
>
> There's no overall amplifier knob to set general
https://bugs.freedesktop.org/show_bug.cgi?id=111244
Michel Dänzer changed:
What|Removed |Added
CC||nicholas.kazlaus...@amd.com
---
https://bugs.freedesktop.org/show_bug.cgi?id=111234
Michel Dänzer changed:
What|Removed |Added
CC||nicholas.kazlaus...@amd.com
---
https://bugs.freedesktop.org/show_bug.cgi?id=111229
Michel Dänzer changed:
What|Removed |Added
Attachment #144877|text/x-log |text/plain
mime type|
On Fri, 2019-07-26 at 19:23 +0200, Andrzej Pietrasiewicz wrote:
> Use the ddc pointer provided by the generic connector.
>
> Signed-off-by: Andrzej Pietrasiewicz
Acked-by: Philipp Zabel
Thanks!
regards
Philipp
> ---
> drivers/gpu/drm/imx/imx-ldb.c | 7 ---
> 1 file changed, 4
On Fri, 2019-07-26 at 19:23 +0200, Andrzej Pietrasiewicz wrote:
> Use the ddc pointer provided by the generic connector.
>
> Signed-off-by: Andrzej Pietrasiewicz
Acked-by: Philipp Zabel
regards
Philipp
> ---
> drivers/gpu/drm/imx/imx-tve.c | 6 --
> 1 file changed, 4 insertions(+), 2
On Fri, Jul 26, 2019 at 12:02 AM Paul Cercueil wrote:
>
> Hi,
>
> This patchset converts the Qi LB60 MIPS board to devicetree and makes it
> use all the shiny new drivers that have been developed or updated
> recently.
>
> All the crappy old drivers and custom code can be dropped since they
>
https://bugs.freedesktop.org/show_bug.cgi?id=111244
Michel Dänzer changed:
What|Removed |Added
Attachment #144901|text/x-log |text/plain
mime type|
https://bugs.freedesktop.org/show_bug.cgi?id=111228
--- Comment #4 from Maik Freudenberg ---
Both amdgpu and modesetting driver were tested, same effect.
Most notewothy in the non-prime modesetting driver case is this:
[ 5.477] (EE) modeset(0): [DRI2] No driver mapping found for PCI device
https://bugs.freedesktop.org/show_bug.cgi?id=111228
Maik Freudenberg changed:
What|Removed |Added
Summary|PRIME output screen satys |PRIME output screen stays
If CONFIG_DRM_TOSHIBA_TC358764=y but CONFIG_DRM_KMS_HELPER=m,
building fails:
drivers/gpu/drm/bridge/tc358764.o:(.rodata+0x228): undefined reference to
`drm_atomic_helper_connector_reset'
drivers/gpu/drm/bridge/tc358764.o:(.rodata+0x240): undefined reference to
Hi Anders,
On Fri, Jul 26, 2019 at 01:27:41PM +0200, Anders Roxell wrote:
> When fall-through warnings was enabled by default, commit d93512ef0f0e
> ("Makefile: Globally enable fall-through warning"), the following
> warnings was starting to show up:
>
> ../drivers/gpu/drm/arm/malidp_hw.c: In
https://bugs.freedesktop.org/show_bug.cgi?id=110674
--- Comment #52 from Peter Hercek ---
I'm getting hangs-up with kernels 5.2.3 (often) and 5.1.15 (less often).
Radeon VII with 3 monitors. Each monitor connected through DP.
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=111232
Michel Dänzer changed:
What|Removed |Added
Attachment #144891|text/x-log |text/plain
mime type|
https://bugs.freedesktop.org/show_bug.cgi?id=111228
--- Comment #3 from Michel Dänzer ---
>From the attached bug report log:
*** /usr/share/X11/xorg.conf.d/10-amdgpu.conf
*** ls: -rw-r--r-- 1 root root 98 2019-07-12 20:45:36.635624123 +1000
/usr/share/X11/xorg.conf.d/10-amdgpu.conf
Section
https://bugs.freedesktop.org/show_bug.cgi?id=111211
--- Comment #5 from Bráulio Barros de Oliveira ---
The issue might appear only after suspend and resume of the laptop.
--
You are receiving this mail because:
You are the assignee for the bug.___
https://bugs.freedesktop.org/show_bug.cgi?id=111244
--- Comment #5 from Michel Dänzer ---
(In reply to cspack from comment #4)
> The first bisect pointed to a merge commit so the second was done to bisect
> within the merged commits.
That doesn't invalidate my previous comment. :) git bisect
On Fri, Jul 26, 2019 at 06:15:46PM +0200, Daniel Vetter wrote:
> On Fri, Jul 26, 2019 at 4:44 PM Brian Starkey wrote:
> >
> > On Fri, Jul 26, 2019 at 04:23:56PM +0200, Daniel Vetter wrote:
> > > On Fri, Jul 26, 2019 at 08:13:00AM +, Lowry Li (Arm Technology China)
> > > wrote:
> > > >
Hi Anders,
On 7/26/19 6:28 AM, Anders Roxell wrote:
> When fall-through warnings was enabled by default the following warnings
> was starting to show up:
>
> ../drivers/video/fbdev/sh_mobile_lcdcfb.c: In function
> ‘sh_mobile_lcdc_channel_fb_init’:
>
https://bugs.freedesktop.org/show_bug.cgi?id=111248
Bug ID: 111248
Summary: Navi10 Font rendering issue in Overwatch
Product: Mesa
Version: git
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
https://bugs.freedesktop.org/show_bug.cgi?id=111231
--- Comment #12 from Pierre-Eric Pelloux-Prayer
---
Thanks for the bug report.
I could reproduce the bug using the provided apitrace, both on a Ryzen platform
and on a Vega Mobile laptop (can't reproduce on Navi).
Using MESA_DEBUG=flush or
https://bugs.freedesktop.org/show_bug.cgi?id=107559
--- Comment #7 from g.grazi...@gmail.com ---
Similar problem over here: everything works fine with amdgpu.dc=0. Without it
the colors are way darker.
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=109456
libgra...@gmail.com changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
On 2019-07-26 11:06 p.m., Sam Ravnborg wrote:
> DRM_WAIT_ON() is from the deprecated drm_os_linux header and
> the modern replacement is the wait_event_*.
>
> The return values differ, so a conversion is needed to
> keep the original interface towards userspace.
> Introduced a switch/case to make
Hi Sébastien,
On Mon, Jul 29, 2019 at 11:14 AM Sébastien Szymanski
wrote:
> config DRM_MXSFB
> - tristate "i.MX23/i.MX28/i.MX6SX MXSFB LCD controller"
> + tristate "i.MX23/i.MX28/i.MX6SX/i.MX6UL MXSFB LCD controller"
This IP is also found on i.MX6SL, i.MX7D, i.MX7S, i.MX8M,
Hi Sébastien,
On Mon, Jul 29, 2019 at 11:27:37AM -0300, Fabio Estevam wrote:
> Hi Sébastien,
>
> On Mon, Jul 29, 2019 at 11:14 AM Sébastien Szymanski
> wrote:
>
> > config DRM_MXSFB
> > - tristate "i.MX23/i.MX28/i.MX6SX MXSFB LCD controller"
> > + tristate
https://bugs.freedesktop.org/show_bug.cgi?id=111234
--- Comment #2 from Nicholas Kazlauskas ---
This is almost certainly a duplicate of:
https://bugzilla.kernel.org/show_bug.cgi?id=204181
I think something in KDE plasma changed recently for how multi monitor support
is handled and how commits
https://bugs.freedesktop.org/show_bug.cgi?id=109456
--- Comment #8 from libgra...@gmail.com ---
Got back to this again recently and can confirm it's fixed in Qemu git (for
4.1) now.
Many thanks :)
--
You are receiving this mail because:
You are the assignee for the
On Fri, Jul 26, 2019 at 06:36:01PM +0200, Maxime Ripard wrote:
> > +
> > + dvdd12-supply:
> > +maxItems: 1
> > +description: Regulator for 1.2V digital core power.
> > +$ref: /schemas/types.yaml#/definitions/phandle
> > +
> > + dvdd25-supply:
> > +maxItems: 1
> > +
https://bugzilla.kernel.org/show_bug.cgi?id=204365
Bug ID: 204365
Summary: amdgpu crashes when using parameter
"drm.edid_firmware"
Product: Drivers
Version: 2.5
Kernel Version: 5.2.4
Hardware: All
OS:
https://bugs.freedesktop.org/show_bug.cgi?id=110488
yanhua <78666...@qq.com> changed:
What|Removed |Added
CC||dri-devel@lists.freedesktop
https://bugs.freedesktop.org/show_bug.cgi?id=111229
--- Comment #7 from weden...@yandex.ru ---
Created attachment 144907
--> https://bugs.freedesktop.org/attachment.cgi?id=144907=edit
kernel 5.1
I've narrowed it down to kernel 5.1. There are a lot of amdgpu changes in 5.1
(Vega related changes
On Fri, 19 Jul 2019, "Koenig, Christian" wrote:
> Am 18.07.19 um 18:46 schrieb Chris Wilson:
>> Quoting Sam Ravnborg (2019-07-18 17:14:58)
>>> drm_print.h used DRM_NAME - thus adding a dependency from
>>> include/drm/drm_print.h => uapi/drm/drm.h
>>>
>>> Hardcode the name "drm" to break this
https://bugs.freedesktop.org/show_bug.cgi?id=109206
--- Comment #63 from Talha Khan ---
I updated my kernel to 5.1.19, and the firwmare files were updated, but I
wasn't able to boot. I had to boot back into 5.1.16 and perform the workaround
before being able to boot into 5.1.19.
--
You are
On Sun, 14 Jul 2019 16:30:08 +0530
Ramalingam C wrote:
> This patch adds a DRM ENUM property to the selected connectors.
> This property is used for mentioning the protected content's type
> from userspace to kernel HDCP authentication.
>
> Type of the stream is decided by the protected content
https://bugs.freedesktop.org/show_bug.cgi?id=110488
--- Comment #2 from yanhua <78666...@qq.com> ---
I encounter this bug too. it causes my gpu failed to any thing.
--
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the
https://bugzilla.kernel.org/show_bug.cgi?id=204363
Bug ID: 204363
Summary: EDID from Acer P1266 rejected as invalid
Product: Drivers
Version: 2.5
Kernel Version: 5.2.4
Hardware: All
OS: Linux
Tree: Mainline
> >>
> >> Even then it so useless (which drm driver is this message for???) that I
> >> want to remove them all :(
> >
> > Yeah, agree. I mean it is nice if the core drm functions use a prefix
> > for debug output.
> >
> > But I actually don't see the point for individual drivers.
>
> We should
1 - 100 of 152 matches
Mail list logo
