In some special cases we must not block, but there's not a
spinlock, preempt-off, irqs-off or similar critical section already
that arms the might_sleep() debug checks. Add a non_block_start/end()
pair to annotate these.
This will be used in the oom paths of mmu-notifiers, where blocking is
not
Hi all,
Here's v2 of my mmu notifier debug checks.
I think the last two patches could probably be extended to all callbacks,
but I'm not really clear on the exact rules. But happy to extend them if
there's interest.
This stuff helps us catch issues in the i915 mmu notifier implementation.
We need to make sure implementations don't cheat and don't have a
possible schedule/blocking point deeply burried where review can't
catch it.
I'm not sure whether this is the best way to make sure all the
might_sleep() callsites trigger, and it's a bit ugly in the code flow.
But it gets the job
tree: git://people.freedesktop.org/~agd5f/linux.git drm-next-4.21
head: 22666cc1481ae3814d9c7718418cc4a3aa7d90c3
commit: eb3dc8978596a045f469f13bb13271a707623ecb [64/142] drm/amd/display: Use
private obj helpers for dm_atomic_state
New smatch warnings:
lkml and Linus gained a CoC, and it's serious this time. Which means
my no 1 reason for declining to officially step up as drm maintainer
is gone, and I didn't find any new good excuse.
I chatted with a few people in private already, and the biggest
concern is that I mislay my community hat and
On Sat, Dec 08, 2018 at 08:36:25AM +, YueHaibing wrote:
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/gpu/drm/ast/ast_fb.c: In function 'astfb_create':
> drivers/gpu/drm/ast/ast_fb.c:194:17: warning:
> variable 'bo' set but not used [-Wunused-but-set-variable]
>
> It never
On Mon, Dec 10, 2018 at 11:11:33AM +0100, Daniel Vetter wrote:
> Having the probe helper stuff (which pretty much everyone needs) in
> the drm_crtc_helper.h file (which atomic drivers should never need) is
> confusing. Split them out.
>
> To make sure I actually achieved the goal here I went
On Mon, Dec 10, 2018 at 11:18:32AM +0100, Daniel Vetter wrote:
> On Mon, Dec 10, 2018 at 11:06:34AM +0100, Greg Kroah-Hartman wrote:
> > On Mon, Dec 10, 2018 at 09:46:53AM +0100, Daniel Vetter wrote:
> > > Drivers might want to remove some sysfs files, which needs the same
> > > locks and ends up
On Sat, Dec 08, 2018 at 02:54:45PM +, Marcel Ziswiler wrote:
> Hi Thierry et al.
>
> I noticed that since commit 3dde5a2342cd ("ARM: tegra: Add VIC on
> Tegra124") graphics on Apalis TK1 is broken. During boot it fails
> loading the vic firmware:
>
> [1.595824] tegra-vic 5434.vic:
On Mon, Dec 10, 2018 at 11:06:34AM +0100, Greg Kroah-Hartman wrote:
> On Mon, Dec 10, 2018 at 09:46:53AM +0100, Daniel Vetter wrote:
> > Drivers might want to remove some sysfs files, which needs the same
> > locks and ends up angering lockdep. Relevant snippet of the stack
> > trace:
> >
> >
On 12/10/18 12:03 PM, Daniel Vetter wrote:
Doesn't do anything for atomic.
Signed-off-by: Daniel Vetter
Cc: Oleksandr Andrushchenko
Cc: xen-de...@lists.xen.org
---
drivers/gpu/drm/xen/xen_drm_front_conn.c | 1 -
1 file changed, 1 deletion(-)
diff --git
Having the probe helper stuff (which pretty much everyone needs) in
the drm_crtc_helper.h file (which atomic drivers should never need) is
confusing. Split them out.
To make sure I actually achieved the goal here I went through all
drivers. And indeed, all atomic drivers are now free of
Having the probe helper stuff (which pretty much everyone needs) in
the drm_crtc_helper.h file (which atomic drivers should never need) is
confusing. Split them out.
To make sure I actually achieved the goal here I went through all
drivers. And indeed, all atomic drivers are now free of
On Mon, Dec 10, 2018 at 09:46:53AM +0100, Daniel Vetter wrote:
> Drivers might want to remove some sysfs files, which needs the same
> locks and ends up angering lockdep. Relevant snippet of the stack
> trace:
>
> kernfs_remove_by_name_ns+0x3b/0x80
> bus_remove_driver+0x92/0xa0
>
Am Mittwoch, 5. Dezember 2018, 14:52:30 CET schrieb Randy Li:
> From: ayaka
>
> The Windows 2/3 or a RGB UI layer is a high performance flexibly
> plane. It is too waste to use it as a cursor plane.
>
> I have verified this patch with weston git version, I am not
> sure whether X would meet
Hi all,
Just a small cleanup motivated by the last patch. After this series atomic
drivers do no longer need the drm_crtc_helper.h header, and none of them
use it. Except for the 2 that support both atomic and legacy kms in the
same driver module (nouveau and amdgpu).
Last patch is a bit huge,
The correct way for legacy drivers to update properties that need to
do a full modeset, is to do a full modeset.
Note that we don't need to call the drm_mode_config_internal helper
because we're not changing any of the refcounted paramters.
Signed-off-by: Daniel Vetter
Cc: Daniel Vetter
Cc:
Doesn't do anything with atomic.
Signed-off-by: Daniel Vetter
Cc: Dave Airlie
Cc: Gerd Hoffmann
Cc: virtualizat...@lists.linux-foundation.org
Cc: spice-de...@lists.freedesktop.org
---
drivers/gpu/drm/qxl/qxl_display.c | 1 -
1 file changed, 1 deletion(-)
diff --git
Doesn't do anything for atomic.
Signed-off-by: Daniel Vetter
Cc: Oleksandr Andrushchenko
Cc: xen-de...@lists.xen.org
---
drivers/gpu/drm/xen/xen_drm_front_conn.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/xen/xen_drm_front_conn.c
It's not a core function, and the matching atomic functions are also
not in the core. Plus the suspend/resume helper is also already there.
Needs a tiny bit of open-coding, but less midlayer beats that I think.
Cc: Sam Bobroff
Signed-off-by: Daniel Vetter
Cc: Maarten Lankhorst
Cc: Maxime
The correct way for legacy drivers to update properties that need to
do a full modeset, is to do a full modeset.
Note that we don't need to call the drm_mode_config_internal helper
because we're not changing any of the refcounted paramters.
Signed-off-by: Daniel Vetter
Cc: Daniel Vetter
---
It's a legacy kms only thing, good to hide it better now that all
those old drivers use the legacy crtc helpers directly.
Signed-off-by: Daniel Vetter
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Sean Paul
Cc: David Airlie
---
drivers/gpu/drm/drm_crtc.c | 10 --
On Thu, Nov 29, 2018 at 01:30:59PM -0500, Lyude Paul wrote:
> Reviewed-by: Lyude Paul
Applied, thanks for your review.
-Daniel
>
> On Wed, 2018-11-28 at 23:12 +0100, Daniel Vetter wrote:
> > When everyone implements it exactly the same way, among all 4
> > implementations, there's not really a
On 08/12/2018 00:08, Lyude Paul wrote:
> uh
> didn't we fix this weeks ago? with "drm/nouveau: tegra: Call
> nouveau_drm_device_init()"
Yes here's the fix from Thierry:
https://patchwork.freedesktop.org/patch/263587/
and I can confirm that it does fix the Oops when applied on top
That's purely for the uapi layer to implement the ALLOW_MODESET flag.
Drivers should instead look at the state, e.g. through
drm_atomic_crtc_needs_modeset(), which vmwgfx already does. Also remove
the confusing comment, since checking allow_modeset is at best a micro
optimization.
v2: Rebase
Ooops, $SUBJECT should be:
"drm/selftest: fix spelling mistake "dimention" -> "dimension"
On 10/12/2018 09:26, Colin King wrote:
> From: Colin Ian King
>
> There is a spelling mistake in a pr_err message, fix this.
>
> Signed-off-by: Colin Ian King
> ---
>
On Sat, Dec 08, 2018 at 08:15:52PM +, Winkler, Tomas wrote:
>
> > On Fri, Dec 07, 2018 at 07:23:06PM +0530, C, Ramalingam wrote:
> > > Hi,
> > >
> > > In one of the offline discussion Tomas has shared his review comments on
> > > v8.
> >
> > Let's please have all review here on the mailing
On Sat, Dec 08, 2018 at 06:47:40PM +, Winkler, Tomas wrote:
>
>
> > -Original Message-
> > From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
> > Vetter
> > Sent: Friday, December 07, 2018 16:17
> > To: C, Ramalingam
> > Cc: Daniel Vetter ;
From: Colin Ian King
There is a spelling mistake in a pr_err message, fix this.
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/selftests/test-drm_damage_helper.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/selftests/test-drm_damage_helper.c
On Wed, Dec 05, 2018 at 07:59:17PM +0800, Brian Starkey wrote:
> Hi James,
>
> On Wed, Dec 05, 2018 at 10:20:13AM +, james qian wang (Arm Technology
> China) wrote:
> > Signed-off-by: James (Qian) Wang
> > ---
> > MAINTAINERS | 8
> > 1 file changed, 8 insertions(+)
> >
> > diff
Drivers might want to remove some sysfs files, which needs the same
locks and ends up angering lockdep. Relevant snippet of the stack
trace:
kernfs_remove_by_name_ns+0x3b/0x80
bus_remove_driver+0x92/0xa0
acpi_video_unregister+0x24/0x40
i915_driver_unload+0x42/0x130 [i915]
https://bugs.freedesktop.org/show_bug.cgi?id=108487
--- Comment #12 from Pekka Paalanen ---
(In reply to magiblot from comment #11)
> Is there any simple way (e.g. using a PKGBUILD file) to compile weston with
> undefined HAVE_GBM_MODIFIERS?
Not really, it needs to be patched out. There should
The encoder .atomic_check() and connector .mode_valid() operations both
walk through the dss devices in the pipeline to validate the mode.
Factor out the common code in a new omap_drm_connector_mode_fixup()
function.
Signed-off-by: Laurent Pinchart
Reviewed-by: Sebastian Reichel
---
Changes
Hi Sebastian,
On Monday, 10 December 2018 00:19:22 EET Sebastian Reichel wrote:
> Hi,
>
> On Wed, Dec 05, 2018 at 05:00:17PM +0200, Laurent Pinchart wrote:
> > The encoder .atomic_check() and connector .mode_valid() operations both
> > walk through the dss devices in the pipeline to validate the
Hi Thierry et al.
I noticed that since commit 3dde5a2342cd ("ARM: tegra: Add VIC on
Tegra124") graphics on Apalis TK1 is broken. During boot it fails
loading the vic firmware:
[1.595824] tegra-vic 5434.vic: Direct firmware load for
nvidia/tegra124/vic03_ucode.bin failed with error -2
[
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c: In function 'gfx_v8_0_pre_soft_reset':
drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c:4950:27: warning:
variable 'srbm_soft_reset' set but not used [-Wunused-but-set-variable]
drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c: In
Hi,
On Wed, Dec 05, 2018 at 05:00:01PM +0200, Laurent Pinchart wrote:
> The displays (connectors, panels and encoders) bail out from their
> .enable() and .disable() handlers if the dss device is already enabled
> or disabled. Those safety checks are not needed when the functions are
> called
Hi,
On Wed, Dec 05, 2018 at 05:00:12PM +0200, Laurent Pinchart wrote:
> The source pointer will be removed to the omap_dss_device structure.
> Store it internally in the DSI panel driver data.
>
> Signed-off-by: Laurent Pinchart
> ---
Reviewed-by: Sebastian Reichel
-- Sebastian
>
On Wed, Dec 05, 2018 at 05:00:07PM +0200, Laurent Pinchart wrote:
> Instead of manually iterating over the dss devices in the pipeline to
> find the first one that implements the .get_modes() operation, add a new
> operation flag for .get_modes() and use the omap_connector_find_device()
> helper
Add the Mali-450 GPU and it's OPP table for the Meson8 and Meson8m2 (the
latter inherits meson8.dtsi).
These SoCs have a Mali-450 GPU with six pixel processors. The OPP table
is taken from the 3.10 vendor kernel which uses the following table:
FCLK_DEV7 | 1, /* 182.1 Mhz */
FCLK_DEV4 | 1,
Hi,
On Wed, Dec 05, 2018 at 05:00:13PM +0200, Laurent Pinchart wrote:
> For HDMI pipelines, when the output gets disconnected the device
> handling CEC needs to be notified. Instead of guessing which device that
> would be (and sometimes getting it wrong), notify all devices in the
> pipeline.
>
Hi,
On Wed, Dec 05, 2018 at 05:00:06PM +0200, Laurent Pinchart wrote:
> Now that the .get_modes() operations takes a drm_connector and fills it
> with modes, it becomes easy to fill display information in the same
> operation without requiring a separate .get_size() opearation.
>
>
The Meson8 SoC is slightly different compared to Meson8b and Meson8m2
because it does not have the glitch-free Mali GPU clock mux. For Meson8b
and Meson8m2 there are currently no known differences.
Add a separate clk_hw_onecell_data table for Meson8 so these differences
can be implemented. For
On Sat, Dec 8, 2018 at 2:40 AM Robin Murphy wrote:
>
> On 2018-12-07 7:28 pm, Souptick Joarder wrote:
> > On Fri, Dec 7, 2018 at 10:41 PM Matthew Wilcox wrote:
> >>
> >> On Fri, Dec 07, 2018 at 03:34:56PM +, Robin Murphy wrote:
> +int vm_insert_range(struct vm_area_struct *vma, unsigned
Hi,
On Wed, Dec 05, 2018 at 05:00:10PM +0200, Laurent Pinchart wrote:
> The DT bindings for the OMAP DSS allow assigning numerical IDs to
> display outputs through display entries in the alias node. The driver
> uses this information to sort pipelines according to the order specified
> in DT,
On Thu, Dec 06, 2018 at 02:47:04PM +0100, Hans de Goede wrote:
> Implement the exec_mipi_pmic_seq_element callback for the CHT Whiskey Cove
> PMIC.
>
> On some CHT devices this fixes the LCD panel not lighting up when it was
> not initialized by the GOP, because an external monitor was plugged in
Hi,
On Wed, Dec 05, 2018 at 04:59:58PM +0200, Laurent Pinchart wrote:
> All .enable() and .disable() handlers for panels and connectors share
> common code that validates and updates the device's state. Move it to
> common locations in the omap_encoder_enable() and omap_encoder_disable()
>
Hi,
On Wed, Dec 05, 2018 at 05:00:22PM +0200, Laurent Pinchart wrote:
> The omapdrm driver initialization procedure starts by connecting all
> available pipelines, gathering related information (such as output and
> display DSS devices, and DT aliases), sorting them by alias, and finally
>
Hi,
On Wed, Dec 05, 2018 at 05:00:09PM +0200, Laurent Pinchart wrote:
> The display isn't used by the encoder implementation, don't pass it to
> the initialization function and store it internally needlessly.
>
> Signed-off-by: Laurent Pinchart
> ---
Reviewed-by: Sebastian Reichel
--
Hi,
On Wed, Dec 05, 2018 at 05:00:16PM +0200, Laurent Pinchart wrote:
> The mode setting handler of the VENC stores the video mode internally,
> to then convert it to a configuration when programming the hardware. The
> stored mode is otherwise unused. Cache the configuration directly
> instead.
Hi,
On Wed, Dec 05, 2018 at 05:00:15PM +0200, Laurent Pinchart wrote:
> The DISPC timings checks relate to the CRTC, but they're performed in
> the encoder and connector .atomic_check() and .mode_valid() operations.
> Move them to the CRTC .mode_valid() operation.
>
> Signed-off-by: Laurent
Hi,
On Wed, Dec 05, 2018 at 05:00:20PM +0200, Laurent Pinchart wrote:
> The DPI and SDI encoders store the full videomode upon mode set, to only
> use the value of the pixel clock when enabling the encoder. This wastes
> memory. Store the pixel clock value only.
>
> Signed-off-by: Laurent
Hi,
On Wed, Dec 05, 2018 at 05:00:08PM +0200, Laurent Pinchart wrote:
> The TV encoder supports both PAL and NTSC modes, but when queried for
> the list of modes it supports, only the currently selected mode is
> reported. Fix it and report the two modes unconditionally.
>
> Signed-off-by:
Hi,
On Wed, Dec 05, 2018 at 04:59:59PM +0200, Laurent Pinchart wrote:
> The internal encoders return an error from their .enable() handler when
> their are not connected to a dss manager. As the flag used is set and
> cleared in the connect and disconnect handlers, this effectively checks
>
Add a compatible string for the Mali-450 GPU on Amlogic Meson8 and
Meson8b SoCs. Meson8 uses an "MP6" variant with six pixel processors
while Meson8b (as cost-reduced SoC) uses an "MP2" variant with two pixel
processors. Both have a reset line to bring the GPU into a well-defined
state.
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/ast/ast_fb.c: In function 'astfb_create':
drivers/gpu/drm/ast/ast_fb.c:194:17: warning:
variable 'bo' set but not used [-Wunused-but-set-variable]
It never used since introduction in commit 312fec1405dd ("drm: Initial KMS
driver for
This series adds support for the Mali-450 GPU on Meson8 and Meson8b.
Meson6 uses a Mali-400 GPU but since we don't have a clock driver (and
I don't have a device for testing) Meson6 is left out in this series.
Meson8 uses a Mali-450 MP6 with six pixel processors. Meson8b (as
cost-reduced SoC)
Hi,
On Wed, Dec 05, 2018 at 05:00:18PM +0200, Laurent Pinchart wrote:
> The omap_dss_device .check_timings() and .set_timings() operations
> operate on struct videomode, while the DRM API operates on struct
> drm_display_mode. This forces conversion from to videomode in the
> callers. While
Add the GPU clock tree on Meson8, Meson8b and Meson8m2.
The GPU clock tree on Meson8b and Meson8m2 is almost identical to the
one one GXBB:
- there's a glitch-free mux at HHI_MALI_CLK_CNTL[31]
- there are two identical parents for this mux: mali_0 and mali_1, each
with a gate, divider and mux
-
On Fri, Dec 7, 2018 at 10:41 PM Matthew Wilcox wrote:
>
> On Fri, Dec 07, 2018 at 03:34:56PM +, Robin Murphy wrote:
> > > +int vm_insert_range(struct vm_area_struct *vma, unsigned long addr,
> > > + struct page **pages, unsigned long page_count)
> > > +{
> > > + unsigned
On Fri, Dec 7, 2018 at 8:20 PM Robin Murphy wrote:
>
> On 06/12/2018 18:42, Souptick Joarder wrote:
> > Convert to use vm_insert_range() to map range of kernel
> > memory to user vma.
> >
> > Signed-off-by: Souptick Joarder
> > Tested-by: Heiko Stuebner
> > Acked-by: Heiko Stuebner
> > ---
> >
On Thu, Dec 06, 2018 at 12:32:47PM +, Kieran Bingham wrote:
> Oh - although, yes - there are some good concepts there - but I'm a bit
> weary of how easy it would be to 'run' the said test against multiple
> kernel version libraries... there would be a lot of possible ABI
> conflicts perhaps.
This is a partial revert of commit 5c63e407aaab ("fbdev: Convert to
using %pOFn instead of device_node.name"). This is the minimal work to
get a Mac Mini G4 back to a bootable state. The function
offb_init_palette_hacks would need to handle the case where `name` has
been set to NULL.
Cc: Rob
On Fri, Dec 07, 2018 at 03:34:56PM +, Robin Murphy wrote:
> > +int vm_insert_range(struct vm_area_struct *vma, unsigned long addr,
> > + struct page **pages, unsigned long page_count)
> > +{
> > + unsigned long uaddr = addr;
> > + int ret = 0, i;
>
> Some of the sites
Hi,
On Wed, Dec 05, 2018 at 05:00:00PM +0200, Laurent Pinchart wrote:
> The displays (connectors, panels and encoders) return an error from
> their .enable() handler when the dss device is not connected. They also
> disconnect the dss device explicitly from their .remove() handler if it
> is
Hi,
On Wed, Dec 05, 2018 at 05:00:05PM +0200, Laurent Pinchart wrote:
> omap_dss_device operations expose fixed video timings through a
> .get_timings() operation that return a single timing for the device. To
> prepare for the move to drm_bridge, modify the API to instead add DRM
> modes
> Implement the exec_mipi_pmic_seq_element callback for the CHT Whiskey Cove
> PMIC.
> On some CHT devices this fixes the LCD panel not lighting up when it was
> not initialized by the GOP, because an external monitor was plugged in and
> the GOP initialized only the external monitor.
> + /*
Add the Mali-450 GPU and it's OPP table for Meson8. The GPU uses two
pixel processors in this configuration. The OPP table is taken from the
3.10 vendor kernel which uses the following table:
FCLK_DEV5 | 1, /* 255 Mhz */
FCLK_DEV7 | 0, /* 364 Mhz */
FCLK_DEV3 | 1, /* 425 Mhz */
Hi,
On Thu, Dec 06, 2018 at 06:23:46PM +0200, Laurent Pinchart wrote:
> Replace internal usage of struct videomode with struct drm_display_mode
> in order to avoid converting needlessly between the data structures.
>
> Signed-off-by: Laurent Pinchart
> ---
> Changes since v1:
>
> - Set
On Wed, Dec 05, 2018 at 04:59:56PM +0200, Laurent Pinchart wrote:
> The venc_device structure wss_data field is set to 0 and never otherwise
> modified, remove it.
>
> Signed-off-by: Laurent Pinchart
> ---
Reviewed-by: Sebastian Reichel
-- Sebastian
> drivers/gpu/drm/omapdrm/dss/venc.c | 11
Hi,
On Wed, Dec 05, 2018 at 04:59:57PM +0200, Laurent Pinchart wrote:
> Instead of rolling out custom suspend/resume implementations based on
> state information stored in the driver's data structures, use the atomic
> suspend/resume helpers that rely on a DRM atomic state object.
>
>
* Russell King [181207 21:24]:
> The binding document for this device says that all GPIOs are optional,
> but the driver fails to bind on OMAP3 LDP, reporting:
>
> panel-sharp-ls037v7dw01: probe of display failed with error -2
>
> Unfortunately, commit ca8c67dafdb7 ("fbdev: omap2: improve usage
Hi,
On Wed, Dec 05, 2018 at 05:00:17PM +0200, Laurent Pinchart wrote:
> The encoder .atomic_check() and connector .mode_valid() operations both
> walk through the dss devices in the pipeline to validate the mode.
> Factor out the common code in a new omap_drm_connector_mode_fixup()
> function.
>
Hi Guys,
I initially thought these patches were a joke. But I guess they are
not. I suppose 2018 is the year everything became offensive.
Could we avoid the s/fuck/hug/g though? I have nothing against
re-wording this stuff to remove the curse word, but it should at least
make sense.
What's
Hi,
On Wed, Dec 05, 2018 at 05:00:14PM +0200, Laurent Pinchart wrote:
> The field is only used to check whether the device is connected, and we
> can do so by checking the dss field instead. Remove the src field.
>
> Signed-off-by: Laurent Pinchart
> ---
Reviewed-by: Sebastian Reichel
--
Hi,
On Wed, Dec 05, 2018 at 04:59:54PM +0200, Laurent Pinchart wrote:
> The omap_connector_attached_encoder() doesn't exist anymore, remove its
> declaration from omap_connector.h.
>
> Signed-off-by: Laurent Pinchart
> ---
Reviewed-by: Sebastian Reichel
-- Sebastian
>
Hi Philipp, can you review this patch and give it your ack?
Thanks,
Steve
On 10/16/18 5:00 PM, Steve Longerbeam wrote:
The function ipu_csi_init_interface() was inverting the F-bit for
NTSC case, in the CCIR_CODE_1/2 registers. The result being that
for NTSC bottom-top field order, the CSI
Hi,
On Wed, Dec 05, 2018 at 05:00:02PM +0200, Laurent Pinchart wrote:
> The omapdrm and omapdss drivers are architectured based on display
> pipelines made of multiple components handled from sink (display) to
> source (DSS output). This is incompatible with the DRM bridge and panel
> APIs that
The binding document for this device says that all GPIOs are optional,
but the driver fails to bind on OMAP3 LDP, reporting:
panel-sharp-ls037v7dw01: probe of display failed with error -2
Unfortunately, commit ca8c67dafdb7 ("fbdev: omap2: improve usage of
gpiod API") removed the -ENOENT handling
Hi,
On Wed, Dec 05, 2018 at 05:00:03PM +0200, Laurent Pinchart wrote:
> The field is only used in a safety check during device
> connection/disconnection, where the src field can be easily used
> instead. Remove it and use src.
>
> Signed-off-by: Laurent Pinchart
> ---
Reviewed-by: Sebastian
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c: In function
'amdgpu_display_crtc_scaling_mode_fixup':
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c:675:27: warning:
variable 'amdgpu_connector' set but not used [-Wunused-but-set-variable]
It never used
Hi,
On Wed, Dec 05, 2018 at 05:00:11PM +0200, Laurent Pinchart wrote:
> Display pipelines based on drm_bridge are handled from the bridge
> closest to the CRTC. To move to that model we thus need to transition
> away from walking pipelines in the other direction, and from accessing
> the device
Hi,
On Wed, Dec 05, 2018 at 05:00:04PM +0200, Laurent Pinchart wrote:
> All the internal encoders share common init and cleanup code. Factor it
> out to separate functions.
>
> Signed-off-by: Laurent Pinchart
> ---
Reviewed-by: Sebastian Reichel
-- Sebastian
>
On Thu, Dec 06, 2018 at 02:47:03PM +0100, Hans de Goede wrote:
> DSI LCD panels describe an initialization sequence in the Video BIOS
> Tables using so called MIPI sequences. One possible element in these
> sequences is a PMIC specific element of 15 bytes.
>
> Although this is not really an ACPI
On Wed, Dec 05, 2018 at 04:59:55PM +0200, Laurent Pinchart wrote:
> The kobj field from struct omap_dss_device is not used. Remove it.
>
> Signed-off-by: Laurent Pinchart
> ---
Reviewed-by: Sebastian Reichel
-- Sebastian
> drivers/gpu/drm/omapdrm/dss/omapdss.h | 2 --
> 1 file changed, 2
Hi Sebastian,
On Monday, 10 December 2018 00:26:28 EET Sebastian Reichel wrote:
> On Wed, Dec 05, 2018 at 05:00:18PM +0200, Laurent Pinchart wrote:
> > The omap_dss_device .check_timings() and .set_timings() operations
> > operate on struct videomode, while the DRM API operates on struct
> >
Instead of rolling out custom suspend/resume implementations based on
state information stored in the driver's data structures, use the atomic
suspend/resume helpers that rely on a DRM atomic state object.
Signed-off-by: Laurent Pinchart
---
Changes since v1:
- Use
101 - 187 of 187 matches
Mail list logo
