On Wed, Oct 7, 2020 at 9:00 PM Jason Gunthorpe wrote:
>
> On Wed, Oct 07, 2020 at 08:10:34PM +0200, Daniel Vetter wrote:
> > 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 assump
On Wed, Oct 7, 2020 at 9:33 PM Dan Williams wrote:
>
> 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
On 10/7/20 9:44 AM, Daniel Vetter wrote:
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: Kyungmi
On 10/7/20 9:44 AM, Daniel Vetter wrote:
...
@@ -1414,15 +1410,10 @@ void hl_unpin_host_memory(struct hl_device *hdev,
struct hl_userptr *userptr)
userptr->sgt->nents,
userptr->dir);
On 10/7/20 9:44 AM, Daniel Vetter wrote:
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: K
On 10/7/20 9:44 AM, Daniel Vetter wrote:
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...@list
On 10/7/20 9:44 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 the
On Wed, Oct 7, 2020 at 11:13 PM John Hubbard wrote:
>
> On 10/7/20 9:44 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'
On Wed, Oct 7, 2020 at 10:33 PM John Hubbard wrote:
>
> On 10/7/20 9:44 AM, Daniel Vetter wrote:
> > 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 G
On 10/7/20 2:32 PM, Daniel Vetter wrote:
On Wed, Oct 7, 2020 at 10:33 PM John Hubbard wrote:
On 10/7/20 9:44 AM, Daniel Vetter wrote:
...
@@ -398,15 +399,11 @@ static void g2d_userptr_put_dma_addr(struct g2d_data *g2d,
dma_unmap_sgtable(to_dma_dev(g2d->drm_dev), g2d_userptr->sgt,
On Wed, Oct 7, 2020 at 11:37 PM John Hubbard wrote:
>
> On 10/7/20 2:32 PM, Daniel Vetter wrote:
> > On Wed, Oct 7, 2020 at 10:33 PM John Hubbard wrote:
> >>
> >> On 10/7/20 9:44 AM, Daniel Vetter wrote:
> ...
> >>> @@ -398,15 +399,11 @@ static void g2d_userptr_put_dma_addr(struct
> >>> g2d_data
Hi! I thought this patch rang a bell, we actually already had some discussion
about this since there's a couple of other systems this was causing issues for.
Unfortunately it never seems like that patch got sent out. Satadru?
(if I don't hear back from them soon, I'll just send out a patch for thi
On 10/7/20 9:44 AM, Daniel Vetter wrote:
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
C
On Wed, Oct 7, 2020 at 12:49 PM Daniel Vetter wrote:
>
> On Wed, Oct 7, 2020 at 9:33 PM Dan Williams wrote:
> >
> > 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 whe
Hi Mikko,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on tegra-drm/drm/tegra/for-next]
[also build test ERROR on tegra/for-next linus/master v5.9-rc8 next-20201007]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we
On Wed, Oct 7, 2020 at 3:23 PM Dan Williams wrote:
>
> On Wed, Oct 7, 2020 at 12:49 PM Daniel Vetter wrote:
> >
> > On Wed, Oct 7, 2020 at 9:33 PM Dan Williams
> > wrote:
> > >
> > > On Wed, Oct 7, 2020 at 11:11 AM Daniel Vetter
> > > wrote:
> > > >
> > > > Since 3234ac664a87 ("/dev/mem: Revo
On Wed, 2020-10-07 at 10:27 +0100, Matteo Franchin wrote:
> Add ABGR format with 10-bit components packed in 64-bit per pixel.
> This format can be used to handle
> VK_FORMAT_R10X6G10X6B10X6A10X6_UNORM_4PACK16 on little-endian
> architectures.
trivial note:
> diff --git a/drivers/gpu/drm/drm_four
Hi Mikko,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on tegra-drm/drm/tegra/for-next]
[also build test WARNING on tegra/for-next linus/master v5.9-rc8 next-20201007]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting
On 10/7/20 9:44 AM, 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 their memory nowadays, invalidating
ptes with unmap_mapping_range when buffers get moved
- co
Hi all,
After merging the drm-misc tree, today's linux-next build (x86_64
allmodconfig) failed like this:
I noticed that the ingenic driver revert I had been waiting for appeared
in hte drm-misc tree, so I removed the BROKEN dependency for it, but it
produced the above errors, so I have marked it
> On Oct 5, 2020, at 20:06, Dave Airlie wrote:
>
> From: Dave Airlie
>
> Both fns checked mem == NULL, just move the check outside.
>
> Signed-off-by: Dave Airlie
That’s a nice cleanup.
Reviewed-by: Zack Rusin
___
dri-devel mailing list
dri-deve
> On Oct 5, 2020, at 20:06, Dave Airlie wrote:
>
> From: Dave Airlie
>
> This just copies the fallback to vmwgfx, I'm going to iterate on this
> a bit until it's not the same as the fallback path.
>
> Signed-off-by: Dave Airlie
What are your plans for it? i.e. how is it going to be differe
Hi Mikko,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on tegra-drm/drm/tegra/for-next]
[also build test ERROR on tegra/for-next linus/master v5.9-rc8 next-20201007]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we
Hi Linus,
Karol found two last minute nouveau fixes, they both fix crashes, the
TTM one follows what other drivers do already, and the other is for
bailing on load on unrecognised chipsets.
Thanks,
Dave.
drm-fixes-2020-10-08:
drm nouveau fixes for 5.9 final
nouveau:
- fix crash in TTM alloc fai
On Thu, 8 Oct 2020 at 13:41, Zack Rusin wrote:
>
>
> > On Oct 5, 2020, at 20:06, Dave Airlie wrote:
> >
> > From: Dave Airlie
> >
> > This just copies the fallback to vmwgfx, I'm going to iterate on this
> > a bit until it's not the same as the fallback path.
> >
> > Signed-off-by: Dave Airlie
Hi all,
On Thu, 8 Oct 2020 14:09:03 +1100 Stephen Rothwell
wrote:
>
> After merging the drm-misc tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
In file included from include/linux/clk.h:13,
from drivers/gpu/drm/ingenic/ingenic-drm-drv.c:10:
drivers/gpu
On Mon, Oct 5, 2020 at 6:45 AM Christoph Hellwig wrote:
>
> How is this going to deal with VIVT caches?
Hrm. That's a good question. I'm not sure I totally have my head
around it but, I guess we could make sure to call
invalidate_kernel_vmap_range() in begin_cpu_access() and
flush_kernel_vmap_
Hi guys,
maybe it becomes clearer to understand when you see this as two
different things:
1. The current location where the buffer is.
2. If the data inside the buffer can be accessed.
The current location is returned back by dma_buf_map_attachment() and
the result of it can be used to fill
On Mon, 5 Oct 2020 at 12:38, Rob Herring wrote:
>
> This doesn't yet do anything in the tools, but make it explicit so we can
> check either 'unevaluatedProperties' or 'additionalProperties' is present
> in schemas.
>
> 'unevaluatedProperties' is appropriate when including another schema (via
> '$
Deadline is November 1st, just in a few weeks!
Don't forget to submit your XDC 2021 proposal to bo...@foundation.x.org
.
Sam
On Thu, 2020-09-03 at 12:16 -0400, Lyude Paul wrote:
> (Including a bunch more emails in the To: that got missed the first
> time)
>
> Hello everyone!
>
> The X.org boar
On Mon, 5 Oct 2020 at 20:38, Rob Herring wrote:
>
> This doesn't yet do anything in the tools, but make it explicit so we can
> check either 'unevaluatedProperties' or 'additionalProperties' is present
> in schemas.
>
> 'unevaluatedProperties' is appropriate when including another schema (via
> '$
On Tue, Oct 06, 2020 at 12:41:22PM +0200, Daniel Vetter wrote:
> On Mon, Oct 05, 2020 at 08:56:50PM -0300, Jason Gunthorpe wrote:
> > On Sun, Oct 04, 2020 at 06:43:36PM +0300, Leon Romanovsky wrote:
> > > This series extends __sg_alloc_table_from_pages to allow chaining of
> > > new pages to alread
> On Apr 8, 2020, at 15:23, Jani Nikula wrote:
>
> On Tue, 07 Apr 2020, Kai-Heng Feng wrote:
>> There's another Samsung OLED panel needs to use DPCD aux interface to
>> control backlight.
>
> Acked-by: Jani Nikula
David,
Can you please merge this patch? Thanks.
Kai-Heng
>
>>
>> Signe
From: Takashi Iwai
Current hdac_i915 uses a static completion instance to wait
for i915 driver to complete the component bind.
This design is not safe if multiple HDA controllers are active and
communicating with different i915 instances, and can lead to list
corruption and failed audio driver p
On Mon, 5 Oct 2020 20:40:12 Rob Clark wrote:
> On Mon, Oct 5, 2020 at 5:44 PM Hillf Danton wrote:
> > On Mon, 5 Oct 2020 18:17:01 Kristian H. Kristensen wrote:
> > > On Mon, Oct 5, 2020 at 4:02 PM Daniel Vetter wrote:
> > > >
> > > > On Mon, Oct 05, 2020 at 05:24:19PM +0800, Hillf Danton wrote
On Mon, 5 Oct 2020 at 20:38, Rob Herring wrote:
>
> In order to add meta-schema checks for additional/unevaluatedProperties
> being present, all schema need to make this explicit. As common/shared
> schema are included by other schemas, they should always allow for
> additionalProperties.
>
> Sign
On Mon, Oct 05, 2020 at 01:38:30PM -0500, Rob Herring wrote:
> In order to add meta-schema checks for additional/unevaluatedProperties
> being present, all schema need to make this explicit. As common/shared
> schema are included by other schemas, they should always allow for
> additionalProperties
From: Yongqiang Niu
MMSYS is the driver which controls the routing of these DDP components,
so the definition of the mtk_ddp_comp_id enum should be placed in mtk-mmsys.h
Signed-off-by: Yongqiang Niu
Reviewed-by: Chun-Kuang Hu
Signed-off-by: Enric Balletbo i Serra
---
This patch was previously
HP DreamColor panel, which is used by new HP ZBook Studio, needs to use
DPCD to control brightness.
Signed-off-by: Kai-Heng Feng
---
drivers/gpu/drm/drm_dp_helper.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 092c8c9
On Tue, Oct 06, 2020 at 08:35:08PM +1100, Stephen Rothwell wrote:
> Hi all,
>
> After merging the hmm tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
>
>
> Caused by commit
>
> 07da1223ec93 ("lib/scatterlist: Add support in dynamic allocation of SG
> table from pa
On Tue, Oct 06, 2020 at 08:23:23AM +0200, Daniel Vetter wrote:
> On Tue, Oct 6, 2020 at 1:41 AM Jason Gunthorpe wrote:
> >
> > On Tue, Oct 06, 2020 at 12:43:31AM +0200, Daniel Vetter wrote:
> >
> > > > iow I think I can outright delete the frame vector stuff.
> > >
> > > Ok this doesn't work, beca
On Tue, Oct 06, 2020 at 07:24:30PM +0200, Daniel Vetter wrote:
> On Tue, Oct 6, 2020 at 6:34 PM Daniel Vetter wrote:
> >
> > On Tue, Oct 06, 2020 at 12:49:56PM -0300, Jason Gunthorpe wrote:
> > > On Tue, Oct 06, 2020 at 11:22:14AM +0200, Daniel Vetter wrote:
> > > >
> > > > For reinstanting the pa
Dear all,
The following series are intended to prepare the mtk-mmsys driver to
allow different DDP (Data Display Path) routing tables per SoC. Note
that the series has been tested only on MT8173 platform and could break
the display on MT2701 and MT2712 based devices. I kindly ask for someone
havin
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 Vasut
>> Cc: Fabio Estevam
>> Cc: Guido Günther
>> Cc: Lucas Stach
>> Cc: NXP Linux Team
>> Cc: Rob Herring
>> Cc: Shawn Guo
>> -
On 10/5/20 11:38 AM, Rob Herring wrote:
> This doesn't yet do anything in the tools, but make it explicit so we can
> check either 'unevaluatedProperties' or 'additionalProperties' is present
> in schemas.
>
> 'unevaluatedProperties' is appropriate when including another schema (via
> '$ref') and
On Mon, 5 Oct 2020 13:38:30 -0500
Rob Herring wrote:
> In order to add meta-schema checks for additional/unevaluatedProperties
> being present, all schema need to make this explicit. As common/shared
> schema are included by other schemas, they should always allow for
> additionalProperties.
>
>
On Mon, Oct 05, 2020 at 08:36:00PM -0700, Andrew Morton wrote:
> On Mon, 5 Oct 2020 14:47:47 -0300 Jason Gunthorpe wrote:
>
> > Andrew please let me know if you need a resend
>
> Andrew is rather confused.
>
> Can we please identify the minimal patch(es) which are needed for 5.9
> and -stable?
On Tue, Oct 06, 2020 at 11:22:14AM +0200, Daniel Vetter wrote:
>
> For reinstanting the pages you need:
>
> - dma_resv_lock, this prevents anyone else from issuing new moves or
> anything like that
> - dma_resv_get_excl + dma_fence_wait to wait for any pending moves to
> finish. gpus generall
On Mon, 5 Oct 2020 13:38:28 -0500
Rob Herring wrote:
> In cases where we don't reference another schema, 'additionalProperties'
> can be used instead. This is preferred for now as 'unevaluatedProperties'
> support isn't implemented yet.
>
> In a few cases, this means adding some missing property
Hi Dave,
On Fri, Oct 02, 2020 at 04:57:05PM +0100, Dave Stevenson wrote:
> Hi Maxime
>
> On Fri, 2 Oct 2020 at 16:19, Maxime Ripard wrote:
> >
> > Hi Tim,
> >
> > On Thu, Oct 01, 2020 at 11:15:46AM +0100, Tim Gover wrote:
> > > hdmi_enable_4k60=1 causes the firmware to select 3.3 GHz for the PLL
Quoting Rajendra Nayak (2020-10-06 00:31:41)
>
> On 10/4/2020 3:56 AM, Kuogee Hsieh wrote:
> > Set link rate by using OPP set rate api so that CX level will be set
> > accordingly based on the link rate.
> >
> > Changes in v2:
> > -- remove dev from dp_ctrl_put() parameters
> > -- address review
On 10/5/20 11:38 AM, Rob Herring wrote:
> In cases where we don't reference another schema, 'additionalProperties'
> can be used instead. This is preferred for now as 'unevaluatedProperties'
> support isn't implemented yet.
>
> In a few cases, this means adding some missing property definitions of
On 10/6/20 3:23 AM, Christoph Hellwig wrote:
On Mon, Oct 05, 2020 at 10:35:43AM -0400, Jonathan Marek wrote:
The cache synchronization doesn't have anything to do with IOMMU (for
example: cache synchronization would be useful in cases where drm/msm
doesn't use IOMMU).
It has to do with doing D
HP DreamColor panel needs to be controlled via AUX interface. However,
it has both DP_EDP_BACKLIGHT_BRIGHTNESS_AUX_SET_CAP and
DP_EDP_BACKLIGHT_BRIGHTNESS_PWM_PIN_CAP set, so it fails to pass
intel_dp_aux_display_control_capable() test.
Skip the test if the panel has force DPCD quirk.
Signed-off-
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 guarantees for some tasks and
> > prevent cross-talking.
>
> There is some cgroup stuff that is pinning SF and some other stuf
> On Apr 8, 2020, at 15:22, Jani Nikula wrote:
>
> On Tue, 07 Apr 2020, Kai-Heng Feng wrote:
>>> On Mar 27, 2020, at 19:03, Kai-Heng Feng
>>> wrote:
>>>
>>> Hi,
>>>
On Mar 23, 2020, at 13:35, Kai-Heng Feng
wrote:
There's another OLED panel needs to use DPCD aux inte
On Mon, Oct 05, 2020 at 01:38:27PM -0500, Rob Herring wrote:
> This doesn't yet do anything in the tools, but make it explicit so we can
> check either 'unevaluatedProperties' or 'additionalProperties' is present
> in schemas.
>
> 'unevaluatedProperties' is appropriate when including another schem
On 10/5/20 11:38 AM, Rob Herring wrote:
> In order to add meta-schema checks for additional/unevaluatedProperties
> being present, all schema need to make this explicit. As common/shared
> schema are included by other schemas, they should always allow for
> additionalProperties.
>
> Signed-off-by:
Hello,
syzbot found the following issue on:
HEAD commit:22fbc037 Merge tag 'for-linus' of git://git.kernel.org/pub..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=133731eb90
kernel config: https://syzkaller.appspot.com/x/.config?x=4e672827d2ffab1f
das
On Tue, Oct 06, 2020 at 08:17:05PM +0200, Daniel Vetter wrote:
> So on the gpu we pipeline this all. So step 4 doesn't happen on the
> cpu, but instead we queue up a bunch of command buffers so that the
> gpu writes these pagetables (and the flushes tlbs and then does the
> actual stuff userspace
https://bugzilla.kernel.org/show_bug.cgi?id=208981
Tino Mettler (tino+ker...@tikei.de) changed:
What|Removed |Added
CC||tino+ker...@tikei.de
Am 05.10.20 um 17:05 schrieb Ruhl, Michael J:
-Original Message-
From: dri-devel On Behalf Of
Christian König
Sent: Thursday, October 1, 2020 7:28 AM
To: dri-devel@lists.freedesktop.org; ray.hu...@amd.com;
airl...@gmail.com; dan...@ffwll.ch
Subject: [PATCH 4/8] drm/ttm: rename TTM cachin
On Wed, Oct 7, 2020 at 9:22 AM Jason Gunthorpe wrote:
> On Tue, Oct 06, 2020 at 12:41:22PM +0200, Daniel Vetter wrote:
> > On Mon, Oct 05, 2020 at 08:56:50PM -0300, Jason Gunthorpe wrote:
> > > On Sun, Oct 04, 2020 at 06:43:36PM +0300, Leon Romanovsky wrote:
> > > > This series extends __sg_alloc_
Am 05.10.20 um 17:01 schrieb Ruhl, Michael J:
-Original Message-
From: dri-devel On Behalf Of
Christian König
Sent: Thursday, October 1, 2020 7:28 AM
To: dri-devel@lists.freedesktop.org; ray.hu...@amd.com;
airl...@gmail.com; dan...@ffwll.ch
Subject: [PATCH 2/8] drm/ttm: move ttm_set_memo
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
> > + - fsl,imx8mq-lcdif
>
> There is no fsl,im
That was missed during the cleanup.
Signed-off-by: Christian König
---
include/drm/ttm/ttm_bo_driver.h | 9 -
1 file changed, 9 deletions(-)
diff --git a/include/drm/ttm/ttm_bo_driver.h b/include/drm/ttm/ttm_bo_driver.h
index 9897a16c0a9d..b58dedce7079 100644
--- a/include/drm/ttm/ttm_b
Am 05.10.20 um 17:39 schrieb Ruhl, Michael J:
-Original Message-
From: dri-devel On Behalf Of
Christian König
Sent: Thursday, October 1, 2020 7:28 AM
To: dri-devel@lists.freedesktop.org; ray.hu...@amd.com;
airl...@gmail.com; dan...@ffwll.ch
Subject: [PATCH 6/8] drm/ttm: add caching state
Hi Clément,
Have just noticed that my Pine H64 board hangs when I try to set the
performance governor for the GPU devfreq.
Is this a known bug?
Thanks,
Tomeu
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mail
Am 05.10.20 um 17:51 schrieb Ruhl, Michael J:
-Original Message-
From: dri-devel On Behalf Of
Christian König
Sent: Thursday, October 1, 2020 7:28 AM
To: dri-devel@lists.freedesktop.org; ray.hu...@amd.com;
airl...@gmail.com; dan...@ffwll.ch
Subject: [PATCH 7/8] drm/ttm: use caching inste
Am 05.10.20 um 18:17 schrieb Ruhl, Michael J:
-Original Message-
From: dri-devel On Behalf Of
Christian König
Sent: Thursday, October 1, 2020 7:28 AM
To: dri-devel@lists.freedesktop.org; ray.hu...@amd.com;
airl...@gmail.com; dan...@ffwll.ch
Subject: [PATCH 8/8] drm/ttm: nuke caching plac
Add ABGR format with 10-bit components packed in 64-bit per pixel.
This format can be used to handle
VK_FORMAT_R10X6G10X6B10X6A10X6_UNORM_4PACK16 on little-endian
architectures.
Signed-off-by: Matteo Franchin
---
drivers/gpu/drm/drm_fourcc.c | 1 +
include/uapi/drm/drm_fourcc.h | 7 +++
2 f
Recently we came across requirement to identify EHL and JSL
platform to program them differently. Thus Split the basic
platform definition, macros, and PCI IDs to differentiate
between EHL and JSL platforms. Also, IS_ELKHARTLAKE is replaced
with IS_JSL_EHL everywhere.
Cc : Matt Roper
Cc : Ville S
On 07/10/2020 10:36, Tejas Upadhyay wrote:
Recently we came across requirement to identify EHL and JSL
platform to program them differently. Thus Split the basic
platform definition, macros, and PCI IDs to differentiate
between EHL and JSL platforms. Also, IS_ELKHARTLAKE is replaced
with IS_JSL_
On Wed, Oct 7, 2020 at 11:29 AM Matteo Franchin wrote:
>
> Add ABGR format with 10-bit components packed in 64-bit per pixel.
> This format can be used to handle
> VK_FORMAT_R10X6G10X6B10X6A10X6_UNORM_4PACK16 on little-endian
> architectures.
>
> Signed-off-by: Matteo Franchin
So is this essenti
On Wed, Oct 07, 2020 at 10:27:25AM +0100, Matteo Franchin wrote:
> Add ABGR format with 10-bit components packed in 64-bit per pixel.
> This format can be used to handle
> VK_FORMAT_R10X6G10X6B10X6A10X6_UNORM_4PACK16 on little-endian
> architectures.
>
> Signed-off-by: Matteo Franchin
> ---
> dr
Hi Daniel,
On 03.10.2020 11:40, Daniel Vetter wrote:
>> After he three places above should use pin_user_pages_fast(), then
>> this whole broken API should be moved into videobuf2-memops.c and a
>> big fat "THIS DOESN'T WORK" stuck on it.
>>
>> videobuf2 should probably use P2P DMA buf for this ins
Hi Daniel,
On Wed, Oct 07, 2020 at 12:06:34PM +0200, Daniel Vetter wrote:
> On Wed, Oct 7, 2020 at 11:29 AM Matteo Franchin
> wrote:
> >
> > Add ABGR format with 10-bit components packed in 64-bit per pixel.
> > This format can be used to handle
> > VK_FORMAT_R10X6G10X6B10X6A10X6_UNORM_4PACK16 o
Hi Ville,
On Wed, Oct 07, 2020 at 01:35:39PM +0300, Ville Syrj�l� wrote:
> On Wed, Oct 07, 2020 at 10:27:25AM +0100, Matteo Franchin wrote:
> > Add ABGR format with 10-bit components packed in 64-bit per pixel.
> > This format can be used to handle
> > VK_FORMAT_R10X6G10X6B10X6A10X6_UNORM_4PAC
From: Benjamin Li
Take advantage of previously-added support for persisting PLL
registers across DSI PHY disable/enable cycles (see 328e1a6
'drm/msm/dsi: Save/Restore PLL status across PHY reset') to
support persisting across the very first DSI PHY enable at
boot.
The bootloader may have left th
>-Original Message-
>From: Christian König
>Sent: Wednesday, October 7, 2020 4:52 AM
>To: dri-devel@lists.freedesktop.org; airl...@gmail.com;
>ray.hu...@amd.com; Ruhl, Michael J
>Subject: [PATCH] drm/ttm: remove ttm_bo_unmap_virtual_locked
>declaration
>
>That was missed during the cleanu
Am 07.10.20 um 13:43 schrieb Ruhl, Michael J:
-Original Message-
From: Christian König
Sent: Wednesday, October 7, 2020 4:52 AM
To: dri-devel@lists.freedesktop.org; airl...@gmail.com;
ray.hu...@amd.com; Ruhl, Michael J
Subject: [PATCH] drm/ttm: remove ttm_bo_unmap_virtual_locked
declara
>-Original Message-
>From: Christian König
>Sent: Wednesday, October 7, 2020 4:31 AM
>To: Ruhl, Michael J ; dri-
>de...@lists.freedesktop.org; ray.hu...@amd.com; airl...@gmail.com;
>dan...@ffwll.ch
>Subject: Re: [PATCH 2/8] drm/ttm: move ttm_set_memory.h out of include
>
>Am 05.10.20 um 17
On Wed, Oct 7, 2020 at 12:47 PM Marek Szyprowski
wrote:
>
> Hi Daniel,
>
> On 03.10.2020 11:40, Daniel Vetter wrote:
> >> After he three places above should use pin_user_pages_fast(), then
> >> this whole broken API should be moved into videobuf2-memops.c and a
> >> big fat "THIS DOESN'T WORK" stu
Am 07.10.20 um 13:46 schrieb Ruhl, Michael J:
-Original Message-
From: Christian König
Sent: Wednesday, October 7, 2020 4:31 AM
To: Ruhl, Michael J ; dri-
de...@lists.freedesktop.org; ray.hu...@amd.com; airl...@gmail.com;
dan...@ffwll.ch
Subject: Re: [PATCH 2/8] drm/ttm: move ttm_set_mem
Hi Daniel,
On 07.10.2020 14:01, Daniel Vetter wrote:
> On Wed, Oct 7, 2020 at 12:47 PM Marek Szyprowski
> wrote:
>> On 03.10.2020 11:40, Daniel Vetter wrote:
After he three places above should use pin_user_pages_fast(), then
this whole broken API should be moved into videobuf2-memops.c
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
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 Wed, Sep 30, 2020 at 10:34:31AM +0200, Christian König 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() function, but now I see that it has been
> > > lost in fb639eb39154 and 6690c8c
101 - 188 of 188 matches
Mail list logo
