On Tue, Nov 24, 2020 at 12:57:43PM -0600, Bjorn Andersson wrote:
> A combination of recent bug fixes by Doug Anderson and the proper
> definition of iommu streams means that this hack is no longer needed.
> Let's clean up the code by reverting '127068abe85b ("i2c: qcom-geni:
> Disable DMA
On Fri, Nov 20, 2020 at 10:15:57PM +, Chrisanthus, Anitha wrote:
> Hi Dan,
> I see the problem now, thanks for the patch.
>
> > -Original Message-
> > From: Dan Carpenter
> > Sent: Friday, November 20, 2020 12:11 AM
> > To: Chrisanthus, Anitha
> > Cc: Dea, Edmund J ; David Airlie ;
Hi Peilin,
On Mon, Nov 30, 2020 at 01:38:05AM -0500, Peilin Ye wrote:
> Hi Sam,
>
> On Sun, Nov 29, 2020 at 12:18:36PM +0100, Sam Ravnborg wrote:
> > On Sun, Nov 29, 2020 at 07:28:08PM +0900, Tetsuo Handa wrote:
> > > But replacing printk(KERN_DEBUG) with pr_debug() prevents __func__ from
> > >
Hi Douglas,
On Mon, Nov 09, 2020 at 05:00:57PM -0800, Douglas Anderson wrote:
> On the panel I'm looking at, there's an 80 ms minimum time between HPD
> being asserted by the panel and setting the backlight enable GPIO.
> While we could just add an 80 ms "enable" delay, this is not ideal.
> Link
Hi Sam,
On Sun, Nov 29, 2020 at 12:18:36PM +0100, Sam Ravnborg wrote:
> On Sun, Nov 29, 2020 at 07:28:08PM +0900, Tetsuo Handa wrote:
> > But replacing printk(KERN_DEBUG) with pr_debug() prevents __func__ from
> > being printed
> > when FBCONDEBUG is defined. Is such change what the author of
On Wed, 18 Nov 2020 14:58:15 +0100, Johan Jonker wrote:
> First fix some legacy things in clk-rk3188.c that was never updated,
> because probably nobody used rk3066a I2S before in the mainline kernel.
> Update the rk3066a HDMI documents with a #sound-dai-cells property.
> Include the code for
Hi Douglas,
On Mon, Nov 09, 2020 at 05:00:56PM -0800, Douglas Anderson wrote:
> It is believed that all of the current users of the "unprepare" delay
> don't actually need to wait the amount of time specified directly in
> the unprepare phase. The purpose of the delay that's specified is to
>
Hi Douglas,
On Mon, Nov 09, 2020 at 05:00:55PM -0800, Douglas Anderson wrote:
> When I run:
> scripts/kernel-doc -rst drivers/gpu/drm/panel/panel-simple.c
>
> I see that several of the kernel-doc entries aren't showing up because
> they don't specify the full path down the hierarchy. Let's fix
Hi Douglas,
On Mon, Nov 09, 2020 at 05:00:58PM -0800, Douglas Anderson wrote:
> Add support for the BOE NV110WTM-N61 panel. The EDID lists two modes
> (one for 60 Hz refresh rate and one for 40 Hz), so we'll list both of
> them here.
>
> Note that the panel datasheet requires 80 ms between HPD
Le sam. 28 nov. 2020 à 19:58, Sam Ravnborg a écrit
:
Hi Paul.
On Sat, Nov 28, 2020 at 05:16:06PM +, Paul Cercueil wrote:
Call drm_mode_config_helper_suspend() and
drm_mode_config_helper_resume() on suspend and resume, respectively.
This makes sure that the display stack is
Hi,
On 27.11.20 г. 15:10 ч., Ivaylo Dimitrov wrote:
On 27.11.20 г. 13:45 ч., Tomi Valkeinen wrote:
On 27/11/2020 01:17, Ivaylo Dimitrov wrote:
Hi Tomi,
On 26.11.20 г. 16:11 ч., Tomi Valkeinen wrote:
Hi Aaro, Ivaylo,
On 24/11/2020 23:03, Ivaylo Dimitrov wrote:
Is there any progress on
On 11/24/20 11:39 AM, Daniel Vetter wrote:
On Fri, Nov 20, 2020 at 01:19:04PM -0300, Leandro Ribeiro wrote:
Hello,
We have a patch in Weston to replace drmGetConnector() calls with
drmGetConnectorCurrent():
https://gitlab.freedesktop.org/wayland/weston/-/issues/437
On 11/28/20 7:46 PM, Aaro Koskinen wrote:
> Hi,
>
> On Fri, Nov 27, 2020 at 09:04:29PM +0100, Sebastian Reichel wrote:
>> The probe routine acquires the reset GPIO using GPIOD_OUT_LOW. Directly
>> afterwards it calls acx565akm_detect(), which sets the GPIO value to
>> HIGH. If the bootloader
Hi,
On Fri, Nov 27, 2020 at 09:04:29PM +0100, Sebastian Reichel wrote:
> The probe routine acquires the reset GPIO using GPIOD_OUT_LOW. Directly
> afterwards it calls acx565akm_detect(), which sets the GPIO value to
> HIGH. If the bootloader initialized the GPIO to HIGH before the probe
> routine
Attaching the panel can fail, so cleanup work is necessary, otherwise
a pointer to freed struct drm_panel* will remain in drm_panel code.
Do the cleanup if panel attaching failed.
Fixes: 69dc678abc2b ("drm/panel: Add Feiyang FY07024DI26A30-D MIPI-DSI LCD
panel")
Signed-off-by: Icenowy Zheng
Aliases property name must include only lowercase and '-', so fix this
in the driver, so we're not tempted to do "ovl_2l0 = _2l0" in the
device-tree instead of the right one which is "ovl-2l0 = _2l0".
Fixes: dd8feb2262d9 ("drm/mediatek: add component OVL_2L1")
Fixes: b17bdd0d7a73 ("drm/mediatek:
On 27.11.20 г. 13:45 ч., Tomi Valkeinen wrote:
On 27/11/2020 01:17, Ivaylo Dimitrov wrote:
Hi Tomi,
On 26.11.20 г. 16:11 ч., Tomi Valkeinen wrote:
Hi Aaro, Ivaylo,
On 24/11/2020 23:03, Ivaylo Dimitrov wrote:
Is there any progress on the issue? I tried 5.9.1 and still nothing displayed.
Hi,
On Fri, Nov 27, 2020 at 10:52:41AM +0200, Tomi Valkeinen wrote:
> When the SDI output was converted to DRM bridge, the atomic versions of
> enable and disable funcs were used. This was not intended, as that would
> require implementing other atomic funcs too. This leads to:
>
> WARNING: CPU:
On 11/27/20 6:10 PM, Leandro Ribeiro wrote:
> In userspace we can use drmGetConnector() or drmGetConnectorCurrent() in
> order to retrieve connector information. The difference between both is
> that the former retrieves the complete set of modes and encoders
> associated with the connector,
In userspace we can use drmGetConnector() or drmGetConnectorCurrent() in
order to retrieve connector information. The difference between both is
that the former retrieves the complete set of modes and encoders
associated with the connector, while the latter only retrieves the
currently known set
Hi Sam-
On 11/28/20 2:41 PM, Sam Ravnborg wrote:
> Fix kernel-doc comments.
>
> v2:
> - Updated subject (Lee)
>
> Signed-off-by: Sam Ravnborg
> Cc: Ferenc Bakonyi
> Cc: linux-nvi...@lists.surfsouth.com
> Cc: Lee Jones
> ---
> drivers/video/fbdev/hgafb.c | 4 ++--
> 1 file changed, 2
The probe routine acquires the reset GPIO using GPIOD_OUT_LOW. Directly
afterwards it calls acx565akm_detect(), which sets the GPIO value to
HIGH. If the bootloader initialized the GPIO to HIGH before the probe
routine was called, there is only a very short time period of a few
instructions where
Call drm_mode_config_helper_suspend() and
drm_mode_config_helper_resume() on suspend and resume, respectively.
This makes sure that the display stack is properly disabled when the
hardware is put to sleep.
Signed-off-by: Paul Cercueil
---
drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 20
On 2020/11/29 19:03, Thomas Zimmermann wrote:
> Am 28.11.20 um 23:40 schrieb Sam Ravnborg:
>> Replacing DPRINTK() statements with pr_debug fixes set but not used
>> warnings. And moves to a more standard logging setup at the same time.
>
> I guess this was added for quick debugging during
You may add:
Tested-by: Ivaylo Dimitrov
On 27.11.20 г. 22:04 ч., Sebastian Reichel wrote:
The probe routine acquires the reset GPIO using GPIOD_OUT_LOW. Directly
afterwards it calls acx565akm_detect(), which sets the GPIO value to
HIGH. If the bootloader initialized the GPIO to HIGH before
Hi,
On 27.11.20 г. 19:30 ч., Tomi Valkeinen wrote:
On 27/11/2020 17:37, Ivaylo Dimitrov wrote:
With 5.9.11 and the patch on top, n900 boots fine, albeit display remains
blank, could be related to
brightness, we're still investigating.
Ok. A DSS regdump for a working version and the latest
On Thu, Nov 19, 2020 at 03:41:29PM +0100, Daniel Vetter wrote:
> I feel like this is ready for some wider soaking. Since the remaining bits
> are all kinda connnected probably simplest if it all goes through -mm.
Did you figure out a sumbission plan for this stuff?
> Daniel Vetter (17):
>
Hi Sebastian,
On Sun, Nov 29, 2020 at 01:53:31AM +0100, Sebastian Reichel wrote:
> On Sun, Nov 29, 2020 at 12:08:47AM +0200, Laurent Pinchart wrote:
> > On Fri, Nov 27, 2020 at 09:04:29PM +0100, Sebastian Reichel wrote:
> > > The probe routine acquires the reset GPIO using GPIOD_OUT_LOW. Directly
Am 28.11.20 um 23:41 schrieb Sam Ravnborg:
Fix following W=1 warnings:
- Fix set but not nused variables which was used only for logging.
s/nused/used
s/which was/that were
Otherwise
Reviewed-by: Thomas Zimmermann
Fixed by introducing no_printk() to trick compiler to think variables
Hi Tetsuo,
On Sun, Nov 29, 2020 at 07:28:08PM +0900, Tetsuo Handa wrote:
> On 2020/11/29 19:03, Thomas Zimmermann wrote:
> > Am 28.11.20 um 23:40 schrieb Sam Ravnborg:
> >> Replacing DPRINTK() statements with pr_debug fixes set but not used
> >> warnings. And moves to a more standard logging
On Sun, Nov 29, 2020 at 11:01:13AM +0100, Thomas Zimmermann wrote:
>
>
> Am 28.11.20 um 23:40 schrieb Sam Ravnborg:
> > Fix kernel-doc warnings reported when using W=1.
> >
> > v2:
> >- Improve subject (Lee)
> >
> > Signed-off-by: Sam Ravnborg
> > Cc: Lee Jones
> > Cc:
Am 28.11.20 um 23:40 schrieb Sam Ravnborg:
Fix kernel-doc warnings reported when using W=1
v2:
- Improve subject (Lee)
Signed-off-by: Sam Ravnborg
Cc: Lee Jones
Cc: Sam Ravnborg
Cc: Randy Dunlap
Cc: Bartlomiej Zolnierkiewicz
Cc: Daniel Vetter
Cc: "Alexander A. Klimov"
---
Am 28.11.20 um 23:40 schrieb Sam Ravnborg:
Fix kernel-doc warnings reported when using W=1.
v2:
- Improve subject (Lee)
Signed-off-by: Sam Ravnborg
Cc: Lee Jones
Cc: linux-fb...@vger.kernel.org
---
drivers/video/of_display_timing.c | 1 +
drivers/video/of_videomode.c | 8
Am 28.11.20 um 23:40 schrieb Sam Ravnborg:
Replacing DPRINTK() statements with pr_debug fixes set but not used
warnings. And moves to a more standard logging setup at the same time.
v2:
- Fix indent (Joe)
Signed-off-by: Sam Ravnborg
Cc: Joe Perches
Cc: Greg Kroah-Hartman
Cc: Daniel
Hi Tom,
On Fri, Nov 27, 2020 at 11:05:08AM -0800, t...@redhat.com wrote:
> From: Tom Rix
>
> The macro use will already have a semicolon.
>
> Signed-off-by: Tom Rix
Thanks, applied to drm-misc-next.
Sam
___
dri-devel mailing list
Am Samstag, 24. Oktober 2020, 05:53:21 CET schrieb Jonathan Liu:
> Error message incorrectly refers to grf clock instead of vpll clock.
>
> Signed-off-by: Jonathan Liu
applied to drm-misc-next
Thanks
Heiko
___
dri-devel mailing list
On Mon, Nov 16, 2020 at 9:55 AM Jonathan Marek wrote:
>
> On 11/16/20 12:50 PM, Rob Clark wrote:
> > On Mon, Nov 16, 2020 at 9:33 AM Christoph Hellwig wrote:
> >>
> >> On Sat, Nov 14, 2020 at 03:07:20PM -0500, Jonathan Marek wrote:
> >>> qcom's vulkan driver has nonCoherentAtomSize=1, and it
From: Arnd Bergmann
gcc warns about an out-of-bounds access when the using nonzero
values for 'plane_id' on kmb->plane_status:
drivers/gpu/drm/kmb/kmb_plane.c: In function 'kmb_plane_atomic_disable':
drivers/gpu/drm/kmb/kmb_plane.c:128:20: warning: array subscript 3 is above
array bounds of
Hi Paul.
On Thu, Nov 19, 2020 at 03:55:56PM +, Paul Cercueil wrote:
> Hi,
>
> This patchset adds support for delta-RGB panels to the ingenic-drm
> driver. Delta-RGB panels have diamond-pattern subpixel layout, and
> expect odd lines to have RGB subpixel ordering, and even lines to have
> GBR
https://bugzilla.kernel.org/show_bug.cgi?id=210415
Bug ID: 210415
Summary: [amdgpu] constant GPU hangs followed by kernel "BUG"
and following kernel oops
Product: Drivers
Version: 2.5
Kernel Version: 5.9.11
Hardware:
On Tue, 10 Nov 2020 21:04:30 +0100, Paul Kocialkowski wrote:
> In the Rockchip DRM LVDS component driver, the endpoint id provided to
> drm_of_find_panel_or_bridge is grabbed from the endpoint's reg property.
>
> However, the property may be missing in the case of a single endpoint.
> Initialize
From: Rob Clark
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/msm/disp/mdp5/mdp5_ctl.c:227: warning: Function parameter or
member 'ctl' not described in 'mdp5_ctl_set_encoder_state'
drivers/gpu/drm/msm/disp/mdp5/mdp5_ctl.c:227: warning: Function parameter or
member
On Sat, Nov 28, 2020 at 11:40:47PM +0100, Sam Ravnborg wrote:
> Fix kernel-doc warnings reported when using W=1.
>
> v2:
> - Improve subject (Lee)
>
> Signed-off-by: Sam Ravnborg
> Cc: Lee Jones
> Cc: linux-fb...@vger.kernel.org
Applied to drm-misc-next after fixing nit that Thomas pointed
Hi Anitha,
On Fri, Nov 20, 2020 at 05:28:59PM +, Chrisanthus, Anitha wrote:
>
>
> > -Original Message-
> > From: Thomas Zimmermann
> > Sent: Friday, November 20, 2020 12:34 AM
> > To: Sam Ravnborg ; Chrisanthus, Anitha
> >
> > Cc: David Airlie ; Dea, Edmund J ;
> >
Hi Rob,
On Sun, Nov 29, 2020 at 10:12:40AM -0800, Rob Clark wrote:
> From: Rob Clark
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/msm/disp/mdp5/mdp5_ctl.c:227: warning: Function parameter or
> member 'ctl' not described in 'mdp5_ctl_set_encoder_state'
>
https://bugzilla.kernel.org/show_bug.cgi?id=210415
--- Comment #3 from David Rubio (david.alejandro.ru...@gmail.com) ---
Created attachment 293867
--> https://bugzilla.kernel.org/attachment.cgi?id=293867=edit
lscpu output
--
You are receiving this mail because:
You are watching the assignee
https://bugzilla.kernel.org/show_bug.cgi?id=210415
--- Comment #2 from David Rubio (david.alejandro.ru...@gmail.com) ---
Created attachment 293865
--> https://bugzilla.kernel.org/attachment.cgi?id=293865=edit
lspci -vvv output
--
You are receiving this mail because:
You are watching the
https://bugzilla.kernel.org/show_bug.cgi?id=210415
--- Comment #1 from David Rubio (david.alejandro.ru...@gmail.com) ---
This is really been happening for really long, but the now-appearing kernel
oops and BUG prints made me realize it's necessary to post this.
The exact GPU model is MSI RX 480
On Sun, Nov 29, 2020 at 11:03:25AM +0100, Thomas Zimmermann wrote:
>
>
> Am 28.11.20 um 23:40 schrieb Sam Ravnborg:
> > Replacing DPRINTK() statements with pr_debug fixes set but not used
> > warnings. And moves to a more standard logging setup at the same time.
> >
> > v2:
> >- Fix indent
Hello Michael,
On Sat, Nov 28, 2020 at 09:48:30AM +0100, Takashi Iwai wrote:
> On Thu, 26 Nov 2020 17:59:50 +0100,
> Uwe Kleine-König wrote:
> >
> > The driver core ignores the return value of struct device_driver::remove
> > because there is only little that can be done. For the shutdown
Hi Sebastian,
On Fri, Nov 27, 2020 at 09:04:29PM +0100, Sebastian Reichel wrote:
> The probe routine acquires the reset GPIO using GPIOD_OUT_LOW. Directly
> afterwards it calls acx565akm_detect(), which sets the GPIO value to
> HIGH. If the bootloader initialized the GPIO to HIGH before the probe
Hi Thomas.
On Sun, Nov 29, 2020 at 10:59:22AM +0100, Thomas Zimmermann wrote:
>
>
> Am 28.11.20 um 23:41 schrieb Sam Ravnborg:
> > Fix following W=1 warnings:
> > - Fix set but not nused variables which was used only for logging.
>
> s/nused/used
>
> s/which was/that were
>
> Otherwise
>
>
52 matches
Mail list logo
