Re: [PATCH v2 02/28] video: fbcon: Fix warnings by using pr_debug() in fbcon
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 > > > being printed > > > when FBCONDEBUG is defined. Is such change what the author of this module > > > expects? > > > > When someone goes and enable DEBUG for fbcon they are also able to > > recognize the logging, so the printing of the function name is redundant > > in this case. > > > > There is likely limited to no use for these few logging entries, but if > > they should be dropped then I expect Peilin Ye to do so as he is the > > only one doing active maintenance of fbcon lately. > > Sure, I will take another look at them. Also sorry for the delay in that > printk() -> dev_*() patch you suggested, overwhelmed by some other > things this week. Sometimes fbcon.c accesses dev structs in a pretty > weird way (e.g. registered_fb[con2fb_map[vc->vc_num]]->dev), I will get > back to it when I understand this better. Please just keep up the good work cleaning up fbcon and related stuff. This is an area that needs some love and care and there is work for many long nights yet to do. Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/kmb: Fix possible oops in probe error handling
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 ;
> > Daniel Vetter ; Sam Ravnborg ; dri-
> > de...@lists.freedesktop.org; kernel-janit...@vger.kernel.org
> > Subject: [PATCH v2] drm/kmb: Fix possible oops in probe error handling
> >
> > If kmb_dsi_init() fails the "kmb->kmb_dsi" variable is an error pointer.
> > The kernel will Oops when we pass it to kmb_dsi_host_unregister().
> >
> > Fixes: 7f7b96a8a0a1 ("drm/kmb: Add support for KeemBay Display")
> > Signed-off-by: Dan Carpenter
> > ---
> > v2: write a better commit message
> >
> > drivers/gpu/drm/kmb/kmb_drv.c | 5 +++--
> > 1 file changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/kmb/kmb_drv.c
> > b/drivers/gpu/drm/kmb/kmb_drv.c
> > index a31a840ce634..8c43b136765c 100644
> > --- a/drivers/gpu/drm/kmb/kmb_drv.c
> > +++ b/drivers/gpu/drm/kmb/kmb_drv.c
> > @@ -504,7 +504,7 @@ static int kmb_probe(struct platform_device *pdev)
> > if (IS_ERR(kmb->kmb_dsi)) {
> > drm_err(>drm, "failed to initialize DSI\n");
> > ret = PTR_ERR(kmb->kmb_dsi);
> > - goto err_free1;
> > + goto err_clear_drvdata;
> > }
> >
> > kmb->kmb_dsi->dev = _pdev->dev;
> > @@ -540,8 +540,9 @@ static int kmb_probe(struct platform_device *pdev)
> > drm_crtc_cleanup(>crtc);
> > drm_mode_config_cleanup(>drm);
> > err_free1:
> > - dev_set_drvdata(dev, NULL);
> > kmb_dsi_host_unregister(kmb->kmb_dsi);
> > + err_clear_drvdata:
> We still need to unregister the dsi_host that was registered in this call
> kmb_dsi_host_bridge_init.
> This will require more changes in kmb_dsi_host_unregister and/or separate out
> mipi_dsi_host_unregister.
> FYI - I will be out all of next week, will be back the next Monday.
Hm... Yes. Now that you point it out, there are several bugs related
to kmb_dsi_host_bridge_init()...
182 void kmb_dsi_host_unregister(struct kmb_dsi *kmb_dsi)
183 {
184 kmb_dsi_clk_disable(kmb_dsi);
185 mipi_dsi_host_unregister(kmb_dsi->host);
^
kmb_dsi->host is dsi_host.
Every user unregisters it, but only the first user registers it. So
if there are multiple users it will be unregistered prematurely. Should
there be a kfree to prevent a leak?
kfree(kmb_dsi->host);
dsi_host = NULL;
186 }
[ snip ]
216 int kmb_dsi_host_bridge_init(struct device *dev)
217 {
218 struct device_node *encoder_node, *dsi_out;
219
220 /* Create and register MIPI DSI host */
221 if (!dsi_host) {
This is only allocated for the first user.
222 dsi_host = kzalloc(sizeof(*dsi_host), GFP_KERNEL);
223 if (!dsi_host)
224 return -ENOMEM;
225
226 dsi_host->ops = _dsi_host_ops;
227
228 if (!dsi_device) {
229 dsi_device = kzalloc(sizeof(*dsi_device),
GFP_KERNEL);
230 if (!dsi_device) {
231 kfree(dsi_host);
^^^
But now it is non-NULL but it is a freed pointer. dsi_host = NULL;
232 return -ENOMEM;
233 }
234 }
235
236 dsi_host->dev = dev;
237 mipi_dsi_host_register(dsi_host);
238 }
239
[ snip ]
482
483 of_node_put(dsi_in);
484 of_node_put(dsi_node);
485 ret = kmb_dsi_host_bridge_init(get_device(_pdev->dev));
^^
This get_device() needs a matching put_device(). I kind of like to put
the kref_get() calls on their own line so that they're more obvious to
the reader.
get_device(_pdev->dev);
kmb_dsi_host_bridge_init(_pdev->dev);
486
487 if (ret == -EPROBE_DEFER) {
488 return -EPROBE_DEFER;
489 } else if (ret) {
490 DRM_ERROR("probe failed to initialize DSI host
bridge\n");
491 return ret;
492 }
493
494 /* Create DRM device */
495 kmb = devm_drm_dev_alloc(dev, _driver,
496 struct kmb_drm_private, drm);
497 if (IS_ERR(kmb))
498 return PTR_ERR(kmb);
On these error paths we would want to unwind using a call to
kmb_dsi_host_unregister().
499
500 dev_set_drvdata(dev, >drm);
501
502 /* Initialize MIPI DSI */
503
Re: [PATCH v2 02/28] video: fbcon: Fix warnings by using pr_debug() in fbcon
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 this module > > expects? > > When someone goes and enable DEBUG for fbcon they are also able to > recognize the logging, so the printing of the function name is redundant > in this case. > > There is likely limited to no use for these few logging entries, but if > they should be dropped then I expect Peilin Ye to do so as he is the > only one doing active maintenance of fbcon lately. Sure, I will take another look at them. Also sorry for the delay in that printk() -> dev_*() patch you suggested, overwhelmed by some other things this week. Sometimes fbcon.c accesses dev structs in a pretty weird way (e.g. registered_fb[con2fb_map[vc->vc_num]]->dev), I will get back to it when I understand this better. Thanks, Peilin Ye ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] Revert "i2c: qcom-geni: Disable DMA processing on the Lenovo Yoga C630"
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 processing on the Lenovo Yoga C630")'.
>
> Signed-off-by: Bjorn Andersson
Acked-by: Shawn Guo
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: (subset) [PATCH v5 0/7] Enable rk3066a HDMI sound
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 sound in the HDMI driver. > Add a simple-sound-card compatible node to rk3066a.dtsi, > because I2S0 and HDMI TX are connected internally. > And as last enable rk3066a HDMI sound in the rk3066a-mk808.dts file. > > [...] Applied, thanks! [1/7] clk: rockchip: add CLK_SET_RATE_PARENT to sclk for rk3066a i2s and uart clocks commit: 5868491e1257786628fdd2457dfb77609f49f91d [2/7] clk: rockchip: fix i2s gate bits on rk3066 and rk3188 commit: caa2fd752ecb80faf7a2e1cdadc737187934675e Best regards, -- Heiko Stuebner ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 02/28] video: fbcon: Fix warnings by using pr_debug() in fbcon
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 development. Anyway, I > never liked these kinds of hacks. > > Acked-by: Thomas Zimmermann > But replacing printk(KERN_DEBUG) with pr_debug() prevents __func__ from being printed when FBCONDEBUG is defined. Is such change what the author of this module expects? ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/panel: sony-acx565akm: Fix race condition in probe
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 the probe
routine was called, there is only a very short time period of a few
instructions where the reset signal is LOW. Exact time depends on
compiler optimizations, kernel configuration and alignment of the stars,
but I expect it to be always way less than 10us. There are no public
datasheets for the panel, but acx565akm_power_on() has a comment with
timings and reset period should be at least 10us. So this potentially
brings the panel into a half-reset state.
The result is, that panel may not work after boot and can get into a
working state by re-enabling it (e.g. by blanking + unblanking), since
that does a clean reset cycle. This bug has recently been hit by Ivaylo
Dimitrov, but there are some older reports which are probably the same
bug. At least Tony Lindgren, Peter Ujfalusi and Jarkko Nikula have
experienced it in 2017 describing the blank/unblank procedure as
possible workaround.
Note, that the bug really goes back in time. It has originally been
introduced in the predecessor of the omapfb driver in 3c45d05be382
("OMAPDSS: acx565akm panel: handle gpios in panel driver") in 2012.
That driver eventually got replaced by a newer one, which had the bug
from the beginning in 84192742d9c2 ("OMAPDSS: Add Sony ACX565AKM panel
driver") and still exists in fbdev world. That driver has later been
copied to omapdrm and then was used as a basis for this driver. Last
but not least the omapdrm specific driver has been removed in
45f16c82db7e ("drm/omap: displays: Remove unused panel drivers").
Reported-by: Jarkko Nikula
Reported-by: Peter Ujfalusi
Reported-by: Tony Lindgren
Reported-by: Aaro Koskinen
Reported-by: Ivaylo Dimitrov
Cc: Merlijn Wajer
Cc: Laurent Pinchart
Cc: Tomi Valkeinen
Fixes: 1c8fc3f0c5d2 ("drm/panel: Add driver for the Sony ACX565AKM panel")
Signed-off-by: Sebastian Reichel
---
drivers/gpu/drm/panel/panel-sony-acx565akm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panel/panel-sony-acx565akm.c
b/drivers/gpu/drm/panel/panel-sony-acx565akm.c
index e95fdfb16b6c..ba0b3ead150f 100644
--- a/drivers/gpu/drm/panel/panel-sony-acx565akm.c
+++ b/drivers/gpu/drm/panel/panel-sony-acx565akm.c
@@ -629,7 +629,7 @@ static int acx565akm_probe(struct spi_device *spi)
lcd->spi = spi;
mutex_init(>mutex);
- lcd->reset_gpio = devm_gpiod_get(>dev, "reset", GPIOD_OUT_LOW);
+ lcd->reset_gpio = devm_gpiod_get(>dev, "reset", GPIOD_OUT_HIGH);
if (IS_ERR(lcd->reset_gpio)) {
dev_err(>dev, "failed to get reset GPIO\n");
return PTR_ERR(lcd->reset_gpio);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 00/17] follow_pfn and other iomap races
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): > drm/exynos: Stop using frame_vector helpers > drm/exynos: Use FOLL_LONGTERM for g2d cmdlists > misc/habana: Stop using frame_vector helpers > misc/habana: Use FOLL_LONGTERM for userptr > mm/frame-vector: Use FOLL_LONGTERM > media: videobuf2: Move frame_vector into media subsystem At the very least it would be good to get those in right away. > mm: Add unsafe_follow_pfn > media/videbuf1|2: Mark follow_pfn usage as unsafe > vfio/type1: Mark follow_pfn as unsafe I'm surprised nobody from VFIO has remarked on this, I think thety won't like it > mm: Close race in generic_access_phys > PCI: Obey iomem restrictions for procfs mmap > /dev/mem: Only set filp->f_mapping > resource: Move devmem revoke code to resource framework > sysfs: Support zapping of binary attr mmaps > PCI: Revoke mappings like devmem This sequence seems fairly stand alone, and in good shape as well My advice is to put the done things on a branch and get Stephen to put them in linux-next. You can send a PR to Lins. There is very little mm stuff in here, and cross subsystem stuff works better in git land, IMHO. Jason ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [REGRESSION] omapdrm/N900 display broken
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 one would be good too.
There's a omapdss
debugfs dir, with dss, dispc and clk files which are of interest here.
It turned out to be a long standing bug in the panel driver, with the
bellow fix it works fine:
diff --git a/drivers/gpu/drm/panel/panel-sony-acx565akm.c
b/drivers/gpu/drm/panel/panel-sony-acx565akm.c
index fc6a7e451abe..304267f7849a
--- a/drivers/gpu/drm/panel/panel-sony-acx565akm.c
+++ b/drivers/gpu/drm/panel/panel-sony-acx565akm.c
@@ -629,7 +629,7 @@ static int acx565akm_probe(struct spi_device *spi)
lcd->spi = spi;
mutex_init(>mutex);
- lcd->reset_gpio = devm_gpiod_get(>dev, "reset", GPIOD_OUT_LOW);
+ lcd->reset_gpio = devm_gpiod_get(>dev, "reset",
GPIOD_OUT_HIGH);
if (IS_ERR(lcd->reset_gpio)) {
dev_err(>dev, "failed to get reset GPIO\n");
return PTR_ERR(lcd->reset_gpio);
Proper patch will follow.
Thanks,
Ivo
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 16/28] video: fbdev: hgafb: Fix kernel-doc warnings
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 insertions(+), 2 deletions(-) > > diff --git a/drivers/video/fbdev/hgafb.c b/drivers/video/fbdev/hgafb.c > index a45fcff1461f..69af72937844 100644 > --- a/drivers/video/fbdev/hgafb.c > +++ b/drivers/video/fbdev/hgafb.c > @@ -358,7 +358,7 @@ static int hga_card_detect(void) > /** > * hgafb_open - open the framebuffer device > * @info:pointer to fb_info object containing info for current hga board > - * @int:open by console system or userland. > + * @init:open by console system or userland. Please add a space after the ':' in 2 lines above. > */ > > static int hgafb_open(struct fb_info *info, int init) > @@ -372,7 +372,7 @@ static int hgafb_open(struct fb_info *info, int init) > /** > * hgafb_open - open the framebuffer device > * @info:pointer to fb_info object containing info for current hga board > - * @int:open by console system or userland. > + * @init:open by console system or userland. Same here (2 lines). > */ > > static int hgafb_release(struct fb_info *info, int init) > thanks. -- ~Randy ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/vkms: detect modes during output initialization
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 of modes and encoders - but is much faster.
This performance improvement is the reason why userspace applications
may prefer to use drmGetConnectorCurrent() when they need to retrieve
information from a device. The problem is that until now VKMS used to
init its output with an encoder, but without any valid mode, so
these userspace applications would not be able to use VKMS.
Call drm_helper_probe_single_connector_modes() during VKMS output
initialization in order to start with the set of all valid modes.
Signed-off-by: Leandro Ribeiro
---
drivers/gpu/drm/vkms/vkms_output.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/vkms/vkms_output.c
b/drivers/gpu/drm/vkms/vkms_output.c
index 4a1848b0318f..20343592d38a 100644
--- a/drivers/gpu/drm/vkms/vkms_output.c
+++ b/drivers/gpu/drm/vkms/vkms_output.c
@@ -80,6 +80,12 @@ int vkms_output_init(struct vkms_device *vkmsdev, int index)
goto err_attach;
}
+ ret = drm_helper_probe_single_connector_modes(connector, XRES_MAX,
YRES_MAX);
+ if (ret == 0) {
+ DRM_ERROR("Failed to get modes for connector\n");
+ goto err_attach;
+ }
+
ret = vkms_enable_writeback_connector(vkmsdev);
if (ret)
DRM_ERROR("Failed to init writeback connector\n");
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/omap: sdi: fix bridge enable/disable
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: 0 PID: 18 at drivers/gpu/drm/drm_bridge.c:708
> drm_atomic_helper_commit_modeset_enables+0x134/0x268
>
> and display not working.
>
> Fix this by using the legacy enable/disable funcs.
>
> Signed-off-by: Tomi Valkeinen
> Reported-by: Aaro Koskinen
> Fixes: 8bef8a6d5da81b909a190822b96805a47348146f ("drm/omap: sdi: Register a
> drm_bridge")
> Cc: sta...@vger.kernel.org # v5.7+
> Tested-by: Ivaylo Dimitrov
Tested-by: Aaro Koskinen
Thanks,
A.
> ---
> drivers/gpu/drm/omapdrm/dss/sdi.c | 10 --
> 1 file changed, 4 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/omapdrm/dss/sdi.c
> b/drivers/gpu/drm/omapdrm/dss/sdi.c
> index 033fd30074b0..282e4c837cd9 100644
> --- a/drivers/gpu/drm/omapdrm/dss/sdi.c
> +++ b/drivers/gpu/drm/omapdrm/dss/sdi.c
> @@ -195,8 +195,7 @@ static void sdi_bridge_mode_set(struct drm_bridge *bridge,
> sdi->pixelclock = adjusted_mode->clock * 1000;
> }
>
> -static void sdi_bridge_enable(struct drm_bridge *bridge,
> - struct drm_bridge_state *bridge_state)
> +static void sdi_bridge_enable(struct drm_bridge *bridge)
> {
> struct sdi_device *sdi = drm_bridge_to_sdi(bridge);
> struct dispc_clock_info dispc_cinfo;
> @@ -259,8 +258,7 @@ static void sdi_bridge_enable(struct drm_bridge *bridge,
> regulator_disable(sdi->vdds_sdi_reg);
> }
>
> -static void sdi_bridge_disable(struct drm_bridge *bridge,
> -struct drm_bridge_state *bridge_state)
> +static void sdi_bridge_disable(struct drm_bridge *bridge)
> {
> struct sdi_device *sdi = drm_bridge_to_sdi(bridge);
>
> @@ -278,8 +276,8 @@ static const struct drm_bridge_funcs sdi_bridge_funcs = {
> .mode_valid = sdi_bridge_mode_valid,
> .mode_fixup = sdi_bridge_mode_fixup,
> .mode_set = sdi_bridge_mode_set,
> - .atomic_enable = sdi_bridge_enable,
> - .atomic_disable = sdi_bridge_disable,
> + .enable = sdi_bridge_enable,
> + .disable = sdi_bridge_disable,
> };
>
> static void sdi_bridge_init(struct sdi_device *sdi)
> --
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/vkms: detect modes during output initialization
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, while the latter only retrieves the
> currently known set of modes and encoders - but is much faster.
>
> This performance improvement is the reason why userspace applications
> may prefer to use drmGetConnectorCurrent() when they need to retrieve
> information from a device. The problem is that until now VKMS used to
> init its output with an encoder, but without any valid mode, so
> these userspace applications would not be able to use VKMS.
>
> Call drm_helper_probe_single_connector_modes() during VKMS output
> initialization in order to start with the set of all valid modes.
>
> Signed-off-by: Leandro Ribeiro
> ---
> drivers/gpu/drm/vkms/vkms_output.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/gpu/drm/vkms/vkms_output.c
> b/drivers/gpu/drm/vkms/vkms_output.c
> index 4a1848b0318f..20343592d38a 100644
> --- a/drivers/gpu/drm/vkms/vkms_output.c
> +++ b/drivers/gpu/drm/vkms/vkms_output.c
> @@ -80,6 +80,12 @@ int vkms_output_init(struct vkms_device *vkmsdev, int
> index)
> goto err_attach;
> }
>
> + ret = drm_helper_probe_single_connector_modes(connector, XRES_MAX,
> YRES_MAX);
> + if (ret == 0) {
> + DRM_ERROR("Failed to get modes for connector\n");
> + goto err_attach;
> + }
> +
> ret = vkms_enable_writeback_connector(vkmsdev);
> if (ret)
> DRM_ERROR("Failed to init writeback connector\n");
>
After this patch we start to receive the warning from
drivers/gpu/drm/drm_modes.c:110
Thanks,
Leandro Ribeiro.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [BUG] drm/vkms: Failure when using drmGetConnectorCurrent()
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 https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/518 Unfortunately this is not working when we use VKMS (upstream version tested). Please see https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/518#note_700345 I guess this is without fbdev configured on vkms? That's what usually papers over this problem for most drivers. Yes, without fbdev configured. for more information, and feel free to jump into the discussion. If there's more helpful information that I can share, please let me know. Like Simon suggested, please submit that patch you have for discussion. -Daniel Sure, I'll submit the patch. Thank you, Leandro Ribeiro. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [REGRESSION] omapdrm/N900 display broken
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 the issue? I tried 5.9.1 and still nothing displayed. Can you test the attached patch? With this patch I don't see oops that Aaro reported, so: Tested-by: Ivaylo Dimitrov Seems to fix the particular issue, however, now we get another oops. As this is not upstream kernel but one with PVR related patches, I will try again with vanilla 5.9. Just in case oops rings any bells (the line in question is https://github.com/maemo-leste/droid4-linux/blob/maemo-5.9/drivers/gpu/drm/omapdrm/omap_gem.c#L801) Do the PVR patches touch omapdrm? The call stack looks like normal boot time probing stuff, not something happening later (possibly from PVR). pvr driver is not even enabled in that particular config, however, I see "HACK: drm/omap: Add omapdrm plugin API" patch in the tree that touches omap-gem.c, I don't really want to just create some noise for problems that are created by out-of-tree patches. And yeah, it looks like a normal boot time probing stuff. As soon as I have some spare time (hopefully later today) I will try vanilla 5.9.x with omap2plus_defconfig and will report. 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. Thanks and regards, Ivo ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/ingenic: Add basic PM support
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 properly disabled when the hardware is put to sleep. Signed-off-by: Paul Cercueil As discussed on irc, with resume fixed to return the result of the drm_mode_config_helper_resume() call. Reviewed-by: Sam Ravnborg Applied with the fix, thanks. Cheers, -Paul ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [REGRESSION] omapdrm/N900 display broken
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. Can you test the attached patch? With this patch I don't see oops that Aaro reported, so: Tested-by: Ivaylo Dimitrov Seems to fix the particular issue, however, now we get another oops. As this is not upstream kernel but one with PVR related patches, I will try again with vanilla 5.9. Just in case oops rings any bells (the line in question is https://github.com/maemo-leste/droid4-linux/blob/maemo-5.9/drivers/gpu/drm/omapdrm/omap_gem.c#L801) Do the PVR patches touch omapdrm? The call stack looks like normal boot time probing stuff, not something happening later (possibly from PVR). pvr driver is not even enabled in that particular config, however, I see "HACK: drm/omap: Add omapdrm plugin API" patch in the tree that touches omap-gem.c, I don't really want to just create some noise for problems that are created by out-of-tree patches. And yeah, it looks like a normal boot time probing stuff. As soon as I have some spare time (hopefully later today) I will try vanilla 5.9.x with omap2plus_defconfig and will report. Ivo ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/mediatek: Use correct aliases name for ovl
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: add component OVL_2L0")
Signed-off-by: Enric Balletbo i Serra
---
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
index 8eba44be3a8a..3064eac1a750 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
@@ -359,7 +359,7 @@ static const struct mtk_ddp_comp_funcs ddp_ufoe = {
static const char * const mtk_ddp_comp_stem[MTK_DDP_COMP_TYPE_MAX] = {
[MTK_DISP_OVL] = "ovl",
- [MTK_DISP_OVL_2L] = "ovl_2l",
+ [MTK_DISP_OVL_2L] = "ovl-2l",
[MTK_DISP_RDMA] = "rdma",
[MTK_DISP_WDMA] = "wdma",
[MTK_DISP_COLOR] = "color",
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/panel: feiyang-fy07024di26a30d: cleanup if panel attaching failed
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
---
drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c
b/drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c
index 581661b506f8..f9c1f7bc8218 100644
--- a/drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c
+++ b/drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c
@@ -227,7 +227,13 @@ static int feiyang_dsi_probe(struct mipi_dsi_device *dsi)
dsi->format = MIPI_DSI_FMT_RGB888;
dsi->lanes = 4;
- return mipi_dsi_attach(dsi);
+ ret = mipi_dsi_attach(dsi);
+ if (ret < 0) {
+ drm_panel_remove(>panel);
+ return ret;
+ }
+
+ return 0;
}
static int feiyang_dsi_remove(struct mipi_dsi_device *dsi)
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/panel: sony-acx565akm: Fix race condition in probe
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 initialized the GPIO to HIGH before the probe
>> routine was called, there is only a very short time period of a few
>> instructions where the reset signal is LOW. Exact time depends on
>> compiler optimizations, kernel configuration and alignment of the stars,
>> but I expect it to be always way less than 10us. There are no public
>> datasheets for the panel, but acx565akm_power_on() has a comment with
>> timings and reset period should be at least 10us. So this potentially
>> brings the panel into a half-reset state.
>>
>> The result is, that panel may not work after boot and can get into a
>> working state by re-enabling it (e.g. by blanking + unblanking), since
>> that does a clean reset cycle. This bug has recently been hit by Ivaylo
>> Dimitrov, but there are some older reports which are probably the same
>> bug. At least Tony Lindgren, Peter Ujfalusi and Jarkko Nikula have
>> experienced it in 2017 describing the blank/unblank procedure as
>> possible workaround.
>>
>> Note, that the bug really goes back in time. It has originally been
>> introduced in the predecessor of the omapfb driver in 3c45d05be382
>> ("OMAPDSS: acx565akm panel: handle gpios in panel driver") in 2012.
>> That driver eventually got replaced by a newer one, which had the bug
>> from the beginning in 84192742d9c2 ("OMAPDSS: Add Sony ACX565AKM panel
>> driver") and still exists in fbdev world. That driver has later been
>> copied to omapdrm and then was used as a basis for this driver. Last
>> but not least the omapdrm specific driver has been removed in
>> 45f16c82db7e ("drm/omap: displays: Remove unused panel drivers").
>>
>> Reported-by: Jarkko Nikula
>> Reported-by: Peter Ujfalusi
>> Reported-by: Tony Lindgren
>> Reported-by: Aaro Koskinen
>> Reported-by: Ivaylo Dimitrov
>> Cc: Merlijn Wajer
>> Cc: Laurent Pinchart
>> Cc: Tomi Valkeinen
>> Fixes: 1c8fc3f0c5d2 ("drm/panel: Add driver for the Sony ACX565AKM panel")
>> Signed-off-by: Sebastian Reichel
>
> Tested-by: Aaro Koskinen
>
I had difficulties with recent kernels. Yesterday's vanilla head
c84e1efae022 and linux-next next-20201127 didn't boot, v5.9.11 had some
other DRM issues. I went back to v5.4.80 which didn't show this panel
issue and was actually working fine. Strange since obviously issue exist
before.
But v5.6.19 was testable, had the issue and this patch fixed it, so
Tested-by: Jarkko Nikula
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/panel: sony-acx565akm: Fix race condition in probe
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 was called, there is only a very short time period of a few
> instructions where the reset signal is LOW. Exact time depends on
> compiler optimizations, kernel configuration and alignment of the stars,
> but I expect it to be always way less than 10us. There are no public
> datasheets for the panel, but acx565akm_power_on() has a comment with
> timings and reset period should be at least 10us. So this potentially
> brings the panel into a half-reset state.
>
> The result is, that panel may not work after boot and can get into a
> working state by re-enabling it (e.g. by blanking + unblanking), since
> that does a clean reset cycle. This bug has recently been hit by Ivaylo
> Dimitrov, but there are some older reports which are probably the same
> bug. At least Tony Lindgren, Peter Ujfalusi and Jarkko Nikula have
> experienced it in 2017 describing the blank/unblank procedure as
> possible workaround.
>
> Note, that the bug really goes back in time. It has originally been
> introduced in the predecessor of the omapfb driver in 3c45d05be382
> ("OMAPDSS: acx565akm panel: handle gpios in panel driver") in 2012.
> That driver eventually got replaced by a newer one, which had the bug
> from the beginning in 84192742d9c2 ("OMAPDSS: Add Sony ACX565AKM panel
> driver") and still exists in fbdev world. That driver has later been
> copied to omapdrm and then was used as a basis for this driver. Last
> but not least the omapdrm specific driver has been removed in
> 45f16c82db7e ("drm/omap: displays: Remove unused panel drivers").
>
> Reported-by: Jarkko Nikula
> Reported-by: Peter Ujfalusi
> Reported-by: Tony Lindgren
> Reported-by: Aaro Koskinen
> Reported-by: Ivaylo Dimitrov
> Cc: Merlijn Wajer
> Cc: Laurent Pinchart
> Cc: Tomi Valkeinen
> Fixes: 1c8fc3f0c5d2 ("drm/panel: Add driver for the Sony ACX565AKM panel")
> Signed-off-by: Sebastian Reichel
Tested-by: Aaro Koskinen
Thanks,
A.
> ---
> drivers/gpu/drm/panel/panel-sony-acx565akm.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/panel/panel-sony-acx565akm.c
> b/drivers/gpu/drm/panel/panel-sony-acx565akm.c
> index e95fdfb16b6c..ba0b3ead150f 100644
> --- a/drivers/gpu/drm/panel/panel-sony-acx565akm.c
> +++ b/drivers/gpu/drm/panel/panel-sony-acx565akm.c
> @@ -629,7 +629,7 @@ static int acx565akm_probe(struct spi_device *spi)
> lcd->spi = spi;
> mutex_init(>mutex);
>
> - lcd->reset_gpio = devm_gpiod_get(>dev, "reset", GPIOD_OUT_LOW);
> + lcd->reset_gpio = devm_gpiod_get(>dev, "reset", GPIOD_OUT_HIGH);
> if (IS_ERR(lcd->reset_gpio)) {
> dev_err(>dev, "failed to get reset GPIO\n");
> return PTR_ERR(lcd->reset_gpio);
> --
> 2.29.2
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/ingenic: Add basic PM support
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
1 file changed, 20 insertions(+)
diff --git a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
index 368bfef8b340..818a0e4f5bfe 100644
--- a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
+++ b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
#include
@@ -1167,6 +1168,24 @@ static int ingenic_drm_remove(struct platform_device
*pdev)
return 0;
}
+static int __maybe_unused ingenic_drm_suspend(struct device *dev)
+{
+ struct ingenic_drm *priv = dev_get_drvdata(dev);
+
+ return drm_mode_config_helper_suspend(>drm);
+}
+
+static int __maybe_unused ingenic_drm_resume(struct device *dev)
+{
+ struct ingenic_drm *priv = dev_get_drvdata(dev);
+
+ drm_mode_config_helper_resume(>drm);
+
+ return 0;
+}
+
+static SIMPLE_DEV_PM_OPS(ingenic_drm_pm_ops, ingenic_drm_suspend,
ingenic_drm_resume);
+
static const u32 jz4740_formats[] = {
DRM_FORMAT_XRGB1555,
DRM_FORMAT_RGB565,
@@ -1246,6 +1265,7 @@ MODULE_DEVICE_TABLE(of, ingenic_drm_of_match);
static struct platform_driver ingenic_drm_driver = {
.driver = {
.name = "ingenic-drm",
+ .pm = pm_ptr(_drm_pm_ops),
.of_match_table = of_match_ptr(ingenic_drm_of_match),
},
.probe = ingenic_drm_probe,
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/panel: sony-acx565akm: Fix race condition in probe
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 the reset signal is LOW. Exact time depends on
compiler optimizations, kernel configuration and alignment of the stars,
but I expect it to be always way less than 10us. There are no public
datasheets for the panel, but acx565akm_power_on() has a comment with
timings and reset period should be at least 10us. So this potentially
brings the panel into a half-reset state.
The result is, that panel may not work after boot and can get into a
working state by re-enabling it (e.g. by blanking + unblanking), since
that does a clean reset cycle. This bug has recently been hit by Ivaylo
Dimitrov, but there are some older reports which are probably the same
bug. At least Tony Lindgren, Peter Ujfalusi and Jarkko Nikula have
experienced it in 2017 describing the blank/unblank procedure as
possible workaround.
Note, that the bug really goes back in time. It has originally been
introduced in the predecessor of the omapfb driver in 3c45d05be382
("OMAPDSS: acx565akm panel: handle gpios in panel driver") in 2012.
That driver eventually got replaced by a newer one, which had the bug
from the beginning in 84192742d9c2 ("OMAPDSS: Add Sony ACX565AKM panel
driver") and still exists in fbdev world. That driver has later been
copied to omapdrm and then was used as a basis for this driver. Last
but not least the omapdrm specific driver has been removed in
45f16c82db7e ("drm/omap: displays: Remove unused panel drivers").
Reported-by: Jarkko Nikula
Reported-by: Peter Ujfalusi
Reported-by: Tony Lindgren
Reported-by: Aaro Koskinen
Reported-by: Ivaylo Dimitrov
Cc: Merlijn Wajer
Cc: Laurent Pinchart
Cc: Tomi Valkeinen
Fixes: 1c8fc3f0c5d2 ("drm/panel: Add driver for the Sony ACX565AKM panel")
Signed-off-by: Sebastian Reichel
---
drivers/gpu/drm/panel/panel-sony-acx565akm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panel/panel-sony-acx565akm.c
b/drivers/gpu/drm/panel/panel-sony-acx565akm.c
index e95fdfb16b6c..ba0b3ead150f 100644
--- a/drivers/gpu/drm/panel/panel-sony-acx565akm.c
+++ b/drivers/gpu/drm/panel/panel-sony-acx565akm.c
@@ -629,7 +629,7 @@ static int acx565akm_probe(struct spi_device *spi)
lcd->spi = spi;
mutex_init(>mutex);
- lcd->reset_gpio = devm_gpiod_get(>dev, "reset", GPIOD_OUT_LOW);
+ lcd->reset_gpio = devm_gpiod_get(>dev, "reset", GPIOD_OUT_HIGH);
if (IS_ERR(lcd->reset_gpio)) {
dev_err(>dev, "failed to get reset GPIO\n");
return PTR_ERR(lcd->reset_gpio);
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/panel: sony-acx565akm: Fix race condition in probe
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
> > > 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 the reset signal is LOW. Exact time depends on
> > > compiler optimizations, kernel configuration and alignment of the stars,
> > > but I expect it to be always way less than 10us. There are no public
> > > datasheets for the panel, but acx565akm_power_on() has a comment with
> > > timings and reset period should be at least 10us. So this potentially
> > > brings the panel into a half-reset state.
> >
> > Good catch.
> >
> > Looks like we got the reset polarity wrong in the driver though.
> > GPIOD_OUT_LOW should mean de-asserted, but the driver expects it to mean
> > low level. We can't fix that as it would require changing the device
> > tree :-(
>
> Yes, polarity is wrong unfortunately.
>
> > > The result is, that panel may not work after boot and can get into a
> > > working state by re-enabling it (e.g. by blanking + unblanking), since
> > > that does a clean reset cycle. This bug has recently been hit by Ivaylo
> > > Dimitrov, but there are some older reports which are probably the same
> > > bug. At least Tony Lindgren, Peter Ujfalusi and Jarkko Nikula have
> > > experienced it in 2017 describing the blank/unblank procedure as
> > > possible workaround.
> > >
> > > Note, that the bug really goes back in time. It has originally been
> > > introduced in the predecessor of the omapfb driver in 3c45d05be382
> > > ("OMAPDSS: acx565akm panel: handle gpios in panel driver") in 2012.
> > > That driver eventually got replaced by a newer one, which had the bug
> > > from the beginning in 84192742d9c2 ("OMAPDSS: Add Sony ACX565AKM panel
> > > driver") and still exists in fbdev world. That driver has later been
> > > copied to omapdrm and then was used as a basis for this driver. Last
> > > but not least the omapdrm specific driver has been removed in
> > > 45f16c82db7e ("drm/omap: displays: Remove unused panel drivers").
> > >
> > > Reported-by: Jarkko Nikula
> > > Reported-by: Peter Ujfalusi
> > > Reported-by: Tony Lindgren
> > > Reported-by: Aaro Koskinen
> > > Reported-by: Ivaylo Dimitrov
> > > Cc: Merlijn Wajer
> > > Cc: Laurent Pinchart
> > > Cc: Tomi Valkeinen
> > > Fixes: 1c8fc3f0c5d2 ("drm/panel: Add driver for the Sony ACX565AKM panel")
> > > Signed-off-by: Sebastian Reichel
> > > ---
> > > drivers/gpu/drm/panel/panel-sony-acx565akm.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/panel/panel-sony-acx565akm.c
> > > b/drivers/gpu/drm/panel/panel-sony-acx565akm.c
> > > index e95fdfb16b6c..ba0b3ead150f 100644
> > > --- a/drivers/gpu/drm/panel/panel-sony-acx565akm.c
> > > +++ b/drivers/gpu/drm/panel/panel-sony-acx565akm.c
> > > @@ -629,7 +629,7 @@ static int acx565akm_probe(struct spi_device *spi)
> > > lcd->spi = spi;
> > > mutex_init(>mutex);
> > >
> > > - lcd->reset_gpio = devm_gpiod_get(>dev, "reset", GPIOD_OUT_LOW);
> > > + lcd->reset_gpio = devm_gpiod_get(>dev, "reset", GPIOD_OUT_HIGH);
> >
> > Wouldn't it be better to instead add a delay here (or in
> > acx565akm_detect()) ? If the panel is in a wrong state at
> > boot time, a real reset can help.
>
> acx565akm_detect() reads some registers to detect a previously
> enabled panel and then driver handles this case properly. If we
> reset the panel before the detection code, any detection code
> would be useless (panel is obviously not enabled after a reset).
>
> I think this detection code is only needed to avoid flickering
> when a bootsplash is shown. So by accepting a bit of flickering
> we can simplify the driver by dropping that code and make it a
> bit more robust by doing a reset. It's a tradeoff and I don't
> have strong feelings for either option.
>
> But I think, that this fix should be applied to fixes branch
> (and backported to stable). Removing panel enable detection
> should not be applied as fix IMHO.
Agreed.
Reviewed-by: Laurent Pinchart
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 4/5] drm: panel: simple: Add BOE NV110WTM-N61
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 asserting and > the backlight power being turned on. We'll use the new timing > constraints structure to do this cleanly. This assumes that the > backlight will be enabled _after_ the panel enable finishes. This is > how it works today and seems a sane assumption. > > Signed-off-by: Douglas Anderson I applied the binding patch (bindings before driver patch), and added the missing flags while applying this patch. All to drm-misc-next. Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 3/5] drm: panel: simple: Allow specifying the delay from prepare to enable
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 training is allowed to happen in parallel with this delay so the > fixed 80 ms delay over-delays. > > We'll support this by logging the time at the end of prepare and then > delaying in enable if enough time hasn't passed. > > Signed-off-by: Douglas Anderson Applied too. Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 2/5] drm: panel: simple: Defer unprepare delay till next prepare to shorten it
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 > allow the panel to fully power off so that we don't try to power it > back on before it's managed to full power down. > > Let's use this observation to avoid the fixed delay that we currently > have. Instead of delaying, we'll note the current time when the > unprepare happens. If someone then tries to prepare the panel later > and not enough time has passed, we'll do the delay before starting the > prepare phase. > > Signed-off-by: Douglas Anderson Applied to drm-misc-next. Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 1/5] drm: panel: simple: Fixup the struct panel_desc kernel doc
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 that > and also move to inline kernel docs. > > Signed-off-by: Douglas Anderson Thanks, applied to drm-misc-next. Could you do a follow-up patch that moves the rest as inline comments and verify that all fields are described. (W=1 should show no warnings). That would be appreciated! Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/kmb: Remove an unnecessary NULL check
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 ; > > kernel-janit...@vger.kernel.org; dri-devel@lists.freedesktop.org; Dan > > Carpenter > > Subject: Re: [PATCH] drm/kmb: Remove an unnecessary NULL check > > > > Hi > > > > Am 20.11.20 um 09:21 schrieb Sam Ravnborg: > > > Hi Anitha. > > > > > > On Fri, Nov 20, 2020 at 01:19:06AM +, Chrisanthus, Anitha wrote: > > >> Looks good to me. > > > > > > Can we get either an "Acked-by:" or "Reviewed-by:"? > > > Then we can use this while applying. > Sorry, forgot that. > Reviewed-by: Anitha Chrisanthus Thanks, patch is now pushed to drm-misc-next. Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] drm/ingenic: Add support for delta-RGB panels
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 subpixel ordering. > > Such panel is used in the YLM (aka. Anbernic) RG-99, RG-300, RG-280M > and RG-280V handheld gaming consoles. > > Cheers, > -Paul > > Paul Cercueil (3): > drm/ingenic: Compute timings according to adjusted_mode->crtc_* > drm/ingenic: Properly compute timings when using a 3x8-bit panel > drm/ingenic: Add support for serial 8-bit delta-RGB panels Strange panel, at least strange bit order. Patches looks good and are all: Reviewed-by: Sam Ravnborg ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] omapfb: fbcon: remove trailing semicolon in macro definition
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 dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 28/28] video: fbdev: s1d13xxxfb: Fix kernel-doc and set but not used warnings
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 > > Reviewed-by: Thomas Zimmermann Fixed and applied to drm-misc-next. Thanks for the a-b's and r-b. Are you up to take a look at the remaining 24 patches? It is all simple patches so should be doable in limited time. Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 02/28] video: fbcon: Fix warnings by using pr_debug() in fbcon
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 (Joe) > > > > Signed-off-by: Sam Ravnborg > > Cc: Joe Perches > > Cc: Greg Kroah-Hartman > > Cc: Daniel Vetter > > Cc: Bartlomiej Zolnierkiewicz > > Cc: Sam Ravnborg > > Cc: Jiri Slaby > > Cc: Peilin Ye > > Cc: Tetsuo Handa > > Cc: George Kennedy > > Cc: Nathan Chancellor > > Cc: Peter Rosin > > --- > > drivers/video/fbdev/core/fbcon.c | 25 - > > 1 file changed, 8 insertions(+), 17 deletions(-) > > > > diff --git a/drivers/video/fbdev/core/fbcon.c > > b/drivers/video/fbdev/core/fbcon.c > > index bf61598bf1c3..44a5cd2f54cc 100644 > > --- a/drivers/video/fbdev/core/fbcon.c > > +++ b/drivers/video/fbdev/core/fbcon.c > > @@ -56,8 +56,6 @@ > >* more details. > >*/ > > -#undef FBCONDEBUG > > - > > I guess this was added for quick debugging during development. Anyway, I > never liked these kinds of hacks. > > Acked-by: Thomas Zimmermann Thanks, applied to drm-misc-next. Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 01/28] video: Fix kernel-doc warnings in of_display_timing + of_videomode
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 out. Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/panel: sony-acx565akm: Fix race condition in probe
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
> routine was called, there is only a very short time period of a few
> instructions where the reset signal is LOW. Exact time depends on
> compiler optimizations, kernel configuration and alignment of the stars,
> but I expect it to be always way less than 10us. There are no public
> datasheets for the panel, but acx565akm_power_on() has a comment with
> timings and reset period should be at least 10us. So this potentially
> brings the panel into a half-reset state.
>
> The result is, that panel may not work after boot and can get into a
> working state by re-enabling it (e.g. by blanking + unblanking), since
> that does a clean reset cycle. This bug has recently been hit by Ivaylo
> Dimitrov, but there are some older reports which are probably the same
> bug. At least Tony Lindgren, Peter Ujfalusi and Jarkko Nikula have
> experienced it in 2017 describing the blank/unblank procedure as
> possible workaround.
>
> Note, that the bug really goes back in time. It has originally been
> introduced in the predecessor of the omapfb driver in 3c45d05be382
> ("OMAPDSS: acx565akm panel: handle gpios in panel driver") in 2012.
> That driver eventually got replaced by a newer one, which had the bug
> from the beginning in 84192742d9c2 ("OMAPDSS: Add Sony ACX565AKM panel
> driver") and still exists in fbdev world. That driver has later been
> copied to omapdrm and then was used as a basis for this driver. Last
> but not least the omapdrm specific driver has been removed in
> 45f16c82db7e ("drm/omap: displays: Remove unused panel drivers").
>
> Reported-by: Jarkko Nikula
> Reported-by: Peter Ujfalusi
> Reported-by: Tony Lindgren
> Reported-by: Aaro Koskinen
> Reported-by: Ivaylo Dimitrov
> Cc: Merlijn Wajer
> Cc: Laurent Pinchart
> Cc: Tomi Valkeinen
> Fixes: 1c8fc3f0c5d2 ("drm/panel: Add driver for the Sony ACX565AKM panel")
> Signed-off-by: Sebastian Reichel
Fixed up the commit references, added Tested-by (impressive list) and
committed to drm-misc-fixes.
Commit references shall look like this:
commit 84192742d9c2 ("OMAPDSS: Add Sony ACX565AKM panel driver")
The word commit is required according to dim (the tool we use for
drm-misc maintenance).
Sam
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/kmb: fix array bounds warning
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 'struct layer_status[1]' [-Warray-bounds]
128 | kmb->plane_status[plane_id].ctrl = LCD_CTRL_GL2_ENABLE;
| ~^~
drivers/gpu/drm/kmb/kmb_plane.c:125:20: warning: array subscript 2 is above
array bounds of 'struct layer_status[1]' [-Warray-bounds]
125 | kmb->plane_status[plane_id].ctrl = LCD_CTRL_GL1_ENABLE;
| ~^~
drivers/gpu/drm/kmb/kmb_plane.c:122:20: warning: array subscript 1 is above
array bounds of 'struct layer_status[1]' [-Warray-bounds]
122 | kmb->plane_status[plane_id].ctrl = LCD_CTRL_VL2_ENABLE;
Having the array truncated to one entry seems intentional, so add
a range check before indexing it to make it clearer what is going
on and shut up the warning.
I received the warning from the kernel test robot after a private
patch that turns on Warray-bounds unconditionally.
Fixes: 7f7b96a8a0a1 ("drm/kmb: Add support for KeemBay Display")
Reported-by: kernel test robot
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/kmb/kmb_plane.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/kmb/kmb_plane.c b/drivers/gpu/drm/kmb/kmb_plane.c
index 8448d1edb553..be8eea3830c1 100644
--- a/drivers/gpu/drm/kmb/kmb_plane.c
+++ b/drivers/gpu/drm/kmb/kmb_plane.c
@@ -114,6 +114,9 @@ static void kmb_plane_atomic_disable(struct drm_plane
*plane,
kmb = to_kmb(plane->dev);
+ if (WARN_ON(plane_id >= KMB_MAX_PLANES))
+ return;
+
switch (plane_id) {
case LAYER_0:
kmb->plane_status[plane_id].ctrl = LCD_CTRL_VL1_ENABLE;
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 210415] [amdgpu] constant GPU hangs followed by kernel "BUG" and following kernel oops
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 of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 210415] [amdgpu] constant GPU hangs followed by kernel "BUG" and following kernel oops
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 assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 210415] [amdgpu] constant GPU hangs followed by kernel "BUG" and following kernel oops
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 GAMING X. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 210415] New: [amdgpu] constant GPU hangs followed by kernel "BUG" and following kernel oops
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: x86-64 OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-...@kernel-bugs.osdl.org Reporter: david.alejandro.ru...@gmail.com Regression: No Created attachment 293863 --> https://bugzilla.kernel.org/attachment.cgi?id=293863=edit dmesg output I have an RX 480. Every few hours after kernel 5.4 (!) I've been getting random GPU hangs, and after kernel 5.9, they became not only more frequent, but afterwards the kernel sent messages like Nov 29 15:44:31 reimu kernel: [drm] Bailing on TDR for s_job:34a, as another already in progress Nov 29 15:44:31 reimu kernel: BUG: kernel NULL pointer dereference, address: 0020 Nov 29 15:44:31 reimu kernel: #PF: supervisor write access in kernel mode Nov 29 15:44:31 reimu kernel: #PF: error_code(0x0002) - not-present page And an Oops right afterwards Oops: 0002 [#2] PREEMPT SMP NOPTI The full dmesg is attached. Kernel is compiled with Archlinux kernel preferences, but using a kernel directly from kernel.org and compiled with the modules I need give me the same error. Attached error. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RESEND PATCH v2 4/5] drm/msm: add DRM_MSM_GEM_SYNC_CACHE for non-coherent cache maintenance
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 looks like > >>> dma_sync_single_for_cpu() does deal in some way with the partial cache > >>> line > >>> case, although I'm not sure that means we can have a > >>> nonCoherentAtomSize=1. > >> > >> No, it doesn't. You need to ensure ownership is managed at > >> dma_get_cache_alignment() granularity. > > > > my guess is nonCoherentAtomSize=1 only works in the case of cache > > coherent buffers > > > > nonCoherentAtomSize doesn't apply to coherent memory (as the name > implies), I guess qcom's driver is just wrong about having > nonCoherentAtomSize=1. > > Jordan just mentioned there is at least one conformance test for this, I > wonder if it just doesn't test it well enough, or just doesn't test the > non-coherent memory type? I was *assuming* (but could be wrong) that Jordan was referring to an opencl cts test? At any rate, it is sounding like you should add a `MSM_PARAM_CACHE_ALIGNMENT` type of param that returns dma_get_cache_alignment(), and then properly implement offset/end BR, -R ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] msm/mdp5: Fix some kernel-doc warnings
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' > drivers/gpu/drm/msm/disp/mdp5/mdp5_ctl.c:227: warning: Function parameter or > member 'pipeline' not described in 'mdp5_ctl_set_encoder_state' > drivers/gpu/drm/msm/disp/mdp5/mdp5_ctl.c:227: warning: Function parameter or > member 'enabled' not described in 'mdp5_ctl_set_encoder_state' > drivers/gpu/drm/msm/disp/mdp5/mdp5_ctl.c:227: warning: Excess function > parameter 'enable' description in 'mdp5_ctl_set_encoder_state' > drivers/gpu/drm/msm/disp/mdp5/mdp5_ctl.c:529: warning: Function parameter or > member 'ctl' not described in 'mdp5_ctl_commit' > drivers/gpu/drm/msm/disp/mdp5/mdp5_ctl.c:529: warning: Function parameter or > member 'pipeline' not described in 'mdp5_ctl_commit' > drivers/gpu/drm/msm/disp/mdp5/mdp5_ctl.c:529: warning: Function parameter or > member 'flush_mask' not described in 'mdp5_ctl_commit' > drivers/gpu/drm/msm/disp/mdp5/mdp5_ctl.c:529: warning: Function parameter or > member 'start' not described in 'mdp5_ctl_commit' > > Cc: Lee Jones > Signed-off-by: Rob Clark Looks fine, Acked-by: Sam Ravnborg ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] msm/mdp5: Fix some kernel-doc warnings
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 'pipeline' not described in 'mdp5_ctl_set_encoder_state' drivers/gpu/drm/msm/disp/mdp5/mdp5_ctl.c:227: warning: Function parameter or member 'enabled' not described in 'mdp5_ctl_set_encoder_state' drivers/gpu/drm/msm/disp/mdp5/mdp5_ctl.c:227: warning: Excess function parameter 'enable' description in 'mdp5_ctl_set_encoder_state' drivers/gpu/drm/msm/disp/mdp5/mdp5_ctl.c:529: warning: Function parameter or member 'ctl' not described in 'mdp5_ctl_commit' drivers/gpu/drm/msm/disp/mdp5/mdp5_ctl.c:529: warning: Function parameter or member 'pipeline' not described in 'mdp5_ctl_commit' drivers/gpu/drm/msm/disp/mdp5/mdp5_ctl.c:529: warning: Function parameter or member 'flush_mask' not described in 'mdp5_ctl_commit' drivers/gpu/drm/msm/disp/mdp5/mdp5_ctl.c:529: warning: Function parameter or member 'start' not described in 'mdp5_ctl_commit' Cc: Lee Jones Signed-off-by: Rob Clark --- drivers/gpu/drm/msm/disp/mdp5/mdp5_ctl.c | 11 ++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_ctl.c b/drivers/gpu/drm/msm/disp/mdp5/mdp5_ctl.c index 030279d7b64b..81b0c7cf954e 100644 --- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_ctl.c +++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_ctl.c @@ -216,7 +216,9 @@ static void send_start_signal(struct mdp5_ctl *ctl) /** * mdp5_ctl_set_encoder_state() - set the encoder state * - * @enable: true, when encoder is ready for data streaming; false, otherwise. + * @ctl: the CTL instance + * @pipeline: the encoder's INTF + MIXER configuration + * @enabled: true, when encoder is ready for data streaming; false, otherwise. * * Note: * This encoder state is needed to trigger START signal (data path kickoff). @@ -510,6 +512,13 @@ static void fix_for_single_flush(struct mdp5_ctl *ctl, u32 *flush_mask, /** * mdp5_ctl_commit() - Register Flush * + * @ctl:the CTL instance + * @pipeline: the encoder's INTF + MIXER configuration + * @flush_mask: bitmask of display controller hw blocks to flush + * @start: if true, immediately update flush registers and set START + * bit, otherwise accumulate flush_mask bits until we are + * ready to START + * * The flush register is used to indicate several registers are all * programmed, and are safe to update to the back copy of the double * buffered registers. -- 2.28.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] powerpc/ps3: make system bus's remove and shutdown callbacks return void
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 callback > > it's ps3_system_bus_shutdown() which ignores the return value. > > > > To simplify the quest to make struct device_driver::remove return void, > > let struct ps3_system_bus_driver::remove return void, too. All users > > already unconditionally return 0, this commit makes it obvious that > > returning an error code is a bad idea and ensures future users behave > > accordingly. > > > > Signed-off-by: Uwe Kleine-König > > For the sound bit: > Acked-by: Takashi Iwai assuming that you are the one who will apply this patch: Note that it depends on patch 1 that Takashi already applied to his tree. So you either have to wait untils patch 1 appears in some tree that you merge before applying, or you have to take patch 1, too. (With Takashi optinally dropping it then.) Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | https://www.pengutronix.de/ | signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/rockchip: dw_hdmi: fix incorrect clock in vpll clock error message
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 dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/rockchip: Avoid uninitialized use of endpoint id in LVDS
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 the endpoint_id variable to 0 to avoid using an > uninitialized variable in that case. Applied, thanks! [1/1] drm/rockchip: Avoid uninitialized use of endpoint id in LVDS commit: aec9fe892812ed10d0bffcf309d2a8fc380d8ce6 Best regards, -- Heiko Stuebner ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 01/28] video: Fix kernel-doc warnings in of_display_timing + of_videomode
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: linux-fb...@vger.kernel.org > > --- > > drivers/video/of_display_timing.c | 1 + > > drivers/video/of_videomode.c | 8 > > 2 files changed, 5 insertions(+), 4 deletions(-) > > > > diff --git a/drivers/video/of_display_timing.c > > b/drivers/video/of_display_timing.c > > index abc9ada798ee..f93b6abbe258 100644 > > --- a/drivers/video/of_display_timing.c > > +++ b/drivers/video/of_display_timing.c > > @@ -52,6 +52,7 @@ static int parse_timing_property(const struct device_node > > *np, const char *name, > > /** > >* of_parse_display_timing - parse display_timing entry from device_node > >* @np: device_node with the properties > > + * @dt: display_timing that contains the result. I may be partially > > written in case of errors > >**/ > > static int of_parse_display_timing(const struct device_node *np, > > struct display_timing *dt) > > diff --git a/drivers/video/of_videomode.c b/drivers/video/of_videomode.c > > index 67aff2421c29..a5bb02f02b44 100644 > > --- a/drivers/video/of_videomode.c > > +++ b/drivers/video/of_videomode.c > > @@ -13,10 +13,10 @@ > > #include > > /** > > - * of_get_videomode - get the videomode # from devicetree > > What's wrong with this line? We use the dash in lots of places? I think my OCD kicked in and I made all lines use ':'. I will re-add the dash when I apply. > > Besides this, > > Acked-by: Thomas Zimmermann Thanks ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 02/28] video: fbcon: Fix warnings by using pr_debug() in fbcon
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 setup at the same time. > > > > I guess this was added for quick debugging during development. Anyway, I > > never liked these kinds of hacks. > > > > Acked-by: Thomas Zimmermann > > > > But replacing printk(KERN_DEBUG) with pr_debug() prevents __func__ from being > printed > when FBCONDEBUG is defined. Is such change what the author of this module > expects? When someone goes and enable DEBUG for fbcon they are also able to recognize the logging, so the printing of the function name is redundant in this case. There is likely limited to no use for these few logging entries, but if they should be dropped then I expect Peilin Ye to do so as he is the only one doing active maintenance of fbcon lately. Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 03/28] video: fbdev: core: Fix kernel-doc warnings in fbmon + fb_notify
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"
---
drivers/video/fbdev/core/fb_notify.c | 3 ++-
drivers/video/fbdev/core/fbmon.c | 2 +-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/core/fb_notify.c
b/drivers/video/fbdev/core/fb_notify.c
index 74c2da528884..d85717b6e14a 100644
--- a/drivers/video/fbdev/core/fb_notify.c
+++ b/drivers/video/fbdev/core/fb_notify.c
@@ -38,7 +38,8 @@ EXPORT_SYMBOL(fb_unregister_client);
/**
* fb_notifier_call_chain - notify clients of fb_events
- *
+ * @val: value passed to callback
+ * @v: pointer passed to callback
Since you're at it, maybe add Returns.
*/
int fb_notifier_call_chain(unsigned long val, void *v)
{
diff --git a/drivers/video/fbdev/core/fbmon.c b/drivers/video/fbdev/core/fbmon.c
index 1bf82dbc9e3c..b0e690f41025 100644
--- a/drivers/video/fbdev/core/fbmon.c
+++ b/drivers/video/fbdev/core/fbmon.c
@@ -605,6 +605,7 @@ static void get_detailed_timing(unsigned char *block,
* fb_create_modedb - create video mode database
* @edid: EDID data
* @dbsize: database size
+ * @specs: monitor specifications, may be NULL
*
* RETURNS: struct fb_videomode, @dbsize contains length of database
*
@@ -1100,7 +1101,6 @@ static u32 fb_get_hblank_by_hfreq(u32 hfreq, u32 xres)
*2 * M
*M = 300;
*C = 30;
-
*/
static u32 fb_get_hblank_by_dclk(u32 dclk, u32 xres)
{
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
OpenPGP_signature
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 02/28] video: fbcon: Fix warnings by using pr_debug() in fbcon
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 Vetter
Cc: Bartlomiej Zolnierkiewicz
Cc: Sam Ravnborg
Cc: Jiri Slaby
Cc: Peilin Ye
Cc: Tetsuo Handa
Cc: George Kennedy
Cc: Nathan Chancellor
Cc: Peter Rosin
---
drivers/video/fbdev/core/fbcon.c | 25 -
1 file changed, 8 insertions(+), 17 deletions(-)
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index bf61598bf1c3..44a5cd2f54cc 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -56,8 +56,6 @@
* more details.
*/
-#undef FBCONDEBUG
-
I guess this was added for quick debugging during development. Anyway, I
never liked these kinds of hacks.
Acked-by: Thomas Zimmermann
#include
#include
#include
@@ -82,12 +80,6 @@
#include "fbcon.h"
-#ifdef FBCONDEBUG
-# define DPRINTK(fmt, args...) printk(KERN_DEBUG "%s: " fmt, __func__ , ##
args)
-#else
-# define DPRINTK(fmt, args...)
-#endif
-
/*
* FIXME: Locking
*
@@ -1015,11 +1007,11 @@ static const char *fbcon_startup(void)
rows /= vc->vc_font.height;
vc_resize(vc, cols, rows);
- DPRINTK("mode: %s\n", info->fix.id);
- DPRINTK("visual: %d\n", info->fix.visual);
- DPRINTK("res:%dx%d-%d\n", info->var.xres,
- info->var.yres,
- info->var.bits_per_pixel);
+ pr_debug("mode: %s\n", info->fix.id);
+ pr_debug("visual: %d\n", info->fix.visual);
+ pr_debug("res:%dx%d-%d\n", info->var.xres,
+info->var.yres,
+info->var.bits_per_pixel);
fbcon_add_cursor_timer(info);
return display_desc;
@@ -2013,7 +2005,7 @@ static int fbcon_resize(struct vc_data *vc, unsigned int
width,
y_diff < 0 || y_diff > virt_fh) {
const struct fb_videomode *mode;
- DPRINTK("attempting resize %ix%i\n", var.xres, var.yres);
+ pr_debug("attempting resize %ix%i\n", var.xres, var.yres);
mode = fb_find_best_mode(, >modelist);
if (mode == NULL)
return -EINVAL;
@@ -2023,7 +2015,7 @@ static int fbcon_resize(struct vc_data *vc, unsigned int
width,
if (virt_w > var.xres/virt_fw || virt_h > var.yres/virt_fh)
return -EINVAL;
- DPRINTK("resize now %ix%i\n", var.xres, var.yres);
+ pr_debug("resize now %ix%i\n", var.xres, var.yres);
if (con_is_visible(vc)) {
var.activate = FB_ACTIVATE_NOW |
FB_ACTIVATE_FORCE;
@@ -3299,8 +3291,7 @@ static void fbcon_exit(void)
if (info->queue.func)
pending = cancel_work_sync(>queue);
- DPRINTK("fbcon: %s pending work\n", (pending ? "canceled" :
- "no"));
+ pr_debug("fbcon: %s pending work\n", (pending ? "canceled" :
"no"));
for (j = first_fb_vc; j <= last_fb_vc; j++) {
if (con2fb_map[j] == i) {
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
OpenPGP_signature
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 01/28] video: Fix kernel-doc warnings in of_display_timing + of_videomode
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 2 files changed, 5 insertions(+), 4 deletions(-) diff --git a/drivers/video/of_display_timing.c b/drivers/video/of_display_timing.c index abc9ada798ee..f93b6abbe258 100644 --- a/drivers/video/of_display_timing.c +++ b/drivers/video/of_display_timing.c @@ -52,6 +52,7 @@ static int parse_timing_property(const struct device_node *np, const char *name, /** * of_parse_display_timing - parse display_timing entry from device_node * @np: device_node with the properties + * @dt: display_timing that contains the result. I may be partially written in case of errors **/ static int of_parse_display_timing(const struct device_node *np, struct display_timing *dt) diff --git a/drivers/video/of_videomode.c b/drivers/video/of_videomode.c index 67aff2421c29..a5bb02f02b44 100644 --- a/drivers/video/of_videomode.c +++ b/drivers/video/of_videomode.c @@ -13,10 +13,10 @@ #include /** - * of_get_videomode - get the videomode # from devicetree What's wrong with this line? We use the dash in lots of places? Besides this, Acked-by: Thomas Zimmermann - * @np - devicenode with the display_timings - * @vm - set to return value - * @index - index into list of display_timings + * of_get_videomode: get the videomode # from devicetree + * @np: devicenode with the display_timings + * @vm: set to return value + * @index: index into list of display_timings *(Set this to OF_USE_NATIVE_MODE to use whatever mode is * specified as native mode in the DT.) * -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer OpenPGP_signature Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 28/28] video: fbdev: s1d13xxxfb: Fix kernel-doc and set but not used warnings
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
are used
- Fix kernel-doc warning by deleting an empty comment line
v2:
- Subject updated (Lee)
Signed-off-by: Sam Ravnborg
Cc: Kristoffer Ericson
Cc: Lee Jones
---
drivers/video/fbdev/s1d13xxxfb.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/s1d13xxxfb.c b/drivers/video/fbdev/s1d13xxxfb.c
index 4541afcf9386..d1b5f965bc96 100644
--- a/drivers/video/fbdev/s1d13xxxfb.c
+++ b/drivers/video/fbdev/s1d13xxxfb.c
@@ -45,7 +45,7 @@
#if 0
#define dbg(fmt, args...) do { printk(KERN_INFO fmt, ## args); } while(0)
#else
-#define dbg(fmt, args...) do { } while (0)
+#define dbg(fmt, args...) do { no_printk(KERN_INFO fmt, ## args); } while (0)
#endif
/*
@@ -512,7 +512,6 @@ s1d13xxxfb_bitblt_copyarea(struct fb_info *info, const
struct fb_copyarea *area)
}
/**
- *
*s1d13xxxfb_bitblt_solidfill - accelerated solidfill function
*@info : framebuffer structure
*@rect : fb_fillrect structure
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
OpenPGP_signature
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
