Use the mtk_pwm_data struction to define different registers
and add MT8183 specific register operations, such as MT8183
have commit register, needs to enable double buffer
before writing register, and needs to select commit mode
and use PWM_PERIOD/PWM_HIGH_WIDTH.
Signed-off-by: Jitao Shi
---
Am 15.01.19 um 23:01 schrieb Grodzovsky, Andrey:
On 01/11/2019 05:03 PM, Andrey Grodzovsky wrote:
On 01/11/2019 02:11 PM, Koenig, Christian wrote:
Am 11.01.19 um 16:37 schrieb Grodzovsky, Andrey:
On 01/11/2019 04:42 AM, Koenig, Christian wrote:
Am 10.01.19 um 16:56 schrieb Grodzovsky,
On Tue, 15 Jan 2019, Lyude Paul wrote:
> Something that I completely missed when implementing the new MST VCPI
> atomic helpers is that with those helpers, there's technically a chance
> of us having to grab additional modeset locks in ->compute_config() and
> furthermore, that means we have the
Am 16.01.19 um 01:33 schrieb Benjamin Herrenschmidt:
> On Tue, 2019-01-15 at 22:31 +1100, Michael Ellerman wrote:
As far as I know Power doesn't really supports un-cached memory at all,
except for a very very old and odd configuration with AGP.
>>> Hopefully Michael/Ben can elaborate
Am 16.01.19 um 08:09 schrieb Thomas Hellstrom:
> On Tue, 2019-01-15 at 21:58 +0100, h...@lst.de wrote:
>> On Tue, Jan 15, 2019 at 07:13:11PM +, Koenig, Christian wrote:
>>> Thomas is correct that the interface you propose here doesn't work
>>> at
>>> all for GPUs.
>>>
>>> The kernel driver is
On Tue, 2019-01-15 at 21:58 +0100, h...@lst.de wrote:
> On Tue, Jan 15, 2019 at 07:13:11PM +, Koenig, Christian wrote:
> > Thomas is correct that the interface you propose here doesn't work
> > at
> > all for GPUs.
> >
> > The kernel driver is not informed of flush/sync, but rather just
> >
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Hi, Chunhui:
On Fri, 2019-01-04 at 15:03 +0800, chunhui dai wrote:
> The parent rate of hdmi phy had set by DPI driver.
The difference of DPI driver in MT8173 and MT2701 is
static const struct mtk_dpi_conf mt8173_conf = {
.cal_factor = mt8173_calculate_factor,
.reg_h_fre_con =
On Wed, Jan 16, 2019 at 07:30:02AM +0100, Gerd Hoffmann wrote:
> Hi,
>
> > + if (!dma_map_sg(dev->dev, xen_obj->sgt->sgl, xen_obj->sgt->nents,
> > + DMA_BIDIRECTIONAL)) {
> > + ret = -EFAULT;
> > + goto fail_free_sgt;
> > + }
>
> Hmm, so it seems the
Hi,
> + if (!dma_map_sg(dev->dev, xen_obj->sgt->sgl, xen_obj->sgt->nents,
> + DMA_BIDIRECTIONAL)) {
> + ret = -EFAULT;
> + goto fail_free_sgt;
> + }
Hmm, so it seems the arm guys could not come up with a suggestion how to
solve that one in a
Yue,
Thanks,
Reviewed-by: Thomas Hellstrom
Will include in the next -next pull.
/Thomas
On Wed, 2019-01-16 at 01:55 +, YueHaibing wrote:
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/gpu/drm/vmwgfx/vmwgfx_surface.c: In function
> 'vmw_hw_surface_destroy':
>
On Tue, Jan 15, 2019 at 5:41 AM Daniel Vetter wrote:
>
> Having the probe helper stuff (which pretty much everyone needs) in
> the drm_crtc_helper.h file (which atomic drivers should never need) is
> confusing. Split them out.
>
> To make sure I actually achieved the goal here I went through all
For Mediatek drm driver, use fbdev emulation to create a framebuffer
device.
Signed-off-by: CK Hu
---
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index
For some application which need kernel virtual address, such as fbcon,
implement these function to map/unmap kernel virtual address of prime
buffer.
Signed-off-by: CK Hu
---
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 2 ++
drivers/gpu/drm/mediatek/mtk_drm_gem.c | 46 ++
Hi all,
Today's linux-next merge of the drm-misc tree got conflicts in:
drivers/gpu/drm/i915/intel_dp.c
drivers/gpu/drm/i915/intel_drv.h
between commits:
e845f099f1c6 ("drm/i915/dsc: Add Per connector debugfs node for DSC
support/enable")
f6bff60e927b ("drm/i915/icl: Fix HPD handling
https://bugs.freedesktop.org/show_bug.cgi?id=109360
Sylvain BERTRAND changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
On 1/14/19 11:13 AM, Liam Mark wrote:
> On Fri, 11 Jan 2019, Andrew F. Davis wrote:
>
>> Buffers may not be mapped from the CPU so skip cache maintenance here.
>> Accesses from the CPU to a cached heap should be bracketed with
>> {begin,end}_cpu_access calls so maintenance should not be needed
[CC Greg]
On Tuesday, January 15, 2019 1:04:02 AM CET Rafael J. Wysocki wrote:
> [CC Lukas and linux-pm]
>
> On Mon, Jan 14, 2019 at 1:32 PM Rafael J. Wysocki wrote:
> >
> > On Fri, Jan 11, 2019 at 3:49 PM Russell King - ARM Linux
> > wrote:
>
> [cut]
>
> > >
> > > This thread is discussing
https://bugs.freedesktop.org/show_bug.cgi?id=106175
--- Comment #102 from tempel.jul...@gmail.com ---
Is that with latest git version of the xf86 DDX driver, including the PR Michel
posted?
I had subpar game performance (looked like half of the fps) too without vsync
the last time I checked
Hi Eugen.
Patch looks good, but a small improvement proposal.
On Mon, Jan 14, 2019 at 09:43:31AM +, eugen.hris...@microchip.com wrote:
> From: Eugen Hristev
>
> PDA 91-00156-A0 5.0 is a 5.0" WVGA TFT LCD panel.
> This panel with backlight is found in PDA 5" LCD screen (TM5000 series or
>
Hi Eugen.
On Mon, Jan 14, 2019 at 09:43:26AM +, eugen.hris...@microchip.com wrote:
> From: Eugen Hristev
>
> Precision Design Associates, Inc. (PDA) manufactures standard and custom
> capacitive touch screens, LCD's embedded controllers and custom embedded
> software. They specialize in
On 01/11/2019 05:03 PM, Andrey Grodzovsky wrote:
>
>
> On 01/11/2019 02:11 PM, Koenig, Christian wrote:
>> Am 11.01.19 um 16:37 schrieb Grodzovsky, Andrey:
>>> On 01/11/2019 04:42 AM, Koenig, Christian wrote:
Am 10.01.19 um 16:56 schrieb Grodzovsky, Andrey:
> [SNIP]
But we will
0-DAY reported the following bug:
tree: git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
head: 21376e2c3c5bad5e87ba700c055c8a8235c2bfd5
commit: e9eafcb589213395232084a2378e2e90f67feb29 [1/2] drm: move
drm_can_sleep() to drm_util.h
config: alpha-allmodconfig (attached as .config)
...
https://bugs.freedesktop.org/show_bug.cgi?id=106175
--- Comment #101 from Hans D ---
For me the TearFree Option works flawlessly with amdgpu.dc=0 on 5.0rc2 and
4.20.1, but 3d games lag. With amdgpu.dc=1 there are some slight hiccups every
2-3 seconds (Firefox`s autoscrolling, video playback
On Fri, Jan 11, 2019 at 05:51:14AM +0200, Laurent Pinchart wrote:
> The OSD Displays OSD070T1718-19TS is a 7" WVGA (800x480) 24bit RGB panel
> and is compatible with the simple-panel bindings.
>
> Signed-off-by: Laurent Pinchart
> ---
> .../display/panel/osddisplays,osd070t1718-19ts.txt
On Fri, 11 Jan 2019 05:51:09 +0200, Laurent Pinchart wrote:
> The TFP410 supports configuration of several input bus parameters
> through either the I2C port or chip pins. In the latter case, we need to
> specify those parameters in DT.
>
> Two new properties are added, ti,deskew to specify the
https://bugs.freedesktop.org/show_bug.cgi?id=102909
--- Comment #4 from Christopher Clapp ---
(In reply to Pander from comment #3)
> Christopher, are you still experiencing this bug?
Pander, the Radeon graphics card in my computer died, so I replaced it with an
Nvidia card. I didn't experience
On Fri, 11 Jan 2019 05:51:13 +0200, Laurent Pinchart wrote:
> OSD Displays is a panel manufacturer. It has been acquired by New Vision
> Displays in 2015 but continues to operate under its own brand name.
>
> Signed-off-by: Laurent Pinchart
> ---
>
On Tue, Jan 15, 2019 at 07:13:11PM +, Koenig, Christian wrote:
> Thomas is correct that the interface you propose here doesn't work at
> all for GPUs.
>
> The kernel driver is not informed of flush/sync, but rather just setups
> coherent mappings between system memory and devices.
>
> In
https://bugs.freedesktop.org/show_bug.cgi?id=109239
--- Comment #8 from Raman Gupta ---
Created attachment 143137
--> https://bugs.freedesktop.org/attachment.cgi?id=143137=edit
Xorg.0.log with modeset ddx instead of amdgpu ddx
(In reply to Michel Dänzer from comment #4)
> Does it also happen
On Tue, Jan 15, 2019 at 03:08:00PM -0500, Lyude Paul wrote:
> Something that I completely missed when implementing the new MST VCPI
> atomic helpers is that with those helpers, there's technically a chance
> of us having to grab additional modeset locks in ->compute_config() and
> furthermore,
Something that I completely missed when implementing the new MST VCPI
atomic helpers is that with those helpers, there's technically a chance
of us having to grab additional modeset locks in ->compute_config() and
furthermore, that means we have the potential to hit a normal modeset
deadlock.
https://bugs.freedesktop.org/show_bug.cgi?id=106175
--- Comment #100 from Brandon Wright ---
(In reply to tempel.julian from comment #99)
> Does the trick for me too, TearFree with amdgpu.dc=0 seems to be completely
> smooth now. Delay / input latency seems to be the same between amdgpu.dc=1
>
On Fri, 11 Jan 2019 15:18:55 +, Peter Rosin wrote:
> DS90C185 has a shutdown pin which does not fit in the lvds-transmitter
> binding, which is meant to be generic.
>
> The sister chip DS90C187 is similar to DS90C185, describe it here as well.
>
> Signed-off-by: Peter Rosin
> ---
>
https://bugs.freedesktop.org/show_bug.cgi?id=109370
MIka R changed:
What|Removed |Added
Severity|normal |minor
Priority|medium
Am 15.01.19 um 19:31 schrieb h...@lst.de:
> On Tue, Jan 15, 2019 at 06:03:39PM +, Thomas Hellstrom wrote:
>> In the graphics case, it's probably because it doesn't fit the graphics
>> use-cases:
>>
>> 1) Memory typically needs to be mappable by another device. (the "dma-
>> buf" interface)
>
https://bugs.freedesktop.org/show_bug.cgi?id=109370
Bug ID: 109370
Summary: [Runelite GPU plugin] Enabling GPU plugin produces
incorrect rendering
Product: Mesa
Version: git
Hardware: x86-64 (AMD64)
OS:
On 1/15/19 10:43 AM, Laura Abbott wrote:
On 1/15/19 7:58 AM, Andrew F. Davis wrote:
On 1/14/19 8:32 PM, Laura Abbott wrote:
On 1/11/19 10:05 AM, Andrew F. Davis wrote:
The "unmapped" heap is very similar to the carveout heap except
the backing memory is presumed to be unmappable by the host,
On 1/15/19 10:38 AM, Andrew F. Davis wrote:
On 1/15/19 11:45 AM, Liam Mark wrote:
On Tue, 15 Jan 2019, Andrew F. Davis wrote:
On 1/14/19 11:13 AM, Liam Mark wrote:
On Fri, 11 Jan 2019, Andrew F. Davis wrote:
Buffers may not be mapped from the CPU so skip cache maintenance here.
Accesses
https://bugzilla.kernel.org/show_bug.cgi?id=202217
Haxk20 (haxk...@gmail.com) changed:
What|Removed |Added
Severity|normal |high
--
You are receiving
On 1/15/19 9:47 AM, Andrew F. Davis wrote:
On 1/14/19 8:39 PM, Laura Abbott wrote:
On 1/11/19 10:05 AM, Andrew F. Davis wrote:
Hello all,
This is a set of (hopefully) non-controversial cleanups for the ION
framework and current set of heaps. These were found as I start to
familiarize myself
On 1/15/19 7:58 AM, Andrew F. Davis wrote:
On 1/14/19 8:32 PM, Laura Abbott wrote:
On 1/11/19 10:05 AM, Andrew F. Davis wrote:
The "unmapped" heap is very similar to the carveout heap except
the backing memory is presumed to be unmappable by the host, in
my specific case due to firewalls. This
Daniel Vetter writes:
> On Tue, Jan 15, 2019 at 03:04:18PM +, James Clarke wrote:
>> Like GNU/Linux, GNU/kFreeBSD's sys/types.h does not define the uintX_t
>> types, which differs from the BSDs' headers. Thus we should include
>> stdint.h to ensure we have all the required integer types.
>>
On 1/15/19 12:38 PM, Andrew F. Davis wrote:
> On 1/15/19 11:45 AM, Liam Mark wrote:
>> On Tue, 15 Jan 2019, Andrew F. Davis wrote:
>>
>>> On 1/14/19 11:13 AM, Liam Mark wrote:
On Fri, 11 Jan 2019, Andrew F. Davis wrote:
> Buffers may not be mapped from the CPU so skip cache
On 1/15/19 11:45 AM, Liam Mark wrote:
> On Tue, 15 Jan 2019, Andrew F. Davis wrote:
>
>> On 1/14/19 11:13 AM, Liam Mark wrote:
>>> On Fri, 11 Jan 2019, Andrew F. Davis wrote:
>>>
Buffers may not be mapped from the CPU so skip cache maintenance here.
Accesses from the CPU to a cached
On Tue, Jan 15, 2019 at 06:03:39PM +, Thomas Hellstrom wrote:
> In the graphics case, it's probably because it doesn't fit the graphics
> use-cases:
>
> 1) Memory typically needs to be mappable by another device. (the "dma-
> buf" interface)
And there is nothing preventing dma-buf sharing of
https://bugs.freedesktop.org/show_bug.cgi?id=106175
--- Comment #99 from tempel.jul...@gmail.com ---
Does the trick for me too, TearFree with amdgpu.dc=0 seems to be completely
smooth now. Delay / input latency seems to be the same between amdgpu.dc=1 and
0, I suppose this is as low as it can be
On Tue, 2019-01-15 at 16:20 +0100, h...@lst.de wrote:
> On Tue, Jan 15, 2019 at 03:24:55PM +0100, Christian König wrote:
> > Yeah, indeed. Bounce buffers are an absolute no-go for GPUs.
> >
> > If the DMA API finds that a piece of memory is not directly
> > accessible by
> > the GPU we need to
https://bugs.freedesktop.org/show_bug.cgi?id=106175
--- Comment #98 from Michel Dänzer ---
(In reply to Brandon Wright from comment #95)
> For me, at least, it hiccups regularly every second and introduces
> noticeable latency. With dc=1 it's smooth
Thanks, I was able to reproduce the hiccups
On 1/14/19 8:39 PM, Laura Abbott wrote:
> On 1/11/19 10:05 AM, Andrew F. Davis wrote:
>> Hello all,
>>
>> This is a set of (hopefully) non-controversial cleanups for the ION
>> framework and current set of heaps. These were found as I start to
>> familiarize myself with the framework to help in
https://bugs.freedesktop.org/show_bug.cgi?id=109366
--- Comment #2 from Alex Deucher ---
Created attachment 143133
--> https://bugs.freedesktop.org/attachment.cgi?id=143133=edit
possible fix
Does this patch fix it? dGPUs are always add in cards, so they always plug
into an upstream port on
On 1/14/19 10:36 PM, Noralf Trønnes wrote:
This switches to drm_atomic_helper_dirtyfb() as the framebuffer dirty
handler. All flushing will now happen in the pipe functions.
Also enable the damage plane property for all except repaper which can
only do full updates.
ili9225:
This change made
https://bugzilla.kernel.org/show_bug.cgi?id=202263
--- Comment #6 from Alex Deucher (alexdeuc...@gmail.com) ---
Created attachment 280505
--> https://bugzilla.kernel.org/attachment.cgi?id=280505=edit
possible fix
Does this patch fix the issue?
--
You are receiving this mail because:
You are
https://bugs.freedesktop.org/show_bug.cgi?id=109366
Alex Deucher changed:
What|Removed |Added
Component|DRM/AMDgpu |DRM/Radeon
--
You are receiving this
https://bugs.freedesktop.org/show_bug.cgi?id=109366
--- Comment #1 from Alex Williamson ---
Use a Q35 VM configuration with the assigned GPU downstream of an emulated PCIe
root port as a workaround. The driver assumes this configuration, presumably
it's the only one that exists on bare metal,
On 1/14/19 8:32 PM, Laura Abbott wrote:
> On 1/11/19 10:05 AM, Andrew F. Davis wrote:
>> The "unmapped" heap is very similar to the carveout heap except
>> the backing memory is presumed to be unmappable by the host, in
>> my specific case due to firewalls. This memory can still be
>> allocated
Hi,
(Sending those kind of bug reports to linux-sunxi doesn't really work,
you should Cc at least the ML involved in the development of the
driver at fault).
On Mon, Jan 14, 2019 at 01:29:34PM +, Priit Laes wrote:
> I have a somewhat curious case with one HDMI/DVI screen that fails
> to
Hi Daniel, Dave,
Here is the drm-misc-next PR for this week.
Thanks!
Maxime
drm-misc-next-2019-01-15:
drm-misc-next for 5.1:
UAPI Changes:
Cross-subsystem Changes:
Core Changes:
- Reorganisation of drm_device and drm_framebuffer headers
- Cleanup of the drmP inclusion
- Fix leaks in the
https://bugs.freedesktop.org/show_bug.cgi?id=107978
--- Comment #42 from Jerry Zuo ---
We are currently looking at the startup issue now.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
https://bugs.freedesktop.org/show_bug.cgi?id=109366
Bug ID: 109366
Summary: NULL pointer at pcie_capability_read_dword with Radeon
SI vfio passthrough
Product: DRI
Version: unspecified
Hardware: x86-64 (AMD64)
On Tue, Jan 15, 2019 at 04:15:49PM +0100, Daniel Vetter wrote:
> On Tue, Jan 15, 2019 at 02:45:53PM +0100, Greg Kroah-Hartman wrote:
> > On Tue, Jan 15, 2019 at 01:12:28PM +0100, Daniel Vetter wrote:
> > > On Tue, Jan 15, 2019 at 11:38:29AM +0100, Greg Kroah-Hartman wrote:
> > > > On Tue, Jan 15,
On Tue, Jan 15, 2019 at 03:24:55PM +0100, Christian König wrote:
> Yeah, indeed. Bounce buffers are an absolute no-go for GPUs.
>
> If the DMA API finds that a piece of memory is not directly accessible by
> the GPU we need to return an error and not try to use bounce buffers behind
> the
On Tue, Jan 15, 2019 at 03:04:18PM +, James Clarke wrote:
> Like GNU/Linux, GNU/kFreeBSD's sys/types.h does not define the uintX_t
> types, which differs from the BSDs' headers. Thus we should include
> stdint.h to ensure we have all the required integer types.
>
> Signed-off-by: James Clarke
On Tue, Jan 15, 2019 at 02:45:53PM +0100, Greg Kroah-Hartman wrote:
> On Tue, Jan 15, 2019 at 01:12:28PM +0100, Daniel Vetter wrote:
> > On Tue, Jan 15, 2019 at 11:38:29AM +0100, Greg Kroah-Hartman wrote:
> > > On Tue, Jan 15, 2019 at 11:27:54AM +0100, Daniel Vetter wrote:
> > > > It's a debug
Like GNU/Linux, GNU/kFreeBSD's sys/types.h does not define the uintX_t
types, which differs from the BSDs' headers. Thus we should include
stdint.h to ensure we have all the required integer types.
Signed-off-by: James Clarke
---
include/uapi/drm/drm.h | 1 +
1 file changed, 1 insertion(+)
https://bugzilla.kernel.org/show_bug.cgi?id=202217
--- Comment #7 from Haxk20 (haxk...@gmail.com) ---
I did some further testing. The bug seems to be that even when i run just TTY
session without GNOME even launched and i suspend the laptop to turn off the
screen then the screen doesnt come back
On Tue, Jan 15, 2019 at 10:17:09AM +0530, Nishad Kamdar wrote:
> This switches the fbtft driver to use GPIO descriptors
> rather than numerical gpios:
>
> Utilize the GPIO library's intrinsic handling of OF GPIOs
> and polarity. If the line is flagged active low, gpiolib
> will deal with this.
>
On Sat, Dec 01, 2018 at 12:31:47PM +0100, Hans de Goede wrote:
> On devices with a burst_mode_ratio which is not 100 (1:1), the pclk
> will have a different value then drm_display_mode.clock .
>
> On a Prowise PT301 tablet where vbt.lfp_lvds_vbt_mode.clock is 66100 and
> burst_mode_ratio is 130
On 1/15/19 2:26 PM, Neil Armstrong wrote:
On 15/01/2019 11:41, Daniel Vetter wrote:
Having the probe helper stuff (which pretty much everyone needs) in
the drm_crtc_helper.h file (which atomic drivers should never need) is
confusing. Split them out.
To make sure I actually achieved the goal
On Sat, Dec 01, 2018 at 12:31:46PM +0100, Hans de Goede wrote:
> The display engine has 2 dithering enable bits which both need to be set
> for dithering to happen, 1 in the PIPECONF register which is taken care of
> by i9xx_set_pipeconf() and a second bit at the encoder level.
>
> The dsi code
https://bugs.freedesktop.org/show_bug.cgi?id=106175
--- Comment #97 from Michel Dänzer ---
(In reply to tempel.julian from comment #96)
> I also noticed that sometimes switching between Vulkan fullscreen windows
> (radv) and desktop can break TearFree, it needs to be reactivated then. I
>
On Sat, Dec 01, 2018 at 12:31:45PM +0100, Hans de Goede wrote:
> There are 3 problems with the dsi code's pipe_bpp handling for 6 bpc
> pixel-formats which this commit addresses:
>
> 1) It assumes that the pipe_bpp is the same as the bpp going over the dsi
> lanes. This assumption is not valid
On Tue, Jan 15, 2019 at 02:29:19PM +0100, Daniel Vetter wrote:
> On Tue, Jan 15, 2019 at 2:27 PM Liviu Dudau wrote:
> >
> > On Tue, Jan 15, 2019 at 01:38:19PM +0100, Daniel Vetter wrote:
> > > On Tue, Jan 15, 2019 at 1:24 PM Liviu Dudau wrote:
> > > >
> > > > On Tue, Jan 15, 2019 at 01:05:47PM
Hi all,
I would like to have some Acked-by's from you, the distro media
folks Cc'd here, to document your intent to start using Intel's
new media driver[1]. So if you recognize yourself (or are otherwise
interested), please read on.
TL;DR Distro folks, please give your Acked-by on patch [5/6]
I
Hi Daniel,
Thank you for the patch.
On Tuesday, 15 January 2019 12:41:37 EET Daniel Vetter wrote:
> Having the probe helper stuff (which pretty much everyone needs) in
> the drm_crtc_helper.h file (which atomic drivers should never need) is
> confusing. Split them out.
>
> To make sure I
https://bugs.freedesktop.org/show_bug.cgi?id=109359
--- Comment #3 from Timur Kristóf ---
Created attachment 143127
--> https://bugs.freedesktop.org/attachment.cgi?id=143127=edit
xorg log
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=109359
--- Comment #2 from Timur Kristóf ---
Created attachment 143126
--> https://bugs.freedesktop.org/attachment.cgi?id=143126=edit
dmesg log
--
You are receiving this mail because:
You are the assignee for the
Am 15.01.19 um 15:17 schrieb Thomas Hellstrom:
Hi, Christoph,
On Mon, 2019-01-14 at 10:48 +0100, Christoph Hellwig wrote:
On Thu, Jan 10, 2019 at 04:42:18PM -0700, Jason Gunthorpe wrote:
Changes since the RFC:
- Rework vmwgfx too [CH]
- Use a distinct type for the DMA page iterator [CH]
- Do
https://bugs.freedesktop.org/show_bug.cgi?id=105733
--- Comment #54 from OliverHB ---
Did anyone ever try switching to a text console (CTRL-ALT-F[1-6]) and back
(usually CTRl-ALT-F7)to graphical screen? That does the trick for me! However,
I wouldn't mind if there is a solution which makes that
Hi, Christoph,
On Mon, 2019-01-14 at 10:48 +0100, Christoph Hellwig wrote:
> On Thu, Jan 10, 2019 at 04:42:18PM -0700, Jason Gunthorpe wrote:
> > > Changes since the RFC:
> > > - Rework vmwgfx too [CH]
> > > - Use a distinct type for the DMA page iterator [CH]
> > > - Do not have a #ifdef [CH]
>
From: Oleksandr Andrushchenko
When GEM backing storage is allocated with drm_gem_get_pages
the backing pages may be cached, thus making it possible that
the backend sees only partial content of the buffer which may
lead to screen artifacts. Make sure that the frontend's
memory is coherent and
https://bugs.freedesktop.org/show_bug.cgi?id=106175
--- Comment #96 from tempel.jul...@gmail.com ---
Yep, that's my observation as well (no compositor vsync enbled at the same
time).
I also noticed that sometimes switching between Vulkan fullscreen windows
(radv) and desktop can break TearFree,
On Tue, Jan 15, 2019 at 01:12:28PM +0100, Daniel Vetter wrote:
> On Tue, Jan 15, 2019 at 11:38:29AM +0100, Greg Kroah-Hartman wrote:
> > On Tue, Jan 15, 2019 at 11:27:54AM +0100, Daniel Vetter wrote:
> > > It's a debug hack flag useful to work around driver bugs. That's not a
> > > good idea for a
On Tue, Jan 15, 2019 at 1:23 PM Liviu Dudau wrote:
>
> On Tue, Jan 15, 2019 at 01:08:36PM +0100, Daniel Vetter wrote:
> > On Tue, Jan 15, 2019 at 10:51:02AM +, Liviu Dudau wrote:
> > > On Tue, Jan 15, 2019 at 09:47:25PM +1100, Stephen Rothwell wrote:
> > > > Hi Liviu,
> > > >
> > > > On Tue,
On Tue, Jan 15, 2019 at 2:27 PM Liviu Dudau wrote:
>
> On Tue, Jan 15, 2019 at 01:38:19PM +0100, Daniel Vetter wrote:
> > On Tue, Jan 15, 2019 at 1:24 PM Liviu Dudau wrote:
> > >
> > > On Tue, Jan 15, 2019 at 01:05:47PM +0100, Daniel Vetter wrote:
> > > > On Mon, Jan 14, 2019 at 03:28:27PM
On Tue, Jan 15, 2019 at 01:38:19PM +0100, Daniel Vetter wrote:
> On Tue, Jan 15, 2019 at 1:24 PM Liviu Dudau wrote:
> >
> > On Tue, Jan 15, 2019 at 01:05:47PM +0100, Daniel Vetter wrote:
> > > On Mon, Jan 14, 2019 at 03:28:27PM +, Ayan Halder wrote:
> > > > One needs to translate the Gralloc
On Mon, Jan 14, 2019 at 05:29:31PM -0500, Lyude Paul wrote:
> Something that I completely missed when implementing the new MST VCPI
> atomic helpers is that with those helpers, there's technically a chance
> of us having to grab additional modeset locks in ->compute_config() and
> furthermore,
https://bugs.freedesktop.org/show_bug.cgi?id=104345
--- Comment #13 from bernhardu ---
Happened again.
A way to avoid that crash may be to not stay int first cold boot.
I am not sure but I think I never saw this when system was
running from a rebooted state (warm boot).
[0.00] Linux
https://bugs.freedesktop.org/show_bug.cgi?id=109239
--- Comment #7 from Harry Wentland ---
If you didn't say you tried swapping monitors and cables I'd say it was a cable
issue.
Are those high refresh rate displays (120Hz+)? If so you might want to give
what's suggested in this comment a try:
On Tue, Jan 15, 2019 at 1:24 PM Liviu Dudau wrote:
>
> On Tue, Jan 15, 2019 at 01:05:47PM +0100, Daniel Vetter wrote:
> > On Mon, Jan 14, 2019 at 03:28:27PM +, Ayan Halder wrote:
> > > One needs to translate the Gralloc buffer flags for AFBC (eg
> > > MALI_GRALLOC_INTFMT_AFBC_BASIC) to the
Now we support the TMDS Clock > 3.4GHz and support the SCDC Control
operation in the DW-HDMI Controller, we can enable support for the
HDMI2.0 3840x2160@60/50 RGB444 display modes.
Signed-off-by: Neil Armstrong
Reviewed-by: Andrzej Hajda
---
drivers/gpu/drm/meson/meson_venc.c | 2 ++
1 file
Add support for SCDC Setup for TMDS Clock > 3.4GHz and enable TMDS
Scrambling when supported or mandatory.
This patch also adds an helper to setup the control bit to support
the high TMDS Bit Period/TMDS Clock-Period Ratio as required with
TMDS Clock > 3.4GHz for HDMI2.0 3840x2160@60/50 modes.
In order to support the HDMI2.0 YUV420 display modes, this patch
adds support for the YUV420 TMDS Clock divided by 2 and the controller
passthrough mode.
YUV420 Synopsys PHY support will need some specific configuration table
to support theses modes.
This patch is based on work from Zheng Yang
From: Zheng Yang
To get input/output bus_format/enc_format dynamically, this patch
introduce following functions in plat_data:
- get_input_bus_format
- get_output_bus_format
- get_enc_in_encoding
- get_enc_out_encoding
Signed-off-by: Zheng Yang
Signed-off-by:
This patch adds support for the YUV420 output from the Amlogic Meson SoCs
Video Processing Unit to the HDMI Controller.
The YUV420 is obtained by generating a YUV444 pixel stream like
the classic HDMI display modes, but then the Video Encoder output
can be configured to down-sample the YUV444
With the YUV420 handling, we can dynamically setup the HDMI output
pixel format depending on the mode and connector info.
So now, we can output in YUV444, which is the native video pipeline
format, directly to the HDMI Sink if it's supported without
necessarily involving the HDMI Controller CSC.
This patchset aims to add support for the following HDMI2.0 4k60 modes:
- 594Mhz TMDS frequency needing TMDS Scramling and 1/40 rate for RGB/YUV4:4:4
- 297MHz TMDS frequency with YUV4:2:0 encoding
The first mode uses the SCDC helpers introduced by intel to :
- discover where the monitor support
Now the DW-HDMI Controller supports the HDMI2.0 modes, enable support
for these modes in the connector if the platform supports them.
We limit these modes to DW-HDMI IP version >= 0x200a which
are designed to support HDMI2.0 display modes.
Signed-off-by: Neil Armstrong
Tested-by: Heiko Stuebner
Add support for TMDS Clock > 3.4GHz for HDMI2.0 display modes.
Signed-off-by: Neil Armstrong
---
drivers/gpu/drm/meson/meson_dw_hdmi.c | 23 +++
1 file changed, 19 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/meson/meson_dw_hdmi.c
On 15/01/2019 11:41, Daniel Vetter wrote:
> Having the probe helper stuff (which pretty much everyone needs) in
> the drm_crtc_helper.h file (which atomic drivers should never need) is
> confusing. Split them out.
>
> To make sure I actually achieved the goal here I went through all
> drivers.
1 - 100 of 127 matches
Mail list logo
