While this looks rather nice it is most likely the wrong approach since
it doesn't handles other concurrent evictions.
It would most likely be better to add a check calling
drm_dev_is_unplugged() into amdgpu_bo_move().
Regards,
Christian.
Am 09.05.20 um 20:51 schrieb Andrey Grodzovsky:
This
From: Marek Vasut
Add bindings for the LVDS-to-eDP bridge chip, IT6251, which is
used to connect the standard 1920x1080 panel on Novena laptop.
Tested on a Kosagi Novena laptop with imx6 display controller.
Based on v5.7-rc2, applies to drm-misc-next 5e6ed29d72d2
Signed-off-by: Marek Vasut
Si
From: Marek Vasut
Add DT bindings for ITE IT6251 LVDS-to-eDP bridge.
Signed-off-by: Marek Vasut
Signed-off-by: Richard Marko
Cc: Daniel Vetter
Cc: Rob Herring
Cc: Sean Cross
Cc: devicet...@vger.kernel.org
To: dri-devel@lists.freedesktop.org
---
.../bindings/display/bridge/ite,it6251.yaml
This declaration can be avoided so change it.
Signed-off-by: Clément Péron
---
drivers/gpu/drm/panfrost/panfrost_devfreq.c | 38 ++---
1 file changed, 18 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
b/drivers/gpu/drm/panfrost/panfrost_
This use devfreq variable that will be lock with spinlock in future
patches. We should either introduce a function to access this one
but as devfreq is optional let's just remove it.
Signed-off-by: Clément Péron
---
drivers/gpu/drm/panfrost/panfrost_job.c | 4
1 file changed, 4 deletions(-)
Fix all occurrences with the commands below.
$ git grep -l equnce drivers/gpu/ | xargs sed -i 's/equnce/equence/g'
Cc: Alex Deucher
Cc: Christian König
Cc: David (ChunMing) Zhou
Cc: amd-...@lists.freedesktop.org
Signed-off-by: Paul Menzel
---
drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c | 4 ++
S5PV210 can be trivially supported by this driver. Only one of
its FIMC devices (#2) supports the same scaling values as Exynos4, and
it is marked by mainscaler-ext in the DTS (as it is for all of the
Exynos4 devices). It's limits are the same as that of id's 0-2 of
Exynos4 so we don't even need
Tested on Netgear DGND3700v2 (BCM6362 with v2.2 controller).
Signed-off-by: Álvaro Fernández Rojas
---
drivers/mtd/nand/raw/brcmnand/brcmnand.c | 76 +---
1 file changed, 67 insertions(+), 9 deletions(-)
diff --git a/drivers/mtd/nand/raw/brcmnand/brcmnand.c
b/drivers/mtd/na
Hi,
This serie cleans and adds regulator support to Panfrost devfreq.
This is mostly based on comment for the freshly introduced lima
devfreq.
We need to add regulator support because on Allwinner the GPU OPP
table defines both frequencies and voltages.
First patches [01-08] should not change th
Later we will introduce devfreq probing regulator if they
are present. As regulator should be probe only one time we
need to get this logic in the device_init().
panfrost_device is already taking care of devfreq_resume()
and devfreq_suspend(), so it's not totally illogic to move
the devfreq_init()
Fix all occurrences with the command below.
git grep -l frequencey | xargs sed -i 's/frequencey/frequency/g'
Cc: Rob Clark
Cc: Sean Paul
Cc: linux-arm-...@vger.kernel.org
Cc: freedr...@lists.freedesktop.org
Cc: Alex Deucher
Cc: Christian König
Cc: David (ChunMing) Zhou
Cc: amd-...@lists.
Instead of expecting an error from dev_pm_opp_of_add_table()
do a simple device_property_present() check.
Signed-off-by: Clément Péron
---
drivers/gpu/drm/panfrost/panfrost_devfreq.c | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/panfrost/panfr
From: Richard Marko
Contains updated patches I've received from Marek with the following
changes:
- yaml docs migration
- fixed Fabios email
- panel commit split into two according to checkpatch request
- added connector for panel
Last review also requested more details for panel like timings a
On Sat, 9 May 2020 at 18:28, Clément Péron wrote:
>
> Hi Steven,
>
> On Thu, 7 May 2020 at 16:30, Steven Price wrote:
> >
> > On 02/05/2020 23:07, Clément Péron wrote:
> > > Hi Steven,
> > >
> > > On Tue, 14 Apr 2020 at 15:10, Steven Price wrote:
> > >>
> > >> Hi Clément,
> > >>
> > >> On 13/04/
From: Marek Vasut
Add driver for the ITE IT6251 LVDS-to-eDP bridge.
Signed-off-by: Marek Vasut
Signed-off-by: Richard Marko
Cc: Daniel Vetter
Cc: Sean Cross
To: dri-devel@lists.freedesktop.org
---
drivers/gpu/drm/bridge/Kconfig | 12 +
drivers/gpu/drm/bridge/Makefile | 1 +
driv
From: Richard Marko
Contains updated patches I've received from Marek with the following
changes:
- yaml docs migration
- extended documentation
Tested on a Kosagi Novena laptop with imx6 display controller.
Based on v5.7-rc2, applies to drm-misc-next 5e6ed29d72d2
CC: Marek Vasut
Cc: Sean Cr
From: Sean Cross
The Innolux N133HSE panel is a 13.3" 1920x1080 panel that contains an
integrated backlight, and connects via eDP.
It is used in the Kosagi Novena.
Signed-off-by: Sean Cross
Signed-off-by: Richard Marko
Cc: Shawn Guo
Cc: Fabio Estevam
Cc: Thierry Reding
To: dri-devel@lists.
Sam Ravnborg 于2020年5月10日周日 上午4:06写道：
>
> Hi Dillon.
>
> On Fri, May 08, 2020 at 06:13:43PM +0800, dillon min wrote:
> > Hi Sam,
> >
> > Thanks for your comments, i will rework this panel driver after l3gd20
> > patch submission.
> >
> > Sam Ravnborg 于2020年5月8日周五 下午5:02写道：
> >
> > > Hi Dillon.
>
Convert busy_count to a simple int protected by spinlock.
Signed-off-by: Clément Péron
---
drivers/gpu/drm/panfrost/panfrost_devfreq.c | 43 +++--
drivers/gpu/drm/panfrost/panfrost_devfreq.h | 10 -
2 files changed, 41 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/
We will later introduce regulators managed by OPP.
Only alloc regulators when it's needed. This also help use
to release the regulators only when they are allocated.
Signed-off-by: Clément Péron
---
drivers/gpu/drm/panfrost/panfrost_device.c | 14 +-
drivers/gpu/drm/panfrost/panfros
From: Sean Cross
The Innolux N133HSE panel is a 13.3" 1920x1080 panel that contains an
integrated backlight, and connects via eDP.
It is used in the Kosagi Novena.
Signed-off-by: Sean Cross
Signed-off-by: Richard Marko
Cc: Shawn Guo
Cc: Fabio Estevam
Cc: Thierry Reding
To: dri-devel@lists.
Hi Steven,
On Thu, 7 May 2020 at 16:30, Steven Price wrote:
>
> On 02/05/2020 23:07, Clément Péron wrote:
> > Hi Steven,
> >
> > On Tue, 14 Apr 2020 at 15:10, Steven Price wrote:
> >>
> >> Hi Clément,
> >>
> >> On 13/04/2020 18:28, Clément Péron wrote:
> >>> Hi Steven,
> >>>
> >
>
> Since you'v
Jian-Hong Pan 於 2020年5月8日 週五 下午2:20寫道：
>
> Maxime Ripard 於 2020年5月8日 週五 上午1:22寫道：
> >
> > On Mon, May 04, 2020 at 02:35:08PM +0800, Jian-Hong Pan wrote:
> > > Maxime Ripard 於 2020年4月29日 週三 上午12:21寫道：
> > > >
> > > > Hi,
> > > >
> > > > On Mon, Apr 27, 2020 at 03:23:42PM +0800, Jian-Hong Pan wrot
These registers are also used on v3.3.
Signed-off-by: Álvaro Fernández Rojas
---
drivers/mtd/nand/raw/brcmnand/brcmnand.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/mtd/nand/raw/brcmnand/brcmnand.c
b/drivers/mtd/nand/raw/brcmnand/brcmnand.c
index e4e3cee
Don't include not required headers and sort them.
Signed-off-by: Clément Péron
---
drivers/gpu/drm/panfrost/panfrost_devfreq.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
in
Devfreq cooling device framework is used in Panfrost
to throttle GPU in order to regulate its temperature.
Enable this driver for ARM64 SoC.
Signed-off-by: Clément Péron
---
arch/arm64/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm6
Hello,
syzbot found the following crash on:
HEAD commit:e99332e7 gcc-10: mark more functions __init to avoid secti..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=13de23a210
kernel config: https://syzkaller.appspot.com/x/.config?x=a45301b663dae85a
das
On 5/10/2020 8:14 AM, Álvaro Fernández Rojas wrote:
> Tested on Netgear DGND3700v2 (BCM6362 with v2.2 controller).
>
> Signed-off-by: Álvaro Fernández Rojas
Can you fix a couple of things for your future submissions:
- for patch count > 1, please provide a cover letter introducing your
patche
Some SoCs have several clocks defined and the OPP core
needs to know the exact name of the clk to use.
Set the clock name to "core".
Signed-off-by: Clément Péron
---
drivers/gpu/drm/panfrost/panfrost_devfreq.c | 13 +
drivers/gpu/drm/panfrost/panfrost_devfreq.h | 1 +
2 files chan
Some OPP tables specify voltage for each frequency. Devfreq can
handle these regulators but they should be get only 1 time to avoid
issue and know who is in charge.
If OPP table is probe don't init regulator.
Signed-off-by: Clément Péron
---
drivers/gpu/drm/panfrost/panfrost_devfreq.c | 19
Signed-off-by: Clément Péron
---
arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dts | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dts
b/arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dts
index 3f7ceeb1a767..14257f7476b8 100644
-
This change adds MDP5 configuration for MSM8x36-based SoCs,
like MSM8936, 8939 and their APQ variants.
The configuration is based on MSM8916's, but adds some notable
features, like ad and pp blocks, along with some register
changes.
changes since v1:
- add an ad block
- add a second mixer @ 0x4700
在 2020/5/9 14:36, Randy Dunlap 写道:
On 5/8/20 11:30 PM, Jason Yan wrote:
Fix the following build warning:
WARNING: modpost: missing MODULE_LICENSE() in
drivers/gpu/drm/panel/panel-visionox-rm69299.o
see include/linux/module.h for more information
Signed-off-by: Jason Yan
---
drivers/gpu/dr
Add an Operating Performance Points table for the GPU to
enable Dynamic Voltage & Frequency Scaling on the H6.
The voltage range is set with minival voltage set to the target
and the maximal voltage set to 1.2V. This allow DVFS framework to
work properly on board with fixed regulator.
Signed-off-
Introduce a boolean to know if opp table has been added.
With this, we can call panfrost_devfreq_fini() in case of error
and release what has been initialised.
Signed-off-by: Clément Péron
---
drivers/gpu/drm/panfrost/panfrost_devfreq.c | 25 -
drivers/gpu/drm/panfrost/panfr
Introduce a proper panfrost_devfreq to deal with devfreq variables.
Signed-off-by: Clément Péron
---
drivers/gpu/drm/panfrost/panfrost_devfreq.c | 76 -
drivers/gpu/drm/panfrost/panfrost_devfreq.h | 20 +-
drivers/gpu/drm/panfrost/panfrost_device.h | 11 +--
drivers/gpu/
Only v3.3-v5.0 have a different CS0 layout.
v3.3- controllers use the same layout for every CS.
Signed-off-by: Álvaro Fernández Rojas
---
drivers/mtd/nand/raw/brcmnand/brcmnand.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/mtd/nand/raw/brcmnand/brcmnand.c
b/
On 5/10/20 8:47 PM, Stephen Rothwell wrote:
> Hi all,
>
> After merging the drm tree, today's linux-next build (x86_64 allmodconfig)
> produced this warning:
>
> WARNING: modpost: missing MODULE_LICENSE() in
> drivers/gpu/drm/panel/panel-visionox-rm69299.o
>
> Introduced by commit
>
> c7f66d
'exynos_dsi_parse_dt()' takes a reference to 'dsi->in_bridge_node'.
This must be released in the error handling path.
This patch is similar to commit 70505c2ef94b ("drm/exynos: dsi: Remove bridge
node reference in removal")
which fixed the issue in the remove function.
Signed-off-by: Christophe
Add a simple cooling map for the GPU.
Signed-off-by: Clément Péron
---
arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 22
1 file changed, 22 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
index 2e31632
Hi Richard.
On Sat, May 09, 2020 at 01:18:34PM +0200, s...@48.io wrote:
> From: Sean Cross
>
> The Innolux N133HSE panel is a 13.3" 1920x1080 panel that contains an
> integrated backlight, and connects via eDP.
>
> It is used in the Kosagi Novena.
Thanks for the patch.
>
> Signed-off-by: Se
On Mon, May 11, 2020 at 4:53 AM Ira Weiny wrote:
>
> On Sat, May 09, 2020 at 12:01:31AM +0200, Arnd Bergmann wrote:
> > In order to call kmap_atomic() etc, we need to include linux/highmem.h:
> >
> > drivers/gpu/drm/vmwgfx/vmwgfx_blit.c: In function 'vmw_bo_cpu_blit_line':
> > drivers/gpu/drm/vmwg
This converts the lms283gf05 backlight driver to use GPIO
descriptors and switches the single PXA Palm Z2 device
over to defining these.
Since the platform data was only used to convey GPIO
information we can delete the platform data header.
Notice that we define the proper active low semantics i
Hi folks.
I didn’t do anything unusual, I just restarted the computer after the
update, launched all the applications that I usually launch and went
to drink tea.
When I returned, I found that the monitor was on (it should have
turned off since I had set the energy-saving mode for 5 minutes in DE)
No need to micro-optmize when we're waiting in a mocked object ...
Signed-off-by: Daniel Vetter
Cc: Sumit Semwal
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
---
drivers/dma-buf/st-dma-fence.c | 41 --
1 file changed, 41 deletions(-)
diff -
It's the default.
Also so much for "we're not going to tell the graphics people how to
review their code", dma_fence is a pretty core piece of gpu driver
infrastructure. And it's very much uapi relevant, including piles of
corresponding userspace protocols and libraries for how to pass these
aroun
It's the default.
Signed-off-by: Daniel Vetter
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: David Airlie
Cc: Daniel Vetter
---
drivers/gpu/drm/drm_writeback.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_writeback.c b/drivers/gpu/drm/drm_writeb
On Sat, 9 May 2020 14:51:44 -0400
Andrey Grodzovsky wrote:
> This RFC is a more of a proof of concept then a fully working
> solution as there are a few unresolved issues we are hopping to get
> advise on from people on the mailing list. Until now extracting a
> card either by physical extraction
I honestly don't exactly understand what's going on here, but the
current code is wrong for sure: It calls dma_buf_vunmap without ever
calling dma_buf_vmap.
What I'm not sure about is whether the WARN_ON is correct:
- msm imports dma-buf using drm_prime_sg_to_page_addr_arrays. Which is
a pretty
Hi all,
I've started this a while ago, with the idea to move shmem helpers over
to dma_resv_lock. Big prep work for that was to untangle the layering
between functions called by drivers, and functions used to implement
drm_gem_object_funcs.
I didn't ever get to the locking part, but I think the c
There's no direct harm, because for the shmem helpers these are noops
on imported buffers. The trouble is in the locks these take - I want
to change dma_buf_vmap locking, and so need to make sure that we only
ever take certain locks on one side of the dma-buf interface: Either
for exporters, or for
No real functional change, since this just converts an annoying Oops
into a more harmless WARNING backtrace. It's still a driver bug.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_gem.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm
There's no direct harm, because for the shmem helpers these are noops
on imported buffers. The trouble is in the locks these take - I want
to change dma_buf_vmap locking, and so need to make sure that we only
ever take certain locks on one side of the dma-buf interface: Either
for exporters, or for
- Ditch the ->pages array
- Make it a private gem bo, which means no shmem object, which means
fireworks if anyone calls drm_gem_object_get_pages. But we've just
made sure that's all covered.
Cc: Gerd Hoffmann
Cc: Rob Herring
Cc: Noralf Trønnes
Signed-off-by: Daniel Vetter
---
drivers/gpu
- Move the shmem helper section to the drm-mm.rst file, next to the
vram helpers. Makes a lot more sense there with the now wider scope.
Also, that's where the all the other backing storage stuff resides.
It's just the framebuffer helpers that should be in the kms helper
section.
- Try to
drm_gem_shmem_get_sg_table is meant to implement
obj->funcs->get_sg_table, for prime exporting. The one we want is
drm_gem_shmem_get_pages_sgt, which also handles imported dma-buf, not
just native objects.
v2: Rebase, this stuff moved around in
commit 2f2aa13724d56829d910b2fa8e80c502d388f106
Auth
Currently this seems to work by converting the sgt into a pages array,
and then treating it like a native object. Do the right thing and
redirect mmap to the exporter.
With this nothing is calling get_pages anymore on imported dma-buf,
and we can start to remove the use of the ->pages array for th
Just a bit of light paranoia. Also sprinkle this check over
drm_gem_shmem_get_sg_table, which should only be called when
exporting, same for the pin/unpin functions, on which it relies to
work correctly.
Cc: Gerd Hoffmann
Cc: Rob Herring
Cc: Noralf Trønnes
Signed-off-by: Daniel Vetter
---
dri
On Mon, May 11, 2020 at 12:11 PM Daniel Vetter wrote:
>
> It's the default.
Thanks for catching that.
>
> Also so much for "we're not going to tell the graphics people how to
> review their code", dma_fence is a pretty core piece of gpu driver
> infrastructure. And it's very much uapi relevant, i
Quoting Daniel Vetter (2020-05-11 10:11:41)
> No need to micro-optmize when we're waiting in a mocked object ...
It's setting up the expected return values for the test.
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.free
And just FYI, the driver was written internally at 2016-17, where the
dma-buf module didn't check the .wait ops before calling it and that's
why the initialization of the default wait was there in the first
place.
I should have removed it when I upstreamed it but it missed my review.
Thanks,
Oded
On Sat, May 09, 2020 at 02:51:44PM -0400, Andrey Grodzovsky wrote:
> This RFC is a more of a proof of concept then a fully working solution as
> there are a few unresolved issues we are hopping to get advise on from people
> on the mailing list.
> Until now extracting a card either by physical ex
On Mon, May 11, 2020 at 10:41:03AM +0100, Chris Wilson wrote:
> Quoting Daniel Vetter (2020-05-11 10:11:41)
> > No need to micro-optmize when we're waiting in a mocked object ...
>
> It's setting up the expected return values for the test.
Drat, I suspect something like that but didn't spot it. K
Hi Richard/Marek.
On Sat, May 09, 2020 at 01:17:31PM +0200, s...@48.io wrote:
> From: Marek Vasut
>
> Add DT bindings for ITE IT6251 LVDS-to-eDP bridge.
Looks good, just a few comments in the following.
Sam
>
> Signed-off-by: Marek Vasut
> Signed-off-by: Richard Marko
> Cc: Daniel V
Quoting Daniel Vetter (2020-05-11 10:54:33)
> - worse, neither vk nor gl (to my knowledge) have a concept of events
> for when the gpu died. The only stuff you have is things like
> arb_robustness which says a) everything continues as if nothing
> happened b) there's a function where
Hi Richard.
On Sat, May 09, 2020 at 01:17:32PM +0200, s...@48.io wrote:
> From: Marek Vasut
>
> Add driver for the ITE IT6251 LVDS-to-eDP bridge.
I assume this is the same driver submitted here:
https://lore.kernel.org/dri-devel/f2892d7b-a60b-4e15-faa7-97ccb20e8...@codeaurora.org/
I miss a cha
On Mon, May 11, 2020 at 11:19:30AM +0100, Chris Wilson wrote:
> Quoting Daniel Vetter (2020-05-11 10:54:33)
> > - worse, neither vk nor gl (to my knowledge) have a concept of events
> > for when the gpu died. The only stuff you have is things like
> > arb_robustness which says a) everythi
Am 11.05.20 um 11:35 schrieb Daniel Vetter:
> - Move the shmem helper section to the drm-mm.rst file, next to the
> vram helpers. Makes a lot more sense there with the now wider scope.
> Also, that's where the all the other backing storage stuff resides.
> It's just the framebuffer helpers
On Mon, May 11, 2020 at 11:54:33AM +0200, Daniel Vetter wrote:
> On Sat, May 09, 2020 at 02:51:44PM -0400, Andrey Grodzovsky wrote:
> > This RFC is a more of a proof of concept then a fully working solution as
> > there are a few unresolved issues we are hopping to get advise on from
> > people o
Hi
Am 11.05.20 um 11:35 schrieb Daniel Vetter:
> There's no direct harm, because for the shmem helpers these are noops
> on imported buffers. The trouble is in the locks these take - I want
> to change dma_buf_vmap locking, and so need to make sure that we only
> ever take certain locks on one sid
On Tue, 5 May 2020 at 17:05, Emil Velikov wrote:
>
> From: Emil Velikov
>
> A few of the new panels create a local macro wrapping around
> mipi_dsi_dcs_write. At the same time, they don't really care about the
> command/payload split.
>
> mipi_dsi_dcs_write does a kmalloc/memcpy/kfree for payload
On Mon, May 11, 2020 at 01:23:38PM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 11.05.20 um 11:35 schrieb Daniel Vetter:
> > There's no direct harm, because for the shmem helpers these are noops
> > on imported buffers. The trouble is in the locks these take - I want
> > to change dma_buf_vmap lock
https://bugzilla.kernel.org/show_bug.cgi?id=207595
--- Comment #8 from Johannes Braun (jjo.br...@gmail.com) ---
Is there a way to ask the amdgpu driver how much displays are supported, e.g.
via a parameter in userspace?
--
You are receiving this mail because:
You are watching the assignee of the
On Mon, May 11, 2020 at 11:54:33AM +0200, Daniel Vetter wrote:
> - One unfortunate thing with drm_dev_unplug is that the driver core is
> very opinionated and doesn't tell you whether it's a hotunplug or a
> driver unload. In the former case trying to shut down hw just wastes
> time (and migh
This is the V4 version of a series that introduces basic writeback
support to VKMS. This patchset starts with a pre-work that aims to make
VKMS composer operations ready for getting the writeback support; it has
updates on the CRC functions and reworks a small part of the VKMS
framebuffer operation
From: Rodrigo Siqueira
In the vkms_composer.c, some of the functions related to CRC and compose
have interdependence between each other. This patch reworks some
functions inside vkms_composer to make crc and composer computation
decoupled.
This patch is preparation work for making vkms able to s
From: Rodrigo Siqueira
This patch implements the necessary functions to add writeback support
for vkms. This feature is useful for testing compositors if you don't
have hardware with writeback support.
Change in V3 (Daniel):
- If writeback is enabled, compose everything into the writeback buffer
From: Rodrigo Siqueira
The compute_crc() function is responsible for calculating the
framebuffer CRC value; due to the XRGB format, this function has to
ignore the alpha channel during the CRC computation. Therefore,
compute_crc() set zero to the alpha channel directly in the input
framebuffer, w
Hi
Am 11.05.20 um 13:37 schrieb Daniel Vetter:
> On Mon, May 11, 2020 at 01:23:38PM +0200, Thomas Zimmermann wrote:
>> Hi
>>
>> Am 11.05.20 um 11:35 schrieb Daniel Vetter:
>>> There's no direct harm, because for the shmem helpers these are noops
>>> on imported buffers. The trouble is in the locks
On Mon, May 11, 2020 at 1:43 PM Lukas Wunner wrote:
>
> On Mon, May 11, 2020 at 11:54:33AM +0200, Daniel Vetter wrote:
> > - One unfortunate thing with drm_dev_unplug is that the driver core is
> > very opinionated and doesn't tell you whether it's a hotunplug or a
> > driver unload. In the fo
Am 11.05.20 um 11:26 schrieb Pekka Paalanen:
On Sat, 9 May 2020 14:51:44 -0400
Andrey Grodzovsky wrote:
This RFC is a more of a proof of concept then a fully working
solution as there are a few unresolved issues we are hopping to get
advise on from people on the mailing list. Until now extract
Am 11.05.20 um 13:19 schrieb Daniel Vetter:
On Mon, May 11, 2020 at 11:54:33AM +0200, Daniel Vetter wrote:
On Sat, May 09, 2020 at 02:51:44PM -0400, Andrey Grodzovsky wrote:
This RFC is a more of a proof of concept then a fully working solution as there
are a few unresolved issues we are hoppi
The GC860 has one GPU device which has a 2d and 3d core. In this case
we want to expose perfmon information for both cores.
The driver has one array which contains all possible perfmon domains
with some meta data - doms_meta. Here we can see that for the GC860
two elements of that array are releva
On Sat, May 09, 2020 at 12:13:02PM +0200, Daniel Vetter wrote:
> On Fri, May 8, 2020 at 7:09 PM Rodrigo Vivi wrote:
> >
> > On Fri, Apr 17, 2020 at 09:28:34PM +0300, Ville Syrjälä wrote:
> > > On Fri, Apr 17, 2020 at 08:10:26PM +0200, Daniel Vetter wrote:
> > > > On Fri, Apr 17, 2020 at 5:43 PM Vi
The GC860 has one GPU device which has a 2d and 3d core. In this case
we want to expose perfmon information for both cores.
The driver has one array which contains all possible perfmon domains
with some meta data - doms_meta. Here we can see that for the GC860
two elements of that array are releva
On Mon, May 11, 2020 at 2:37 PM Ville Syrjälä
wrote:
>
> On Sat, May 09, 2020 at 12:13:02PM +0200, Daniel Vetter wrote:
> > On Fri, May 8, 2020 at 7:09 PM Rodrigo Vivi wrote:
> > >
> > > On Fri, Apr 17, 2020 at 09:28:34PM +0300, Ville Syrjälä wrote:
> > > > On Fri, Apr 17, 2020 at 08:10:26PM +020
Hi
Am 30.04.20 um 10:23 schrieb Thomas Zimmermann:
> Hi
>
> Am 29.04.20 um 20:20 schrieb Sam Ravnborg:
>> Hi Thomas,
>>
>> On Wed, Apr 29, 2020 at 04:32:26PM +0200, Thomas Zimmermann wrote:
>>> All register names and fields are now named according to the
>>> MGA programming manuals. The function
On Mon, May 11, 2020 at 2:34 PM Christian König
wrote:
>
> Am 11.05.20 um 13:19 schrieb Daniel Vetter:
> > On Mon, May 11, 2020 at 11:54:33AM +0200, Daniel Vetter wrote:
> >> On Sat, May 09, 2020 at 02:51:44PM -0400, Andrey Grodzovsky wrote:
> >>> This RFC is a more of a proof of concept then a fu
https://bugzilla.kernel.org/show_bug.cgi?id=207595
--- Comment #9 from Alex Deucher (alexdeuc...@gmail.com) ---
You can ask any KMS driver via the drmModeGetResources() function call in
libdrm.
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=207595
--- Comment #10 from Alex Deucher (alexdeuc...@gmail.com) ---
If using X, you can also use `xrandr --verbose` to see number of crtcs.
--
You are receiving this mail because:
You are watching the assignee of the bug.
_
On Mon, May 11, 2020 at 02:41:13PM +0200, Daniel Vetter wrote:
> On Mon, May 11, 2020 at 2:37 PM Ville Syrjälä
> wrote:
> >
> > On Sat, May 09, 2020 at 12:13:02PM +0200, Daniel Vetter wrote:
> > > On Fri, May 8, 2020 at 7:09 PM Rodrigo Vivi
> > > wrote:
> > > >
> > > > On Fri, Apr 17, 2020 at 09
On Mon, May 11, 2020 at 09:53:18AM +0200, Linus Walleij wrote:
> This converts the lms283gf05 backlight driver to use GPIO
> descriptors and switches the single PXA Palm Z2 device
> over to defining these.
>
> Since the platform data was only used to convey GPIO
> information we can delete the pla
On Mon, May 11, 2020 at 02:21:57PM +0200, Daniel Vetter wrote:
> On Mon, May 11, 2020 at 1:43 PM Lukas Wunner wrote:
> > On Mon, May 11, 2020 at 11:54:33AM +0200, Daniel Vetter wrote:
> > > - One unfortunate thing with drm_dev_unplug is that the driver core is
> > > very opinionated and doesn't
On Mon, May 11, 2020 at 4:08 PM Lukas Wunner wrote:
>
> On Mon, May 11, 2020 at 02:21:57PM +0200, Daniel Vetter wrote:
> > On Mon, May 11, 2020 at 1:43 PM Lukas Wunner wrote:
> > > On Mon, May 11, 2020 at 11:54:33AM +0200, Daniel Vetter wrote:
> > > > - One unfortunate thing with drm_dev_unplug i
Hello,
On Fri, May 08, 2020 at 04:46:51PM -0400, Lyude Paul wrote:
> +bool kthread_queue_flush_work(struct kthread_work *work,
> + struct kthread_flush_work *fwork);
> +void __kthread_flush_work_fn(struct kthread_work *work);
As an exposed interface, this doesn't seem gr
Hi Rob,
What's your opinion on this?
Some context: It's about bindings that define signed integer properties
with range checks that go below and above zero. The schema checker fails
because, apparently, it interprets every cell value as an uint32, which
makes the range check fail for negative num
https://bugzilla.kernel.org/show_bug.cgi?id=203033
--- Comment #2 from Mathieu Malaterre (mathieu.malate...@gmail.com) ---
Same here:
May 11 16:54:31 vostrodell kernel: [ 605.330992] INFO: task kworker/u8:3:162
blocked for more than 120 seconds.
May 11 16:54:31 vostrodell kernel: [ 605.330997]
https://bugzilla.kernel.org/show_bug.cgi?id=203033
--- Comment #3 from Mathieu Malaterre (mathieu.malate...@gmail.com) ---
Forgot to include hardware information:
$ lspci -s 01:00.0
01:00.0 VGA compatible controller: NVIDIA Corporation GT215 [GeForce GT 240]
(rev a2)
--
You are receiving this m
On Mon, May 11, 2020 at 4:49 PM Tejun Heo wrote:
>
> Hello,
>
> On Fri, May 08, 2020 at 04:46:51PM -0400, Lyude Paul wrote:
> > +bool kthread_queue_flush_work(struct kthread_work *work,
> > + struct kthread_flush_work *fwork);
> > +void __kthread_flush_work_fn(struct kthr
On Fri, May 08, 2020 at 04:46:52PM -0400, Lyude Paul wrote:
> Add some simple wrappers around incrementing/decrementing
> kthread_work.cancelling under lock, along with checking whether queuing
> is currently allowed on a given kthread_work, which we'll use want to
> implement work cancelling with
1 - 100 of 179 matches
Mail list logo
