As we are not using the sysfs infrastructure anymore, link to it is
removed. And global srm data and mutex to protect it are removed,
with required handling at revocation check function.
v2:
srm_data is dropped and few more comments are addressed.
v3:
ptr passing around is fixed with
Hi Ramalingam,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on drm-tip/drm-tip drm-exynos/exynos-drm-next
tegra-drm/drm/tegra/for-next linus/master v5.5 next-20200207]
[cannot apply to drm/drm-next
On Thu, Feb 6, 2020 at 11:46 PM Gerd Hoffmann wrote:
>
> Introduce new virtio_gpu_object_shmem_init() helper function which will
> create the virtio_gpu_mem_entry array, containing the backing storage
> information for the host. For the most path this just moves code from
>
The global disable_notify state does not scale well when we start
using it in more places and when there are multiple threads. Allow
individual commands to be added to the virtqueue but not committed.
The naming conventions are
virtio_gpu_cmd_foo -> add foo and commit
virtio_gpu_add_bar ->
Hi,
This series replaces the global disable_notify state by command-level bools to
control vq kicks. When command batching is applied to more places, this
prevents one process from affecting another process.
v2: update to this convention
virtio_gpu_cmd_foo: add foo and commit
Call virtqueue_kick_prepare once in virtio_gpu_enable_notify, not
whenever a command is added. This should be more efficient since
the intention is to batch commands.
Signed-off-by: Chia-I Wu
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 1 -
drivers/gpu/drm/virtio/virtgpu_vq.c | 34
virtio_gpu_queue_ctrl_sgs queues only. virtio_gpu_commit_ctrl must
be explicitly called. This however means that we need to grab the
spinlock twice.
Signed-off-by: Chia-I Wu
---
drivers/gpu/drm/virtio/virtgpu_vq.c | 29 ++---
1 file changed, 22 insertions(+), 7
The pull request you sent on Fri, 7 Feb 2020 13:29:48 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-next-2020-02-07
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/c16b99d6c5a3f103ae45e33084055a2440d70544
Thank you!
--
Deet-doot-dot, I am a bot.
Split into init and register functions to avoid a segfault
in some configs when the load/unload callbacks are removed.
v2:
- add back accidently dropped has_aux setting
- set dev in late_register
v3:
- fix dp cec ordering
Signed-off-by: Alex Deucher
---
I've sent out a v4 version of the format modifier patches which avoid
caching values in the nouveau_framebuffer struct. It will have a few
trivial conflicts with your series, but should make them structurally
compatible.
I'm fine with either v3 or v4 of my series personally, but if these
Make sure framebuffer dimensions and tiling
parameters will not result in accesses beyond the
end of the GEM buffer they are bound to.
v3: Return EINVAL when creating FB against BO with
unsupported tiling
Signed-off-by: James Jones
---
drivers/gpu/drm/nouveau/nouveau_display.c | 97
Advertise support for the full list of format
modifiers supported by each class of NVIDIA
desktop GPU display hardware. Stash the array
of modifiers in the nouveau_display struct for
use when validating userspace framebuffer
creation requests, which will be supportd in
a subsequent change.
This series modifies the NV5x+ nouveau display backends to advertise
appropriate format modifiers on their display planes in atomic mode
setting blobs.
Corresponding modifications to Mesa/userspace are available on the
Mesa-dev gitlab merge request 3724:
Allow setting the block layout of a nouveau FB
object using DRM format modifiers. When
specified, the format modifier block layout and
kind overrides the GEM buffer's implicit layout
and kind. The specified format modifier is
validated against the list of modifiers supported
by the target
On 02/05, Jerry (Fangzhi) Zuo wrote:
> Unlike DP 1.2 edid corruption test, DP 1.4 requires to calculate
> real CRC value of the last edid data block, and write it back.
> Current edid CRC calculates routine adds the last CRC byte,
> and check if non-zero.
>
> This behavior is not accurate;
We've moved the debugfs handling into a centralized place
so we can remove the legacy load an unload callbacks.
Acked-by: Christian König
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 5 -
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c| 13 +++--
2
Into the function that creates the debugfs files rather
than setting them explicitly in the callers.
Reviewed-by: Harry Wentland
Acked-by: Christian König
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 --
Split into init and register functions to avoid a segfault
in some configs when the load/unload callbacks are removed.
v2:
- add back accidently dropped has_aux setting
- set dev in late_register
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c | 16
In order to remove the load and unload drm callbacks,
we need to reorder the init sequence to move all the drm
debugfs file handling. Do this for pm.
Acked-by: Christian König
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 7 +++
In order to remove the load and unload drm callbacks,
we need to reorder the init sequence to move all the drm
debugfs file handling. Do this for ttm.
Acked-by: Christian König
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 10 ++
In order to remove the load and unload drm callbacks,
we need to reorder the init sequence to move all the drm
debugfs file handling. Do this for SA (sub allocator).
Acked-by: Christian König
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 4
In order to remove the load and unload drm callbacks,
we need to reorder the init sequence to move all the drm
debugfs file handling. Do this for gem.
Acked-by: Christian König
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 4
In order to remove the load and unload drm callbacks,
we need to reorder the init sequence to move all the drm
debugfs file handling. Do this for display.
v2: add config guard for DC
Reviewed-by: Harry Wentland (v1)
Acked-by: Christian König (v1)
Signed-off-by: Alex Deucher
---
These are deprecated and the drm will soon start warning when drivers still
use them. It was a long and twisty road, but seems to work.
v2: Add additional patch (13/15) which should fix the crash reported by
Thomas Zimmermann.
v3: Fix dp aux registration harder, add missing kconfig guard
Alex
In order to remove the load and unload drm callbacks,
we need to reorder the init sequence to move all the drm
debugfs file handling. Do this for firmware.
Acked-by: Christian König
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 4
In order to remove the load and unload drm callbacks,
we need to reorder the init sequence to move all the drm
debugfs file handling. Do this for rings.
Acked-by: Christian König
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 23 -
The core does this for us now.
Acked-by: Christian König
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c| 1 -
drivers/gpu/drm/amd/amdgpu/dce_virtual.c | 1 -
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 1 -
3 files changed, 3 deletions(-)
In order to remove the load and unload drm callbacks,
we need to reorder the init sequence to move all the drm
debugfs file handling. Do this for fence handling.
Acked-by: Christian König
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 3 +++
To handle debugfs setup on non DP MST connectors.
Reviewed-by: Harry Wentland
Acked-by: Christian König
Signed-off-by: Alex Deucher
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 18 ++
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git
to amdgpu_debugfs_fini. It will be used for other things in
the future.
Acked-by: Christian König
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 4 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.h | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 +-
3
In order to remove the load and unload drm callbacks,
we need to reorder the init sequence to move all the drm
debugfs file handling. Do this for register access files.
Acked-by: Christian König
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 4
On Fri, Feb 07, 2020 at 08:26:17PM +0200, Jyri Sarha wrote:
> On 07/02/2020 20:18, Jyri Sarha wrote:
> > The old implementation of placing planes on the CRTC while configuring
> > the planes was naive and relied on the order in which the planes were
> > configured, enabled, and disabled. The
On 07/02/2020 20:18, Jyri Sarha wrote:
> The old implementation of placing planes on the CRTC while configuring
> the planes was naive and relied on the order in which the planes were
> configured, enabled, and disabled. The situation where a plane's zpos
> was changed on the fly was completely
The old implementation of placing planes on the CRTC while configuring
the planes was naive and relied on the order in which the planes were
configured, enabled, and disabled. The situation where a plane's zpos
was changed on the fly was completely broken. The usual symptoms of
this problem was
On 06/02/20 15:13, Boris Brezillon wrote:
We need to use the AS attached to the opened FD when dumping counters.
Reported-by: Antonio Caggiano
Fixes: 7282f7645d06 ("drm/panfrost: Implement per FD address spaces")
Cc:
Signed-off-by: Boris Brezillon
It works fine on RK3399.
Tested-by:
On Thu, Feb 06, 2020 at 05:43:52PM +0100, Bas Nieuwenhuizen wrote:
> Hi,
>
> I'd appreciate if you could take a look at this patch. I believe I
> have accommodated the earlier review comments.
Sorry, it was sitting on my todo list. Looks good.
> Thank you,
> Bas
>
> On Fri, Jan 24, 2020 at
On Fri, Jan 24, 2020 at 12:57:10AM +0100, Bas Nieuwenhuizen wrote:
> This
>
> 1) Enables core DRM syncobj support.
> 2) Adds options to the submission ioctl to wait/signal syncobjs.
>
> Just like the wait fence fd, this does inline waits. Using the
> scheduler would be nice but I believe it is
On Thu, Feb 6, 2020 at 11:24 PM Evan Benn wrote:
>
> The cursor and primary planes were hard coded.
> Now search for them for passing to drm_crtc_init_with_planes
>
> Signed-off-by: Evan Benn
I like it!
Reviewed-by: Sean Paul
> ---
>
> drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 18
On Fri, Feb 07, 2020 at 12:44:28PM +0100, Andrzej Pietrasiewicz wrote:
> Hi All again,
Hi Andrzej,
>
> @malidp and komeda folks: I kindly ask you to have your say. If there is
> no interest from you (which is ok with me) I will resend the series
> dropping the komeda and malidp part.
I *am*
From: Lukasz Luba
Add support of other devices into the Energy Model framework not only the
CPUs. Change the interface to be more unified which can handle other
devices as well.
Signed-off-by: Lukasz Luba
---
Documentation/power/energy-model.rst | 129 +
drivers/cpufreq/scmi-cpufreq.c
Save pll state before dsi host is powered off. Without this change
some register values gets resetted.
Signed-off-by: Harigovindan P
---
Changes in v1:
- Saving pll state before dsi host is powered off.
- Removed calling of save state in post_disable since everything
From: Lukasz Luba
The overhauled Energy Model (EM) framework support also devfreq devices.
The unified API interface of the EM can be used in the thermal subsystem to
not duplicate code. The power table now is taken from EM structure and
there is no need to maintain calculation for it locally.
Convert orisetech,otm8009a to json-schema.
Signed-off-by: Benjamin Gaignard
---
.../bindings/display/panel/orisetech,otm8009a.txt | 23 --
.../bindings/display/panel/orisetech,otm8009a.yaml | 53 ++
2 files changed, 53 insertions(+), 23 deletions(-)
delete mode
From: Lukasz Luba
Add device to the Energy Model framework. It will create a dedicated
and unified data structures used i.e. in the thermal framework.
The power model used in dev_pm_opp subsystem is simplified and created
based on DT 'dynamic-power-coefficient', volatage and frequency. It is
On Fri, 7 Feb 2020, Philippe Mathieu-Daudé wrote:
> On Wed, Feb 5, 2020 at 11:18 PM Finn Thain
> wrote:
> > On Wed, 5 Feb 2020, Philippe Mathieu-Daudé wrote:
> > > On Sun, Feb 2, 2020 at 3:41 AM Finn Thain
> > > wrote:
> > > >
> > > > This patch resolves these compiler errors and warnings
On Thu, Feb 6, 2020 at 1:52 AM Harigovindan P wrote:
>
> Save pll state before dsi host is powered off. Without this change
> some register values gets resetted.
The phy driver already does this. Why is the current implementation
insufficient?
>
> Signed-off-by: Harigovindan P
> ---
>
>
Zephyr secondary cache is 256KB, 128B lines. 32B sectors. A secondary cache
line can contain two instruction cache lines (64B), or four data cache
lines (32B). Hardware prefetch Cache detects stream access, and prefetches
ahead of processor access. Add support to inavalidate BMIPS5000 cpu zephyr
From: Sam Ravnborg
To complement panel-simple.yaml, create panel-simple-dsi.yaml.
panel-simple-dsi-yaml are for all simple DSP panels with a single
power-supply and optional backlight / enable GPIO.
Migrate panasonic,vvx10f034n00 over to the new file.
The objectives with one file for all the
This file doesn't need everything provided by .
All it needs are some types, which are provided by .
Drop unneeded completely.
Signed-off-by: Andy Shevchenko
---
v3: Drop header completely (Laurent)
include/linux/platform_data/shmob_drm.h | 2 --
1 file changed, 2 deletions(-)
diff --git
The cursor and primary planes were hard coded.
Now search for them for passing to drm_crtc_init_with_planes
Signed-off-by: Evan Benn
---
drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git
Hi,
We are developing a custom board based on the rk3399 soc. We need two
displays, and would like to use the two mipi DSI interfaces
ff96.mipi and ff968000.mipi,
simultaneously, independently, both with an own touch controller, 4
lanes per display.
Question, is this a possible scenario,
Save pll state before dsi host is powered off. Without this change
some register values gets resetted.
Signed-off-by: Harigovindan P
---
Changes in v1:
- Saving pll state before dsi host is powered off.
- Removed calling of save state in msm_dsi_phy_disable since everything
This patch resolves these compiler errors and warnings --
CC drivers/video/fbdev/g364fb.o
drivers/video/fbdev/g364fb.c: In function 'g364fb_cursor':
drivers/video/fbdev/g364fb.c:137:9: error: 'x' undeclared (first use in this
function)
drivers/video/fbdev/g364fb.c:137:9: note: each
Convert raydium,rm68200 to json-schema.
Signed-off-by: Benjamin Gaignard
---
.../bindings/display/panel/raydium,rm68200.txt | 25 --
.../bindings/display/panel/raydium,rm68200.yaml| 56 ++
2 files changed, 56 insertions(+), 25 deletions(-)
delete mode 100644
On Wed, Feb 05, 2020 at 07:33:22PM +0200, Laurent Pinchart wrote:
> Hi Andy,
>
> Thank you for the patch.
>
> On Wed, Feb 05, 2020 at 11:32:26AM +0200, Andy Shevchenko wrote:
> > This file doesn't need everything provided by .
> > All it needs are some types, which are provided by .
> >
> >
From: Lukasz Luba
Drop the CPU specific interface with cpumask and switch to struct device.
The Energy Model framework supports both: CPUs and devfreq devices. The new
interface provides easy way to create a Energy Model (EM), which then might
be used in i.e. thermal subsystem.
Signed-off-by:
On Thu, Feb 6, 2020 at 2:13 AM Harigovindan P wrote:
>
> For a given byte clock, if VCO recalc value is exactly same as
> vco set rate value, vco_set_rate does not get called assuming
> VCO is already set to required value. But Due to GDSC toggle,
> VCO values are erased in the HW. To make sure
For a given byte clock, if VCO recalc value is exactly same as
vco set rate value, vco_set_rate does not get called assuming
VCO is already set to required value. But Due to GDSC toggle,
VCO values are erased in the HW. To make sure VCO is programmed
correctly, we forcefully call set_rate from
A few minor patches are needed to more easily boot a MIPS Magnum build
under QEMU. This series fixes a build failure in the g364fb driver and
modifies jazz_defconfig for use with 'qemu-system-mips64el -M magnum'.
Note that QEMU's dp8393x implementation has bugs, one of which prevents
the Linux
On 2/6/2020 11:30 AM, Kamal Dasu wrote:
> Zephyr secondary cache is 256KB, 128B lines. 32B sectors. A secondary cache
> line can contain two instruction cache lines (64B), or four data cache
> lines (32B). Hardware prefetch Cache detects stream access, and prefetches
> ahead of processor
Apologies for the confusing thread. Please apply the above patch:
'drm/mediatek: Find the cursor plane instead of hard coding it'
before Sean Paul's original patch:
'drm/mediatek: Ensure the cursor plane is on top of other overlays'
This way authorship is correctly preserved, but we do not
On Wed, Feb 5, 2020 at 11:18 PM Finn Thain wrote:
> On Wed, 5 Feb 2020, Philippe Mathieu-Daudé wrote:
> > On Sun, Feb 2, 2020 at 3:41 AM Finn Thain
> > wrote:
> > >
> > > This patch resolves these compiler errors and warnings --
> > >
> > > CC drivers/video/fbdev/g364fb.o
> > >
On 2/5/20 8:09 PM, Stephen Rothwell wrote:
> Hi all,
>
> Please do not add any v5.7 material to your linux-next included
> branches until after v5.6-rc1 has been released.
>
> Changes since 20200205:
>
on i386:
ERROR: "dtn_debugfs_init" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
Full
To complement panel-simple.yaml, create panel-simple-dsi.yaml.
panel-simple-dsi-yaml are for all simple DSP panels with a single
power-supply and optional backlight / enable GPIO / reset GPIO.
Some DSI panels like orisetech,otm8009a or raydium,rm68200 are quite
similar to simple dsi panel but
From: Lukasz Luba
Hi all,
This patch set introduces support for devices in the Energy Model (EM)
framework. It will unify the power model for thermal subsystem and make it
simpler. The 1st patch refactors EM framework and adds support for devices.
The 2nd patch changes
On Fri, Feb 07, 2020 at 05:39:26PM +0100, Daniel Vetter wrote:
> On Fri, Feb 07, 2020 at 03:59:50PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > WARN if the encoder possible_crtcs is effectively empty or contains
> > bits for non-existing crtcs.
> >
> > TODO: Or should we
On Fri, Feb 07, 2020 at 03:16:02PM +0100, Thomas Zimmermann wrote:
> Atomic modesetting doesn't use struct drm_connector_funcs.dpms and
> the set function, drm_helper_connector_dpms(), wouldn't support it
> anyway. So keep the pointer to NULL.
>
> Signed-off-by: Thomas Zimmermann
On both
On Fri, Feb 07, 2020 at 06:34:47PM +0200, Ville Syrjälä wrote:
> On Fri, Feb 07, 2020 at 05:27:51PM +0100, Daniel Vetter wrote:
> > On Fri, Feb 07, 2020 at 04:50:01PM +0200, Ville Syrjälä wrote:
> > > On Fri, Feb 07, 2020 at 03:28:35PM +0100, Thomas Zimmermann wrote:
> > > > Hi
> > > >
> > > > Am
On Fri, Feb 07, 2020 at 03:59:50PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> WARN if the encoder possible_crtcs is effectively empty or contains
> bits for non-existing crtcs.
>
> TODO: Or should we perhapst just filter out any bit for a
> non-exisiting crtc?
>
> Cc: Thomas
On Fri, Feb 07, 2020 at 03:59:45PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> The docs say possible_clones should always include the encoder itself.
> Since most drivers don't want to deal with the complexities of cloning
> let's allow them to set possible_clones=0 and instead we'll
On Fri, Feb 07, 2020 at 05:27:51PM +0100, Daniel Vetter wrote:
> On Fri, Feb 07, 2020 at 04:50:01PM +0200, Ville Syrjälä wrote:
> > On Fri, Feb 07, 2020 at 03:28:35PM +0100, Thomas Zimmermann wrote:
> > > Hi
> > >
> > > Am 07.02.20 um 14:59 schrieb Ville Syrjala:
> > > > From: Ville Syrjälä
> >
On Fri, Feb 07, 2020 at 03:20:44PM +0100, Thomas Zimmermann wrote:
> Hi
>
> Am 07.02.20 um 14:59 schrieb Ville Syrjala:
> > From: Ville Syrjälä
> >
> > It's not at all clear what cloning options this driver supports.
> > So let's just clear possible_clones instead of setting it to some
> >
On Fri, Feb 07, 2020 at 03:59:46PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> I doubt the DP+DP and SDVO+SDVO cloning works for this driver.
> i915 at least doesn't do those. Truthfully there could be some very
> specific circumstances where some of them would do doable, but
>
On Fri, Feb 07, 2020 at 04:50:01PM +0200, Ville Syrjälä wrote:
> On Fri, Feb 07, 2020 at 03:28:35PM +0100, Thomas Zimmermann wrote:
> > Hi
> >
> > Am 07.02.20 um 14:59 schrieb Ville Syrjala:
> > > From: Ville Syrjälä
> > >
> > > The docs say possible_clones should always include the encoder
On Fri, Feb 07, 2020 at 03:02:00PM +0100, Thomas Zimmermann wrote:
> Hi
>
> Am 07.02.20 um 14:37 schrieb Daniel Vetter:
> > On Fri, Feb 07, 2020 at 09:41:31AM +0100, Thomas Zimmermann wrote:
> >> The simple-encoder helpers initialize an encoder with an empty
> >> implementation. This covers the
On Fri, Feb 07, 2020 at 03:36:49PM +0100, Noralf Trønnes wrote:
>
>
> Den 07.02.2020 09.41, skrev Thomas Zimmermann:
> > The simple-encoder helpers initialize an encoder with an empty
> > implementation. This covers the requirements of most of the existing
> > DRM drivers. A call to
On 07/02/2020 15:57, Boris Brezillon wrote:
> On Thu, 6 Feb 2020 20:18:30 +0100
> Neil Armstrong wrote:
>
>> Switch the dw-hdmi driver to drm_bridge_funcs by implementing a new local
>> bridge, connecting it to the dw-hdmi bridge, then implement the
>>
On Thu, Feb 6, 2020 at 3:51 PM Christian König wrote:
>
> Am 06.02.20 um 15:49 schrieb Alex Deucher:
> > On Thu, Feb 6, 2020 at 6:50 AM Christian König
> > wrote:
> >> Am 06.02.20 um 12:10 schrieb Lucas Stach:
> >>> Hi all,
> >>>
> >>> On Mi, 2020-02-05 at 19:24 +0100, Lucas Stach wrote:
>
We try hard to select a suitable hole in the drm_mm first time. But if
that is unsuccessful, we then have to look at neighbouring nodes, and
this requires traversing the rbtree. Walking the rbtree can be slow
(much slower than a linear list for deep trees), and if the drm_mm has
been purposefully
On Thu, 6 Feb 2020 20:18:30 +0100
Neil Armstrong wrote:
> Switch the dw-hdmi driver to drm_bridge_funcs by implementing a new local
> bridge, connecting it to the dw-hdmi bridge, then implement the
> atomic_get_input_bus_fmts/atomic_get_output_bus_fmts.
>
> Signed-off-by: Neil Armstrong
> ---
On Fri, Feb 07, 2020 at 03:28:35PM +0100, Thomas Zimmermann wrote:
> Hi
>
> Am 07.02.20 um 14:59 schrieb Ville Syrjala:
> > From: Ville Syrjälä
> >
> > The docs say possible_clones should always include the encoder itself.
> > Since most drivers don't want to deal with the complexities of
On 2/7/20 12:01 AM, Finn Thain wrote:
> This patch resolves these compiler errors and warnings --
>
> CC drivers/video/fbdev/g364fb.o
> drivers/video/fbdev/g364fb.c: In function 'g364fb_cursor':
> drivers/video/fbdev/g364fb.c:137:9: error: 'x' undeclared (first use in this
> function)
>
Den 07.02.2020 09.41, skrev Thomas Zimmermann:
> The simple-encoder helpers initialize an encoder with an empty
> implementation. This covers the requirements of most of the existing
> DRM drivers. A call to drm_simple_encoder_create() allocates and
> initializes an encoder instance, a call to
Hi
Am 07.02.20 um 14:59 schrieb Ville Syrjala:
> From: Ville Syrjälä
>
> The docs say possible_clones should always include the encoder itself.
> Since most drivers don't want to deal with the complexities of cloning
> let's allow them to set possible_clones=0 and instead we'll fix that
> up in
Am 07.02.20 um 14:59 schrieb Ville Syrjala:
> From: Ville Syrjälä
>
> Many drivers are populating encoder->possible_clones wrong. Let's
> persuade them to get it right by adding some loud WARNs.
>
> We'll cross check the bits between any two encoders. So either
> both encoders can clone with
Hi
Am 07.02.20 um 14:59 schrieb Ville Syrjala:
> From: Ville Syrjälä
>
> It's not at all clear what cloning options this driver supports.
> So let's just clear possible_clones instead of setting it to some
> bogus value.
>
> Cc: Philipp Zabel
> Signed-off-by: Ville Syrjälä
> ---
>
Am 07.02.20 um 14:59 schrieb Ville Syrjala:
> From: Ville Syrjälä
>
> Replace the hand rolled encoder bitmask thing with drm_encoder_mask()
>
> Cc: Inki Dae
> Cc: Joonyoung Shim
> Cc: Seung-Woo Kim
> Cc: Kyungmin Park
> Signed-off-by: Ville Syrjälä
Acked-by: Thomas Zimmermann
> ---
>
Atomic modesetting doesn't use struct drm_connector_funcs.dpms and
the set function, drm_helper_connector_dpms(), wouldn't support it
anyway. So keep the pointer to NULL.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/bochs/bochs_kms.c | 1 -
1 file changed, 1 deletion(-)
diff --git
Atomic modesetting doesn't use struct drm_connector_funcs.dpms and
the set function, drm_helper_connector_dpms(), wouldn't support it
anyway. So keep the pointer to NULL.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/udl/udl_connector.c | 1 -
1 file changed, 1 deletion(-)
diff --git
Hi
Am 07.02.20 um 14:37 schrieb Daniel Vetter:
> On Fri, Feb 07, 2020 at 09:41:31AM +0100, Thomas Zimmermann wrote:
>> The simple-encoder helpers initialize an encoder with an empty
>> implementation. This covers the requirements of most of the existing
>> DRM drivers. A call to
On Fri, Feb 07, 2020 at 02:37:20PM +0100, Daniel Vetter wrote:
> On Fri, Feb 07, 2020 at 09:41:31AM +0100, Thomas Zimmermann wrote:
> > The simple-encoder helpers initialize an encoder with an empty
> > implementation. This covers the requirements of most of the existing
> > DRM drivers. A call to
From: Ville Syrjälä
The docs say possible_clones should always include the encoder itself.
Since most drivers don't want to deal with the complexities of cloning
let's allow them to set possible_clones=0 and instead we'll fix that
up in the core.
We can't put this special case into
From: Ville Syrjälä
Many drivers are populating encoder->possible_clones wrong. Let's
persuade them to get it right by adding some loud WARNs.
We'll cross check the bits between any two encoders. So either
both encoders can clone with the other, or neither can.
We'll also complain about
From: Ville Syrjälä
Remainder of my possible_clones/crtcs cleanup. All the i915 bits and a
few other driver bits got merged already.
Ville Syrjälä (6):
drm: Include the encoder itself in possible_clones
drm/gma500: Sanitize possible_clones
drm/exynos: Use drm_encoder_mask()
drm/imx:
From: Ville Syrjälä
I doubt the DP+DP and SDVO+SDVO cloning works for this driver.
i915 at least doesn't do those. Truthfully there could be some very
specific circumstances where some of them would do doable, but
genereally it's too much pain to deal with so we've chose not to
bother. Let's use
From: Ville Syrjälä
WARN if the encoder possible_crtcs is effectively empty or contains
bits for non-existing crtcs.
TODO: Or should we perhapst just filter out any bit for a
non-exisiting crtc?
Cc: Thomas Zimmermann
Cc: Daniel Vetter
Signed-off-by: Ville Syrjälä
---
From: Ville Syrjälä
It's not at all clear what cloning options this driver supports.
So let's just clear possible_clones instead of setting it to some
bogus value.
Cc: Philipp Zabel
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/imx/imx-drm-core.c | 2 +-
1 file changed, 1 insertion(+), 1
From: Ville Syrjälä
Replace the hand rolled encoder bitmask thing with drm_encoder_mask()
Cc: Inki Dae
Cc: Joonyoung Shim
Cc: Seung-Woo Kim
Cc: Kyungmin Park
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/exynos/exynos_drm_drv.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
Hi
Am 07.02.20 um 13:14 schrieb Gerd Hoffmann:
> Move final cleanups to qxl_drm_release() callback.
> Add drm_atomic_helper_shutdown() call to qxl_pci_remove().
>
> Reorder calls in qxl_device_fini(). Cleaning up gem & ttm
> might trigger qxl commands, so we should do that before
> releaseing
On Fri, Feb 07, 2020 at 01:14:20PM +0100, Gerd Hoffmann wrote:
> Split virtio_gpu_deinit(), move the drm shutdown and release to
> virtio_gpu_release(). Also free vbufs in case we can't queue them.
>
> Signed-off-by: Gerd Hoffmann
> ---
> drivers/gpu/drm/virtio/virtgpu_drv.h | 1 +
>
1 - 100 of 142 matches
Mail list logo
