On Tue, Mar 17, 2020 at 7:08 PM Jason Ekstrand wrote:
>
> On Tue, Mar 17, 2020 at 7:16 PM Jacob Lifshay
> wrote:
> >
> > On Tue, Mar 17, 2020 at 11:14 AM Lucas Stach wrote:
> > >
> > > Am Dienstag, den 17.03.2020, 10:59 -0700 schrieb Jacob Lifshay:
> > > > I think I found a
Hi Dave,
20. 3. 18. 오전 11:17에 Dave Airlie 이(가) 쓴 글:
> This seems to contain a exynos drm fixes backmerge, please don't do
> that without a headsup.
>
> Can you send one without that or do you need a fixes backmerge, if so
> please request me to do that first, then rebase this and send it.
Sorry
Hi all,
Today's linux-next merge of the drm tree got a conflict in:
arch/arm/configs/omap2plus_defconfig
between commit:
98c2cc359f8f ("ARM: omap2plus_defconfig: Update for moved and dropped
options")
from the omap tree and commit:
e7e67d9a2f1d ("drm/omap: Switch the HDMI and VENC
This seems to contain a exynos drm fixes backmerge, please don't do
that without a headsup.
Can you send one without that or do you need a fixes backmerge, if so
please request me to do that first, then rebase this and send it.
Dave.
On Mon, 16 Mar 2020 at 11:04, Inki Dae wrote:
>
>
On Tue, Mar 17, 2020 at 7:16 PM Jacob Lifshay wrote:
>
> On Tue, Mar 17, 2020 at 11:14 AM Lucas Stach wrote:
> >
> > Am Dienstag, den 17.03.2020, 10:59 -0700 schrieb Jacob Lifshay:
> > > I think I found a userspace-accessible way to create sync_files and
> > > dma_fences that would fulfill the
Since the PWM framework is switching struct pwm_state.duty_cycle's
datatype to u64, prepare for this transition by using DIV_ROUND_UP_ULL
to handle a 64-bit dividend.
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: David Airlie
Cc: Daniel Vetter
Cc: Chris Wilson
Cc: "Ville Syrjälä"
Cc:
Since the PWM framework is switching struct pwm_state.period's datatype
to u64, prepare for this transition by using div_u64 to handle a 64-bit
dividend instead of a straight division operation.
Cc: Lee Jones
Cc: Daniel Thompson
Cc: Jingoo Han
Cc: Bartlomiej Zolnierkiewicz
Cc:
Yes, I will do it.
On Tue, Mar 17, 2020 at 2:04 PM Daniel Vetter wrote:
> On Mon, Mar 16, 2020 at 06:08:30PM -0300, Igor Torrente wrote:
> > Ccing dri-devel and linux-kernel.
>
> git apply-mbox chokes on this, can you pls resubmit?
>
> Thanks, Daniel
>
> >
> > -- Forwarded message
Le mardi 17 mars 2020 à 11:27 -0500, Jason Ekstrand a écrit :
> On Tue, Mar 17, 2020 at 10:33 AM Nicolas Dufresne
> wrote:
> > Le lundi 16 mars 2020 à 23:15 +0200, Laurent Pinchart a écrit :
> > > Hi Jason,
> > >
> > > On Mon, Mar 16, 2020 at 10:06:07AM -0500, Jason Ekstrand wrote:
> > > > On
Replace "pionter" with "pointer" in the drm_gem_handle_create description.
Changes in v2:
- Change subject text
Signed-off-by: Igor Matheus Andrade Torrente
---
drivers/gpu/drm/drm_gem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_gem.c
On Tue, Mar 17, 2020 at 01:59:55PM +0100, Christoph Hellwig wrote:
> On Tue, Mar 17, 2020 at 09:47:55AM -0300, Jason Gunthorpe wrote:
> > I've been using v7 of Ralph's tester and it is working well - it has
> > DEVICE_PRIVATE support so I think it can test this flow too. Ralph are
> > you able?
>
Because period and duty cycle are defined in the PWM framework structs as ints
with units of nanoseconds, the maximum time duration that can be set is limited
to ~2.147 seconds. Consequently, applications desiring to set greater time
periods via the PWM framework are not be able to do so - like,
On Wed, Mar 18, 2020 at 1:02 AM Daniel Vetter wrote:
>
> On Mon, Mar 16, 2020 at 03:18:23PM +0800, Qiujun Huang wrote:
> > We should hold idr_mutex for idr_alloc.
> >
> > Signed-off-by: Qiujun Huang
>
> I've not seen the first version of this anywhere in my inbox, not sure
> where that got lost.
clang warns:
drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c:754:6: warning: variable 'shadow'
is used uninitialized whenever 'if' condition is
false [-Wsometimes-uninitialized]
if (offset == grbm_cntl || offset == grbm_idx)
^
On Wed, Mar 18, 2020 at 12:57 AM Daniel Vetter wrote:
>
> On Mon, Mar 16, 2020 at 11:36:08AM +0800, Qiujun Huang wrote:
> > leases has been destroyed:
> > drm_master_put
> > ->drm_master_destroy
> > ->idr_destroy
> >
> > so the "out_lessee" needn't to call idr_destroy again.
> >
>
Le lundi 16 mars 2020 à 23:15 +0200, Laurent Pinchart a écrit :
> Hi Jason,
>
> On Mon, Mar 16, 2020 at 10:06:07AM -0500, Jason Ekstrand wrote:
> > On Mon, Mar 16, 2020 at 5:20 AM Laurent Pinchart wrote:
> > > On Wed, Mar 11, 2020 at 04:18:55PM -0400, Nicolas Dufresne wrote:
> > > > (I know I'm
Fix a checkpatch warning caused by a misaligned comment block.
Signed-off-by: Igor Matheus Andrade Torrente
---
drivers/gpu/drm/drm_gem.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index
This introduces support for CRC readback on gf119+, using the
documentation generously provided to us by Nvidia:
https://github.com/NVIDIA/open-gpu-doc/blob/master/Display-CRC/display-crc.txt
We expose all available CRC sources. SF, SOR, PIOR, and DAC are exposed
through a single set of "outp"
This introduces support for CRC readback on gf119+, using the
documentation generously provided to us by Nvidia:
https://github.com/NVIDIA/open-gpu-doc/blob/master/Display-CRC/display-crc.txt
We expose all available CRC sources. SF, SOR, PIOR, and DAC are exposed
through a single set of "outp"
We'll be rolling back more things in this function, and the way it's
structured is a bit confusing. So, let's clean this up a bit and just
unroll in the event of failure.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/dispnv50/head.c | 33 +
1 file changed, 23
In order to make sure that we flush disable updates at the right time
when disabling CRCs, we'll need to be able to look at the outp state to
see if we're changing it at the same time that we're disabling CRCs.
So, expose the struct in disp.h.
Signed-off-by: Lyude Paul
---
While most of the functionality on Nvidia GPUs doesn't require using an
explicit handle instead of the main VRAM handle + offset, there are a
couple of places that do require explicit handles, such as CRC
functionality. Since this means we're about to add another
nouveau-chosen handle, let's just
Currently, we modify the depth value stored in the atomic state when
performing a commit in order to workaround the fact we haven't
implemented support for depths higher then 10 yet. This isn't idempotent
though, as it will happen every atomic commit where we modify the OR
state even if the head's
While we expose the ability to turn off hardware dithering for nouveau,
we actually make the mistake of turning it on anyway, due to
dithering_depth containing a non-zero value if our dithering depth isn't
also set to 6 bpc.
So, fix it by never enabling dithering when it's disabled.
We refer to the armed hardware assembly as armh elsewhere in nouveau, so
fix the naming here to make it consistent.
This patch contains no functional changes.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/dispnv50/wndw.c | 12 ++--
1 file changed, 6 insertions(+), 6
While we're not quite ready yet to add support for flexible wndw
mappings, we are going to need to at least keep track of the static wndw
mappings we're currently using in each head's atomic state. We'll likely
use this in the future to implement real flexible window mapping, but
the primary
Nvidia released some documentation on how CRC support works on their
GPUs, hooray!
So: this patch series implements said CRC support in nouveau, along with
adding some special debugfs interfaces for some relevant igt-gpu-tools
tests that we'll be sending in just a short bit.
This additionally
From: Ville Syrjälä
Add some kind of vblank workers. The interface is similar to regular
delayed works, and also allows for re-scheduling.
Whatever hardware programming we do in the work must be fast
(must at least complete during the vblank, sometimes during
the first few scanlines of vblank),
On Tue, Mar 17, 2020 at 11:14 AM Lucas Stach wrote:
>
> Am Dienstag, den 17.03.2020, 10:59 -0700 schrieb Jacob Lifshay:
> > I think I found a userspace-accessible way to create sync_files and
> > dma_fences that would fulfill the requirements:
> >
No functional changes
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/nouveau_connector.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c
b/drivers/gpu/drm/nouveau/nouveau_connector.c
index 9a9a7f5003d3..0d42a7e5deff
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/nouveau_connector.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c
b/drivers/gpu/drm/nouveau/nouveau_connector.c
index 0d42a7e5deff..9fb00c4b9764 100644
---
This function doesn't exist
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/nouveau_bios.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_bios.h
b/drivers/gpu/drm/nouveau/nouveau_bios.h
index 18eb061ccafb..5495f004a297 100644
---
On 3/17/20 5:59 AM, Christoph Hellwig wrote:
On Tue, Mar 17, 2020 at 09:47:55AM -0300, Jason Gunthorpe wrote:
I've been using v7 of Ralph's tester and it is working well - it has
DEVICE_PRIVATE support so I think it can test this flow too. Ralph are
you able?
This hunk seems trivial enough to
On 3/17/20 4:56 AM, Jason Gunthorpe wrote:
On Mon, Mar 16, 2020 at 01:24:09PM -0700, Ralph Campbell wrote:
The reason for it being backwards is that "normally" a device doesn't want
the device private page to be faulted back to system memory, it wants to
get the device private struct page so
On 3/17/20 12:34 AM, Christoph Hellwig wrote:
On Mon, Mar 16, 2020 at 03:49:51PM -0700, Ralph Campbell wrote:
On 3/16/20 12:32 PM, Christoph Hellwig wrote:
Remove the code to fault device private pages back into system memory
that has never been used by any driver. Also replace the usage of
On Tue, 2020-03-17 at 17:48 +0100, Daniel Vetter wrote:
> On Thu, Mar 12, 2020 at 12:17:12PM -0700, Joe Perches wrote:
> > Convert /* fallthrough */ style comments to fallthrough;
> >
> > Convert the various uses of fallthrough comments to fallthrough;
> >
> > Done via script
> > Link:
> >
Hi,
On Mon, Mar 16, 2020 at 4:06 AM Kalyan Thota wrote:
>
> "The PM core always increments the runtime usage counter
> before calling the ->suspend() callback and decrements it
> after calling the ->resume() callback"
>
> DPU and DSI are managed as runtime devices. When
> suspend is triggered,
Explicit synchronization is the future. At least, that seems to be what
most userspace APIs are agreeing on at this point. However, most of our
Linux APIs (both userspace and kernel UAPI) are currently built around
implicit synchronization with dma-buf. While work is ongoing to change
many of
On Mon, Mar 16, 2020 at 6:41 PM Qiang Yu wrote:
> Not concrete reason, as the comment, trace point when
> dma_fence_signal act as the task completion event, so not add duplicate
> one.
I see. Patch is:
Reviewed-by: Vasily Khoruzhick
Regards,
Vasily
We're getting some random other stuff that we're not really interested
in, so match only word boundaries. Also avoid the capture group while
at it.
Suggested by Joe Perches.
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linaro-mm-...@lists.linaro.org
Cc: Joe Perches
On Mon, Mar 16, 2020 at 3:44 PM Gerd Hoffmann wrote:
>
> Hi,
>
> > >> At virtio level it is pretty simple: The host completes the SUBMIT_3D
> > >> virtio command when it finished rendering, period.
> > >>
> > >>
> > >> On the guest side we don't need the fence_id. The completion callback
> >
Hi Sam,
Thank you for the patch.
On Sat, Mar 14, 2020 at 04:30:47PM +0100, Sam Ravnborg wrote:
> Fix a few grammar/editorial issues spotted by Laurent Pinchart.
>
> Signed-off-by: Sam Ravnborg
> Cc: Laurent Pinchart
> Cc: Rob Herring
> ---
> .../bindings/display/panel/display-timings.yaml
Hi Sam,
Thank you for the patch.
On Sat, Mar 14, 2020 at 04:30:46PM +0100, Sam Ravnborg wrote:
> The "data-mapping" property may not be the best way to describe the
> interface between panels and display interfaces.
> Drop use of in the panel-simple driver, so we have time to find
> the right
Hi Sam,
Thank you for the patch.
On Sat, Mar 14, 2020 at 04:30:45PM +0100, Sam Ravnborg wrote:
> data-mapping may not be the best way to describe the
> data format used between panels and display interface.
>
> Drop it from the panel-dpi binding so we do not start to rely on it.
> We can then
On 2/24/20 4:07 AM, Maxime Ripard wrote:
static void vc4_hdmi_encoder_enable(struct drm_encoder *encoder)
{
struct drm_display_mode *mode = >crtc->state->adjusted_mode;
@@ -1314,6 +1438,92 @@ static int vc4_hdmi_init_resources(struct vc4_hdmi
*vc4_hdmi)
return 0;
}
Am Dienstag, den 17.03.2020, 10:59 -0700 schrieb Jacob Lifshay:
> On Tue, Mar 17, 2020 at 10:21 AM Lucas Stach wrote:
> > Am Dienstag, den 17.03.2020, 10:12 -0700 schrieb Jacob Lifshay:
> > > One related issue with explicit sync using sync_file is that combined
> > > CPUs/GPUs (the CPU cores
On Tue, Mar 17, 2020 at 10:21 AM Lucas Stach wrote:
>
> Am Dienstag, den 17.03.2020, 10:12 -0700 schrieb Jacob Lifshay:
> > One related issue with explicit sync using sync_file is that combined
> > CPUs/GPUs (the CPU cores *are* the GPU cores) that do all the
> > rendering in userspace (like
Am Dienstag, den 17.03.2020, 11:33 -0400 schrieb Nicolas Dufresne:
> Le lundi 16 mars 2020 à 23:15 +0200, Laurent Pinchart a écrit :
> > Hi Jason,
> >
> > On Mon, Mar 16, 2020 at 10:06:07AM -0500, Jason Ekstrand wrote:
> > > On Mon, Mar 16, 2020 at 5:20 AM Laurent Pinchart wrote:
> > > > On Wed,
Am Dienstag, den 17.03.2020, 10:12 -0700 schrieb Jacob Lifshay:
> One related issue with explicit sync using sync_file is that combined
> CPUs/GPUs (the CPU cores *are* the GPU cores) that do all the
> rendering in userspace (like llvmpipe but for Vulkan and with extra
> instructions for GPU
Hi,
On Sun, Mar 15, 2020 at 12:42 PM Christophe JAILLET
wrote:
>
> If this memory allocation fails, we have to go through the error handling
> path to perform some clean-up, as already done in other other paths of
> this function.
>
> Fixes: db735fc4036b ("drm/msm: Set dma maximum segment size
On Tue, Mar 17, 2020 at 12:13 PM Jacob Lifshay wrote:
>
> One related issue with explicit sync using sync_file is that combined
> CPUs/GPUs (the CPU cores *are* the GPU cores) that do all the
> rendering in userspace (like llvmpipe but for Vulkan and with extra
> instructions for GPU tasks) but
On Tue., Mar. 17, 2020, 06:02 Michel Dänzer, wrote:
> On 2020-03-16 7:33 p.m., Marek Olšák wrote:
> > On Mon, Mar 16, 2020 at 5:57 AM Michel Dänzer
> wrote:
> >> On 2020-03-16 4:50 a.m., Marek Olšák wrote:
> >>> The synchronization works because the Mesa driver waits for idle
> (drains
> >>>
One related issue with explicit sync using sync_file is that combined
CPUs/GPUs (the CPU cores *are* the GPU cores) that do all the
rendering in userspace (like llvmpipe but for Vulkan and with extra
instructions for GPU tasks) but need to synchronize with other
drivers/processes is that there
We're getting some random other stuff that we're not relly interested
in, so match only word boundaries. Also avoid the capture group while
at it.
Suggested by Joe Perches.
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linaro-mm-...@lists.linaro.org
Cc: Joe Perches
Cc:
On Mon, Mar 16, 2020 at 06:08:30PM -0300, Igor Torrente wrote:
> Ccing dri-devel and linux-kernel.
git apply-mbox chokes on this, can you pls resubmit?
Thanks, Daniel
>
> -- Forwarded message -
> From: Igor Matheus Andrade Torrente
> Date: Mon, Mar 16, 2020 at 6:04 PM
>
On Mon, Mar 16, 2020 at 03:18:23PM +0800, Qiujun Huang wrote:
> We should hold idr_mutex for idr_alloc.
>
> Signed-off-by: Qiujun Huang
I've not seen the first version of this anywhere in my inbox, not sure
where that got lost.
Anyway, this seems like a false positive - I'm assuming this was
On Mon, Mar 16, 2020 at 11:36:08AM +0800, Qiujun Huang wrote:
> leases has been destroyed:
> drm_master_put
> ->drm_master_destroy
> ->idr_destroy
>
> so the "out_lessee" needn't to call idr_destroy again.
>
> Reported-and-tested-by:
On Fri, Mar 13, 2020 at 09:41:52AM +0100, Gerd Hoffmann wrote:
> Shutdown of firmware framebuffer has a bunch of problems. Because
> of this the framebuffer region might still be reserved even after
> drm_fb_helper_remove_conflicting_pci_framebuffers() returned.
Is that still the fbdev lifetime
On Thu, Mar 12, 2020 at 12:17:12PM -0700, Joe Perches wrote:
> Convert /* fallthrough */ style comments to fallthrough;
>
> Convert the various uses of fallthrough comments to fallthrough;
>
> Done via script
> Link:
>
On Tue, Mar 17, 2020 at 10:33 AM Nicolas Dufresne wrote:
>
> Le lundi 16 mars 2020 à 23:15 +0200, Laurent Pinchart a écrit :
> > Hi Jason,
> >
> > On Mon, Mar 16, 2020 at 10:06:07AM -0500, Jason Ekstrand wrote:
> > > On Mon, Mar 16, 2020 at 5:20 AM Laurent Pinchart wrote:
> > > > On Wed, Mar 11,
Hi Tejun,
What's your thoughts on this latest series?
Regards,
Kenny
On Wed, Feb 26, 2020 at 2:02 PM Kenny Ho wrote:
>
> This is a submission for the introduction of a new cgroup controller for the
> drm subsystem follow a series of RFCs [v1, v2, v3, v4]
>
> Changes from PR v1
> * changed
On Tue, Mar 17, 2020 at 3:01 AM Simon Ser wrote:
>
> On Monday, March 16, 2020 5:04 PM, Jason Ekstrand
> wrote:
>
> > Hopefully, that will provide some motivation for other compositors
> > (kwin, gnome-shell, etc.) because they now have a real user of it in
> > an upstream driver for a major
To avoid duplication of pwm polarity definitions,
remove "enum pwm_polarity" and use macros instead.
Prepare to use both polarity flags in DTs.
Signed-off-by: Oleksandr Suvorov
---
drivers/pwm/core.c | 2 +-
drivers/pwm/pwm-atmel-tcb.c | 8
Signed-off-by: Yassine Oudjana
---
drivers/gpu/drm/amd/amdgpu/si_dpm.c | 1 -
drivers/gpu/drm/radeon/si_dpm.c | 1 -
2 files changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/si_dpm.c
b/drivers/gpu/drm/amd/amdgpu/si_dpm.c
index 4cb4c891120b..0860e85a2d35 100644
---
On Fri, Feb 14, 2020 at 7:36 AM Michel Dänzer wrote:
>
> On 2020-02-14 12:49 p.m., Jani Nikula wrote:
> > On Fri, 14 Feb 2020, Chris Wilson wrote:
> >> Quoting Jani Nikula (2020-02-14 06:36:15)
> >>> On Thu, 13 Feb 2020, Nathan Chancellor wrote:
> A recent commit in clang added
PWM_POLARITY_* flags were defined in include/linux/pwm.h as a enum and
in include/dt-bindings/pwm/pwm.h as macros.
This patchset fixes duplication and introduces using PWM_POLARITY_NORMAL
flag instead of '0' constant in DT files.
Oleksandr Suvorov (7):
pwm: rename the PWM_POLARITY_INVERSED
Hi Vinay.
On Tue, Mar 17, 2020 at 12:25:42PM +0530, Vinay Simha B N wrote:
> sam,
>
> i need some inputs on the below error. I had created this file
> Documentation/devicetree/bindings/display/bridge/toshiba-tc358775.yaml
> by using vim editor. Do we have any tool to create yaml file?
I use
module_put() balances try_module_get(), not request_module(). Fix the
error path to match that.
Fixes: 2066facca4c7 ("drm/kms: slave encoder interface.")
Signed-off-by: Wolfram Sang
---
drivers/gpu/drm/drm_encoder_slave.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git
On Tue, Mar 17, 2020 at 01:28:13PM +0100, Christoph Hellwig wrote:
> On Tue, Mar 17, 2020 at 01:24:45PM +0100, Christoph Hellwig wrote:
> > On Tue, Mar 17, 2020 at 09:15:36AM -0300, Jason Gunthorpe wrote:
> > > > Getting rid of HMM_PFN_DEVICE_PRIVATE seems reasonable to me since a
> > > > driver
sam,
i need some inputs on the below error. I had created this file
Documentation/devicetree/bindings/display/bridge/toshiba-tc358775.yaml
by using vim editor. Do we have any tool to create yaml file?
i do not get the error when running 'make dt_binding_check' in my
build environment
While converting I2C users to new APIs, I found a refcounting problem in
the encoder_slave implementation. This series fixes it and converts to
the new API.
Based on linux-next and only build tested.
Wolfram Sang (2):
drm: encoder_slave: fix refcouting error for modules
drm: encoder_slave:
On Mon, Mar 16, 2020 at 01:24:09PM -0700, Ralph Campbell wrote:
> The reason for it being backwards is that "normally" a device doesn't want
> the device private page to be faulted back to system memory, it wants to
> get the device private struct page so it can update its page table to point
>
On Mon, Mar 16, 2020 at 10:13:47AM +0100, Christoph Hellwig wrote:
> On Wed, Mar 11, 2020 at 03:35:06PM -0300, Jason Gunthorpe wrote:
> > From: Jason Gunthorpe
> >
> > Currently if a special PTE is encountered hmm_range_fault() immediately
> > returns EFAULT and sets the HMM_PFN_SPECIAL error
On Mon, Mar 16, 2020 at 06:52:58PM +0100, Christoph Hellwig wrote:
> Add a new opaque owner field to struct dev_pagemap, which will allow
> the hmm and migrate_vma code to identify who owns ZONE_DEVICE memory,
> and refuse to work on mappings not owned by the calling entity.
Using a pointer seems
On Tue, Mar 17, 2020 at 02:06:08PM +0100, Christoph Hellwig wrote:
> On Tue, Mar 17, 2020 at 09:53:17AM -0300, Jason Gunthorpe wrote:
> > > Thinking out loud a bit more:
> > >
> > > - do we really need HMM_PFN_ERROR, or is just a return value from
> > >hmm_range_fault enough?
> >
> > I'm
On Mon, Mar 16, 2020 at 07:49:35PM +0100, Christoph Hellwig wrote:
> On Mon, Mar 16, 2020 at 11:42:19AM -0700, Ralph Campbell wrote:
> >
> > On 3/16/20 10:52 AM, Christoph Hellwig wrote:
> >> No driver has actually used properly wire up and support this feature.
> >> There is various code related
Hi Sam,
On Sun, Mar 15, 2020 at 02:43:42PM +0100, Sam Ravnborg wrote:
> Independent bindings can be SPI slaves which for example is
> the case for several panel bindings.
>
> Move SPI slave properties to spi-slave.yaml so the independent
> SPI slave bindings can include spi-slave.yaml rather than
sam,
Reviewed-by: Vinay Simha BN
Thanks.
On Sun, Mar 15, 2020 at 7:14 PM Sam Ravnborg wrote:
>
> Signed-off-by: Sam Ravnborg
> Cc: Vinay Simha BN
> Cc: Thierry Reding
> Cc: Sam Ravnborg
> ---
> .../display/panel/jdi,lt070me05000.txt| 31 -
>
syzbot has found a reproducer for the following crash on:
HEAD commit:fb33c651 Linux 5.6-rc6
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=17dacd55e0
kernel config: https://syzkaller.appspot.com/x/.config?x=9f894bd92023de02
dashboard link:
> vkAcquireNextImageKHR() [...] it's the application's decision whether it
> wants a fence, a semaphore, both or none
Correction: "or none" is not allowed
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
On Mon, Mar 16, 2020 at 08:32:15PM +0100, Christoph Hellwig wrote:
> diff --git a/mm/hmm.c b/mm/hmm.c
> index 180e398170b0..cfad65f6a67b 100644
> +++ b/mm/hmm.c
> @@ -118,15 +118,6 @@ static inline void hmm_pte_need_fault(const struct
> hmm_vma_walk *hmm_vma_walk,
> /* We aren't ask to do
On Mon, Mar 16, 2020 at 01:49:53PM +0100, Christoph Hellwig wrote:
> On Mon, Mar 16, 2020 at 09:10:53AM -0300, Jason Gunthorpe wrote:
> > On Mon, Mar 16, 2020 at 10:13:47AM +0100, Christoph Hellwig wrote:
> > > On Wed, Mar 11, 2020 at 03:35:06PM -0300, Jason Gunthorpe wrote:
> > > > From: Jason
On Tue, Mar 17, 2020 at 02:10:47PM +0100, Mauro Carvalho Chehab wrote:
> Several references got broken due to txt to ReST conversion.
>
> Several of them can be automatically fixed with:
>
> scripts/documentation-file-ref-check --fix
>
> Signed-off-by: Mauro Carvalho Chehab
>
Hi,
On Mon, Mar 16, 2020 at 10:43:46PM +0100, Sam Ravnborg wrote:
> On Mon, Mar 16, 2020 at 09:48:50PM +0100, Maxime Ripard wrote:
> > Hi Sam,
> >
> > On Sun, Mar 15, 2020 at 02:43:42PM +0100, Sam Ravnborg wrote:
> > > Independent bindings can be SPI slaves which for example is
> > > the case for
Current implementation shows error as "failed to set gamma: Function
no implemented" if platform specific drm has no gamma property implemented
Signed-off-by: Rohit Visavalia
---
tests/modetest/modetest.c | 21 -
1 file changed, 16 insertions(+), 5 deletions(-)
diff --git
Hi Sam,
Le dim. 15 mars 2020 à 14:43, Sam Ravnborg a écrit
:
Signed-off-by: Sam Ravnborg
Reviewed-by: Paul Cercueil
Cheers,
-Paul
Cc: Paul Cercueil
Cc: Thierry Reding
Cc: Sam Ravnborg
---
.../panel/kingdisplay,kd035g6-54nt.txt| 42 -
PinePhone uses PWM backlight and a XBD599 LCD panel over DSI for
display.
Add its device nodes.
Signed-off-by: Icenowy Zheng
---
No changes in v2.
.../dts/allwinner/sun50i-a64-pinephone.dtsi | 37 +++
1 file changed, 37 insertions(+)
diff --git
Hi Sam,
On Sat, Mar 14, 2020 at 04:30:45PM +0100, Sam Ravnborg wrote:
> data-mapping may not be the best way to describe the
> data format used between panels and display interface.
>
> Drop it from the panel-dpi binding so we do not start to rely on it.
> We can then work out how to best
This patch series is against next-20200317. It fixes all references to files
under Documentation/* that were moved, renamed or removed.
After this patch series, this script:
./scripts/documentation-file-ref-check
Doesn't complain about any broken reference.
Mauro Carvalho Chehab (12
Xingbangda XBD599 is a 5.99" 720x1440 MIPI-DSI IPS LCD panel made by
Xingbangda, which is used on PinePhone final assembled phones.
Add support for it.
Signed-off-by: Icenowy Zheng
---
Changes in v2:
- Raised copyright info to 2020.
- Sort panel operation functions.
- Sort inclusion.
Ccing dri-devel and linux-kernel.
-- Forwarded message -
From: Igor Matheus Andrade Torrente
Date: Mon, Mar 16, 2020 at 6:04 PM
Subject: [PATCH] Staging: drm_gem: Fix a typo in a function comment
To: , ,
, , , <
sumit.sem...@linaro.org>
Cc: Igor Matheus Andrade Torrente , <
On Mon, Mar 16, 2020 at 07:13:24PM +0100, Christoph Hellwig wrote:
> On Mon, Mar 16, 2020 at 03:07:13PM -0300, Jason Gunthorpe wrote:
> > I chose this to be simple without having to goto unwind it.
> >
> > So, instead like this:
>
> As ѕaid, and per the previous discussion: I think just
Fix a checkpatch warning caused by a misaligned comment block.
Signed-off-by: Igor Matheus Andrade Torrente
---
drivers/gpu/drm/drm_gem.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index
On Mon, Mar 16, 2020 at 11:42:19AM -0700, Ralph Campbell wrote:
>
> On 3/16/20 10:52 AM, Christoph Hellwig wrote:
> > No driver has actually used properly wire up and support this feature.
> > There is various code related to it in nouveau, but as far as I can tell
> > it never actually got
On Mon, Mar 16, 2020 at 02:52:13AM -0700, Christoph Hellwig wrote:
> On Mon, Mar 16, 2020 at 10:41:42AM +0100, Christian König wrote:
> > Well I would prefer if the drivers can somehow express their requirements
> > and get IOVA structures already in the form they need.
> >
> > Converting the
Hi,
Here is what should be the final drm-misc-next PR for 5.7.
Maxime
drm-misc-next-2020-03-17:
drm-misc-next for 5.7:
UAPI Changes:
Cross-subsystem Changes:
Core Changes:
- dp-mst: Remove register_connector callback, add drm_dp_destroy_connector
- Changes to scnprintf on multiple
Hi Jason,
I've been wrestling with the sync problems in Wayland some time ago, but
only with regards to 3D drivers.
The guarantee given by the GL/GLES spec is limited to a single graphics
context. If the same buffer is accessed by 2 contexts the outcome is
unspecified. The cross-context and
On Tue, Mar 17, 2020 at 01:32:10PM +0100, Christoph Hellwig wrote:
> On Mon, Mar 16, 2020 at 02:12:01PM +0100, Christoph Hellwig wrote:
> > On Mon, Mar 16, 2020 at 10:04:58AM -0300, Jason Gunthorpe wrote:
> > > > Ok. I had some cleanups like this based of older trees, but if you are
> > > >
> GL and GLES are not relevant. What is relevant is EGL, which defines
> interfaces to make things work on the native platform.
Yes and no. This is what EGL spec says about sharing a texture between contexts:
"OpenGL and OpenGL ES makes no attempt to synchronize access to
texture objects. If a
Hi Maxime,
On Mon, 2020-02-24 at 10:07 +0100, Maxime Ripard wrote:
> @@ -1460,6 +1456,7 @@ static int vc4_hdmi_dev_remove(struct platform_device
> *pdev)
> }
>
> struct vc4_hdmi_variant bcm2835_variant = {
> + .max_pixel_clock= 14850,
Just a reminder this might change in the
1 - 100 of 140 matches
Mail list logo
