qxl device will not dma, so we don't need ttm_dma_tt. Go use ttm_tt
instead, to avoid wasting resources (swiotlb bounce buffers for
example).
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/qxl/qxl_ttm.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu
Hi
On 2019-01-28 19:28, Yizhuo wrote:
> In function gsc_set_gscblk_fimd_wb(), local variable "gscblk_cfg"
> could be uninitialized of function regmap_read returns -EINVAL.
> However, this value will be write to the register after "or"
> operation. This is potentially unsafe.
>
> Signed-off-by: Yi
Den 29.01.2019 01.19, skrev Eric Anholt:
> Noralf Trønnes writes:
>
>> Den 28.01.2019 21.57, skrev Rob Herring:
>>> On Sun, Dec 2, 2018 at 9:59 AM Noralf Trønnes wrote:
Den 30.11.2018 00.58, skrev Eric Anholt:
> Daniel Vetter writes:
>
>> On Wed, Nov 28, 2018 at 01:
On Mon, Jan 28, 2019 at 03:40:47PM +0100, Noralf Trønnes wrote:
>
>
> Den 21.01.2019 10.05, skrev Daniel Vetter:
> > On Sun, Jan 20, 2019 at 12:43:18PM +0100, Noralf Trønnes wrote:
> >> It's now safe to let fbcon unbind automatically on fbdev unregister.
> >> The crash problem was fixed in commit
On Fri, Jan 25, 2019 at 11:01:48PM +0200, Ville Syrjälä wrote:
> On Tue, Jan 22, 2019 at 10:39:38AM +0100, Daniel Vetter wrote:
> > On Mon, Jan 21, 2019 at 10:24:29PM +0200, Ville Syrjala wrote:
> > > From: Ville Syrjälä
> > >
> > > Use ENOENT consistently for the case where the requested propert
Den 29.01.2019 09.25, skrev Gerd Hoffmann:
> qxl device will not dma, so we don't need ttm_dma_tt. Go use ttm_tt
> instead, to avoid wasting resources (swiotlb bounce buffers for
> example).
>
> Signed-off-by: Gerd Hoffmann
> ---
Acked-by: Noralf Trønnes
_
On Sun, Jan 27, 2019 at 12:00:37PM +0100, David Herrmann wrote:
> Hey
>
> On Sat, Jan 26, 2019 at 8:27 PM Sam Ravnborg wrote:
> > David Herrmann removed the last bits of drm_bus in:
> > c5786fe5f1c50941dbe27fc8b4aa1afee46ae893 ("drm: Goody bye, drm_bus!")
> >
> > Remove the todo item.
> >
> > Sig
It's probably not what you want, definitely not after Noralf's work to
add drm_dev_enter/exit.
Cc: Noralf Trønnes
Signed-off-by: Daniel Vetter
---
include/drm/drm_drv.h | 4
1 file changed, 4 insertions(+)
diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
index 9a688cf12881..ca46
On Mon, Jan 28, 2019 at 03:42:48PM -0500, Sean Paul wrote:
> From: Sean Paul
>
> Use the drm_mode_vrefresh helper where we need refresh rate in case
> vrefresh is empty.
>
> Signed-off-by: Sean Paul
I think adding a todo to remove these fields and switch everone over to
the helpers would be us
On 1/28/19 10:19 AM, Alex Deucher wrote:
> On Fri, Jan 25, 2019 at 5:31 PM Gustavo A. R. Silva
> wrote:
>>
>> Add missing break statement in order to prevent the code from falling
>> through to the default case.
>>
>> The resoning for this is that pclk_vol_table is an automatic variable.
>> So,
24.01.2019 21:02, Thierry Reding пишет:
> From: Thierry Reding
>
> If we use the IOMMU API directly to map buffers into host1x' IOVA space,
> we must make sure that the DMA API doesn't already set up a mapping, or
> else translation will fail.
>
> The direct DMA API allows us to allocate memory
24.01.2019 21:02, Thierry Reding пишет:
> From: Thierry Reding
>
> Tegra DRM clients need access to their parent, so store a pointer to it
> upon registration. It's technically possible to get at this by going via
> the host1x client's parent and getting the driver data, but that's quite
> compli
24.01.2019 21:02, Thierry Reding пишет:
> From: Thierry Reding
>
> Loading the firmware requires an allocation of IOVA space to make sure
> that the VIC's Falcon microcontroller can read the firmware if address
> translation via the SMMU is enabled.
>
> However, the allocation currently happens
In function ipu_prg_get_pre(), local variable "val" could
be uninitialized if function regmap_read() returns -EINVAL.
However, this value is used in if statement. This is
potentially unsafe.
Signed-off-by: Yizhuo
---
drivers/gpu/ipu-v3/ipu-prg.c | 8 +++-
1 file changed, 7 insertions(+), 1 d
Didn't knew about that line, sorry..
Sure you can include that.
I'm hoping patchwork won't thing it got tested twice by me..
Tested-by: Tristan Bastian
Gesendet: Montag, 28. Januar 2019 um 09:10 Uhr
Von: "Thierry Reding"
An: "Tristan Bastian"
Cc: "Wolfram Sang" , "Rob Herring" , "Luca
In function gsc_set_gscblk_fimd_wb(), local variable "gscblk_cfg"
could be uninitialized of function regmap_read returns -EINVAL.
However, this value will be write to the register after "or"
operation. This is potentially unsafe.
Signed-off-by: Yizhuo
---
drivers/gpu/drm/exynos/exynos_drm_gsc.c
On poniedziałek, 28 stycznia 2019 14:47:41 CET Andrzej Hajda wrote:
> Hi Paweł,
>
> Nice work.
>
> I agree with most Sam's comments (maybe expect DRM_DEV_* logging - I am
> not sure if we need concurrent logging facility).
>
> I'd like to add few more comments:
>
>
>
> On 25.01.2019 17:46, Pa
On Mon, Jan 21, 2019, at 4:20 PM, Chris Wilson wrote:
> Rather than every backend and GPU driver reinventing the same wheel for
> user level debugging of HW execution, the common dma-fence framework
> should include the tracing infrastructure required for most client API
> level flow visualisation.
On Mon, Jan 28, 2019 at 09:08:15AM +0100, Thierry Reding wrote:
> On Sat, Jan 26, 2019 at 01:37:34PM +0100, Tristan Bastian wrote:
> > Am 25.01.19 um 14:11 schrieb Thierry Reding:
> > > From: Thierry Reding
> > >
> > > If an I2C adapter doesn't match the provided device tree node, also try
> > >
From: Manfred Schlaegl
There is no clipping on the x or y axis for logos larger that the framebuffer
size. Therefore: a logo bigger than screen size leads to invalid memory access:
[1.254664] Backtrace:
[1.254728] [] (cfb_imageblit) from []
(fb_show_logo+0x620/0x684)
[1.254763] r10
On 23.01.2019 14:03, Kees Cook wrote:
> This adds a new plugin "stackinit" that attempts to perform unconditional
> initialization of all stack variables
Hello Kees! Hello everyone!
I was curious about the performance impact of the initialization of all stack
variables. So I did a very brief test
Den 29.01.2019 09.56, skrev Daniel Vetter:
> It's probably not what you want, definitely not after Noralf's work to
> add drm_dev_enter/exit.
>
> Cc: Noralf Trønnes
> Signed-off-by: Daniel Vetter
> ---
Reviewed-by: Noralf Trønnes
> include/drm/drm_drv.h | 4
> 1 file changed, 4 insert
On 2019-01-29 2:16 a.m., Dave Airlie wrote:
> So libdrm README renamed to README.rst, however that means it no
> longer gets included in the dist tarball.
>
> I think autotools considers README special, so we might need to fix it,
Adding the new README file to EXTRA_DIST seems enough, see e.g.
ht
On Tue, Jan 29, 2019 at 10:02:32AM +0100, Noralf Trønnes wrote:
>
>
> Den 29.01.2019 09.56, skrev Daniel Vetter:
> > It's probably not what you want, definitely not after Noralf's work to
> > add drm_dev_enter/exit.
> >
> > Cc: Noralf Trønnes
> > Signed-off-by: Daniel Vetter
> > ---
>
> Revie
On Tue, Jan 29, 2019 at 10:26:57AM +0100, Michel Dänzer wrote:
> On 2019-01-29 2:16 a.m., Dave Airlie wrote:
> > So libdrm README renamed to README.rst, however that means it no
> > longer gets included in the dist tarball.
> >
> > I think autotools considers README special, so we might need to fi
On Fri, Jan 25, 2019 at 03:02:46PM +, Emil Velikov wrote:
> On Thu, 24 Jan 2019 at 17:00, Daniel Vetter wrote:
> >
> > It's 0.
> >
> I'd add a bit more information here. Feel free to reuse as much/little
> of the following:
>
> Both macros evaluate to 0. At the same time flag is already set t
Hello Christian Gmeiner,
The patch 9e2c2e273012: "drm/etnaviv: add infrastructure to query
perf counter" from Sep 24, 2017, leads to the following static
checker warning:
drivers/gpu/drm/etnaviv/etnaviv_drv.c:410 etnaviv_ioctl_pm_query_dom()
warn: 'args->pipe' is out of bounds '3'
Quoting Michael Sartain (2019-01-29 01:52:12)
> On Mon, Jan 21, 2019, at 4:20 PM, Chris Wilson wrote:
> > Rather than every backend and GPU driver reinventing the same wheel for
> > user level debugging of HW execution, the common dma-fence framework
> > should include the tracing infrastructure re
Den 29.01.2019 10.51, skrev Daniel Vetter:
> On Tue, Jan 29, 2019 at 10:02:32AM +0100, Noralf Trønnes wrote:
>>
>>
>> Den 29.01.2019 09.56, skrev Daniel Vetter:
>>> It's probably not what you want, definitely not after Noralf's work to
>>> add drm_dev_enter/exit.
>>>
>>> Cc: Noralf Trønnes
>>> S
Den 28.01.2019 12.49, skrev Gerd Hoffmann:
> On Mon, Jan 28, 2019 at 11:25:28AM +0100, Noralf Trønnes wrote:
>>
>>
>> Den 28.01.2019 07.48, skrev Gerd Hoffmann:
Fix by using drm_fb_helper_lastclose() which checks if fbdev is in use.
>>>
static int drm_fbdev_client_restore(struct drm_cl
Den 29.01.2019 11.20, skrev Noralf Trønnes:
>
>
> Den 29.01.2019 10.51, skrev Daniel Vetter:
>> On Tue, Jan 29, 2019 at 10:02:32AM +0100, Noralf Trønnes wrote:
>>>
>>>
>>> Den 29.01.2019 09.56, skrev Daniel Vetter:
It's probably not what you want, definitely not after Noralf's work to
And move the documenation we alreay have into kerneldoc, plus a bit of
polish while at it.
v2:
- Ditch FIXME from commit message, I've resolved that already before
sending out the first version.
- Put the legacy DRIVER_ flags at the end (Sam).
Cc: Sam Ravnborg
Reviewed-by: Emil Velikov
Review
This is only used by drm_irq_install(), which is an optional helper.
For legacy pci devices this is required (due to interrupt sharing without
msi/msi-x), and just making this the default exactly matches the behaviour
of all existing drivers using the drm_irq_install() helpers. In case that
ever be
If a non-legacy driver calls these it's valid to assume there is
interrupt support. The flag is really only needed for legacy drivers,
which control IRQ enabling/disabling through the DRM_IOCTL_CONTROL
legacy IOCTL.
Also remove all the flag usage from non-legacy drivers.
v2: Review from Emil:
- i
Quoting Lyude Paul (2019-01-28 20:56:01)
> When resuming, we check whether or not any previously connected
> MST topologies are still present and if so, attempt to resume them. If
> this fails, we disable said MST topologies and fire off a hotplug event
> so that userspace knows to reprobe.
>
> Ho
https://bugs.freedesktop.org/show_bug.cgi?id=109493
Chris Wilson changed:
What|Removed |Added
QA Contact|intel-gfx-bugs@lists.freede |
|sktop.org
Op 28-01-2019 om 09:44 schreef Uma Shankar:
> Create a new connector property to program colorspace to sink devices.
> Modern sink devices support more than 1 type of colorspace like 601,
> 709, BT2020 etc. This helps to switch based on content type which is
> to be displayed. The decision lies wit
Op 28-01-2019 om 09:44 schreef Uma Shankar:
> This patch attaches the colorspace connector property to the
> hdmi connector. Based on colorspace change, modeset will be
> triggered to switch to new colorspace.
>
> Based on colorspace property value create an infoframe
> with appropriate colorspace.
if vmw_execbuf_fence_commands() fails, The handle value will be
uninitialized and a bogus fence handle might be copied to user-space.
Cc:
Fixes: 2724b2d54cda: ("drm/vmwgfx: Use new validation interface for the
modesetting code v2")
Reported-by: Dan Carpenter
Signed-off-by: Thomas Hellstrom
Rev
From: Deepak Rawat
During modeset check it is possible to have all crtc_state's in atomic
state. Check for crtc enable status while checking for display unit
active status. Only error if enabling a crtc while display unit is not
active.
Cc:
Fixes: 9da6e26c0aae: ("drm/vmwgfx: Fix a layout race c
I'm kinda fed up explaining why the have a confusing name :-)
Cc: Noralf Trønnes
Cc: Laurent Pinchart
Signed-off-by: Daniel Vetter
---
Documentation/gpu/todo.rst | 10 ++
1 file changed, 10 insertions(+)
diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
index 38360e
>-Original Message-
>From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
>Sent: Tuesday, January 29, 2019 5:54 PM
>To: Shankar, Uma ; intel-...@lists.freedesktop.org;
>dri-devel@lists.freedesktop.org
>Cc: Syrjala, Ville ; Lankhorst, Maarten
>
>Subject: Re: [Intel-gfx] [v7 1
Previously we set only the dma mask and not the coherent mask. Fix that.
Also, for clarity, make sure both are initially set to 64 bits.
Fixes: 0d00c488f3de: ("drm/vmwgfx: Fix the driver for large dma addresses")
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 9 ++-
instead of relying on intel_iommu_enabled, use the fact that the
dma_map_ops::map_page != dma_direct_map_page.
Signed-off-by: Thomas Hellstrom
---
v2: Merge fixes and typo fix in commit message. Also check for ops being
non-NULL before dereferencing it.
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c |
Hi Thierry,
Am Dienstag, 13. November 2018, 13:42:05 CET schrieb Heiko Stuebner:
> From: Heiko Stuebner
>
> This is a panel handled through the generic lvds-panel binding,
> so only needs its additional compatible specified.
>
> Signed-off-by: Heiko Stuebner
just pulling this pending patch ou
https://bugs.freedesktop.org/show_bug.cgi?id=109206
--- Comment #6 from Chris ---
Still having the same bug in kernel 5.0-rc4 and my raven_dmcu.bin also matches
to the previously attached bin file(sha256
a45972418d1c078afbd7884ffd58784954220759bc0d5464ce60165ffe1775bd).
However, in one of my tes
On text-based systems the 'quiet' boot option will show printk levels
higher than CONSOLE_LOGLEVEL_QUIET. The displaying of the Tux logo
during boot can cause some consoles to lose display data and as a result
confuse the end user.
Do not display the Tux logo on systems that are in 'quiet' boot.
On text-based systems the 'quiet' boot option will show printk levels
higher than CONSOLE_LOGLEVEL_QUIET. The displaying of the Tux logo
during boot can cause some consoles to lose display data and as a result
confuse the end user.
Do not display the Tux logo on systems that are in 'quiet' boot.
Hi Daniel.
>
> Sam, want drm-misc commit rights to start merging your own stuff? Assuming
> you plan to stick around ofc ... I'll also ask the drm-misc maintainers
> whether that's ok.
The plan is to re-submit the Atmel LCDC DRM driver when I find enough time
to finish it. All coding is done and
Quoting Jerome Glisse (2019-01-24 17:30:32)
> On Thu, Jan 24, 2019 at 02:09:12PM +0200, Joonas Lahtinen wrote:
> > Hi Jerome,
> >
> > This patch seems to have plenty of Cc:s, but none of the right ones :)
>
> So sorry, i am bad with git commands.
>
> > For further iterations, I guess you could u
We really want to have fastboot enabled by default to avoid an ugly
modeset during boot.
Currently we are enabling fastboot by default on gen9+ (Skylake and newer).
The intention is to enable it on older generations after it has seen more
testing on gen9+.
VLV and CHV devices are still being sold
>-Original Message-
>From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
>Sent: Tuesday, January 29, 2019 5:56 PM
>To: Shankar, Uma ; intel-...@lists.freedesktop.org;
>dri-devel@lists.freedesktop.org
>Cc: Syrjala, Ville ; Lankhorst, Maarten
>
>Subject: Re: [Intel-gfx] [v7 2
Den 24.01.2019 18.57, skrev Daniel Vetter:
> On Thu, Jan 24, 2019 at 6:46 PM Greg KH wrote:
>>
>> On Thu, Jan 24, 2019 at 11:43:12AM +0100, Daniel Vetter wrote:
>>> On Wed, Jan 23, 2019 at 11:54:07AM +0100, Noralf Trønnes wrote:
Den 22.01.2019 20.30, skrev Daniel Vetter:
> On
Den 29.01.2019 14.21, skrev Daniel Vetter:
> I'm kinda fed up explaining why the have a confusing name :-)
>
> Cc: Noralf Trønnes
> Cc: Laurent Pinchart
> Signed-off-by: Daniel Vetter
> ---
I agree that it's confusing,
Acked-by: Noralf Trønnes
I would also make sense to fold drm_fb_cma_he
On Tue, Jan 29, 2019 at 11:42:48AM +0100, Daniel Vetter wrote:
> This is only used by drm_irq_install(), which is an optional helper.
> For legacy pci devices this is required (due to interrupt sharing without
> msi/msi-x), and just making this the default exactly matches the behaviour
> of all exi
https://bugzilla.kernel.org/show_bug.cgi?id=202445
--- Comment #1 from Alex Deucher (alexdeuc...@gmail.com) ---
Please attach your dmesg output and xorg log (if using X).
--
You are receiving this mail because:
You are watching the assignee of the bug.
___
Hi Daniel,
On Mon, Jan 28, 2019 at 06:22:58PM +0100, Daniel Vetter wrote:
> Compared to the RFC[1] no changes to the patch itself, but igt moved
> forward a lot:
>
> - gitlab CI builds with: reduced configs/libraries, arm cross build
> and a sysroot build (should address all the build/cross pla
From: Oleksandr Andrushchenko
When GEM backing storage is allocated those are normal pages,
so there is no point using pgprot_writecombine while mmaping.
This fixes mismatch of buffer pages' memory attributes between
the frontend and backend which may cause screen artifacts.
Fixes: c575b7eeb89f
Hi Sam,
On Mon, Jan 28, 2019 at 12:41 AM Jagan Teki wrote:
>
> On Sat, Jan 26, 2019 at 1:22 AM Sam Ravnborg wrote:
> >
> > Hi Jagan.
> >
> > Looks good, only very few nits left.
> >
> > On Sat, Jan 26, 2019 at 12:52:33AM +0530, Jagan Teki wrote:
> > > Feiyang FY07024DI26A30-D is 1024x600, 4-lane
On Sat, Jan 26, 2019 at 09:39:00PM +0530, Jagan Teki wrote:
> On 25/01/19 9:22 PM, Maxime Ripard wrote:
> > On Fri, Jan 25, 2019 at 01:28:52AM +0530, Jagan Teki wrote:
> > > The MIPI DSI controller in Allwinner A64 is similar to A33.
> > >
> > > But unlike A33, A64 doesn't have DSI_SCLK gating whi
https://bugzilla.kernel.org/show_bug.cgi?id=202449
Bug ID: 202449
Summary: vrr_capable not showing up in xrandr with eDP display.
Product: Drivers
Version: 2.5
Kernel Version: 4.20
Hardware: All
OS: Linux
Tree
On Tue, Jan 29, 2019 at 03:34:46PM +0100, Noralf Trønnes wrote:
>
>
> Den 24.01.2019 18.57, skrev Daniel Vetter:
> > On Thu, Jan 24, 2019 at 6:46 PM Greg KH wrote:
> >>
> >> On Thu, Jan 24, 2019 at 11:43:12AM +0100, Daniel Vetter wrote:
> >>> On Wed, Jan 23, 2019 at 11:54:07AM +0100, Noralf Trøn
Hi Jagan.
> >
> > I see DRM_MODE_ARG as mode argument, that print all mode timings but
> > here we need only 3 timings out of it. do we really need? if yes
> > please suggest an example.
>
> fyi: sent v6 for this except this change. Let me know if you have any
> comments on this.
Drivers looks f
Hi Uma,
On Tue, Jan 29, 2019 at 01:30:43PM +, Shankar, Uma wrote:
>
>
> >-Original Message-
> >From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> >Sent: Tuesday, January 29, 2019 5:54 PM
> >To: Shankar, Uma ; intel-...@lists.freedesktop.org;
> >dri-devel@lists.freed
On Mon, Jan 28, 2019 at 03:06:10PM +0530, Jagan Teki wrote:
> On Sat, Jan 26, 2019 at 2:54 AM Maxime Ripard
> wrote:
> >
> > On Fri, Jan 25, 2019 at 01:28:49AM +0530, Jagan Teki wrote:
> > > Minimum PLL used for MIPI is 500MHz, as per manual, but
> > > lowering the min rate by 300MHz can result p
https://bugs.freedesktop.org/show_bug.cgi?id=109487
--- Comment #4 from Alex Deucher ---
Reverting this patch should fix it:
https://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-next-5.1-wip&id=10117450735c7a7c0858095fb46a860e7037cb9a
--
You are receiving this mail because:
You are the assig
Create a new connector property to program colorspace to sink devices.
Modern sink devices support more than 1 type of colorspace like 601,
709, BT2020 etc. This helps to switch based on content type which is
to be displayed. The decision lies with compositors as to in which
scenarios, a particular
This patch series creates a new connector property to program
colorspace to sink devices. Modern sink devices support more
than 1 type of colorspace like 601, 709, BT2020 etc. This helps
to switch based on content type which is to be displayed. The
decision lies with compositors as to in which scen
This patch attaches the colorspace connector property to the
hdmi connector. Based on colorspace change, modeset will be
triggered to switch to new colorspace.
Based on colorspace property value create an infoframe
with appropriate colorspace. This can be used to send an
infoframe packet with prop
On Tue, Jan 29, 2019 at 3:54 AM Daniel Vetter wrote:
>
> On Sun, Jan 27, 2019 at 12:00:37PM +0100, David Herrmann wrote:
> > Hey
> >
> > On Sat, Jan 26, 2019 at 8:27 PM Sam Ravnborg wrote:
> > > David Herrmann removed the last bits of drm_bus in:
> > > c5786fe5f1c50941dbe27fc8b4aa1afee46ae893 ("d
On Fri, Jan 25, 2019 at 10:29 AM Wentland, Harry wrote:
>
> On 2019-01-24 7:52 p.m., ndesaulni...@google.com wrote:
> > arch/x86/Makefile disables SSE and SSE2 for the whole kernel. The
> > AMDGPU drivers modified in this patch re-enable SSE but not SSE2. Turn
> > on SSE2 to support emitting dou
https://bugzilla.kernel.org/show_bug.cgi?id=202449
--- Comment #1 from Haxk20 (haxk...@gmail.com) ---
Sorry after further reading im not sure that dGPU is connected to HDMI
directly. Is there a way to see in linux ?
--
You are receiving this mail because:
You are watching the assignee of the bug
https://bugzilla.kernel.org/show_bug.cgi?id=202449
Alex Deucher (alexdeuc...@gmail.com) changed:
What|Removed |Added
CC||alexdeuc...@gmail.c
https://bugs.freedesktop.org/show_bug.cgi?id=109487
--- Comment #5 from Tom St Denis ---
Reverting just the -msse2 commit on top of drm-next works fine for me.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mail
Hi Sam,
Thanks for the review, I'll address the points left out.
On Sat, Jan 26, 2019 at 04:39:46PM +0100, Sam Ravnborg wrote:
> > + return ret;
> > + }
> > +
> > + /* Reset */
> > + msleep(20);
> > + gpiod_set_value(ctx->gpios.power, 1);
> > + msleep(20);
> > + gpiod_set_va
On Tue, Jan 29, 2019 at 09:22:56PM +0530, Uma Shankar wrote:
> This patch attaches the colorspace connector property to the
> hdmi connector. Based on colorspace change, modeset will be
> triggered to switch to new colorspace.
>
> Based on colorspace property value create an infoframe
> with appro
https://bugzilla.kernel.org/show_bug.cgi?id=202449
--- Comment #4 from Haxk20 (haxk...@gmail.com) ---
Created attachment 280851
--> https://bugzilla.kernel.org/attachment.cgi?id=280851&action=edit
Xorg log
--
You are receiving this mail because:
You are watching the assignee of the bug.
__
https://bugzilla.kernel.org/show_bug.cgi?id=202449
--- Comment #3 from Haxk20 (haxk...@gmail.com) ---
Created attachment 280849
--> https://bugzilla.kernel.org/attachment.cgi?id=280849&action=edit
dmesg
--
You are receiving this mail because:
You are watching the assignee of the bug.
_
https://bugzilla.kernel.org/show_bug.cgi?id=202445
--- Comment #2 from Clément Guérin (li...@protonmail.com) ---
Created attachment 280853
--> https://bugzilla.kernel.org/attachment.cgi?id=280853&action=edit
dmesg output
--
You are receiving this mail because:
You are watching the assignee of
https://bugzilla.kernel.org/show_bug.cgi?id=202445
--- Comment #3 from Clément Guérin (li...@protonmail.com) ---
Created attachment 280855
--> https://bugzilla.kernel.org/attachment.cgi?id=280855&action=edit
Xorg.1.log
--
You are receiving this mail because:
You are watching the assignee of th
Hi Maxime.
> > > + }
> > > +
> > > + drm_mode_set_name(mode);
> > > +
> > > + mode->type = DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED;
> > > + drm_mode_probed_add(connector, mode);
> > > +
> > > + panel->connector->display_info.bpc = 8;
> > > + panel->connector->display_info.width_mm = 154;
>
Hi,
On Wed, 2019-01-23 at 16:54 +0100, Maxime Ripard wrote:
> The current code allows the TCON clock divider to have a range between 4
> and 127 when feeding the DSI controller.
>
> The only display supported so far had a display clock rate that ended up
> using a divider of 4, but testing with o
On Tue, Jan 29, 2019 at 09:59:40AM +0100, Daniel Vetter wrote:
> On Mon, Jan 28, 2019 at 03:42:48PM -0500, Sean Paul wrote:
> > From: Sean Paul
> >
> > Use the drm_mode_vrefresh helper where we need refresh rate in case
> > vrefresh is empty.
> >
> > Signed-off-by: Sean Paul
>
> I think adding
Hi,
On Tue, 29 Jan 2019 at 15:24, Brian Starkey wrote:
> On Tue, Jan 29, 2019 at 01:30:43PM +, Shankar, Uma wrote:
> > >> +#define DP_COLORIMETRY_SCRGB 15
> > >> +#define DP_COLORIMETRY_DCI_P3 16
> > >> +#define DP_COLORIMETRY_CUSTOM_COLOR_PROFILE 17
>
> Sorry,
On Mon, Jan 28, 2019 at 02:58:53PM -0800, Chandan Uddaraju wrote:
> This change adds definitions needed for DP audio compliance testing.
> It also adds missing definition for DP video compliance.
>
> Changes in V2:
> -- Delete cover letter for this patch.
> -- Move the description from cover lette
>-Original Message-
>From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
>Ville Syrjälä
>Sent: Tuesday, January 29, 2019 9:14 PM
>To: Shankar, Uma
>Cc: emil.l.veli...@gmail.com; intel-...@lists.freedesktop.org; Syrjala, Ville
>; Lankhorst, Maarten ;
>dri-devel@l
Hi,
On Wed, 2019-01-23 at 16:54 +0100, Maxime Ripard wrote:
> The current calculation for the video start delay in the current DSI driver
> is that it is the total vertical size, minus the backporch and sync length,
> plus 1.
>
> However, the Allwinner code has it as the active vertical size, plu
>-Original Message-
>From: Daniel Stone [mailto:dan...@fooishbar.org]
>Sent: Tuesday, January 29, 2019 9:24 PM
>To: Brian Starkey
>Cc: Shankar, Uma ; Syrjala, Ville
>; intel-...@lists.freedesktop.org; dri-
>de...@lists.freedesktop.org; nd ; Lankhorst, Maarten
>
>Subject: Re: [Intel-gfx]
On Tue, Jan 29, 2019 at 03:57:29PM +, Shankar, Uma wrote:
>
>
> >-Original Message-
> >From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
> >Ville Syrjälä
> >Sent: Tuesday, January 29, 2019 9:14 PM
> >To: Shankar, Uma
> >Cc: emil.l.veli...@gmail.com; intel-
From: Sean Paul
Suggested-by: Daniel Vetter
Signed-off-by: Sean Paul
---
Documentation/gpu/todo.rst | 15 +++
1 file changed, 15 insertions(+)
diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
index 38360ede12215..7fc30380eaf6c 100644
--- a/Documentation/gpu/tod
https://bugs.freedesktop.org/show_bug.cgi?id=108889
--- Comment #4 from CI Bug Log ---
A CI Bug Log filter associated to this bug has been updated:
{- SKL ICL: igt@sw_sync@sync_busy_fork* - incomplete - __igt_fork_helper:
Assertion `!proc->running' failed. -}
{+ HSW SKL ICL: igt@sw_sync@sync_bus
On Tue, Jan 29, 2019 at 04:20:00PM +0200, Joonas Lahtinen wrote:
> Quoting Jerome Glisse (2019-01-24 17:30:32)
> > On Thu, Jan 24, 2019 at 02:09:12PM +0200, Joonas Lahtinen wrote:
> > > Hi Jerome,
> > >
> > > This patch seems to have plenty of Cc:s, but none of the right ones :)
> >
> > So sorry,
>-Original Message-
>From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
>Sent: Tuesday, January 29, 2019 9:34 PM
>To: Shankar, Uma
>Cc: emil.l.veli...@gmail.com; intel-...@lists.freedesktop.org; Syrjala, Ville
>; Lankhorst, Maarten ;
>dri-devel@lists.freedesktop.org
>Subject: Re:
On Tue, Jan 29, 2019 at 11:15:51AM -0500, Sean Paul wrote:
> From: Sean Paul
>
> Suggested-by: Daniel Vetter
> Signed-off-by: Sean Paul
Reviewed-by: Sam Ravnborg
> ---
> Documentation/gpu/todo.rst | 15 +++
> 1 file changed, 15 insertions(+)
>
> diff --git a/Documentation/gpu/to
https://bugs.freedesktop.org/show_bug.cgi?id=109487
--- Comment #6 from asavah ---
Yes, indeed reverting
https://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-next-5.1-wip&id=10117450735c7a7c0858095fb46a860e7037cb9a
seems to fix the issue.
--
You are receiving this mail because:
You are the a
On Tue, Jan 29, 2019 at 11:15:51AM -0500, Sean Paul wrote:
> From: Sean Paul
>
> Suggested-by: Daniel Vetter
> Signed-off-by: Sean Paul
> ---
> Documentation/gpu/todo.rst | 15 +++
> 1 file changed, 15 insertions(+)
>
> diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/t
On Tue, Jan 29, 2019 at 04:20:39PM +, Shankar, Uma wrote:
>
>
> >-Original Message-
> >From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
> >Sent: Tuesday, January 29, 2019 9:34 PM
> >To: Shankar, Uma
> >Cc: emil.l.veli...@gmail.com; intel-...@lists.freedesktop.org; Syrjala,
On Tue, Jan 29, 2019 at 10:55:47AM -0500, Sean Paul wrote:
> On Mon, Jan 28, 2019 at 02:58:53PM -0800, Chandan Uddaraju wrote:
> > This change adds definitions needed for DP audio compliance testing.
> > It also adds missing definition for DP video compliance.
> >
> > Changes in V2:
> > -- Delete
From: Sean Paul
Changes in v2:
- Add drm_display_mode.vrefresh removal (Ville)
- Add Sam's R-b and bonus points
Cc: Ville Syrjälä
Suggested-by: Daniel Vetter
Reviewed-by: Sam Ravnborg
Bonus-points-awarded-by: Sam Ravnborg
Signed-off-by: Sean Paul
---
Documentation/gpu/todo.rst | 18 +++
On Tue, Jan 29, 2019 at 02:37:23PM +0100, Heiko Stübner wrote:
> Hi Thierry,
>
> Am Dienstag, 13. November 2018, 13:42:05 CET schrieb Heiko Stuebner:
> > From: Heiko Stuebner
> >
> > This is a panel handled through the generic lvds-panel binding,
> > so only needs its additional compatible speci
1 - 100 of 181 matches
Mail list logo
