On Mon, Mar 04, 2019 at 05:47:09PM +0200, Jani Nikula wrote:
> On Mon, 04 Mar 2019, Maxime Ripard wrote:
> > In some cases, in order to accomodate with displays with poor EDIDs, we
> > need to ignore that the monitor alledgedly supports audio output and
> > disable the audio output.
>
> *sad trom
On Mon, Mar 04, 2019 at 03:45:56PM +0100, Noralf Trønnes wrote:
>
>
> Den 22.02.2019 16.58, skrev Andy Shevchenko:
> > On Fri, Feb 22, 2019 at 01:43:29PM +0100, Noralf Trønnes wrote:
> >> Buffers passed to spi_sync() must be dma-safe even for tiny buffers since
> >> some SPI controllers use DMA f
On Mon, Mar 04, 2019 at 02:10:00PM +0100, Luc Van Oostenryck wrote:
> The method in struct amdgpu_virt_ops::trans_msg() is defined as
> using an 'u32' for its 2nd argument (the request) but the actual
> implementation()s and calls use an 'enum idh_request' for it.
>
> Fix this by using 'enum idh_r
Switch to bitmap_zalloc() to show clearly what we are allocating.
Besides that it returns pointer of bitmap type instead of opaque void *.
Signed-off-by: Andy Shevchenko
---
drivers/gpu/drm/selftests/test-drm_mm.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/d
Thanks for the useful review comments.
With regard to the bugs something between rc1 and rc8 results
in a freeze on poweroff. Power domain doesn't seem to turn off
the vop and hdmi in rc8.
For testing only.
Forgot to ask rob+dt the prefered document name for "rockchip,rk3066-hdmi"
Please advise i
Switch to bitmap_zalloc() to show clearly what we are allocating.
Besides that it returns pointer of bitmap type instead of opaque void *.
Signed-off-by: Andy Shevchenko
---
drivers/gpu/drm/i915/i915_gem.c | 2 +-
drivers/gpu/drm/i915/i915_gem_fence_reg.c | 3 +--
drivers/gpu/d
Hi,
this is the second spin of a patch set that aims to complete the Armada
DRM binding documentation. Compared to the first version it omits the
display-subsystem node and thus is somewhat simpler. Also, the
reserved-mem property has been moved to a separate documentation file.
The he individual
Support Boe Himax8279d 8.0" 1200x1920 TFT LCD panel, it is a MIPI DSI
panel.
Signed-off-by: Jerry Han
Cc: Jitao Shi
Cc: Nick Sanders
Cc: YH Lin
Cc: Rock wang
---
MAINTAINERS |6 +
drivers/gpu/drm/panel/Kconfig| 22 +
drivers/gpu/drm/pane
Switch to bitmap_zalloc() to show clearly what we are allocating.
Besides that it returns pointer of bitmap type instead of opaque void *.
Signed-off-by: Andy Shevchenko
---
drivers/gpu/drm/i915/i915_gem.c | 2 +-
drivers/gpu/drm/i915/i915_gem_fence_reg.c | 3 +--
drivers/gpu/d
Switch to bitmap_zalloc() to show clearly what we are allocating.
Besides that it returns pointer of bitmap type instead of opaque void *.
Signed-off-by: Andy Shevchenko
---
drivers/gpu/drm/selftests/test-drm_mm.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/d
Hi Hans,
On Thu, Feb 28, 2019 at 05:54:21PM +0100, Hans de Goede wrote:
> Hi Heikki,
>
> On 28-02-19 15:47, Heikki Krogerus wrote:
> > Hi Hans,
> >
> > On Thu, Feb 28, 2019 at 12:24:25PM +0100, Hans de Goede wrote:
> > > Hi,
> > >
> > > On 28-02-19 10:15, Heikki Krogerus wrote:
>
>
>
> > > >
Support Boe Himax8279d 8.0" 1200x1920 TFT LCD panel, it is a MIPI DSI
panel.
Signed-off-by: Jerry Han
Cc: Jitao Shi
Cc: Nick Sanders
Cc: YH Lin
Cc: Rock wang
---
MAINTAINERS |6 +
drivers/gpu/drm/panel/Kconfig| 22 +
drivers/gpu/drm/pane
The Boe Himax8279d is a 8.0" panel with a 1200x1920 resolution and
connected to DSI using four lanes.
Signed-off-by: Jerry Han
Cc: Jitao Shi
Cc: Nick Sanders
Cc: YH Lin
Cc: Rock wang
---
.../bindings/display/panel/boe,himax8279d.txt | 24 ++
1 file changed, 24 insert
Support Boe Himax8279d 8.0" 1200x1920 TFT LCD panel, it is a MIPI DSI
panel.
Signed-off-by: Jerry Han
Cc: Jitao Shi
Cc: Derek Basehore
Cc: Rock wang
---
MAINTAINERS |6 +
drivers/gpu/drm/panel/Kconfig| 22 +
drivers/gpu/drm/panel/Makefile
This makes it possible to choose a different pixel format for the
endpoint. Modelled after what other LCD controllers use, including
marvell,pxa2xx-lcdc and atmel,hlcdc-display-controller and perhaps more.
Signed-off-by: Lubomir Rintel
---
.../devicetree/bindings/display/marvell,armada-lcdc.txt
This is the binding for memory that is set aside for allocation of Marvell
Armada framebuffer objects.
Signed-off-by: Lubomir Rintel
---
Changes since v1:
- Moved from bindings/display/armada/
- Removed the marvell,dove-framebuffer string
- Added to the MAINTAINERS entry
.../marvell,armada-fra
The port is a child, not a property. And should be accompanied by an
example. Plus a pair of cosmetic changes that don't seem to deserve a
separate commit.
Signed-off-by: Lubomir Rintel
---
Changes since v1:
- Minor adjustments to the commit message wording.
.../bindings/display/marvell,armada
On Mon, Mar 04, 2019 at 09:41:34AM +, Chris Wilson wrote:
> Quoting Andy Shevchenko (2019-03-04 09:29:08)
> > Switch to bitmap_zalloc() to show clearly what we are allocating.
> > Besides that it returns pointer of bitmap type instead of opaque void *.
>
> Which is confusing; since we explicit
The Boe Himax8279d is a 8.0" panel with a 1200x1920 resolution and
connected to DSI using four lanes.
Signed-off-by: Jerry Han
Cc: Jitao Shi
Cc: Derek Basehore
Cc: Rock wang
---
.../bindings/display/panel/boe,himax8279d.txt | 24 ++
1 file changed, 24 insertions(+)
c
The method in struct amdgpu_virt_ops::trans_msg() is defined as
using an 'u32' for its 2nd argument (the request) but the actual
implementation()s and calls use an 'enum idh_request' for it.
Fix this by using 'enum idh_request' for the method declaration too.
Signed-off-by: Luc Van Oostenryck
--
Use a more generic name, since it will document more compatible LCD
controllers than just that of Dove. Also, there's no point putting it in
a separate directory.
Signed-off-by: Lubomir Rintel
---
Changes since v1:
- Choose a better name than armada/marvell-armada-drm.txt, since
there will be
From: Priit Laes
Even though HDMI connector features hotplug detect pin (HPD), there
are older devices which do not support it. For these devices fall
back to additional check on I2C bus to probe for EDID data.
One known example is HDMI/DVI display with following edid:
$ xxd -p display.edid
00f
On Mon, Mar 04, 2019 at 06:51:33PM +0100, Noralf Trønnes wrote:
> Den 04.03.2019 16.10, skrev Andy Shevchenko:
> > On Mon, Mar 04, 2019 at 03:45:56PM +0100, Noralf Trønnes wrote:
> >> Den 22.02.2019 16.58, skrev Andy Shevchenko:
> >>> On Fri, Feb 22, 2019 at 01:43:29PM +0100, Noralf Trønnes wrote:
There's a generic compatible string and the driver will work on a MMP2 as
well, using the same binding.
Signed-off-by: Lubomir Rintel
---
Changes since v1:
- Added marvell,armada-lcdc compatible string.
.../devicetree/bindings/display/marvell,armada-lcdc.txt | 4 +++-
1 file changed, 3 i
On Mon, Mar 04, 2019 at 03:05:31PM -0500, Alex Deucher wrote:
> On Mon, Mar 4, 2019 at 2:53 PM Eric Anholt wrote:
> >
> > Maxime Ripard writes:
> >
> > > In some cases, in order to accomodate with displays with poor EDIDs, we
> > > need to ignore that the monitor alledgedly supports audio output
Hi,
On Mon, Mar 04, 2019 at 12:06:01PM -0800, Eric Anholt wrote:
> > Since a change of the command line parser can pretty easily get things
> > wrong and introduce regressions, I also worked with a number of unit tests
> > that you can find here: http://code.bulix.org/tpo7dg-607264?raw
>
> Would
Hi Eric,
On Mon, Mar 04, 2019 at 12:02:16PM -0800, Eric Anholt wrote:
> Maxime Ripard writes:
>
> > Signed-off-by: Maxime Ripard
>
> Googling for users of the firmware's hdmi_drive= flag, I'm seeing lots
> of people with hdmi_drive=2 (force HDMI mode) due to Raspberry Pi not
> allowing HDMI au
On Fri, 1 Mar 2019 at 13:24, Andrzej Hajda wrote:
>
> To support local paths both DECON and GSCALER should enable respective
> Smart Deck clocks DSD and GSD.
>
> Signed-off-by: Andrzej Hajda
> ---
> arch/arm64/boot/dts/exynos/exynos5433.dtsi | 25 +-
> 1 file changed, 15 inse
I take it that both instances are supposed to call bitmap_zalloc?
If you can send a v2 that compiles, I can merge it after it passes the
CI.
Regards, Joonas
Quoting Andy Shevchenko (2019-03-04 11:03:20)
> Switch to bitmap_zalloc() to show clearly what we are allocating.
> Besides that it returns
On 05.03.2019 10:28, Krzysztof Kozlowski wrote:
> On Fri, 1 Mar 2019 at 13:24, Andrzej Hajda wrote:
>> To support local paths both DECON and GSCALER should enable respective
>> Smart Deck clocks DSD and GSD.
>>
>> Signed-off-by: Andrzej Hajda
>> ---
>> arch/arm64/boot/dts/exynos/exynos5433.dtsi
On Tue, 5 Mar 2019 at 10:36, Andrzej Hajda wrote:
>
> On 05.03.2019 10:28, Krzysztof Kozlowski wrote:
> > On Fri, 1 Mar 2019 at 13:24, Andrzej Hajda wrote:
> >> To support local paths both DECON and GSCALER should enable respective
> >> Smart Deck clocks DSD and GSD.
> >>
> >> Signed-off-by: Andr
https://bugs.freedesktop.org/show_bug.cgi?id=109628
--- Comment #5 from Rafał Miłecki ---
Created attachment 143531
--> https://bugs.freedesktop.org/attachment.cgi?id=143531&action=edit
dmesg from 5.0.0-rc7 with WARNINGs
Thanks Nicholas for looking at this.
I kept running 5.0.0-rc7 for few mo
Quoting Andy Shevchenko (2019-03-05 10:20:31)
> On Tue, Mar 05, 2019 at 11:28:36AM +0200, Joonas Lahtinen wrote:
> > I take it that both instances are supposed to call bitmap_zalloc?
> >
> > If you can send a v2 that compiles, I can merge it after it passes the
> > CI.
>
> v2 had been sent yester
On Tue, 05 Mar 2019, Maxime Ripard wrote:
> On Mon, Mar 04, 2019 at 05:47:09PM +0200, Jani Nikula wrote:
>> On Mon, 04 Mar 2019, Maxime Ripard wrote:
>> > In some cases, in order to accomodate with displays with poor EDIDs, we
>> > need to ignore that the monitor alledgedly supports audio output
On 03/04/2019 08:52 PM, Arnd Bergmann wrote:
> A recent cleanup introduced a build failure when a variable
> was spelled incorrectly:
>
> In file included from drivers/video/fbdev/mbx/mbxfb.c:881:
> drivers/video/fbdev/mbx/mbxdebugfs.c: In function 'mbxfb_debugfs_init':
> drivers/video/fbdev/mbx/
On 4.3.2019 21.53, Arnd Bergmann wrote:
drivers/gpu/host1x/hw/channel_hw.c: In function 'host1x_channel_set_streamid':
drivers/gpu/host1x/hw/channel_hw.c:118:30: error: implicit declaration of
function 'dev_iommu_fwspec_get'; did you mean 'iommu_fwspec_free'?
[-Werror=implicit-function-declarat
Hi,
[This is an automated email]
This commit has been processed because it contains a -stable tag.
The stable tag indicates that it's relevant for the following trees: all
The bot has tested the following trees: v4.20.13, v4.19.26, v4.14.104,
v4.9.161, v4.4.176, v3.18.136.
v4.20.13: Build OK!
Op 26-02-2019 om 08:36 schreef Ramalingam C:
> This patch adds a DRM ENUM property to the selected connectors.
> This property is used for pass the protected content's type
> from userspace to kernel HDCP authentication.
>
> Type of the stream is decided by the protected content providers as
> Type
Op 26-02-2019 om 08:36 schreef Ramalingam C:
> Attaches the content type property for HDCP2.2 capable connectors.
>
> Implements the update of content type from property and apply the
> restriction on HDCP version selection.
>
> Signed-off-by: Ramalingam C
> ---
> drivers/gpu/drm/i915/intel_ddi.c
On Tue, 2019-03-05 at 09:08 +0100, Maxime Ripard wrote:
> Chances are that they would stop at 1, call the device trash and never
> submit any quirk, therefore making the quirk approach useless in the
> process.
But the device _is_ trash. It's not like writing an accurate EDID is
difficult, if you
On Tue, Mar 05, 2019 at 10:12:40AM +0100, Maxime Ripard wrote:
> On Mon, Mar 04, 2019 at 03:05:31PM -0500, Alex Deucher wrote:
> > On Mon, Mar 4, 2019 at 2:53 PM Eric Anholt wrote:
> > >
> > > Maxime Ripard writes:
> > >
> > > > In some cases, in order to accomodate with displays with poor EDIDs,
On Fri, Mar 1, 2019 at 11:23 PM Qiang Yu wrote:
>
> > > +static struct lima_fence *lima_fence_create(struct lima_sched_pipe *pipe)
> > > +{
> > > + struct lima_fence *fence;
> > > +
> > > + fence = kmem_cache_zalloc(lima_fence_slab, GFP_KERNEL);
> >
> > Out of curiosity, what is the be
Hi Jyri,
Thank you for the patch.
On Thu, Feb 28, 2019 at 01:18:50PM +0200, Jyri Sarha wrote:
> drm_fb_cma_get_gem_obj() may return NULL. The return value needs to be
> checked before dereferencing the returned pointer.
>
> Signed-off-by: Jyri Sarha
> ---
> drivers/gpu/drm/tilcdc/tilcdc_crtc.c
Hi,
On Fri, Mar 01, 2019 at 07:48:15PM +0200, Georgi Djakov wrote:
> On 2/11/19 17:02, Maxime Ripard wrote:
> > The current DT bindings assume that the DMA will be performed by the
> > devices through their parent DT node, and rely on that assumption for the
> > address translation using dma-range
https://bugs.freedesktop.org/show_bug.cgi?id=109834
Bug ID: 109834
Summary: No x86 libraries in new amdgpu-pro drivers
Product: DRI
Version: DRI git
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
Sev
https://bugs.freedesktop.org/show_bug.cgi?id=109834
pearlydragon changed:
What|Removed |Added
Priority|medium |high
--
You are receiving this mail bec
On 19/02/2019 10:55, Maxime Ripard wrote:
Hi Robin,
On Wed, Feb 13, 2019 at 04:40:11PM +, Robin Murphy wrote:
On 13/02/2019 15:41, Maxime Ripard wrote:
Hi Robin,
Thanks for your feedback!
On Tue, Feb 12, 2019 at 06:46:40PM +, Robin Murphy wrote:
On 11/02/2019 15:02, Maxime Ripard wr
On 05/03/2019 15:53, Maxime Ripard wrote:
Hi,
On Fri, Mar 01, 2019 at 07:48:15PM +0200, Georgi Djakov wrote:
On 2/11/19 17:02, Maxime Ripard wrote:
The current DT bindings assume that the DMA will be performed by the
devices through their parent DT node, and rely on that assumption for the
add
https://bugs.freedesktop.org/show_bug.cgi?id=109835
Bug ID: 109835
Summary: [865G] [drm] GPU HANG: ecode 2:0:0x75f4003e, in
europa.exe [1323], reason: hang on rcs0, action: reset
Product: Mesa
Version: unspecified
Hardware:
https://bugs.freedesktop.org/show_bug.cgi?id=109835
--- Comment #1 from rtent...@yandex.ru ---
Created attachment 143539
--> https://bugs.freedesktop.org/attachment.cgi?id=143539&action=edit
dmesg
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=109835
--- Comment #2 from rtent...@yandex.ru ---
Created attachment 143540
--> https://bugs.freedesktop.org/attachment.cgi?id=143540&action=edit
error
--
You are receiving this mail because:
You are the assignee for the bug.
On 3/4/19 7:16 PM, John Stultz wrote:
> On Mon, Mar 4, 2019 at 6:53 AM Andrew F. Davis wrote:
>> On 3/1/19 6:06 AM, Brian Starkey wrote:
>>> On Mon, Feb 25, 2019 at 08:36:04AM -0600, Andrew F. Davis wrote:
+static long dma_heap_ioctl(struct file *filp, unsigned int cmd, unsigned
long ar
Maxime Ripard writes:
> [ Unknown signature status ]
> On Mon, Mar 04, 2019 at 03:05:31PM -0500, Alex Deucher wrote:
>> On Mon, Mar 4, 2019 at 2:53 PM Eric Anholt wrote:
>> >
>> > Maxime Ripard writes:
>> >
>> > > In some cases, in order to accomodate with displays with poor EDIDs, we
>> > > ne
On Mon, Mar 04, 2019 at 08:53:42AM -0600, Andrew F. Davis wrote:
> On 3/1/19 6:06 AM, Brian Starkey wrote:
> >
> > Am I right in thinking "cmd" comes from userspace? It might be a good
> > idea to not trust _IOC_SIZE(cmd) and use our own. I'm looking at
> > Documentation/ioctl/botching-up-ioctls.t
On Tue, Mar 5, 2019 at 10:05 AM Andrew F. Davis wrote:
> On 3/4/19 7:16 PM, John Stultz wrote:
> > The current patchset against v5.0 (with hikey960 patches), which
> > includes the flags and other suggested changes is here:
> >
> > https://git.linaro.org/people/john.stultz/android-dev.git/log/?
> -Original Message-
> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> Sent: Tuesday, March 5, 2019 8:09 PM
> To: C, Ramalingam ; intel-...@lists.freedesktop.org;
> dri-devel@lists.freedesktop.org; daniel.vet...@ffwll.ch; Shankar, Uma
>
> Subject: Re: [Intel-gfx] [PAT
On Tue, Mar 5, 2019 at 1:16 PM Paul Menzel
wrote:
>
> Dear Linux folks,
>
>
> Using the MST display Dell UP3214Q (two panels) with an AMD system,
> the virtual monitor object is not created. GDM and Xfce consider both
> panels as separate screens (`xrandr --listmonitors`).
>
> [0.00] Linux
On Tue, Mar 05, 2019 at 05:24:13PM +0200, Ville Syrjälä wrote:
> On Tue, Mar 05, 2019 at 10:12:40AM +0100, Maxime Ripard wrote:
> > On Mon, Mar 04, 2019 at 03:05:31PM -0500, Alex Deucher wrote:
> > > On Mon, Mar 4, 2019 at 2:53 PM Eric Anholt wrote:
> > > >
> > > > Maxime Ripard writes:
> > > >
>
On Tue, Mar 5, 2019 at 2:15 PM Ville Syrjälä
wrote:
>
> On Tue, Mar 05, 2019 at 05:24:13PM +0200, Ville Syrjälä wrote:
> > On Tue, Mar 05, 2019 at 10:12:40AM +0100, Maxime Ripard wrote:
> > > On Mon, Mar 04, 2019 at 03:05:31PM -0500, Alex Deucher wrote:
> > > > On Mon, Mar 4, 2019 at 2:53 PM Eric
Hi Jyri,
Thank you for the patch.
On Thu, Feb 28, 2019 at 01:18:51PM +0200, Jyri Sarha wrote:
> Earlier there were no mode_valid() helper for crtc and tilcdc had a
> hack to over come this limitation. But now the mode_valid() helper is
> there (has been since v4.13), so it is about time to get ri
https://bugs.freedesktop.org/show_bug.cgi?id=109206
--- Comment #21 from Tim Carr ---
I can confirm that the amd-staging-drm-next kernel also works for my system.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel m
On 2019-03-04 13:32, Sean Paul wrote:
On Wed, Feb 13, 2019 at 05:52:19PM -0800, Jeykumar Sankaran wrote:
Subclass drm private object state for DPU for handling driver
specific data. Adds atomic private object to dpu crtc to
track hw resources per display. Provide helper function to
retrieve DPU
On Tue, Mar 05, 2019 at 02:21:04PM -0500, Alex Deucher wrote:
> On Tue, Mar 5, 2019 at 2:15 PM Ville Syrjälä
> wrote:
> >
> > On Tue, Mar 05, 2019 at 05:24:13PM +0200, Ville Syrjälä wrote:
> > > On Tue, Mar 05, 2019 at 10:12:40AM +0100, Maxime Ripard wrote:
> > > > On Mon, Mar 04, 2019 at 03:05:31
On 05/03/2019 17:43, Laurent Pinchart wrote:
> Hi Jyri,
>
> Thank you for the patch.
>
> On Thu, Feb 28, 2019 at 01:18:50PM +0200, Jyri Sarha wrote:
>> drm_fb_cma_get_gem_obj() may return NULL. The return value needs to be
>> checked before dereferencing the returned pointer.
>>
>> Signed-off-by:
On Tue, Mar 05, 2019 at 09:42:50PM +0200, Jyri Sarha wrote:
> On 05/03/2019 17:43, Laurent Pinchart wrote:
> > Hi Jyri,
> >
> > Thank you for the patch.
> >
> > On Thu, Feb 28, 2019 at 01:18:50PM +0200, Jyri Sarha wrote:
> >> drm_fb_cma_get_gem_obj() may return NULL. The return value needs to be
Qiang Yu writes:
> - Mali 4xx GPUs have two kinds of processors GP and PP. GP is for
> OpenGL vertex shader processing and PP is for fragment shader
> processing. Each processor has its own MMU so prcessors work in
> virtual address space.
> - There's only one GP but multiple PP (max 4 for
On Tue, Mar 05, 2019 at 11:34:48AM -0800, Jeykumar Sankaran wrote:
> On 2019-03-04 13:32, Sean Paul wrote:
> > On Wed, Feb 13, 2019 at 05:52:19PM -0800, Jeykumar Sankaran wrote:
> > > Subclass drm private object state for DPU for handling driver
> > > specific data. Adds atomic private object to dp
Rob Herring writes:
> On Fri, Mar 1, 2019 at 11:23 PM Qiang Yu wrote:
>>
>> > > +static struct lima_fence *lima_fence_create(struct lima_sched_pipe
>> > > *pipe)
>> > > +{
>> > > + struct lima_fence *fence;
>> > > +
>> > > + fence = kmem_cache_zalloc(lima_fence_slab, GFP_KERNEL);
>>
Here is a initial RFC of the dma-buf heaps patchset Andrew and I
have been working on which tries to destage a fair chunk of ION
functionality.
The patchset implements per-heap devices which can be opened
directly and then an ioctl is used to allocate a dmabuf from the
heap.
The interface is simi
Add generic helper dmabuf ops for dma heaps, so we can reduce
the amount of duplicative code for the exported dmabufs.
This code is an evolution of the Android ION implementation, so
thanks to its original authors and maintainters:
Rebecca Schultz Zavin, Colin Cross, Laura Abbott, and others!
C
This adds a CMA heap, which allows userspace to allocate
a dma-buf of contiguous memory out of a CMA region.
This code is an evolution of the Android ION implementation, so
thanks to its original author and maintainters:
Benjamin Gaignard, Laura Abbott, and others!
Cc: Laura Abbott
Cc: Benjami
This patch adds system heap to the dma-buf heaps framework.
This allows applications to get a page-allocator backed dma-buf
for non-contiguous memory.
This code is an evolution of the Android ION implementation, so
thanks to its original authors and maintainters:
Rebecca Schultz Zavin, Colin Cr
Add very trivial allocation test for dma-heaps.
TODO: Need to actually do some validation on
the returned dma-buf.
Cc: Laura Abbott
Cc: Benjamin Gaignard
Cc: Greg KH
Cc: Sumit Semwal
Cc: Liam Mark
Cc: Brian Starkey
Cc: Andrew F. Davis
Cc: Chenbo Feng
Cc: Alistair Strachan
Cc: dri-devel@l
From: "Andrew F. Davis"
This framework allows a unified userspace interface for dma-buf
exporters, allowing userland to allocate specific types of
memory for use in dma-buf sharing.
Each heap is given its own device node, which a user can
allocate a dma-buf fd from using the DMA_HEAP_IOC_ALLOC.
Maxime Ripard writes:
> [ Unknown signature status ]
> On Mon, Mar 04, 2019 at 03:05:31PM -0500, Alex Deucher wrote:
>> On Mon, Mar 4, 2019 at 2:53 PM Eric Anholt wrote:
>> >
>> > Maxime Ripard writes:
>> >
>> > > In some cases, in order to accomodate with displays with poor EDIDs, we
>> > > ne
On Sat, Nov 24, 2018 at 9:06 PM Brian Masney wrote:
> Add binding for the LG ACX467AKM-7 4.95" 1080×1920 LCD panel that is
> found on the LG Nexus 5 (hammerhead) phone. This appears to be a JDI
> panel based on some Internet searches, however a specific model number
> could not be found. I disass
On Sat, Nov 24, 2018 at 9:06 PM Brian Masney wrote:
> From: Jonathan Marek
>
> Add ACX467AKM-7 4.95" 1080×1920 LCD panel that is found on the LG Nexus
> 5 (hammerhead) phone.
>
> Signed-off-by: Jonathan Marek
> [masn...@onstation.org: checkpatch fixes; rename jdi,1080p-hammerhead
> binding to l
https://bugs.freedesktop.org/show_bug.cgi?id=80419
--- Comment #153 from hede ---
Why is this fix in older versions (like mesa 13.0) but not newer ones? Mesa
18.2.2 on Ubuntu 18.10 (cosmic) still needs manually patching. And upstream
version 19 still excludes this fix.
btw: I can confirm this b
Hi Brian,
On Fri, Feb 22, 2019 at 03:06:19PM +, Brian Starkey wrote:
> On Fri, Feb 22, 2019 at 04:46:29PM +0200, Laurent Pinchart wrote:
> > On Fri, Feb 22, 2019 at 02:30:03PM +, Brian Starkey wrote:
> >> On Thu, Feb 21, 2019 at 12:32:00PM +0200, Laurent Pinchart wrote:
> >>> One-shot entr
On 3/4/19 11:49 AM, Helen Koike wrote:
> Async update callbacks are expected to set the old_fb in the new_state
> so prepare/cleanup framebuffers are balanced.
>
> Calling drm_atomic_set_fb_for_plane() (which gets a reference of the new
> fb and put the old fb) is not required, as it's taken car
On 3/4/19 11:49 AM, Helen Koike wrote:
> Hello,
>
> This series is a first attempt to fix the slow down in performance introduced
> by
> "[PATCH v2] drm: Block fb changes for async plane updates" where async update
> falls back to a sync update, causing igt failures of type:
>
> "CRITICAL:
tree: git://people.freedesktop.org/~agd5f/linux.git drm-next-5.2-wip
head: 5b1489e11b0d36226c0192b3ce18f5654fd15243
commit: 09910581cf6218cad6416e53aa0645402d8147be [275/283] drm/amdkfd: add RAS
ECC event support (v2)
config: i386-randconfig-s2-201909 (attached as .config)
compiler: gcc-6 (Deb
Hi Jyri,
Thank you for the patch.
On Fri, Feb 15, 2019 at 10:13:15AM +0200, Jyri Sarha wrote:
> Calling drm_fbdev_cma_fini() after drm_dev_unregister() started to
> cause a crash when unloading tilcdc some time between 4.14 and
> 4.19. Instead of changing the unload order it looks like using
> dr
Hi Jyri,
Thank you for the patch.
On Fri, Feb 15, 2019 at 10:13:16AM +0200, Jyri Sarha wrote:
> Most of the struct tilcdc_panel_info data members, that are also
> exposed in dts binding, are essentially display IP register bits that
> should not need customization per connected display basis. Thi
Hi Tomi,
On Fri, Jan 18, 2019 at 10:29:33AM +0200, Tomi Valkeinen wrote:
> On 18/01/19 00:04, Rob Herring wrote:
>
> > Mesa/libdrm already has lots of code to open the correct devices and
> > not care about minor numbers. What's the problem here?
>
> Well, maybe the problem is that I don't know
On Mon, 2019-02-25 at 10:09 +0800, wangyan wang wrote:
> From: Wangyan Wang
>
> V6 adopt maintainer's suggestion.
> Here is the change list between V5 & V6
> 1. change "unsigned char mux_flags;" to "u8 mux_flags;" to
> match with the struct in " clk: mediatek: add MUX_GATE_FLAGS_2".
>
Hi, Wangy
On Wed, Mar 6, 2019 at 4:18 AM Eric Anholt wrote:
>
> Rob Herring writes:
>
> > On Fri, Mar 1, 2019 at 11:23 PM Qiang Yu wrote:
> >>
> >> > > +static struct lima_fence *lima_fence_create(struct lima_sched_pipe
> >> > > *pipe)
> >> > > +{
> >> > > + struct lima_fence *fence;
> >> > > +
> >
deadlock test for sdma will cause gpu recoverty.
disable the test for now until GPU reset recovery could survive at least
1000 times test.
Change-Id: I9adac63c62db22107345eddb30e7d81a1bda838c
Signed-off-by: Flora Cui
---
tests/amdgpu/amdgpu_test.c| 4 ++
tests/amdgpu/deadlock_tests.c | 103
Hi Sam,
On Sat, Jan 12, 2019 at 01:41:11PM +0100, Sam Ravnborg wrote:
> On Sat, Jan 12, 2019 at 03:10:51AM +0200, Laurent Pinchart wrote:
> > This allows nicer kerneldoc with an easy way to reference the enum and
> > the values.
> >
> > Signed-off-by: Laurent Pinchart
> > ---
> > include/drm/dr
On Wed, Mar 6, 2019 at 4:16 AM Eric Anholt wrote:
>
> Qiang Yu writes:
>
> > - Mali 4xx GPUs have two kinds of processors GP and PP. GP is for
> > OpenGL vertex shader processing and PP is for fragment shader
> > processing. Each processor has its own MMU so prcessors work in
> > virtual ad
> >
> > I don't think you need the _pad fields here, and they're actually a bad
> > idea because the lack of checking in your ioctls means you can't trust
> > that userspace has initialized them to 0 when you want to redefine them
> > as a flags field later.
>
> Could I drop the _pad? I thought the
From: kbuild test robot
drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c:405:2-3: Unneeded semicolon
drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c:435:2-3: Unneeded semicolon
Remove unneeded semicolon.
Generated by: scripts/coccinelle/misc/semicolon.cocci
Fixes: 1381f5b10b10 ("drm/amdgpu: add amdgpu_ras.c
tree: git://people.freedesktop.org/~agd5f/linux.git drm-next-5.2-wip
head: 5b1489e11b0d36226c0192b3ce18f5654fd15243
commit: 1381f5b10b10f8f88d01ca43be9161aeed1d68a2 [264/283] drm/amdgpu: add
amdgpu_ras.c to support ras (v2)
coccinelle warnings: (new ones prefixed by >>)
>> drivers/gpu/drm/a
On Tue, Feb 26, 2019 at 6:25 AM Maxime Ripard wrote:
>
> Hi,
>
> This implements roughly what we discussed as part of the ANX6345 series to
> relax the pixel clock validation while still filtering out the modes we
> can't reach using the bridges.
>
> Let me know what you think,
> Maxime
With last
Hi Laurent.
> > > + * @DRM_BUS_FLAG_DE_LOW: The Data Enable signal is active low
> > > + * @DRM_BUS_FLAG_DE_HIGH:The Data Enable signal is
> > > active high
> > > + * @DRM_BUS_FLAG_PIXDATA_POSEDGE:Legacy value, do not use
> > > + * @DRM_BUS_FLAG_PIXDATA_NEGEDGE:
deadlock test for sdma will cause gpu recoverty.
disable the test for now until GPU reset recovery could survive at least
1000 times test.
v2: add modprobe parameter
Change-Id: I9adac63c62db22107345eddb30e7d81a1bda838c
Signed-off-by: Flora Cui
---
tests/amdgpu/amdgpu_test.c| 4 ++
tests/a
Reviewed-and-tested-by: Evan Quan
> -Original Message-
> From: amd-gfx On Behalf Of Cui,
> Flora
> Sent: Wednesday, March 06, 2019 2:37 PM
> To: amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
> Cc: Cui, Flora
> Subject: [PATCH v2] tests/amdgpu: add deadlock test for sdma
tree: git://people.freedesktop.org/~agd5f/linux.git drm-next-5.2-wip
head: 5b1489e11b0d36226c0192b3ce18f5654fd15243
commit: 09910581cf6218cad6416e53aa0645402d8147be [275/283] drm/amdkfd: add RAS
ECC event support (v2)
config: i386-randconfig-m2-201909 (attached as .config)
compiler: gcc-7 (Deb
https://bugs.freedesktop.org/show_bug.cgi?id=109850
Bug ID: 109850
Summary: there is a problem in frame buffer console.
Product: DRI
Version: XOrg git
Hardware: PowerPC
OS: Windows (All)
Status: NEW
Severi
https://bugs.freedesktop.org/show_bug.cgi?id=109440
--- Comment #4 from Zohaib Shehzad ---
dkjfnwib 8rybvrlkjv wbi
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http
1 - 100 of 124 matches
Mail list logo
