On Sat, Oct 3, 2020 at 1:31 AM Jason Gunthorpe wrote:
>
> On Fri, Oct 02, 2020 at 08:16:48PM +0200, Daniel Vetter wrote:
> > On Fri, Oct 2, 2020 at 8:06 PM Jason Gunthorpe wrote:
> > > On Fri, Oct 02, 2020 at 07:53:03PM +0200, Daniel Vetter wrote:
> > > > For $reasons I've stumbled over this code
On Wed, Oct 7, 2020 at 2:57 PM Thomas Zimmermann wrote:
>
> Hi
>
> Am 02.10.20 um 11:58 schrieb Daniel Vetter:
> > On Wed, Sep 30, 2020 at 02:51:46PM +0200, Daniel Vetter wrote:
> >> On Wed, Sep 30, 2020 at 2:34 PM Christian König
> >> wrote:
> >>>
> >>> Am 30.09.20 um 11:47 schrieb Daniel Vetter
On 10/06, Melissa Wen wrote:
> Drop issues already resolved in vkms:
>
> - CRC API Improvements to [1] add igt test to check extreme alpha values
> and [2] alpha blending;
> - [3] prime buffer sharing;
> - [4] writeback support;
>
> On the other hand, we also found or thought about other improv
Hi
Am 07.10.20 um 15:10 schrieb Daniel Vetter:
> On Wed, Oct 7, 2020 at 2:57 PM Thomas Zimmermann wrote:
>>
>> Hi
>>
>> Am 02.10.20 um 11:58 schrieb Daniel Vetter:
>>> On Wed, Sep 30, 2020 at 02:51:46PM +0200, Daniel Vetter wrote:
On Wed, Sep 30, 2020 at 2:34 PM Christian König
wrote:
Am 07.10.20 um 15:20 schrieb Thomas Zimmermann:
Hi
Am 07.10.20 um 15:10 schrieb Daniel Vetter:
On Wed, Oct 7, 2020 at 2:57 PM Thomas Zimmermann wrote:
Hi
Am 02.10.20 um 11:58 schrieb Daniel Vetter:
On Wed, Sep 30, 2020 at 02:51:46PM +0200, Daniel Vetter wrote:
On Wed, Sep 30, 2020 at 2:34
We didn't take the kernel_fb_helper_lock mutex, which protects that
code. While at it, simplify the code
- inline the function (originally shared with kgdb I think)
- drop the error tracking and all the complications
- drop the pointless early out, it served nothing
Signed-off-by: Daniel Vetter
C
On Wed, Oct 7, 2020 at 3:06 PM Jason Gunthorpe wrote:
>
> On Wed, Oct 07, 2020 at 02:58:33PM +0200, Daniel Vetter wrote:
> > On Wed, Oct 7, 2020 at 2:48 PM Tomasz Figa wrote:
> > >
> > > On Wed, Oct 7, 2020 at 2:44 PM Jason Gunthorpe wrote:
> > > >
> > > > On Wed, Oct 07, 2020 at 02:33:56PM +020
Hi Marek,
On Wed, Oct 07, 2020 at 10:55:24AM +0200, Marek Vasut wrote:
> On 10/7/20 10:43 AM, Lucas Stach wrote:
> > On Mi, 2020-10-07 at 10:32 +0200, Marek Vasut wrote:
> >> On 10/7/20 3:24 AM, Laurent Pinchart wrote:
> >> [...]
> >>> +properties:
> >>> + compatible:
> >>> +enum:
> >>> +
On Tue, Oct 6, 2020 at 8:00 PM Chrisanthus, Anitha
wrote:
>
> Hi Rob,
> Thanks for the your prompt review. Please see my comments/questions inline.
> For everything else, I can incorporate the changes in v2.
> Anitha
>
> > -Original Message-
> > From: Rob Herring
> > Sent: Tuesday, Octobe
On Mon, Aug 31, 2020 at 3:03 PM Anitha Chrisanthus
wrote:
>
> This is a new DRM driver for Intel's KeemBay SOC.
> The SoC couples an ARM Cortex A53 CPU with an Intel
> Movidius VPU.
>
> This driver is tested with the KMB EVM board which is the refernce baord
> for Keem Bay SOC. The SOC's display p
On Fri, Oct 2, 2020 at 9:17 PM Anitha Chrisanthus
wrote:
>
> Register definitions for Keem Bay display driver
>
> v2: removed license text (Sam)
> v3: Squashed all 59 commits to one
> v4: review changes from Sam Ravnborg
> renamed dev_p to kmb
> v5: corrected spellings
> v6: corrected chec
On Wed, Oct 7, 2020 at 3:34 PM Tomasz Figa wrote:
>
> On Wed, Oct 7, 2020 at 3:06 PM Jason Gunthorpe wrote:
> >
> > On Wed, Oct 07, 2020 at 02:58:33PM +0200, Daniel Vetter wrote:
> > > On Wed, Oct 7, 2020 at 2:48 PM Tomasz Figa wrote:
> > > >
> > > > On Wed, Oct 7, 2020 at 2:44 PM Jason Gunthorp
On Wed, Oct 7, 2020 at 4:09 PM Daniel Vetter wrote:
>
> On Wed, Oct 7, 2020 at 3:34 PM Tomasz Figa wrote:
> >
> > On Wed, Oct 7, 2020 at 3:06 PM Jason Gunthorpe wrote:
> > >
> > > On Wed, Oct 07, 2020 at 02:58:33PM +0200, Daniel Vetter wrote:
> > > > On Wed, Oct 7, 2020 at 2:48 PM Tomasz Figa w
On Wed, Oct 7, 2020 at 4:12 PM Tomasz Figa wrote:
>
> On Wed, Oct 7, 2020 at 4:09 PM Daniel Vetter wrote:
> >
> > On Wed, Oct 7, 2020 at 3:34 PM Tomasz Figa wrote:
> > >
> > > On Wed, Oct 7, 2020 at 3:06 PM Jason Gunthorpe wrote:
> > > >
> > > > On Wed, Oct 07, 2020 at 02:58:33PM +0200, Daniel
On Wed, Oct 7, 2020 at 3:25 PM Christian König wrote:
>
> Am 07.10.20 um 15:20 schrieb Thomas Zimmermann:
> > Hi
> >
> > Am 07.10.20 um 15:10 schrieb Daniel Vetter:
> >> On Wed, Oct 7, 2020 at 2:57 PM Thomas Zimmermann
> >> wrote:
> >>> Hi
> >>>
> >>> Am 02.10.20 um 11:58 schrieb Daniel Vetter:
> -Original Message-
> From: Rob Herring
> Sent: Wednesday, October 7, 2020 6:45 AM
> To: Chrisanthus, Anitha
> Cc: dri-devel ; Paauwe, Bob J
> ; Dea, Edmund J ;
> Vetter, Daniel ; Sam Ravnborg
>
> Subject: Re: [PATCH v8 1/4] drm/kmb: Keem Bay driver register definition
>
> On Fri, Oc
On Wed, Oct 7, 2020 at 4:23 PM Daniel Vetter wrote:
>
> On Wed, Oct 7, 2020 at 4:12 PM Tomasz Figa wrote:
> >
> > On Wed, Oct 7, 2020 at 4:09 PM Daniel Vetter wrote:
> > >
> > > On Wed, Oct 7, 2020 at 3:34 PM Tomasz Figa wrote:
> > > >
> > > > On Wed, Oct 7, 2020 at 3:06 PM Jason Gunthorpe wro
Hi Lukasz,
On Monday 21 Sep 2020 at 13:20:06 (+0100), Lukasz Luba wrote:
[..]
> /**
> - * freq_get_state() - get the cooling state corresponding to a frequency
> + * freq_get_state() - get the performance index corresponding to a frequency
If we change the meaning of the return value, I think th
Hi Lukasz,
On Monday 21 Sep 2020 at 13:20:05 (+0100), Lukasz Luba wrote:
> The Energy Model (EM) framework supports devices such as Devfreq. Create
> new registration functions which automatically register EM for the thermal
> devfreq_cooling devices. This patch prepares the code for coming change
On 10/7/20 3:24 AM, Laurent Pinchart wrote:
[...]
> properties:
>compatible:
> -enum:
> - - fsl,imx23-lcdif
> - - fsl,imx28-lcdif
> - - fsl,imx6sx-lcdif
> - - fsl,imx8mq-lcdif
> +oneOf:
> + - enum:
> + - fsl,imx23-lcdif
> + - fsl,imx28-lcdif
On 10/06/20 13:04, Rob Clark wrote:
> On Tue, Oct 6, 2020 at 3:59 AM Qais Yousef wrote:
> >
> > On 10/05/20 16:24, Rob Clark wrote:
> >
> > [...]
> >
> > > > RT planning and partitioning is not easy task for sure. You might want
> > > > to
> > > > consider using affinities too to get stronger gua
On 10/7/20 10:43 AM, Lucas Stach wrote:
> On Mi, 2020-10-07 at 10:32 +0200, Marek Vasut wrote:
>> On 10/7/20 3:24 AM, Laurent Pinchart wrote:
>> [...]
>>> +properties:
>>> + compatible:
>>> +enum:
>>> + - fsl,imx23-lcdif
>>> + - fsl,imx28-lcdif
>>> + - fsl,imx6sx-lcdif
>>> +
On 10/7/20 3:33 PM, Laurent Pinchart wrote:
> Hi Marek,
>
> On Wed, Oct 07, 2020 at 10:55:24AM +0200, Marek Vasut wrote:
>> On 10/7/20 10:43 AM, Lucas Stach wrote:
>>> On Mi, 2020-10-07 at 10:32 +0200, Marek Vasut wrote:
On 10/7/20 3:24 AM, Laurent Pinchart wrote:
[...]
> +properties
On Wed, Oct 07, 2020 at 02:33:56PM +0200, Marek Szyprowski wrote:
> Well, it was in vb2_get_vma() function, but now I see that it has been
> lost in fb639eb39154 and 6690c8c78c74 some time ago...
There is no guarentee that holding a get on the file says anthing
about the VMA. This needed to check
On 10/7/20 3:24 AM, Laurent Pinchart wrote:
[...]
> + bus-width:
> +enum: [16, 18, 24]
> +description: |
> + The output bus width. This value overrides the configuration
> + derived from the connected device (encoder or panel). It should
On Wed, Oct 07, 2020 at 04:11:59PM +0200, Tomasz Figa wrote:
> We also need to bring back the vma_open() that somehow disappeared
> around 4.2, as Marek found.
No
Jason
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedeskto
On Wed, Oct 07, 2020 at 03:06:17PM +0200, Tomasz Figa wrote:
> Note that vb2_vmalloc is only used for in-kernel CPU usage, e.g. the
> contents being copied by the driver between vb2 buffers and some
> hardware FIFO or other dedicated buffers. The memory does not go to
> any hardware DMA.
That is
On 10/7/20 3:24 AM, Laurent Pinchart wrote:
[...]
> +properties:
> + compatible:
> +enum:
> + - fsl,imx23-lcdif
> + - fsl,imx28-lcdif
> + - fsl,imx6sx-lcdif
> + - fsl,imx8mq-lcdif
There is no fsl,imx8mq-lcdif in drivers/gpu/drm/mxsfb/mxsfb_drv.c,
so the DT must specify com
On Wed, Oct 07, 2020 at 02:58:33PM +0200, Daniel Vetter wrote:
> On Wed, Oct 7, 2020 at 2:48 PM Tomasz Figa wrote:
> >
> > On Wed, Oct 7, 2020 at 2:44 PM Jason Gunthorpe wrote:
> > >
> > > On Wed, Oct 07, 2020 at 02:33:56PM +0200, Marek Szyprowski wrote:
> > > > Well, it was in vb2_get_vma() func
syzbot has found a reproducer for the following issue on:
HEAD commit:c85fb28b Merge tag 'arm64-fixes' of git://git.kernel.org/p..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=17406d7050
kernel config: https://syzkaller.appspot.com/x/.config?x=140446a
On 10/7/20 2:42 AM, Laurent Pinchart wrote:
> Hi Marek,
>
> On Wed, Oct 07, 2020 at 12:38:50AM +0200, Marek Vasut wrote:
>> On 10/6/20 11:15 PM, Rob Herring wrote:
>>> On Sun, 04 Oct 2020 00:48:01 +0200, Marek Vasut wrote:
NXP's i.MX8MM has an LCDIF as well.
Signed-off-by: Marek Vas
On Wed, Oct 07, 2020 at 03:34:01PM +0200, Tomasz Figa wrote:
> I think the userptr zero-copy hack should be able to go away indeed,
> given that we now have CMA that allows having carveouts backed by
> struct pages and having the memory represented as DMA-buf normally.
This also needs to figure o
On Mon, Oct 05, 2020 at 05:15:40PM +0200, Maxime Ripard wrote:
> The Allwinner SoCs with two TCONs and LVDS output can use both to drive an
> LVDS dual-link. Add a new property to express that link between these two
> TCONs.
>
> Signed-off-by: Maxime Ripard
> ---
> Documentation/devicetree/bindi
Hi all,
This series aims to replace one-element arrays with flexible-array
members.
There is a regular need in the kernel to provide a way to declare having
a dynamically sized set of trailing elements in a structure. Kernel code
should always use “flexible array members”[1] for these cases. The
There is a regular need in the kernel to provide a way to declare having
a dynamically sized set of trailing elements in a structure. Kernel code
should always use “flexible array members”[1] for these cases. The older
style of one-element or zero-length arrays should no longer be used[2].
Refacto
There is a regular need in the kernel to provide a way to declare having
a dynamically sized set of trailing elements in a structure. Kernel code
should always use “flexible array members”[1] for these cases. The older
style of one-element or zero-length arrays should no longer be used[2].
Use a f
On Wed, Oct 7, 2020 at 3:36 AM Qais Yousef wrote:
>
> On 10/06/20 13:04, Rob Clark wrote:
> > On Tue, Oct 6, 2020 at 3:59 AM Qais Yousef wrote:
> > >
> > > On 10/05/20 16:24, Rob Clark wrote:
> > >
> > > [...]
> > >
> > > > > RT planning and partitioning is not easy task for sure. You might
> >
There is a regular need in the kernel to provide a way to declare having
a dynamically sized set of trailing elements in a structure. Kernel code
should always use “flexible array members”[1] for these cases. The older
style of one-element or zero-length arrays should no longer be used[2].
Refacto
There is a regular need in the kernel to provide a way to declare having
a dynamically sized set of trailing elements in a structure. Kernel code
should always use “flexible array members”[1] for these cases. The older
style of one-element or zero-length arrays should no longer be used[2].
Refacto
There is a regular need in the kernel to provide a way to declare having
a dynamically sized set of trailing elements in a structure. Kernel code
should always use “flexible array members”[1] for these cases. The older
style of one-element or zero-length arrays should no longer be used[2].
Refacto
There is a regular need in the kernel to provide a way to declare having
a dynamically sized set of trailing elements in a structure. Kernel code
should always use “flexible array members”[1] for these cases. The older
style of one-element or zero-length arrays should no longer be used[2].
Refacto
There is a regular need in the kernel to provide a way to declare having
a dynamically sized set of trailing elements in a structure. Kernel code
should always use “flexible array members”[1] for these cases. The older
style of one-element or zero-length arrays should no longer be used[2].
Refacto
On Wed, Oct 07, 2020 at 04:24:32AM +0300, Laurent Pinchart wrote:
> Convert the mxsfb binding to YAML. The deprecated binding is dropped, as
> neither the DT sources nor the driver support it anymore. The converted
> binding is named fsl,lcdif.yaml to match the usual bindings naming
> scheme.
>
>
There is a regular need in the kernel to provide a way to declare having
a dynamically sized set of trailing elements in a structure. Kernel code
should always use “flexible array members”[1] for these cases. The older
style of one-element or zero-length arrays should no longer be used[2].
Refacto
There is a regular need in the kernel to provide a way to declare having
a dynamically sized set of trailing elements in a structure. Kernel code
should always use “flexible array members”[1] for these cases. The older
style of one-element or zero-length arrays should no longer be used[2].
Refacto
On Wed, 07 Oct 2020 04:24:33 +0300, Laurent Pinchart wrote:
> Additional compatible strings have been added in DT source for the
> i.MX6SL, i.MX6SLL, i.MX6UL and i.MX7D without updating the bindings.
> Most of the upstream DT sources use the fsl,imx28-lcdif compatible
> string, which mostly predate
There is a regular need in the kernel to provide a way to declare having
a dynamically sized set of trailing elements in a structure. Kernel code
should always use “flexible array members”[1] for these cases. The older
style of one-element or zero-length arrays should no longer be used[2].
Refacto
On Wed, Oct 07, 2020 at 11:00:20AM -0500, Rob Herring wrote:
> On Wed, Oct 07, 2020 at 04:24:32AM +0300, Laurent Pinchart wrote:
> > Convert the mxsfb binding to YAML. The deprecated binding is dropped, as
> > neither the DT sources nor the driver support it anymore. The converted
> > binding is na
There is a regular need in the kernel to provide a way to declare having
a dynamically sized set of trailing elements in a structure. Kernel code
should always use “flexible array members”[1] for these cases. The older
style of one-element or zero-length arrays should no longer be used[2].
Refacto
On Wed, 07 Oct 2020 04:24:34 +0300, Laurent Pinchart wrote:
> When the PCB routes the display data signals in an unconventional way,
> the output bus width may differ from the bus width of the connected
> panel or encoder. For instance, when a 18-bit RGB panel has its R[5:0],
> G[5:0] and B[5:0] si
There is a regular need in the kernel to provide a way to declare having
a dynamically sized set of trailing elements in a structure. Kernel code
should always use “flexible array members”[1] for these cases. The older
style of one-element or zero-length arrays should no longer be used[2].
Refacto
There is a regular need in the kernel to provide a way to declare having
a dynamically sized set of trailing elements in a structure. Kernel code
should always use “flexible array members”[1] for these cases. The older
style of one-element or zero-length arrays should no longer be used[2].
Refacto
There is a regular need in the kernel to provide a way to declare having
a dynamically sized set of trailing elements in a structure. Kernel code
should always use “flexible array members”[1] for these cases. The older
style of one-element or zero-length arrays should no longer be used[2].
Use a f
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
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).
Signed-off-by: Daniel Vetter
Cc: Jason Gunthorpe
Cc: Pawel Osciak
Cc: Marek Szyprowski
Cc:
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: linux-samsung-...@vger.
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.
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 Kozlo
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 dedic
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 se
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 ded
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.
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.
Hi all,
This developed from a discussion with Jason, starting with some patches
touching get_vaddr_frame that I typed up.
The problem is that way back VM_IO | VM_PFNMAP mappings were pretty
static, and so just following the ptes to derive a pfn and then use that
somewhere else was ok.
But we're
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 dedic
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 lo
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: And
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 real
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 u
On Mon, Oct 5, 2020 at 5:15 AM Ville Syrjälä
wrote:
>
> On Fri, Oct 02, 2020 at 10:55:52AM -0700, Rob Clark wrote:
> > On Fri, Oct 2, 2020 at 4:05 AM Ville Syrjälä
> > wrote:
> > >
> > > On Fri, Oct 02, 2020 at 01:52:56PM +0300, Ville Syrjälä wrote:
> > > > On Thu, Oct 01, 2020 at 05:25:55PM +020
On Monday 21 Sep 2020 at 13:20:04 (+0100), Lukasz Luba wrote:
> Devfreq cooling needs to now the correct status of the device in order
> to operate. Do not rely on Devfreq last_status which might be a stale data
> and get more up-to-date values of the load.
>
> Devfreq framework can change the dev
On 10/07/20 08:57, Rob Clark wrote:
> Yeah, I think we will end up making some use of uclamp.. there is
> someone else working on that angle
>
> But without it, this is a case that exposes legit prioritization
> problems with commit_work which we should fix ;-)
I wasn't suggesting this as an alte
Add the helpers and register definitions needed to read out the common
and per-PHY LTTPR capabilities and perform link training in the LTTPR
non-transparent mode.
v2:
- Add drm_dp_dpcd_read_phy_link_status() and DP_PHY_LTTPR() here instead
of adding these to i915. (Ville)
v3:
- Use memmove() to
On Wed, Oct 7, 2020 at 6:53 PM Jason Gunthorpe wrote:
>
> On Wed, Oct 07, 2020 at 06:44:18PM +0200, Daniel Vetter wrote:
> >
> > - /*
> > - * While get_vaddr_frames() could be used for transient (kernel
> > - * controlled lifetime) pinning of memory pages all current
> > - * use
Add the /dev/host1x device node, implementing the following
functionality:
- Reading syncpoint values
- Allocating syncpoints (providing syncpoint FDs)
- Incrementing syncpoints (based on syncpoint FD)
Signed-off-by: Mikko Perttunen
---
v3:
* Pass process name as syncpoint name when allocating
With job recovery becoming optional, syncpoints may have a mismatch
between their value and max value when freed. As such, when freeing,
set the max value to the current value of the syncpoint so that it
is in a sane state for the next user.
Signed-off-by: Mikko Perttunen
---
v3:
* Use host1x_syn
Add a firewall that validates jobs before submission to ensure
they don't do anything they aren't allowed to do, like accessing
memory they should not access.
The firewall is functionality-wise a copy of the firewall already
implemented in gpu/host1x. It is copied here as it makes more
sense for i
Add support for inserting syncpoint waits in the CDMA pushbuffer.
These waits need to be done in HOST1X class, while gather submitted
by the application execute in engine class.
Support is added by converting the gather list of job into a command
list that can include both gathers and waits. When
With the new UAPI implementation, engines are powered on and off
when there are active jobs, and the core code handles channel
allocation. To accommodate that, boot the engine as part of
runtime PM instead of using the open_channel callback, which is
not used by the new submit path.
Signed-off-by:
Hi all,
here's the third revision of the Host1x/TegraDRM UAPI proposal.
The open issues from RFCv2 should be resolved now, so I'm
dropping the RFC tag. The series is still only tested with Tegra186
so I'm hoping for people with devices with other chips to test this
out.
The test suite[1] has been
Make syncpoint expiration checks always use the same logic used by
the hardware. This ensures that there are no race conditions that
could occur because of the hardware triggering a syncpoint interrupt
and then the driver disagreeing.
One situation where this could occur is if a job incremented a
Add reference counting for allocated syncpoints to allow keeping
them allocated while jobs are referencing them. Additionally,
clean up various places using syncpoint IDs to use host1x_syncpt
pointers instead.
Signed-off-by: Mikko Perttunen
---
drivers/gpu/drm/tegra/dc.c | 4 +-
drivers
Syncpoints don't need to be associated with any client,
so remove the property, and expose host1x_syncpt_alloc.
This will allow allocating syncpoints without prior knowledge
of the engine that it will be used with.
Signed-off-by: Mikko Perttunen
---
v3:
* Clean up host1x_syncpt_alloc signature to
To allow sharing of implicit fences when exporting/importing dma_buf
objects, set the 'resv' fields when importing or exporting GEM
objects.
Signed-off-by: Mikko Perttunen
---
drivers/gpu/drm/tegra/gem.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/tegra/gem.c b/drivers/
Add a new property for jobs to enable or disable recovery i.e.
CPU increments of syncpoints to max value on job timeout. This
allows for a more solid model for hanged jobs, where userspace
doesn't need to guess if a syncpoint increment happened because
the job completed, or because job timeout was
To avoid false lockdep warnings, give each client lock a different
lock class, passed from the initialization site by macro.
Signed-off-by: Mikko Perttunen
---
drivers/gpu/host1x/bus.c | 7 ---
include/linux/host1x.h | 9 -
2 files changed, 12 insertions(+), 4 deletions(-)
diff --
Add a callback field to the job structure, to be called just before
the job is to be freed. This allows the job's submitter to clean
up any of its own state, like decrement runtime PM refcounts.
Signed-off-by: Mikko Perttunen
---
drivers/gpu/host1x/job.c | 3 +++
include/linux/host1x.h | 4 +++
Update the tegra_drm.h UAPI header, adding the new proposed UAPI.
The old staging UAPI is left in for now, with minor modification
to avoid name collisions.
Signed-off-by: Mikko Perttunen
---
v3:
* Remove timeout field
* Inline the syncpt_incrs array to the submit structure
* Remove WRITE_RELOC (
To avoid duplication, allocate the per-engine shared channel in the
core code instead. Once MLOCKs are implemented on Host1x side, we
can also update this to avoid allocating a shared channel when
MLOCKs are enabled.
Signed-off-by: Mikko Perttunen
---
drivers/gpu/drm/tegra/drm.c | 11 +++
Implement the new UAPI, and bump the TegraDRM major version.
Signed-off-by: Mikko Perttunen
---
v3:
* Remove WRITE_RELOC. Relocations are now patched implicitly
when patching is needed.
* Directly call PM runtime APIs on devices instead of using
power_on/power_off callbacks.
* Remove incorrec
Add an implementation of dma_fences based on syncpoints. Syncpoint
interrupts are used to signal fences. Additionally, after
software signaling has been enabled, a 30 second timeout is started.
If the syncpoint threshold is not reached within this period,
the fence is signalled with an -ETIMEDOUT e
On T20-T148 chips, the bootloader can set up a boot splash
screen with DC configured to increment syncpoint 26/27
at VBLANK. Because of this we shouldn't allow these syncpoints
to be allocated until DC has been reset and will no longer
increment them in the background.
As such, on these chips, res
Before this patch, cancelled waiters would only be cleaned up
once their threshold value was reached. Make host1x_intr_put_ref
process the cancellation immediately to fix this.
Signed-off-by: Mikko Perttunen
---
drivers/gpu/host1x/intr.c | 14 +-
1 file changed, 9 insertions(+), 5 de
Show the number of pending waiters in the debugfs status file.
This is useful for testing to verify that waiters do not leak
or accumulate incorrectly.
Signed-off-by: Mikko Perttunen
---
drivers/gpu/host1x/debug.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git
Add the userspace interface header, specifying interfaces
for allocating and accessing syncpoints from userspace,
and for creating sync_file based fences based on syncpoint
thresholds.
Signed-off-by: Mikko Perttunen
---
include/uapi/linux/host1x.h | 134
1 fi
On Wed, Oct 7, 2020 at 7:27 PM Jason Gunthorpe wrote:
>
> On Wed, Oct 07, 2020 at 06:44:20PM +0200, Daniel Vetter wrote:
> > 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 the
On Wed, Oct 7, 2020 at 7:36 PM Jason Gunthorpe wrote:
>
> On Wed, Oct 07, 2020 at 06:44:24PM +0200, Daniel Vetter wrote:
> > 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 the
On Wed, Oct 7, 2020 at 7:39 PM Jason Gunthorpe wrote:
>
> On Wed, Oct 07, 2020 at 06:44:26PM +0200, Daniel Vetter wrote:
> > 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 p
Capitalize subject, like other patches in this series and previous
drivers/pci history.
On Wed, Oct 07, 2020 at 06:44:23PM +0200, Daniel Vetter wrote:
> Since 3234ac664a87 ("/dev/mem: Revoke mappings when a driver claims
> the region") /dev/kmem zaps ptes when the kernel requests exclusive
> accce
On Wed, Oct 07, 2020 at 06:44:22PM +0200, Daniel Vetter wrote:
> 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
On Wed, Oct 7, 2020 at 8:41 PM Bjorn Helgaas wrote:
>
> Capitalize subject, like other patches in this series and previous
> drivers/pci history.
>
> On Wed, Oct 07, 2020 at 06:44:23PM +0200, Daniel Vetter wrote:
> > Since 3234ac664a87 ("/dev/mem: Revoke mappings when a driver claims
> > the regio
On Wed, Oct 7, 2020 at 11:11 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 us
1 - 100 of 188 matches
Mail list logo
