Hi Linus,
Quiet enough for rc2, mostly amdgpu fixes, a couple of i915 fixes, and
one nouveau module firmware fix.
Regards,
Dave.
drm-fixes-2020-04-18:
drm fixes for 5.7-rc2
i915:
- Fix guest page access by using the brand new VFIO dma r/w interface (Yan)
- Fix for i915 perf read buffers
Reviewed-by: Lyude Paul
In the future btw, you should use the DRM maintainer tools to add a Fixed-by
tag, since this:
Fixes: cd82d82cbc04 ("drm/dp_mst: Add branch bandwidth validation to MST
atomic check")
Also so it gets cc'd to stable, I'll fixup the patch and push it. Thanks!
On Tue,
On Mon, 2 Mar 2020 15:03:29 -0800 Andrew Morton
wrote:
>
> (switched to email. Please respond via emailed reply-to-all, not via the
> bugzilla web interface).
>
> On Mon, 02 Mar 2020 21:55:10 + bugzilla-dae...@bugzilla.kernel.org wrote:
>
> >
Increase DRM_OBJECT_MAX_PROPERTY to accommodate for additional
DRM properties on MSM chipsets.
Signed-off-by: Abhinav Kumar
---
include/drm/drm_mode_object.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/drm/drm_mode_object.h b/include/drm/drm_mode_object.h
index
On Fri, 2020-04-17 at 17:03 -0400, Tejun Heo wrote:
> Hello,
>
> On Fri, Apr 17, 2020 at 04:16:28PM -0400, Lyude Paul wrote:
> > Hey Tejun! So I ended up rewriting the drm_vblank_work stuff so that it
> > used
> > kthread_worker. Things seem to work alright now. But while we're doing
> > just
> >
Hello,
On Fri, Apr 17, 2020 at 04:16:28PM -0400, Lyude Paul wrote:
> Hey Tejun! So I ended up rewriting the drm_vblank_work stuff so that it used
> kthread_worker. Things seem to work alright now. But while we're doing just
> fine with vblank workers on nouveau, we're still having trouble meeting
Hi Dmitry,
On Fri, Apr 17, 2020 at 11:52:11PM +0300, Dmitry Osipenko wrote:
> 17.04.2020 23:31, Laurent Pinchart пишет:
> > On Fri, Apr 17, 2020 at 10:41:59PM +0300, Dmitry Osipenko wrote:
> >> 17.04.2020 22:30, Laurent Pinchart пишет:
> >> ...
> #include
> +#include
> >>>
> >>> You
https://bugzilla.kernel.org/show_bug.cgi?id=207331
Alex Deucher (alexdeuc...@gmail.com) changed:
What|Removed |Added
CC|
Hi,
On Fri, Apr 17, 2020 at 12:13 AM Kalyan Thota wrote:
>
> "The PM core always increments the runtime usage counter
> before calling the ->suspend() callback and decrements it
> after calling the ->resume() callback"
>
> DPU and DSI are managed as runtime devices. When
> suspend is triggered,
On Fri, Apr 17, 2020 at 11:11:06PM +0300, Dmitry Osipenko wrote:
> 17.04.2020 22:24, Laurent Pinchart пишет:
> ...
> > As I tried to explain before, if you wrap the panel in a bridge with
> > drm_panel_bridge_add() (or the devm_ variant), you will always have a
> > bridge associated with the
Hi Dmitry,
On Fri, Apr 17, 2020 at 10:41:59PM +0300, Dmitry Osipenko wrote:
> 17.04.2020 22:30, Laurent Pinchart пишет:
> ...
> >> #include
> >> +#include
> >
> > You could add a forward declaration of struct drm_bridge instead, that
> > can lower the compilation time a little bit.
>
> This
Hi Arnd.
On Fri, Apr 17, 2020 at 10:03:23PM +0200, Arnd Bergmann wrote:
> On Fri, Apr 17, 2020 at 6:50 PM Sam Ravnborg wrote:
>
> >
> > So what this try to say is that we cannot have FB a module while DRM is
> > built-in (marked N in the above).
>
> Correct
>
> >
> > Could you explain in the
On Thu, Apr 9, 2020 at 3:39 AM Rob Herring wrote:
> Since the VExpress setup in pl111_vexpress.c is now just a single
> function call, let's move it into pl111_versatile.c and we can further
> simplify pl111_versatile_init() by moving the other pieces for VExpress
> into
On Thu, Apr 9, 2020 at 3:39 AM Rob Herring wrote:
> The init VExpress variants currently instantiates a 'muxfpga' driver for
> the sole purpose of getting a regmap for it. There's no reason to
> instantiate a driver and doing so just complicates things. The muxfpga
> driver also isn't
Hey Tejun! So I ended up rewriting the drm_vblank_work stuff so that it used
kthread_worker. Things seem to work alright now. But while we're doing just
fine with vblank workers on nouveau, we're still having trouble meeting the
time constraints needed for using vblank works for i915's needs.
On Thu, Apr 9, 2020 at 3:39 AM Rob Herring wrote:
> Add a missing MODULE_DEVICE_TABLE entry to fix module autoloading.
>
> Cc: Eric Anholt
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-by: Rob Herring
Reviewed-by: Linus Walleij
Yours,
Linus Walleij
On Fri, Apr 17, 2020 at 6:50 PM Sam Ravnborg wrote:
>
> So what this try to say is that we cannot have FB a module while DRM is
> built-in (marked N in the above).
Correct
>
> Could you explain in the changelog why this combination is not good.
> (Or tell me if my analysis was flawed).
I
On Fri, Apr 17, 2020 at 7:04 PM Sam Ravnborg wrote:
>
> Hi Arnd.
>
> On Fri, Apr 17, 2020 at 05:55:52PM +0200, Arnd Bergmann wrote:
> > Rather than having CONFIG_FB_BACKLIGHT select CONFIG_BACKLIGHT_CLASS_DEVICE,
> > make any driver that needs it have a dependency on the class device
> > being
This introduces support for CRC readback on gf119+, using the
documentation generously provided to us by Nvidia:
https://github.com/NVIDIA/open-gpu-doc/blob/master/Display-CRC/display-crc.txt
We expose all available CRC sources. SF, SOR, PIOR, and DAC are exposed
through a single set of "outp"
Nvidia released some documentation on how CRC support works on their
GPUs, hooray!
So: this patch series implements said CRC support in nouveau, along with
adding some special debugfs interfaces for some relevant igt-gpu-tools
tests that we'll be sending in just a short bit.
This additionally
In order to make sure that we flush disable updates at the right time
when disabling CRCs, we'll need to be able to look at the outp state to
see if we're changing it at the same time that we're disabling CRCs.
So, expose the struct in disp.h.
Signed-off-by: Lyude Paul
---
We refer to the armed hardware assembly as armh elsewhere in nouveau, so
fix the naming here to make it consistent.
This patch contains no functional changes.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/dispnv50/wndw.c | 12 ++--
1 file changed, 6 insertions(+), 6
While kthread_queue_work() is fine for basic kthread_worker usecases,
it's a little limiting if you want to create your own delayed work
implementations that delay off things other than a clock. Looking at
kthread_delayed_works for instance, all of the code shares the lock in
kthread_work so that
Since we'll be allocating resources for kthread_create_worker() in the
next commit (which could fail and require us to clean up the mess),
let's simplify the cleanup process a bit by registering a
drm_vblank_init_release() action for each drm_vblank_crtc so they're
still cleaned up if we fail to
We'll be rolling back more things in this function, and the way it's
structured is a bit confusing. So, let's clean this up a bit and just
unroll in the event of failure.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/dispnv50/head.c | 33 +
1 file changed, 23
Currently, we modify the depth value stored in the atomic state when
performing a commit in order to workaround the fact we haven't
implemented support for depths higher then 10 yet. This isn't idempotent
though, as it will happen every atomic commit where we modify the OR
state even if the head's
While we're not quite ready yet to add support for flexible wndw
mappings, we are going to need to at least keep track of the static wndw
mappings we're currently using in each head's atomic state. We'll likely
use this in the future to implement real flexible window mapping, but
the primary
While most of the functionality on Nvidia GPUs doesn't require using an
explicit handle instead of the main VRAM handle + offset, there are a
couple of places that do require explicit handles, such as CRC
functionality. Since this means we're about to add another
nouveau-chosen handle, let's just
Add some kind of vblank workers. The interface is similar to regular
delayed works, and is mostly based off kthread_work. It allows for
scheduling delayed works that execute once a particular vblank sequence
has passed. It also allows for accurate flushing of scheduled vblank
works - in that
While we expose the ability to turn off hardware dithering for nouveau,
we actually make the mistake of turning it on anyway, due to
dithering_depth containing a non-zero value if our dithering depth isn't
also set to 6 bpc.
So, fix it by never enabling dithering when it's disabled.
https://bugzilla.kernel.org/show_bug.cgi?id=207331
Grzegorz Kowal (custos.men...@gmail.com) changed:
What|Removed |Added
CC|
https://bugzilla.kernel.org/show_bug.cgi?id=207331
--- Comment #1 from Grzegorz Kowal (custos.men...@gmail.com) ---
Created attachment 288571
--> https://bugzilla.kernel.org/attachment.cgi?id=288571=edit
dmesg
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=207331
Bug ID: 207331
Summary: commit "drm/amdgpu: fix gfx hang during suspend with
video playback" breaks reboot/shutdown
Product: Drivers
Version: 2.5
Kernel Version: 5.6.5
Hi Dmitry,
Thank you for the patch.
On Fri, Apr 17, 2020 at 08:52:37PM +0300, Dmitry Osipenko wrote:
> Newer Tegra device-trees will specify a video output graph which involves
> a bridge. This patch adds initial support for the DRM bridges to the
> Tegra's DRM output.
>
> Signed-off-by: Dmitry
Hi Dmitry,
Thank you for the patch.
On Fri, Apr 17, 2020 at 08:52:38PM +0300, Dmitry Osipenko wrote:
> Newer Tegra device-trees will specify a video output graph, which involves
> LVDS encoder bridge. This patch adds support for the LVDS encoder bridge
> to the RGB output, allowing us to model
On Fri, Apr 17, 2020 at 08:10:26PM +0200, Daniel Vetter wrote:
> On Fri, Apr 17, 2020 at 5:43 PM Ville Syrjälä
> wrote:
> >
> > On Fri, Apr 17, 2020 at 05:23:10PM +0200, Daniel Vetter wrote:
> > > On Thu, Apr 16, 2020 at 08:04:20PM +0300, Ville Syrjala wrote:
> > > > From: Ville Syrjälä
> > > >
Hi Rajendra,
I have essentially the same comments as for "tty: serial: qcom_geni_serial:
Use OPP API to set clk/perf state"
(https://patchwork.kernel.org/patch/11495209/).
about error handling of 'dev_pm_opp_of_add_table' and misleading struct
member names 'opp'/'opp_table'. Please apply the
On Fri, Apr 17, 2020 at 6:05 PM Neil Armstrong wrote:
>
> On 17/04/2020 17:07, Daniel Vetter wrote:
> > On Thu, Apr 16, 2020 at 05:24:53PM +0200, Neil Armstrong wrote:
> >> Amlogic uses a proprietary lossless image compression protocol and format
> >> for their hardware video codec accelerators,
On Fri, Apr 17, 2020 at 5:43 PM Ville Syrjälä
wrote:
>
> On Fri, Apr 17, 2020 at 05:23:10PM +0200, Daniel Vetter wrote:
> > On Thu, Apr 16, 2020 at 08:04:20PM +0300, Ville Syrjala wrote:
> > > From: Ville Syrjälä
> > >
> > > Revert back to comparing fb->format->format instead fb->format for the
Hi Doug,
On Thu, Apr 16, 2020 at 02:53:18PM -0700, Doug Anderson wrote:
> On Wed, Apr 15, 2020 at 5:54 PM Laurent Pinchart wrote:
> > On Wed, Apr 15, 2020 at 04:49:00PM -0700, Doug Anderson wrote:
> > > On Wed, Apr 15, 2020 at 1:33 PM Laurent Pinchart wrote:
> > > > On Wed, Apr 15, 2020 at
On Thu, Apr 9, 2020 at 9:16 AM Sam Ravnborg wrote:
>
> Hi Rob.
>
> On Wed, Apr 08, 2020 at 07:39:46PM -0600, Rob Herring wrote:
> > The init VExpress variants currently instantiates a 'muxfpga' driver for
> > the sole purpose of getting a regmap for it. There's no reason to
> > instantiate a
On Thu, Apr 9, 2020 at 9:34 AM Sam Ravnborg wrote:
>
> Hi Rob.
>
> On Wed, Apr 08, 2020 at 07:39:47PM -0600, Rob Herring wrote:
> > Since the VExpress setup in pl111_vexpress.c is now just a single
> > function call, let's move it into pl111_versatile.c and we can further
> > simplify
On Fri, Apr 17, 2020 at 05:55:45PM +0200, Arnd Bergmann wrote:
> I tried to fix up some dependencies after the sii8620 "imply EXTCON"
> statementn broke, trying a few things but in the backing out a
> change that would completely reverse the LEDS_CLASS selects into
> a 'depends on'.
>
> However,
Hi Arnd.
On Fri, Apr 17, 2020 at 05:55:52PM +0200, Arnd Bergmann wrote:
> Rather than having CONFIG_FB_BACKLIGHT select CONFIG_BACKLIGHT_CLASS_DEVICE,
> make any driver that needs it have a dependency on the class device
> being available, to prevent circular dependencies.
>
> This is the same
On 17.04.2020 17:55, Arnd Bergmann wrote:
> Using 'imply' does not work here, it still cause the same build
> failure:
>
> arm-linux-gnueabi-ld: drivers/gpu/drm/bridge/sil-sii8620.o: in function
> `sii8620_remove':
> sil-sii8620.c:(.text+0x1b8): undefined reference to
>
Hi Arnd.
On Fri, Apr 17, 2020 at 05:55:51PM +0200, Arnd Bergmann wrote:
> CONFIG_DRM_KMS_FB_HELPER selects CONFIG_FB, which is something it
> really should not, to avoid circular dependencies and accidentally
> including potentially dangerous user interfaces in the kernel,
> so change this into a
On 17/04/2020 18:05, Neil Armstrong wrote:
> On 17/04/2020 17:07, Daniel Vetter wrote:
>> On Thu, Apr 16, 2020 at 05:24:53PM +0200, Neil Armstrong wrote:
>>> Amlogic uses a proprietary lossless image compression protocol and format
>>> for their hardware video codec accelerators, either video
From: Colin Ian King
The variable test_result is being initialized with a value that is
never read and it is being updated later with a new value. The
initialization is redundant and can be removed.
Addresses-Coverity: ("Unused value")
Signed-off-by: Colin Ian King
---
On 17/04/2020 17:07, Daniel Vetter wrote:
> On Thu, Apr 16, 2020 at 05:24:53PM +0200, Neil Armstrong wrote:
>> Amlogic uses a proprietary lossless image compression protocol and format
>> for their hardware video codec accelerators, either video decoders or
>> video input encoders.
>>
>> It
Rather than having CONFIG_FB_BACKLIGHT select CONFIG_BACKLIGHT_CLASS_DEVICE,
make any driver that needs it have a dependency on the class device
being available, to prevent circular dependencies.
This is the same way that the backlight is already treated for the DRM
subsystem.
Signed-off-by:
In order to get rid of the 'select FB' line in Kconfig for all platforms,
change the w100fb driver to handle the gpio lines itself rather than
using an indirect function call.
This also allows removing the remaining exported interfaces from the
driver, the only other symbol has been unused for a
I tried to fix up some dependencies after the sii8620 "imply EXTCON"
statementn broke, trying a few things but in the backing out a
change that would completely reverse the LEDS_CLASS selects into
a 'depends on'.
However, what I got now are multiple changes that remove gratious
"selects" that
Using 'imply' does not work here, it still cause the same build
failure:
arm-linux-gnueabi-ld: drivers/gpu/drm/bridge/sil-sii8620.o: in function
`sii8620_remove':
sil-sii8620.c:(.text+0x1b8): undefined reference to `extcon_unregister_notifier'
arm-linux-gnueabi-ld:
Selecting FB_DDC currently turns on CONFIG_I2C implicitly,
which is often not desired and can lead to circular dependencies.
Change this to a 'depends on' and change all drivers that
rely on FB_DDC to have an appropriate I2C dependency as well.
Signed-off-by: Arnd Bergmann
---
In order to add more compile-time dependencies to CONFIG_FB, remove the
last few instances of selecting it from platform code.
This was originally written to allow a modular driver, but that never
worked because vmlinux cannot call exported functions from a loadable
module.
Just change the
The meaning of the 'imply' keyword has changed recently, and neither the
old meaning (select the symbol if its dependencies are met) nor the new
meaning (enable it by default, but let the user set any other setting)
is what we want here.
Work around this by adding two more Kconfig options that
CONFIG_FB causes unnecessary Kconfig dependency problems when selected
from another driver. Since it is already optional in vmwgfx at runtime,
turn this into a compile-time dependency so the support can be completely
left out of the driver and enabled only if CONFIG_FB is explicitly
selected in
CONFIG_DRM_KMS_FB_HELPER selects CONFIG_FB, which is something it
really should not, to avoid circular dependencies and accidentally
including potentially dangerous user interfaces in the kernel,
so change this into a 'depends on' check.
Two device drivers currently select
On Fri, Apr 17, 2020 at 05:23:10PM +0200, Daniel Vetter wrote:
> On Thu, Apr 16, 2020 at 08:04:20PM +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Revert back to comparing fb->format->format instead fb->format for the
> > page flip ioctl. This check was originally only here to
On Fri, Apr 17, 2020 at 06:10:32PM +0800, YueHaibing wrote:
> drivers/gpu/drm/gma500/oaktrail_hdmi.c:676:35: warning: ‘hdmi_ids’ defined
> but not used [-Wunused-const-variable=]
> static const struct pci_device_id hdmi_ids[] = {
>^~~~
>
> It is never
On Thu, Apr 16, 2020 at 08:04:20PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Revert back to comparing fb->format->format instead fb->format for the
> page flip ioctl. This check was originally only here to disallow pixel
> format changes, but when we changed it to do the pointer
> -Original Message-
> From: dri-devel On Behalf Of Ville
> Syrjala
> Sent: Thursday, April 16, 2020 10:34 PM
> To: dri-devel@lists.freedesktop.org
> Cc: intel-...@lists.freedesktop.org; Laurent Pinchart
> ; sta...@vger.kernel.org
> Subject: [PATCH] drm: Fix page flip ioctl format check
On Thu, Apr 16, 2020 at 05:24:53PM +0200, Neil Armstrong wrote:
> Amlogic uses a proprietary lossless image compression protocol and format
> for their hardware video codec accelerators, either video decoders or
> video input encoders.
>
> It considerably reduces memory bandwidth while writing
On Thu, Apr 16, 2020 at 12:30:55PM +0200, Geert Uytterhoeven wrote:
> According to https://www.analog.com/, the company name is spelled
> "Analog Devices".
>
> Signed-off-by: Geert Uytterhoeven
Queued for 5.8 in drm-misc-next, thanks for your patch.
-Daniel
> ---
>
On Thu, Apr 16, 2020 at 12:25:08PM +0200, Greg Kroah-Hartman wrote:
> On Tue, Apr 14, 2020 at 09:41:31PM -0700, John Stultz wrote:
> > On Tue, Apr 14, 2020 at 7:28 AM Greg Kroah-Hartman
> > wrote:
> > >
> > > On Tue, Apr 14, 2020 at 04:18:47PM +0200, Ørjan Eide wrote:
> > > > Only sync the
On Thu, Apr 16, 2020 at 03:44:53PM +0200, Yussuf Khalil wrote:
> On Wed, 2020-04-15 at 13:13 +0200, Daniel Vetter wrote:
> > On Wed, Apr 15, 2020 at 10:33:25AM +0300, Jani Nikula wrote:
> > > On Tue, 14 Apr 2020, Yussuf Khalil wrote:
> > > > On Tue, 2020-04-14 at 14:34 +0200, Daniel Vetter wrote:
On Thu, Apr 16, 2020 at 03:51:36PM +0200, Yussuf Khalil wrote:
> On Tue, 2020-04-14 at 14:41 +0200, Daniel Vetter wrote:
> > On Mon, Apr 13, 2020 at 11:40:22PM +0200, Yussuf Khalil wrote:
> > > Add a new flag to mark modes that are considered a CE mode
> > > according to the
> > > CEA-861
On Fri, 2020-04-17 at 16:18 +0200, Daniel Vetter wrote:
> > I suppose rf-kill is a bit similar.
RfKill is actually much more complicated, and I don't really see how it
is related. We may be in the situation where we cannot control the
hardware state, but RfKill has two entirely separate "block"
On Fri, Apr 17, 2020 at 1:55 PM Jani Nikula wrote:
>
> On Fri, 17 Apr 2020, Pekka Paalanen wrote:
> > On Wed, 15 Apr 2020 17:40:46 +0200
> > Hans de Goede wrote:
> >
> >> Hi,
> >>
> >> On 4/15/20 5:28 PM, Jani Nikula wrote:
> >> > On Wed, 15 Apr 2020, Hans de Goede wrote:
> >> >> ii. Currently
On Fri, Apr 17, 2020 at 11:02 AM Pekka Paalanen wrote:
>
> On Wed, 15 Apr 2020 17:40:46 +0200
> Hans de Goede wrote:
>
> > Hi,
> >
> > On 4/15/20 5:28 PM, Jani Nikula wrote:
> > > On Wed, 15 Apr 2020, Hans de Goede wrote:
> > >> ii. Currently the "privacy-screen" property added by Rajat's
> >
On 3/24/20 2:23 PM, Chuhong Yuan wrote:
> The driver forgets to free irq in remove which is requested in
> probe.
> Add the missed call to fix it.
> Also, the position of request_irq() in probe should be put before
> register_framebuffer().
>
> Signed-off-by: Chuhong Yuan
Patch queued for
On 3/29/20 4:58 PM, Chuhong Yuan wrote:
> The driver forgets to free the I/O region in remove and probe
> failure.
> Add the missed calls to fix it.
>
> Since the success of request_region() is optional, add the "region" field
> in vesafb_par to represent whether request_region() succeeds.
>
On 4/17/20 11:23 AM, Jason Yan wrote:
> Fix the following gcc warning:
>
> drivers/video/fbdev/aty/aty128fb.c:337:36: warning: ‘sdr_64’ defined but
> not used [-Wunused-const-variable=]
> static const struct aty128_meminfo sdr_64 = {
> ^~
>
>
On 3/24/20 2:23 PM, Chuhong Yuan wrote:
> The driver calls register_framebuffer() in probe but does not call
> unregister_framebuffer() in remove.
> Rename current remove to __s1d13xxxfb_remove() for error handler.
> Then add a new remove to call unregister_framebuffer().
>
> Signed-off-by:
[ added dri-devel ML to Cc: ]
On 4/15/20 6:50 PM, Linus Walleij wrote:
> This converts the SA11x0 frame buffer driver to use
> GPIO descriptors. Get the GPIO optional and register
> a look-up table specifically for the Shannon machine.
>
> Cc: Russell King
> Cc: Bartlomiej Zolnierkiewicz
>
[ added dri-devel ML to Cc: ]
On 3/24/20 6:05 PM, Andy Shevchenko wrote:
> Device property API allows to gather device resources from different sources,
> such as ACPI. Convert the drivers to unleash the power of device property API.
>
> Signed-off-by: Andy Shevchenko
Patch queued for v5.8,
On 4/12/20 10:21 PM, Sam Ravnborg wrote:
> Fix following warning:
> vt8500lcdfb.c: In function 'vt8500lcd_blank':
> vt8500lcdfb.c:229:6: warning: this statement may fall through
> [-Wimplicit-fallthrough=]
> if (info->fix.visual == FB_VISUAL_PSEUDOCOLOR ||
> ^
>
On 3/24/20 2:45 PM, Bartlomiej Zolnierkiewicz wrote:
> Hi,
>
> Small cleanup for controlfb driver:
>
> - fix sparse warnings
> - remove not working module support
> - add COMPILE_TEST support
> - remove redundant function prototypes
>
> Changes since v1
>
[ added dri-devel ML to Cc: ]
On 3/24/20 6:05 PM, Andy Shevchenko wrote:
> Introduce temporary variable to increase readability of the code.
>
> Signed-off-by: Andy Shevchenko
Patch queued for v5.8 (w/ few lines over 80 characters fixed), thanks.
Best regards,
--
Bartlomiej Zolnierkiewicz
On 4/15/20 3:23 PM, YueHaibing wrote:
> drivers/video/fbdev/omap2/omapfb/dss/venc.c:212:33:
> warning: ‘venc_config_pal_bdghi’ defined but not used
> [-Wunused-const-variable=]
> static const struct venc_config venc_config_pal_bdghi = {
> ^
[ added dri-devel ML to Cc: ]
On 3/24/20 6:05 PM, Andy Shevchenko wrote:
> There is no need to have forward declaration of struct ssd1307fb_par.
> Drop it for good.
>
> Signed-off-by: Andy Shevchenko
Patch queued for v5.8, thanks.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R
On 3/23/20 10:16 PM, Uwe Kleine-König wrote:
> The fbdev framework doesn't care to call the .set_power callback only on
> changes. So the driver has to care for itself that the regulator doesn't
> get disabled more often than enabled.
>
> This fixes the regulator warning
>
> unbalanced
[ added dri-devel ML to Cc: ]
On 3/24/20 6:05 PM, Andy Shevchenko wrote:
> Use the atomic API wherever appropriate and get rid of pwm_apply_args()
> call (the reference period and polarity are now explicitly set when
> calling pwm_apply_state()).
>
> We also make use of the
On 3/24/20 9:45 PM, Daniel Vetter wrote:
> On Tue, Mar 24, 2020 at 02:45:03PM +0100, Bartlomiej Zolnierkiewicz wrote:
>> Use in_le32() instead of le32_to_cpup() to fix sparse warning about
>> improper type of the argument.
>>
>> Also add missing inline keyword to control_par_to_var() definition
[ added dri-devel ML to Cc: ]
On 3/24/20 6:05 PM, Andy Shevchenko wrote:
> Use the ->probe_new() callback.
>
> The driver does not use const struct i2c_device_id * argument,
> so convert it to utilise the simplified I²C driver registration.
>
> Signed-off-by: Andy Shevchenko
Patch queued for
On some qualcomm platforms DPU needs to express a perforamnce state
requirement on a power domain depennding on the clock rates.
Use OPP table from DT to register with OPP framework and use
dev_pm_opp_set_rate() to set the clk/perf state.
Signed-off-by: Rajendra Nayak
Cc: Rob Clark
Cc: Sean
On SDM845 DSI needs to express a perforamnce state
requirement on a power domain depending on the clock rates.
Use OPP table from DT to register with OPP framework and use
dev_pm_opp_set_rate() to set the clk/perf state.
Signed-off-by: Rajendra Nayak
Cc: Rob Clark
Cc: Sean Paul
Cc:
On Fri, Apr 17, 2020 at 9:16 AM YueHaibing wrote:
>
> drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_clock_source.c:1017:50:
> warning: ‘video_optimized_pixel_rates’ defined but not used
> [-Wunused-const-variable=]
> static const struct pixel_rate_range_table_entry
>
On Fri, Apr 17, 2020 at 9:16 AM Jason Yan wrote:
>
> Fix the following gcc warning:
>
> drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/vega10_powertune.c:710:46:
> warning: ‘PSMGCEDCThresholdConfig_vega10’ defined but not used
> [-Wunused-const-variable=]
> static const struct
On 17/04/2020 16:29, Laurent Pinchart wrote:
Hi Tomi,
Thank you for the patch.
On Fri, Apr 17, 2020 at 02:41:51PM +0300, Tomi Valkeinen wrote:
If the given videomode does not specify DISPLAY_FLAG_* for the specific
signal property, the driver used a default value. These defaults were
never
Hi Tomi,
On Fri, Apr 17, 2020 at 04:34:19PM +0300, Tomi Valkeinen wrote:
> On 17/04/2020 16:29, Laurent Pinchart wrote:
> > On Fri, Apr 17, 2020 at 02:41:51PM +0300, Tomi Valkeinen wrote:
> >> If the given videomode does not specify DISPLAY_FLAG_* for the specific
> >> signal property, the driver
Hi Tomi,
Thank you for the patch.
On Fri, Apr 17, 2020 at 02:41:51PM +0300, Tomi Valkeinen wrote:
> If the given videomode does not specify DISPLAY_FLAG_* for the specific
> signal property, the driver used a default value. These defaults were
> never thought through, as the expectation was that
(Adding Alex to the thread)
On 17/04/2020 14:40, Tomi Valkeinen wrote:
The AUO G101EVN010 is a 18-bit LVDS panel, not a parallel panel, as
indicated by the current bus_format.
Fix the bus_format to MEDIA_BUS_FMT_RGB666_1X7X3_SPWG, and also set the
connector_type to LVDS.
Signed-off-by: Tomi
Hi Tomi,
Thank you for the patch.
On Fri, Apr 17, 2020 at 04:00:34PM +0300, Tomi Valkeinen wrote:
> (Adding Alex to the thread)
>
> On 17/04/2020 14:40, Tomi Valkeinen wrote:
> > The AUO G101EVN010 is a 18-bit LVDS panel, not a parallel panel, as
> > indicated by the current bus_format.
> >
>
Hello,
On Fri, Apr 17, 2020 at 02:44:22PM +0200, Maxime Ripard wrote:
> On Fri, Apr 17, 2020 at 02:18:11PM +0200, H. Nikolaus Schaller wrote:
> > Hi Maxime,
> > I have started to test v5.7-rc1 and can't fully boot the GTA04
> > device any more.
> >
> > What I see in the log is:
> >
> > [
Call intel_dp_set_infoframes(false) function on intel_ddi_post_disable_dp()
to make sure not to send VSC SDP and HDR Metadata Infoframe SDP.
v5: Polish commit message [Uma]
Signed-off-by: Gwan-gyeong Mun
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/i915/display/intel_ddi.c | 2 ++
1 file
In order to use a common VSC SDP Colorimetry calculating code on PSR,
it adds a compute routine for PSR VSC SDP.
As PSR routine can not use infoframes.vsc of crtc state, it also adds new
writing of DP SDPs (Secondary Data Packet) for PSR.
PSR routine has its own scenario and timings of writing a
Added state readout for DP HDR Metadata Infoframe SDP.
v9: Rebased
v10: Rebased
Signed-off-by: Gwan-gyeong Mun
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/i915/display/intel_ddi.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
Dump out the HDMI Dynamic Range and Mastering (DRM) infoframe in the
normal crtc state dump.
Signed-off-by: Gwan-gyeong Mun
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/i915/display/intel_display.c | 3 +++
1 file changed, 3 insertions(+)
diff --git
Compared to implementation of DP and HDMI's encoder->infoframes_enabled,
the lspcon's implementation returns its active state. (we expect enabled
infoframe states of HW.) It leads to pipe state mismatch error
when ddi_get_config is called.
Because the current implementation of lspcon is not ready
1 - 100 of 164 matches
Mail list logo
