Re: [PATCH] fbdev: Update fbdev source file paths

2023-09-01 Thread Jonathan Neuschäfer
On Thu, Aug 31, 2023 at 11:49:47PM +0200, Helge Deller wrote:
> On 8/31/23 11:02, Helge Deller wrote:
> > On 8/31/23 10:51, Daniel Vetter wrote:
> > > On Thu, Aug 31, 2023 at 08:44:59AM +0200, Jonathan Neuschäfer wrote:
> > > > On Wed, Aug 30, 2023 at 09:10:26AM +0200, Thomas Zimmermann wrote:
> > > > > Hi
> > > > > 
> > > > > Am 29.08.23 um 22:02 schrieb Jonathan Neuschäfer:
> > > > > > The files fbmem.c, fb_defio.c, fbsysfs.c, fbmon.c, modedb.c, and
> > > > > > fbcmap.c were moved to drivers/video/fbdev, and subsequently to
> > > > > > drivers/video/fbdev/core, in the commits listed below.
> > > > > > 
> > > > > > Reported by kalekale in #kernel (Libera IRC).
> > > > > > 
> > > > > > Fixes: f7018c213502 ("video: move fbdev to drivers/video/fbdev")
> > > > > > Fixes: 19757fc8432a ("fbdev: move fbdev core files to separate 
> > > > > > directory")
> > > > > > Signed-off-by: Jonathan Neuschäfer 
> > > > > 
> > > > > IMHO these comments might just be removed.
> > > > 
> > > > I think it's nice to have some sort of visual separation between groups
> > > > of functions in fb.h, which these comments provide at the moment.
> > > > Therefore I'm currently leaning towards my patch as it is, but I'm
> > > > willing to have my mind changed and do a v2 which just removes the
> > > > comments.
> > > 
> > > Just the filename without the full path maybe?
> > 
> > Yes, I'd prefer that as well.
> 
> I've manually changed it and applied the patch to the fbdev git tree.

Thanks, everyone!

Jonathan


signature.asc
Description: PGP signature


Re: [PATCH] fbdev: Update fbdev source file paths

2023-08-30 Thread Jonathan Neuschäfer
On Wed, Aug 30, 2023 at 09:10:26AM +0200, Thomas Zimmermann wrote:
> Hi
> 
> Am 29.08.23 um 22:02 schrieb Jonathan Neuschäfer:
> > The files fbmem.c, fb_defio.c, fbsysfs.c, fbmon.c, modedb.c, and
> > fbcmap.c were moved to drivers/video/fbdev, and subsequently to
> > drivers/video/fbdev/core, in the commits listed below.
> > 
> > Reported by kalekale in #kernel (Libera IRC).
> > 
> > Fixes: f7018c213502 ("video: move fbdev to drivers/video/fbdev")
> > Fixes: 19757fc8432a ("fbdev: move fbdev core files to separate directory")
> > Signed-off-by: Jonathan Neuschäfer 
> 
> IMHO these comments might just be removed.

I think it's nice to have some sort of visual separation between groups
of functions in fb.h, which these comments provide at the moment.
Therefore I'm currently leaning towards my patch as it is, but I'm
willing to have my mind changed and do a v2 which just removes the
comments.


Thanks

> 
> Best regards
> Thomas
> 
> > ---
> >   include/linux/fb.h | 12 ++--
> >   1 file changed, 6 insertions(+), 6 deletions(-)
> > 
> > diff --git a/include/linux/fb.h b/include/linux/fb.h
> > index ce7d588edc3e6..3cda5b9f2469b 100644
> > --- a/include/linux/fb.h
> > +++ b/include/linux/fb.h
> > @@ -592,7 +592,7 @@ extern ssize_t fb_sys_write(struct fb_info *info, const 
> > char __user *buf,
> > __FB_DEFAULT_SYS_OPS_DRAW, \
> > __FB_DEFAULT_SYS_OPS_MMAP
> > 
> > -/* drivers/video/fbmem.c */
> > +/* drivers/video/fbdev/core/fbmem.c */
> >   extern int register_framebuffer(struct fb_info *fb_info);
> >   extern void unregister_framebuffer(struct fb_info *fb_info);
> >   extern int fb_prepare_logo(struct fb_info *fb_info, int rotate);


signature.asc
Description: PGP signature


[PATCH] fbdev: Update fbdev source file paths

2023-08-29 Thread Jonathan Neuschäfer
The files fbmem.c, fb_defio.c, fbsysfs.c, fbmon.c, modedb.c, and
fbcmap.c were moved to drivers/video/fbdev, and subsequently to
drivers/video/fbdev/core, in the commits listed below.

Reported by kalekale in #kernel (Libera IRC).

Fixes: f7018c213502 ("video: move fbdev to drivers/video/fbdev")
Fixes: 19757fc8432a ("fbdev: move fbdev core files to separate directory")
Signed-off-by: Jonathan Neuschäfer 
---
 include/linux/fb.h | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/include/linux/fb.h b/include/linux/fb.h
index ce7d588edc3e6..3cda5b9f2469b 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -592,7 +592,7 @@ extern ssize_t fb_sys_write(struct fb_info *info, const 
char __user *buf,
__FB_DEFAULT_SYS_OPS_DRAW, \
__FB_DEFAULT_SYS_OPS_MMAP

-/* drivers/video/fbmem.c */
+/* drivers/video/fbdev/core/fbmem.c */
 extern int register_framebuffer(struct fb_info *fb_info);
 extern void unregister_framebuffer(struct fb_info *fb_info);
 extern int fb_prepare_logo(struct fb_info *fb_info, int rotate);
@@ -636,7 +636,7 @@ static inline void __fb_pad_aligned_buffer(u8 *dst, u32 
d_pitch,
}
 }

-/* drivers/video/fb_defio.c */
+/* drivers/video/fbdev/core/fb_defio.c */
 int fb_deferred_io_mmap(struct fb_info *info, struct vm_area_struct *vma);
 extern int  fb_deferred_io_init(struct fb_info *info);
 extern void fb_deferred_io_open(struct fb_info *info,
@@ -735,14 +735,14 @@ static inline bool fb_be_math(struct fb_info *info)
 #endif /* CONFIG_FB_FOREIGN_ENDIAN */
 }

-/* drivers/video/fbsysfs.c */
+/* drivers/video/fbdev/core/fbsysfs.c */
 extern struct fb_info *framebuffer_alloc(size_t size, struct device *dev);
 extern void framebuffer_release(struct fb_info *info);
 extern int fb_init_device(struct fb_info *fb_info);
 extern void fb_cleanup_device(struct fb_info *head);
 extern void fb_bl_default_curve(struct fb_info *fb_info, u8 off, u8 min, u8 
max);

-/* drivers/video/fbmon.c */
+/* drivers/video/fbdev/core/fbmon.c */
 #define FB_MAXTIMINGS  0
 #define FB_VSYNCTIMINGS1
 #define FB_HSYNCTIMINGS2
@@ -776,7 +776,7 @@ extern int of_get_fb_videomode(struct device_node *np,
 extern int fb_videomode_from_videomode(const struct videomode *vm,
   struct fb_videomode *fbmode);

-/* drivers/video/modedb.c */
+/* drivers/video/fbdev/core/modedb.c */
 #define VESA_MODEDB_SIZE 43
 #define DMT_SIZE 0x50

@@ -802,7 +802,7 @@ extern void fb_videomode_to_modelist(const struct 
fb_videomode *modedb, int num,
 extern const struct fb_videomode *fb_find_best_display(const struct 
fb_monspecs *specs,
   struct list_head *head);

-/* drivers/video/fbcmap.c */
+/* drivers/video/fbdev/core/fbcmap.c */
 extern int fb_alloc_cmap(struct fb_cmap *cmap, int len, int transp);
 extern int fb_alloc_cmap_gfp(struct fb_cmap *cmap, int len, int transp, gfp_t 
flags);
 extern void fb_dealloc_cmap(struct fb_cmap *cmap);
--
2.40.1



[PATCH] drm/amdgpu: Fix a typo ("boradcast")

2023-01-29 Thread Jonathan Neuschäfer
Spell it as "broadcast".

Signed-off-by: Jonathan Neuschäfer 
---
 drivers/gpu/drm/amd/amdgpu/df_v1_7.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/df_v1_7.c 
b/drivers/gpu/drm/amd/amdgpu/df_v1_7.c
index b991609f46c10..5dfab8021 100644
--- a/drivers/gpu/drm/amd/amdgpu/df_v1_7.c
+++ b/drivers/gpu/drm/amd/amdgpu/df_v1_7.c
@@ -94,7 +94,7 @@ static void df_v1_7_update_medium_grain_clock_gating(struct 
amdgpu_device *adev,
WREG32_SOC15(DF, 0, mmDF_PIE_AON0_DfGlobalClkGater, tmp);
}

-   /* Exit boradcast mode */
+   /* Exit broadcast mode */
adev->df.funcs->enable_broadcast_mode(adev, false);
 }

--
2.39.0



[PATCH] dma-buf: Add "dma-buf" to title of documentation

2023-01-29 Thread Jonathan Neuschäfer
To make it easier to find the dma-buf documentation when looking through
tables-of-contents etc., put the name "dma-buf" in the title.

Signed-off-by: Jonathan Neuschäfer 
---
 Documentation/driver-api/dma-buf.rst | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/driver-api/dma-buf.rst 
b/Documentation/driver-api/dma-buf.rst
index 622b8156d2127..61b6f42ed0f18 100644
--- a/Documentation/driver-api/dma-buf.rst
+++ b/Documentation/driver-api/dma-buf.rst
@@ -1,5 +1,5 @@
-Buffer Sharing and Synchronization
-==
+Buffer Sharing and Synchronization (dma-buf)
+

 The dma-buf subsystem provides the framework for sharing buffers for
 hardware (DMA) access across multiple device drivers and subsystems, and
--
2.39.0



Re: [RFC PATCH 4/6] drm: mxc-epdc: Add update management

2022-03-12 Thread Jonathan Neuschäfer
On Sun, Feb 06, 2022 at 09:00:14AM +0100, Andreas Kemnade wrote:
> The EPDC can process some dirty rectangles at a time, pick them up and
> forward them to the controller. Only processes not involving PXP are
> supported at the moment. Due to that and to work with more waveforms,
> there is some masking/shifting done. It was tested with the factory
> waveforms of Kobo Clara HD, Tolino Shine 3, and Tolino Shine 2HD.
> Also the waveform called epdc_E060SCM.fw from NXP BSP works with the
> i.MX6SL devices.
> 
> Signed-off-by: Andreas Kemnade 
> ---

[...]
> + adj_update_region = upd_data_list->update_desc->upd_data.update_region;
> + /*
> +  * Is the working buffer idle?
> +  * If the working buffer is busy, we must wait for the resource
> +  * to become free. The IST will signal this event.

What does IST mean?


> +void mxc_epdc_draw_mode0(struct mxc_epdc *priv)

What does mode 0 imply? An overview of the possible modes would be
appreciated.

> +{
> + u32 *upd_buf_ptr;
> + int i;
> + u32 xres, yres;
> +
> + upd_buf_ptr = (u32 *)priv->epdc_mem_virt;
> +
> + epdc_working_buf_intr(priv, true);
> + epdc_lut_complete_intr(priv, 0, true);
> +
> + /* Use unrotated (native) width/height */
> + xres = priv->epdc_mem_width;
> + yres = priv->epdc_mem_height;
> +
> + /* Program EPDC update to process buffer */
> + epdc_set_update_area(priv, priv->epdc_mem_phys, 0, 0, xres, yres, 0);
> + epdc_submit_update(priv, 0, priv->wv_modes.mode_init, UPDATE_MODE_FULL,
> + false, true, 0xFF);
> +
> + dev_dbg(priv->drm.dev, "Mode0 update - Waiting for LUT to 
> complete...\n");
> +
> + /* Will timeout after ~4-5 seconds */
> +
> + for (i = 0; i < 40; i++) {
> + if (!epdc_is_lut_active(priv, 0)) {
> + dev_dbg(priv->drm.dev, "Mode0 init complete\n");
> + return;
> + }
> + msleep(100);
> + }
> +
> + dev_err(priv->drm.dev, "Mode0 init failed!\n");
> +}

> +#define WAVEFORM_MODE_GLR16  4
> +#define WAVEFORM_MODE_GLD16  5
> +#define WAVEFORM_MODE_AUTO   257

(How) are these mode numbers related to "mode 0"?


Jonathan


signature.asc
Description: PGP signature


Re: [RFC PATCH 3/6] drm: mxc-epdc: Add display and waveform initialisation

2022-03-12 Thread Jonathan Neuschäfer
On Sun, Feb 06, 2022 at 09:00:13AM +0100, Andreas Kemnade wrote:
> Adds display parameter initialisation, display power up/down and
> waveform loading
> 
> Signed-off-by: Andreas Kemnade 
> ---
[...]
> + /* Enable the v3p3 regulator */
> + ret = regulator_enable(priv->v3p3_regulator);
> + if (IS_ERR((void *)ret)) {

if (ret < 0)   is common enough to be understood.

> + dev_err(priv->drm.dev,
> + "Unable to enable V3P3 regulator. err = 0x%x\n",
> + ret);
> + mutex_unlock(&priv->power_mutex);
> + return;
> + }
> +
> + usleep_range(1000, 2000);
> +
> + pm_runtime_get_sync(priv->drm.dev);
> +
> + /* Enable clocks to EPDC */
> + clk_prepare_enable(priv->epdc_clk_axi);
> + clk_prepare_enable(priv->epdc_clk_pix);
> +
> + epdc_write(priv, EPDC_CTRL_CLEAR, EPDC_CTRL_CLKGATE);
> +
> + /* Enable power to the EPD panel */
> + ret = regulator_enable(priv->display_regulator);
> + if (IS_ERR((void *)ret)) {

dito

> + dev_err(priv->drm.dev,
> + "Unable to enable DISPLAY regulator. err = 0x%x\n",
> + ret);
> + mutex_unlock(&priv->power_mutex);
> + return;
> + }
> +
> + ret = regulator_enable(priv->vcom_regulator);
> + if (IS_ERR((void *)ret)) {

dito

> + dev_err(priv->drm.dev,
> + "Unable to enable VCOM regulator. err = 0x%x\n",
> + ret);
> + mutex_unlock(&priv->power_mutex);
> + return;
> + }
> +
> + priv->powered = true;
> +
> + mutex_unlock(&priv->power_mutex);
> +}

[...]
> + priv->rev = ((val & EPDC_VERSION_MAJOR_MASK) >>
> + EPDC_VERSION_MAJOR_OFFSET) * 10
> + + ((val & EPDC_VERSION_MINOR_MASK) >>
> + EPDC_VERSION_MINOR_OFFSET);

Instead of this transformation it might be (1) safer against unexpected
versions and (2) simpler, to store the EPDC_VERSION register content
directly.

Instead of

if (priv->rev == 20) { ... }

we'd have

if (priv->rev == 0x0200) { ... }

or perhaps something along the lines of

if (priv->rev == EPDC_REV(2, 0, 0)) { ... }

(using a macro that does the proper bitshifts).

> + dev_dbg(priv->drm.dev, "EPDC version = %d\n", priv->rev);
> +
> + if (priv->rev <= 20) {
> + dev_err(priv->drm.dev, "Unsupported version (%d)\n", priv->rev);
> + return -ENODEV;
> + }
> +
> + /* Initialize EPDC pins */
> + pinctrl = devm_pinctrl_get_select_default(priv->drm.dev);
> + if (IS_ERR(pinctrl)) {
> + dev_err(priv->drm.dev, "can't get/select pinctrl\n");
> + return PTR_ERR(pinctrl);
> + }
> +
> + mutex_init(&priv->power_mutex);
> +
> + return 0;
> +}

[...]
> diff --git a/drivers/gpu/drm/mxc-epdc/epdc_waveform.h 
> b/drivers/gpu/drm/mxc-epdc/epdc_waveform.h
> new file mode 100644
> index ..c5c461b975cb
> --- /dev/null
> +++ b/drivers/gpu/drm/mxc-epdc/epdc_waveform.h
> @@ -0,0 +1,7 @@
> +/* SPDX-License-Identifier: GPL-2.0+ */
> +/* Copyright (C) 2022 Andreas Kemnade */
> +int mxc_epdc_fb_get_temp_index(struct mxc_epdc *priv, int temp);
> +int mxc_epdc_prepare_waveform(struct mxc_epdc *priv,
> +   const u8 *waveform, size_t size);
> +void mxc_epdc_set_update_waveform(struct mxc_epdc *priv,
> +   struct mxcfb_waveform_modes *wv_modes);
> diff --git a/drivers/gpu/drm/mxc-epdc/mxc_epdc.h 
> b/drivers/gpu/drm/mxc-epdc/mxc_epdc.h
> index c5f5280b574f..f7b1cbc4cc4e 100644
> --- a/drivers/gpu/drm/mxc-epdc/mxc_epdc.h
> +++ b/drivers/gpu/drm/mxc-epdc/mxc_epdc.h
> @@ -8,6 +8,32 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include "epdc_regs.h"
> +
> +#define TEMP_USE_AMBIENT 0x1000

What's the significance of 0x1000 here? Is it a register value?


>  static void mxc_epdc_pipe_update(struct drm_simple_display_pipe *pipe,
> @@ -187,6 +267,7 @@ static struct drm_driver mxc_epdc_driver = {
>  static int mxc_epdc_probe(struct platform_device *pdev)
>  {
>   struct mxc_epdc *priv;
> + const struct firmware *firmware;
>   int ret;
>  
>   priv = devm_drm_dev_alloc(&pdev->dev, &mxc_epdc_driver, struct 
> mxc_epdc, drm);
> @@ -195,6 +276,19 @@ static int mxc_epdc_probe(struct platform_device *pdev)
>  
>   platform_set_drvdata(pdev, priv);
>  
> + ret = mxc_epdc_init_hw(priv);
> + if (ret)
> + return ret;
> +
> + ret = request_firmware(&firmware, "imx/epdc/epdc.fw", priv->drm.dev);

Thinking ahead to the point when we'll have multiple waveforms for
different modes...  What's your idea for a naming scheme to distinguish
the different waveform files, and should the default name be epdc.fw, or
perhaps something more specific?

> + if (ret)
> + return ret;
> +
> + ret = mxc_epdc_

Re: [RFC PATCH 2/6] drm: Add skeleton for EPDC driver

2022-03-12 Thread Jonathan Neuschäfer
On Sun, Feb 06, 2022 at 09:00:12AM +0100, Andreas Kemnade wrote:
> This driver is for the EPD controller in the i.MX SoCs. Add a skeleton
> and basic things for the driver
> 
> Signed-off-by: Andreas Kemnade 
> ---
>  drivers/gpu/drm/Kconfig |   2 +
>  drivers/gpu/drm/Makefile|   1 +
>  drivers/gpu/drm/mxc-epdc/Kconfig|  15 +
>  drivers/gpu/drm/mxc-epdc/Makefile   |   5 +
>  drivers/gpu/drm/mxc-epdc/epdc_regs.h| 442 
>  drivers/gpu/drm/mxc-epdc/mxc_epdc.h |  20 ++
>  drivers/gpu/drm/mxc-epdc/mxc_epdc_drv.c | 248 +
>  7 files changed, 733 insertions(+)
>  create mode 100644 drivers/gpu/drm/mxc-epdc/Kconfig
>  create mode 100644 drivers/gpu/drm/mxc-epdc/Makefile
>  create mode 100644 drivers/gpu/drm/mxc-epdc/epdc_regs.h
>  create mode 100644 drivers/gpu/drm/mxc-epdc/mxc_epdc.h
>  create mode 100644 drivers/gpu/drm/mxc-epdc/mxc_epdc_drv.c
> 
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index b1f22e457fd0..6b6b44ff7556 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -390,6 +390,8 @@ source "drivers/gpu/drm/gud/Kconfig"
>  
>  source "drivers/gpu/drm/sprd/Kconfig"
>  
> +source "drivers/gpu/drm/mxc-epdc/Kconfig"

I'd put it under gpu/drm/imx/epdc, perhaps.

> +int mxc_epdc_output(struct drm_device *drm)
> +{
> + struct mxc_epdc *priv = to_mxc_epdc(drm);
> + int ret;
> +
> + priv->connector.dpms = DRM_MODE_DPMS_OFF;
> + priv->connector.polled = 0;
> + drm_connector_helper_add(&priv->connector,
> +  &mxc_epdc_connector_helper_funcs);
> + ret = drm_connector_init(drm, &priv->connector,
> +  &mxc_epdc_connector_funcs,
> +  DRM_MODE_CONNECTOR_Unknown);
> + if (ret)
> + return ret;
> + ret = of_get_display_timing(drm->dev->of_node, "timing", &priv->timing);
> + if (ret)
> + return ret;
> +
> + return 0;

Possible to simplify to:

return of_get_display_timing(drm->dev->of_node, "timing", 
&priv->timing);



Jonathan


signature.asc
Description: PGP signature


Re: [RFC PATCH 1/6] dt-bindings: display: imx: Add EPDC

2022-03-12 Thread Jonathan Neuschäfer
Hello Andreas,

Sorry for the delay, I finally got around to having a look at the
patchset.

Some comments from skimming the patches below, and in my other replies.


On Sun, Feb 06, 2022 at 09:00:11AM +0100, Andreas Kemnade wrote:
> Add a binding for the Electrophoretic Display Controller found at least
> in the i.MX6.
> The timing subnode is directly here to avoid having display parameters
> spread all over the plate.
> 
> Supplies are organized the same way as in the fbdev driver in the
> NXP/Freescale kernel forks. The regulators used for that purpose,
> like the TPS65185, the SY7636A and MAX17135 have typically a single bit to
> start a bunch of regulators of higher or negative voltage with a
> well-defined timing. VCOM can be handled separately, but can also be
> incorporated into that single bit.
> 
> Signed-off-by: Andreas Kemnade 
> ---
>  .../bindings/display/imx/fsl,mxc-epdc.yaml| 159 ++
>  1 file changed, 159 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/imx/fsl,mxc-epdc.yaml
> 
> diff --git a/Documentation/devicetree/bindings/display/imx/fsl,mxc-epdc.yaml 
> b/Documentation/devicetree/bindings/display/imx/fsl,mxc-epdc.yaml
> new file mode 100644
> index ..7e0795cc3f70
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/imx/fsl,mxc-epdc.yaml
> @@ -0,0 +1,159 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
[...]
> +  - vscan-holdoff
> +  - sdoed-width
> +  - sdoed-delay
> +  - sdoez-width
> +  - sdoez-delay
> +  - gdclk-hp-offs
> +  - gdsp-offs
> +  - gdoe-offs
> +  - gdclk-offs
> +  - num-ce

These parameters should perhaps have sane defaults in the driver, and be
optional in the DT.


> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +#include 
> +#include 
> +
> +epdc: epdc@20f4000 {
[...]
> +
> +timing {
> +clock-frequency = <8000>;
> +hactive = <1448>;
> +hback-porch = <16>;
> +hfront-porch = <102>;
> +hsync-len = <28>;
> +vactive = <1072>;
> +vback-porch = <4>;
> +vfront-porch = <4>;
> +vsync-len = <2>;
> +};
> +};

The way you did it here, the timing parameters are directly under the
EPDC node in the DT, but I wonder if it would be better to have a
separate node for the display panel, which can then provide the timing
parameters either in the DT or in the panel driver (selected by compatible
string of the panel).


Jonathan


signature.asc
Description: PGP signature


Re: [PATCH 2/2] maintainers: Update freedesktop.org IRC channels

2021-05-30 Thread Jonathan Neuschäfer
On Sat, May 29, 2021 at 10:16:38AM -0400, Alyssa Rosenzweig wrote:
> Like many free software projects, freedesktop.org issued a non-binding
> recommendation for projects to migrate from OFTC to Freenode [1]. As

The other way around:from Freenode to OFTC

> such, freedesktop.org entries in the MAINTAINERS file are out-of-date as
> the respective channels have moved. Update the file to point to the
> right network.
> 
> [1] https://lists.freedesktop.org/archives/dri-devel/2021-May/307605.html


Thanks,
Jonathan Neuschäfer


signature.asc
Description: PGP signature


[PATCH] drm/mipi-dbi: Switch to new kerneldoc syntax for named variable macro argument

2021-01-04 Thread Jonathan Neuschäfer
The syntax without dots is available since commit 43756e347f21
("scripts/kernel-doc: Add support for named variable macro arguments").

The same HTML output is produced with and without this patch.

Signed-off-by: Jonathan Neuschäfer 
---
 include/drm/drm_mipi_dbi.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/drm/drm_mipi_dbi.h b/include/drm/drm_mipi_dbi.h
index c2827ceaba0d2..f543d6e3e822c 100644
--- a/include/drm/drm_mipi_dbi.h
+++ b/include/drm/drm_mipi_dbi.h
@@ -172,7 +172,7 @@ int mipi_dbi_buf_copy(void *dst, struct drm_framebuffer *fb,
  * mipi_dbi_command - MIPI DCS command with optional parameter(s)
  * @dbi: MIPI DBI structure
  * @cmd: Command
- * @seq...: Optional parameter(s)
+ * @seq: Optional parameter(s)
  *
  * Send MIPI DCS command to the controller. Use mipi_dbi_command_read() for
  * get/read.
--
2.29.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH RESEND] drm/mcde: Fix Sphinx formatting

2020-02-17 Thread Jonathan Neuschäfer
- Format the pipe diagram as a monospace block.
- Fix formatting of the list. Without the empty line, the first dash is
  not parsed as a bullet point.

Signed-off-by: Jonathan Neuschäfer 
---
Previous copy: 
https://lore.kernel.org/lkml/20191002153827.23026-2-j.neuschae...@gmx.net/

It seems that this patch got lost, somehow.
---
 drivers/gpu/drm/mcde/mcde_drv.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/mcde/mcde_drv.c b/drivers/gpu/drm/mcde/mcde_drv.c
index 9a09eba53182..c535abed4765 100644
--- a/drivers/gpu/drm/mcde/mcde_drv.c
+++ b/drivers/gpu/drm/mcde/mcde_drv.c
@@ -20,11 +20,11 @@
  * input formats including most variants of RGB and YUV.
  *
  * The hardware has four display pipes, and the layout is a little
- * bit like this:
+ * bit like this::
  *
- * Memory -> Overlay -> Channel -> FIFO -> 5 formatters -> DSI/DPI
- * External  0..5   0..3   A,B,3 x DSI bridge
- * source 0..9 C0,C1   2 x DPI
+ *   Memory -> Overlay -> Channel -> FIFO -> 5 formatters -> DSI/DPI
+ *   External  0..5   0..3   A,B,3 x DSI bridge
+ *   source 0..9 C0,C1   2 x DPI
  *
  * FIFOs A and B are for LCD and HDMI while FIFO CO/C1 are for
  * panels with embedded buffer.
@@ -43,6 +43,7 @@
  * to change as we exploit more of the hardware capabilities.
  *
  * TODO:
+ *
  * - Enabled damaged rectangles using drm_plane_enable_fb_damage_clips()
  *   so we can selectively just transmit the damaged area to a
  *   command-only display.
--
2.20.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH] drm/i915: Add Sphinx-compatible references to struct fields

2019-10-03 Thread Jonathan Neuschäfer
This fixes the following kernel-doc warnings and makes the corrsponding fields
show up in the generated HTML:

./drivers/gpu/drm/i915/i915_drv.h:1143: warning: Incorrect use of kernel-doc 
format:  * State of the OA buffer.
./drivers/gpu/drm/i915/i915_drv.h:1154: warning: Incorrect use of kernel-doc 
format:  * Locks reads and writes to all head/tail state
./drivers/gpu/drm/i915/i915_drv.h:1176: warning: Incorrect use of kernel-doc 
format:  * One 'aging' tail pointer and one 'aged' tail pointer 
ready to
./drivers/gpu/drm/i915/i915_drv.h:1188: warning: Incorrect use of kernel-doc 
format:  * Index for the aged tail ready to read() data up to.
./drivers/gpu/drm/i915/i915_drv.h:1193: warning: Incorrect use of kernel-doc 
format:  * A monotonic timestamp for when the current aging 
tail pointer
./drivers/gpu/drm/i915/i915_drv.h:1199: warning: Incorrect use of kernel-doc 
format:  * Although we can always read back the head pointer 
register,

Signed-off-by: Jonathan Neuschäfer 
---
 drivers/gpu/drm/i915/i915_drv.h | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 772154e4073e..55782e78f026 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1140,7 +1140,7 @@ struct i915_perf_stream {
int period_exponent;

/**
-* State of the OA buffer.
+* @oa_buffer: State of the OA buffer.
 */
struct {
struct i915_vma *vma;
@@ -1151,6 +1151,7 @@ struct i915_perf_stream {
int size_exponent;

/**
+* @oa_buffer.ptr_lock:
 * Locks reads and writes to all head/tail state
 *
 * Consider: the head and tail pointer state needs to be read
@@ -1173,6 +1174,7 @@ struct i915_perf_stream {
spinlock_t ptr_lock;

/**
+* @oa_buffer.tails:
 * One 'aging' tail pointer and one 'aged' tail pointer ready to
 * used for reading.
 *
@@ -1185,17 +1187,20 @@ struct i915_perf_stream {
} tails[2];

/**
+* @oa_buffer.aged_tail_idx:
 * Index for the aged tail ready to read() data up to.
 */
unsigned int aged_tail_idx;

/**
+* @oa_buffer.aging_timestamp:
 * A monotonic timestamp for when the current aging tail pointer
 * was read; used to determine when it is old enough to trust.
 */
u64 aging_timestamp;

/**
+* @oa_buffer.head:
 * Although we can always read back the head pointer register,
 * we prefer to avoid trusting the HW state, just to avoid any
 * risk that some hardware condition could * somehow bump the
--
2.20.1



[PATCH 1/2] drm/mcde: Fix reference to DOC comment

2019-10-02 Thread Jonathan Neuschäfer
The :doc: reference did not match the DOC comment's name.

Fixes: 5fc537bfd000 ("drm/mcde: Add new driver for ST-Ericsson MCDE")
Signed-off-by: Jonathan Neuschäfer 
---
 Documentation/gpu/mcde.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/gpu/mcde.rst b/Documentation/gpu/mcde.rst
index c69e977defda..dd43dde379e0 100644
--- a/Documentation/gpu/mcde.rst
+++ b/Documentation/gpu/mcde.rst
@@ -5,4 +5,4 @@
 ===

 .. kernel-doc:: drivers/gpu/drm/mcde/mcde_drv.c
-   :doc: ST-Ericsson MCDE DRM Driver
+   :doc: ST-Ericsson MCDE Driver
--
2.20.1



[PATCH 2/2] drm/mcde: Fix Sphinx formatting

2019-10-02 Thread Jonathan Neuschäfer
- Format the pipe diagram as a monospace block.
- Fix formatting of the list. Without the empty line, the first dash is
  not parsed as a bullet point.

Signed-off-by: Jonathan Neuschäfer 
---
 drivers/gpu/drm/mcde/mcde_drv.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/mcde/mcde_drv.c b/drivers/gpu/drm/mcde/mcde_drv.c
index 9a09eba53182..c535abed4765 100644
--- a/drivers/gpu/drm/mcde/mcde_drv.c
+++ b/drivers/gpu/drm/mcde/mcde_drv.c
@@ -20,11 +20,11 @@
  * input formats including most variants of RGB and YUV.
  *
  * The hardware has four display pipes, and the layout is a little
- * bit like this:
+ * bit like this::
  *
- * Memory -> Overlay -> Channel -> FIFO -> 5 formatters -> DSI/DPI
- * External  0..5   0..3   A,B,3 x DSI bridge
- * source 0..9 C0,C1   2 x DPI
+ *   Memory -> Overlay -> Channel -> FIFO -> 5 formatters -> DSI/DPI
+ *   External  0..5   0..3   A,B,3 x DSI bridge
+ *   source 0..9 C0,C1   2 x DPI
  *
  * FIFOs A and B are for LCD and HDMI while FIFO CO/C1 are for
  * panels with embedded buffer.
@@ -43,6 +43,7 @@
  * to change as we exploit more of the hardware capabilities.
  *
  * TODO:
+ *
  * - Enabled damaged rectangles using drm_plane_enable_fb_damage_clips()
  *   so we can selectively just transmit the damaged area to a
  *   command-only display.
--
2.20.1



[PATCH] drm/drv: Use // for comments in example code

2019-08-09 Thread Jonathan Neuschäfer
This improves Sphinx output in two ways:

- It avoids an unmatched single-quote ('), about which Sphinx complained:

  /.../Documentation/gpu/drm-internals.rst:298:
WARNING: Could not lex literal_block as "c". Highlighting skipped.

  An alternative approach would be to replace "can't" with a word that
  doesn't have a single-quote.

- It lets Sphinx format the comments in italics and grey, making the
  code slightly easier to read.

Signed-off-by: Jonathan Neuschäfer 
---
 drivers/gpu/drm/drm_drv.c | 14 ++
 1 file changed, 6 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 9d00947ca447..769feeff 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -328,11 +328,9 @@ void drm_minor_release(struct drm_minor *minor)
  * struct drm_device *drm;
  * int ret;
  *
- * [
- *   devm_kzalloc() can't be used here because the drm_device
- *   lifetime can exceed the device lifetime if driver unbind
- *   happens when userspace still has open file descriptors.
- * ]
+ * // devm_kzalloc() can't be used here because the drm_device '
+ * // lifetime can exceed the device lifetime if driver unbind
+ * // happens when userspace still has open file descriptors.
  * priv = kzalloc(sizeof(*priv), GFP_KERNEL);
  * if (!priv)
  * return -ENOMEM;
@@ -355,7 +353,7 @@ void drm_minor_release(struct drm_minor *minor)
  * if (IS_ERR(priv->pclk))
  * return PTR_ERR(priv->pclk);
  *
- * [ Further setup, display pipeline etc ]
+ * // Further setup, display pipeline etc
  *
  * platform_set_drvdata(pdev, drm);
  *
@@ -370,7 +368,7 @@ void drm_minor_release(struct drm_minor *minor)
  * return 0;
  * }
  *
- * [ This function is called before the devm_ resources are released ]
+ * // This function is called before the devm_ resources are released
  * static int driver_remove(struct platform_device *pdev)
  * {
  * struct drm_device *drm = platform_get_drvdata(pdev);
@@ -381,7 +379,7 @@ void drm_minor_release(struct drm_minor *minor)
  * return 0;
  * }
  *
- * [ This function is called on kernel restart and shutdown ]
+ * // This function is called on kernel restart and shutdown
  * static void driver_shutdown(struct platform_device *pdev)
  * {
  * drm_atomic_helper_shutdown(platform_get_drvdata(pdev));
--
2.20.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/sched: Fix description of drm_sched_stop

2019-04-22 Thread Jonathan Neuschäfer
Since commit 222b5f044159 ("drm/sched: Refactor ring mirror list
handling."), drm_sched_hw_job_reset is no longer there, so let's adjust
the doc comment accordingly.

Signed-off-by: Jonathan Neuschäfer 
---
 drivers/gpu/drm/scheduler/sched_main.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/scheduler/sched_main.c 
b/drivers/gpu/drm/scheduler/sched_main.c
index 19fc601c9eeb..a1bec2779e76 100644
--- a/drivers/gpu/drm/scheduler/sched_main.c
+++ b/drivers/gpu/drm/scheduler/sched_main.c
@@ -366,10 +366,9 @@ void drm_sched_increase_karma(struct drm_sched_job *bad)
 EXPORT_SYMBOL(drm_sched_increase_karma);

 /**
- * drm_sched_hw_job_reset - stop the scheduler if it contains the bad job
+ * drm_sched_stop - stop the scheduler
  *
  * @sched: scheduler instance
- * @bad: bad scheduler job
  *
  */
 void drm_sched_stop(struct drm_gpu_scheduler *sched)
--
2.20.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] dt-bindings: display: panel: Fix compatible string for Toshiba LT089AC29000

2017-12-17 Thread Jonathan Neuschäfer
The compatible string for this panel was specified as
toshiba,lt089ac29000.txt. I believe this is a mistake.

Fixes: 06e733e41f87 ("drm/panel: simple: add Toshiba LT089AC19000")
Cc: Lucas Stach 
Signed-off-by: Jonathan Neuschäfer 
---
 .../devicetree/bindings/display/panel/toshiba,lt089ac29000.txt  | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git 
a/Documentation/devicetree/bindings/display/panel/toshiba,lt089ac29000.txt 
b/Documentation/devicetree/bindings/display/panel/toshiba,lt089ac29000.txt
index 4c0caaf246c9..89826116628c 100644
--- a/Documentation/devicetree/bindings/display/panel/toshiba,lt089ac29000.txt
+++ b/Documentation/devicetree/bindings/display/panel/toshiba,lt089ac29000.txt
@@ -1,7 +1,7 @@
 Toshiba 8.9" WXGA (1280x768) TFT LCD panel
 
 Required properties:
-- compatible: should be "toshiba,lt089ac29000.txt"
+- compatible: should be "toshiba,lt089ac29000"
 - power-supply: as specified in the base binding
 
 This binding is compatible with the simple-panel binding, which is specified
-- 
2.15.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH] drm/i915/guc: Fix doc reference to intel_guc_fw.c

2017-11-28 Thread Jonathan Neuschäfer
On Tue, Nov 28, 2017 at 09:51:13AM +0100, Michal Wajdeczko wrote:
> On Tue, 28 Nov 2017 07:50:52 +0100, Jonathan Neuschäfer
>  wrote:
> 
> > Sphinx complains that it can't find intel_guc_loader.c, and rightly so:
> > The file has been renamed.
> > 
> > Fixes: e8668bbcb0f9 ("drm/i915/guc: Rename intel_guc_loader.c to
> > intel_guc_fw.c")
> > Cc: Michal Wajdeczko 
> > Signed-off-by: Jonathan Neuschäfer 
> > ---
> >  Documentation/gpu/i915.rst | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
> > index 2e7ee0313c1c..e21698e16534 100644
> > --- a/Documentation/gpu/i915.rst
> > +++ b/Documentation/gpu/i915.rst
> > @@ -341,10 +341,10 @@ GuC
> >  GuC-specific firmware loader
> >  
> > -.. kernel-doc:: drivers/gpu/drm/i915/intel_guc_loader.c
> > +.. kernel-doc:: drivers/gpu/drm/i915/intel_guc_fw.c
> > :doc: GuC-specific firmware loader
> > -.. kernel-doc:: drivers/gpu/drm/i915/intel_guc_loader.c
> > +.. kernel-doc:: drivers/gpu/drm/i915/intel_guc_fw.c
> > :internal:
> > GuC-based command submission
> 
> + Ville
> 
> Well, this will fix sphinx error, but in my opinion it will not make
> i915 documentation any better. See my earlier patch/comments in [1].

Thanks for the pointer.

Hmm, right, given that there's no "DOC:" line in intel_guc_fw.c anymore,
the ":doc:" directive above is not useful.

As a tiny step towards more complete documentation (and to keep people
from patching this spot again ;), IMHO it makes sense to do this (it's
of course up to the maintainers whether they agree):

---
diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
index 2e7ee0313c1c..e94d3ac2bdd0 100644
--- a/Documentation/gpu/i915.rst
+++ b/Documentation/gpu/i915.rst
@@ -341,10 +341,7 @@ GuC
 GuC-specific firmware loader
 
 
-.. kernel-doc:: drivers/gpu/drm/i915/intel_guc_loader.c
-   :doc: GuC-specific firmware loader
-
-.. kernel-doc:: drivers/gpu/drm/i915/intel_guc_loader.c
+.. kernel-doc:: drivers/gpu/drm/i915/intel_guc_fw.c
:internal:
 
 GuC-based command submission
---

> So maybe better to wait for other comments which way to go.

Makes sense.


Thanks,
Jonathan Neuschäfer

> 
> Thanks for the patch,
> Michal
> 
> [1] https://patchwork.freedesktop.org/patch/188424/


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH] drm/i915/guc: Fix doc reference to intel_guc_fw.c

2017-11-28 Thread Jonathan Neuschäfer
Sphinx complains that it can't find intel_guc_loader.c, and rightly so:
The file has been renamed.

Fixes: e8668bbcb0f9 ("drm/i915/guc: Rename intel_guc_loader.c to 
intel_guc_fw.c")
Cc: Michal Wajdeczko 
Signed-off-by: Jonathan Neuschäfer 
---
 Documentation/gpu/i915.rst | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
index 2e7ee0313c1c..e21698e16534 100644
--- a/Documentation/gpu/i915.rst
+++ b/Documentation/gpu/i915.rst
@@ -341,10 +341,10 @@ GuC
 GuC-specific firmware loader
 
 
-.. kernel-doc:: drivers/gpu/drm/i915/intel_guc_loader.c
+.. kernel-doc:: drivers/gpu/drm/i915/intel_guc_fw.c
:doc: GuC-specific firmware loader
 
-.. kernel-doc:: drivers/gpu/drm/i915/intel_guc_loader.c
+.. kernel-doc:: drivers/gpu/drm/i915/intel_guc_fw.c
:internal:
 
 GuC-based command submission
-- 
2.15.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH] drm/udl: Fix unaligned memory access in udl_render_hline

2017-04-11 Thread Jonathan Neuschäfer
On Tue, Apr 11, 2017 at 09:30:53AM -0400, Sean Paul wrote:
> On Fri, Apr 07, 2017 at 10:02:29PM +0200, Jonathan Neuschäfer wrote:
> > On SPARC, the udl driver filled my kernel log with these messages:
> > 
> > [186668.910612] Kernel unaligned access at TPC[76609c] 
> > udl_render_hline+0x13c/0x3a0
> > 
> > Use put_unaligned_be16 to avoid them. On x86 this results in the same
> > code, but on SPARC the compiler emits two single-byte stores.
> > 
> 
> Pushed to drm-misc-fixes with Dave's IRC Ack.
> 
> Thanks,
> 
> Sean

Thanks as well :-)


Jonathan


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH] drm/udl: Fix unaligned memory access in udl_render_hline

2017-04-09 Thread Jonathan Neuschäfer
On SPARC, the udl driver filled my kernel log with these messages:

[186668.910612] Kernel unaligned access at TPC[76609c] 
udl_render_hline+0x13c/0x3a0

Use put_unaligned_be16 to avoid them. On x86 this results in the same
code, but on SPARC the compiler emits two single-byte stores.

Signed-off-by: Jonathan Neuschäfer 
---
 drivers/gpu/drm/udl/udl_transfer.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/udl/udl_transfer.c 
b/drivers/gpu/drm/udl/udl_transfer.c
index 917dcb978c2c..0c87b1ac6b68 100644
--- a/drivers/gpu/drm/udl/udl_transfer.c
+++ b/drivers/gpu/drm/udl/udl_transfer.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include "udl_drv.h"
@@ -163,7 +164,7 @@ static void udl_compress_hline16(
const u8 *const start = pixel;
const uint16_t repeating_pixel_val16 = pixel_val16;
 
-   *(uint16_t *)cmd = cpu_to_be16(pixel_val16);
+   put_unaligned_be16(pixel_val16, cmd);
 
cmd += 2;
pixel += bpp;
-- 
2.11.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel