Am 14.06.19 um 14:59 schrieb Peter Zijlstra:
On Fri, Jun 14, 2019 at 02:41:22PM +0200, Christian König wrote:
Use the provided macros instead of implementing deadlock handling on our own.
Signed-off-by: Christian König
---
drivers/gpu/drm/drm_gem.c | 49
On Fri, Jun 14, 2019 at 03:06:10PM +0200, Christian König wrote:
> Am 14.06.19 um 14:59 schrieb Peter Zijlstra:
> > +#define ww_mutex_lock_for_each(loop, pos, contended, ret, intr, ctx) \
> > + for (contended = ERR_PTR(-ENOENT); ({ \
> > + __label__
On Tue, 2019-06-11 at 18:16 -0700, Steve Longerbeam wrote:
> The output of the IC downsizer unit in both dimensions must be <= 1024
> before being passed to the IC resizer unit. This was causing corrupted
> images when:
>
> input_dim > 1024, and
> input_dim / 2 < output_dim < input_dim
>
> Some
On Thu, 2019-06-13 at 18:02 -0700, Steve Longerbeam wrote:
> For the write channels with 4:2:0 subsampled YUV formats, avoid chroma
> overdraw by only writing chroma for even lines (skip odd chroma rows).
> This reduces necessary write memory bandwidth by at least 25% (more
> with rotation
On Fri, Jun 14, 2019 at 12:03:13PM +0530, Jagan Teki wrote:
> On Thu, Jun 13, 2019 at 6:56 PM Maxime Ripard
> wrote:
> >
> > On Wed, Jun 05, 2019 at 01:17:11PM +0530, Jagan Teki wrote:
> > > On Tue, Jun 4, 2019 at 3:30 PM Maxime Ripard
> > > wrote:
> > > >
> > > > On Wed, May 29, 2019 at
Quoting Steven Rostedt (2019-06-14 14:39:14)
> I'm trying to debug some code where I need KASAN and lockdep enabled
> but I can't get past this splat unrelated to my code. I bisected it
> down to this commit:
>
> 32eb6bcfdda9da ("drm/i915: Make request allocation caches global")
>
> To make
The struct drm_cmdline_mode holds the result of the command line parsers.
However, it wasn't documented so far, so let's do that.
Signed-off-by: Maxime Ripard
---
include/drm/drm_connector.h | 86 +-
1 file changed, 84 insertions(+), 2 deletions(-)
diff
Hi,
The proprietary stack for the RaspberryPi allows for a number of video
parameters widely used by their users, but yet don't have any equivalents
in the mainline kernel.
Those options are detailed here:
https://www.raspberrypi.org/documentation/configuration/config-txt/video.md
While not all
On 2019/05/27, Emil Velikov wrote:
> From: Emil Velikov
>
> Currently one can circumvent DRM_AUTH, when the ioctl is exposed via the
> render node. A seemingly deliberate design decision.
>
> Hence we can drop the DRM_AUTH all together (details in follow-up patch)
> yet not all userspace checks
dma_alloc_coherent is not just the page allocator. The only valid
arguments to pass are either GFP_ATOMIC or GFP_ATOMIC with possible
modifiers of __GFP_NORETRY or __GFP_NOWARN.
Signed-off-by: Christoph Hellwig
---
drivers/net/ethernet/broadcom/cnic.c | 4 ++--
1 file changed, 2 insertions(+),
We are not allowed to call virt_to_page on pages returned from
dma_alloc_coherent, as in many cases the virtual address returned
is aactually a kernel direct mapping. Also there generally is no
need to mark dma memory as reserved.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/drm_bufs.c
dma_alloc_coherent is not just the page allocator. The only valid
arguments to pass are either GFP_ATOMIC or GFP_ATOMIC with possible
modifiers of __GFP_NORETRY or __GFP_NOWARN.
Signed-off-by: Christoph Hellwig
---
drivers/s390/net/ism_drv.c | 3 ++-
1 file changed, 2 insertions(+), 1
Hi Boris,
Am Freitag, 14. Juni 2019, 15:53:20 CEST schrieb Boris Brezillon:
> On Thu, 13 Jun 2019 16:22:44 -0300
> Ezequiel Garcia wrote:
>
>
> > +static int vop_gamma_lut_request(struct device *dev,
> > +struct resource *res, struct vop *vop)
> > +{
> > +
Hi Robert.
On top of the feedback from Fabio here is a bit more.
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
Divide include up in block in following order:
#include
#include
#incude
On Fri, Jun 14, 2019 at 11:51:10AM +0200, Greg Kroah-Hartman wrote:
> As stated before, there is no need to care if a debugfs function
> succeeds or not, and no code logic in the kernel should ever change
> based on a debugfs function return value, so make
> drm_debugfs_create_files() never fail.
Hello,
On Fri, Jun 14, 2019 at 04:08:33PM +0100, Chris Wilson wrote:
> #ifdef CONFIG_MEMCG
> if (slab_state >= FULL && err >= 0 && is_root_cache(s)) {
> struct kmem_cache *c;
>
> mutex_lock(_mutex);
>
> so it happens to hit the error + FULL case with the
On Wed, Jun 12, 2019 at 09:18:56PM -0500, Alex Deucher wrote:
> Hi Dave, Daniel,
>
> Fixes for 5.2:
> - Extend previous vce fix for resume to uvd and vcn
> - Fix bounds checking in ras debugfs interface
> - Fix a regression on SI using amdgpu
>
> The following changes since commit
Hi,
Am Mittwoch, 5. Juni 2019, 10:04:24 CEST schrieb sandor...@nxp.com:
> From: Sandor Yu
>
> variable of rate in the struct drm_dp_link should assign to
> 162000/27/54/81.
>
> Signed-off-by: Sandor Yu
applied to drm-misc-next after fixing patch subject and description
to be in
Thomas just a gentle ping on this.
It's not that my live depends on this, but it would still be a nice to
have cleanup.
Thanks,
Christian.
Am 07.06.19 um 16:47 schrieb Christian König:
This feature is only used by vmwgfx and superflous for everybody else.
Signed-off-by: Christian König
On Fri, Jun 14, 2019 at 8:53 AM Robert Chiras wrote:
>
> Add dt-bindings documentation for Raydium RM67191 DSI panel.
>
> Signed-off-by: Robert Chiras
> ---
> .../bindings/display/panel/raydium,rm67191.txt | 42
> ++
> 1 file changed, 42 insertions(+)
> create mode
On Wed, Jun 05, 2019 at 01:03:16PM +0530, Jagan Teki wrote:
> On Wed, Jun 5, 2019 at 12:19 PM Maxime Ripard
> wrote:
> >
> > Hi,
> >
> > I've reordered the mail a bit to work on chunks
> >
> > On Fri, May 24, 2019 at 03:37:42PM +0530, Jagan Teki wrote:
> > > > I wish it was in your commit log in
On Fri, Jun 14, 2019 at 03:01:22PM +, David Laight wrote:
> I'm pretty sure there is a lot of code out there that makes that assumption.
> Without it many drivers will have to allocate almost double the
> amount of memory they actually need in order to get the required alignment.
> So instead
https://bugs.freedesktop.org/show_bug.cgi?id=110897
--- Comment #32 from Richard Thier ---
If my card has no "hiz_ram" what that means? Can anyone explain if I am right?
This is what I suspect so far:
- Zcompression I get still, because the card has zmask_ram
- No hierarchical Z (hiz) at all
On Fri, Jun 14, 2019 at 04:48:57PM +0200, Christoph Hellwig wrote:
> On Fri, Jun 14, 2019 at 04:02:39PM +0200, Greg KH wrote:
> > Perhaps a hint as to how we can fix this up? This is the first time
> > I've heard of the comedi code not handling dma properly.
>
> It can be fixed by:
>
> a)
On Fri, 14 Jun 2019 09:12:39 -0600
Rob Herring wrote:
> On Wed, May 29, 2019 at 9:16 AM Alyssa Rosenzweig
> wrote:
> >
> > Woohoo! Patches 1-3 are R-b; patch 4 is A-b. Exciting progress! Hoping
> > to hear what Rob and Steven think :)
>
> All looks fine to me, but there's a kbuild error on
On Thu, Jun 13, 2019 at 7:28 PM Maxime Ripard wrote:
>
> On Wed, Jun 05, 2019 at 01:11:44PM +0530, Jagan Teki wrote:
> > On Tue, Jun 4, 2019 at 8:00 PM Maxime Ripard
> > wrote:
> > >
> > > On Fri, May 24, 2019 at 03:37:36PM +0530, Jagan Teki wrote:
> > > > On Fri, May 24, 2019 at 2:18 AM Maxime
Hi Robert,
Minor comment. See inline:
On Fri, Jun 14, 2019 at 2:52 PM Robert Chiras wrote:
>
> This patch adds Raydium RM67191 TFT LCD panel driver (MIPI-DSI
> protocol).
>
> Signed-off-by: Robert Chiras
> ---
> drivers/gpu/drm/panel/Kconfig | 9 +
>
Am 14.06.19 um 14:09 schrieb Emil Velikov:
> On 2019/05/27, Emil Velikov wrote:
> [SNIP]
> Hi Christian,
>
>
> In the following, I would like to summarise and emphasize the need for
> DRM_AUTH removal. I would kindly ask you to spend a couple of minutes
> extra reading it.
>
>
> Today DRM drivers*
On Fri, Jun 14, 2019 at 02:41:20PM +0200, Christian König wrote:
> The ww_mutex implementation allows for detection deadlocks when multiple
> threads try to acquire the same set of locks in different order.
>
> The problem is that handling those deadlocks was the burden of the user of
> the
https://bugs.freedesktop.org/show_bug.cgi?id=110897
--- Comment #29 from Richard Thier ---
Okay this is weird for me:
/* src/gallium/drivers/r300/r300_texture_desc.c */
399 /* Get the HIZ buffer size in dwords. */
400 hiz_numdw = (stride * height) / (8*8 * pipes);
On Fri, Jun 14, 2019 at 03:47:22PM +0200, Christoph Hellwig wrote:
> comedi_buf.c abuse the DMA API in gravely broken ways, as it assumes it
> can call virt_to_page on the result, and the just remap it as uncached
> using vmap. Disable the driver until this API abuse has been fixed.
>
>
Hi Jani,
On Fri, Jun 14, 2019 at 03:28:59PM +0300, Jani Nikula wrote:
> On Fri, 14 Jun 2019, Maxime Ripard wrote:
> > The drm_client_modeset_commit_atomic function uses two times the
> > plane_state variable in inner blocks of code, but the variable has a scope
> > global to this function.
> >
>
https://bugs.freedesktop.org/show_bug.cgi?id=109955
--- Comment #34 from Alex Deucher ---
(In reply to Jiri Slaby from comment #33)
> > amdgpu :1e:00.0: GPU reset(2) succeeded!
> > [drm] Skip scheduling IBs!
> > ...
> > [drm] Skip scheduling IBs!
> > [drm:amdgpu_cs_ioctl [amdgpu]] *ERROR*
Add COMPILE_TEST support to s3c-fb driver for better compile
testing coverage.
Cc: Jingoo Han
Signed-off-by: Bartlomiej Zolnierkiewicz
---
drivers/video/fbdev/Kconfig |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Index: b/drivers/video/fbdev/Kconfig
https://bugs.freedesktop.org/show_bug.cgi?id=110897
--- Comment #30 from Richard Thier ---
It seems it can be normal, but then my understanding of hyperZ was a bit off
then.
I will try adding hiz ram for it just to see what happens :-)
--
You are receiving this mail because:
You are the
https://bugs.freedesktop.org/show_bug.cgi?id=110783
--- Comment #16 from Gert Wollny ---
I've updated the MR to add a CAP for support of TGSI_OPCODE_DIV to also check
for it.
--
You are receiving this mail because:
You are the assignee for the
Fix sparse warning:
drivers/gpu/drm/bridge/sii902x.c:665:5: warning:
symbol 'sii902x_audio_digital_mute' was not declared. Should it be static?
Reported-by: Hulk Robot
Signed-off-by: YueHaibing
---
drivers/gpu/drm/bridge/sii902x.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff
On Thu, 28 Mar 2019 at 16:50, Uma Shankar wrote:
>
> This is how a typical display color hardware pipeline looks like:
> +---+
> |RAM|
> | +--++-++-+ |
> | | FB 1 || FB 2 |
On 2019/06/14, Koenig, Christian wrote:
> Am 14.06.19 um 17:53 schrieb Emil Velikov:
> > On 2019/06/14, Koenig, Christian wrote:
> >> Am 14.06.19 um 14:09 schrieb Emil Velikov:
> >>> On 2019/05/27, Emil Velikov wrote:
> >>> [SNIP]
> >>> Hi Christian,
> >>>
> >>>
> >>> In the following, I would
Hi Fabio,
On Vi, 2019-06-14 at 09:27 -0300, Fabio Estevam wrote:
> Hi Robert,
>
> On Fri, Jun 14, 2019 at 8:52 AM Robert Chiras
> wrote:
>
> >
> > --- /dev/null
> > +++ b/drivers/gpu/drm/panel/panel-raydium-rm67191.c
> > @@ -0,0 +1,730 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > +
On Thu, 13 Jun 2019 16:22:44 -0300
Ezequiel Garcia wrote:
> +static int vop_gamma_lut_request(struct device *dev,
> + struct resource *res, struct vop *vop)
> +{
> + resource_size_t offset = vop->data->gamma_lut_addr_off;
> + resource_size_t size =
On Thu, Jun 13, 2019 at 01:34:04PM +0530, Jagan Teki wrote:
> On Fri, May 31, 2019 at 12:23 AM Maxime Ripard
> wrote:
> >
> > On Fri, May 24, 2019 at 03:55:42PM +0530, Jagan Teki wrote:
> > > On Fri, May 24, 2019 at 2:07 AM Maxime Ripard
> > > wrote:
> > > >
> > > > On Mon, May 20, 2019 at
https://bugs.freedesktop.org/show_bug.cgi?id=110783
--- Comment #15 from AngryPenguin ---
Hi.
I can confirm, this fix my issue with vaapi and vdpau.
Thanks.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel
From: Colin Ian King
There is an if block that is missing the { } curly brackets. Add
these in.
Addresses-Coverity: ("Structurally dead code")
Fixes: 94dc57b10399 ("drm/mgag200: Rewrite cursor handling")
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/mgag200/mgag200_cursor.c | 3 ++-
1
On 14/06/2019 15:50, 'Christoph Hellwig' wrote:
On Fri, Jun 14, 2019 at 02:15:44PM +, David Laight wrote:
Does this still guarantee that requests for 16k will not cross a 16k boundary?
It looks like you are losing the alignment parameter.
The DMA API never gave you alignment guarantees to
On Fri, Jun 14, 2019 at 04:59:08PM +0200, Daniel Vetter wrote:
> On Fri, Jun 14, 2019 at 11:51:09AM +0200, Greg Kroah-Hartman wrote:
> > The function can not fail, and no one checks the current return value,
> > so just mark it as a void function so no one gets confused.
> >
> > Cc: Maarten
On Fri, Jun 14, 2019 at 5:20 PM Greg Kroah-Hartman
wrote:
>
> On Fri, Jun 14, 2019 at 04:59:08PM +0200, Daniel Vetter wrote:
> > On Fri, Jun 14, 2019 at 11:51:09AM +0200, Greg Kroah-Hartman wrote:
> > > The function can not fail, and no one checks the current return value,
> > > so just mark it
On 2019/06/14, Koenig, Christian wrote:
> Am 14.06.19 um 14:09 schrieb Emil Velikov:
> > On 2019/05/27, Emil Velikov wrote:
> > [SNIP]
> > Hi Christian,
> >
> >
> > In the following, I would like to summarise and emphasize the need for
> > DRM_AUTH removal. I would kindly ask you to spend a couple
This patch adds Raydium RM67191 TFT LCD panel driver (MIPI-DSI
protocol).
Signed-off-by: Robert Chiras
---
drivers/gpu/drm/panel/Kconfig | 9 +
drivers/gpu/drm/panel/Makefile| 1 +
drivers/gpu/drm/panel/panel-raydium-rm67191.c | 730 ++
The drm_client_modeset_commit_atomic function uses two times the
plane_state variable in inner blocks of code, but the variable has a scope
global to this function.
This will lead to inadvertent devs to reuse the variable in the second
block with the value left by the first, without any warning
Properly configuring the overscan properties might be needed for the
initial setup of the framebuffer for display that still have overscan.
Let's allow for more properties on the kernel command line to setup each
margin.
Reviewed-by: Noralf Trønnes
Signed-off-by: Maxime Ripard
---
Now that the TV margins are properly parsed and filled into
drm_cmdline_mode, we just need to initialise the first state at reset to
get those values and start using them.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 8 +++-
1 file changed, 7 insertions(+), 1
Rotations and reflections setup are needed in some scenarios to initialise
properly the initial framebuffer. Some drivers already had a bunch of
quirks to deal with this, such as either a private kernel command line
parameter (omapdss) or on the device tree (various panels).
In order to
From: Maxime Ripard
Rewrite the command line parser in order to get away from the state machine
parsing the video mode lines.
Hopefully, this will allow to extend it more easily to support named modes
and / or properties set directly on the command line.
Signed-off-by: Maxime Ripard
---
The drm_client_rotation has a check on the rotation value, but the
reflections are also stored in the same variable, and the check doesn't
take this into account.
Therefore, even though we might have a valid rotation, if we're also using
a reflection parameter, the test will fail for no
During the connector reset, if that connector has a TV property, it needs
to be reset to the value provided on the command line.
Provide a helper to do that.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/drm_atomic_state_helper.c | 18 ++
The command line parser is pretty tough to get right and very error prone,
so let's add a selftest to try to catch any regression.
Reviewed-by: Noralf Trønnes
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/selftests/Makefile | 2 +-
The TV margins has been defined as a structure inside the
drm_connector_state structure so far. However, we will need it in other
structures as well, so let's move that structure definition so that it can
be reused.
Signed-off-by: Maxime Ripard
---
include/drm/drm_connector.h | 34
The ww_mutex implementation allows drivers to acquire locks on a set of locking
primitives with detection of deadlocks. If a deadlock happens we can then
backoff and reacquire the contended lock until we should finally be able to
acquire all necessary locks for an operation.
The problem is that
Use the provided macros instead of implementing deadlock handling on our own.
Signed-off-by: Christian König
---
drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c | 55 +---
1 file changed, 14 insertions(+), 41 deletions(-)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
The ww_mutex implementation allows for detection deadlocks when multiple
threads try to acquire the same set of locks in different order.
The problem is that handling those deadlocks was the burden of the user of
the ww_mutex implementation and at least some users didn't got that right
on the
Use the provided macros instead of implementing deadlock handling on our own.
Signed-off-by: Christian König
---
drivers/gpu/drm/vc4/vc4_gem.c | 56 ---
1 file changed, 13 insertions(+), 43 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_gem.c
Use the provided macros instead of implementing deadlock handling on our own.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_execbuf_util.c | 87 +-
1 file changed, 30 insertions(+), 57 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_execbuf_util.c
Use the provided macros instead of implementing deadlock handling on our own.
Signed-off-by: Christian König
---
drivers/gpu/drm/lima/lima_gem.c | 41 +
1 file changed, 11 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/lima/lima_gem.c
Use the provided macros instead of implementing deadlock handling on our own.
Signed-off-by: Christian König
---
drivers/gpu/drm/drm_gem.c | 49 ++-
1 file changed, 12 insertions(+), 37 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem.c
On Fri, 14 Jun 2019 16:03:28 +0200
Heiko Stübner wrote:
> Hi Boris,
>
> Am Freitag, 14. Juni 2019, 15:53:20 CEST schrieb Boris Brezillon:
> > On Thu, 13 Jun 2019 16:22:44 -0300
> > Ezequiel Garcia wrote:
> >
> >
> > > +static int vop_gamma_lut_request(struct device *dev,
> > > +
Am 14.06.19 um 17:53 schrieb Emil Velikov:
> On 2019/06/14, Koenig, Christian wrote:
>> Am 14.06.19 um 14:09 schrieb Emil Velikov:
>>> On 2019/05/27, Emil Velikov wrote:
>>> [SNIP]
>>> Hi Christian,
>>>
>>>
>>> In the following, I would like to summarise and emphasize the need for
>>> DRM_AUTH
Use ->screen_buffer instead of ->screen_base to fix sparse warnings.
[ Please see commit 17a7b0b4d974 ("fb.h: Provide alternate screen_base
pointer") for details. ]
Reported-by: kbuild test robot
Cc: Shawn Guo
Cc: Sascha Hauer
Cc: Pengutronix Kernel Team
Cc: Fabio Estevam
Cc: Uwe
https://bugs.freedesktop.org/show_bug.cgi?id=110897
--- Comment #26 from Richard Thier ---
Okay it is still bad now despite I have compiled with "-O0" flags actually...
To be honest I have no idea actually why it started working last time.
Also now that I step with the debugger I see that a lot
On Fri, Jun 14, 2019 at 4:32 PM Chen-Yu Tsai wrote:
>
> On Fri, Jun 14, 2019 at 6:56 PM Jagan Teki wrote:
> >
> > On Fri, Jun 14, 2019 at 9:05 AM Chen-Yu Tsai wrote:
> > >
> > > On Fri, Jun 14, 2019 at 11:19 AM Chen-Yu Tsai wrote:
> > > >
> > > > On Fri, Jun 14, 2019 at 2:53 AM Jagan Teki
>
Hi Robert,
On Fri, Jun 14, 2019 at 8:52 AM Robert Chiras wrote:
> --- /dev/null
> +++ b/drivers/gpu/drm/panel/panel-raydium-rm67191.c
> @@ -0,0 +1,730 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * i.MX drm driver - Raydium MIPI-DSI panel driver
> + *
> + * Copyright (C) 2017 NXP
> + *
>
https://bugs.freedesktop.org/show_bug.cgi?id=110897
--- Comment #27 from Richard Thier ---
This is also always happening:
434 /* Enable fastfill and/or hiz.
435 *
436 * If we cleared zmask/hiz, it's in use now. The Hyper-Z state update
437 * looks if zmask/hiz is in
https://bugs.freedesktop.org/show_bug.cgi?id=110897
Richard Thier changed:
What|Removed |Added
Priority|low |medium
--
You are receiving this mail
On Fri, Jun 14, 2019 at 02:41:22PM +0200, Christian König wrote:
> Use the provided macros instead of implementing deadlock handling on our own.
>
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/drm_gem.c | 49 ++-
> 1 file changed, 12 insertions(+),
dma_alloc_coherent is not just the page allocator. The only valid
arguments to pass are either GFP_ATOMIC or GFP_ATOMIC with possible
modifiers of __GFP_NORETRY or __GFP_NOWARN.
Signed-off-by: Christoph Hellwig
---
drivers/infiniband/hw/qib/qib_iba6120.c | 2 +-
Many architectures (e.g. arm, m68 and sh) have always used exact
allocation in their dma coherent allocator, which avoids a lot of
memory waste especially for larger allocations. Lift this behavior
into the generic allocator so that dma-direct and the generic IOMMU
code benefit from this behavior
comedi_buf.c abuse the DMA API in gravely broken ways, as it assumes it
can call virt_to_page on the result, and the just remap it as uncached
using vmap. Disable the driver until this API abuse has been fixed.
Signed-off-by: Christoph Hellwig
---
drivers/staging/comedi/Kconfig | 1 +
1 file
dma_alloc_coherent is not just the page allocator. The only valid
arguments to pass are either GFP_ATOMIC or GFP_ATOMIC with possible
modifiers of __GFP_NORETRY or __GFP_NOWARN.
Signed-off-by: Christoph Hellwig
---
drivers/infiniband/hw/hfi1/init.c | 22 +++---
1 file changed,
dma_alloc_coherent is not just the page allocator. The only valid
arguments to pass are either GFP_ATOMIC or GFP_ATOMIC with possible
modifiers of __GFP_NORETRY or __GFP_NOWARN.
Signed-off-by: Christoph Hellwig
---
drivers/net/wireless/intel/iwlwifi/fw/dbg.c | 3 +--
Lift the code to clear __GFP_COMP from arm into the common DMA
allocator path. For one this fixes the various other patches that
call alloc_pages_exact or split_page in case a bogus driver passes
the argument, and it also prepares for doing exact allocation in
the generic dma-direct allocator.
No need to duplicate the logic over two functions that are almost the
same.
Signed-off-by: Christoph Hellwig
---
include/linux/gfp.h | 5 +++--
mm/page_alloc.c | 39 +++
2 files changed, 10 insertions(+), 34 deletions(-)
diff --git a/include/linux/gfp.h
This fits in with the naming scheme used by alloc_pages_node.
Signed-off-by: Christoph Hellwig
---
include/linux/gfp.h | 2 +-
mm/page_alloc.c | 4 ++--
mm/page_ext.c | 2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/include/linux/gfp.h b/include/linux/gfp.h
index
On 2019-06-14 2:55 p.m., Koenig, Christian wrote:
> Am 14.06.19 um 14:09 schrieb Emil Velikov:
>
>> That said, the proposal will not conflict with the DRM_AUTH removal. If
>> anything it is step 0.5 of the grand master plan.
>
> That's the point I strongly disagree on.
>
> By lowering the
Hi, Christian,
On Fri, 2019-06-14 at 14:58 +0200, Christian König wrote:
> Thomas just a gentle ping on this.
>
> It's not that my live depends on this, but it would still be a nice
> to
> have cleanup.
>
> Thanks,
> Christian.
>
I thought I had answered this, but I can't find it in my
Fix error code from -ENOENT to -ENOMEM.
Cc: Jingoo Han
Signed-off-by: Bartlomiej Zolnierkiewicz
---
drivers/video/fbdev/s3c-fb.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: b/drivers/video/fbdev/s3c-fb.c
===
On Fri, Jun 14, 2019 at 11:27:45AM +0200, Jacopo Mondi wrote:
> Hi Daniel,
>
> On Fri, Jun 14, 2019 at 10:42:51AM +0200, Daniel Vetter wrote:
> > On Fri, Jun 14, 2019 at 10:15:52AM +0200, Jacopo Mondi wrote:
> > > Hi Laurent,
> > >thanks for review
> > >
> > > On Fri, Jun 07, 2019 at
Fix error code from -ENODEV to -ENOMEM.
Cc: Maik Broemme
Signed-off-by: Bartlomiej Zolnierkiewicz
---
drivers/video/fbdev/intelfb/intelfbdrv.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: b/drivers/video/fbdev/intelfb/intelfbdrv.c
On Fri, Jun 14, 2019 at 07:29:23PM +0800, Young Xiao wrote:
> We should check mode_config_initialized flag in amdgpu_hotplug_work_func.
>
> See commit 7f98ca454ad3 ("drm/radeon: fix hotplug race at startup") for
> details.
>
> Signed-off-by: Young Xiao <92siuy...@gmail.com>
> ---
>
On Wed, May 29, 2019 at 9:16 AM Alyssa Rosenzweig wrote:
>
> Woohoo! Patches 1-3 are R-b; patch 4 is A-b. Exciting progress! Hoping
> to hear what Rob and Steven think :)
All looks fine to me, but there's a kbuild error on patch 4 that needs
to be fixed.
Rob
On Fri, Jun 14, 2019 at 05:30:32PM +0200, Greg KH wrote:
> On Fri, Jun 14, 2019 at 04:48:57PM +0200, Christoph Hellwig wrote:
> > On Fri, Jun 14, 2019 at 04:02:39PM +0200, Greg KH wrote:
> > > Perhaps a hint as to how we can fix this up? This is the first time
> > > I've heard of the comedi code
On Fri, Jun 14, 2019 at 5:49 PM Daniel Vetter wrote:
>
> On Wed, Jun 12, 2019 at 09:18:56PM -0500, Alex Deucher wrote:
> > Hi Dave, Daniel,
> >
> > Fixes for 5.2:
> > - Extend previous vce fix for resume to uvd and vcn
> > - Fix bounds checking in ras debugfs interface
> > - Fix a regression on
Add dt-bindings documentation for Raydium RM67191 DSI panel.
Signed-off-by: Robert Chiras
---
.../bindings/display/panel/raydium,rm67191.txt | 42 ++
1 file changed, 42 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/raydium,rm67191.txt
This patch-set contains the DRM panel driver and dt-bindings documentation
for the DSI driven panel: Raydium RM67191.
Robert Chiras (2):
dt-bindings: display: panel: Add support for Raydium RM67191 panel
drm/panel: Add support for Raydium RM67191 panel driver
https://bugs.freedesktop.org/show_bug.cgi?id=108987
--- Comment #2 from CI Bug Log ---
The CI Bug Log issue associated to this bug has been archived.
New failures matching the above filters will not be associated to this bug
anymore.
--
You are receiving this mail because:
You are the
https://bugs.freedesktop.org/show_bug.cgi?id=108987
Lakshmi changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Am Donnerstag, 23. Mai 2019, 00:46:29 CEST schrieb Justin Swartz:
> Like the RK3328, RK322x SoCs offer a Synopsis DesignWare HDMI transmitter
> and an Innosilicon HDMI PHY.
>
> Add a new dw_hdmi_plat_data struct, rk3228_hdmi_drv_data.
> Assign a set of mostly generic rk3228_hdmi_phy_ops
Am 14.06.19 um 14:56 schrieb Peter Zijlstra:
On Fri, Jun 14, 2019 at 02:41:20PM +0200, Christian König wrote:
The ww_mutex implementation allows for detection deadlocks when multiple
threads try to acquire the same set of locks in different order.
The problem is that handling those deadlocks
On Fri, Jun 14, 2019 at 02:41:22PM +0200, Christian König wrote:
> Use the provided macros instead of implementing deadlock handling on our own.
>
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/drm_gem.c | 49 ++-
> 1 file changed, 12 insertions(+),
Hi Fabio,
On Vi, 2019-06-14 at 09:59 -0300, Fabio Estevam wrote:
> On Fri, Jun 14, 2019 at 8:53 AM Robert Chiras
> wrote:
> >
> >
> > Add dt-bindings documentation for Raydium RM67191 DSI panel.
> >
> > Signed-off-by: Robert Chiras
> > ---
> > .../bindings/display/panel/raydium,rm67191.txt
On Fri, Jun 14, 2019 at 10:29 AM Robert Chiras wrote:
> The GPIO is active high, and the above sequence was received from the
> panel vendor in the following form:
> SET_RESET_PIN(1);
> MDELAY(10);
> SET_RESET_PIN(0);
> MDELAY(5);
> SET_RESET_PIN(1);
>
1 - 100 of 377 matches
Mail list logo
