On 22/09/2020 07:22, Christoph Hellwig wrote:
On Mon, Sep 21, 2020 at 08:11:57PM +0100, Matthew Wilcox wrote:
This is awkward. I'd like it if we had a vfree() variant which called
put_page() instead of __free_pages(). I'd like it even more if we
used release_pages() instead of our own loop t
From: Leon Romanovsky
Changelog:
v3:
* Squashed Christopher's suggestion to avoid introduced new API, but extend
existing one.
v2: https://lore.kernel.org/linux-rdma/20200916140726.839377-1-l...@kernel.org
* Fixed indentations and comments
* Deleted sg_alloc_next()
* Squashed lib/scatterlist
From: Maor Gottlieb
Extend __sg_alloc_table_from_pages to support dynamic allocation of
SG table from pages. It should be used by drivers that can't supply
all the pages at one time.
This function returns the last populated SGE in the table. Users should
pass it as an argument to the function fr
On 17/09/2020 19:59, Thomas Hellström (Intel) wrote:
From: Thomas Hellström
With the huge number of sites where multiple-object locking is
needed in the driver, it becomes difficult to avoid recursive
ww_acquire_ctx initialization, and the function prototypes become
bloated passing the ww_acqu
On Mon, Sep 21, 2020 at 02:01:25PM -0700, Navare, Manasi wrote:
> On Mon, Sep 14, 2020 at 09:52:57PM +0300, Ville Syrjälä wrote:
> > On Mon, Sep 14, 2020 at 11:32:48AM -0700, Navare, Manasi wrote:
> > > On Mon, Sep 07, 2020 at 03:35:23PM +0300, Ville Syrjälä wrote:
> > > > On Thu, Sep 03, 2020 at 0
On Mon, Sep 21, 2020 at 02:18:33PM -0700, Navare, Manasi wrote:
> On Mon, Sep 14, 2020 at 12:21:26PM -0700, Navare, Manasi wrote:
> > On Thu, Sep 03, 2020 at 10:23:35PM +0300, Ville Syrjälä wrote:
> > > On Wed, Jul 15, 2020 at 03:42:21PM -0700, Manasi Navare wrote:
> > > > From: Maarten Lankhorst
On Tue, Sep 22, 2020 at 08:22:49AM +0200, Christoph Hellwig wrote:
> On Mon, Sep 21, 2020 at 08:11:57PM +0100, Matthew Wilcox wrote:
> > This is awkward. I'd like it if we had a vfree() variant which called
> > put_page() instead of __free_pages(). I'd like it even more if we
> > used release_pag
Hi,
Here's the patch which introduces GVT-g ww lock support against
drm-intel-gt-next branch.
Thanks
--
The following changes since commit 4316b19dee27cc5cd34a95fdbc0a3a5237507701:
drm/i915: Fix uninitialised variable in intel_context_create_request.
(2020-09-21 11:09:46 +0200)
are av
Add the drm-core helpers and register definitions required to detect
LTTPRs and perform the link training in non-transparent mode. In i915
switch to non-transparent link training mode if any LTTPR is detected.
Cc: dri-de...@lists.freedesktop.org
Imre Deak (7):
drm/i915: Fix DP link training pat
To prepare for a follow-up LTTPR change factor out a helper to disable
the training pattern in DPCD. We'll need to do this for each LTTPR
(without programming the port to output the idle pattern) when training
in LTTPR non-transparent mode.
Signed-off-by: Imre Deak
---
.../drm/i915/display/intel
The link status is used to communicate the parameters of the link
training with the DPRX and determine if the link training is successful
or a retraining is needed. Accordingly move the function to read the
link status to intel_dp_link_training.c
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915
An LTTPR can be trained with training pattern 4 even if the DPCD
revision is < 1.4, but drm_dp_training_pattern_mask() would change
pattern 4 to pattern 3 on those DPCD revisions.
Since intel_dp_training_pattern() makes already sure that the proper
training pattern is used, all that needs to be ma
Split the prepare, link training, fallback-handling steps into their own
functions for clarity and as a preparation for the upcoming LTTPR changes.
While at it also add some documentation to exported functions.
Signed-off-by: Imre Deak
---
.../drm/i915/display/intel_dp_link_training.c | 80
By default LTTPRs should be in transparent link training mode,
nevertheless in this patch we switch to this default mode explicitly.
The DP Standard recommends this, supposedly because an LTTPR may be left
in the non-transparent mode (by BIOS, previous kernel, or after reset
due to a firmware bug)
The DP Standard's recommendation is to use the LTTPR non-transparent
mode link training if LTTPRs are detected, so let's do this.
Besides power-saving, the advantages of this are that the maximum number
of LTTPRs can only be used in non-transparent mode (the limit is 5-8 in
transparent mode), and
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.
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Imre Deak
---
drivers/gpu/drm/drm_dp_helper.c | 179 ++
== Series Details ==
Series: drm/i915: Add support for LTTPR non-transparent link training mode
URL : https://patchwork.freedesktop.org/series/81968/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
154fc7783917 drm/i915: Fix DP link training pattern mask
b688f7336e26 drm/i915: Mo
== Series Details ==
Series: drm/i915: Add support for LTTPR non-transparent link training mode
URL : https://patchwork.freedesktop.org/series/81968/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
On Tue, Sep 22, 2020 at 03:51:00PM +0300, Imre Deak wrote:
> An LTTPR can be trained with training pattern 4 even if the DPCD
> revision is < 1.4, but drm_dp_training_pattern_mask() would change
> pattern 4 to pattern 3 on those DPCD revisions.
>
> Since intel_dp_training_pattern() makes already s
On Tue, Sep 22, 2020 at 03:51:01PM +0300, Imre Deak wrote:
> The link status is used to communicate the parameters of the link
> training with the DPRX and determine if the link training is successful
> or a retraining is needed. Accordingly move the function to read the
> link status to intel_dp_l
== Series Details ==
Series: drm/i915: Add support for LTTPR non-transparent link training mode
URL : https://patchwork.freedesktop.org/series/81968/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9033 -> Patchwork_18544
Sum
On Tue, Sep 22, 2020 at 03:51:02PM +0300, Imre Deak wrote:
> Split the prepare, link training, fallback-handling steps into their own
> functions for clarity and as a preparation for the upcoming LTTPR changes.
>
> While at it also add some documentation to exported functions.
>
> Signed-off-by:
On 9/22/20 11:12 AM, Tvrtko Ursulin wrote:
On 17/09/2020 19:59, Thomas Hellström (Intel) wrote:
From: Thomas Hellström
With the huge number of sites where multiple-object locking is
needed in the driver, it becomes difficult to avoid recursive
ww_acquire_ctx initialization, and the function
On Fri, Jan 31, 2020 at 07:34:00AM +, Daniel Stone wrote:
> On Thu, 5 Jul 2018 at 11:21, Daniel Vetter wrote:
> > When doing an atomic modeset with ALLOW_MODESET drivers are allowed to
> > pull in arbitrary other resources, including CRTCs (e.g. when
> > reconfiguring global resources).
> >
>
On Mon, Sep 21, 2020 at 6:35 PM Lyude Paul wrote:
>
> So if I understand this correctly, it sounds like that some Pixelbooks boot up
> with DP_EDP_BACKLIGHT_BRIGHTNESS_MSB set to a non-zero value, without the
> panel actually having DPCD backlight controls enabled?
It boots with DP_EDP_BACKLIGHT_
We need details about enabling TE on which port
before we enable TE through vblank enable path.
This is based on the configuration that we receive
from the VBT wrt ports, dual_link.
Signed-off-by: Vandita Kulkarni
Reviewed-by: Jani Nikula
---
drivers/gpu/drm/i915/display/icl_dsi.c | 30
In case of dual link, we get the TE on slave.
So clear the TE on slave DSI IIR.
If we are operating in TE_GATE mode, after we do
a frame update, the transcoder will send the frame data
to the panel, after it receives a TE. Whereas if we
are operating in NO_GATE mode then the transcoder will
immedi
This series contain interrupt handling part of cmd mode.
Configuration patches were merged already.
v10: Address the review comments on patch 3 and 4
v11: fix compilation issue introduced in v10
v12: fix check patch errors on patch 3
v13: Use sw vblank counter (Ville)
Vandita Kulkarni (5):
drm/
In TE Gate mode or TE NO_GATE mode on every flip
we need to set the frame update request bit.
After this bit is set transcoder hardware will
automatically send the frame data to the panel
in case of TE NO_GATE mode, where it sends after
it receives the TE event in case of TE_GATE mode.
Once the fr
Configure TE interrupt as part of the vblank
enable call flow.
v2: Hide the private flags check inside configure_te (Jani)
v3: Fix the position of masking de_port_masked for DSI_TE.
v4: Simplify the caller of configure_te (Jani)
v5: Clear IIR, remove the usage of private_flags
v6: including ic
In case of DSI cmd mode, we get hw vblank counter
updated after the TE comes in, if we try to read
the hw vblank counter in te handler we wouldnt have
the udpated vblank counter yet.
This will lead to a state where we would send the
vblank event to the user space in the next te,
though the frame up
On Tue, Sep 22, 2020 at 3:36 PM Marius Vlad wrote:
>
> On Fri, Jan 31, 2020 at 07:34:00AM +, Daniel Stone wrote:
> > On Thu, 5 Jul 2018 at 11:21, Daniel Vetter wrote:
> > > When doing an atomic modeset with ALLOW_MODESET drivers are allowed to
> > > pull in arbitrary other resources, includin
On 2020-09-18 21:47, Logan Gunthorpe wrote:
Hi Lu,
On 2020-09-11 9:21 p.m., Lu Baolu wrote:
Tom Murphy has almost done all the work. His latest patch series was
posted here.
https://lore.kernel.org/linux-iommu/20200903201839.7327-1-murph...@tcd.ie/
Thanks a lot!
This series is a follow-up wi
On 2020-09-15 09:31, Tvrtko Ursulin wrote:
On 15/09/2020 02:47, Lu Baolu wrote:
Hi Tvrtko,
On 9/14/20 4:04 PM, Tvrtko Ursulin wrote:
Hi,
On 12/09/2020 04:21, Lu Baolu wrote:
Tom Murphy has almost done all the work. His latest patch series was
posted here.
https://lore.kernel.org/linux-iom
On 9/18/20 12:37 PM, Christoph Hellwig wrote:
>
> +static int gnttab_apply(pte_t *pte, unsigned long addr, void *data)
> +{
> + pte_t ***p = data;
> +
> + **p = pte;
> + (*p)++;
> + return 0;
> +}
> +
> static int arch_gnttab_valloc(struct gnttab_vm_area *area, unsigned
> nr_fr
Simplify the return expression.
Signed-off-by: Qinglang Miao
---
drivers/gpu/drm/i915/i915_drv.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index acc32066c..a594bb4aa 100644
--- a/drivers/gpu/drm/i91
On Mon, 21 Sep 2020 10:03:32 +0200
Samuel Iglesias Gonsálvez wrote:
> Hi all,
>
> Huge thanks again to the entire team from Intel, for their great work
> organizing XDC 2020, our first virtual conference!
>
> As usual we're looking for feedback on both XDC itself, and the CFP
> process and prog
On Tue, 22 Sep 2020 at 15:04, Daniel Vetter wrote:
> On Tue, Sep 22, 2020 at 3:36 PM Marius Vlad wrote:
> > Gentle ping. I've tried out Linus's master tree and, and like Pekka,
> > I've noticed this isn't integrated/added.
>
> Defacto the uapi we have now is that userspace needs to ignore "spurio
== Series Details ==
Series: Add support for mipi dsi cmd mode (rev13)
URL : https://patchwork.freedesktop.org/series/69290/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9034 -> Patchwork_18545
Summary
---
**SUCCESS
On Tue, Sep 22, 2020 at 09:23:59AM +0100, Tvrtko Ursulin wrote:
> If I understood this sub-thread correctly, iterating and freeing the pages
> via the vmapped ptes, so no need for a
> shmem_read_mapping_page_gfp loop in shmem_unpin_map looks plausible to me.
>
> I did not get the reference to kern
On Tue, Sep 22, 2020 at 12:21:44PM +0100, Matthew Wilcox wrote:
> Actually, vfree() will work today; I cc'd you on a documentation update
> to make it clear that this is permitted.
vfree calls __free_pages, the i915 and a lot of other code calls
put_page. They are mostly the same, but not quite a
On Tue, Sep 22, 2020 at 04:13:23PM +0300, Ville Syrjälä wrote:
> On Tue, Sep 22, 2020 at 03:51:00PM +0300, Imre Deak wrote:
> > An LTTPR can be trained with training pattern 4 even if the DPCD
> > revision is < 1.4, but drm_dp_training_pattern_mask() would change
> > pattern 4 to pattern 3 on those
== Series Details ==
Series: series starting with [1/6] zsmalloc: switch from alloc_vm_area to
get_vm_area (rev4)
URL : https://patchwork.freedesktop.org/series/81855/
State : failure
== Summary ==
Applying: zsmalloc: switch from alloc_vm_area to get_vm_area
error: sha1 information is lacking
== Series Details ==
Series: drm/i915: simplify the return expression of i915_driver_release()
URL : https://patchwork.freedesktop.org/series/81977/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9034 -> Patchwork_18546
Summ
On Tue, Sep 22, 2020 at 04:14:24PM +0300, Ville Syrjälä wrote:
> On Tue, Sep 22, 2020 at 03:51:01PM +0300, Imre Deak wrote:
> > The link status is used to communicate the parameters of the link
> > training with the DPRX and determine if the link training is successful
> > or a retraining is needed
On Tue, Sep 22, 2020 at 04:39:06PM +0200, Christoph Hellwig wrote:
> On Tue, Sep 22, 2020 at 12:21:44PM +0100, Matthew Wilcox wrote:
> > Actually, vfree() will work today; I cc'd you on a documentation update
> > to make it clear that this is permitted.
>
> vfree calls __free_pages, the i915 and a
On Mon, Sep 21, 2020 at 04:44:10PM -0400, boris.ostrov...@oracle.com wrote:
> This will end up incrementing area->ptes pointer. So perhaps something like
>
>
> pte_t **ptes = area->ptes;
>
> if (apply_to_page_range(&init_mm, (unsigned long)area->area->addr,
> PAGE_SIZE *
== Series Details ==
Series: series starting with [1/6] zsmalloc: switch from alloc_vm_area to
get_vm_area (rev5)
URL : https://patchwork.freedesktop.org/series/81855/
State : failure
== Summary ==
Applying: zsmalloc: switch from alloc_vm_area to get_vm_area
error: sha1 information is lacking
== Series Details ==
Series: drm/i915: Add support for LTTPR non-transparent link training mode
URL : https://patchwork.freedesktop.org/series/81968/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_9033_full -> Patchwork_18544_full
===
On Tue, Sep 22, 2020 at 11:24:20AM -0400, boris.ostrov...@oracle.com wrote:
>
> On 9/22/20 10:58 AM, Christoph Hellwig wrote:
> > On Mon, Sep 21, 2020 at 04:44:10PM -0400, boris.ostrov...@oracle.com wrote:
> >> This will end up incrementing area->ptes pointer. So perhaps something like
> >>
> >>
>
On Tue, Sep 22, 2020 at 04:27:05PM +0300, Ville Syrjälä wrote:
> On Tue, Sep 22, 2020 at 03:51:02PM +0300, Imre Deak wrote:
> > Split the prepare, link training, fallback-handling steps into their own
> > functions for clarity and as a preparation for the upcoming LTTPR changes.
> >
> > While at i
On Tue, 2020-09-22 at 09:39 -0400, Sean Paul wrote:
> On Mon, Sep 21, 2020 at 6:35 PM Lyude Paul wrote:
> > So if I understand this correctly, it sounds like that some Pixelbooks
> > boot up
> > with DP_EDP_BACKLIGHT_BRIGHTNESS_MSB set to a non-zero value, without the
> > panel actually having DPC
On 2020-09-21 6:24 p.m., Lu Baolu wrote:
I'm trying to test this on an old Sandy Bridge, but found that I get
spammed with warnings on boot. I've put a sample of a few of them below.
They all seem to be related to ioat.
I had the same issue with Tom's v2 but never saw th
On Tue, Sep 22, 2020 at 4:14 PM Daniel Stone wrote:
>
> On Tue, 22 Sep 2020 at 15:04, Daniel Vetter wrote:
> > On Tue, Sep 22, 2020 at 3:36 PM Marius Vlad
> > wrote:
> > > Gentle ping. I've tried out Linus's master tree and, and like Pekka,
> > > I've noticed this isn't integrated/added.
> >
>
On 22/09/2020 15:31, Christoph Hellwig wrote:
On Tue, Sep 22, 2020 at 09:23:59AM +0100, Tvrtko Ursulin wrote:
If I understood this sub-thread correctly, iterating and freeing the pages
via the vmapped ptes, so no need for a
shmem_read_mapping_page_gfp loop in shmem_unpin_map looks plausible to
On 9/22/20 11:27 AM, Christoph Hellwig wrote:
> On Tue, Sep 22, 2020 at 11:24:20AM -0400, boris.ostrov...@oracle.com wrote:
>> On 9/22/20 10:58 AM, Christoph Hellwig wrote:
>>> On Mon, Sep 21, 2020 at 04:44:10PM -0400, boris.ostrov...@oracle.com wrote:
This will end up incrementing area->ptes
On 9/22/20 10:58 AM, Christoph Hellwig wrote:
> On Mon, Sep 21, 2020 at 04:44:10PM -0400, boris.ostrov...@oracle.com wrote:
>> This will end up incrementing area->ptes pointer. So perhaps something like
>>
>>
>> pte_t **ptes = area->ptes;
>>
>> if (apply_to_page_range(&init_mm, (unsigned long)area
On Tue, Sep 22, 2020 at 05:13:45PM +0100, Tvrtko Ursulin wrote:
>> void *shmem_pin_map(struct file *file)
>> {
>> -const size_t n_pte = shmem_npte(file);
>> -pte_t *stack[32], **ptes, **mem;
>
> Chris can comment how much he'd miss the 32 page stack shortcut.
I'd like to see a profile
== Series Details ==
Series: Add support for mipi dsi cmd mode (rev13)
URL : https://patchwork.freedesktop.org/series/69290/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9034_full -> Patchwork_18545_full
Summary
---
On Tue, Sep 22, 2020 at 06:30:35PM +0300, Imre Deak wrote:
> On Tue, Sep 22, 2020 at 04:27:05PM +0300, Ville Syrjälä wrote:
> > On Tue, Sep 22, 2020 at 03:51:02PM +0300, Imre Deak wrote:
> > > Split the prepare, link training, fallback-handling steps into their own
> > > functions for clarity and a
On Tue, Sep 22, 2020 at 03:51:03PM +0300, Imre Deak wrote:
> To prepare for a follow-up LTTPR change factor out a helper to disable
> the training pattern in DPCD. We'll need to do this for each LTTPR
> (without programming the port to output the idle pattern) when training
> in LTTPR non-transpare
On 22/09/2020 17:33, Christoph Hellwig wrote:
On Tue, Sep 22, 2020 at 05:13:45PM +0100, Tvrtko Ursulin wrote:
void *shmem_pin_map(struct file *file)
{
- const size_t n_pte = shmem_npte(file);
- pte_t *stack[32], **ptes, **mem;
Chris can comment how much he'd miss the 32 pag
== Series Details ==
Series: drm/i915: simplify the return expression of i915_driver_release()
URL : https://patchwork.freedesktop.org/series/81977/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_9034_full -> Patchwork_18546_full
On Tue, Sep 22, 2020 at 07:49:17PM +0300, Ville Syrjälä wrote:
> On Tue, Sep 22, 2020 at 06:30:35PM +0300, Imre Deak wrote:
> > On Tue, Sep 22, 2020 at 04:27:05PM +0300, Ville Syrjälä wrote:
> > > On Tue, Sep 22, 2020 at 03:51:02PM +0300, Imre Deak wrote:
> > > > Split the prepare, link training, f
On Thu, 17 Sep 2020, Zhenyu Wang wrote:
> Hi,
>
> Here's one left GVT fix against 5.9 is for kernel oops with VFIO edid
> on BDW.
Pulled, thanks.
BR,
Jani.
>
> Thanks
> --
> The following changes since commit a291e4fba259a56a6a274c1989997acb6f0bb03a:
>
> drm/i915/gvt: Use GFP_ATOMIC instead o
On Tue, Sep 22, 2020 at 03:51:06PM +0300, Imre Deak wrote:
> The DP Standard's recommendation is to use the LTTPR non-transparent
> mode link training if LTTPRs are detected, so let's do this.
>
> Besides power-saving, the advantages of this are that the maximum number
> of LTTPRs can only be used
On Tue, Sep 22, 2020 at 07:54:20PM +0300, Ville Syrjälä wrote:
> On Tue, Sep 22, 2020 at 03:51:03PM +0300, Imre Deak wrote:
> > To prepare for a follow-up LTTPR change factor out a helper to disable
> > the training pattern in DPCD. We'll need to do this for each LTTPR
> > (without programming the
On Tue, Sep 22, 2020 at 08:25:35PM +0300, Imre Deak wrote:
> On Tue, Sep 22, 2020 at 07:49:17PM +0300, Ville Syrjälä wrote:
> > On Tue, Sep 22, 2020 at 06:30:35PM +0300, Imre Deak wrote:
> > > On Tue, Sep 22, 2020 at 04:27:05PM +0300, Ville Syrjälä wrote:
> > > > On Tue, Sep 22, 2020 at 03:51:02PM
On Tue, Sep 22, 2020 at 08:41:28PM +0300, Imre Deak wrote:
> On Tue, Sep 22, 2020 at 07:54:20PM +0300, Ville Syrjälä wrote:
> > On Tue, Sep 22, 2020 at 03:51:03PM +0300, Imre Deak wrote:
> > > To prepare for a follow-up LTTPR change factor out a helper to disable
> > > the training pattern in DPCD.
From: Mauro Carvalho Chehab
The name of the argument is different, causing those warnings:
./drivers/gpu/drm/drm_edid.c:3754: warning: Function parameter or
member 'video_code' not described in 'drm_display_mode_from_cea_vic'
./drivers/gpu/drm/drm_edid.c:3754: warning: Excess fu
Note that none of the code that this touches is in i915, however at the
time I posted this patch all of the DP helpers that concern these
patches were added through drm-intel-next-queued, not drm-misc-next, so
it makes more sense to merge it through drm-intel-next-queued. As such,
I'm just sending
From: Mauro Carvalho Chehab
As warned by kernel-doc:
./drivers/gpu/drm/drm_dp_helper.c:385: warning: Function parameter or
member 'type' not described in 'drm_dp_downstream_is_type'
./drivers/gpu/drm/drm_dp_helper.c:886: warning: Function parameter or
member 'dev' not described
On Tue, Sep 22, 2020 at 08:47:56PM +0300, Ville Syrjälä wrote:
> On Tue, Sep 22, 2020 at 08:41:28PM +0300, Imre Deak wrote:
> > On Tue, Sep 22, 2020 at 07:54:20PM +0300, Ville Syrjälä wrote:
> > > On Tue, Sep 22, 2020 at 03:51:03PM +0300, Imre Deak wrote:
> > > > To prepare for a follow-up LTTPR ch
When doing an atomic modeset with ALLOW_MODESET drivers are allowed to
pull in arbitrary other resources, including CRTCs (e.g. when
reconfiguring global resources).
But in nonblocking mode userspace has then no idea this happened,
which can lead to spurious EBUSY calls, both:
- when that other CR
On Tue, Sep 22, 2020 at 08:37:44PM +0300, Ville Syrjälä wrote:
> On Tue, Sep 22, 2020 at 03:51:06PM +0300, Imre Deak wrote:
> > The DP Standard's recommendation is to use the LTTPR non-transparent
> > mode link training if LTTPRs are detected, so let's do this.
> >
> > Besides power-saving, the ad
On 2020-09-22 3:51 a.m., Robin Murphy wrote:
> On 2020-09-18 21:47, Logan Gunthorpe wrote:
>> Hi Lu,
>>
>> On 2020-09-11 9:21 p.m., Lu Baolu wrote:
>>> Tom Murphy has almost done all the work. His latest patch series was
>>> posted here.
>>>
>>> https://lore.kernel.org/linux-iommu/20200903201839
Alrighty, I'll take everyone else's silence as tacit approval of
Ville's opinions. (I didn't receive any email bounces this time, so I
think my issue was transient.) I will start on inverting the quirk and
making the most-significant-alignment matter for these registers by
default.
Who can help me
On Tue, Sep 22, 2020 at 01:19:15PM +0300, Ville Syrjälä wrote:
> On Mon, Sep 21, 2020 at 02:01:25PM -0700, Navare, Manasi wrote:
> > On Mon, Sep 14, 2020 at 09:52:57PM +0300, Ville Syrjälä wrote:
> > > On Mon, Sep 14, 2020 at 11:32:48AM -0700, Navare, Manasi wrote:
> > > > On Mon, Sep 07, 2020 at 0
== Series Details ==
Series: drm/i915: kernel-doc fixes for new DP helpers
URL : https://patchwork.freedesktop.org/series/81985/
State : failure
== Summary ==
Applying: drm/dp: fix kernel-doc warnings at drm_dp_helper.c
Using index info to reconstruct a base tree...
M drivers/gpu/drm/drm
On Tue, Sep 22, 2020 at 01:27:35PM +0300, Ville Syrjälä wrote:
> On Mon, Sep 21, 2020 at 02:18:33PM -0700, Navare, Manasi wrote:
> > On Mon, Sep 14, 2020 at 12:21:26PM -0700, Navare, Manasi wrote:
> > > On Thu, Sep 03, 2020 at 10:23:35PM +0300, Ville Syrjälä wrote:
> > > > On Wed, Jul 15, 2020 at 0
== Series Details ==
Series: drm: document and enforce rules around "spurious" EBUSY from
atomic_commit
URL : https://patchwork.freedesktop.org/series/81988/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
a5bc5130e920 drm: document and enforce rules around "spurious" EBUSY from
Hi,
On Tue, 22 Sep 2020 at 17:02, Daniel Vetter wrote:
> On Tue, Sep 22, 2020 at 4:14 PM Daniel Stone wrote:
> > I think we need a guarantee that this never happens if ALLOW_MODESET
> > is always used in blocking mode, plus in future a cap we can use to
> > detect that we won't be getting spurio
Hi,
On Tue, 22 Sep 2020 at 19:18, Daniel Vetter wrote:
> + for_each_new_crtc_in_state(state, crtc, old_crtc_state, i)
> + affected_crtc |= drm_crtc_mask(crtc);
> +
> + /*
> +* For commits that allow modesets drivers can add other CRTCs to the
> +* atomic
== Series Details ==
Series: drm: document and enforce rules around "spurious" EBUSY from
atomic_commit
URL : https://patchwork.freedesktop.org/series/81988/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9036 -> Patchwork_18550
+Lyude
I notice that Lyude email was somehow dropped from the thread.
Lyude was the person who submitted the patch for Thinkpad and should
know the OUI of the panel.
On Tue, Sep 22, 2020 at 11:47 AM Kevin Chowski wrote:
>
> Alrighty, I'll take everyone else's silence as tacit approval of
> Ville'
Hi! Since I got dropped from the thread, many responses inline
On Tue, 2020-09-22 at 12:58 -0700, Puthikorn Voravootivat wrote:
> +Lyude
> I notice that Lyude email was somehow dropped from the thread.
> Lyude was the person who submitted the patch for Thinkpad and should
> know the OUI of the pan
== Series Details ==
Series: drm: document and enforce rules around "spurious" EBUSY from
atomic_commit
URL : https://patchwork.freedesktop.org/series/81988/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_9036_full -> Patchwork_18550_full
==
A static analysis tool has reveiled a NULL pointer error in
__i915_gem_object_lock. This appears to be correct as many calls
pass a NULL into the ww parameter.
Signed-off-by: Steve Hampson
---
drivers/gpu/drm/i915/gem/i915_gem_object.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
== Series Details ==
Series: Fix NULL pointer found by static analysis
URL : https://patchwork.freedesktop.org/series/81999/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9039 -> Patchwork_18551
Summary
---
**SUCCESS
On Tue, Sep 22, 2020 at 11:39:57AM +0300, Leon Romanovsky wrote:
> E.g. with the Infiniband driver that allocates a single page for hold
> the
> pages. For 1TB memory registration, the temporary buffer would consume
> only
> 4KB, instead of 2GB.
Formatting looks little weird here.
Otherwise look
On 9/22/20 7:05 PM, Robin Murphy wrote:
With the previous version of the series I hit a problem on Ivybridge
where apparently the dma engine width is not respected. At least
that is my layman interpretation of the errors. From the older thread:
<3> [209.526605] DMAR: intel_iommu_map: iommu wid
On Thu, Sep 17, 2020 at 03:20:46PM +0300, Ville Syrjälä wrote:
> On Tue, Sep 15, 2020 at 04:03:45PM -0700, Navare, Manasi wrote:
> > On Mon, Sep 14, 2020 at 10:47:56PM +0300, Ville Syrjälä wrote:
> > > On Mon, Sep 14, 2020 at 12:38:57PM -0700, Navare, Manasi wrote:
> > > > On Mon, Sep 14, 2020 at 1
On Tue, Sep 22, 2020 at 06:04:37PM +0100, Tvrtko Ursulin wrote:
> Only reason I can come up with now is if mapping side is on a latency
> sensitive path, while un-mapping is lazy/delayed so can be more costly.
> Then fast map and extra cost on unmap may make sense.
In general yes. But compared
93 matches
Mail list logo
