On Fri, May 04, 2018 at 03:17:59PM -0700, matthew.s.atw...@intel.com wrote:
> From: Matt Atwood
>
> As more differentation occurs between DP spec. Its useful to have these
> as macros in a drm_dp_helper.
>
> v2: DPCD_REV_XX to DP_DPCD_REV_XX
>
> Signed-off-by: Matt Atwood
Reviewed-by: Rodrigo
The default-on property - or the def_value via legacy pdata) should be
handled as:
if it is 1, the backlight must be enabled (kept enabled)
if it is 0, the backlight must be disabled (kept disabled)
This only works for the case when default-on is set. If it is not set then
the brightness of the ba
On 05/08/2018 04:07 AM, Stephen Rothwell wrote:
Hi all,
After merging the drm-intel tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/gpu/drm/xen/xen_drm_front.c: In function 'xen_drv_probe':
drivers/gpu/drm/xen/xen_drm_front.c:740:10: error: 'struct bus_type' has n
https://bugzilla.kernel.org/show_bug.cgi?id=199025
--- Comment #25 from todd (todd...@gmail.com) ---
I wish they let us edit our posts here.
I realized I made a mistake in number 3 of comment #22.
It should say "your systems default video driver" instead of Nouvaeu. Also if
you're using a GPU o
On Mon, May 07, 2018 at 06:37:52AM -0700, Laura Abbott wrote:
> On 05/06/2018 06:18 PM, Nathan Chancellor wrote:
> > checkpatch.pl complains these are invalid because the rules in
> > Documentation/process/license-rules.rst state that C headers should
> > have "/* */" style comments.
> >
>
> The
On 2018-05-07 14:59, Andrzej Hajda wrote:
> On 04.05.2018 15:52, Peter Rosin wrote:
>> If the bridge supplier is unbound, this will bring the bridge consumer
>> down along with the bridge. Thus, there will no longer linger any
>> dangling pointers from the bridge consumer (the drm_device) to some
>
On 2018-05-07 15:59, Peter Rosin wrote:
> On 2018-05-07 15:39, Daniel Vetter wrote:
>> On Thu, May 03, 2018 at 11:12:21PM +0200, Peter Rosin wrote:
>>> On 2018-05-03 11:06, Daniel Vetter wrote:
On Wed, May 02, 2018 at 09:40:23AM +0200, Peter Rosin wrote:
> The more natural approach would p
On 2018-05-07 13:36, Dan Carpenter wrote:
Hi Kiran,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on backlight/for-backlight-next]
[also build test WARNING on v4.17-rc3 next-20180504]
[if your patch is applied to the wrong git tree, please drop us a note
to hel
On 05/07/2018 09:13 AM, Randy Dunlap wrote:
> On 05/07/2018 12:09 AM, Andrzej Hajda wrote:
>> On 06.05.2018 02:46, Randy Dunlap wrote:
>>> On 05/05/2018 04:22 PM, kbuild test robot wrote:
Hi Maciej,
FYI, the error/warning still remains.
>>> Hi M. Robot,
>>>
>>> I am cc-ing dri-devel@
On 05/07/2018 12:09 AM, Andrzej Hajda wrote:
> On 06.05.2018 02:46, Randy Dunlap wrote:
>> On 05/05/2018 04:22 PM, kbuild test robot wrote:
>>> Hi Maciej,
>>>
>>> FYI, the error/warning still remains.
>> Hi M. Robot,
>>
>> I am cc-ing dri-devel@lists.freedesktop.org so that they are aware of the
>>
On Mon, May 07, 2018 at 04:50:42PM +0200, Thomas Hellstrom wrote:
>
> Do you want me to take patch 7 and 8 through a vmwgfx pull request?
I'm happy to follow any process that the different sub-teams here prefer.
I sent this out as one series as it clearly is connected, but if you'd
rather have th
On Thu 03 May 02:57 PDT 2018, Kiran Gunda wrote:
> WLED peripheral has over voltage protection(OVP) circuitry and the OVP
> fault is notified through an interrupt. Though this fault condition rising
> is due to an incorrect hardware configuration is mitigated in the hardware,
> it still needs to b
On Mon, 2018-05-07 at 11:36 +0200, Maarten Lankhorst wrote:
> Op 04-05-18 om 16:25 schreef Ezequiel Garcia:
> > It's perfectly possible to get dumb buffers out of drivers
> > that don't support modeset. This is the case of vgem,
> > which can be used to export dmabuf to run various tests.
> > There
On 2018-05-07 15:56, Daniel Vetter wrote:
> On Fri, May 04, 2018 at 03:51:46PM +0200, Peter Rosin wrote:
>> Hi!
>>
>> It was noted by Russel King [1] that bridges (not using components)
>> might disappear unexpectedly if the owner of the bridge was unbound.
>> Jyri Sarha had previously noted the sa
Quoting spa...@codeaurora.org (2018-05-03 02:41:29)
> On 2018-05-02 22:31, Stephen Boyd wrote:
> > Quoting Sandeep Panda (2018-05-01 21:32:00)
> >> diff --git
> >> a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt
> >> b/Documentation/devicetree/bindings/display/bridge/ti,sn65ds
Hi Boris,
> Boris Brezillon hat am 7. Mai 2018 um 09:11
> geschrieben:
>
>
> On Sun, 6 May 2018 01:56:36 +0200 (CEST)
> Stefan Wahren wrote:
>
> > > Boris Brezillon hat am 5. Mai 2018 um 20:00
> > > geschrieben:
> > >
> > >
> > > On Sat, 5 May 2018 19:44:57 +0200 (CEST)
> > > Stefan Wahr
It's perfectly possible to get dumb buffers out of drivers
that don't support modeset. This is the case of vgem,
which can be used to export dmabuf to run various tests.
Inspired by commit f3f4c4d68a28 ("drm: Allow CAP_PRIME on !MODESET").
Fixes: d5264ed3823a ("drm: Return -ENOTSUPP when called f
On Thu 03 May 02:57 PDT 2018, Kiran Gunda wrote:
> pm8941-wled.c driver is supporting the WLED peripheral
> on pm8941. Rename it to qcom-wled.c so that it can support
> WLED on multiple PMICs.
>
> Signed-off-by: Kiran Gunda
Reviewed-by: Bjorn Andersson
Regards,
Bjorn
> ---
> .../bindings/le
On Thu 03 May 02:57 PDT 2018, Kiran Gunda wrote:
[..]
> +
> +#define WLED_AUTO_DETECT_OVP_COUNT 5
> +#define WLED_AUTO_DETECT_CNT_DLY_US HZ /* 1 second */
> +static bool wled_auto_detection_required(struct wled *wled)
So cfg.auto_detection_enabled is set, but we didn't have a f
On 04.05.2018 16:37, Thierry Reding wrote:
> From: Thierry Reding
>
> Failure to register the Tegra DRM client would leak the resources. Move
> cleanup code to error unwinding gotos to fix that and share the cleanup
> code with the other error paths.
>
> Signed-off-by: Thierry Reding
> ---
> d
On Thu 03 May 02:57 PDT 2018, Kiran Gunda wrote:
> WLED4 peripheral is present on some PMICs like pmi8998
> and pm660l. It has a different register map and also
> configurations are different. Add support for it.
>
Several things are going on in this patch, it needs to be split to
not hide the f
-Using drm_display_mode_to_videomode to avoid duplicate logic
-Removed index = drm_crtc_index(crtc) as it is unused
-Replaced DRM_MODE_FLAG_* flags with DISPLAY_FLAGS_* flags
-Replaced mode->h/vdisplay with vm.h/vactive
Acked-by: Stefan Agner
Signed-off-by: Satendra Singh Thakur
Cc: Madhur Verma
On 2018-05-07 15:39, Daniel Vetter wrote:
> On Thu, May 03, 2018 at 11:12:21PM +0200, Peter Rosin wrote:
>> On 2018-05-03 11:06, Daniel Vetter wrote:
>>> On Wed, May 02, 2018 at 09:40:23AM +0200, Peter Rosin wrote:
The more natural approach would perhaps be to add an drm_bridge_add,
but t
Quoting Sean Paul (2018-05-02 12:03:16)
> On Wed, May 02, 2018 at 10:01:59AM +0530, Sandeep Panda wrote:
>
> > + struct drm_display_mode curr_mode;
> > + struct mutex lock;
> > + unsigned int ctrl_ref_count;
> > +};
> > +
> > +static const struct regmap_range ti_sn_bridge_volatile_rang
On Thu 03 May 02:57 PDT 2018, Kiran Gunda wrote:
> Handle the short circuit interrupt and check if the short circuit
> interrupt is valid. Re-enable the module to check if it goes
> away. Disable the module altogether if the short circuit event
> persists.
>
> Signed-off-by: Kiran Gunda
> ---
>
https://bugzilla.kernel.org/show_bug.cgi?id=199025
--- Comment #26 from Chen Yu (yu.c.c...@intel.com) ---
If this is highly connected with video driver, then bugzilla freedesktop might
be a better place to track this bug down since I've seldom seen any graphic
driver people jumped into kernel bug
On Mon, 2018-05-07 at 16:05 +0200, Daniel Vetter wrote:
> On Mon, May 07, 2018 at 04:16:40PM +0300, StanLis wrote:
> > From: Stanislav Lisovskiy
> >
> > Added content_type property to drm_connector_state
> > in order to properly handle external HDMI TV content-type setting.
> >
> > v2:
> > * Mo
https://bugs.freedesktop.org/show_bug.cgi?id=105733
--- Comment #14 from Koz Ross ---
I also seem to be having similar issues - I have given a full report as bug
#106434.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri
On Mon, May 07, 2018 at 03:59:04PM +0200, Peter Rosin wrote:
> On 2018-05-07 15:39, Daniel Vetter wrote:
> > On Thu, May 03, 2018 at 11:12:21PM +0200, Peter Rosin wrote:
> >> On 2018-05-03 11:06, Daniel Vetter wrote:
> >>> On Wed, May 02, 2018 at 09:40:23AM +0200, Peter Rosin wrote:
> The more
From: Stanislav Lisovskiy
Added content_type property to drm_connector_state
in order to properly handle external HDMI TV content-type setting.
v2:
* Moved helper function which attaches content type property
to the drm core, as was suggested.
Removed redundant connector state initializat
From: Stanislav Lisovskiy
Added content type setting property to drm_connector(part 1)
and enabled transmitting it with HDMI AVI infoframes
for i915(part 2).
Stanislav Lisovskiy (2):
drm: content-type property for HDMI connector
i915: content-type property for HDMI connector
Documentation/
From: Stanislav Lisovskiy
Added encoding of drm content_type property from drm_connector_state
within AVI infoframe in order to properly handle external HDMI TV
content-type setting.
This requires also manipulationg ITC bit, as stated in
HDMI spec.
v2:
* Moved helper function which attaches co
On Mon, May 07, 2018 at 04:24:43PM +0200, Peter Rosin wrote:
> On 2018-05-07 15:59, Peter Rosin wrote:
> > On 2018-05-07 15:39, Daniel Vetter wrote:
> >> On Thu, May 03, 2018 at 11:12:21PM +0200, Peter Rosin wrote:
> >>> On 2018-05-03 11:06, Daniel Vetter wrote:
> On Wed, May 02, 2018 at 09:40
On Tue, May 08, 2018 at 01:52:01AM -0300, Ezequiel Garcia wrote:
> It's perfectly possible to get dumb buffers out of drivers
> that don't support modeset. This is the case of vgem,
> which can be used to export dmabuf to run various tests.
>
> Inspired by commit f3f4c4d68a28 ("drm: Allow CAP_PRIM
On Tue, May 08, 2018 at 07:18:20AM +, Lisovskiy, Stanislav wrote:
> On Mon, 2018-05-07 at 16:05 +0200, Daniel Vetter wrote:
> > On Mon, May 07, 2018 at 04:16:40PM +0300, StanLis wrote:
> > > From: Stanislav Lisovskiy
> > >
> > > Added content_type property to drm_connector_state
> > > in orde
https://bugzilla.kernel.org/show_bug.cgi?id=199025
--- Comment #27 from todd (todd...@gmail.com) ---
@Chen
After seeing a few responses from people I'm starting to see that this is
definitely not a video driver specific issue. Not everybody is using Nouveau. I
suspected it wasn't from the start b
On Mon, May 07, 2018 at 11:26:59AM +0530, kgu...@codeaurora.org wrote:
> Hi Jingoo Han,
> Thanks for the response.
>
> Thanks,
> Kiran
> On 2018-05-04 21:25, Jingoo Han wrote:
> > On Thursday, May 3, 2018 6:12 AM, Kiran Gunda wrote:
> >
> > If you really want someone to review your patch, please
On Thu, May 03, 2018 at 03:42:28PM +0530, Kiran Gunda wrote:
> pm8941-wled.c driver is supporting the WLED peripheral
> on pm8941. Rename it to qcom-wled.c so that it can support
> WLED on multiple PMICs.
>
> Signed-off-by: Kiran Gunda
> ---
> .../bindings/leds/backlight/{pm8941-wled.txt => qcom
On 07.05.2018 15:43, Peter Rosin wrote:
> On 2018-05-07 14:59, Andrzej Hajda wrote:
>> On 04.05.2018 15:52, Peter Rosin wrote:
>>> If the bridge supplier is unbound, this will bring the bridge consumer
>>> down along with the bridge. Thus, there will no longer linger any
>>> dangling pointers from
https://bugzilla.kernel.org/show_bug.cgi?id=199653
Bug ID: 199653
Summary: [AMDGPU][DC] BUG: unable to handle kernel NULL pointer
dereference (trace decoded)
Product: Drivers
Version: 2.5
Kernel Version: drm-next-4.18-wip (agd5f,
https://bugzilla.kernel.org/show_bug.cgi?id=199653
--- Comment #1 from Marcus Husar (marcus.hu...@gmail.com) ---
Created attachment 275829
--> https://bugzilla.kernel.org/attachment.cgi?id=275829&action=edit
Original call trace of crash
--
You are receiving this mail because:
You are watching
https://bugzilla.kernel.org/show_bug.cgi?id=199653
--- Comment #2 from Marcus Husar (marcus.hu...@gmail.com) ---
Created attachment 275831
--> https://bugzilla.kernel.org/attachment.cgi?id=275831&action=edit
Journal log with amdgpu.dc_log=1 drm.debug=6
--
You are receiving this mail because:
Y
https://bugzilla.kernel.org/show_bug.cgi?id=199653
--- Comment #3 from Marcus Husar (marcus.hu...@gmail.com) ---
Created attachment 275833
--> https://bugzilla.kernel.org/attachment.cgi?id=275833&action=edit
Call trace of i2c designware warning (taints kernel)
--
You are receiving this mail be
drm_dev_alloc() returns error pointers, it never returns NULL.
Fixes: c575b7eeb89f ("drm/xen-front: Add support for Xen PV display frontend")
Signed-off-by: Dan Carpenter
diff --git a/drivers/gpu/drm/xen/xen_drm_front.c
b/drivers/gpu/drm/xen/xen_drm_front.c
index 1b0ea9ac330e..8615e8522c7a 1006
The xen_drm_front_shbuf_alloc() function was returning a mix of error
pointers and NULL and the the caller wasn't checking correctly. I've
changed it to always return error pointer consistently.
Fixes: c575b7eeb89f ("drm/xen-front: Add support for Xen PV display frontend")
Signed-off-by: Dan Carp
If the loop times out then we want to exit with "to" set to zero, but in
the current code it's set to -1.
Fixes: c575b7eeb89f ("drm/xen-front: Add support for Xen PV display frontend")
Signed-off-by: Dan Carpenter
diff --git a/drivers/gpu/drm/xen/xen_drm_front.c
b/drivers/gpu/drm/xen/xen_drm_fr
On 05/08/2018 12:26 PM, Dan Carpenter wrote:
drm_dev_alloc() returns error pointers, it never returns NULL.
Fixes: c575b7eeb89f ("drm/xen-front: Add support for Xen PV display frontend")
Signed-off-by: Dan Carpenter
Thank you,
Reviewed-by: Oleksandr Andrushchenko
diff --git a/drivers/gpu/dr
DSI driver is not really interested in this interrupt. It causes only
unnecessary code execution of interrupt handler and could possibly
cause FIFO overflow - as it triggers DSI interrupt handler to process
next DSI transfer. With this patch we will get rid of about 30 IRQ
handler calls per second.
On 05/08/2018 12:27 PM, Dan Carpenter wrote:
The xen_drm_front_shbuf_alloc() function was returning a mix of error
pointers and NULL and the the caller wasn't checking correctly. I've
changed it to always return error pointer consistently.
Fixes: c575b7eeb89f ("drm/xen-front: Add support for Xe
On 05/08/2018 12:28 PM, Dan Carpenter wrote:
If the loop times out then we want to exit with "to" set to zero, but in
the current code it's set to -1.
Fixes: c575b7eeb89f ("drm/xen-front: Add support for Xen PV display frontend")
Signed-off-by: Dan Carpenter
Thank you,
Reviewed-by: Oleksandr A
https://bugzilla.kernel.org/show_bug.cgi?id=199025
--- Comment #28 from Paul van Maaren (ker...@vanmaaren.org) ---
I will change the runlevel to text and see if it resolves the problem. I assume
I can test by typing: "echo mem > /sys/power/state" ?
--
You are receiving this mail because:
You are
Hi Dirk,
On 7 May 2018 at 00:16, Dirk Hohndel (VMware) wrote:
> These files are licensed under GPL-2.0.
> Removing the MIT boilerplate as that really didn't make any sense for
> those two header files.
>
> Signed-off-by: Dirk Hohndel (VMware)
> ---
> drivers/gpu/drm/vmwgfx/Kconfig
Quoting Chris Wilson (2018-02-08 10:09:06)
> sync_dump() is an unused, unexported, function that adds 64k to the
> kernel image and doesn't even provide locking around the global array it
> uses.
>
> add/remove: 0/2 grow/shrink: 0/0 up/down: 0/-65734 (-65734)
> Function
On Tue, May 08, 2018 at 09:58:49AM +0200, Peter Rosin wrote:
> On 2018-05-08 08:51, Jyri Sarha wrote:
> > On 05/04/18 16:51, Peter Rosin wrote:
> >> It gets rid of an #ifdef and the .of_node member is going away.
> >>
> >> Signed-off-by: Peter Rosin
> >> ---
> >> drivers/gpu/drm/bridge/panel.c |
On Thu, May 03, 2018 at 03:42:30PM +0530, Kiran Gunda wrote:
> Handle the short circuit interrupt and check if the short circuit
> interrupt is valid. Re-enable the module to check if it goes
> away. Disable the module altogether if the short circuit event
> persists.
>
> Signed-off-by: Kiran Gund
On Thu, May 03, 2018 at 03:42:31PM +0530, Kiran Gunda wrote:
> WLED peripheral has over voltage protection(OVP) circuitry and the OVP
> fault is notified through an interrupt. Though this fault condition rising
> is due to an incorrect hardware configuration is mitigated in the hardware,
> it still
On Mon, May 07, 2018 at 05:09:21PM +0200, Daniel Vetter wrote:
> On Mon, May 07, 2018 at 02:33:25PM +0100, Chris Wilson wrote:
> > Quoting Feng Tang (2018-05-07 22:26:34)
> > > Hi Chris,
> > >
> > > Thanks for the prompt review!
> > >
> > > On Mon, May 07, 2018 at 11:40:45AM +0100, Chris Wilson
From: Ankit Nautiyal
This patch series is a re-attempt to enable aspect ratio support in
DRM layer. Currently the aspect ratio information gets lost in translation
during a user->kernel mode or vice versa.
The old patch series (https://pw-emeril.freedesktop.org/series/10850/) had
4 patches, out
From: Ville Syrjälä
Make mode matching less confusing by allowing the caller to specify
which parts of the modes should match via some flags.
Signed-off-by: Ville Syrjälä
Reviewed-by: Shashank Sharma
---
drivers/gpu/drm/drm_modes.c | 134 ++--
include/d
From: Ville Syrjälä
commit 6dffd431e229 ("drm: Add aspect ratio parsing in DRM layer")
cause us to not send out any VICs in the AVI infoframes. That commit
was since reverted, but if and when we add aspect ratio handing back
we need to be more careful.
Let's handle this by considering the aspect
From: Ville Syrjälä
If the user mode would specify an aspect ratio other than 4:3 or 16:9
we now silently ignore it. Maybe a better apporoach is to return an
error? Let's try that.
Also we must be careful that we don't try to send illegal picture
aspect in the infoframe as it's only capable of s
From: Ville Syrjälä
Use drm_mode_equal_no_clocks_no_stereo() in
drm_match_hdmi_mode_clock_tolerance() for consistency as we
also use it in drm_match_hdmi_mode() and the cea mode matching
functions.
This doesn't actually change anything since the input mode
comes from detailed timings and we matc
From: "Sharma, Shashank"
Current DRM layer functions don't parse aspect ratio information
while converting a user mode->kernel mode or vice versa. This
causes modeset to pick mode with wrong aspect ratio, eventually
causing failures in HDMI compliance test cases, due to wrong VIC.
This patch add
From: "Sharma, Shashank"
HDMI 2.0/CEA-861-F introduces two new aspect ratios:
- 64:27
- 256:135
This patch:
- Adds new DRM flags for to represent these new aspect ratios.
- Adds new cases to handle these aspect ratios while converting
from user->kernel mode or vise versa.
This patch was once
From: Ville Syrjälä
AVI infoframe can only carry none, 4:3, or 16:9 picture aspect
ratios. Return an error if the user asked for something different.
Cc: Shashank Sharma
Cc: "Lin, Jia"
Cc: Akashdeep Sharma
Cc: Jim Bride
Cc: Jose Abreu
Cc: Daniel Vetter
Cc: Emil Velikov
Cc: Thierry Reding
From: Ankit Nautiyal
If the user-space does not support aspect-ratio, and requests for a
modeset with mode having aspect ratio bits set, then the given
user-mode must be rejected. Secondly, while preparing a user-mode from
kernel mode, the aspect-ratio info must not be given, if aspect-ratio
is n
From: Ankit Nautiyal
To enable aspect-ratio support in DRM, blindly exposing the aspect
ratio information along with mode, can break things in existing
non-atomic user-spaces which have no intention or support to use this
aspect ratio information.
To avoid this, a new drm client cap is required
From: Ankit Nautiyal
We parse the EDID and add all the modes in the connector's modelist.
This adds CEA modes with aspect ratio information too, regardless of
whether user space requested this information or not.
This patch:
-prunes the modes with aspect-ratio information, from the
drm_mode_get
Quoting Feng Tang (2018-05-08 20:03:15)
>
> On Mon, May 07, 2018 at 05:09:21PM +0200, Daniel Vetter wrote:
> > On Mon, May 07, 2018 at 02:33:25PM +0100, Chris Wilson wrote:
> > > Quoting Feng Tang (2018-05-07 22:26:34)
> > > > Hi Chris,
> > > >
> > > > Thanks for the prompt review!
> > > >
> > >
On 05/08/2018 12:37 PM, Oleksandr Andrushchenko wrote:
On 05/08/2018 12:28 PM, Dan Carpenter wrote:
If the loop times out then we want to exit with "to" set to zero, but in
the current code it's set to -1.
Fixes: c575b7eeb89f ("drm/xen-front: Add support for Xen PV display
frontend")
Signed-o
On 05/08/2018 12:37 PM, Oleksandr Andrushchenko wrote:
On 05/08/2018 12:27 PM, Dan Carpenter wrote:
The xen_drm_front_shbuf_alloc() function was returning a mix of error
pointers and NULL and the the caller wasn't checking correctly. I've
changed it to always return error pointer consistently.
On 05/08/2018 12:34 PM, Oleksandr Andrushchenko wrote:
On 05/08/2018 12:26 PM, Dan Carpenter wrote:
drm_dev_alloc() returns error pointers, it never returns NULL.
Fixes: c575b7eeb89f ("drm/xen-front: Add support for Xen PV display
frontend")
Signed-off-by: Dan Carpenter
Thank you,
Reviewed-
On Tue, May 8, 2018 at 1:33 PM, Chris Wilson wrote:
> Quoting Feng Tang (2018-05-08 20:03:15)
>>
>> On Mon, May 07, 2018 at 05:09:21PM +0200, Daniel Vetter wrote:
>> > On Mon, May 07, 2018 at 02:33:25PM +0100, Chris Wilson wrote:
>> > > Quoting Feng Tang (2018-05-07 22:26:34)
>> > > > Hi Chris,
>>
On 05/08/18 10:58, Peter Rosin wrote:
> On 2018-05-08 08:51, Jyri Sarha wrote:
>> On 05/04/18 16:51, Peter Rosin wrote:
>>> It gets rid of an #ifdef and the .of_node member is going away.
>>>
>>> Signed-off-by: Peter Rosin
>>> ---
>>> drivers/gpu/drm/bridge/panel.c | 4 +---
>>> 1 file changed, 1
https://bugs.freedesktop.org/show_bug.cgi?id=105786
cd changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
With etnaviv not being tied into the IOMMU framework anymore, the MMU
functions will only be called under sleeping locks. Thus we are able
to allocate the memory for the 2nd level page tables on demand without
having to deal with memory allocation in atomic context.
This speeds up driver intitiali
We are likely to write multiple page entries at once and already ensure
proper write buffer flushing before GPU submit, so this improves CPU
time usage in the submit path without any downsides.
Signed-off-by: Lucas Stach
---
v2: use shorter _wc function names.
---
drivers/gpu/drm/etnaviv/etnaviv
MMUv2 supports up to 40 bits of physical address by folding the upper
8 bits into bits [4:11] of the PTE.
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/etnaviv/etnaviv_iommu_v2.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_iommu_v2.c
On Mon, May 07, 2018 at 10:15:46PM +0200, Paul Kocialkowski wrote:
> > > + backlight: backlight {
> > > + compatible = "pwm-backlight";
> > > + pwms = <&pwm 0 5 PWM_POLARITY_INVERTED>;
> > > + brightness-levels = <0 10 20 30 40 50 60 70 80 90 100>;
> >
> > The increase
https://bugzilla.kernel.org/show_bug.cgi?id=199655
Bug ID: 199655
Summary: amdgpu: XFX Radeon RX 580 runs its fans only in
dangerously low speeds and ignores temperature
Product: Drivers
Version: 2.5
Kernel Version: 4.16.7
https://bugzilla.kernel.org/show_bug.cgi?id=199655
--- Comment #1 from Sergey Kondakov (virtuous...@gmail.com) ---
Created attachment 275837
--> https://bugzilla.kernel.org/attachment.cgi?id=275837&action=edit
lspci_2018-05-08-quircks
--
You are receiving this mail because:
You are watching th
This replaces the repetitive GPL-2.0 license text in code and header files
with the SPDX tags. Generated hardware headers aren't changed, as any changes
there need to be done in the upstream rnndb repository.
Signed-off-by: Lucas Stach
---
Christian, I've replaced some of your copyright statement
>> > > > On Mon, May 07, 2018 at 11:40:45AM +0100, Chris Wilson wrote:
> >> > > > > Quoting Feng Tang (2018-05-07 11:36:09)
> >> > > > > > To fulfil the Dell 4K monitor, the dpcd max retries has been
> >> > > > > > bumped
> >> > > > > > from 7 to 32, which may hurt the boot/init time for some
>
https://bugs.freedesktop.org/show_bug.cgi?id=106441
Bug ID: 106441
Summary: Totem video playback stuttering and graphical
artifacts
Product: Mesa
Version: 18.0
Hardware: x86-64 (AMD64)
OS: Linux (All)
On Mon, 7 May 2018 06:35:36 -0300
Mauro Carvalho Chehab wrote:
> I decided to give a try with Sphinx last stable version
> (1.17.4), and noticed several issues. The worse one was
> with the networking book: a non-standard footnote there
> with [*] instead of a number causes it to break PDF build
https://bugs.freedesktop.org/show_bug.cgi?id=106441
Michel Dänzer changed:
What|Removed |Added
Attachment #139426|text/x-log |text/plain
mime type|
-ci/linux/commits/Bibby-Hsieh/drm-mediatek-support-hdmi-output-for-mt2701-and-mt7623/20180508-140924
base: git://people.freedesktop.org/~airlied/linux.git drm-next
config: arm-allyesconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget
https
On Tue, May 08, 2018 at 10:13:42AM -0600, Jonathan Corbet wrote:
> On Mon, 7 May 2018 06:35:36 -0300
> Mauro Carvalho Chehab wrote:
>
> > I decided to give a try with Sphinx last stable version
> > (1.17.4), and noticed several issues. The worse one was
> > with the networking book: a non-standa
WHi Alex,
On Thu, Apr 19, 2018 at 4:13 PM, Alex Deucher wrote:
https://bugs.freedesktop.org/show_bug.cgi?id=105684
>>>
>>> No progress made on that bug report so far.
>>> What can we do to help this advance?
>>
>> Ping, any news here? How can we help advance on this bug?
>
> Can you try one
https://bugzilla.kernel.org/show_bug.cgi?id=199025
--- Comment #29 from Paul van Maaren (ker...@vanmaaren.org) ---
I just did the runlevel test and it does not make difference for me. I did:
ln -sf /usr/lib/systemd/system/multi-user.target
/etc/systemd/system/default.target
and a reboot to 4.16
On Fri, May 04, 2018 at 03:18:00PM -0700, matthew.s.atw...@intel.com wrote:
> From: Matt Atwood
>
> DP_TRAINING_AUX_RD_INTERVAL with DP 1.3 spec changed bit scheeme from 8
> bits to 7 in DPCD 0x000e. The 8th bit is used to identify extended
> receiver capabilities. For panels that use this new fe
On Wed, 09 May 2018, Feng Tang wrote:
> >> > > > On Mon, May 07, 2018 at 11:40:45AM +0100, Chris Wilson wrote:
>> >> > > > > Quoting Feng Tang (2018-05-07 11:36:09)
>> >> > > > > > To fulfil the Dell 4K monitor, the dpcd max retries has been
>> >> > > > > > bumped
>> >> > > > > > from 7 to 32, w
https://bugs.freedesktop.org/show_bug.cgi?id=106228
--- Comment #1 from Alex Deucher ---
Harry, I thought we fixed something like this recently. Maybe this patch?
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c3d7bad88e3b35b981eecc1645ddbb3f13a8b54f
--
You are r
https://bugzilla.kernel.org/show_bug.cgi?id=199025
--- Comment #30 from Patrice (p.pol...@free.fr) ---
I can't access the faulty machine until next Saturday - but it runs Fedora28's
latest Xfce .
--
You are receiving this mail because:
You are watching the assignee of the bug.
__
https://bugs.freedesktop.org/show_bug.cgi?id=106228
--- Comment #2 from Harry Wentland ---
That patch only affects Carrizo and should only be needed for S3.
We don't see this issue with Ubuntu 18.04 on a Raven laptop we have available.
The OS (Gnome) shows brightness as expected on boot.
I wond
https://bugs.freedesktop.org/show_bug.cgi?id=106402
--- Comment #1 from Alex Deucher ---
Please attach your full dmesg output and xorg log if you are using X.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel maili
https://bugs.freedesktop.org/show_bug.cgi?id=106177
--- Comment #5 from Alex Deucher ---
Please use debugfs (e.g., /sys/kernel/debug/dri/0/amdgpu_pm_info) to check the
current clocks.
--
You are receiving this mail because:
You are the assignee for the bug.__
https://bugs.freedesktop.org/show_bug.cgi?id=106404
Alex Deucher changed:
What|Removed |Added
Product|DRI |Mesa
QA Contact|
On Thu, May 3, 2018 at 11:41 AM, Dirk Hohndel wrote:
> On Thu, May 03, 2018 at 08:46:20AM -0400, Sean Paul wrote:
>>
>> Thank you for the awesome summary, it is very helpful! So since the
>> boilerplate
>> has to stay, is there a benefit to adding the SPDX header? Is it just to make
>> scripting/
https://bugs.freedesktop.org/show_bug.cgi?id=106303
--- Comment #4 from Alex Deucher ---
Can you bisect? Are you using multiple monitors?
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@li
1 - 100 of 141 matches
Mail list logo
