I want to split up a few more things and document some details better
(like how exactly to subclass drm_atomic_state). And maybe also split
up the helpers a bit per-topic, but this should be a ok-ish start for
better atomic overview.
v2: Spelling and clarifications (Eric).
v3: Implement suggestio
On Wed, Mar 01, 2017 at 02:42:02PM -0300, Gabriel Krisman Bertazi wrote:
> Daniel Vetter writes:
>
> > I've spent quite some time trying to beat DOT into submission, this is the
> > best I can do. The FIXME really is just a hint for someone with more clue
> > to maybe make it better, or if not po
On Wed, Mar 01, 2017 at 12:56:36PM -0300, Gabriel Krisman Bertazi wrote:
> Daniel Vetter writes:
>
> Hi Daniel,
>
> > +if dst_fname:
> > +name = dst_fname[len(out_dir) + 1:]
> > +# the builder needs not to copy one more time, so pop it if exists.
> > +translator.build
On Tue, Feb 28, 2017 at 04:36:51PM +0100, Maxime Ripard wrote:
> Implement legacy framebuffer ioctl FBIO_WAITFORVSYNC in the generic
> framebuffer emulation driver. Legacy framebuffer users like non kms/drm
> based OpenGL(ES)/EGL implementations may require the ioctl to
> synchronize drawing or buf
On Wed, Mar 01, 2017 at 06:50:08PM -0300, Gabriel Krisman Bertazi wrote:
> Daniel Vetter writes:
>
> Hi Daniel, thanks again for your review.
>
> > Hm, I bit silly that we need #ifdef here, all this stuff is meant to Just
> > Work. Can't we just fix the oops with suitable checks in the fini path
On Thu, Mar 02, 2017 at 02:30:09AM +0200, Laurent Pinchart wrote:
> Hi Daniel,
>
> On Wednesday 04 Jan 2017 17:13:23 Laurent Pinchart wrote:
> > On Wednesday 04 Jan 2017 15:58:25 Daniel Vetter wrote:
> > > On Wed, Jan 04, 2017 at 04:33:57PM +0200, Laurent Pinchart wrote:
> > >> On Wednesday 04 Jan
On Wed, Mar 01, 2017 at 11:42:48AM +0100, Daniel Vetter wrote:
> Hi all,
>
> topic/designware-baytrail-2017-03-01:
> Baytrail PMIC vs. PMU race fixes from Hans de Goede
>
> I opted to put all the patches for all subsystems into the topic branches,
> so that if needed, each subsystem can apply ref
tree: git://anongit.freedesktop.org/drm-intel topic/designware-baytrail
head: ca9b131b63aaf21419725bcf90497877d6bf6271
commit: 26363e10f680194a71c8d4287c8e2886ed539c4e [2/12]
x86/platform/intel/iosf_mbi: Add a PMIC bus access notifier
config: i386-randconfig-c0-03021134 (attached as .config)
c
Regards
Shashank
On 3/1/2017 8:41 PM, Ville Syrjälä wrote:
On Tue, Feb 28, 2017 at 02:09:09PM +0530, Shashank Sharma wrote:
Geminilake platform sports a native HDMI 2.0 controller, and is
capable of driving pixel-clocks upto 594Mhz. HDMI 2.0 spec
mendates scrambling for these higher clocks, f
Regards
Shashank
On 3/1/2017 8:28 PM, Ville Syrjälä wrote:
On Tue, Feb 28, 2017 at 02:09:08PM +0530, Shashank Sharma wrote:
This patch does following:
- Adds a new structure (drm_hdmi_info) in drm_display_info.
This structure will be used to save and indicate if sink
supports advanced H
On 02/28/2017 06:58 PM, Krzysztof Kozlowski wrote:
On Tue, Feb 28, 2017 at 10:17 AM, Hoegeun Kwon wrote:
Hi All,
[Resend this v2 patches, because i have missing TO and CC.]
The dsi + panel is a parental relationship, so OF grpah is not needed.
Therefore, the current dsi_parse_dt function will
https://bugs.freedesktop.org/show_bug.cgi?id=100024
Michel Dänzer changed:
What|Removed |Added
Product|DRI |Mesa
Version|XOrg git
https://bugs.freedesktop.org/show_bug.cgi?id=100024
Michel Dänzer changed:
What|Removed |Added
Attachment #130009|text/x-log |text/plain
mime type|
https://bugs.freedesktop.org/show_bug.cgi?id=100024
Michel Dänzer changed:
What|Removed |Added
Attachment #130008|text/x-log |text/plain
mime type|
https://bugs.freedesktop.org/show_bug.cgi?id=100024
Michel Dänzer changed:
What|Removed |Added
Attachment #130018|text/x-log |text/plain
mime type|
Hi Laurent,
On 01-03-2017 11:09, Laurent Pinchart wrote:
> Hi Jose,
>
> On Thursday 05 Jan 2017 15:06:49 Jose Abreu wrote:
>> On 05-01-2017 12:29, Laurent Pinchart wrote:
>>> On Tuesday 20 Dec 2016 12:17:23 Jose Abreu wrote:
On 20-12-2016 11:45, Russell King - ARM Linux wrote:
> On Tue,
Hi,
On Wed, Mar 01, 2017 at 01:31:01PM +0100, Boris Brezillon wrote:
> The current suspend resume implementation is assuming register values are
> kept when entering suspend, which is no longer the case with the
> suspend-to-RAM on the sama5d2.
>
> While at it, switch to the generic infrastructur
On Wed, Mar 01, 2017 at 09:38:48AM +0530, Archit Taneja wrote:
[...]
> > +static const struct i2c_device_id stdp2690_ge_b850v3_fw_i2c_table[] = {
> > + {"stdp2690_ge_fw", 0},
> > + {},
> > +};
> > +MODULE_DEVICE_TABLE(i2c, stdp2690_ge_b850v3_fw_i2c_table);
> > +
> > +static const struct of_devi
On 02/28/2017 07:58 PM, Peter Senna Tschudin wrote:
The video processing pipeline on the second output on the GE B850v3:
Host -> LVDS|--(STDP4028)--|DP -> DP|--(STDP2690)--|DP++ -> Video output
Each bridge has a dedicated flash containing firmware for supporting the
custom design. The resul
Updating the state in a running VSP1 requires two interrupts from the
VSP. Initially, the updated state will be committed - but only after the
VSP1 has completed processing it's current frame will the new state be
taken into account. As such, the committed state will only be 'completed'
after an ex
Hi Archit,
Thank you for the review!
On Wed, Mar 01, 2017 at 09:38:48AM +0530, Archit Taneja wrote:
>
>
> On 02/28/2017 07:58 PM, Peter Senna Tschudin wrote:
> > The video processing pipeline on the second output on the GE B850v3:
> >
> > Host -> LVDS|--(STDP4028)--|DP -> DP|--(STDP2690)--|D
The DRM object does not register the pipe with the WPF object. This is
used internally throughout the driver as a means of accessing the pipe.
As such this breaks operations which require access to the pipe from WPF
interrupts.
Register the pipe inside the WPF object after it has been declared as
To be able to perform page flips in DRM without flicker we need to be
able to notify the rcar-du module when the VSP has completed its
processing.
To synchronise the page flip events for userspace, we move the required
event through the VSP to track the data flow. When the frame is
completed, the
The RCAR-DU utilises a running VSPD pipeline to perform processing
for the display pipeline.
Changes to this pipeline are performed with an atomic flush operation which
updates the state in the VSPD. Due to the way the running pipeline is
operated, any flush operation has an implicit latency of on
Hi Daniel,
On Wednesday 04 Jan 2017 17:13:23 Laurent Pinchart wrote:
> On Wednesday 04 Jan 2017 15:58:25 Daniel Vetter wrote:
> > On Wed, Jan 04, 2017 at 04:33:57PM +0200, Laurent Pinchart wrote:
> >> On Wednesday 04 Jan 2017 14:51:48 Daniel Vetter wrote:
> >>> Hm, something like drm_bridge_panel_
On 2017-02-24 07:14 PM, Jeff Smith wrote:
Signed-off-by: Jeff Smith
---
drivers/gpu/drm/amd/display/dc/core/dc_link.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
index 2b
On Tue, Feb 28, 2017 at 7:55 AM, Joe Perches wrote:
> Use a more common logging style.
>
> Miscellanea:
>
> o Coalesce formats and realign arguments
> o Neaten a few macros now using pr_
>
> Signed-off-by: Joe Perches
Applied. Thanks!
Alex
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu.h
On 2017-02-24 07:14 PM, Jeff Smith wrote:
Signed-off-by: Jeff Smith
---
.../drm/amd/display/amdgpu_dm/amdgpu_dm_types.c| 32 --
.../display/dc/dce110/dce110_timing_generator.c| 4 ---
2 files changed, 23 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/a
On Mon, Feb 27, 2017 at 8:31 PM, Joe Perches wrote:
> Using 'printk("\n")' is not preferred anymore and
> using printk to continue logging messages now produces
> multiple line logging output unless the continuations
> use KERN_CONT.
>
> Convert these uses to appropriately use pr_cont or a
> singl
Den 01.03.2017 15.31, skrev Daniel Vetter:
On Fri, Jan 27, 2017 at 03:29:29PM +0100, Daniel Vetter wrote:
On Fri, Jan 27, 2017 at 03:23:43PM +0100, Noralf Trønnes wrote:
Den 27.01.2017 08.49, skrev Daniel Vetter:
On Thu, Jan 26, 2017 at 11:56:02PM +0100, Noralf Trønnes wrote:
This patchset r
Hi Jose,
On Wednesday 01 Mar 2017 16:25:46 Jose Abreu wrote:
> On 01-03-2017 11:09, Laurent Pinchart wrote:
> > On Thursday 05 Jan 2017 15:06:49 Jose Abreu wrote:
> >> On 05-01-2017 12:29, Laurent Pinchart wrote:
> >>> On Tuesday 20 Dec 2016 12:17:23 Jose Abreu wrote:
> On 20-12-2016 11:45, R
From: Neil Armstrong
The Synopsys Designware HDMI TX Controller does not enforce register
access on platforms instanciating it. The current driver supports two
different types of memory-mapped flat register access, but in order to
support the Amlogic Meson SoCs integration, and provide a more gen
From: Kieran Bingham
The device type isn't used anymore now that workarounds and PHY-specific
operations are performed based on version information read at runtime.
Remove it.
Signed-off-by: Kieran Bingham
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/bridge/dw-hdmi.c| 2 --
Hello,
This patch series refactors all the PHY handling code in order to allow
support of vendor PHYs and Synopsys DWC HDMI 2.0 TX PHYs.
The series starts with a few cleanups and small fixes. Patch 1/9 just removes
unused code, patch 2/9 moves the color converter code out of the PHY configure
fun
From: Kieran Bingham
The DWC HDMI TX controller interfaces with a companion PHY. While
Synopsys provides multiple standard PHYs, SoC vendors can also integrate
a custom PHY.
Modularize PHY configuration to support vendor PHYs through platform
data. The existing PHY configuration code was origina
When powering the PHY up we need to wait for the PLL to lock. This is
done by polling the TX_PHY_LOCK bit in the HDMI_PHY_STAT0 register
(interrupt-based wait could be implemented as well but is likely
overkill). The bit is asserted when the PLL locks, but the current code
incorrectly waits for the
The HDMI TX controller support different PHYs whose programming
interface can vary significantly, especially with vendor PHYs that are
not provided by Synopsys. To support them, create a PHY operation
structure that can be provided by the platform glue layer. The existing
PHY handling code (limited
The PHY requires us to wait for the PHY to switch to low power mode
after deasserting TXPWRON and before asserting PDDQ in the power down
sequence, otherwise power down will fail.
The PHY power down can be monitored though the TX_READY bit, available
through I2C in the PHY registers, or the TX_PHY
From: Neil Armstrong
If the input pixel format is not RGB, the CSC must be enabled in order to
provide valid pixel to DVI sinks.
This patch removes the hdmi only dependency on the CSC enabling.
Reviewed-by: Jose Abreu
Reviewed-by: Laurent Pinchart
Signed-off-by: Neil Armstrong
---
drivers/gp
The color space converter isn't part of the PHY, move its configuration
out of PHY code.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/bridge/dw-hdmi.c | 25 ++---
1 file changed, 10 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c b/drivers
Most of the hdmi_phy_test_*() functions are unused. Remove them.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/bridge/dw-hdmi.c | 26 --
1 file changed, 26 deletions(-)
diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c b/drivers/gpu/drm/bridge/dw-hdmi.c
index 9a9ec27d9
Daniel Vetter writes:
Hi Daniel, thanks again for your review.
> Hm, I bit silly that we need #ifdef here, all this stuff is meant to Just
> Work. Can't we just fix the oops with suitable checks in the fini paths
> instead?
Heh. I expected someone would bring up this objection. My rationale i
Hi Maxime,
On Tue, Feb 28, 2017 at 04:36:51PM +0100, Maxime Ripard wrote:
> Implement legacy framebuffer ioctl FBIO_WAITFORVSYNC in the generic
> framebuffer emulation driver. Legacy framebuffer users like non kms/drm
> based OpenGL(ES)/EGL implementations may require the ioctl to
On Wed, Mar 01, 2017 at 04:01:05PM -0300, Gabriel Krisman Bertazi wrote:
> Daniel Vetter writes:
>
> > You forgot to update the kernel-doc, building them now generates new
> > warnings. Please fix in a follow-up patch.
>
> Hm, that´s a bummer. Please take the fix below. Thanks for spotting.
A
On Fri, Feb 24, 2017 at 12:54:43PM +, John Keeping wrote:
> This version is mostly small changes in response to review comments from
> Sean and Chris, the details are in the individual patches.
>
> I decided to drop the final patch which adds support for MIPI read
> commands because I'm not us
On Mon, Feb 20, 2017 at 04:02:16PM +0800, Chris Zhong wrote:
> Hi all
>
> [Resend this v7 version series, since there are 5 mails have gone missing,
> last
> week]
>
> This version does not change the existing v6 patches, just to add the
> "bandwidth fix" patch back, since we really need it.
>
Daniel Vetter writes:
> You forgot to update the kernel-doc, building them now generates new
> warnings. Please fix in a follow-up patch.
Hm, that´s a bummer. Please take the fix below. Thanks for spotting.
-- >8 --
Subject: [PATCH] drm: Update drm_fbdev_cma_init documentation
Commit be7f735
If a CMA allocation failed, the partially constructed BO would be
unreferenced through the normal path, and we might choose to put it in
the BO cache. If we then reused it before it expired from the cache,
the kernel would OOPS.
Signed-off-by: Eric Anholt
Fixes: c826a6e10644 ("drm/vc4: Add a BO
The from_cache flag was actually "the BO is invisible to userspace",
so we can repurpose it to just zero out a cached BO and return it to
userspace.
Improves wall time for a loop of 5 glsl-algebraic-add-add-1 by
-1.44989% +/- 0.862891% (n=28, 1 outlier removed from each that
appeared to be other s
Gerd Hoffmann writes:
> Hi,
>
> This little series has some fixes and cleanups for the qxl driver.
> Based on drm-misc-next branch.
>
Hi Gerd,
Please add a reviewed-by for series.
Reviewed-by: Gabriel Krisman Bertazi
> cheers,
> Gerd
>
> Gerd Hoffmann (4):
> qxl: drop mode_info.modes
On Wed, Mar 01, 2017 at 09:50:56AM -0800, Ben Widawsky wrote:
> On 17-03-01 12:51:17, Ville Syrjälä wrote:
> >On Tue, Feb 28, 2017 at 03:20:38PM -0800, Ben Widawsky wrote:
> >> On 17-02-28 12:18:39, Jason Ekstrand wrote:
> >
> >> >I've said it before but reading through Ben's patches again make me
https://bugs.freedesktop.org/show_bug.cgi?id=100024
--- Comment #10 from Julien Isorce ---
Created attachment 130018
--> https://bugs.freedesktop.org/attachment.cgi?id=130018&action=edit
output of max-texture-size2 test with attached patch for mesa
--
You are receiving this mail because:
You
https://bugs.freedesktop.org/show_bug.cgi?id=100024
--- Comment #9 from Julien Isorce ---
Created attachment 130016
--> https://bugs.freedesktop.org/attachment.cgi?id=130016&action=edit
patch for mesa to translate the radeonsi printf ENOMEM to a proper
GL_OUT_OF_MEMORY
--
You are receiving th
On 17-03-01 12:51:17, Ville Syrjälä wrote:
On Tue, Feb 28, 2017 at 03:20:38PM -0800, Ben Widawsky wrote:
On 17-02-28 12:18:39, Jason Ekstrand wrote:
>I've said it before but reading through Ben's patches again make me want to
>be peskier about it. I would really like the UABI to treat the CC
https://bugs.freedesktop.org/show_bug.cgi?id=100024
--- Comment #8 from Julien Isorce ---
Created attachment 130015
--> https://bugs.freedesktop.org/attachment.cgi?id=130015&action=edit
output of max-texture-size2 test with USE_FENCE workaround
--
You are receiving this mail because:
You are
https://bugs.freedesktop.org/show_bug.cgi?id=100024
--- Comment #7 from Julien Isorce ---
Created attachment 130014
--> https://bugs.freedesktop.org/attachment.cgi?id=130014&action=edit
output of max-texture-size2 test with MESA_VERBOSE and R600_DEBUG
--
You are receiving this mail because:
Y
https://bugs.freedesktop.org/show_bug.cgi?id=100024
--- Comment #6 from Julien Isorce ---
Created attachment 130013
--> https://bugs.freedesktop.org/attachment.cgi?id=130013&action=edit
output of max-texture-size2 test with MESA_VERBOSE
--
You are receiving this mail because:
You are the assi
https://bugs.freedesktop.org/show_bug.cgi?id=100024
--- Comment #5 from Julien Isorce ---
Created attachment 130012
--> https://bugs.freedesktop.org/attachment.cgi?id=130012&action=edit
default output of max-texture-size2 test
--
You are receiving this mail because:
You are the assignee for t
https://bugs.freedesktop.org/show_bug.cgi?id=100024
--- Comment #4 from Julien Isorce ---
Created attachment 130011
--> https://bugs.freedesktop.org/attachment.cgi?id=130011&action=edit
max-texture-size2 backtrace untill ENOMEM
--
You are receiving this mail because:
You are the assignee for
https://bugs.freedesktop.org/show_bug.cgi?id=100024
--- Comment #3 from Julien Isorce ---
Created attachment 130009
--> https://bugs.freedesktop.org/attachment.cgi?id=130009&action=edit
Xorg.log
--
You are receiving this mail because:
You are the assignee for the bug._
https://bugs.freedesktop.org/show_bug.cgi?id=100024
--- Comment #2 from Julien Isorce ---
Created attachment 130008
--> https://bugs.freedesktop.org/attachment.cgi?id=130008&action=edit
dmesg
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=100024
--- Comment #1 from Julien Isorce ---
Created attachment 130006
--> https://bugs.freedesktop.org/attachment.cgi?id=130006&action=edit
lspic -s -v
--
You are receiving this mail because:
You are the assignee for the bug.__
https://bugs.freedesktop.org/show_bug.cgi?id=100024
Bug ID: 100024
Summary: [radeonsi] Failed to find memory space for buffer
eviction when calling glTexSubImage2D with 16384 / 2
Product: DRI
Version: XOrg git
Hardware: All
Daniel Vetter writes:
> I want to split up a few more things and document some details better
> (like how exactly to subclass drm_atomic_state). And maybe also split
> up the helpers a bit per-topic, but this should be a ok-ish start for
> better atomic overview.
>
> One thing I failed at is gett
Daniel Vetter writes:
> I've spent quite some time trying to beat DOT into submission, this is the
> best I can do. The FIXME really is just a hint for someone with more clue
> to maybe make it better, or if not possible at all, what would look better
> when doing a proper diagram with .svg or so
Daniel Vetter writes:
> Resulted in confusion a few times in the past.
>
Reviewed-by: Gabriel Krisman Bertazi
--
Gabriel Krisman Bertazi
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-de
Daniel Vetter writes:
> Oh, the shiny and pretties!
>
Very nice!
Reviewed-by: Gabriel Krisman Bertazi
--
Gabriel Krisman Bertazi
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Wed, Mar 01, 2017 at 04:07:02PM +0200, Ville Syrjälä wrote:
> On Mon, Feb 20, 2017 at 04:25:45PM +0100, Tomeu Vizoso wrote:
> > Rotel RSX-1058 is a receiver with 4 HDMI inputs and a HDMI output, all
> > 1.1.
> >
> > When a sink that supports deep color is connected to the output, the
> > receiv
Daniel Vetter writes:
Hi Daniel,
> +if dst_fname:
> +name = dst_fname[len(out_dir) + 1:]
> +# the builder needs not to copy one more time, so pop it if exists.
> +translator.builder.images.pop(img_node['uri'], None)
> +img_node['uri'] = dst_fname
> +im
On Fri, Dec 16, 2016 at 12:29:07PM +0200, Jani Nikula wrote:
> From: Manasi Navare
>
> If link training at a link rate optimal for a particular
> mode fails during modeset's atomic commit phase, then we
> let the modeset complete and then retry. We save the link rate
> value at which link trainin
On Tue, Feb 28, 2017 at 02:09:09PM +0530, Shashank Sharma wrote:
> Geminilake platform sports a native HDMI 2.0 controller, and is
> capable of driving pixel-clocks upto 594Mhz. HDMI 2.0 spec
> mendates scrambling for these higher clocks, for reduced RF footprint.
>
> This patch checks if the moni
On Wed, Mar 01, 2017 at 06:45:10AM -0800, Manasi Navare wrote:
> This fixes the kernel doc warning that was introduced in
> the 'commit 40ee6fbef75fe6 ("drm: Add a new connector
> atomic property for link status")'. Description has
> been added for the enum values.
>
> Signed-off-by: Manasi Navare
On Wed, Mar 01, 2017 at 03:09:08PM +0100, Gerd Hoffmann wrote:
> Just use kmem_cache instead of rolling
> our own, limited implementation.
>
> Signed-off-by: Gerd Hoffmann
Looks very reasonable.
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/virtio/virtgpu_drv.h | 4 +--
> drivers/gpu/d
On Tue, Feb 28, 2017 at 02:09:08PM +0530, Shashank Sharma wrote:
> This patch does following:
> - Adds a new structure (drm_hdmi_info) in drm_display_info.
> This structure will be used to save and indicate if sink
> supports advanced HDMI 2.0 features
> - Adds another structure drm_scdc within
This fixes the kernel doc warning that was introduced in
the 'commit 40ee6fbef75fe6 ("drm: Add a new connector
atomic property for link status")'. Description has
been added for the enum values.
Signed-off-by: Manasi Navare
Cc: Jani Nikula
Cc: Daniel Vetter
Cc: dri-devel@lists.freedesktop.org
-
On Fri, Jan 27, 2017 at 03:29:29PM +0100, Daniel Vetter wrote:
> On Fri, Jan 27, 2017 at 03:23:43PM +0100, Noralf Trønnes wrote:
> >
> > Den 27.01.2017 08.49, skrev Daniel Vetter:
> > > On Thu, Jan 26, 2017 at 11:56:02PM +0100, Noralf Trønnes wrote:
> > > > This patchset removes the need for drive
On Mon, Feb 20, 2017 at 04:25:45PM +0100, Tomeu Vizoso wrote:
> Rotel RSX-1058 is a receiver with 4 HDMI inputs and a HDMI output, all
> 1.1.
>
> When a sink that supports deep color is connected to the output, the
> receiver will send EDIDs that advertise this capability, even if it
> isn't possi
Just use kmem_cache instead of rolling
our own, limited implementation.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 4 +--
drivers/gpu/drm/virtio/virtgpu_vq.c | 57 +++-
2 files changed, 11 insertions(+), 50 deletions(-)
diff --git a
On Wed, Mar 01, 2017 at 01:31:01PM +0100, Boris Brezillon wrote:
> The current suspend resume implementation is assuming register values are
> kept when entering suspend, which is no longer the case with the
> suspend-to-RAM on the sama5d2.
>
> While at it, switch to the generic infrastructure to
On Tue, Feb 28, 2017 at 08:36:57PM +0100, Daniel Vetter wrote:
> It's still just an experiment, but one lesson learned from drm-misc is
> that not updating MAINTAINERS just leads to confusion. And this is
> easy to revert.
...
> Cc: Shawn Guo
> Signed-off-by: Daniel Vetter
...
> @@ -4476,6 +4479,
https://bugs.freedesktop.org/show_bug.cgi?id=99784
--- Comment #6 from lazane...@gmail.com ---
Problem persists with DRM 2.49.0 / 4.10.1-041001-lowlatency, LLVM 3.9.1
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-deve
The current suspend resume implementation is assuming register values are
kept when entering suspend, which is no longer the case with the
suspend-to-RAM on the sama5d2.
While at it, switch to the generic infrastructure to enter suspend mode
(drm_atomic_helper_suspend/resume()).
Signed-off-by: Bo
https://bugs.freedesktop.org/show_bug.cgi?id=99450
Hugo Posnic changed:
What|Removed |Added
Resolution|--- |FIXED
Status|REOPENED
Hi Jose,
On Thursday 05 Jan 2017 15:06:49 Jose Abreu wrote:
> On 05-01-2017 12:29, Laurent Pinchart wrote:
> > On Tuesday 20 Dec 2016 12:17:23 Jose Abreu wrote:
> >> On 20-12-2016 11:45, Russell King - ARM Linux wrote:
> >>> On Tue, Dec 20, 2016 at 03:33:48AM +0200, Laurent Pinchart wrote:
>
On Tue, Feb 28, 2017 at 03:20:38PM -0800, Ben Widawsky wrote:
> On 17-02-28 12:18:39, Jason Ekstrand wrote:
> >I've said it before but reading through Ben's patches again make me want to
> >be peskier about it. I would really like the UABI to treat the CCS as if
> >it's Y-tiled with a tile size o
Hi all,
topic/designware-baytrail-2017-03-01:
Baytrail PMIC vs. PMU race fixes from Hans de Goede
I opted to put all the patches for all subsystems into the topic branches,
so that if needed, each subsystem can apply refactorings to the entire
thing. Which might be needed since we're very early i
On Thu, Feb 02, 2017 at 02:26:40PM -0200, Gabriel Krisman Bertazi wrote:
> Instead of receiving the num_crts as a parameter, we can read it
> directly from the mode_config structure. I audited the drivers that
> invoke this helper and I believe all of them initialize the mode_config
> struct accor
On Fri, Dec 16, 2016 at 12:29:06PM +0200, Jani Nikula wrote:
> /**
> + * enum drm_link_status - connector's link_status property value
> + *
> + * This enum is used as the connector's link status property value.
> + * It is set to the values defined in uapi.
> + */
> +enum drm_link_status {
> +
All Exynos CRTCs are fully configured by .enable callback. The only users
of mode_set_nofb actually did nothing in their callbacks - they immediately
returned because devices were in suspend state - mode_set_nofb is always
called on disabled device.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/d
When reading the monitor config fails, don't retry forever. If it fails
ten times in a row just give up to avoid the driver hangs. Also add a
small delay after each attempt, so the host has a chance to complete a
partial update.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/qxl/qxl_display.
Try to read the client monitors config at driver load time, even without
explicit notification. So in case that info was filled before the driver
loaded and we've missed the notifications because of that the settings
will still be used.
With that place we now have to take care to properly handle
Call qxl_add_monitors_config_modes() unconditionally. Do all sanity
checks in that function.
Fix sanity checks. monitors_config is the current monitor
configuration, whereas client_monitors_config is the configuration
requested by the spice client. So when filling the mode list, based on
the sp
Hi,
This little series has some fixes and cleanups for the qxl driver.
Based on drm-misc-next branch.
cheers,
Gerd
Gerd Hoffmann (4):
qxl: drop mode_info.modes & related code.
qxl: limit monitor config read retries
qxl: read monitors config at boot
qxl: fix qxl_conn_get_modes
drive
very old qxl hardware revisions (predating qxl ksm support by a few
years) supported a fixed list of video modes only. The list is still
provided by the virtual hardware, for backward compatibility reasons.
The qxl kms driver never ever looks at it, except for dumping it to
the kernel log at load
Hi Maarten,
Thank you for the resend.
For the whole series,
Tested-by: Laurent Pinchart
On Wednesday 01 Mar 2017 10:21:26 Maarten Lankhorst wrote:
> There are new iterator macros that annotate whether the new or old
> state should be used. This is better than using a state that depends on
> wh
On Tue, Feb 28, 2017 at 03:48:47PM -0800, Eric Anholt wrote:
> Daniel Vetter writes:
>
> > I want to split up a few more things and document some details better
> > (like how exactly to subclass drm_atomic_state). And maybe also split
> > up the helpers a bit per-topic, but this should be a ok-is
https://bugzilla.kernel.org/show_bug.cgi?id=193341
stefan.ko...@um.si changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
On Wed, 01 Mar 2017, Daniel Vetter wrote:
> On Tue, Feb 28, 2017 at 06:59:52PM +, Joan Jani wrote:
>> Fixed the following style issues
>>
>> drivers/gpu/vga/vga_switcheroo.c:98: WARNING: please, no space before tabs
>> drivers/gpu/vga/vga_switcheroo.c:99: WARNING: please, no space before tabs
This is a straightforward conversion that converts all the users of
get_existing_state in atomic core to use get_old_state or get_new_state
Changes since v1:
- Fix using the wrong state in drm_atomic_helper_update_legacy_modeset_state.
Changes since v2:
- Use the correct state in disable_outputs()
There are new iterator macros that annotate whether the new or old
state should be used. This is better than using a state that depends on
whether it's called before or after swap. For clarity, also rename the
variables from $obj_state to (old,new)_$obj_state as well.
Changes since v1:
- Use old/n
1 - 100 of 112 matches
Mail list logo
