On 2020-10-30 08:04, Daniel Vetter wrote:
> On Fri, Oct 30, 2020 at 11:41 AM Liu, Monk wrote:
>>
>> [AMD Official Use Only - Internal Distribution Only]
>>
>> What's the purpose of the patch sets
>>
>> e.g.: what bug can those 5 patches fix or what feature provided
>>
>> for this particular one
On 10/30/20 3:08 AM, Daniel Vetter wrote:
This is used by media/videbuf2 for persistent dma mappings, not just
for a single dma operation and then freed again, so needs
FOLL_LONGTERM.
Unfortunately current pup_locked doesn't support FOLL_LONGTERM due to
locking issues. Rework the code to pull
Hi Neil.
On Fri, Oct 30, 2020 at 09:31:36AM +0100, Neil Armstrong wrote:
> Hi,
>
> On 29/10/2020 23:20, Sam Ravnborg wrote:
> > Hi Anitha.
> >
> > On Thu, Oct 29, 2020 at 02:27:52PM -0700, Anitha Chrisanthus wrote:
> >> This patch adds bindings for Intel KeemBay Display
> >>
> >> v2: review
The pull request you sent on Fri, 30 Oct 2020 12:01:27 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2020-10-30-1
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/7ba4d8675090480e64388f4669271c03123072b2
Thank you!
--
Deet-doot-dot, I am a bot.
On Fri, Oct 30, 2020 at 3:09 AM Daniel Vetter wrote:
>
> Since 3234ac664a87 ("/dev/mem: Revoke mappings when a driver claims
> the region") /dev/kmem zaps ptes when the kernel requests exclusive
> acccess to an iomem region. And with CONFIG_IO_STRICT_DEVMEM, this is
> the default for all driver
On Fri, Oct 30, 2020 at 12:51 AM Hillf Danton wrote:
> On Thu, 29 Oct 2020 21:04:30 -0700 John Stultz wrote:
> >
> > But I'll try to share my thoughts:
> >
> > So the system heap allows for allocation of non-contiguous buffers
> > (currently allocated from page_alloc), which we keep track using
>
On Fri, Oct 30, 2020 at 6:11 AM Daniel Vetter wrote:
>
> Only the following drivers aren't converted:
> - amdgpu, because of the driver_feature mangling due to virt support
> - nouveau, because DRIVER_ATOMIC uapi is still not the default on the
> platforms where it's supported (i.e. again
On Fri, Oct 30, 2020 at 6:11 AM Daniel Vetter wrote:
>
> It's nice if a big function/ioctl table like this is const. Only
> downside here is that we need a few more #ifdef to paper over the
> differences when CONFIG_DRM_LEGACY is enabled. Maybe provides more
> motivation to sunset that horror
On Fri, Oct 30, 2020 at 6:11 AM Daniel Vetter wrote:
>
> Prep work to make drm_device->driver const.
>
> Signed-off-by: Daniel Vetter
> Cc: Alex Deucher
> Cc: "Christian König"
> Cc: Evan Quan
> Cc: Felix Kuehling
> Cc: Hawking Zhang
> Cc: Andrey Grodzovsky
> Cc: Luben Tuikov
> Cc: Thomas
On Mon, 26 Oct 2020 08:41:06 +0200, Bogdan Togorean wrote:
> Add YAML device tree bindings for Analog Devices Inc. AXI HDMI TX
> IP core DRM driver.
>
> Signed-off-by: Bogdan Togorean
> ---
> .../bindings/display/adi/adi,axi-hdmi-tx.yaml | 72 +++
> 1 file changed, 72
On Fri, Oct 30, 2020 at 6:11 AM Daniel Vetter wrote:
>
> This means some very few #ifdef in code, but it allows us to
> enlist the compiler to make sure this stuff isn't used anymore.
>
> More important, only legacy drivers change drm_device (for the
> legacy_dev_list shadow attach management),
On Fri, Oct 30, 2020 at 6:11 AM Daniel Vetter wrote:
>
> With only the kms driver left, we can fold this in. This means
> we need to move the ioctl table, which means one additional ioctl
> must be defined in headers.
>
> Also there's a conflict between the radeon_init macro and the module
> init
Applied. Thanks!
Alex
On Fri, Oct 30, 2020 at 1:04 PM Harry Wentland wrote:
>
>
>
> On 2020-10-29 11:53 p.m., Alex Deucher wrote:
> > On Mon, Oct 26, 2020 at 5:01 PM Arnd Bergmann wrote:
> >>
> >> From: Arnd Bergmann
> >>
> >> gcc -Wextra warns about a function taking an enum argument
> >>
On 2020-10-29 11:53 p.m., Alex Deucher wrote:
On Mon, Oct 26, 2020 at 5:01 PM Arnd Bergmann wrote:
From: Arnd Bergmann
gcc -Wextra warns about a function taking an enum argument
being called with a bool:
drivers/gpu/drm/amd/amdgpu/../display/modules/color/color_gamma.c: In function
Hi Dave, Daniel,
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://git.pengutronix.de/git/pza/linux.git tags/imx-drm-next-2020-10-30
for you to fetch changes up to
https://bugzilla.kernel.org/show_bug.cgi?id=208835
--- Comment #4 from Tom (t...@collider.in) ---
Created attachment 293321
--> https://bugzilla.kernel.org/attachment.cgi?id=293321=edit
systemd journal
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=208835
Tom (t...@collider.in) changed:
What|Removed |Added
CC||t...@collider.in
--- Comment #3
On Fri, 23 Oct 2020 15:31:26 +0200, Fabien Parent wrote:
> Add binding documentation for the MT8167 SoC
>
> Signed-off-by: Fabien Parent
> Reviewed-by: Chun-Kuang Hu
> ---
>
> Changelog:
>
> V2: No change
>
> .../devicetree/bindings/display/mediatek/mediatek,disp.txt| 4 ++--
> 1 file
https://bugzilla.kernel.org/show_bug.cgi?id=208115
op (paananen.o...@tuta.io) changed:
What|Removed |Added
CC||paananen.o...@tuta.io
---
When unloading the call to pm_runtime_put_sync_suspend() will attempt to
turn the GPU cores off, however panfrost_device_fini() will have turned
the clocks off. This leads to the hardware locking up.
Instead don't call pm_runtime_put_sync_suspend() and instead simply mark
the device as suspended
On Fri, Oct 30, 2020 at 02:19:45PM +, Chris Wilson wrote:
> Quoting Ville Syrjala (2020-10-22 20:42:56)
> > From: Ville Syrjälä
> >
> > The new >8k CEA modes have dotclocks reaching 5.94 GHz, which
> > means our clock*1000 will now overflow the 32bit unsigned
> > integer. Switch to 64bit
On Fri, Oct 30, 2020 at 3:11 PM Tomasz Figa wrote:
>
> On Fri, Oct 30, 2020 at 11:08 AM Daniel Vetter wrote:
> >
> > This is used by media/videbuf2 for persistent dma mappings, not just
> > for a single dma operation and then freed again, so needs
> > FOLL_LONGTERM.
> >
> > Unfortunately current
On Fri, Oct 30, 2020 at 3:27 PM Christian König
wrote:
>
> Am 30.10.20 um 13:08 schrieb Daniel Vetter:
> > On Fri, Oct 30, 2020 at 12:13 PM Christian König
> > wrote:
> >> The check for swiotlb has moved to nouveu_ttm.c, but we forgot to move
> >> the include as well.
> >>
> >> Signed-off-by:
Am Donnerstag, den 29.10.2020, 15:20 +0100 schrieb Guido Günther:
> etnaviv_iommu_find_iova has it so etnaviv_iommu_insert_exact and
> lockdep_assert_held should have it as well.
This sounds reasonable to me. I've added this patch to my etnaviv/next
branch.
Regards,
Lucas
> Signed-off-by: Guido
On 2020-10-30 10:53, Boris Brezillon wrote:
[...]
+ /* Schedule a reset if there's no reset in progress. */
+ if (!atomic_cmpxchg(>reset.pending, 0, 1))
Nit: this could just be a simple xchg with 1 - you don't need the
compare aspect, since setting it to true when it was already
Am 30.10.20 um 13:08 schrieb Daniel Vetter:
On Fri, Oct 30, 2020 at 12:13 PM Christian König
wrote:
The check for swiotlb has moved to nouveu_ttm.c, but we forgot to move
the include as well.
Signed-off-by: Christian König
Hm drm-misc-next compiles fine with swiotlb enabled in config. Am I
Quoting Ville Syrjala (2020-10-22 20:42:56)
> From: Ville Syrjälä
>
> The new >8k CEA modes have dotclocks reaching 5.94 GHz, which
> means our clock*1000 will now overflow the 32bit unsigned
> integer. Switch to 64bit maths to avoid it.
>
> Cc: sta...@vger.kernel.org
> Reported-by: Randy
Hi,
On Fri, Oct 30, 2020 at 10:19:54AM +0100, Lucas Stach wrote:
> Am Donnerstag, den 29.10.2020, 19:20 +0100 schrieb Daniel Vetter:
> > On Thu, Oct 29, 2020 at 03:38:21PM +0100, Lucas Stach wrote:
> > > Hi Guido,
> > >
> > > Am Donnerstag, den 29.10.2020, 15:20 +0100 schrieb Guido Günther:
> > >
On Fri, Oct 30, 2020 at 11:08 AM Daniel Vetter wrote:
>
> This is used by media/videbuf2 for persistent dma mappings, not just
> for a single dma operation and then freed again, so needs
> FOLL_LONGTERM.
>
> Unfortunately current pup_locked doesn't support FOLL_LONGTERM due to
> locking issues.
On Thu, 29 Oct 2020 13:37:21 +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
On 10/30/20 14:07, Pekka Paalanen wrote:
> On Wed, 28 Oct 2020 13:06:02 +0300
> Paul Gofman wrote:
>
>> 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
>> ---
Signed-off-by: Paul Gofman
---
v2:
- no changes.
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
Signed-off-by: Paul Gofman
---
v2:
- simplify log2_int implementation.
util_math.h | 15 +--
1 file changed, 5 insertions(+), 10 deletions(-)
diff --git a/util_math.h b/util_math.h
index e2fa95f5..32297349 100644
--- a/util_math.h
+++ b/util_math.h
@@ -33,16 +33,11 @@
static
From: Artur Świgoń
This patch adds an 'interconnects' property to Exynos4412 DTS in order to
declare the interconnect path used by the mixer. Please note that the
'interconnect-names' property is not needed when there is only one path in
'interconnects', in which case calling of_icc_get() with a
This patch adds interconnect support to exynos-mixer. The mixer works
the same as before when CONFIG_INTERCONNECT is 'n'.
For proper operation of the video mixer block we need to ensure the
interconnect busses like DMC or LEFTBUS provide enough bandwidth so
as to avoid DMA buffer underruns in the
This patch adds registration of a child platform device for the exynos
interconnect driver. It is assumed that the interconnect provider will
only be needed when #interconnect-cells property is present in the bus
DT node, hence the child device will be created only when such a property
is present.
This patchset adds interconnect API support for the Exynos SoC "samsung,
exynos-bus" compatible devices, which already have their corresponding
exynos-bus driver in the devfreq subsystem. Complementing the devfreq
driver with an interconnect functionality allows to ensure the QoS
requirements of
This patch adds the following properties for Exynos4412 interconnect
bus nodes:
- interconnects: to declare connections between nodes in order to
guarantee PM QoS requirements between nodes,
- #interconnect-cells: required by the interconnect framework,
- samsung,data-clk-ratio: which allows
Add documentation for new optional properties in the exynos bus nodes:
interconnects, #interconnect-cells, samsung,data-clock-ratio.
These properties allow to specify the SoC interconnect structure which
then allows the interconnect consumer devices to request specific
bandwidth requirements.
This patch adds a generic interconnect driver for Exynos SoCs in order
to provide interconnect functionality for each "samsung,exynos-bus"
compatible device.
The SoC topology is a graph (or more specifically, a tree) and its
edges are specified using the 'samsung,interconnect-parent' in the
DT.
Hi Boris,
On 30/10/2020 10:08, Boris Brezillon wrote:
> The "propagate output flags" and soon to be added "use
> timing->input_flags if present" logic should only be used as a fallback
> for bridges that do not support dynamic bus format/flags negotiation
> IMHO. Ideally we'd want to convert all
On 29/10/2020 15:22, 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 is that most
Hi Georgi,
On 15.09.2020 23:40, Georgi Djakov wrote:
> On 9/9/20 17:47, Sylwester Nawrocki wrote:
>> On 09.09.2020 11:07, Georgi Djakov wrote:
>>> On 8/28/20 17:49, Sylwester Nawrocki wrote:
On 30.07.2020 14:28, Sylwester Nawrocki wrote:
> On 09.07.2020 23:04, Rob Herring wrote:
>>
On Fri, Oct 30, 2020 at 12:13 PM Christian König
wrote:
>
> The check for swiotlb has moved to nouveu_ttm.c, but we forgot to move
> the include as well.
>
> Signed-off-by: Christian König
Hm drm-misc-next compiles fine with swiotlb enabled in config. Am I
blind or is this a merge problem with
On Fri, Oct 30, 2020 at 11:41 AM Liu, Monk wrote:
>
> [AMD Official Use Only - Internal Distribution Only]
>
> What's the purpose of the patch sets
>
> e.g.: what bug can those 5 patches fix or what feature provided
>
> for this particular one (3/5) I didn't see how it helpful, could you give a
This is freed both here and in the caller (virtio_gpu_vram_map()) so
it's a double free. The correct place is only in the caller.
Fixes: 16845c5d5409 ("drm/virtio: implement blob resources: implement vram
object")
Signed-off-by: Dan Carpenter
---
drivers/gpu/drm/virtio/virtgpu_vq.c | 4 +---
On 30/10/2020 00:48, Laurent Pinchart wrote:
>>> And, hmm... It's too easy to get confused with these, but... If the bridge
>>> defines timings, and
>>> timings->input_bus_flags != 0, should we always pick that, even if we got
>>> something via
>>> output_flags? Logic being, if this bridge
The check for swiotlb has moved to nouveu_ttm.c, but we forgot to move
the include as well.
Signed-off-by: Christian König
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 1 -
drivers/gpu/drm/nouveau/nouveau_ttm.c | 3 +++
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git
On 30/10/2020 10:53, Boris Brezillon wrote:
We've fixed many races in panfrost_job_timedout() but some remain.
Instead of trying to fix it again, let's simplify the logic and move
the reset bits to a separate work scheduled when one of the queue
reports a timeout.
v2:
- Use atomic_cmpxchg() to
On Wed, 28 Oct 2020 13:06:02 +0300
Paul Gofman wrote:
> 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
On 30/10/2020 10:28, Boris Brezillon wrote:
On Fri, 30 Oct 2020 10:00:07 +
Steven Price wrote:
On 30/10/2020 07:08, Boris Brezillon wrote:
We've fixed many races in panfrost_job_timedout() but some remain.
Instead of trying to fix it again, let's simplify the logic and move
the reset
We've fixed many races in panfrost_job_timedout() but some remain.
Instead of trying to fix it again, let's simplify the logic and move
the reset bits to a separate work scheduled when one of the queue
reports a timeout.
v2:
- Use atomic_cmpxchg() to conditionally schedule the reset work (Steven
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
Reviewed-by: Matthias Kaehlcke
---
Documentation/devicetree/bindings/display/msm/gpu.txt | 7 +++
1 file changed, 7 insertions(+)
diff --git
Add cooling-cells property and the cooling maps for the gpu tzones
to support GPU cooling.
Signed-off-by: Akhil P Oommen
Reviewed-by: Matthias Kaehlcke
---
arch/arm64/boot/dts/qcom/sc7180.dtsi | 30 +++---
1 file changed, 23 insertions(+), 7 deletions(-)
diff --git
Register GPU as a devfreq cooling device so that it can be passively
cooled by the thermal framework.
Signed-off-by: Akhil P Oommen
Tested-by: Matthias Kaehlcke
---
Changes in v5:
1. Update Reviewed-by/Tested-by tags
Changes in v4:
1. Fix gpu cooling map.
2. Add mka's
[AMD Official Use Only - Internal Distribution Only]
What's the purpose of the patch sets
e.g.: what bug can those 5 patches fix or what feature provided
for this particular one (3/5) I didn't see how it helpful, could you give a
background ?
thanks
_
Monk
On Fri, 30 Oct 2020 10:00:07 +
Steven Price wrote:
> On 30/10/2020 07:08, Boris Brezillon wrote:
> > We've fixed many races in panfrost_job_timedout() but some remain.
> > Instead of trying to fix it again, let's simplify the logic and move
> > the reset bits to a separate work scheduled
With only the kms driver left, we can fold this in. This means
we need to move the ioctl table, which means one additional ioctl
must be defined in headers.
Also there's a conflict between the radeon_init macro and the module
init function, so rename the module functions to avoid that.
It's nice if a big function/ioctl table like this is const. Only
downside here is that we need a few more #ifdef to paper over the
differences when CONFIG_DRM_LEGACY is enabled. Maybe provides more
motivation to sunset that horror show :-)
v2:
- Fix super important checkpatch warning (Sam)
-
Only the following drivers aren't converted:
- amdgpu, because of the driver_feature mangling due to virt support
- nouveau, because DRIVER_ATOMIC uapi is still not the default on the
platforms where it's supported (i.e. again driver_feature mangling)
- vc4, again because of driver_feature
This means some very few #ifdef in code, but it allows us to
enlist the compiler to make sure this stuff isn't used anymore.
More important, only legacy drivers change drm_device (for the
legacy_dev_list shadow attach management), therefore this is
prep to allow modern drivers to have a const
Prep work to make drm_device->driver const.
Signed-off-by: Daniel Vetter
Cc: Alex Deucher
Cc: "Christian König"
Cc: Evan Quan
Cc: Felix Kuehling
Cc: Hawking Zhang
Cc: Andrey Grodzovsky
Cc: Luben Tuikov
Cc: Thomas Zimmermann
Cc: Monk Liu
Cc: Yintian Tao
Cc: Dennis Li
Cc: shaoyunl
Cc:
We want all iomem mmaps to consistently revoke ptes when the kernel
takes over and CONFIG_IO_STRICT_DEVMEM is enabled. This includes the
pci bar mmaps available through procfs and sysfs, which currently do
not revoke mappings.
To prepare for this, move the code from the /dev/kmem driver to
It's the only user. This also garbage collects the CONFIG_FRAME_VECTOR
symbol from all over the tree (well just one place, somehow omap media
driver still had this in its Kconfig, despite not using it).
Reviewed-by: John Hubbard
Acked-by: Mauro Carvalho Chehab
Acked-by: Tomasz Figa
The media model assumes that buffers are all preallocated, so that
when a media pipeline is running we never miss a deadline because the
buffers aren't allocated or available.
This means we cannot fix the v4l follow_pfn usage through
mmu_notifier, without breaking how this all works. The only
We want to be able to revoke pci mmaps so that the same access rules
applies as for /dev/kmem. Revoke support for devmem was added in
3234ac664a87 ("/dev/mem: Revoke mappings when a driver claims the
region").
The simplest way to achieve this is by having the same filp->f_mapping
for all
Way back it was a reasonable assumptions that iomem mappings never
change the pfn range they point at. But this has changed:
- gpu drivers dynamically manage their memory nowadays, invalidating
ptes with unmap_mapping_range when buffers get moved
- contiguous dma allocations have moved from
There's three ways to access PCI BARs from userspace: /dev/mem, sysfs
files, and the old proc interface. Two check against
iomem_is_exclusive, proc never did. And with CONFIG_IO_STRICT_DEVMEM,
this starts to matter, since we don't want random userspace having
access to PCI BARs while a driver is
These are persistent, not just for the duration of a dma operation.
Signed-off-by: Daniel Vetter
Cc: Jason Gunthorpe
Cc: Andrew Morton
Cc: John Hubbard
Cc: Jérôme Glisse
Cc: Jan Kara
Cc: Dan Williams
Cc: linux...@kvack.org
Cc: linux-arm-ker...@lists.infradead.org
Cc:
When we care about pagecache maintenance, we need to make sure that
both f_mapping and i_mapping point at the right mapping.
But for iomem mappings we only care about the virtual/pte side of
things, so f_mapping is enough. Also setting inode->i_mapping was
confusing me as a driver maintainer,
The exynos g2d interface is very unusual, but it looks like the
userptr objects are persistent. Hence they need FOLL_LONGTERM.
Signed-off-by: Daniel Vetter
Cc: Jason Gunthorpe
Cc: Inki Dae
Cc: Joonyoung Shim
Cc: Seung-Woo Kim
Cc: Kyungmin Park
Cc: Kukjin Kim
Cc: Krzysztof Kozlowski
Cc:
Since 3234ac664a87 ("/dev/mem: Revoke mappings when a driver claims
the region") /dev/kmem zaps ptes when the kernel requests exclusive
acccess to an iomem region. And with CONFIG_IO_STRICT_DEVMEM, this is
the default for all driver uses.
Except there's two more ways to access PCI BARs: sysfs and
Hi all
Another update of my patch series to clamp down a bunch of races and gaps
around follow_pfn and other access to iomem mmaps. Previous version:
v1:
https://lore.kernel.org/dri-devel/20201007164426.1812530-1-daniel.vet...@ffwll.ch/
v2:
Way back it was a reasonable assumptions that iomem mappings never
change the pfn range they point at. But this has changed:
- gpu drivers dynamically manage their memory nowadays, invalidating
ptes with unmap_mapping_range when buffers get moved
- contiguous dma allocations have moved from
All we need are a pages array, pin_user_pages_fast can give us that
directly. Plus this avoids the entire raw pfn side of get_vaddr_frames.
Reviewed-by: John Hubbard
Signed-off-by: Daniel Vetter
Cc: Jason Gunthorpe
Cc: Andrew Morton
Cc: John Hubbard
Cc: Jérôme Glisse
Cc: Jan Kara
Cc: Dan
This is used by media/videbuf2 for persistent dma mappings, not just
for a single dma operation and then freed again, so needs
FOLL_LONGTERM.
Unfortunately current pup_locked doesn't support FOLL_LONGTERM due to
locking issues. Rework the code to pull the pup path out from the
mmap_sem critical
All we need are a pages array, pin_user_pages_fast can give us that
directly. Plus this avoids the entire raw pfn side of get_vaddr_frames.
Reviewed-by: John Hubbard
Signed-off-by: Daniel Vetter
Cc: Jason Gunthorpe
Cc: Inki Dae
Cc: Joonyoung Shim
Cc: Seung-Woo Kim
Cc: Kyungmin Park
Cc:
The code seems to stuff these pfns into iommu pts (or something like
that, I didn't follow), but there's no mmu_notifier to ensure that
access is synchronized with pte updates.
Hence mark these as unsafe. This means that with
CONFIG_STRICT_FOLLOW_PFN, these will be rejected.
Real fix is to wire
On 30/10/2020 07:40, Mauro Carvalho Chehab wrote:
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
---
On 30/10/2020 07:08, Boris Brezillon wrote:
We've fixed many races in panfrost_job_timedout() but some remain.
Instead of trying to fix it again, let's simplify the logic and move
the reset bits to a separate work scheduled when one of the queue
reports a timeout.
Fixes: 1a11a88cfd9a
Am 30.10.20 um 09:25 schrieb Greg KH:
On Fri, Oct 30, 2020 at 09:00:04AM +0100, Christian König wrote:
Am 30.10.20 um 08:57 schrieb Deepak R Varma:
On Fri, Oct 30, 2020 at 08:11:20AM +0100, Greg KH wrote:
On Fri, Oct 30, 2020 at 08:52:45AM +0530, Deepak R Varma wrote:
Using
On Fri, 30 Oct 2020, Deepak R Varma wrote:
> Using DEFINE_DEBUGFS_ATTRIBUTE macro with debugfs_create_file_unsafe()
> function in place of the debugfs_create_file() function will make the
> file operation struct "reset" aware of the file's lifetime. Additional
> details here:
Am Freitag, den 30.10.2020, 10:33 +0100 schrieb Daniel Vetter:
> On Fri, Oct 30, 2020 at 10:19:54AM +0100, Lucas Stach wrote:
> > Am Donnerstag, den 29.10.2020, 19:20 +0100 schrieb Daniel Vetter:
> > > On Thu, Oct 29, 2020 at 03:38:21PM +0100, Lucas Stach wrote:
> > > > Hi Guido,
> > > >
> > > >
On Fri, Oct 30, 2020 at 10:19:54AM +0100, Lucas Stach wrote:
> Am Donnerstag, den 29.10.2020, 19:20 +0100 schrieb Daniel Vetter:
> > On Thu, Oct 29, 2020 at 03:38:21PM +0100, Lucas Stach wrote:
> > > Hi Guido,
> > >
> > > Am Donnerstag, den 29.10.2020, 15:20 +0100 schrieb Guido Günther:
> > > >
On Fri, Oct 30, 2020 at 10:15:21AM +0100, Daniel Vetter wrote:
> On Fri, Oct 30, 2020 at 09:25:18AM +0100, Greg KH wrote:
> > On Fri, Oct 30, 2020 at 09:00:04AM +0100, Christian König wrote:
> > > Am 30.10.20 um 08:57 schrieb Deepak R Varma:
> > > > On Fri, Oct 30, 2020 at 08:11:20AM +0100, Greg
Am Donnerstag, den 29.10.2020, 19:20 +0100 schrieb Daniel Vetter:
> On Thu, Oct 29, 2020 at 03:38:21PM +0100, Lucas Stach wrote:
> > Hi Guido,
> >
> > Am Donnerstag, den 29.10.2020, 15:20 +0100 schrieb Guido Günther:
> > > So far the unmap from gpu address space only happened when dropping the
>
On Thu, 29 Oct 2020 17:00:47 +
Steven Price wrote:
> The mutex within the panfrost_queue_state should have the lifetime of
> the queue, however it was erroneously initialised/destroyed during
> panfrost_job_{open,close} which is called every time a client
> opens/closes the drm node.
>
>
On Fri, Oct 30, 2020 at 09:25:18AM +0100, Greg KH wrote:
> On Fri, Oct 30, 2020 at 09:00:04AM +0100, Christian König wrote:
> > Am 30.10.20 um 08:57 schrieb Deepak R Varma:
> > > On Fri, Oct 30, 2020 at 08:11:20AM +0100, Greg KH wrote:
> > > > On Fri, Oct 30, 2020 at 08:52:45AM +0530, Deepak R
On Thu, Oct 29, 2020 at 06:00:58PM -0700, Abhinav Kumar wrote:
> Currently drm_atomic_print_state() internally allocates and uses a
> drm_info printer. Allow it to accept any drm_printer type so that
> the API can be leveraged even for taking drm snapshot.
>
> Rename the drm_atomic_print_state()
On Thu, Oct 29, 2020 at 08:01:04PM +0100, Maxime Ripard wrote:
> In order to make the vc4_kms_load code and error path a bit easier to
> read and extend, add functions to create state objects, and use managed
> actions to cleanup if needed.
>
> Signed-off-by: Maxime Ripard
Nice. With an
On Thu, Oct 29, 2020 at 08:00:59PM +0100, Maxime Ripard wrote:
> The BO cache needs to be cleaned up using vc4_bo_cache_destroy, but it's
> not used consistently (vc4_drv's bind calls it in its error path, but
> doesn't in unbind), and we can make that automatic through a managed
> action. Let's
On Friday, October 30, 2020 9:09 AM, Pekka Paalanen wrote:
> On Thu, 29 Oct 2020 21:53:34 +0100
> Marcin Kocur marcin2...@gmail.com wrote:
>
> > Hello,
> > this is the output of turning off and on my display (using power button):
>
> ...
>
> > The monitor was visible in xrandr as DP-2, after
On Fri, Oct 30, 2020 at 9:30 AM Tomi Valkeinen wrote:
>
> On 29/10/2020 15:22, 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
On Fri, 30 Oct 2020 10:40:46 +0200
Tomi Valkeinen wrote:
> Hi Boris,
>
> On 30/10/2020 10:08, Boris Brezillon wrote:
> > The "propagate output flags" and soon to be added "use
> > timing->input_flags if present" logic should only be used as a fallback
> > for bridges that do not support dynamic
On 22/09/2020 16:16, Robin Murphy wrote:
> Hi all,
>
> Here's a quick v2 with the tags so far picked up and some inline
> commentary about the shareability domains for the pagetable code.
>
> Robin.
>
>
> Robin Murphy (3):
> iommu/io-pgtable-arm: Support coherency for Mali LPAE
>
On 29/10/2020 23:22, Sam Ravnborg wrote:
> Hi Anitha.
>
> On Thu, Oct 29, 2020 at 02:27:53PM -0700, Anitha Chrisanthus wrote:
>> This patch adds bindings for Intel KeemBay MIPI DSI
>>
>> Signed-off-by: Anitha Chrisanthus
>> Cc: Sam Ravnborg
>> Cc: Thomas Zimmermann
>> Cc: Daniel Vetter
>
>
Hi,
On 29/10/2020 23:20, Sam Ravnborg wrote:
> Hi Anitha.
>
> On Thu, Oct 29, 2020 at 02:27:52PM -0700, Anitha Chrisanthus wrote:
>> This patch adds bindings for Intel KeemBay Display
>>
>> v2: review changes from Rob Herring
>> v3: review changes from Sam Ravnborg (removed mipi dsi entries, and
Himax HX8837 is a secondary display controller used to drive the panel
on OLPC platforms.
Signed-off-by: Lubomir Rintel
Reviewed-by: Rob Herring
---
Changes since v4:
- Rob's Reviewed-by
Changes since v3:
- Moved to bindings/display/
- Added the ports
- Converted to YAML
- Removed Pavel's
We should be setting the drm_dp_aux_msg::reply field if a NACK or a
SHORT reply happens. Update the error bit handling logic in
ti_sn_aux_transfer() to handle these cases and notify upper layers that
such errors have happened. This helps the retry logic understand that a
timeout has happened, or
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu11/navi10_ppt.c:2527:35:
warning: ‘navi10_i2c_algo’
defined but not used [-Wunused-const-variable=]
static const struct i2c_algorithm navi10_i2c_algo = {
^~~
1 - 100 of 161 matches
Mail list logo
