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 10:37:04PM -0500, Jason Ekstrand wrote:
> On Mon, Mar 16, 2020 at 6:39 PM Roman Gilg wrote:
> >
> > On Wed, Mar 11, 2020 at 8:21 PM Jason Ekstrand wrote:
> > >
> > > On Wed, Mar 11, 2020 at 12:31 PM Jason Ekstrand
> > > wrote:
> > > >
> > > > All,
> > > >
> > > > Sorry f
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 desktop platform and not just a few
> weston examples. However, som
Hi Daniel.
On Tue, Mar 17, 2020 at 08:15:47AM +0100, Daniel Vetter wrote:
> We're getting some random other stuff that we're not relly interested
really
> in, so match only word boundaries. Also avoid the capture group while
> at it.
>
> Sug
On Thursday, March 12, 2020 3:43 PM, Harry Wentland wrote:
> Not the main VRR expert and we're still discussing this internally but I
> think it'll very much depend on the display whether you'll see flicker
> in this case.
>
> The other complication is that for gaming we don't want to use the
> c
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
>>> the GFX pipeline) at the end of command buffers and there is only 1
>>>
On Wed, Mar 11, 2020 at 03:55:37PM +0100, Andrzej Pietrasiewicz wrote:
> The new struct contains afbc-specific data.
>
> The new function can be used by drivers which support afbc to complete
> the preparation of struct drm_afbc_framebuffer. It must be called after
> allocating the said struct and
Hi Maxime.
On Tue, Mar 17, 2020 at 09:49:59AM +0100, Maxime Ripard wrote:
> 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-
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:
> > All the SPI devices will be declared under a spi controller node that
> > will validate its child nodes (and thus the devices) already.
> This was the missing piece -
From: Colin Ian King
There are spelling mistakes in pr_err messages and a comment. Fix these.
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 2 +-
drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c| 2 +-
drivers/gpu/drm/amd/amdkfd/kfd_flat_memory.c | 2 +-
3 files
On Mon, 2 Mar 2020 at 18:29, Emil Velikov wrote:
>
> On Wed, 19 Feb 2020 at 13:27, Emil Velikov wrote:
> >
> > From: Emil Velikov
> >
> > This commit reworks the permission handling of the two ioctls. In
> > particular it enforced the CAP_SYS_ADMIN check only, if:
> > - we're issuing the ioctl
On Tue, 2020-03-17 at 08:15 +0100, Daniel Vetter wrote:
> 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.
[]
> diff --git a/MAINTAINERS b/MAINTAINERS
[]
> @@ -5025,7 +5025,7 @@ F: include/lin
The name of the devicetree directory is wrong on those three
TI bindings:
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml | 2 +-
Documentation/devicetree/bindings/display/ti/ti,j721e-dss.yaml | 2 +-
Documentation/devicetree/bindings/displ
Some filesystem references got broken by a previous patch
series I submitted. Address those.
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/ABI/stable/sysfs-devices-node | 2 +-
Documentation/ABI/testing/procfs-smaps_rollup | 2 +-
Documentation/admin-guide/cpu-load.rst| 2 +
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
---
Documentation/admin-guide/kernel-parameters.txt | 2 +-
Documentation/memory-barriers.
On 2020-03-17 5:08 a.m., Simon Ser wrote:
> On Thursday, March 12, 2020 3:43 PM, Harry Wentland wrote:
>
>> Not the main VRR expert and we're still discussing this internally but I
>> think it'll very much depend on the display whether you'll see flicker
>> in this case.
>>
>> The other compli
Hi, Jitao:
I agree with Neil, so please base on Boris' effort to negotiate with bridge.
Regards,
Chun-Kuang Hu
Neil Armstrong 於 2020年3月11日 週三 下午9:53寫道：
>
> Hi,
>
> On 11/03/2020 08:18, Jitao Shi wrote:
> > Some chips's sample mode are rising, falling and dual edge (both
> > falling and rising
Hi Igor,
First of all, thanks for your patch.
Just a few suggestions:
* Avoid using "Fix" in this sort of patch. Usually, we use "Fix" for
indicating a bug fix or similar. You can read more about it here:
https://kernelnewbies.org/PatchPhilosophy
* Patch subject format may vary between subsys
On 17/03/2020 15:10, Mauro Carvalho Chehab wrote:
> The name of the devicetree directory is wrong on those three
> TI bindings:
>
> Signed-off-by: Mauro Carvalho Chehab
Acked-by: Jyri Sarha
> ---
> Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml | 2 +-
> Documentation/devicetr
i2c_new_client() is deprecated, use the replacement
i2c_new_client_device(). Also, we have a helper to check if a driver is
bound. Use it to simplify the code. Note that this changes the errno for
a failed device creation from ENOMEM to ENODEV. No callers currently
interpret this errno, though, so
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 the
> > HMM_PFN_DEVICE_PRIVATE flag in
Hello Icenowy,
On Mon, Mar 16, 2020 at 09:35:01PM +0800, Icenowy Zheng wrote:
> Xingbangda XBD599 is a 5.99" 720x1440 MIPI-DSI IPS LCD panel made by
> Xingbangda, which is used on PinePhone final assembled phones.
>
> [snip]
>
> +static const struct drm_display_mode xbd599_default_mode = {
> +
Xingbangda XBD599 is a 5.99" 720x1440 MIPI-DSI LCD panel.
Add its device tree binding.
Signed-off-by: Icenowy Zheng
---
Changes in v2:
- Example fix.
- Format fix.
.../display/panel/xingbangda,xbd599.yaml | 50 +++
1 file changed, 50 insertions(+)
create mode 100644
Docu
The max() function call in horizontal timing calculation shouldn't pad a
length already subtracted with overhead to overhead, instead it should
only prevent the set timing to underflow.
Signed-off-by: Icenowy Zheng
---
No changes in v2.
drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 10 +-
1
Shenzhen Xingbangda Display Technology Co., Ltd is a company which
produces LCD modules. It supplies the LCD panels of the PinePhone series
(the developers' kit and the final phone).
Add the vendor prefix of it.
Signed-off-by: Icenowy Zheng
---
No changes in v2.
Documentation/devicetree/bindin
On Wed, Mar 11, 2020 at 03:34:58PM -0300, Jason Gunthorpe wrote:
> From: Jason Gunthorpe
>
> The hmm_range_fault() flow is fairly complicated. The scheme allows the
> caller to specify if it needs a usable result for each page, or if it only
> needs the current page table status filled in. This m
On Mon, Mar 16, 2020 at 10:02:50AM +0100, Christoph Hellwig wrote:
> On Wed, Mar 11, 2020 at 03:35:00PM -0300, Jason Gunthorpe wrote:
> > @@ -694,6 +672,15 @@ long hmm_range_fault(struct hmm_range *range, unsigned
> > int flags)
> > return -EBUSY;
> > ret = walk_pag
On 3/6/20 12:08 PM, Daniel Vetter wrote:
> Acked-by: Daniel Vetter
The series has been pushed on drm-misc-next.
Thanks,
Benjamin
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
This patchset adds support for the LCD panel of PinePhone.
The first 3 patches are for the panel itself, and the last 2 patches are
for enabling it on PinePhone.
PATCH 4 is the fix of a bug in sun6i_mipi_dsi which will gets triggered
on XBD599.
Icenowy Zheng (5):
dt-bindings: vendor-prefixes:
min(max) is type of uint32_t, min < 0(max < 0) is never true.
move it.
Addressed-Coverity: ("Unsigned compared against 0")
Signed-off-by: Qiujun Huang
---
drivers/gpu/drm/amd/powerplay/amdgpu_smu.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/powerplay/amdgpu_smu.c
On Mon, Mar 16, 2020 at 08:32:16PM +0100, Christoph Hellwig wrote:
> Hmm range fault will succeed for any kind of device private memory,
> even if it doesn't belong to the calling entity. While nouveau
> has some crude checks for that, they are broken because they assume
> nouveau is the only user
"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, PM core adds a refcount on all the
devices and calls device suspend, sinc
> That's not true; you can post back a sync token every time the client
> buffer is used by the compositor.
Technically, yes but it's very cumbersome and invasive to the point
where it becomes impractical. Explicit sync is much cleaner solution.
> For instance, Mesa adds the `wl_drm` extension, wh
On Mon, Mar 16, 2020 at 10:05:03AM +0100, Christoph Hellwig wrote:
> On Wed, Mar 11, 2020 at 03:35:01PM -0300, Jason Gunthorpe wrote:
> > From: Jason Gunthorpe
> >
> > This eventually calls into handle_mm_fault() which is a sleeping function.
> > Release the lock first.
> >
> > hmm_vma_walk_hole
Em dom., 15 de mar. de 2020 às 10:46, Sam Ravnborg
escreveu:
> Signed-off-by: Sam Ravnborg
> Cc: Marco Franchi
> Cc: Thierry Reding
> Cc: Sam Ravnborg
> ---
>
Thanks!
Reviewed-by: Marco Franchi
___
dri-devel mailing list
dri-devel@lists.freedeskt
Add DISP_CC_MDSS_ROT_CLK and DISP_CC_MDSS_AHB_CLK
in the assigned clocks list for sc7180 target.
Signed-off-by: Krishna Manikandan
---
arch/arm64/boot/dts/qcom/sc7180.dtsi | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/sc7180.dtsi
b/arch/arm64/
> As long as we can fall back to not using fences then we should be fine.
Buffers written by the camera are trivial because you control what
happens - just don't attach fence, so that the capture can be used
immediately. For recycled buffers there's an extra bit of work to do
because won't be up
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 cross
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
> > > > active
> 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 tex
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 cl
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 turned
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 IOVA
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 instanc
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 removing
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 , <
rodrig
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.
drivers/g
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 000fa4a1899f..6e960d57
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 a/arch/arm64/boot/dts/allwinne
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
> Documentati
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 a/
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: https://syzk
> 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
https://lists.freedesktop.org/mailman/li
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 an
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 not
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 t
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
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 describe
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 -
> .../display/panel/jdi,lt070me05
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
> to
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 out
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
Documentati
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 -
.../panel/kingdisplay,kd035g
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: us
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 Gun
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 Cheha
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 c
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 a/d
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 vim
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 -Wtautologic
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 e
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
--- a/drivers/g
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
drivers/pwm/pwm-b
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 des
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 cgro
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, 2
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:
> https://lore.kernel.org/lkml/b56602fcf79f849e733e7b521bb0e17895d390fa.1582230
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 f
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: syzbot+05835159fe322770f...@syzkaller.appspotma
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 ca
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
> Subject
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:
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 shou
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
> >>> the
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 ne
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 fo
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 tasks)
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, M
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 llvmp
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 *are*
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 = &encoder->crtc->state->adjusted_mode;
@@ -1314,6 +1438,92 @@ static int vc4_hdmi_init_resources(struct vc4_hdmi
*vc4_hdmi)
return 0;
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 wo
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 way
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
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
> > >
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
Cc:
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
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 th
1 - 100 of 144 matches
Mail list logo
