https://bugs.freedesktop.org/show_bug.cgi?id=107784
--- Comment #9 from Sylvain BERTRAND ---
Ok, I got it. Since my git knowledge is quite limited, this "merge" commit is
opening a vast sea of new commits to test.
I'll dive into bisection using bisect (which actually deals with those merge
comm
Hi Maxime,
Thank you for the patch.
On Wednesday, 5 September 2018 12:16:33 EEST Maxime Ripard wrote:
> The phy framework is only allowing to configure the power state of the PHY
> using the init and power_on hooks, and their power_off and exit
> counterparts.
>
> While it works for most, simple
Hi Maxime,
Thank you for the patch.
On Wednesday, 5 September 2018 12:16:34 EEST Maxime Ripard wrote:
> Now that we have some infrastructure for it, allow the MIPI D-PHY phy's to
> be configured through the generic functions through a custom structure
> added to the generic union.
>
> The parame
On 2018-09-03 12:54 PM, Daniel Vetter wrote:
For atomic driver this is the default, no need to reimplement it. We
still need to keep the copypasta for not-atomic drivers though, since
no one polished the legacy crtc helpers as much as the atomic ones.
Thanks for the patch! It seems I made an
Hi Maxime,
Thank you for the patch.
On Wednesday, 5 September 2018 12:16:35 EEST Maxime Ripard wrote:
> The MIPI D-PHY spec defines default values and boundaries for most of the
> parameters it defines. Introduce helpers to help drivers get meaningful
> values based on their current parameters, a
Hi Maxime,
Thank you for the patch.
On Wednesday, 5 September 2018 12:16:32 EEST Maxime Ripard wrote:
> MIPI D-PHY is a MIPI standard meant mostly for display and cameras in
> embedded systems. Add a mode for it.
>
> Signed-off-by: Maxime Ripard
Reviewed-by: Laurent Pinchart
> ---
> include
On Wed, Sep 5, 2018 at 3:45 PM, Leo Li wrote:
>
>
> On 2018-09-03 12:54 PM, Daniel Vetter wrote:
>>
>> For atomic driver this is the default, no need to reimplement it. We
>> still need to keep the copypasta for not-atomic drivers though, since
>> no one polished the legacy crtc helpers as much as
Hi Maxime,
Thank you for the patch.
On Wednesday, 5 September 2018 12:16:40 EEST Maxime Ripard wrote:
> Cadence has designed a D-PHY that can be used by the, currently in tree,
> DSI bridge (DRM), CSI Transceiver and CSI Receiver (v4l2) drivers.
>
> Only the DSI driver has an ad-hoc driver for t
Hi Geert,
On Tuesday, 4 September 2018 17:32:32 EEST Geert Uytterhoeven wrote:
> On Tue, Sep 4, 2018 at 2:10 PM Laurent Pinchart wrote:
> > From: Takeshi Kihara
> >
> > Add device nodes for I2C ch{0,1,2,3,4,5,6,7} to R-Car E3 R8A77990 device
> > tree.
> >
> > Signed-off-by: Takeshi Kihara
> >
Hi Jacopo,
On Tuesday, 4 September 2018 17:49:53 EEST jacopo mondi wrote:
> On Tue, Sep 04, 2018 at 04:32:32PM +0200, Geert Uytterhoeven wrote:
> > On Tue, Sep 4, 2018 at 2:10 PM Laurent Pinchart wrote:
> >> From: Takeshi Kihara
> >>
> >> Add device nodes for I2C ch{0,1,2,3,4,5,6,7} to R-Car E3
On 5 September 2018 at 14:20, Thomas Hellstrom wrote:
>> In that case, please give me 24h to do a libdrm release before pushing.
>> I had to push some workarounds for the sandboxing mentioned earlier :-\
>>
>> Thanks
>> Emil
>
>
> Ouch, I just pushed the patch, but feel free to cut the release ju
Only needed minimal changes in drm_internal.h (for the drm_ioctl_t
type and a few forward declarations), plus a few missing includes in
drm_connector.c.
Yay, the last stage of the drm header cleanup can finally commence!
v2: Compiles now, with drm/kernel.h extracted.
Reviewed-by: Sean Paul
Sign
Just a bit of missing includes and pre declarations.
v2: Compiles now, with drm/kernel.h extracted.
v3: Rebase
Reviewed-by: Sean Paul
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_crtc_internal.h | 8
drivers/gpu/drm/drm_plane.c | 11 ++-
include/drm/drm_color
We have a bunch of neat little macros all over the place which should
move to kernel.h. But some of them died in bikesheds on lkml, and we
need a decent home for them.
Start out by moving the for_each_if macro there.
v2: Rename to drm_util.h instead (Dave&Sean)
Cc: Sean Paul
Acked-by: Sean Paul
This is starting to become easy!
v2: Compiles now, with drm/kernel.h extracted.
Reviewed-by: Sean Paul
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_crtc.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
ind
Remove the kerneldoc and EXPORT_SYMBOL which aren't used and really
shouldn't ever be used by drivers directly.
Unfortunately this means we need to move the set_writeback_fb function
around to avoid a forward decl.
Signed-off-by: Daniel Vetter
Cc: David Airlie
Cc: Gustavo Padovan
Cc: Maarten L
- drmP.h is now fully split up.
- vkms is happening (and will gain its own todo and docs under a new
vkms.rst file real soon)
- legacy cruft is completely hidden now, drm_vblank.c is split out
from drm_irq.c now. I've decided to drop the task to split out
drm_legacy.ko, partially because Dave
This leaves all the commit/check and state handling in drm_atomic.c,
while pulling all the uapi glue and the huge ioctl itself into a
seprate file.
This seems to almost perfectly split the rather big drm_atomic.c file
into 2 equal sizes.
Also adjust the kerneldoc and type a very terse overview te
https://bugzilla.kernel.org/show_bug.cgi?id=198123
Daniel Vetter (dan...@ffwll.ch) changed:
What|Removed |Added
Status|NEW |NEEDINFO
--
You are re
Hi Geert,
On Tuesday, 4 September 2018 17:29:29 EEST Geert Uytterhoeven wrote:
> On Tue, Sep 4, 2018 at 2:10 PM Laurent Pinchart wrote:
> > The LVDS encoders in the D3 and E3 SoCs differ significantly from those
> > in the other R-Car Gen3 family members:
> >
> > - The LVDS PLL architecture is mo
https://bugzilla.kernel.org/show_bug.cgi?id=201023
--- Comment #1 from Michel Dänzer (mic...@daenzer.net) ---
Please send the patch to the amd-...@lists.freedesktop.org mailing list for
review.
--
You are receiving this mail because:
You are watching the assignee of the bug.
On Tue, Sep 04, 2018 at 12:18:17AM +0300, Haneen Mohammed wrote:
> crtc_state is accessed by both vblank_handle() and the ordered
> work_struct handle vkms_crc_work_handle() to retrieve and or update
> the frame number for computed CRC.
>
> Since work_struct can fail, add frame_end to account for
https://bugs.freedesktop.org/show_bug.cgi?id=107798
Martin Peres changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--
You are receiving this mail b
On Wed, Sep 05, 2018 at 11:22:05AM +0100, Chris Wilson wrote:
> Since this is handling user provided bpp and depth, we need to sanity
> check and propagate the EINVAL back rather than assume what the insane
> client intended and fill the logs with DRM_ERROR.
>
> v2: Check both bpp and depth match
On Wed, Sep 05, 2018 at 04:05:18PM +0800, Icenowy Zheng wrote:
>
>
> 于 2018年9月5日 GMT+08:00 下午3:56:01, Maxime Ripard 写到:
> >On Wed, Sep 05, 2018 at 03:46:41PM +0800, Icenowy Zheng wrote:
> >>
> >>
> >> 于 2018年9月5日 GMT+08:00 下午3:14:35, Maxime Ripard
> > 写到:
> >> >On Mon, Sep 03, 2018 at 09:34:32
Currently unloading bochs_drm (after unbinding the vtconsole) results in
a warning about a leaked connector:
[drm:drm_mode_config_cleanup] *ERROR* connector Virtual-3 leaked!
While investigating a potential fix I noticed that a lot of open-coded
functionality is already implemented elsewhere,
On Wed, Sep 05, 2018 at 04:41:27PM +0200, Peter Wu wrote:
> Currently unloading bochs_drm (after unbinding the vtconsole) results in
> a warning about a leaked connector:
>
> [drm:drm_mode_config_cleanup] *ERROR* connector Virtual-3 leaked!
>
> While investigating a potential fix I noticed th
On Wed, Sep 05, 2018 at 01:51:25PM +0530, Jagan Teki wrote:
> On Wed, Sep 5, 2018 at 12:37 PM, Maxime Ripard
> wrote:
> > On Tue, Sep 04, 2018 at 10:06:08PM +0530, Jagan Teki wrote:
> >> Allwinner SoC like SUN8I and SUN50I are now using DE2 Mixer
> >> so enable them as default.
> >>
> >> Signed-of
On Wed, Sep 05, 2018 at 01:54:42PM +0530, Jagan Teki wrote:
> On Wed, Sep 5, 2018 at 12:38 PM, Maxime Ripard
> wrote:
> > On Tue, Sep 04, 2018 at 10:06:09PM +0530, Jagan Teki wrote:
> >> Allwinner SUN50I are now using DesignWare HDMI so enable
> >> them as default. This can build DRM_SUN8I_DW_HDMI
On Wed, Sep 05, 2018 at 04:46:29PM +0200, Daniel Vetter wrote:
> On Wed, Sep 05, 2018 at 04:41:27PM +0200, Peter Wu wrote:
> > Currently unloading bochs_drm (after unbinding the vtconsole) results in
> > a warning about a leaked connector:
> >
> > [drm:drm_mode_config_cleanup] *ERROR* connecto
https://bugs.freedesktop.org/show_bug.cgi?id=107793
--- Comment #7 from Nicholas Kazlauskas ---
Can you try booting with amdgpu.dc=0 in your kernel boot parameters?
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel
For atomic driver this is the default, no need to reimplement it. We
still need to keep the copypasta for not-atomic drivers though, since
no one polished the legacy crtc helpers as much as the atomic ones.
Signed-off-by: Daniel Vetter
Cc: Alex Deucher
Cc: Harry Wentland
Cc: Andrey Grodzovsky
Since this is handling user provided bpp and depth, we need to sanity
check and propagate the EINVAL back rather than assume what the insane
client intended and fill the logs with DRM_ERROR.
v2: Check both bpp and depth match the builtin pixel format, and
introduce a canonical DRM_FORMAT_INVALID t
Motivated by the ksummit-discuss discussion.
Cc: Shuah Khan
Cc: Thomas Petazzoni
Cc: Mauro Carvalho Chehab
Cc: Greg Kroah-Hartman
Cc: linux-fb...@vger.kernel.org
Signed-off-by: Daniel Vetter
---
MAINTAINERS| 2 ++
drivers/staging/fbtft/TODO | 4
2 files changed, 6 insert
Here's a set of patches that inserts a step into the build process to make
sure that the UAPI headers can all be built together with C++ (if the
compiler being used supports C++). All but the final patch perform fixups,
including:
(1) Fix member names that conflict with C++ reserved words by pr
The i810 and msm drm drivers use C++ keywords as structural members. Fix
this by inserting an anonymous union that provides an alternative name and
then hide the reserved name in C++.
Signed-off-by: David Howells
cc: Rob Clark
cc: David Airlie
cc: linux-arm-...@vger.kernel.org
cc: dri-devel@li
On Mon, Sep 03, 2018 at 12:54:44PM +0530, Sharat Masetty wrote:
> This patch fixes a trivial leak when trying to create a submitqueue.
>
> Signed-off-by: Sharat Masetty
Doh. Thanks.
Reviewed-by: Jordan Crouse
> ---
> drivers/gpu/drm/msm/msm_submitqueue.c | 4 +++-
> 1 file changed, 3 insertio
Hi Laurent,
On Tue, Sep 04, 2018 at 03:10:11PM +0300, Laurent Pinchart wrote:
> Hello everybody,
>
> This patch series adds display support for the D3 and E3 SoCs, and in
> particular the Draak and Ebisu boards.
>
> The code is based on Ulrich's "[PROTO][PATCH 00/10] R-Car D3 LVDS/HDMI support
> (
https://bugs.freedesktop.org/show_bug.cgi?id=105880
djip.per...@free.fr changed:
What|Removed |Added
Attachment #141452|0 |1
is obsolete|
On Wed, Sep 05, 2018 at 04:54:27PM +0100, David Howells wrote:
>
> Here's a set of patches that inserts a step into the build process to make
> sure that the UAPI headers can all be built together with C++ (if the
> compiler being used supports C++). All but the final patch perform fixups,
> incl
On Wed, Sep 05, 2018 at 03:57:06PM +0200, Daniel Vetter wrote:
> Only needed minimal changes in drm_internal.h (for the drm_ioctl_t
> type and a few forward declarations), plus a few missing includes in
> drm_connector.c.
>
> Yay, the last stage of the drm header cleanup can finally commence!
>
>
https://bugs.freedesktop.org/show_bug.cgi?id=105433
--- Comment #6 from Thomas R. ---
Tested with 4.18.5, same behaviour.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.o
On Wed, Sep 5, 2018 at 7:12 PM, Sam Ravnborg wrote:
> On Wed, Sep 05, 2018 at 03:57:06PM +0200, Daniel Vetter wrote:
>> Only needed minimal changes in drm_internal.h (for the drm_ioctl_t
>> type and a few forward declarations), plus a few missing includes in
>> drm_connector.c.
>>
>> Yay, the last
On Wed, Sep 05, 2018 at 07:33:38PM +0200, Yann Droneaud wrote:
> Hi,
>
> Le mercredi 05 septembre 2018 à 18:55 +0200, Greg KH a écrit :
> > On Wed, Sep 05, 2018 at 04:54:27PM +0100, David Howells wrote:
> > >
> > > Here's a set of patches that inserts a step into the build process to make
> > > s
https://bugs.freedesktop.org/show_bug.cgi?id=107784
--- Comment #10 from Felix Schwarz ---
(In reply to Sylvain BERTRAND from comment #9)
> Ok, I got it. Since my git knowledge is quite limited, this "merge" commit is
> opening a vast sea of new commits to test.
>
> I'll dive into bisection usi
From: Fabio Estevam
Adopt the SPDX license identifier headers to ease license compliance
management.
Signed-off-by: Fabio Estevam
---
drivers/gpu/drm/panel/panel-seiko-43wvf1g.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-seiko-43wvf1g.c
From: Fabio Estevam
There is a missing ">" character in Marco's email.
Fix it.
Signed-off-by: Fabio Estevam
---
drivers/gpu/drm/panel/panel-seiko-43wvf1g.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panel/panel-seiko-43wvf1g.c
b/drivers/gpu/drm/panel/
Greg KH wrote:
> > Here's a set of patches that inserts a step into the build process to make
> > sure that the UAPI headers can all be built together with C++ (if the
> > compiler being used supports C++). All but the final patch perform fixups,
> > including:
>
> Wait, why do we care? What h
The DRM bus flags convey additional information on pixel data on
the bus. All current available bus flags might be of interest for
a bridge. Remove the sampling_edge field and use bus_flags.
In the case at hand a dumb VGA bridge needs a specific data enable
polarity (DRM_BUS_FLAG_DE_LOW).
Signed-
Use libutil to lookup connector type names and state. This also
makes sure that the latest connector type addition "DPI" gets
printed correctly.
Signed-off-by: Stefan Agner
---
tests/modeprint/Makefile.am | 1 +
tests/modeprint/meson.build | 2 +-
tests/modeprint/modeprint.c | 43 ++---
Support boards with a passive RGB to VGA bridge which require a low
active data-enable polarity.
Signed-off-by: Stefan Agner
---
Alternatively a new dt binding could be introduced for dumb VGA bridges
requiring low active data enable... However, also other polarities might
need a specific polarit
Allow to specify the data-enable polarity required by a dumb VGA
DAC converting parallel RGB to VGA.
Signed-off-by: Stefan Agner
---
.../devicetree/bindings/display/bridge/dumb-vga-dac.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/display/brid
Print encoder types similar to connector types.
Signed-off-by: Stefan Agner
---
tests/modeprint/modeprint.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/tests/modeprint/modeprint.c b/tests/modeprint/modeprint.c
index 1d62270f..ad727e12 100644
--- a/tests/modeprint/m
On Wed, Aug 29, 2018 at 03:31:11PM +0100, Chris Wilson wrote:
> Quoting Lucas De Marchi (2018-08-29 01:35:32)
> > We don't need to call IS_GEN() for each gen >= 9: we can rather use the
> > new intel_is_genx() helper to iterate the pciids array once.
> >
> > Signed-off-by: Lucas De Marchi
> > ---
On 05.09.2018 11:00, Stefan Agner wrote:
> The DRM bus flags convey additional information on pixel data on
> the bus. All current available bus flags might be of interest for
> a bridge. Remove the sampling_edge field and use bus_flags.
>
> In the case at hand a dumb VGA bridge needs a specific d
On 05.09.2018 00:07, Laurent Pinchart wrote:
> Hi Stefan,
>
> Thank you for the patch.
>
> On Wednesday, 5 September 2018 08:21:10 EEST Stefan Agner wrote:
>> Allow to specify the data-enable polarity required by a dumb VGA
>> DAC converting parallel RGB to VGA.
>>
>> Signed-off-by: Stefan Agner
- drmP.h is now fully split up.
- vkms is happening (and will gain its own todo and docs under a new
vkms.rst file real soon)
- legacy cruft is completely hidden now, drm_vblank.c is split out
from drm_irq.c now. I've decided to drop the task to split out
drm_legacy.ko, partially because Dave
For atomic driver this is the default, no need to reimplement it. We
still need to keep the copypasta for not-atomic drivers though, since
no one polished the legacy crtc helpers as much as the atomic ones.
v2: amdgpu uses ->best_encoder internally, give it a local copy. It
might be a good idea to
On Wed, Sep 05, 2018 at 08:04:43AM +0200, Gerd Hoffmann wrote:
> Userspace on big endian machhines typically expects the ADDFB ioctl
> returns a big endian framebuffer. drm_mode_addfb() will call
> drm_mode_addfb2() unconditionally with little endian DRM_FORMAT_*
> values though, which is wrong.
Hi Dave,
Here goes drm-intel-fixes-2018-09-05:
The critical fix here on display side is the DP MST regression one.
But this pull also include fixes for DP SST, small VDSC register fix
and GVT's bucked with "BXT fixes, two guest warning fixes, dmabuf
format mod fix and one for recent multiple VM t
On 05.09.2018 00:44, Laurent Pinchart wrote:
> Hi Stefan,
>
> On Wednesday, 5 September 2018 10:06:28 EEST Laurent Pinchart wrote:
>> On Wednesday, 5 September 2018 08:21:08 EEST Stefan Agner wrote:
>> > The DRM bus flags convey additional information on pixel data on
>> > the bus. All current ava
Adding PCI IDs to different projects is a boring manual task that
motivated me to create this series. The idea is to centralize the IDs in
the kernel header and let other projects copy it.
Initially my plan was to convert all gens, back to gen2, but that proved
slightly difficult since there are s
Signed-off-by: Lucas De Marchi
---
intel/intel_chipset.c | 1 +
intel/intel_chipset.h | 27 ++-
2 files changed, 3 insertions(+), 25 deletions(-)
diff --git a/intel/intel_chipset.c b/intel/intel_chipset.c
index 545819ae..a960b756 100644
--- a/intel/intel_chipset.c
+++ b/
This will allow platforms to reuse kernel IDs instead of manually
keeping them in sync. In most of the cases we only need to extend
IS_9XX(). Current platforms that fit this requirement can be ported
over to use this macro. Right now it's a nop since it doesn't have any
PCI ID added.
The i915_pci
We don't need to call IS_GEN() for each gen >= 9: we can rather use the
new intel_is_genx() helper to iterate the pciids array once.
Signed-off-by: Lucas De Marchi
---
intel/intel_bufmgr_gem.c | 8 +---
intel/intel_decode.c | 8 ++--
2 files changed, 3 insertions(+), 13 deletions(-)
Signed-off-by: Lucas De Marchi
---
intel/intel_chipset.c | 1 +
intel/intel_chipset.h | 34 +-
2 files changed, 2 insertions(+), 33 deletions(-)
diff --git a/intel/intel_chipset.c b/intel/intel_chipset.c
index a960b756..a627928e 100644
--- a/intel/intel_chipset.c
The 2 PCI IDs that are used for the command line overrid mechanism
were left defined. The rest can be gone and then we just use the kernel
defines.
Signed-off-by: Lucas De Marchi
---
intel/intel_chipset.c | 5 ++
intel/intel_chipset.h | 187 +-
2 files c
The newly added internal rgb encoder for Rockchip vops is missing
stubs for the case that the rgb output part is not enabled in the
kernel config. So add these.
Fixes: 1f0f01515172 ("drm/rockchip: Add support for Rockchip Soc RGB output
interface")
Signed-off-by: Heiko Stuebner
---
drivers/gpu/
On Wed, Sep 05, 2018 at 09:13:02PM +0200, Heiko Stuebner wrote:
> The newly added internal rgb encoder for Rockchip vops is missing
> stubs for the case that the rgb output part is not enabled in the
> kernel config. So add these.
>
> Fixes: 1f0f01515172 ("drm/rockchip: Add support for Rockchip So
This series adds an iterator for cpu nodes and converts users over to use
it or of_get_cpu_node in some cases. This allows us to remove the
dependency on device_type property for cpu nodes though removing that
from DTS files will have to wait for some time. In some cases, this makes
the DT search m
"device_type" use is deprecated for FDT though it has continued to be used
for nodes like cpu nodes. Use of_get_cpu_node() instead which works using
node names by default. This will allow the eventually removal of cpu
device_type properties.
Cc: Timur Tabi
Cc: Bartlomiej Zolnierkiewicz
Cc: linux
>
> > 2) patch revision info belongs outside the changelog part - no?
>
> If it's information worth writing it's information worth recording. In
> drm we're pretty much ok with whatever you feel like, and most people
> include the patch revision in the commit message. Too many cases where
> criti
On Wed, Sep 05, 2018 at 03:33:56PM -0400, Sean Paul wrote:
> On Wed, Sep 05, 2018 at 09:13:02PM +0200, Heiko Stuebner wrote:
> > The newly added internal rgb encoder for Rockchip vops is missing
> > stubs for the case that the rgb output part is not enabled in the
> > kernel config. So add these.
>
Quoting Lucas De Marchi (2018-09-05 19:31:55)
> Adding PCI IDs to different projects is a boring manual task that
> motivated me to create this series. The idea is to centralize the IDs in
> the kernel header and let other projects copy it.
>
> Initially my plan was to convert all gens, back to ge
At times 12bpc HDMI cannot be driven due to faulty cables, dongles
level shifters etc. To workaround them we may need to drive the output
at a lower bpc. Currently the user space does not have a way to limit
the bpc. The default bpc to be programmed is decided by the driver and
is run against conne
Use the newly added "max bpc" connector property to limit pipe bpp.
V3: Use drm_connector_state to access the "max bpc" property
V4: Initialize the drm property, add suuport to DP(Ville)
V5: Use the property in the connector and fix CI failure(Ville)
Cc: Ville Syrjälä
Cc: Rodrigo Vivi
Cc: Kisho
Hi Dave,
Here's the latest from -misc-next. This PR includes last weeks as well, I've
added both summaries below for your convenience.
This week was quite busy, guess everyone is back to work now! This pull features
a nice mix of new hw support and code cleanup, with the headliner being udmabuf.
From: Sean Paul
I ran across this last week when I was trying to get this function to
work. It's useful to have the scale values in the log upon failure.
Signed-off-by: Sean Paul
---
drivers/gpu/drm/drm_atomic_helper.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drive
Hi Stefan,
On Wednesday, 5 September 2018 21:10:08 EEST Stefan Agner wrote:
> On 05.09.2018 00:07, Laurent Pinchart wrote:
> > On Wednesday, 5 September 2018 08:21:10 EEST Stefan Agner wrote:
> >> Allow to specify the data-enable polarity required by a dumb VGA
> >> DAC converting parallel RGB to
https://bugs.freedesktop.org/show_bug.cgi?id=107045
--- Comment #24 from taij...@posteo.de ---
OK, another update after another test, this time booting into a live system
without any graphical shell/login manager.
Here, manipulating /sys/class/intel_backlight/brightness does nothing to the
dGPU,
bisected: e2a9ca29b5edc89da2fddeae30e1070b272395c5
This commit is one in a series related to new TSC code.
I tried to switch the clocksource to hpet early in the boot process, did not
change anything.
Any ideas before I post an issue on kernel bugzilla?
__
https://bugs.freedesktop.org/show_bug.cgi?id=107784
--- Comment #11 from Sylvain BERTRAND ---
bisected: e2a9ca29b5edc89da2fddeae30e1070b272395c5
This commit is one in a series related to new TSC code.
I tried to switch the clocksource to hpet early in the boot process, did not
change anything.
https://bugs.freedesktop.org/show_bug.cgi?id=107784
Sylvain BERTRAND changed:
What|Removed |Added
Attachment #141416|0 |1
is obsolete|
https://bugs.freedesktop.org/show_bug.cgi?id=107784
--- Comment #13 from Sylvain BERTRAND ---
Created attachment 141465
--> https://bugs.freedesktop.org/attachment.cgi?id=141465&action=edit
kernel log from a good commit
--
You are receiving this mail because:
You are the assignee for the bug.
On Wed, Sep 05, 2018 at 04:46:01PM -0400, Sean Paul wrote:
> From: Sean Paul
>
> I ran across this last week when I was trying to get this function to
> work. It's useful to have the scale values in the log upon failure.
>
> Signed-off-by: Sean Paul
Reviewed-by: Daniel Vetter
> ---
> driver
On Wed, Sep 05, 2018 at 01:12:00PM -0700, Radhakrishna Sripada wrote:
> Use the newly added "max bpc" connector property to limit pipe bpp.
>
> V3: Use drm_connector_state to access the "max bpc" property
> V4: Initialize the drm property, add suuport to DP(Ville)
> V5: Use the property in the con
On Wed, Sep 05, 2018 at 08:56:44PM +0100, Chris Wilson wrote:
> Quoting Lucas De Marchi (2018-09-05 19:31:55)
> > Adding PCI IDs to different projects is a boring manual task that
> > motivated me to create this series. The idea is to centralize the IDs in
> > the kernel header and let other projec
From: Lukasz Spintzyk
FB_DAMAGE_CLIPS is an optional plane property to mark damaged regions
on the plane in framebuffer coordinates of the framebuffer attached to
the plane.
The layout of blob data is simply an array of "struct drm_mode_rect"
with maximum array size limited by DRM_MODE_FB_DIRTY_
Using the new interface implement STDU plane update for surface backed
fb.
Signed-off-by: Deepak Rawat
---
drivers/gpu/drm/vmwgfx/vmwgfx_kms.h | 11 ++
drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c | 209 ++-
2 files changed, 219 insertions(+), 1 deletion(-)
diff --git a/driver
With fb_damage_clips blob property in drm_plane_state, this patch adds
helper iterator to traverse the damage clips that lie inside plane src.
Iterator will return full plane src as damage in case need full plane
update or damage is not specified.
Signed-off-by: Deepak Rawat
---
drivers/gpu/drm/
Add a new struct vmw_du_update_plane similar to vmw_kms_dirty which
represent the flow of operations needed to update a display unit from
surface or bo(blit a new framebuffer).
Signed-off-by: Deepak Rawat
---
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 108 +
drivers/gpu/drm/vmwgfx
From: Rob Clark
Add an atomic helper to implement dirtyfb support. This is needed to
support DSI command-mode panels with x11 userspace (ie. when we can't
rely on pageflips to trigger a flush to the panel).
v2: Modified the helper to use plane fb_damage_clips property and
removed plane_state::d
Using the new interface implement SOU plane update for surface backed
fb.
Signed-off-by: Deepak Rawat
---
drivers/gpu/drm/vmwgfx/vmwgfx_kms.h | 3 +
drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c | 187 +++
2 files changed, 190 insertions(+)
diff --git a/drivers/gpu/drm/vmwgfx/
STDU primary plane now support damage clips, enable it for user-space.
Signed-off-by: Deepak Rawat
---
drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
index 167190b75e2f..11a76aa
With new interface to do plane update on STDU available, use that
instead of old kms_dirty. Update the commet to sync with code.
Signed-off-by: Deepak Rawat
---
drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c | 38 +++-
1 file changed, 9 insertions(+), 29 deletions(-)
diff --git a/
With new atomic helper for dirty fb IOCTL is available which uses damage
interface, use that for dirty fb IOCTL.
Signed-off-by: Deepak Rawat
---
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 116 +---
1 file changed, 2 insertions(+), 114 deletions(-)
diff --git a/drivers/gpu/drm
Using the new interface implement SOU plane update for BO backed fb.
Signed-off-by: Deepak Rawat
---
drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c | 134 +++
1 file changed, 134 insertions(+)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.
Using the new interface implement STDU plane update for BO backed fb.
Signed-off-by: Deepak Rawat
---
drivers/gpu/drm/vmwgfx/vmwgfx_kms.h | 14 ++
drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c | 235 +++
2 files changed, 249 insertions(+)
diff --git a/drivers/gpu/drm/vmwgfx/vmw
Plane damage is irrelevant when full modeset happens so clear the damage
blob property(If set by user-space). With damage blob cleared damage
helper iterator will return full plane src as damage clip.
Signed-off-by: Deepak Rawat
---
drivers/gpu/drm/drm_atomic_helper.c | 4
include/drm/drm_
SOU primary plane now support damage clips, enable it for user-space.
Signed-off-by: Deepak Rawat
---
drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
index 290d550d1b77..c49666
101 - 200 of 245 matches
Mail list logo
