Am 03.10.19 um 22:18 schrieb Davidlohr Bueso:
> The generic tree tree really wants [a, b) intervals, not fully closed.
> As such convert it to use the new interval_tree_gen.h. Most of the
> conversions are straightforward, with the exception of perhaps
> radeon_vm_bo_set_addr(), but semantics have
Am 03.10.19 um 22:18 schrieb Davidlohr Bueso:
> The amdgpu_vm interval tree really wants [a, b) intervals,
NAK, we explicitly do need an [a, b[ interval here.
Regards,
Christian.
> not fully closed ones. As such convert it to use the new
> interval_tree_gen.h, and also rename the 'last' endpoint
Hi Laurent,
Are you happy with this patch? Please let me know.
https://patchwork.kernel.org/project/linux-renesas-soc/list/?series=180271
regards,
Biju
> Subject: [PATCH 0/4] Add RZ/G2N DU support
>
> This patch series aims to add binding/driver support for R8A774B1(a.k.a
> RZ/G2N) DU (which i
On Thu, 03 Oct 2019, Jason Gunthorpe wrote:
On Thu, Oct 03, 2019 at 01:18:47PM -0700, Davidlohr Bueso wrote:
Hi,
It has been discussed[1,2] that almost all users of interval trees would better
be served if the intervals were actually not [a,b], but instead [a, b). This
series attempts to conve
In previous release amdgpu_pmu.o is only built when CONFIG_PERF_EVENTS
is selected. But after commit 64f55e629237e4752db1 ("drm/amdgpu: Add RAS
EEPROM table.") it is duplicated in amdgpu-y. This change causes a build
error when !CONFIG_PERF_EVENTS, so fix it.
Fixes: 64f55e629237e4752db1 ("drm/amdg
Hi all,
Today's linux-next merge of the drm-misc tree got a conflict in:
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
between commit:
2f232cf29e03 ("drm/amdgpu/dm/mst: Don't create MST topology managers for eDP
ports")
from the admgpu tree and commit:
ae85b0df124f ("drm_
On Thu, Oct 03, 2019 at 01:18:47PM -0700, Davidlohr Bueso wrote:
> Hi,
>
> It has been discussed[1,2] that almost all users of interval trees would
> better
> be served if the intervals were actually not [a,b], but instead [a, b). This
> series attempts to convert all callers by way of transition
Hi Davidlohr,
I love your patch! Yet something to improve:
[auto build test ERROR on next-20191003]
url:
https://github.com/0day-ci/linux/commits/Davidlohr-Bueso/lib-interval-tree-move-to-half-closed-intervals/20191004-042411
config: arm64-allyesconfig (attached as .config)
compiler
Hi,
Static analysis with Coverity has detected a potential issue with
function validate_bksv in
drivers/gpu/drm/amd/display/modules/hdcp/hdcp1_execution.c with recent
commit:
commit ed9d8e2bcb003ec94658cafe9b1bb3960e2139ec
Author: Bhawanpreet Lakha
Date: Tue Aug 6 17:52:01 2019 -0400
drm/
https://bugs.freedesktop.org/show_bug.cgi?id=111881
erhar...@mailbox.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
From: Colin Ian King
The boolean variable pasid_mapping_needed is not initialized and
there are code paths that do not assign it any value before it is
is read later. Fix this by initializing pasid_mapping_needed to
false.
Addresses-Coverity: ("Uninitialized scalar variable")
Fixes: 6817bf283b2
From: Colin Ian King
There is a return statement that is not reachable and a variable that
is not used. Remove them.
Addresses-Coverity: ("Structurally dead code")
Fixes: de7b45babd9b ("drm/amdgpu: cleanup creating BOs at fixed location (v2)")
Signed-off-by: Colin Ian King
---
drivers/gpu/drm
Add curly braces to an 'else' branch in pwm_backlight_update_status()
to match the corresponding 'if' branch.
Signed-off-by: Matthias Kaehlcke
---
drivers/video/backlight/pwm_bl.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/vi
https://bugs.freedesktop.org/show_bug.cgi?id=111902
Bug ID: 111902
Summary: too much trees
Product: DRI
Version: XOrg git
Hardware: x86-64 (AMD64)
URL: http://mu.ac.in/portal/
OS: Windows (All)
Status
On Thu, 03 Oct 2019, Matthew Wilcox wrote:
On Thu, Oct 03, 2019 at 01:18:47PM -0700, Davidlohr Bueso wrote:
It has been discussed[1,2] that almost all users of interval trees would better
be served if the intervals were actually not [a,b], but instead [a, b). This
So how does a user represent
Make dma_fence_enable_sw_signaling() behave like its
dma_fence_add_callback() and dma_fence_default_wait() counterparts and
perform the test to enable signaling under the fence->lock, along with
the action to do so. This ensure that should an implementation be trying
to flush the cb_list (by signal
In preparation for rearranging the booleans into a flags field, ensure
all the current users are using the inline helpers and not directly
accessing the members.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_mm.c | 19 ---
.../gpu/drm/i915/gem/i915_gem_
A few callers need to serialise the destruction of their drm_mm_node and
ensure it is removed from the drm_mm before freeing. However, to be
completely sure that any access from another thread is complete before
we free the struct, we require the RELEASE semantics of
clear_bit_unlock().
This allow
If we unwind the active requests, and on resubmission discover that we
intend to preempt the active context with itself, simply skip the ELSP
submission.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
d
A straightforward conversion of assignment and checking of the boolean
state flags (allocated, scanned) into non-atomic bitops. The caller
remains responsible for all locking around the drm_mm and its nodes.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_mm.c | 18
https://bugs.freedesktop.org/show_bug.cgi?id=110865
--- Comment #36 from tempel.jul...@gmail.com ---
(In reply to Dieter Nützel from comment #28)
> I've tried solving the flicker with both fixes (sent by magist3r) from this
> bug
>
> Bug 102646 - Screen flickering under amdgpu-experimental [buggy
On Thu, Oct 03, 2019 at 01:18:55PM -0700, Davidlohr Bueso wrote:
> +++ b/mm/nommu.c
> @@ -1793,7 +1793,7 @@ int nommu_shrink_inode_mappings(struct inode *inode,
> size_t size,
> size_t r_size, r_top;
>
> low = newsize >> PAGE_SHIFT;
> - high = (size + PAGE_SIZE - 1) >> PAGE_SHIFT
On Thu, Oct 03, 2019 at 01:18:47PM -0700, Davidlohr Bueso wrote:
> It has been discussed[1,2] that almost all users of interval trees would
> better
> be served if the intervals were actually not [a,b], but instead [a, b). This
So how does a user represent a range from ULONG_MAX to ULONG_MAX now?
On 10/3/19 9:41 PM, Mark Brown wrote:
> On Thu, Oct 03, 2019 at 09:21:06PM +0200, Jacek Anaszewski wrote:
>> On 10/3/19 8:35 PM, Mark Brown wrote:
>>> On Thu, Oct 03, 2019 at 07:43:17PM +0200, Jacek Anaszewski wrote:
On 10/3/19 2:47 PM, Jean-Jacques Hiblot wrote:
> On 03/10/2019 12:42, Seb
The drm_mm interval tree really wants [a, b) intervals, not
fully closed as it is now. As such convert it to use the new
interval_tree_gen.h.
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Daniel Vetter
Cc: intel-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Davidloh
The generic tree tree really wants [a, b) intervals, not fully closed.
As such convert it to use the new interval_tree_gen.h. Most of the
conversions are straightforward, with the exception of perhaps
radeon_vm_bo_set_addr(), but semantics have been tried to be left
untouched.
Cc: "Christian König
With some considerations, the custom pat_rbtree implementation can be
simplified to use most of the generic interval_tree machinery.
o The tree inorder traversal can slightly differ when there are key
('start') collisions in the tree due to one going left and another right.
This, however, only aff
Now that we have the semi-open equivalent, interval_tree_gen.h, and
all users updated, we can do without this header file.
Signed-off-by: Davidlohr Bueso
---
include/linux/interval_tree_generic.h | 187 --
1 file changed, 187 deletions(-)
delete mode 100644 inclu
While the kernel's interval tree implementation uses closed intervals, all
users (with the exception of query stabbing) really want half closed intervals,
specifically [a, b), and will explicitly correct this before calling the tree
api.
This patch simply duplicates the include/linuxinterval_tree
The usnic_uiom interval tree really wants [a, b) intervals,
not fully closed. As such convert it to use the new
interval_tree_gen.h, and also rename the 'last' endpoint
in the node to 'end', which both a more suitable name for
the half closed interval and also reduces the chances of some
caller bei
The __mmu_int_rb interval tree really wants [a, b) intervals,
not fully closed as currently. As such convert it to use the new
interval_tree_gen.h.
Cc: Mike Marciniszyn
Cc: Dennis Dalessandro
Cc: Doug Ledford
Cc: linux-r...@vger.kernel.org
Signed-off-by: Davidlohr Bueso
---
drivers/infiniband
The vma and anon vma interval tree really wants [a, b) intervals,
not fully closed. As such convert it to use the new
interval_tree_gen.h. Because of vma_last_pgoff(), the conversion
is quite straightforward.
Signed-off-by: Davidlohr Bueso
---
include/linux/mm.h | 4 ++--
mm/interval_tree.c | 4
The vhost_umem interval tree really wants [a, b) intervals,
not fully closed as currently. As such convert it to use the
new interval_tree_gen.h, and also rename the 'last' endpoint
in the node to 'end', which both a more suitable name for
the half closed interval and also reduces the chances of so
This documents better the nature of the stab lookup/query.
In addition, this is a step that will make the conversion
of interval tree nodes from [a,b] to [a,b) easier to review.
For symmetry with vma_interval_tree, the anon equivalent is
also introduced, albeit a single user. This patch does not
Hi,
It has been discussed[1,2] that almost all users of interval trees would better
be served if the intervals were actually not [a,b], but instead [a, b). This
series attempts to convert all callers by way of transitioning from using
"interval_tree_generic.h" to "interval_tree_gen.h". Once all us
On Thu, Oct 3, 2019 at 2:59 AM Jani Nikula wrote:
>
> On Wed, 02 Oct 2019, Mat King wrote:
> > On Wed, Oct 2, 2019 at 4:46 AM Jani Nikula
> > wrote:
> >>
> >> On Wed, 02 Oct 2019, Daniel Thompson wrote:
> >> > On Wed, Oct 02, 2019 at 12:30:05PM +0300, Jani Nikula wrote:
> >> >> On Tue, 01 Oct
On Thu, Oct 03, 2019 at 10:37:11PM +0300, Ville Syrjälä wrote:
> On Thu, Oct 03, 2019 at 12:30:51PM -0700, Rodrigo Vivi wrote:
> > Hi Dave and Daniel,
> >
> > This v2 contains a critical DP-MST fix that it would be really good to be
> > propagated as soon as possible.
> >
> > Besides all the drm-
On Thu, Oct 03, 2019 at 09:21:06PM +0200, Jacek Anaszewski wrote:
> On 10/3/19 8:35 PM, Mark Brown wrote:
> > On Thu, Oct 03, 2019 at 07:43:17PM +0200, Jacek Anaszewski wrote:
> >> On 10/3/19 2:47 PM, Jean-Jacques Hiblot wrote:
> >>> On 03/10/2019 12:42, Sebastian Reichel wrote:
> On Thu, Oct
On Thu, Oct 03, 2019 at 12:30:51PM -0700, Rodrigo Vivi wrote:
> Hi Dave and Daniel,
>
> This v2 contains a critical DP-MST fix that it would be really good to be
> propagated as soon as possible.
>
> Besides all the drm-intel-next-fixes that I mentioned on previous email.
>
> Here goes drm-intel
Hi Dave and Daniel,
This v2 contains a critical DP-MST fix that it would be really good to be
propagated as soon as possible.
Besides all the drm-intel-next-fixes that I mentioned on previous email.
Here goes drm-intel-fixes-2019-10-03-1:
- Fix DP-MST crtc_mask
- Fix dsc dpp calculations
- Fix g
Hi Mark,
On 10/3/19 8:35 PM, Mark Brown wrote:
> On Thu, Oct 03, 2019 at 07:43:17PM +0200, Jacek Anaszewski wrote:
>> On 10/3/19 2:47 PM, Jean-Jacques Hiblot wrote:
>>> On 03/10/2019 12:42, Sebastian Reichel wrote:
On Thu, Oct 03, 2019 at 10:28:09AM +0200, Jean-Jacques Hiblot wrote:
>
> This
Hi,
On Thu, Oct 3, 2019 at 11:37 AM Sean Paul wrote:
>
> On Thu, Oct 3, 2019 at 1:20 PM Douglas Anderson wrote:
> >
> > I'm embarassed to say that even though I've touched
> > vop_crtc_mode_fixup() twice and I swear I tested it, there's still a
> > stupid glaring bug in it. Specifically, on vey
I'm embarassed to say that even though I've touched
vop_crtc_mode_fixup() twice and I swear I tested it, there's still a
stupid glaring bug in it. Specifically, on veyron_minnie (with all
the latest display timings) we want to be setting our pixel clock to
66,666,666.67 Hz and we tell userspace th
From: Daniel Stone
Mirroring addfb2, add tests for the new ioctl which will return us
information about framebuffers containing multiple buffers, as well as
modifiers.
Changes since v1:
- Add test that uses getfb2 output to call addfb2 as suggested by Ville
Signed-off-by: Daniel Stone
Signed-
Depends on ummerged kernel code for getfb2
Rest of drm.h taken from:
commit 54ecb8f7028c5eb3d740bb82b0f1d90f2df63c5c
Author: Linus Torvalds
Date: Mon Sep 30 10:35:40 2019 -0700
Linux 5.4-rc1
Signed-off-by: Juston Li
---
include/drm-uapi/drm.h | 39 +++
https://bugs.freedesktop.org/show_bug.cgi?id=111889
--- Comment #6 from Alex Deucher ---
What component (mesa, kernel, etc.) did you change which caused the regression?
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-d
From: Daniel Stone
Add a wrapper around the getfb2 ioctl, which returns extended
framebuffer information mirroring addfb2, including multiple planes and
modifiers.
This depends on unmerged kernel API so should not be merged.
Changes since v1:
- functions should be drm_public
- modifier for sh
On Thu, Oct 3, 2019 at 1:20 PM Douglas Anderson wrote:
>
> I'm embarassed to say that even though I've touched
> vop_crtc_mode_fixup() twice and I swear I tested it, there's still a
> stupid glaring bug in it. Specifically, on veyron_minnie (with all
> the latest display timings) we want to be se
On Thu, Oct 03, 2019 at 07:43:17PM +0200, Jacek Anaszewski wrote:
> On 10/3/19 2:47 PM, Jean-Jacques Hiblot wrote:
> > On 03/10/2019 12:42, Sebastian Reichel wrote:
> >> On Thu, Oct 03, 2019 at 10:28:09AM +0200, Jean-Jacques Hiblot wrote:
This mail has nothing relevant in the subject line and page
From: Daniel Stone
getfb2 allows us to pass multiple planes and modifiers, just like addfb2
over addfb.
Changes since v1:
- unused modifiers set to 0 instead of DRM_FORMAT_MOD_INVALID
- update ioctl number
Signed-off-by: Daniel Stone
Signed-off-by: Juston Li
---
drivers/gpu/drm/drm_crtc_in
https://bugs.freedesktop.org/show_bug.cgi?id=111729
--- Comment #5 from SET ---
(In reply to Alex Deucher from comment #4)
> Can you bisect?
Bisecting would be of great help. I doubt it's feasible in practice. The bug
happens after an undetermined number of syspend/resume cycles. It would take
w
Quoting Krzysztof Kozlowski (2019-10-02 09:40:46)
> Convert generic PWM bindings to DT schema format using json-schema. The
> consumer bindings are split to separate file.
>
> Signed-off-by: Krzysztof Kozlowski
>
> ---
>
> Changes since v2:
> 1. Change also pwm-sprd.txt
>
> Changes since v1:
On Thu, Oct 03, 2019 at 10:58:52AM -0700, Rodrigo Vivi wrote:
> Hi Dave and Daniel,
>
> I know you are on XDC and I was even considering not send any this week,
> but let me send this before I forget.
>
> There are the drm-intel-next-fixes pull requests that I had sent
> that are still needed and
Hi Dave and Daniel,
I know you are on XDC and I was even considering not send any this week,
but let me send this before I forget.
There are the drm-intel-next-fixes pull requests that I had sent
that are still needed and it would be good if you could pull those.
Besides we have more 2 fixes her
Hi Jean,
On 10/3/19 2:47 PM, Jean-Jacques Hiblot wrote:
> Hi Sebastian,
>
> On 03/10/2019 12:42, Sebastian Reichel wrote:
>> Hi,
>>
>> On Thu, Oct 03, 2019 at 10:28:09AM +0200, Jean-Jacques Hiblot wrote:
>>> From: Tomi Valkeinen
>>>
>>> This patch adds basic support for a kernel driver to get a
This fixes the following kernel-doc warnings and makes the corrsponding fields
show up in the generated HTML:
./drivers/gpu/drm/i915/i915_drv.h:1143: warning: Incorrect use of kernel-doc
format: * State of the OA buffer.
./drivers/gpu/drm/i915/i915_drv.h:1154: warning: Incorrect use of k
Sebastian,
On 03/10/2019 13:47, Sebastian Reichel wrote:
Hi,
On Thu, Oct 03, 2019 at 10:28:12AM +0200, Jean-Jacques Hiblot wrote:
From: Tomi Valkeinen
This patch adds a led-backlight driver (led_bl), which is similar to
pwm_bl except the driver uses a LED class driver to adjust the
brightnes
I'm embarassed to say that even though I've touched
vop_crtc_mode_fixup() twice and I swear I tested it, there's still a
stupid glaring bug in it. Specifically, on veyron_minnie (with all
the latest display timings) we want to be setting our pixel clock to
66,666,666.67 Hz and we tell userspace th
On Friday, 26 July 2019 09:06:16 BST Lowry Li (Arm Technology China) wrote:
> This patch adds the checks for vrefresh, crtc_hdisplay and crtc_vdisplay.
>
> Signed-off-by: Lowry Li (Arm Technology China)
> ---
> drivers/gpu/drm/arm/display/komeda/komeda_crtc.c | 28
> +++-
>
https://bugs.freedesktop.org/show_bug.cgi?id=107731
--- Comment #14 from James Wood ---
I was about to report having the same bug but it seems the today's Mesa
19.2.0-2 update has solved the problem, I will include what I was originally
going to post in case it's of use to anyone.
---
I've bega
Quoting Krzysztof Kozlowski (2019-10-02 09:06:30)
> Convert Generic Power Domain bindings to DT schema format using
> json-schema. The consumer bindings are split to separate file.
>
> Signed-off-by: Krzysztof Kozlowski
>
> ---
Acked-by: Stephen Boyd
On Wed, Oct 2, 2019 at 5:27 AM Philippe Schenker
wrote:
>
> On Tue, 2019-10-01 at 17:05 -0500, Rob Herring wrote:
> > On Fri, Sep 20, 2019 at 09:54:11AM +0200, Marcel Ziswiler wrote:
> > > From: Marcel Ziswiler
> > >
> > > Add display timings for the following 3 display panels manufactured
> > >
On Thu, Oct 03, 2019 at 05:37:15PM +0200, Benjamin Gaignard wrote:
> Le jeu. 3 oct. 2019 à 17:05, Ville Syrjälä
> a écrit :
> >
> > On Thu, Oct 03, 2019 at 04:46:54PM +0200, Benjamin Gaignard wrote:
> > > Le jeu. 3 oct. 2019 à 16:27, Ville Syrjälä
> > > a écrit :
> > > >
> > > > On Mon, Sep 09, 2
https://bugs.freedesktop.org/show_bug.cgi?id=111896
Andre Klapper changed:
What|Removed |Added
Keywords|cleanup0407 |
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=111897
Andre Klapper changed:
What|Removed |Added
Component|General |Two
Product|DRI
Le jeu. 3 oct. 2019 à 17:05, Ville Syrjälä
a écrit :
>
> On Thu, Oct 03, 2019 at 04:46:54PM +0200, Benjamin Gaignard wrote:
> > Le jeu. 3 oct. 2019 à 16:27, Ville Syrjälä
> > a écrit :
> > >
> > > On Mon, Sep 09, 2019 at 03:52:05PM +0200, Benjamin Gaignard wrote:
> > > > Fix warnings with W=1.
>
On Thu, Oct 3, 2019 at 6:47 PM Maxime Ripard wrote:
>
> On Thu, Oct 03, 2019 at 12:15:21PM +0530, Jagan Teki wrote:
> > The LCD timing definitions between Linux DRM vs Allwinner are different,
> > below diagram shows this clear differences.
> >
> >Active Front
Hi,
On Thu, Oct 03, 2019 at 04:39:39PM +0200, Linus Walleij wrote:
> On Thu, Oct 3, 2019 at 4:34 PM Linus Walleij wrote:
> > On Wed, Oct 2, 2019 at 5:39 PM Jonathan Neuschäfer
> > wrote:
> >
> > > The :doc: reference did not match the DOC comment's name.
> > >
> > > Fixes: 5fc537bfd000 ("drm/mcd
On 03/10/2019 16.59, Hans Verkuil wrote:
> On 10/3/19 9:15 AM, Johan Korsnes wrote:
>> When logging the AVI InfoFrame, clearly indicate whether or not the
>> extended colorimetry attribute is active. This is only the case when
>> the AVI InfoFrame colorimetry attribute is set to extended. [0]
>>
>>
On Thu, Oct 03, 2019 at 04:46:54PM +0200, Benjamin Gaignard wrote:
> Le jeu. 3 oct. 2019 à 16:27, Ville Syrjälä
> a écrit :
> >
> > On Mon, Sep 09, 2019 at 03:52:05PM +0200, Benjamin Gaignard wrote:
> > > Fix warnings with W=1.
> > > Few for_each macro set variables that are never used later.
> >
On 10/3/19 3:44 PM, Ville Syrjälä wrote:
> On Thu, Oct 03, 2019 at 09:15:49AM +0200, Johan Korsnes wrote:
>> When logging the AVI InfoFrame, clearly indicate whether or not the
>> extended colorimetry attribute is active. This is only the case when
>> the AVI InfoFrame colorimetry attribute is set
On 03/10/2019 15.44, Ville Syrjälä wrote:
> On Thu, Oct 03, 2019 at 09:15:49AM +0200, Johan Korsnes wrote:
>> When logging the AVI InfoFrame, clearly indicate whether or not the
>> extended colorimetry attribute is active. This is only the case when
>> the AVI InfoFrame colorimetry attribute is set
On 10/3/19 9:15 AM, Johan Korsnes wrote:
> When logging the AVI InfoFrame, clearly indicate whether or not the
> extended colorimetry attribute is active. This is only the case when
> the AVI InfoFrame colorimetry attribute is set to extended. [0]
>
> [0] CTA-861-G section 6.4 page 57
>
> Signed-
https://bugs.freedesktop.org/show_bug.cgi?id=111848
--- Comment #17 from m...@cschwarz.com ---
The kernel-package.py script is broken.
I'll build kernels directly.
Git bisect says approximately 13 steps are required between v4.20 and v5.0.
Will report back in ~14 days when that's done (bug manifes
Le jeu. 3 oct. 2019 à 16:27, Ville Syrjälä
a écrit :
>
> On Mon, Sep 09, 2019 at 03:52:05PM +0200, Benjamin Gaignard wrote:
> > Fix warnings with W=1.
> > Few for_each macro set variables that are never used later.
> > Prevent warning by marking these variables as __maybe_unused.
> >
> > Signed-of
On 03/10/2019 15:18, Chris Wilson wrote:
Quoting Ruhl, Michael J (2019-10-03 15:12:38)
-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
Chris Wilson
Sent: Thursday, October 3, 2019 9:24 AM
To: intel-...@lists.freedesktop.org
Cc: dri-devel@
>-Original Message-
>From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
>Sent: Thursday, October 3, 2019 10:19 AM
>To: Ruhl, Michael J ; intel-
>g...@lists.freedesktop.org
>Cc: dri-devel@lists.freedesktop.org
>Subject: RE: [Intel-gfx] [PATCH v3] dma-fence: Serialise signal enabling
>(dma_
https://bugs.freedesktop.org/show_bug.cgi?id=111848
--- Comment #16 from Alex Deucher ---
(In reply to me from comment #15)
> Is there a Fedora workflow for bisecting?
> Also, do I need to take care of any GPU firmware or is it just the kernel?
Don't worry about the firmware, just the kernel is
On Thu, Oct 3, 2019 at 4:34 PM Linus Walleij wrote:
> On Wed, Oct 2, 2019 at 5:39 PM Jonathan Neuschäfer
> wrote:
>
> > The :doc: reference did not match the DOC comment's name.
> >
> > Fixes: 5fc537bfd000 ("drm/mcde: Add new driver for ST-Ericsson MCDE")
> > Signed-off-by: Jonathan Neuschäfer
>
https://bugs.freedesktop.org/show_bug.cgi?id=111848
--- Comment #15 from m...@cschwarz.com ---
Is there a Fedora workflow for bisecting?
Also, do I need to take care of any GPU firmware or is it just the kernel?
--
You are receiving this mail because:
You are the assignee for the bug.___
On Wed, Oct 2, 2019 at 5:39 PM Jonathan Neuschäfer
wrote:
> The :doc: reference did not match the DOC comment's name.
>
> Fixes: 5fc537bfd000 ("drm/mcde: Add new driver for ST-Ericsson MCDE")
> Signed-off-by: Jonathan Neuschäfer
Both patches applied!
Yours,
Linus Walleij
__
https://bugs.freedesktop.org/show_bug.cgi?id=111729
--- Comment #4 from Alex Deucher ---
Can you bisect?
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.
https://bugs.freedesktop.org/show_bug.cgi?id=111848
--- Comment #14 from Alex Deucher ---
Can you bisect?
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists
On Mon, Sep 09, 2019 at 03:52:05PM +0200, Benjamin Gaignard wrote:
> Fix warnings with W=1.
> Few for_each macro set variables that are never used later.
> Prevent warning by marking these variables as __maybe_unused.
>
> Signed-off-by: Benjamin Gaignard
> ---
> drivers/gpu/drm/drm_atomic_helper
https://bugs.freedesktop.org/show_bug.cgi?id=111848
--- Comment #13 from m...@cschwarz.com ---
Can confirm this problem on
kernel-5.2.17-200.fc30
kernel-5.2.9-200.fc30
kernel-5.2.5-200.fc30
kernel-5.3.1-150.vanilla.knurd.1.fc30
Suspend & resume work flawlessly on
kernel-4.20.16-200.fc29
--
Y
Quoting Ruhl, Michael J (2019-10-03 15:12:38)
> >-Original Message-
> >From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
> >Chris Wilson
> >Sent: Thursday, October 3, 2019 9:24 AM
> >To: intel-...@lists.freedesktop.org
> >Cc: dri-devel@lists.freedesktop.org
> >Su
On Thu, Oct 03, 2019 at 01:59:42PM +0530, Sharma, Shashank wrote:
>
> On 9/25/2019 7:25 PM, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Now that the cea mode handling is not 100% tied to the single
> > array the dummy VIC 0 mode is pretty much pointles. Throw it
> > out.
> >
> > Cc: Hans
On Thu, Oct 03, 2019 at 01:52:58PM +0530, Sharma, Shashank wrote:
>
> On 9/25/2019 7:25 PM, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Add a second table to the cea modes with VIC >= 193.
> >
> > Cc: Hans Verkuil
> > Cc: Shashank Sharma
> > Signed-off-by: Ville Syrjälä
> > ---
> >
https://bugs.freedesktop.org/show_bug.cgi?id=111729
m...@cschwarz.com changed:
What|Removed |Added
CC||m...@cschwarz.com
--- Comment #3 fro
>-Original Message-
>From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
>Chris Wilson
>Sent: Thursday, October 3, 2019 9:24 AM
>To: intel-...@lists.freedesktop.org
>Cc: dri-devel@lists.freedesktop.org
>Subject: [Intel-gfx] [PATCH v3] dma-fence: Serialise signal en
>-Original Message-
>From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf
>Of Chris Wilson
>Sent: Thursday, October 3, 2019 3:08 AM
>To: Ruhl, Michael J ; dri-
>de...@lists.freedesktop.org
>Cc: intel-...@lists.freedesktop.org
>Subject: RE: [PATCH 2/2] drm/mm: Pack allo
On Thu, Oct 03, 2019 at 01:46:16PM +0530, Sharma, Shashank wrote:
> Hello Ville,
>
> On 9/25/2019 7:24 PM, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > We're going to need two cea mode tables (on for VICs < 128,
> > another one for VICs >= 193). To that end replace the direct
> > edid_cea
On Thu, Oct 03, 2019 at 09:51:18AM +0200, Andrzej Pietrasiewicz wrote:
> To human readers
The commit message is always for human readers, no need to point that
out...
>
> "array of struct drm_format modifiers" is almost indistinguishable from
> "array of struct drm_format_modifiers", especially
https://bugs.freedesktop.org/show_bug.cgi?id=111898
Bug ID: 111898
Summary: Very Cluttery
Product: DRI
Version: XOrg git
Hardware: x86-64 (AMD64)
OS: Windows (All)
Status: NEW
Severity: normal
Pr
On Thu, Oct 03, 2019 at 09:15:49AM +0200, Johan Korsnes wrote:
> When logging the AVI InfoFrame, clearly indicate whether or not the
> extended colorimetry attribute is active. This is only the case when
> the AVI InfoFrame colorimetry attribute is set to extended. [0]
>
> [0] CTA-861-G section 6.
On Wed, 2 Oct 2019 at 18:06, Krzysztof Kozlowski wrote:
>
> Convert Generic Power Domain bindings to DT schema format using
> json-schema. The consumer bindings are split to separate file.
>
> Signed-off-by: Krzysztof Kozlowski
Thanks for working on this, it looks good to me! Although, I have t
On 15/09/2019 19:45, Chris Wilson wrote:
The ulterior motive to switching the booleans over to bitops is to
allow use of the allocated flag as a bitlock.
Locked bit usage applies only to DRM_MM_NODE_ALLOCATED_BIT?
Any value in extracting the conversion to calling drm_mm_node_allocated
ahead
On Thu, Oct 03, 2019 at 09:21:30PM +0800, Icenowy Zheng wrote:
>
>
> 于 2019年10月3日 GMT+08:00 下午9:19:16, Maxime Ripard 写到:
> >On Thu, Oct 03, 2019 at 12:38:43PM +0530, Jagan Teki wrote:
> >> On Tue, Oct 1, 2019 at 1:33 PM Icenowy Zheng wrote:
> >> >
> >> > This reverts commit da676c6aa6413d59ab0a80
On Thu, Oct 03, 2019 at 09:04:03PM +0800, Icenowy Zheng wrote:
> 于 2019年10月3日 GMT+08:00 下午7:47:33, Maxime Ripard 写到:
> >On Thu, Oct 03, 2019 at 12:15:24PM +0530, Jagan Teki wrote:
> >> Allwinner MIPI DSI controllers are supplied with SoC DSI
> >> power rails via VCC-DSI pin.
> >>
> >> Some board s
Hi Ayan,
Thanks for the patch. I'm OK with either the static reserved type way or
the previous dynamic way. So this patch is:
Reviewed-by: Qiang Yu
PS. for anyone would like to know the usage of this modifier, lima mesa
driver need this modifier to denote some tiled texture format and shared
bet
1 - 100 of 158 matches
Mail list logo
