https://bugs.freedesktop.org/show_bug.cgi?id=110749
--- Comment #4 from Cyrax ---
Created attachment 144516
--> https://bugs.freedesktop.org/attachment.cgi?id=144516=edit
dmesg event umr dumps as usual
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=110822
--- Comment #18 from Gobinda Joy ---
(In reply to b6khqjqov4 from comment #17)
> (In reply to Gobinda Joy from comment #16)
> > This doesn't seems like the same bug. For instance, in my case the whole
> > boot process hangs check the attached
Port the sky81452-backlight driver to adhere to new gpio descriptor based
APIs. Modified the file sky81452-backlight.c and sky81452-backlight.h.
The gpio descriptor property in device tree should be "sky81452-en-gpios"
Removed unnecessary header files "linux/gpio.h" and "linux/of_gpio.h".
On 2019.05.26 13:26:33 +0530, Hariprasad Kelam wrote:
> Remove duplicate include of trace.h
>
> Issue identified by includecheck
>
> Signed-off-by: Hariprasad Kelam
> ---
> drivers/gpu/drm/i915/gvt/trace_points.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git
https://bugzilla.kernel.org/show_bug.cgi?id=203627
--- Comment #5 from Aleksandr Mezin (mezin.alexan...@gmail.com) ---
(In reply to Aleksandr Mezin from comment #2)
> vega10_sos.bin
>
> Copying that file from previous firmware release into /lib/firmware/amdgpu
> makes the system boot again with
This adds support on GF119:GV100 (exclusive) for CTM (aka CSC).
Signed-off-by: Ilia Mirkin
---
v1 -> v2:
- ctm -> csc
- mark csc.valid = false when there is no ctm property
drivers/gpu/drm/nouveau/dispnv50/atom.h | 6 ++
drivers/gpu/drm/nouveau/dispnv50/base907c.c | 65
On Tue, Jun 11, 2019 at 02:30:38PM +0200, Daniel Vetter wrote:
> On Tue, Jun 11, 2019 at 11:13:45AM +, Lowry Li (Arm Technology China)
> wrote:
> > From: "Lowry Li (Arm Technology China)"
> >
> > The komeda internal resources (pipelines) are shared between crtcs,
> > and resources release by
Hi all,
Today's linux-next merge of the drm-misc tree got a conflict in:
drivers/gpu/drm/amd/display/dc/dce/dce_audio.c
between commit:
c7c7192c56d2 ("drm/amd/display: add audio related regs")
from the amdgpu tree and commit:
4fc4dca8320e ("drm/amd: drop use of drmp.h in os_types.h")
https://bugs.freedesktop.org/show_bug.cgi?id=110897
--- Comment #9 from Richard Thier ---
So these does not seem to happen at any time:
/* Emit clear packets. */
r300_emit_gpu_flush(r300, r300->gpu_flush.size, r300->gpu_flush.state);
r300->gpu_flush.dirty = FALSE;
Commit f13e143e7444 ("dma-buf: start caching of sg_table objects v2")
added a support of caching the sgt pointer into an attach pointer to
let users reuse the sgt pointer without another mapping. However, it
might not totally work as most of dma-buf callers are doing attach()
and map_attachment()
The input bytesperline calculation for packed pixel formats was
incorrect. The min/max clamping values must be multiplied by the
packed bits-per-pixel. This was causing corrupted converted images
when the input format was RGB4 (probably also other input packed
formats).
Fixes: d966e23d61a2c
The output of the IC downsizer unit in both dimensions must be <= 1024
before being passed to the IC resizer unit. This was causing corrupted
images when:
input_dim > 1024, and
input_dim / 2 < output_dim < input_dim
Some broken examples were 1920x1080 -> 1024x768 and 1920x1080 ->
1280x1080.
The output width and height alignment values were being used in the
input bytesperline calculation. Fix by separating local vars w_align
and h_align into w_align_in, h_align_in, w_align_out, and h_align_out.
Fixes: d966e23d61a2c ("gpu: ipu-v3: image-convert: fix bytesperline
adjustment")
https://bugs.freedesktop.org/show_bug.cgi?id=110897
--- Comment #8 from Richard Thier ---
I think I see a bug happening here and we are not emitting the relevant things.
A bit tired now for the night...
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=110897
--- Comment #7 from Richard Thier ---
Created attachment 144515
--> https://bugs.freedesktop.org/attachment.cgi?id=144515=edit
Log output for "added logging" patch
As you can see the "KUL-D" and the "KULAKVA-n" log messages never gets
https://bugs.freedesktop.org/show_bug.cgi?id=110781
Marek Olšák changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://bugs.freedesktop.org/show_bug.cgi?id=110897
--- Comment #6 from Richard Thier ---
Created attachment 144514
--> https://bugs.freedesktop.org/attachment.cgi?id=144514=edit
Added logging - magically works but slow from logging!
This is what I am running with now. There are no other
On Tue, Jun 11, 2019 at 1:54 AM Hans de Goede wrote:
>
> Hi,
>
> On 11-06-19 10:08, Jani Nikula wrote:
> > On Mon, 10 Jun 2019, Derek Basehore wrote:
> >> This removes the orientation quirk detection from the code to add
> >> an orientation property to a panel. This is used only for legacy x86
>
On Tue, Jun 11, 2019 at 5:00 PM Shyam Saini
wrote:
>
> Currently, there are 3 different macros, namely sizeof_field, SIZEOF_FIELD
> and FIELD_SIZEOF which are used to calculate the size of a member of
> structure, so to bring uniformity in entire kernel source tree lets use
> FIELD_SIZEOF and
https://bugs.freedesktop.org/show_bug.cgi?id=110897
--- Comment #5 from Richard Thier ---
Hi!
Was it looking similar? Was it solved for your case?
Btw I just started to have insights on what the hardware does, but might need
to work a bit in the wine field because of the good weather so if I
https://bugs.freedesktop.org/show_bug.cgi?id=110897
--- Comment #4 from cosiek...@o2.pl ---
Hello you all! Couple of years ago I did tests HyperZ
https://bugs.freedesktop.org/show_bug.cgi?id=37724
Maybe you will find this link useful!
--
You are receiving this mail because:
You are the assignee
https://bugs.freedesktop.org/show_bug.cgi?id=110897
--- Comment #3 from Richard Thier ---
H... I must have made a measurement error as looking at the code the small
patch of mine cannot be slower than before it when not using HYPERZ...
--
You are receiving this mail because:
You are the
https://bugs.freedesktop.org/show_bug.cgi?id=110781
--- Comment #67 from Rui Salvaterra ---
(In reply to Richard Thier from comment #66)
> Is there any indicator to look for? Like shader files on disk at some places
> or near the runned binary or current dir or whatever with this or that name?
On Sat, Jun 08, 2019 at 03:02:29PM +0800, Jitao Shi wrote:
> Add documentation for boe tv101wum-n16 panel.
Typo in the subject and checkpatch complains about trailing whitespace.
>
> Signed-off-by: Jitao Shi
> ---
> .../display/panel/boe,tv101wum-nl6.txt| 34 +++
> 1
https://bugs.freedesktop.org/show_bug.cgi?id=110844
--- Comment #7 from nathaniel.h...@protonmail.com ---
Created attachment 144513
--> https://bugs.freedesktop.org/attachment.cgi?id=144513=edit
A xorg.log.old from last boot before i reproduced the issue
--
You are receiving this mail
https://bugs.freedesktop.org/show_bug.cgi?id=110844
--- Comment #8 from nathaniel.h...@protonmail.com ---
I also attached a xorg.log.old hoping that might help.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel
On Tue, Jun 11, 2019 at 03:52:06PM -0600, Rob Herring wrote:
> On Mon, 27 May 2019 18:22:35 +0200, meg...@megous.com wrote:
> > From: Ondrej Jirman
> >
> > Some Allwinner SoC using boards (Orange Pi 3 for example) need to enable
> > on-board voltage shifting logic for the DDC bus using a gpio to
Hi Jacek,
On Tue, Jun 11, 2019 at 10:02:23PM +0200, Jacek Anaszewski wrote:
> Hi Matthias,
>
> On 6/11/19 1:37 AM, Matthias Kaehlcke wrote:
> > Add an optional 'max-brightness' property, which is used to specify
> > the number of brightness levels (max-brightness + 1) when the node
> > has no
On Tue, Jun 11, 2019 at 8:25 AM Rob Herring wrote:
>
> On Mon, Jun 10, 2019 at 10:03 PM Derek Basehore
> wrote:
> >
> > This adds to the rotation documentation to explain how drivers should
> > use the property and gives an example of the property in a devicetree
> > node.
> >
> >
> On Jun 11, 2019, at 2:20 PM, Thomas Hellström (VMware)
> wrote:
>
> On 6/11/19 9:10 PM, Nadav Amit wrote:
>>> On Jun 11, 2019, at 11:26 AM, Thomas Hellström (VMware)
>>> wrote:
>>>
>>> Hi, Nadav,
>>>
>>> On 6/11/19 7:21 PM, Nadav Amit wrote:
> On Jun 11, 2019, at 5:24 AM, Thomas
Hi Pavel,
On Tue, Jun 11, 2019 at 12:18:43PM +0200, Pavel Machek wrote:
> On Mon 2019-06-10 16:37:39, Matthias Kaehlcke wrote:
> > Commit 88ba95bedb79 ("backlight: pwm_bl: Compute brightness of LED
> > linearly to human eye") uses pwm_period / hweight32(pwm_period) as
> > as heuristic to
On Mon, 3 Jun 2019 17:23:30 +0200, Paul Cercueil wrote:
> Add documentation for the devicetree bindings of the LCD controller present in
> the JZ47xx family of SoCs from Ingenic.
>
> Signed-off-by: Paul Cercueil
> Tested-by: Artur Rojek
> ---
>
> Notes:
> v2: Remove ingenic,panel
https://bugs.freedesktop.org/show_bug.cgi?id=110844
--- Comment #6 from nathaniel.h...@protonmail.com ---
(In reply to Alex Deucher from comment #4)
> You said it started happening for week or two ago. What component(s) did
> you update at that time?
Ive been trying to fix my issue a bit more
On Mon, 27 May 2019 18:22:35 +0200, meg...@megous.com wrote:
> From: Ondrej Jirman
>
> Some Allwinner SoC using boards (Orange Pi 3 for example) need to enable
> on-board voltage shifting logic for the DDC bus using a gpio to be able
> to access DDC bus. Use ddc-en-gpios property on the
Hi Thierry,
On Tue, Jun 11, 2019 at 12:28:51PM +0200, Thierry Reding wrote:
> On Mon, Jun 10, 2019 at 04:37:38PM -0700, Matthias Kaehlcke wrote:
> > Add an optional 'max-brightness' property, which is used to specify
> > the number of brightness levels (max-brightness + 1) when the node
> > has
Hi Andrew,
>
> On Tue, 11 Jun 2019 15:00:10 -0600 Andreas Dilger wrote:
>
> > >> to FIELD_SIZEOF
> > >
> > > As Alexey has pointed out, C structs and unions don't have fields -
> > > they have members. So this is an opportunity to switch everything to
> > > a new member_sizeof().
> > >
> > >
On Jun 11, 2019, at 3:09 PM, Andrew Morton wrote:
>
> On Tue, 11 Jun 2019 15:00:10 -0600 Andreas Dilger wrote:
>
to FIELD_SIZEOF
>>>
>>> As Alexey has pointed out, C structs and unions don't have fields -
>>> they have members. So this is an opportunity to switch everything to
>>> a new
On 6/11/19 9:10 PM, Nadav Amit wrote:
On Jun 11, 2019, at 11:26 AM, Thomas Hellström (VMware)
wrote:
Hi, Nadav,
On 6/11/19 7:21 PM, Nadav Amit wrote:
On Jun 11, 2019, at 5:24 AM, Thomas Hellström (VMware)
wrote:
From: Thomas Hellstrom
[ snip ]
+/**
+ * apply_pt_wrprotect - Leaf pte
On Tue, 11 Jun 2019 15:00:10 -0600 Andreas Dilger wrote:
> >> to FIELD_SIZEOF
> >
> > As Alexey has pointed out, C structs and unions don't have fields -
> > they have members. So this is an opportunity to switch everything to
> > a new member_sizeof().
> >
> > What do people think of that
Hi Kees,
Cc'ing William Kucharski,
> On Wed, Jun 12, 2019 at 01:08:36AM +0530, Shyam Saini wrote:
> > In favour of FIELD_SIZEOF, this patch also deprecates other two similar
> > macros sizeof_field and SIZEOF_FIELD.
> >
> > For code compatibility reason, retain sizeof_field macro as a wrapper
On Jun 11, 2019, at 2:48 PM, Andrew Morton wrote:
>
> On Wed, 12 Jun 2019 01:08:36 +0530 Shyam Saini
> wrote:
>
>> Currently, there are 3 different macros, namely sizeof_field, SIZEOF_FIELD
>> and FIELD_SIZEOF which are used to calculate the size of a member of
>> structure, so to bring
Hi Sean.
Small things here and there. Did not stare at this long enough to
understand the code, but added some feedback anyway.
Sam
>
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index d36feb4a62330..9d630a28a7880 100644
> --- a/drivers/gpu/drm/Makefile
> +++
From: Laurent Pinchart
Add functions to the atomic core to retrieve the old and new connectors
associated with an encoder in a drm_atomic_state. This is useful for
encoders and bridges that need to access the connector, for instance for
the drm_display_info.
The CRTC associated with the encoder
From: Sean Paul
This patch adds atomic_enable and atomic_disable callbacks to the
encoder helpers. This will allow encoders to make informed decisions in
their start-up/shutdown based on the committed state.
Aside from the new hooks, this patch also introduces the new signature
for .atomic_*
On Wed, 12 Jun 2019 01:08:36 +0530 Shyam Saini
wrote:
> Currently, there are 3 different macros, namely sizeof_field, SIZEOF_FIELD
> and FIELD_SIZEOF which are used to calculate the size of a member of
> structure, so to bring uniformity in entire kernel source tree lets use
> FIELD_SIZEOF and
On Wed, Jun 12, 2019 at 01:08:36AM +0530, Shyam Saini wrote:
> In favour of FIELD_SIZEOF, this patch also deprecates other two similar
> macros sizeof_field and SIZEOF_FIELD.
>
> For code compatibility reason, retain sizeof_field macro as a wrapper macro
> to FIELD_SIZEOF
Can you explain this
Hi Thomas.
On Tue, Jun 11, 2019 at 03:03:40PM +0200, Thomas Zimmermann wrote:
> Another explicit lock operation of a GEM VRAM BO is located in AST's
> framebuffer update code. Instead of locking the BO, we pin it to wherever
> it is.
>
> v2:
> * update with pin flag of 0
>
>
On Tue, Jun 11, 2019 at 11:50 AM Stephen Boyd wrote:
>
> Quoting Brendan Higgins (2019-06-11 10:58:30)
> > On Fri, Jun 07, 2019 at 12:00:47PM -0700, Stephen Boyd wrote:
> > > Quoting Iurii Zaikin (2019-06-05 18:29:42)
> > > > On Fri, May 17, 2019 at 11:22 AM Stephen Boyd wrote:
> > > > >
> > > >
On Tue, Jun 11, 2019 at 08:53:52PM +0200, Sam Ravnborg wrote:
> Hi Sean.
>
> Nits below.
>
> >
> > + /**
> > +* @atomic_disable:
> > +*
> ...
> > +*
> > +* This callback is a variant of @disable that provides the atomic state
> > +* to the driver. It takes priority over
On Fri, Jun 07, 2019 at 02:06:03PM -0400, Sean Paul wrote:
> On Thu, Jun 06, 2019 at 03:58:21PM -0700, Doug Anderson wrote:
> > Hi,
> >
> > On Thu, Jun 6, 2019 at 9:42 AM Sean Paul wrote:
> > >
> > > On Tue, Jun 04, 2019 at 01:42:07PM -0700, Douglas Anderson wrote:
> > > > On Rockchip
Hi Matthias,
On 6/11/19 1:37 AM, Matthias Kaehlcke wrote:
Add an optional 'max-brightness' property, which is used to specify
the number of brightness levels (max-brightness + 1) when the node
has no 'brightness-levels' table.
Signed-off-by: Matthias Kaehlcke
---
https://bugs.freedesktop.org/show_bug.cgi?id=110381
--- Comment #7 from Nicholas Kazlauskas ---
I think this is fixed 5.2 and the latest amd-staging-drm-next.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel
Currently, there are 3 different macros, namely sizeof_field, SIZEOF_FIELD
and FIELD_SIZEOF which are used to calculate the size of a member of
structure, so to bring uniformity in entire kernel source tree lets use
FIELD_SIZEOF and replace all occurrences of other two macros with this.
For this
https://bugs.freedesktop.org/show_bug.cgi?id=110381
--- Comment #6 from John Francis ---
I get this on kernel 5.1.8 when I use a KVM switch with DisplayPort
daisy-chained MST monitors. It occurs when I switch back.
I can workaround by powering off the last monitor in the chain, and then
https://bugs.freedesktop.org/show_bug.cgi?id=108505
Marcin Deranek changed:
What|Removed |Added
Resolution|--- |WORKSFORME
Status|NEW
> On Jun 11, 2019, at 11:26 AM, Thomas Hellström (VMware)
> wrote:
>
> Hi, Nadav,
>
> On 6/11/19 7:21 PM, Nadav Amit wrote:
>>> On Jun 11, 2019, at 5:24 AM, Thomas Hellström (VMware)
>>> wrote:
>>>
>>> From: Thomas Hellstrom
>> [ snip ]
>>
>>> +/**
>>> + * apply_pt_wrprotect - Leaf pte
Hi Sean.
I got a parse error due to missing ')' in $subject :-)
The rest (changelog, patch) looked fine to me.
Sam
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
The A540 is a derivative of the A530, and is found in the MSM8998 SoC.
Signed-off-by: Jeffrey Hugo
---
v3:
-Adjusted MERCIU for A540 for best performance.
drivers/gpu/drm/msm/adreno/a5xx.xml.h | 28
drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 26 +++-
Hi Sean.
Nits below.
>
> + /**
> + * @atomic_disable:
> + *
...
> + *
> + * This callback is a variant of @disable that provides the atomic state
> + * to the driver. It takes priority over @disable during atomic commits.
> + *
> + * This hook is used
Quoting Brendan Higgins (2019-06-11 10:58:30)
> On Fri, Jun 07, 2019 at 12:00:47PM -0700, Stephen Boyd wrote:
> > Quoting Iurii Zaikin (2019-06-05 18:29:42)
> > > On Fri, May 17, 2019 at 11:22 AM Stephen Boyd wrote:
> > > >
> > > > Quoting Brendan Higgins (2019-05-14 15:17:10)
> > > > > diff
Hi, Nadav,
On 6/11/19 7:21 PM, Nadav Amit wrote:
On Jun 11, 2019, at 5:24 AM, Thomas Hellström (VMware)
wrote:
From: Thomas Hellstrom
[ snip ]
+/**
+ * apply_pt_wrprotect - Leaf pte callback to write-protect a pte
+ * @pte: Pointer to the pte
+ * @token: Page table token, see
https://bugs.freedesktop.org/show_bug.cgi?id=110781
--- Comment #66 from Richard Thier ---
> Yes, I think it's a good idea to open a new bug.
Added seperate bug for working on HyperZ glitches:
https://bugs.freedesktop.org/show_bug.cgi?id=110897
> By the way, I have a vague memory of HiZ on
On Tue, Jun 11, 2019 at 8:05 PM Mauro Carvalho Chehab
wrote:
>
> Em Tue, 11 Jun 2019 19:52:04 +0300
> Andy Shevchenko escreveu:
>
> > On Fri, Jun 7, 2019 at 10:04 PM Mauro Carvalho Chehab
> > wrote:
> > > Sphinx doesn't like orphan documents:
> >
> > > Documentation/laptops/lg-laptop.rst:
https://bugs.freedesktop.org/show_bug.cgi?id=110897
--- Comment #2 from Richard Thier ---
Created attachment 144512
--> https://bugs.freedesktop.org/attachment.cgi?id=144512=edit
Error gone patch - but it is slow
If I understand it well, HyperZ can be owned by only one process / owner and
the
Hi Michael,
Thank you for the patch.
On Tue, Jun 11, 2019 at 03:04:09PM +0100, Michael Drake wrote:
> Adds device tree bindings for:
>
> TI DS90UB949-Q1 1080p HDMI to FPD-Link III bridge serializer
>
> It supports instantiation via device tree / ACPI table.
>
> The device has the compatible
Hi Michael,
Thank you for the patch.
On Tue, Jun 11, 2019 at 03:04:08PM +0100, Michael Drake wrote:
> This may be used by userspace to determine the state
> of the device.
Why is this needed ? Userspace shouldn't even be aware that this device
exists.
> Signed-off-by: Michael Drake
> Cc:
Hi Michael,
Thank you for the patch.
On Tue, Jun 11, 2019 at 03:04:07PM +0100, Michael Drake wrote:
> If the alive check detects a transition to the alive state,
> the device configuration is rewritten.
This seems like a big hack. You will have at the very least to explain
why this is needed,
On Tue, Jun 11, 2019 at 07:39:12PM +0200, Daniel Vetter wrote:
> On Tue, Jun 11, 2019 at 12:08:20PM -0400, Sean Paul wrote:
> > From: Sean Paul
> >
> > Instead of flushing all vops every time we get a dirtyfb call, use the
> > damage helper to kick off an atomic commit. Even though we don't use
On Tue, Jun 11, 2019 at 07:55:45PM +0200, Daniel Vetter wrote:
> On Tue, Jun 11, 2019 at 7:50 PM Ville Syrjälä
> wrote:
> >
> > On Fri, Jun 07, 2019 at 08:40:15PM +0200, Daniel Vetter wrote:
> > > On Fri, Jun 07, 2019 at 07:26:10PM +0300, Ville Syrjala wrote:
> > > > From: Ville Syrjälä
> > > >
Hi Michael,
Thank you for the patch.
On Tue, Jun 11, 2019 at 03:04:04PM +0100, Michael Drake wrote:
> The config property can be used to provide an array of
> register addresses and values to be written to configure
> the device for the board.
Please don't. DT describes the hardware (or more
https://bugs.freedesktop.org/show_bug.cgi?id=110862
--- Comment #7 from denisgolo...@yandex.ru ---
Created attachment 144511
--> https://bugs.freedesktop.org/attachment.cgi?id=144511=edit
dmesg after successfull X restart
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=110897
--- Comment #1 from Richard Thier ---
Created attachment 144510
--> https://bugs.freedesktop.org/attachment.cgi?id=144510=edit
Second screenshot (visible tile boundary - zbuffer is completely wasted below)
Added second screenshot. You can
https://bugs.freedesktop.org/show_bug.cgi?id=110862
--- Comment #6 from denisgolo...@yandex.ru ---
Created attachment 144509
--> https://bugs.freedesktop.org/attachment.cgi?id=144509=edit
xorg log after successful X restart
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=110862
--- Comment #5 from denisgolo...@yandex.ru ---
Created attachment 144508
--> https://bugs.freedesktop.org/attachment.cgi?id=144508=edit
xrandr
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=110862
--- Comment #4 from denisgolo...@yandex.ru ---
Created attachment 144507
--> https://bugs.freedesktop.org/attachment.cgi?id=144507=edit
dmesg after bug occured
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=110862
--- Comment #3 from denisgolo...@yandex.ru ---
Created attachment 144506
--> https://bugs.freedesktop.org/attachment.cgi?id=144506=edit
xorg.log after bug occured
--
You are receiving this mail because:
You are the assignee for the
Hi Michael,
Thank you for the patch.
On Tue, Jun 11, 2019 at 03:04:02PM +0100, Michael Drake wrote:
> Adds device tree bindings for:
>
> TI DS90UB948-Q1 2K FPD-Link III to OpenLDI Deserializer
>
> The device has the compatible string "ti,ds90ub948", and
> and allows an arrray of strings to
https://bugs.freedesktop.org/show_bug.cgi?id=110897
Bug ID: 110897
Summary: HyperZ is broken for r300 (bad z for some micro and
macrotiles?)
Product: Mesa
Version: git
Hardware: Other
OS: other
Hi Sean,
Thank you for the patch.
On Tue, Jun 11, 2019 at 12:08:18PM -0400, Sean Paul wrote:
> From: Sean Paul
>
> Everyone who implements connector_helper_funcs->atomic_check reaches
> into the connector state to get the atomic state. Instead of continuing
> this pattern, change the callback
On Fri, Jun 07, 2019 at 12:00:47PM -0700, Stephen Boyd wrote:
> Quoting Iurii Zaikin (2019-06-05 18:29:42)
> > On Fri, May 17, 2019 at 11:22 AM Stephen Boyd wrote:
> > >
> > > Quoting Brendan Higgins (2019-05-14 15:17:10)
> > > > diff --git a/kernel/sysctl-test.c b/kernel/sysctl-test.c
> > > >
On Tue, Jun 11, 2019 at 7:50 PM Ville Syrjälä
wrote:
>
> On Fri, Jun 07, 2019 at 08:40:15PM +0200, Daniel Vetter wrote:
> > On Fri, Jun 07, 2019 at 07:26:10PM +0300, Ville Syrjala wrote:
> > > From: Ville Syrjälä
> > >
> > > i915 will now refuse to enable a C8 plane unless the gamma_lut
> > > is
On Fri, Jun 07, 2019 at 08:43:56PM +0200, Daniel Vetter wrote:
> On Fri, Jun 07, 2019 at 07:26:11PM +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Respect the user's choice of depth/bpp for the fbdev framebuffer
> > and throw out the fb we inherited from the BIOS if it doesn't
> >
On Fri, Jun 07, 2019 at 08:40:15PM +0200, Daniel Vetter wrote:
> On Fri, Jun 07, 2019 at 07:26:10PM +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > i915 will now refuse to enable a C8 plane unless the gamma_lut
> > is already enabled (to avoid scanning out whatever garbage got
> >
On Tue, Jun 11, 2019 at 12:08:20PM -0400, Sean Paul wrote:
> From: Sean Paul
>
> Instead of flushing all vops every time we get a dirtyfb call, use the
> damage helper to kick off an atomic commit. Even though we don't use
> damage clips, the helper commit will force us through the normal
>
On Tue, Jun 11, 2019 at 06:19:21PM +0200, Sebastian Reichel wrote:
> Hi Daniel,
>
> On Tue, Jun 11, 2019 at 01:30:51PM +0200, Daniel Vetter wrote:
> > On Tue, Jun 11, 2019 at 11:05:40AM +0300, Tomi Valkeinen wrote:
> > > Hi Dave,
> > >
> > > Please pull omapdrm changes for 5.3.
> > >
> > >
https://bugs.freedesktop.org/show_bug.cgi?id=110781
--- Comment #65 from Rui Salvaterra ---
(In reply to Richard Thier from comment #64)
> Rui!
>
> Btw I am also running your patch already too and did not see much problems
> so far, but many of the stuff I am running was DX7 and DX8 level in
Instead of using non-standard "encoder-slave" property to find
encoder let's find it by associated endpoint.
While I'm on it add corresponding log message if we don't find
any encoder and we assume that we use virtual LCD on the
simulation platform.
Signed-off-by: Eugeniy Paltsev
---
https://bugs.freedesktop.org/show_bug.cgi?id=110781
--- Comment #64 from Richard Thier ---
Rui!
Btw I am also running your patch already too and did not see much problems so
far, but many of the stuff I am running was DX7 and DX8 level in graphics
settings so I do not know how many times I
From: Colin Ian King
Currently variable ret is being initialized with -ENOENT however that
value is never read and ret is being re-assigned later on. Hence this
assignment is redundant and can be removed.
Addresses-Coverity: ("Unused value")
Signed-off-by: Colin Ian King
---
Em Tue, 11 Jun 2019 19:52:04 +0300
Andy Shevchenko escreveu:
> On Fri, Jun 7, 2019 at 10:04 PM Mauro Carvalho Chehab
> wrote:
> > Sphinx doesn't like orphan documents:
>
> > Documentation/laptops/lg-laptop.rst: WARNING: document isn't included
> > in any toctree
>
> >
https://bugs.freedesktop.org/show_bug.cgi?id=110777
Anton Herzfeld changed:
What|Removed |Added
Assignee|dri-devel@lists.freedesktop |alexdeuc...@gmail.com
Hi Daniel,
On Tue, Jun 11, 2019 at 04:33:14PM +0100, Daniel Thompson wrote:
> On Mon, Jun 10, 2019 at 04:37:39PM -0700, Matthias Kaehlcke wrote:
> > Commit 88ba95bedb79 ("backlight: pwm_bl: Compute brightness of LED
> > linearly to human eye") uses pwm_period / hweight32(pwm_period) as
> > as
https://bugs.freedesktop.org/show_bug.cgi?id=109206
--- Comment #49 from Talha Khan ---
I updated my kernel to 5.1.7 and did not need to run dracut to rebuild my
initramfs. I was able to boot just fine.
--
You are receiving this mail because:
You are the assignee for the
On Fri, Jun 7, 2019 at 10:04 PM Mauro Carvalho Chehab
wrote:
> Sphinx doesn't like orphan documents:
> Documentation/laptops/lg-laptop.rst: WARNING: document isn't included in
> any toctree
> Documentation/laptops/lg-laptop.rst | 2 ++
> diff --git
On Tue, Jun 11, 2019 at 04:37:16PM +0100, Build bot for Mark Brown wrote:
Today's -next fails to build an arm allmodconfig due to:
> arm-allmodconfig
> ../drivers/gpu/drm/arm/display/komeda/d71/d71_component.c:206:30: error:
> passing argument 3 of 'd71_layer_update_fb' from incompatible
On Tue, 11 Jun 2019 at 18:18, Ezequiel Garcia
wrote:
>
>
>
> On Tue, Jun 11, 2019, 1:01 PM Anders Roxell wrote:
>>
>> On Tue, 11 Jun 2019 at 10:21, Hans Verkuil wrote:
>> >
>> > On 6/11/19 10:15 AM, Philipp Zabel wrote:
>> > > Hi,
>> > >
>> > > On Mon, 2019-06-10 at 13:14 +, Matt Redfearn
Hi Daniel,
On Tue, Jun 11, 2019 at 01:30:51PM +0200, Daniel Vetter wrote:
> On Tue, Jun 11, 2019 at 11:05:40AM +0300, Tomi Valkeinen wrote:
> > Hi Dave,
> >
> > Please pull omapdrm changes for 5.3.
> >
> > Tomi
> >
> > The following changes since commit
On Tue, Jun 11, 2019, 1:01 PM Anders Roxell
wrote:
> On Tue, 11 Jun 2019 at 10:21, Hans Verkuil wrote:
> >
> > On 6/11/19 10:15 AM, Philipp Zabel wrote:
> > > Hi,
> > >
> > > On Mon, 2019-06-10 at 13:14 +, Matt Redfearn wrote:
> > >>
> > >> On 10/06/2019 14:03, Anders Roxell wrote:
> > >>>
On Tue, Jun 11, 2019 at 11:05:52AM +0200, Daniel Vetter wrote:
Hi stable team,
Please backport dbb92471674a ("Revert "drm: allow render capable
master with DRM_AUTH ioctls"") to 5.1, we accidentally forgot the Cc:
stable and Fixes: line for that revert. Thanks to Michel for spotting
this.
From: Sean Paul
Now that we use the drm psr helpers, we no longer need to hand-roll our
atomic_commit_tail implementation. So use the helper
Changes in v2:
- None
Changes in v3:
- None
Changes in v4:
- None
Changes in v5:
- None
Link to v1:
1 - 100 of 238 matches
Mail list logo