On Fri, Oct 30, 2020 at 3:38 PM Daniel Vetter wrote:
>
> 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
VM_IO | VM_PFNMAP mappings and
> >> tell everyone to cut over to dma-buf memory sharing for zerocopy.
> >>
> >> userptr for normal memory will keep working as-is, this only affects
> >> the zerocopy userptr usage enabled in 50ac952d2263 ("[media]
> >&g
t; mmu_notifier, without breaking how this all works. The only real fix
> >>>>>> is to deprecate userptr support for VM_IO | VM_PFNMAP mappings and
> >>>>>> tell everyone to cut over to dma-buf memory sharing for zerocopy.
> >>>>>>
> >>>
On Thu, Apr 18, 2019 at 5:55 PM Paul Kocialkowski
wrote:
>
> Hi Daniel,
>
> On Thu, 2019-04-18 at 10:18 +0200, Daniel Vetter wrote:
> > On Wed, Apr 17, 2019 at 08:10:15PM +0200, Paul Kocialkowski wrote:
> > > Hi Nicolas,
> > >
> > > I'm detaching this thread from our V4L2 stateless decoding spec s
On Thu, Apr 18, 2019 at 6:14 PM Paul Kocialkowski
wrote:
>
> Hi,
>
> On Thu, 2019-04-18 at 18:09 +0900, Tomasz Figa wrote:
> > On Thu, Apr 18, 2019 at 5:55 PM Paul Kocialkowski
> > wrote:
> > > Hi Daniel,
> > >
> > > On Thu, 2019-04-18 at 10:18
On Fri, Apr 19, 2019 at 9:30 AM Nicolas Dufresne wrote:
>
> Le jeudi 18 avril 2019 à 10:18 +0200, Daniel Vetter a écrit :
> > > It would be cool if both could be used concurrently and not just return
> > > -EBUSY when the device is used with the other subsystem.
> >
> > We live in this world alrea
On Sat, Apr 20, 2019 at 12:31 AM Nicolas Dufresne wrote:
>
> Le vendredi 19 avril 2019 à 13:27 +0900, Tomasz Figa a écrit :
> > On Fri, Apr 19, 2019 at 9:30 AM Nicolas Dufresne
> > wrote:
> > > Le jeudi 18 avril 2019 à 10:18 +0200, Daniel Vetter a écrit :
> &g
Hi Helen,
On Fri, Dec 14, 2018 at 10:35 AM Helen Koike wrote:
>
> Hi Tomasz,
>
> On 12/13/18 2:02 AM, Tomasz Figa wrote:
> > On Thu, Dec 6, 2018 at 1:12 AM Helen Koike
> > wrote:
> >>
> >> Hi Ville
> >>
> >> On 11/27/18 11:34 AM, V
On Thu, Dec 20, 2018 at 7:47 PM Daniel Vetter wrote:
>
> On Thu, Dec 20, 2018 at 10:07 AM Tomasz Figa wrote:
> >
> > Hi Helen,
> >
> > On Fri, Dec 14, 2018 at 10:35 AM Helen Koike
> > wrote:
> > >
> > > Hi Tomasz,
> > >
> >
On Wed, Mar 13, 2019 at 12:52 AM Boris Brezillon
wrote:
>
> On Tue, 12 Mar 2019 12:34:45 -0300
> Helen Koike wrote:
>
> > On 3/12/19 3:34 AM, Boris Brezillon wrote:
> > > On Mon, 11 Mar 2019 23:21:59 -0300
> > > Helen Koike wrote:
> > >
> > >> In the case of async update, modifications are done
On Mon, Jun 3, 2019 at 4:40 AM Rob Clark wrote:
>
> On Fri, May 10, 2019 at 7:35 AM Rob Clark wrote:
> >
> > On Tue, Dec 4, 2018 at 2:29 PM Rob Herring wrote:
> > >
> > > On Sat, Dec 1, 2018 at 10:54 AM Rob Clark wrote:
> > > >
> > > > This solves a problem we see with drm/msm, caused by gettin
On Mon, Jun 3, 2019 at 7:48 PM Rob Clark wrote:
>
> On Sun, Jun 2, 2019 at 11:25 PM Tomasz Figa wrote:
> >
> > On Mon, Jun 3, 2019 at 4:40 AM Rob Clark wrote:
> > >
> > > On Fri, May 10, 2019 at 7:35 AM Rob Clark wrote:
> > > >
> >
e, and use said DMA device when importing PRIME buffers.
>
> Signed-off-by: Alexandre Courbot
> ---
> drivers/gpu/drm/mediatek/mtk_drm_drv.c | 47 --
> drivers/gpu/drm/mediatek/mtk_drm_drv.h | 2 ++
> 2 files changed, 46 insertions(+), 3 deletions(-)
&
On Mon, Aug 1, 2022 at 8:43 PM ayaka wrote:
>
>
>
> Sent from my iPad
>
> > On Aug 1, 2022, at 5:46 PM, Tomasz Figa wrote:
> >
> > CAUTION: Email originated externally, do not click links or open
> > attachments unless you recognize the sender and know t
On Tue, Aug 2, 2022 at 9:21 PM ayaka wrote:
>
> Sorry, the previous one contains html data.
>
> > On Aug 2, 2022, at 3:33 PM, Tomasz Figa wrote:
> >
> > On Mon, Aug 1, 2022 at 8:43 PM ayaka wrote:
> >> Sent from my iPad
> >>>> On Aug 1, 2
Hi Randy,
On Tue, Aug 9, 2022 at 1:28 AM Hsia-Jun Li wrote:
>
> From: "Hsia-Jun(Randy) Li"
>
> The most of detail has been written in the drm.
> Please notice that the tiled formats here request
> one more plane for storing the motion vector metadata.
> This buffer won't be compressed, so you ca
Hi Randy,
On Tue, Aug 9, 2022 at 1:28 AM Hsia-Jun Li wrote:
>
> From: "Hsia-Jun(Randy) Li"
>
> Memory Traffic Reduction(MTR) is a module in Synaptics
> VideoSmart platform could process lossless compression image
> and cache the tile memory line.
>
> Those modifiers only record the parameters wo
> > Le vendredi 19 août 2022 à 02:13 +0300, Laurent Pinchart a écrit :
> >> On Thu, Aug 18, 2022 at 02:33:42PM +0800, Hsia-Jun Li wrote:
> >>> On 8/18/22 14:06, Tomasz Figa wrote:
> >>>> On Tue, Aug 9, 2022 at 1:28 AM Hsia-Jun Li
> >>>> w
Hi Randy,
Sorry for the late reply, I went on vacation last week.
On Sun, Aug 7, 2022 at 12:23 AM Hsia-Jun Li wrote:
>
>
>
> On 8/5/22 18:09, Tomasz Figa wrote:
> > CAUTION: Email originated externally, do not click links or open
> > attachments unless you recognize
ux/dma-buf.h | 34 +----
> 21 files changed, 162 insertions(+), 153 deletions(-)
>
For drivers/media/videobu2:
Acked-by: Tomasz Figa
Best regards,
Tomasz
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index 1c912255c5d6..452a6a1f
drivers/gpu/drm/qxl/qxl_prime.c | 4 +-
> drivers/gpu/drm/tegra/gem.c | 27 +--
> drivers/infiniband/core/umem_dmabuf.c | 11 +-
> .../common/videobuf2/videobuf2-dma-contig.c | 26 +--
> .../media/common/videobuf2/videobuf2-dma-sg.c | 23 +-
> .../common/videobuf2/videobuf2-vmalloc.c | 17 +-
For the videobuf2 changes:
Acked-by: Tomasz Figa
Best regards,
Tomasz
Hi Daniel, Gerd,
On Tue, Sep 17, 2019 at 10:23 PM Daniel Vetter wrote:
>
> On Thu, Sep 12, 2019 at 06:41:21PM +0900, Tomasz Figa wrote:
> > This patch is an early RFC to judge the direction we are following in
> > our virtualization efforts in Chrome OS. The purpose is to star
On Tue, Oct 8, 2019 at 7:03 PM Daniel Vetter wrote:
>
> On Sat, Oct 05, 2019 at 02:41:54PM +0900, Tomasz Figa wrote:
> > Hi Daniel, Gerd,
> >
> > On Tue, Sep 17, 2019 at 10:23 PM Daniel Vetter wrote:
> > >
> > > On Thu, Sep 12, 2019 at 06:41:21PM +0900
On Wed, Oct 9, 2019 at 12:04 AM Daniel Vetter wrote:
>
> On Tue, Oct 08, 2019 at 07:49:39PM +0900, Tomasz Figa wrote:
> > On Tue, Oct 8, 2019 at 7:03 PM Daniel Vetter wrote:
> > >
> > > On Sat, Oct 05, 2019 at 02:41:54PM +0900, Tomasz Figa wrote:
> > > &g
On Wed, Oct 16, 2019 at 3:12 PM Gerd Hoffmann wrote:
>
> Hi,
>
> > up later when given a buffer index. But we would still need to make
> > the DMA-buf itself importable. For virtio-gpu I guess that would mean
> > returning an sg_table backed by the shadow buffer pages.
>
> The virtio-gpu driver
On Wed, Oct 16, 2019 at 6:18 PM Daniel Vetter wrote:
>
> On Wed, Oct 16, 2019 at 12:19:02PM +0900, Tomasz Figa wrote:
> > On Wed, Oct 9, 2019 at 12:04 AM Daniel Vetter wrote:
> > >
> > > On Tue, Oct 08, 2019 at 07:49:39PM +0900, Tomasz Figa wrote:
> > >
d
already do the work. For example, a V4L2 driver using the videobuf2
framework would just call thee vb2_dma_contig_plane_dma_addr() function
to get what the above open-coded function would return.
Signed-off-by: Tomasz Figa
---
drivers/gpu/drm/virtio/virtgpu_drv.c | 2 +
drivers/gpu/d
Hi Gerd,
On Thu, Sep 12, 2019 at 9:38 PM Gerd Hoffmann wrote:
>
> Hi,
>
> > To seamlessly enable buffer sharing with drivers using such frameworks,
> > make the virtio-gpu driver expose the resource handle as the DMA address
> > of the buffer returned from the DMA-buf mapping operation. Arguab
On Fri, Sep 13, 2019 at 5:07 PM Gerd Hoffmann wrote:
>
> Hi,
>
> > > > To seamlessly enable buffer sharing with drivers using such frameworks,
> > > > make the virtio-gpu driver expose the resource handle as the DMA address
> > > > of the buffer returned from the DMA-buf mapping operation. Argu
t;
> Suggested-by: Daniel Vetter
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/media/common/videobuf2/videobuf2-dma-contig.c | 3 +++
> drivers/media/common/videobuf2/videobuf2-dma-sg.c | 3 +++
> drivers/media/common/videobuf2/videobuf2-vmalloc.c| 3 +++
> 3 files cha
Hi Christian and everyone,
On Thu, Nov 3, 2022 at 4:14 AM Christian König
wrote:
>
> Am 02.11.22 um 18:10 schrieb Lucas Stach:
> > Am Mittwoch, dem 02.11.2022 um 13:21 +0100 schrieb Christian König:
> > [SNIP]
> >> It would just be doing this for the importer and exactly that
> >> would be bad de
e read-only buffer issue has been resolved, FOLL_WRITE could
> >>> again be set depending on the DMA direction.
> >>>
> >>> Cc: Hans Verkuil
> >>> Cc: Marek Szyprowski
> >>> Cc: Tomasz Figa
> >>> Cc: Marek Szyprowski
>
that case, but I don't know the
background behind it being added here in the first place. +Hans
Verkuil +Marek Szyprowski do you happen to remember anything about it?
Best regards,
Tomasz
>
> FOLL_FORCE in this case seems to be a legacy leftover. Let's just remove
> it.
>
>
Hi Christian,
On Thu, Nov 17, 2022 at 9:11 PM Christian König
wrote:
>
> Hi Tomasz,
>
> Am 17.11.22 um 10:35 schrieb Tomasz Figa:
> > Hi Christian and everyone,
> >
> > On Thu, Nov 3, 2022 at 4:14 AM Christian König
> > wrote:
> >> Am 02.11.22 um
On Mon, Dec 5, 2022 at 5:29 PM Christian König wrote:
>
> Hi Tomasz,
>
> Am 05.12.22 um 07:41 schrieb Tomasz Figa:
> > [SNIP]
> >> In other words explicit ownership transfer is not something we would
> >> want as requirement in the framework, cause otherwise w
On Fri, Dec 9, 2022 at 7:27 PM Christian König wrote:
>
> Am 09.12.22 um 09:26 schrieb Tomasz Figa:
[snip]
> Yes, same what Daniel said as well. We need to provide some more hints
> which allocator to use from the kernel.
>
> >>>>>> So if a device dr
On Fri, Dec 9, 2022 at 6:32 PM Pekka Paalanen wrote:
>
> On Fri, 9 Dec 2022 17:26:06 +0900
> Tomasz Figa wrote:
>
> > On Mon, Dec 5, 2022 at 5:29 PM Christian König
> > wrote:
> > >
> > > Hi Tomasz,
> > >
> > > Am 05.12.22 um 07:41
Hi Hsia-Jun,
On Tue, Aug 22, 2023 at 8:14 PM Hsia-Jun Li wrote:
>
> Hello
>
> I would like to introduce a usage of SHMEM slimier to DMA-buf, the major
> purpose of that is sharing metadata or just a pure container for cross
> drivers.
>
> We need to exchange some sort of metadata between drivers,
On Wed, Aug 23, 2023 at 4:11 PM Hsia-Jun Li wrote:
>
>
>
> On 8/23/23 12:46, Tomasz Figa wrote:
> > CAUTION: Email originated externally, do not click links or open
> > attachments unless you recognize the sender and know the content is safe.
> >
> >
> >
-lpthread is not always a valid flag to pull pthread support, especially
on Android it will fail to link due to a missing libpthread.so. The more
generic way to build-in pthread support is to use the -pthread CFLAG, so
let's use it instead.
Signed-off-by: Tomasz Figa
---
tests/e
Hi Mark,
Thanks for reviving this series and sorry for not taking care of it
myself. Please see some comments inline.
On Tue, Feb 7, 2017 at 3:09 PM, Mark Yao wrote:
> From: Tomasz Figa
>
> The API is not suitable for subsystems consisting of multiple devices
> and requires severe
Hi Mark,
On Tue, Feb 7, 2017 at 9:37 PM, Thierry Reding wrote:
> On Tue, Feb 07, 2017 at 04:39:33PM +0800, Mark Yao wrote:
>> From: Tomasz Figa
>>
>> When converting the driver to use shmem-backed GEMs for IOMMU-enabled
>> systems, we forgot to add calls to drm_gem_o
Hi Zain,
On Mon, Feb 13, 2017 at 6:27 PM, zain wang wrote:
>
> The analogix_dp_transfer() will return -EBUSY if num_transferred is zero.
> But sometimes we will send a bare address packet to start the transaction,
> like drm_dp_i2c_xfer() show:
> ..
> /* Send a bare address pa
On Mon, Feb 20, 2017 at 1:04 PM, Zain Wang wrote:
> 在 2017/2/20 10:40, Tomasz Figa 写道:
>> On Mon, Feb 13, 2017 at 6:27 PM, zain wang wrote:
>>> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
>>> b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
>&g
Hi Sean,
On Fri, Mar 10, 2017 at 1:32 PM, Sean Paul wrote:
>
> From: Tomasz Figa
>
> Since we take the ownership of drvdata, the master driver does not have
> any means of accessing its own data from unbind callback and all it can
> do is calling the analogix unbind callback
Hi Everyone,
On Wed, May 10, 2017 at 9:24 AM, Inki Dae wrote:
>
>
> 2017년 04월 26일 07:21에 Sakari Ailus 이(가) 쓴 글:
>> Hi Marek,
>>
>> On Thu, Apr 20, 2017 at 01:23:09PM +0200, Marek Szyprowski wrote:
>>> Hi Laurent,
>>>
>>> On 2017-04-20 12:25, Laurent Pinchart wrote:
Hi Marek,
(CC'in
On Wed, May 10, 2017 at 2:27 PM, Inki Dae wrote:
> Hi Tomasz,
>
> 2017년 05월 10일 14:38에 Tomasz Figa 이(가) 쓴 글:
>> Hi Everyone,
>>
>> On Wed, May 10, 2017 at 9:24 AM, Inki Dae wrote:
>>>
>>>
>>> 2017년 04월 26일 07:21에 Sakari Ailus 이(가) 쓴 글:
>&
Hi Sakari,
Some comments inline.
On Mon, May 8, 2017 at 11:03 PM, Sakari Ailus
wrote:
> The struct vb2_dc_buf contains two struct sg_table fields: sgt_base and
> dma_sgt. The former is used by DMA-BUF buffers whereas the latter is used
> by USERPTR.
>
> Unify the two, leaving dma_sgt.
>
> MMAP b
Hi Sakari,
Some comments inline.
On Mon, May 8, 2017 at 11:03 PM, Sakari Ailus
wrote:
> Patch ccc66e73 ("ARM: 8508/2: videobuf2-dc: Let drivers specify DMA
> attrs") added support for driver specific DMA attributes to
> videobuf2-dma-contig but it had several issues in it.
>
> In particular,
>
>
Hi Sakari,
Few comments inline.
On Mon, May 8, 2017 at 11:03 PM, Sakari Ailus
wrote:
> From: Samu Onkalo
>
> The user may request to the driver (vb2) to skip the cache maintenance
> operations in case the buffer does not need cache synchronisation, e.g. in
> cases where the buffer is passed bet
-next branch of Sean Paul's dogwood tree:
https://cgit.freedesktop.org/~seanpaul/dogwood/log/?h=for-next
git://people.freedesktop.org/~seanpaul/dogwood
Tomasz Figa (8):
drm/rockchip: Clear interrupt status bits before enabling
drm/rockchip: Get rid of some unnecessary code
drm/rockchip:
interrupt signalled, we have to clear the old bit before we
update the enable register.
Signed-off-by: Tomasz Figa
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
b/drivers/gpu/drm/rockchip
pport unreferencing cursor framebuffers
asynchronously to the commit, which was what the helper expected.
Since both problems have been solved by previous patches, we can now
make the driver use the generic helper and remove custom waiting code.
Signed-off-by: Tomasz Figa
---
drivers/gpu/drm/roc
Current code implements prepare_fb and cleanup_fb callbacks only to
grab/release fb references, which is already done by atomic framework
when creating/destryoing plane state. Let's remove these
unused bits.
Signed-off-by: Tomasz Figa
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c
hould be relatively low and in practice almost equal to the vop
hardirq handler running time.
Signed-off-by: Tomasz Figa
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 34 +
1 file changed, 34 insertions(+)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
b
code to unreference any changed framebuffer from a
flip work.
Signed-off-by: Tomasz Figa
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 41 +
1 file changed, 41 insertions(+)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
b/drivers/gpu/drm/rockchip
("drm/rockchip: Enable
vblank without event").
Signed-off-by: Tomasz Figa
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 15 ---
1 file changed, 4 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
b/drivers/gpu/drm/rockchip/roc
complete FB changes before) and lets us remove the manual window
update check.
Signed-off-by: Tomasz Figa
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 54 ++---
1 file changed, 10 insertions(+), 44 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
b
After changes introduced by last patches, there is no useful data stored
in vop_plane_state struct. Let's remove it and make the driver use
generic plane state alone.
Signed-off-by: Tomasz Figa
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 94 +
1 file ch
rjan Eide
Signed-off-by: Tomasz Figa
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
index b70f942..ca
Hi Mark,
On Sun, Sep 18, 2016 at 10:50 AM, Mark yao wrote:
> On 2016å¹´09æ14æ¥ 20:54, Tomasz Figa wrote:
>>
>> Current code implements prepare_fb and cleanup_fb callbacks only to
>> grab/release fb references, which is already done by atomic framework
>> when crea
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 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 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 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:
> > > >
> &
Hi Daniel,
On Fri, Oct 9, 2020 at 7:52 PM Daniel Vetter wrote:
>
> On Fri, Oct 9, 2020 at 2:48 PM Jason Gunthorpe wrote:
> >
> > On Fri, Oct 09, 2020 at 02:37:23PM +0200, Mauro Carvalho Chehab wrote:
> >
> > > I'm not a mm/ expert, but, from what I understood from Daniel's patch
> > > descriptio
Hi Mauro,
On Fri, Oct 9, 2020 at 2:37 PM Mauro Carvalho Chehab
wrote:
>
> Em Fri, 9 Oct 2020 09:21:11 -0300
> Jason Gunthorpe escreveu:
>
> > On Fri, Oct 09, 2020 at 12:34:21PM +0200, Mauro Carvalho Chehab wrote:
> > > Hi,
> > >
> > > Em Fri, 9 Oct 2020 09:59:26 +0200
> > > Daniel Vetter escre
this is a good first step towards deprecating this legacy
code, so:
Acked-by: Tomasz Figa
Of course the last word goes to Mauro. :)
Best regards,
Tomasz
>
> Signed-off-by: Daniel Vetter
> Cc: Jason Gunthorpe
> Cc: Kees Cook
> Cc: Dan Williams
> Cc: Andrew Morton
> C
t; Reviewed-by: John Hubbard
> Acked-by: Mauro Carvalho Chehab
> Signed-off-by: Daniel Vetter
> Cc: Jason Gunthorpe
> Cc: Pawel Osciak
> Cc: Marek Szyprowski
> Cc: Kyungmin Park
> Cc: Tomasz Figa
> Cc: Mauro Carvalho Chehab
> Cc: Andrew Morton
> Cc: John Hubba
e a lot.
>
> Signed-off-by: Daniel Vetter
> Cc: Jason Gunthorpe
> Cc: Pawel Osciak
> Cc: Marek Szyprowski
> Cc: Kyungmin Park
> Cc: Tomasz Figa
> Cc: Mauro Carvalho Chehab
> Cc: Andrew Morton
> Cc: John Hubbard
> Cc: Jérôme Glisse
> Cc: Jan
t; Signed-off-by: Daniel Vetter
> Cc: Jason Gunthorpe
> Cc: Pawel Osciak
> Cc: Marek Szyprowski
> Cc: Kyungmin Park
> Cc: Tomasz Figa
> Cc: Mauro Carvalho Chehab
> Cc: Andrew Morton
> Cc: John Hubbard
> Cc: Jérôme Glisse
> Cc: Jan Kara
> Cc: Dan Williams
&g
Hi Niklas,
On Fri, May 22, 2020 at 01:52:01AM +0200, Niklas Söderlund wrote:
> Bayer formats are used with cameras and contain green, red and blue
> components, with alternating lines of red and green, and blue and green
> pixels in different orders. For each block of 2x2 pixels there is one
> pix
Hi Hsin-Yi,
On Mon, Jun 22, 2020 at 11:01:09PM +0800, Hsin-Yi Wang wrote:
> Disable the plane if it's not visible. Otherwise mtk_ovl_layer_config()
> would proceed with invalid plane and we may see vblank timeout.
>
> Fixes: 119f5173628a ("drm/mediatek: Add DRM Driver for Mediatek SoC MT8173.")
>
changed, 15 insertions(+), 10 deletions(-)
>
+/- the Change-Id pointed out by Matthias:
Reviewed-by: Tomasz Figa
Best regards,
Tomasz
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
| 6 +-
> include/drm/drm_prime.h | 5 +-
> include/linux/dma-buf-map.h | 193 ++++++
> include/linux/dma-buf.h | 11 +-
> 18 files changed, 372 insertions(+), 94 deletions(-)
> create mode 100644 include
Signed-off-by: Daniel Vetter
> Cc: Inki Dae
> Cc: Joonyoung Shim
> Cc: Seung-Woo Kim
> Cc: Kyungmin Park
> Cc: Kukjin Kim
> Cc: Krzysztof Kozlowski
> Cc: Pawel Osciak
> Cc: Marek Szyprowski
> Cc: Tomasz Figa
> Cc: Andrew Morton
> Cc: Oded Gabbay
> Cc: O
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() function, but now I see that it has been
> > lost in fb639eb39154 and 6690c8c78c74 some time ago...
>
> There is no guarentee that holding a
Hi Marek,
On Fri, Sep 4, 2020 at 3:35 PM Marek Szyprowski
wrote:
>
> Use recently introduced common wrappers operating directly on the struct
> sg_table objects and scatterlist page iterators to make the code a bit
> more compact, robust, easier to follow and copy/paste safe.
>
> No functional ch
On Mon, Sep 7, 2020 at 4:02 PM Marek Szyprowski
wrote:
>
> Hi Tomasz,
>
> On 07.09.2020 15:07, Tomasz Figa wrote:
> > On Fri, Sep 4, 2020 at 3:35 PM Marek Szyprowski
> > wrote:
> >> Use recently introduced common wrappers operating directly on the struct
>
On Thu, Sep 10, 2020 at 11:17 AM Hans Verkuil wrote:
>
> On 04/09/2020 15:17, Marek Szyprowski wrote:
> > Use recently introduced common wrappers operating directly on the struct
> > sg_table objects and scatterlist page iterators to make the code a bit
> > more compact, robust, easier to follow a
On Mon, May 11, 2015 at 7:55 PM, Tomasz Figa wrote:
> VOP can support BGR formats in all windows thanks to red/blue swap option
> provided in WINx_CTRL0 registers. This patch enables support for
> ABGR, XBGR, BGR888 and BGR565 formats by using this feature.
>
> Signed-off-
Hi Mark,
Mark Yao rock-chips.com> writes:
>
> No functional changes, sort the vop registers to make
> code more readable.
I might have found a typo. I guess it could be just fixed in this patch,
if it's already moving the code around. Please see the comments inline.
>
> Signed-off-by: Mark Ya
Hi Mark,
Mark Yao rock-chips.com> writes:
>
> Some new vop register support mask, bit[16-31] is mask,
> bit[0-15] is value, the mask is correspond to the value.
Please see my comments inline.
>
> Signed-off-by: Mark Yao rock-chips.com>
> ---
> drivers/gpu/drm/rockchip/rockchip_drm_vop.c |
Hi Mark,
Mark Yao rock-chips.com> writes:
>
> There are two VOP in rk3399 chip, respectively VOP_BIG and VOP_LIT.
> most registers layout of this two vop is same, their framework are both
> VOP_FULL, the Major differences of this two is that:
Reviewed-by: Tomasz Figa
Best regards,
Tomasz
and little display controllers are not identical and have differing
> +feature sets on the rk3399.
I think this doesn't really need any explanation. If two separate
compatible strings are given, it means that the hardware is different. :)
Other than that,
Reviewed-by: Tomasz Figa
Best regards,
Tomasz
ned-off-by: Shunqian Zheng
> ---
> drivers/iommu/rockchip-iommu.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
Reviewed-by: Tomasz Figa
Best regards,
Tomasz
ned-off-by: Simon Xue
> Signed-off-by: Shunqian Zheng
> ---
> drivers/iommu/rockchip-iommu.c | 1 +
> 1 file changed, 1 insertion(+)
Reviewed-by: Tomasz Figa
Best regards,
Tomasz
Hi,
On Wed, Jun 8, 2016 at 10:26 PM, Shunqian Zheng
wrote:
> An virtual iommu without reg or interrupts for display.
> Adding this according to iommu driver changes.
>
> Signed-off-by: Shunqian Zheng
> ---
> arch/arm/boot/dts/rk3288.dtsi | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff -
Hi,
On Wed, Jun 8, 2016 at 10:26 PM, Shunqian Zheng
wrote:
> An virtual master device like DRM need to attach to iommu
> domain to share the domain with VOP(the one with actual
> iommu slave). We currently check the group is NULL to indicate
> a virtual master, which is not true since we decide
Hi,
On Wed, Jun 8, 2016 at 10:26 PM, Shunqian Zheng
wrote:
> Rockchip DRM used the arm special API, arm_iommu_*(), to attach
> iommu for ARM32 SoCs. This patch convert to common iommu API
> so it would support ARM64 like RK3399.
>
> The general idea is domain_alloc(), attach_device() and
> arch_
64 platform to be used with 64-bit SoCs equipped with this type of
IOMMU."
> Signed-off-by: Simon Xue
> Signed-off-by: Shunqian Zheng
> ---
> drivers/iommu/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
Assuming that the above is fixed:
Reviewed-by: Tomasz Figa
Best regards,
Tomasz
Hi,
On Wed, Jun 8, 2016 at 10:26 PM, Shunqian Zheng
wrote:
> Use DMA API instead of architecture internal functions like
> __cpuc_flush_dcache_area() etc.
>
> To support the virtual device like DRM the virtual slave iommu
> added in the previous patch, attaching to which the DRM can use
> it own
On Mon, Jun 13, 2016 at 6:56 PM, Shunqian Zheng
wrote:
> Hi
>
> On 2016å¹´06æ10æ¥ 17:10, Tomasz Figa wrote:
>>
>> Hi,
>>
>> On Wed, Jun 8, 2016 at 10:26 PM, Shunqian Zheng
>> wrote:
>>>
>>> Use DMA API instead of architecture i
On Mon, Jun 13, 2016 at 7:31 PM, Shunqian Zheng
wrote:
> HI,
>
>
> On 2016å¹´06æ13æ¥ 18:21, Tomasz Figa wrote:
>>
>> On Mon, Jun 13, 2016 at 6:56 PM, Shunqian Zheng
>> wrote:
>>>
>>> Hi
>>>
>>> On 2016å¹´06æ10æ¥ 17:10, Tomas
Hi Yakir,
Yakir Yang rock-chips.com> writes:
> >> Required properties:
> >> -- compatible: "rockchip,rk3288-edp";
> >> +- compatible: "rockchip,rk3288-edp",
> >> + "rockchip,rk3399-edp";
> > As commented by Tomasz on gerrit, there is a pre-existing typo here.
> > Specifically "rockc
Make panel detect to an optional action
> - correct the register bit define error in ANALOGIX_DP_PLL_REG_1
This version looks good to me. For all patches in the series:
Reviewed-by: Tomasz Figa
Best regards,
Tomasz
this patch
> creates a iommu when attaching.
>
> Signed-off-by: Shunqian Zheng
> Suggested-by: Tomasz Figa
To clarify, I don't really like the idea of virtual IOMMU, however it
is registered, dts or manually, but I don't think there is any other
reasonable way of dealin
Hi Shunqian,
On Wed, Jun 15, 2016 at 9:04 PM, Shunqian Zheng
wrote:
> Rockchip DRM used the arm special API, arm_iommu_*(), to attach
> iommu for ARM32 SoCs. This patch convert to common iommu API
> so it would support ARM64 like RK3399.
>
> The general idea is domain_alloc(), attach_device() an
Hi Shunqian,
On Wed, Jun 15, 2016 at 9:04 PM, Shunqian Zheng
wrote:
> Use DMA API instead of architecture internal functions like
> __cpuc_flush_dcache_area() etc.
>
> To support the virtual device like DRM the virtual slave iommu
> added in the previous patch, attaching to which the DRM can use
the, now
unnecessary, call to drm_connector_register_all() from driver code.
Fixes: f706974a69b6 ("drm/rockchip: Drop drm_driver.load/unload callbacks")
Signed-off-by: Tomasz Figa
---
drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 18 +++---
1 file changed, 7 inserti
1 - 100 of 417 matches
Mail list logo
