Hi Dave, Daniel,
Fixes for 5.10.
The following changes since commit 3650b228f83adda7e5ee532e2b90429c03f7b9ec:
Linux 5.10-rc1 (2020-10-25 15:14:11 -0700)
are available in the Git repository at:
git://people.freedesktop.org/~agd5f/linux tags/amd-drm-fixes-5.10-2020-10-29
for you to fetch ch
On 28. 10. 20, 17:06, Daniel Vetter wrote:
So ever since syzbot discovered fbcon, we have solid proof that it's
full of bugs. And often the solution is to just delete code and remove
features, e.g. 50145474f6ef ("fbcon: remove soft scrollback code").
...
--- a/drivers/video/fbdev/core/fbcon.c
Hi all,
Today's linux-next merge of the drm-misc tree got a conflict in:
drivers/gpu/drm/drm_gem.c
between commit:
f49a51bfdc8e ("drm/shme-helpers: Fix dma_buf_mmap forwarding bug")
from the drm-misc-fixes tree and commit:
d693def4fd1c ("drm: Remove obsolete GEM and PRIME callbacks from
On Wed, Oct 28, 2020 at 07:09:54PM +0530, Akhil P Oommen wrote:
> Add cooling device support to gpu. A cooling device is bound to a
> thermal zone to allow thermal mitigation.
>
> Signed-off-by: Akhil P Oommen
> ---
> Documentation/devicetree/bindings/display/msm/gpu.txt | 7 +++
> 1 file ch
On Tue, Oct 27, 2020 at 06:36:02PM -0700, Hyun Kwon wrote:
> Hi Peter,
>
> Thanks for the patch.
>
> On Fri, Oct 23, 2020 at 02:46:02AM -0700, Peter Ujfalusi wrote:
> > There is no need to use the of_dma_request_slave_channel() directly as
> > dma_request_chan() is going to try to get the channel
Hi Akhil,
On Wed, Oct 28, 2020 at 07:09:53PM +0530, Akhil P Oommen wrote:
> Add cooling-cells property and the cooling maps for the gpu tzones
> to support GPU cooling.
>
> Signed-off-by: Akhil P Oommen
> ---
> arch/arm64/boot/dts/qcom/sc7180.dtsi | 30 +++---
> 1 file c
This adds a heap that allocates non-contiguous buffers that are
marked as writecombined, so they are not cached by the CPU.
This is useful, as most graphics buffers are usually not touched
by the CPU or only written into once by the CPU. So when mapping
the buffer over and over between devices, we
Hey All,
So just wanted to resend my last revision of my patch series
of performance optimizations to the dma-buf system heap.
This series reworks the system heap to use sgtables, and then
consolidates the pagelist method from the heap-helpers into the
CMA heap. After which the heap-helpers logi
While the system heap can return non-contiguous pages,
try to allocate larger order pages if possible.
This will allow slight performance gains and make implementing
page pooling easier.
Cc: Sumit Semwal
Cc: Liam Mark
Cc: Laura Abbott
Cc: Brian Starkey
Cc: Hridya Valsaraju
Cc: Suren Baghdasa
In preparation for some patches to optmize the system
heap code, rework the dmabuf exporter to utilize sgtables rather
then pageslists for tracking the associated pages.
This will allow for large order page allocations, as well as
more efficient page pooling.
In doing so, the system heap stops us
This patch is basically a port of Ørjan Eide's similar patch for ION
https://lore.kernel.org/lkml/20200414134629.54567-1-orjan.e...@arm.com/
Only sync the sg-list of dma-buf heap attachment when the attachment
is actually mapped on the device.
dma-bufs may be synced at any time. It can be reache
Since the heap-helpers logic ended up not being as generic as
hoped, move the heap-helpers dma_buf_ops implementations into
the cma_heap directly.
This will allow us to remove the heap_helpers code in a following
patch.
Cc: Sumit Semwal
Cc: Liam Mark
Cc: Laura Abbott
Cc: Brian Starkey
Cc: Hri
The heap-helpers code was not as generic as initially hoped
and it is now not being used, so remove it from the tree.
Cc: Sumit Semwal
Cc: Liam Mark
Cc: Laura Abbott
Cc: Brian Starkey
Cc: Hridya Valsaraju
Cc: Suren Baghdasaryan
Cc: Sandeep Patil
Cc: Daniel Mentz
Cc: Chris Goldsworthy
Cc:
Keep track of the heap device struct.
This will be useful for special DMA allocations
and actions.
Cc: Sumit Semwal
Cc: Liam Mark
Cc: Laura Abbott
Cc: Brian Starkey
Cc: Hridya Valsaraju
Cc: Suren Baghdasaryan
Cc: Sandeep Patil
Cc: Daniel Mentz
Cc: Chris Goldsworthy
Cc: Ørjan Eide
Cc: Ro
Add support for the BOE NV110WTM-N61 panel. The EDID lists two modes
(one for 60 Hz refresh rate and one for 40 Hz), so we'll list both of
them here.
Note that the panel datasheet requires 80 ms between HPD asserting and
the backlight power being turned on. We'll use the new timing
constraints s
Add yet another eDP panel.
Signed-off-by: Douglas Anderson
---
(no changes since v1)
.../devicetree/bindings/display/panel/panel-simple.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
b/Documentation/devicetr
The simple panel code currently allows panels to define fixed delays
at certain stages of initialization. These work OK, but they don't
really map all that clearly to the requirements presented in many
panel datasheets. Instead of defining a fixed delay, those datasheets
provide a timing diagram
On Wed, Oct 28, 2020 at 4:41 PM Daniel Vetter wrote:
>
> On Wed, Oct 28, 2020 at 3:36 PM Patrik Jakobsson
> wrote:
> >
> > GTT roll support was used to accelerate fb panning on some machines.
> > Unfortunately this never worked properly with multiple monitors and
> > caused issues on others where
Quoting Stephen Rothwell (2020-10-28 21:28:23)
> Hi all,
>
> Commit
>
> d13208a88f41 ("lockdep: Fix nr_unused_locks")
>
> is missing a Signed-off-by from its author.
>
> Also, the author's email name is missing the leading 'P'.
And it shouldn't be in the drm-intel-fixes tree.
-Chris
I sent a patch to the mailing list and wanted to have some review on
that from at least Ben, but no idea if Ben already picked it and if
it's good enough for sending it to stable yet.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lis
Hi all,
Commit
d13208a88f41 ("lockdep: Fix nr_unused_locks")
is missing a Signed-off-by from its author.
Also, the author's email name is missing the leading 'P'.
--
Cheers,
Stephen Rothwell
pgp1YjPCOl5iy.pgp
Description: OpenPGP digital signature
_
On Wed, Oct 28, 2020 at 7:50 PM Sam Ravnborg wrote:
>
> Hi Daniel.
>
> On Wed, Oct 28, 2020 at 05:06:00PM +0100, Daniel Vetter wrote:
> > So ever since syzbot discovered fbcon, we have solid proof that it's
> > full of bugs. And often the solution is to just delete code and remove
> > features, e.
On Wed, Oct 28, 2020 at 8:02 PM Thomas Zimmermann wrote:
>
> Hi
>
> Am 28.10.20 um 17:06 schrieb Daniel Vetter:
> > So ever since syzbot discovered fbcon, we have solid proof that it's
> > full of bugs. And often the solution is to just delete code and remove
> > features, e.g. 50145474f6ef ("fbc
On Wed, Oct 28, 2020 at 04:15:26PM -0300, Jason Gunthorpe wrote:
> Since commit 9a40401cfa13 ("lib/scatterlist: Do not limit max_segment to
> PAGE_ALIGNED values") the max_segment input to sg_alloc_table_from_pages()
> does not have to be any special value. The new algorithm will always
> create so
The function etnaviv_gem_prime_vunmap() is empty. Remove it before
changing the interface to use struct drm_buf_map.
Signed-off-by: Thomas Zimmermann
Acked-by: Christian König
Tested-by: Sam Ravnborg
---
drivers/gpu/drm/etnaviv/etnaviv_drv.h | 1 -
drivers/gpu/drm/etnaviv/etnaviv_gem.c
This patch replaces the vmap/vunmap's use of raw pointers in GEM object
functions with instances of struct dma_buf_map. GEM backends are
converted as well. For most of them, this simply changes the returned type.
TTM-based drivers now return information about the location of the memory,
either sys
GEM's vmap and vunmap interfaces now wrap memory pointers in struct
dma_buf_map.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Daniel Vetter
Tested-by: Sam Ravnborg
---
drivers/gpu/drm/drm_client.c | 18 +++---
drivers/gpu/drm/drm_gem.c | 26 +-
drive
The parameters map and is_iomem are always of the same value. Removed them
to prepares the function for conversion to struct dma_buf_map.
v4:
* don't check for !kmap->virtual; will always be false
Signed-off-by: Thomas Zimmermann
Reviewed-by: Daniel Vetter
Reviewed-by: Christian König
The new functions ttm_bo_{vmap,vunmap}() map and unmap a TTM BO in kernel
address space. The mapping's address is returned as struct dma_buf_map.
Each function is a simplified version of TTM's existing kmap code. Both
functions respect the memory's location ani/or writecombine flags.
On top TTM's
To do framebuffer updates, one needs memcpy from system memory and a
pointer-increment function. Add both interfaces with documentation.
v5:
* include to build on sparc64 (Sam)
Signed-off-by: Thomas Zimmermann
Reviewed-by: Sam Ravnborg
Tested-by: Sam Ravnborg
---
include/linux/dma-bu
Kernel DRM clients now store their framebuffer address in an instance
of struct dma_buf_map. Depending on the buffer's location, the address
refers to system or I/O memory.
Callers of drm_client_buffer_vmap() receive a copy of the value in
the call's supplied arguments. It can be accessed and modi
The function drm_gem_cma_prime_vunmap() is empty. Remove it before
changing the interface to use struct drm_buf_map.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Christian König
Tested-by: Sam Ravnborg
---
drivers/gpu/drm/drm_gem_cma_helper.c | 17 -
drivers/gpu/drm/vc4/vc4_bo
DRM's fbdev console uses regular load and store operations to update
framebuffer memory. The bochs driver on sparc64 requires the use of
I/O-specific load and store operations. We have a workaround, but need
a long-term solution to the problem.
This patchset changes GEM's vmap/vunmap interfaces to
At least sparc64 requires I/O-specific access to framebuffers. This
patch updates the fbdev console accordingly.
For drivers with direct access to the framebuffer memory, the callback
functions in struct fb_ops test for the type of memory and call the rsp
fb_sys_ of fb_cfb_ functions. Read and wri
The functions exynos_drm_gem_prime_{vmap,vunmap}() are empty. Remove
them before changing the interface to use struct drm_buf_map. As a side
effect of removing drm_gem_prime_vmap(), the error code changes from
ENOMEM to EOPNOTSUPP.
Signed-off-by: Thomas Zimmermann
Acked-by: Christian König
Teste
On Tue, Oct 27, 2020 at 11:30:31PM +0300, Dmitry Osipenko wrote:
> 27.10.2020 13:27, Krzysztof Kozlowski пишет:
> > On Mon, Oct 26, 2020 at 01:17:24AM +0300, Dmitry Osipenko wrote:
> >> Use devm_platform_ioremap_resource() helper which makes code a bit
> >> cleaner.
> >
> > Such cleanups (and few
On Tue, Oct 27, 2020 at 11:16:29PM +0300, Dmitry Osipenko wrote:
> 27.10.2020 22:48, Krzysztof Kozlowski пишет:
> > On Tue, Oct 27, 2020 at 10:19:28PM +0300, Dmitry Osipenko wrote:
> >> 27.10.2020 13:25, Krzysztof Kozlowski пишет:
> >>> On Mon, Oct 26, 2020 at 01:16:56AM +0300, Dmitry Osipenko wrot
Am 27.10.20 um 17:31 schrieb Peilin Ye:
> Remove 6 unused extern variables to reduce confusion. It is worth
> mentioning that lib/fonts/font_8x8.c and lib/fonts/font_8x16.c also
> declare `fontdata_8x8` and `fontdata_8x16` respectively, and this file
> has nothing to do with them.
>
> Signed-off
Hi Patrik
Am 28.10.20 um 15:36 schrieb Patrik Jakobsson:
> GTT roll support was used to accelerate fb panning on some machines.
> Unfortunately this never worked properly with multiple monitors and
> caused issues on others where the framebuffer wouldn't fit in stolen
> memory. Let's remove it!
>
Hi
Am 28.10.20 um 17:06 schrieb Daniel Vetter:
> So ever since syzbot discovered fbcon, we have solid proof that it's
> full of bugs. And often the solution is to just delete code and remove
> features, e.g. 50145474f6ef ("fbcon: remove soft scrollback code").
>
> Now the problem is that most mo
Hi Daniel.
On Wed, Oct 28, 2020 at 05:06:00PM +0100, Daniel Vetter wrote:
> So ever since syzbot discovered fbcon, we have solid proof that it's
> full of bugs. And often the solution is to just delete code and remove
> features, e.g. 50145474f6ef ("fbcon: remove soft scrollback code").
>
> Now
On Wed, Oct 28, 2020 at 06:56:47AM -0400, Peilin Ye wrote:
> `width` and `height` are defined as unsigned in our UAPI font descriptor
> `struct console_font`. Make them unsigned in our kernel font descriptor
> `struct font_desc`, too.
>
> Also, change the corresponding printk() format identifiers
On 14:31-20201021, Tomi Valkeinen wrote:
> On 16/10/2020 13:39, Nikhil Devshatwar wrote:
> > When the next bridge does not specify any bus flags, use the
> > bridge->timings->input_bus_flags as fallback when propagating
> > bus flags from next bridge to current bridge.
> >
> > Signed-off-by: Nikhi
On 15:11-20201019, Tomi Valkeinen wrote:
> Hi Nikhil,
>
> On 16/10/2020 13:39, Nikhil Devshatwar wrote:
> > This series moves the tidss to using new connectoe model, where the
> > SoC driver (tidss) creates the connector and all the bridges are
> > attached with the flag DRM_BRIDGE_ATTACH_NO_CON
> -Original Message-
> From: Jason Gunthorpe
> Sent: Wednesday, October 28, 2020 9:36 AM
> To: Xiong, Jianxin
> Cc: linux-r...@vger.kernel.org; dri-devel@lists.freedesktop.org; Doug Ledford
> ; Leon Romanovsky
> ; Sumit Semwal ; Christian Koenig
> ; Vetter, Daniel
>
> Subject: Re: [PAT
On Wed, Oct 28, 2020 at 05:06:00PM +0100, Daniel Vetter wrote:
> So ever since syzbot discovered fbcon, we have solid proof that it's
> full of bugs. And often the solution is to just delete code and remove
> features, e.g. 50145474f6ef ("fbcon: remove soft scrollback code").
>
> Now the problem
On Wed, Oct 28, 2020 at 5:45 PM Sam Ravnborg wrote:
>
> Hi Daniel et al.
>
> On Wed, Oct 28, 2020 at 05:06:00PM +0100, Daniel Vetter wrote:
> > So ever since syzbot discovered fbcon, we have solid proof that it's
> > full of bugs. And often the solution is to just delete code and remove
> > featur
Hi Daniel et al.
On Wed, Oct 28, 2020 at 05:06:00PM +0100, Daniel Vetter wrote:
> So ever since syzbot discovered fbcon, we have solid proof that it's
> full of bugs. And often the solution is to just delete code and remove
> features, e.g. 50145474f6ef ("fbcon: remove soft scrollback code").
>
So ever since syzbot discovered fbcon, we have solid proof that it's
full of bugs. And often the solution is to just delete code and remove
features, e.g. 50145474f6ef ("fbcon: remove soft scrollback code").
Now the problem is that most modern-ish drivers really only treat
fbcon as an dumb kernel
For user-provided fonts, the framebuffer layer is using a
negative-indexing macro, FNTCHARCNT(), to keep track of their number of
characters. For built-in fonts, it is using hard-coded values (256). This
results in something like the following:
map.length = (ops->p->userfont) ?
On Wed, Oct 28, 2020 at 3:36 PM Patrik Jakobsson
wrote:
>
> GTT roll support was used to accelerate fb panning on some machines.
> Unfortunately this never worked properly with multiple monitors and
> caused issues on others where the framebuffer wouldn't fit in stolen
> memory. Let's remove it!
A
On Wed, Oct 28, 2020 at 10:23:03AM -0500, Rob Herring wrote:
> On Tue, Oct 27, 2020 at 08:30:39PM +0100, Krzysztof Kozlowski wrote:
> > On Tue, Oct 27, 2020 at 10:17:19PM +0300, Dmitry Osipenko wrote:
> > > 27.10.2020 11:54, Krzysztof Kozlowski пишет:
> > > > On Mon, Oct 26, 2020 at 01:16:47AM +030
On Mon, 26 Oct 2020 01:17:02 +0300, Dmitry Osipenko wrote:
> Each memory client have a unique hardware ID, this patch adds these IDs.
>
> Signed-off-by: Dmitry Osipenko
> ---
> include/dt-bindings/memory/tegra124-mc.h | 68
> 1 file changed, 68 insertions(+)
>
Reviewed
On Mon, 26 Oct 2020 01:16:58 +0300, Dmitry Osipenko wrote:
> Document EMC DFS OPP table and interconnect paths that will be used
> for scaling of system's memory bandwidth based on memory utilization
> statistics. Previously ACTMON was supposed to drive EMC clock rate
> directly, but now it should
On Mon, 26 Oct 2020 01:16:57 +0300, Dmitry Osipenko wrote:
> Document new OPP table and voltage regulator properties which are needed
> for supporting dynamic voltage-frequency scaling of the memory controller.
> Some boards may have a fixed core voltage regulator, hence it's optional
> because fre
On Mon, 26 Oct 2020 01:16:54 +0300, Dmitry Osipenko wrote:
> Document new OPP table and voltage regulator properties which are needed
> for supporting dynamic voltage-frequency scaling of the memory controller.
> Some boards may have a fixed core voltage regulator, hence it's optional
> because fre
On Mon, Oct 26, 2020 at 01:16:51AM +0300, Dmitry Osipenko wrote:
> External Memory Controller can gather various hardware statistics that
> are intended to be used for debugging purposes and for dynamic frequency
> scaling of memory bus.
>
> Document the new mfd-simple compatible and EMC statistic
On Tue, Oct 27, 2020 at 11:18:34PM +0300, Dmitry Osipenko wrote:
> 27.10.2020 22:44, Krzysztof Kozlowski пишет:
> > On Tue, Oct 27, 2020 at 10:22:19PM +0300, Dmitry Osipenko wrote:
> >> 27.10.2020 12:02, Krzysztof Kozlowski пишет:
> @@ -31,17 +32,34 @@ Example:
> ...
> >>
On Mon, 26 Oct 2020 01:16:47 +0300, Dmitry Osipenko wrote:
> Tegra20 External Memory Controller talks to DRAM chips and it needs to be
> reprogrammed when memory frequency changes. Tegra Memory Controller sits
> behind EMC and these controllers are tightly coupled. This patch adds the
> new phandle
On Tue, Oct 27, 2020 at 08:30:39PM +0100, Krzysztof Kozlowski wrote:
> On Tue, Oct 27, 2020 at 10:17:19PM +0300, Dmitry Osipenko wrote:
> > 27.10.2020 11:54, Krzysztof Kozlowski пишет:
> > > On Mon, Oct 26, 2020 at 01:16:47AM +0300, Dmitry Osipenko wrote:
> > >> Tegra20 External Memory Controller t
On Mon, 26 Oct 2020 01:16:46 +0300, Dmitry Osipenko wrote:
> There is superfluous zero in the registers base address and registers
> size should be twice bigger.
>
> Signed-off-by: Dmitry Osipenko
> ---
> .../bindings/memory-controllers/nvidia,tegra20-emc.txt | 2 +-
> 1 file changed, 1
On Wed, Oct 21, 2020 at 10:04:45PM -0700, Alexandru Stan wrote:
> The previous behavior was a little unexpected, its properties/problems:
> 1. It was designed to generate strictly increasing values (no repeats)
> 2. It had quantization errors when calculating step size. Resulting in
> unexpected ju
On Tue, Oct 27, 2020 at 5:50 PM Arnd Bergmann wrote:
>
> On Tue, Oct 27, 2020 at 10:54 AM Patrik Jakobsson
> wrote:
> > On Tue, Oct 27, 2020 at 10:33 AM Daniel Vetter wrote:
> > > On Mon, Oct 26, 2020 at 08:41:04PM +0100, Arnd Bergmann wrote:
> > > > From: Arnd Bergmann
> > > >
> > > > gcc -Wex
The dev_pm_opp_of_add_table() api initializes the icc nodes for gpu
indirectly. So we can avoid using of_icc_get() api in the common
probe path. To improve this, move of_icc_get() to target specific code
where it is required.
This patch helps to fix duplicate gpu node listed in the interconnect
su
GTT roll support was used to accelerate fb panning on some machines.
Unfortunately this never worked properly with multiple monitors and
caused issues on others where the framebuffer wouldn't fit in stolen
memory. Let's remove it!
Signed-off-by: Patrik Jakobsson
---
drivers/gpu/drm/gma500/frameb
Implement the shutdown callback for adreno gpu platform device
to safely shutdown it before a system reboot. This helps to avoid
futher transactions from gpu after the smmu is moved to bypass mode.
Signed-off-by: Akhil P Oommen
---
drivers/gpu/drm/msm/adreno/adreno_device.c | 6 ++
1 file ch
From: Mauro Carvalho Chehab
Several entries at the stable ABI files won't parse if we pass
them directly to the ReST output.
Adjust them, in order to allow adding their contents as-is at
the stable ABI book.
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Mauro Carvalho Chehab
---
Docume
s/convertion/conversion in subject line
On Wed, 28 Oct 2020 at 12:37, Maxime Ripard wrote:
>
> Most of the helpers to retrieve vc4 structures from the DRM base structures
> rely on the fact that the first member of the vc4 structure is the DRM one
> and just cast the pointers between them.
>
> Ho
Hi Maxime
On Fri, 25 Sep 2020 at 14:00, Maxime Ripard wrote:
>
> The FIFO between the pixelvalve and the HDMI controller runs at 2 pixels
> per clock cycle, and cannot deal with odd timings.
>
> Let's reject any mode with such timings.
>
> Signed-off-by: Maxime Ripard
It's unsupported due to th
Add cooling-cells property and the cooling maps for the gpu tzones
to support GPU cooling.
Signed-off-by: Akhil P Oommen
---
arch/arm64/boot/dts/qcom/sc7180.dtsi | 30 +++---
1 file changed, 23 insertions(+), 7 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sc7180.dt
Add cooling device support to gpu. A cooling device is bound to a
thermal zone to allow thermal mitigation.
Signed-off-by: Akhil P Oommen
---
Documentation/devicetree/bindings/display/msm/gpu.txt | 7 +++
1 file changed, 7 insertions(+)
diff --git a/Documentation/devicetree/bindings/display
Register GPU as a devfreq cooling device so that it can be passively
cooled by the thermal framework.
Signed-off-by: Akhil P Oommen
---
Changes in v3:
1. Minor fix in binding documentation (RobH)
Changes in v2:
1. Update the dt bindings documentation
drivers/gpu/drm/msm/msm_gpu.c
Hi Maxime
On Wed, 8 Jul 2020 at 15:46, Maxime Ripard wrote:
>
> Since the components for a given device in ASoC are identified by their
> name, it makes sense to add one even though it's not strictly necessary.
>
> Signed-off-by: Maxime Ripard
Reviewed-by: Dave Stevenson
> ---
> drivers/gpu/
On Fri, Oct 23, 2020 at 02:21:21PM +0200, Daniel Vetter wrote:
> Again needs to be put right after the call to
> drm_atomic_helper_commit_hw_done(), since that's the last thing which
> can hold up a subsequent atomic commit.
>
> No surprises here.
>
> Signed-off-by: Daniel Vetter
> Cc: "James (Q
From: Colin Ian King
A recent change added two uint16_t elements to PPTable_t and reduced the
uint32_t array down to 8 elements. This results in the dev_info printing
of pptable->SkuReserved[8] accessing a value that is out-of-range on
array SkuReserved. The array has been shrunk by 1 element, s
Am 28.10.20 um 12:31 schrieb Daniel Vetter:
Not technically a problem for ttm, but very likely a driver bug and
pretty big time confusing for reviewing code.
So warn about it, both at cleanup time (so we catch these for sure)
and at pin/unpin time (so we know who's the culprit).
Signed-off-by:
Ok, I have initiated the steps to upgrade the CI machine's silicon & BIOS.
Thanks
Hariom Pandey
> -Original Message-
> From: Vivi, Rodrigo
> Sent: Wednesday, October 28, 2020 5:24 PM
> To: Pandey, Hariom ; Szwichtenberg, Radoslaw
>
> Cc: Chris Wilson ; Ausmus, James
> ; Nikula, Jani ; i
> On Oct 27, 2020, at 11:49 PM, Pandey, Hariom wrote:
>
> Hi Chris,
>
> Awaiting your kind response here…
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9208/fi-ehl-1/igt@i915_selftest@live@gt_pm.html
"Did not enter RC6!"
Chris already told that we need to get RC6 working on CI.
If we need
On Wed, Oct 28, 2020 at 07:31:20PM +0800, Daniel Vetter wrote:
> Not technically a problem for ttm, but very likely a driver bug and
> pretty big time confusing for reviewing code.
>
> So warn about it, both at cleanup time (so we catch these for sure)
> and at pin/unpin time (so we know who's the
[AMD Public Use]
-Original Message-
From: Chauhan, Madhav
Sent: Tuesday, October 27, 2020 12:57 AM
To: Koenig, Christian ;
dri-devel@lists.freedesktop.org
Cc: Huang, Ray
Subject: RE: [PATCH 01/13] drm/ttm: nuke ttm_tt_set_(un)populated again
[AMD Public Use]
-Original Message-
Not technically a problem for ttm, but very likely a driver bug and
pretty big time confusing for reviewing code.
So warn about it, both at cleanup time (so we catch these for sure)
and at pin/unpin time (so we know who's the culprit).
Signed-off-by: Daniel Vetter
Cc: Christian Koenig
Cc: Huang
On Tue, Oct 27, 2020 at 03:54:31PM +0100, Maxime Ripard wrote:
> Hi,
>
> On Tue, Oct 27, 2020 at 01:14:42PM +0900, Hoegeun Kwon wrote:
> > There is a problem that if vc4_drm bind fails, a memory leak occurs on
> > the drm_property_create side. Add error handding for drm_mode_config.
> >
> > Signe
`width` and `height` are defined as unsigned in our UAPI font descriptor
`struct console_font`. Make them unsigned in our kernel font descriptor
`struct font_desc`, too.
Also, change the corresponding printk() format identifiers from `%d` to
`%u`, in sti_select_fbfont().
Signed-off-by: Peilin Ye
On 10/28/20 13:30, Michel Dänzer wrote:
> On 2020-10-28 11:09 a.m., Paul Gofman wrote:
>> On 10/28/20 11:18, Pekka Paalanen wrote:
>>>
+static unsigned log2_int(unsigned x)
+{
+ unsigned l;
+
+ if (x < 2) {
+ return 0;
+ }
+ for (l = 2; ;
On Wed, Oct 28, 2020 at 09:18:44AM +0100, Daniel Vetter wrote:
> On Wed, Oct 28, 2020 at 01:43:07AM -0400, Peilin Ye wrote:
> > On Tue, Oct 27, 2020 at 07:50:58PM +0100, Daniel Vetter wrote:
> > > On Tue, Oct 27, 2020 at 12:33:05PM -0400, Peilin Ye wrote:
> > > > It is improper to define `width` an
On 2020-10-28 11:09 a.m., Paul Gofman wrote:
On 10/28/20 11:18, Pekka Paalanen wrote:
+static unsigned log2_int(unsigned x)
+{
+unsigned l;
+
+if (x < 2) {
+return 0;
+}
+for (l = 2; ; l++) {
+if ((unsigned)(1 << l) > x) {
Hi,
wouldn't this loop fail to end
On Wed, Oct 28, 2020 at 10:53 AM Christian König
wrote:
>
> Am 28.10.20 um 10:16 schrieb Daniel Vetter:
> > On Wed, Oct 21, 2020 at 11:58:45AM +0200, Christian König wrote:
> >> Am 21.10.20 um 06:40 schrieb Dave Airlie:
> >>> From: Dave Airlie
> >>>
> >>> The move notify callback is only used in
On Wed, Oct 28, 2020 at 09:44:15AM +0100, Boris Brezillon wrote:
> On Tue, 27 Oct 2020 22:49:22 +0100
> Daniel Vetter wrote:
>
> > When we forward an mmap to the dma_buf exporter, they get to own
> > everything. Unfortunately drm_gem_mmap_obj() overwrote
> > vma->vm_private_data after the driver
On 10/28/20 11:18, Pekka Paalanen wrote:
>
>>
>> +static unsigned log2_int(unsigned x)
>> +{
>> +unsigned l;
>> +
>> +if (x < 2) {
>> +return 0;
>> +}
>> +for (l = 2; ; l++) {
>> +if ((unsigned)(1 << l) > x) {
> Hi,
>
> wouldn't this loop fail to end when x >= 0x80
Signed-off-by: Paul Gofman
---
radeon/radeon_surface.c | 20 +---
util_math.h | 14 ++
xf86drm.c | 16
3 files changed, 15 insertions(+), 35 deletions(-)
diff --git a/radeon/radeon_surface.c b/radeon/radeon_surface.c
index ea
Signed-off-by: Paul Gofman
---
util_math.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/util_math.h b/util_math.h
index e2fa95f5..f6bbe192 100644
--- a/util_math.h
+++ b/util_math.h
@@ -38,6 +38,9 @@ static inline unsigned log2_int(unsigned x)
if (x < 2) {
return 0;
}
On Tue, Oct 27, 2020 at 6:12 PM Peilin Ye wrote:
> Remove 6 unused extern variables to reduce confusion. It is worth
> mentioning that lib/fonts/font_8x8.c and lib/fonts/font_8x16.c also
> declare `fontdata_8x8` and `fontdata_8x16` respectively, and this file
> has nothing to do with them.
>
> Sig
Am 27.10.20 um 22:49 schrieb Daniel Vetter:
When we forward an mmap to the dma_buf exporter, they get to own
everything. Unfortunately drm_gem_mmap_obj() overwrote
vma->vm_private_data after the driver callback, wreaking the
exporter complete. This was noticed because vb2_common_vm_close blew
up
On 10/27/20 9:06 PM, Dmitry Osipenko wrote:
26.10.2020 12:11, Mikko Perttunen пишет:
The first patches should be the ones that are relevant to the existing
userspace code, like support for the waits.
Can you elaborate what you mean by this?
All features that don't have an immediate real use
Am 28.10.20 um 10:16 schrieb Daniel Vetter:
On Wed, Oct 21, 2020 at 11:58:45AM +0200, Christian König wrote:
Am 21.10.20 um 06:40 schrieb Dave Airlie:
From: Dave Airlie
The move notify callback is only used in one place, this should
be removed in the future, but for now just rename it to the
On Wed, Oct 21, 2020 at 02:40:31PM +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> Currently drivers get called to move a buffer, but if they have to
> move it temporarily through another space (SYSTEM->VRAM via TT)
> then they can end up with a lot of ttm->driver->ttm call stacks,
> if the tem
On Wed, Oct 21, 2020 at 11:58:45AM +0200, Christian König wrote:
> Am 21.10.20 um 06:40 schrieb Dave Airlie:
> > From: Dave Airlie
> >
> > The move notify callback is only used in one place, this should
> > be removed in the future, but for now just rename it to the use
> > case which is to notif
On Tue, Oct 27, 2020 at 01:17:18PM +0100, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski
>
> When allocating an array of elements, users should check for
> multiplication overflow or preferably use one of the provided helpers
> like: kmalloc_array().
>
> There's no krealloc_array() count
On Tue, 27 Oct 2020 22:49:22 +0100
Daniel Vetter wrote:
> When we forward an mmap to the dma_buf exporter, they get to own
> everything. Unfortunately drm_gem_mmap_obj() overwrote
> vma->vm_private_data after the driver callback, wreaking the
> exporter complete. This was noticed because vb2_comm
On Wed, Oct 28, 2020 at 01:43:07AM -0400, Peilin Ye wrote:
> On Tue, Oct 27, 2020 at 07:50:58PM +0100, Daniel Vetter wrote:
> > On Tue, Oct 27, 2020 at 12:33:05PM -0400, Peilin Ye wrote:
> > > It is improper to define `width` and `height` as signed in `struct
> > > font_desc`. Make them unsigned. A
1 - 100 of 159 matches
Mail list logo
