Geert Uytterhoeven
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/renesas/shmobile/shmob_drm_plane.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/renesas/shmobile/shmob_drm_plane.c
> b/drivers/gpu/drm/renesas/shmobile/shmob_drm_plane.c
&
efinition for the primary plane.
>
> Fortunately both definitions resolve to the same value, so this bug did
> not cause any harm.
>
> Signed-off-by: Geert Uytterhoeven
With the typo in the commit message fixed,
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/renesas/
_LE isn't supported, I'd leave it out for
now. It can be added later once a driver needs it.
Reviewed-by: Laurent Pinchart
> Signed-off-by: Geert Uytterhoeven
> Cc: Mauro Carvalho Chehab
> Cc: linux-me...@vger.kernel.org
> ---
> .../media/v4l/subdev-format
Hi Geert,
Thank you for the patch.
On Thu, Jun 22, 2023 at 11:21:13AM +0200, Geert Uytterhoeven wrote:
> Add device tree bindings for the LCD Controller (LCDC) found in Renesas
> SuperH SH-Mobile and ARM SH/R-Mobile SOCs.
>
> Based on a plain text prototype by Laurent Pinchart.
>
> Signed-off-by: Geert Uytterhoeven
Reviewed-by: Laurent Pinchart
> ---
> v2:
> - Drop "first part" in drivers/gpu/drm/drm_plane_helper.c.
> ---
> drivers/gpu/drm/drm_plane_helper.c | 12 +-
> include/drm/drm_crtc.h | 5
tzimmermann/linux/tree/fbconv
> - - [2]
> https://gitlab.freedesktop.org/tzimmermann/linux/blob/fbconv/drivers/gpu/drm/drm_fbconv_helper.c
> + .. [4] https://gitlab.freedesktop.org/tzimmermann/linux/tree/fbconv
> + .. [5]
> https://gitlab.freedesktop.org/tzimmermann/linux/blob/fbconv/drivers/gpu/drm/drm_fbconv_helper.c
>
> Contact: Thomas Zimmermann
>
--
Regards,
Laurent Pinchart
format |= LDBBSIFR_AL_PK | LDBBSIFR_RY | LDBBSIFR_RPKF_ARGB32;
Reviewed-by: Laurent Pinchart
> break;
> case V4L2_PIX_FMT_NV12:
> case V4L2_PIX_FMT_NV21:
--
Regards,
Laurent Pinchart
Cc: Paul Cercueil
> Cc: Laurent Pinchart
> Cc: Sam Ravnborg
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/drm_bridge_connector.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_bridge_connector.c
> b/drivers/gpu/drm/d
Hi Thomas,
Thank you for the patch.
On Tue, Jun 20, 2023 at 02:03:23PM +0200, Thomas Zimmermann wrote:
> There are no external users of drm_gem_dma_vm_ops. Unexport the symbol.
>
> Signed-off-by: Thomas Zimmermann
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/drm_g
un-export a number of symbols
> from the GEM DMA helpers.
>
> Signed-off-by: Thomas Zimmermann
Nice simplification.
Reviewed-by: Laurent Pinchart
I assume you'll merge the whole series through drm-misc, please let me
know if that's not correct.
> ---
> drivers/gpu/
NULL;
> struct drm_bridge *bridge, *panel_bridge = NULL;
> - int connector_type;
> + int connector_type, ret;
With 'ret' declared on a separate line,
Reviewed-by: Laurent Pinchart
>
> bridge_connector = kzalloc(sizeof(*bridge_connector), GFP_KERNEL);
>
Hi Tomi,
Thank you for the patch.
On Mon, Jun 19, 2023 at 11:23:23AM +0300, Tomi Valkeinen wrote:
> Add drm-misc as the git tree for tilcdc and omapdrm. Change Tomi's email
> to point to ideasonboard.com instead of kernel.org.
>
> Signed-off-by: Tomi Valkeinen
Reviewed-by: Laur
evice.
>
> I think from dt point it is correct to have single device node for
> a device. even though device contains PMIC and RTC as separate functionality
> With shared resources like IRQ, PINS and Clocks as at the PMIC device is the
> one
> exposes to this to outside world.
>
> > > By instating a client device, we are sharing the relevant resources to
> > > RTC device driver.
> >
> > By instantiating a client device, you create a second struct device, which
> > is the kernel abstraction of a hardware device. This shows in my opinion
> > that we're dealing with two devices here, hence my recommendation of using
> > two DT nodes.
>
> Two DT nodes is the problem. DT maintainer's don't like it, for them it is
> just
> one device which provides PMIC/RTC functionality.
Have they followed this discussion ?
> > As you've noticed, with two devices and a single DT node, pinctrl
> > complains. You can hack around that by moving the pinctrl configuration
> > from the PMIC DT node to another DT node, and that's one first hack.
>
> PMIC device expose pins and it binds the pins during probe. Since it is a
> single device,
> we don't need to share this to RTC device. We just need to add pinctrl
> definitions
> in PMIC device node. This is not a hack.
>
> > Then, you'll need to have two different device IDs depending on the PMIC
> > version to let the RTC driver set the oscillator bit correctly, and that's
> > a second hack.
>
> PMIC has all the information, so it can instantiate and bind with the
> configuration
> needed for second device. So it is not a hack.
>
> > A solution with two DT nodes models the hardware better and is cleaner.
>
> But looks like all other people are happy with single DT node.
At the end of the day, it's not my driver, and not my subsystems, so
I'll let you make mistakes if you're happy with them. I still strongly
think it's a mistake, but I can't get everybody to do things right, can
I ? :-)
--
Regards,
Laurent Pinchart
t; > The last versions you posted did not have any pinctrl properties?
> > >
> > > By default, PMIC_INT# is not populated RZ/G2L SMARC EVK, so I haven't
> > > added
> > > Support for PMIC_INT# for the patches posted till date.
> > >
> > > Yesterday I checked with HW people, is there a way to enable PMIC_INT#
> > > and they told me to do the above HW modification.
> > >
> > > Today I found this issue, with this modified HW and PMIC INT# enabled on
> > > the DT,
> > > while assigning of_node of PMIC with info.of_node. It is just a
> > > coincidence.
> >
> > IC.
> >
> > So you now have two Linux devices pointing to the same DT node,
> > causing pinctrl issues...
>
> So don't set info.of_node? ;-)
>
> Without of_node, devm_clk_get() and friends falls back to registered
> clkdevs. So you could call clk_register_clkdev() from within the
> PMIC driver, and can keep on using devm_clk_get_optional() in the
> ISL1208 driver.
Seriously, how many hacks are we piling ? :-)
> If that fails, there's also software_node.properties, or even the good
> old platform_data...
--
Regards,
Laurent Pinchart
, clocks, pinctrl and IRQ properties.
> So it will be represented as single node with single compatible.
The chip is a single package that contains two independent devices. This
is not different than bundling many IP cores in an SoC, we have one DT
node per IP core, not a single DT node for the SoC. The fact that we're
dealing with an external physical component here isn't relevant.
> By instating a client device, we are sharing the relevant resources to
> RTC device driver.
By instantiating a client device, you create a second struct device,
which is the kernel abstraction of a hardware device. This shows in my
opinion that we're dealing with two devices here, hence my
recommendation of using two DT nodes.
As you've noticed, with two devices and a single DT node, pinctrl
complains. You can hack around that by moving the pinctrl configuration
from the PMIC DT node to another DT node, and that's one first hack.
Then, you'll need to have two different device IDs depending on the PMIC
version to let the RTC driver set the oscillator bit correctly, and
that's a second hack.
A solution with two DT nodes models the hardware better and is cleaner.
--
Regards,
Laurent Pinchart
fo" as it results in pinctrl
> > failure. info->platformdata and
> > Client->dev.platformdata to retrieve this info??
>
> Or
>
> I2C instantiation based on actual oscillator bit value, ie, two
> i2c_device_id's
> with one for setting oscillator bit and another for clearing oscillator bit
>
> PMIC driver parses the clock details. Based on firmware version and clock,
> It instantiates either i2c_device_id with setting oscillator bit or
> clearing oscillator bit.
I don't like that hack. I still think that two DT nodes is the best
option, I think you're trying hard to hack around a problem that is
actually not a problem.
--
Regards,
Laurent Pinchart
Hi Geert,
On Mon, Jun 12, 2023 at 03:08:46PM +0200, Geert Uytterhoeven wrote:
> On Mon, Jun 12, 2023 at 2:54 PM Laurent Pinchart wrote:
> > On Mon, Jun 12, 2023 at 12:42:33PM +, Biju Das wrote:
> > > > Subject: Re: [PATCH v5 01/11] i2c: Enhance i2c_new_ancillary_device AP
On Mon, Jun 12, 2023 at 02:44:33PM +0200, Geert Uytterhoeven wrote:
> On Mon, Jun 12, 2023 at 2:23 PM Laurent Pinchart wrote:
> > On Mon, Jun 12, 2023 at 09:53:02AM +, Biju Das wrote:
> > > Hi All,
> > >
> > > How do we proceed here between [1] and [2]?
&
ting "renesas,invert-xtoscb" is OK
> for
> the relevant maintainers??
It's fine with me at least :-) I think a property makes sense, as it
describes the device. Updating the device tree in the boot loader based
on auto-detection of features is also fairly common (to set the
n";
> renesas,raa215300-pmic = <>; /* Parse the handle to get
> PMIC version to check Oscillator bit is inverted or not */
This isn't nice. I would instead add a renesas,invert-xtoscb boolean
property. If you don't want different DT sources for different revisions
remove callback returning void
> drm/mediatek: Convert to platform remove callback returning void
> drm/kmb: Convert to platform remove callback returning void
> drm/ingenic: Convert to platform remove callback returning void
> drm/imx/ipuv3: Convert to platform remove callback returning void
> drm/imx/dcss: Convert to platform remove callback returning void
> drm/etnaviv: Convert to platform remove callback returning void
> drm/armada: Convert to platform remove callback returning void
--
Regards,
Laurent Pinchart
the oscillator bit being set correctly,
or is that used for the RTC only ?
> > > If XIN and XOUT not connected RTC operation not possible.
> > >
> > > IRQ# (optional) functionality is shared between PMIC and RTC. (PMIC
> > > fault for various bucks/LDOs/WDT/OTP/NVM and alarm condition).
> >
> > IRQs can be shared between multiple devices so this shouldn't be a
> > problem.
>
> OK. How do we represent this IRQ in DT?
You can simply reference the same IRQ from the interrupts property of
different DT nodes.
> > > The board, I have doesn't populate IRQ# pin. If needed some customers
> > > can populate IRQ# pin and use it for PMIC fault and RTC alarm.
> > >
> > > Also, currently my board has PMIC rev a0 where oscillator bit is
> > > inverted and internal oscillator is enabled (ie: XIN and XOUT is
> > > connected to external crystal)
--
Regards,
Laurent Pinchart
T not connected RTC operation not possible.
>
> IRQ# (optional) functionality is shared between PMIC and RTC. (PMIC
> fault for various bucks/LDOs/WDT/OTP/NVM or alarm condition).
IRQs can be shared between multiple devices so this shouldn't be a
problem.
> The board, I have doesn't populate IRQ# pin. If needed some customers
> can populate IRQ# pin and use it for PMIC fault or RTC alarm.
>
> Also, currently my board has PMIC rev a0 where oscillator bit is
> inverted and internal oscillator is enabled (ie: XIN and XOUT is
> connected to external crystal)
--
Regards,
Laurent Pinchart
Hi Alexander,
On Wed, Jun 07, 2023 at 01:26:03PM +0200, Alexander Stein wrote:
> Am Dienstag, 6. Juni 2023, 17:12:29 CEST schrieb Laurent Pinchart:
> > On Tue, Jun 06, 2023 at 04:48:33PM +0200, Alexander Stein wrote:
> > > When -EPROBE_DEFER is returned do not raise an error, b
t;dev, DMA_BIT_MASK(ZYNQMP_DISP_MAX_DMA_BIT));
> + ret = dma_set_mask(dpsub->dev, DMA_BIT_MASK(ZYNQMP_DISP_MAX_DMA_BIT));
> + if (ret)
> + return ret;
This seems reasonable.
Reviewed-by: Laurent Pinchart
Tomi, would you be able to quickly test this ?
>
>
On Tue, Jun 06, 2023 at 11:47:50PM +0530, Siddh Raman Pant wrote:
> On Tue, 06 Jun 2023 23:19:28 +0530, Laurent Pinchart wrote:
> > The idea would be to include the drm_print_deprecated.h header in
> > drivers that still use the deprecated macros.
>
> Yeah, what I meant was i
Hi Jani,
On Wed, Jun 07, 2023 at 12:39:44AM +0300, Jani Nikula wrote:
> On Tue, 06 Jun 2023, Laurent Pinchart wrote:
> > On Tue, Jun 06, 2023 at 04:15:22PM +0530, Siddh Raman Pant wrote:
> >> drm_print.h says DRM_DEBUG_KMS is deprecated in favor of
> >> drm_dbg_kms().
On Tue, Jun 06, 2023 at 10:59:14PM +0530, Siddh Raman Pant wrote:
> On Tue, 06 Jun 2023 20:35:45 +0530, Laurent Pinchart wrote:
> > This is a nice series, thank you for working on that.
> >
> > Now that the deprecated macros are used in drivers only, would it make
&
On Tue, Jun 06, 2023 at 10:36:25PM +0530, Siddh Raman Pant wrote:
> On Tue, 06 Jun 2023 20:14:52 +0530, Laurent Pinchart wrote:
> > Hi Siddh,
> >
> > Thank you for the patch.
>
> Anytime :)
>
> > > if (!crtcs || !modes || !enabled || !offsets)
When not called from a probe path, dropping the message will result in a
silent error, which would be hard to debug :-(
> @@ -357,6 +358,7 @@ int drm_bridge_attach(struct drm_encoder *encoder, struct
> drm_bridge *bridge,
> DRM_ERROR("failed to attach bridge to encoder %s: %d\n",
> encoder->name, ret);
> #endif
> + }
>
> return ret;
> }
--
Regards,
Laurent Pinchart
rm/drm_modeset_helper.c| 2 +-
> drivers/gpu/drm/drm_pci.c | 14 +--
> drivers/gpu/drm/drm_plane.c | 46 -
> drivers/gpu/drm/drm_probe_helper.c | 39
> drivers/gpu/drm/drm_rect.c | 4 +-
> drivers/gpu/drm/drm_scatter.c | 19 ++--
> drivers/gpu/drm/drm_syncobj.c | 2 +-
> drivers/gpu/drm/drm_sysfs.c | 22 ++---
> drivers/gpu/drm/drm_vm.c| 45 +
> include/drm/drm_print.h | 81 ++--
> 40 files changed, 480 insertions(+), 423 deletions(-)
--
Regards,
Laurent Pinchart
d\n",
> + base->rev, base->bytes, base->prod_id, base->ext_count);
>
> /* +1 for DispID checksum */
> dispid_length = sizeof(*base) + base->bytes + 1;
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 0454
, "OBJ ID: %d (%d)\n", obj->id,
> + kref_read(>refcount));
> kref_put(>refcount, obj->free_cb);
> }
> }
> @@ -209,7 +210,8 @@ EXPORT_SYMBOL(drm_mode_object_put);
> void drm_mode_object_get(struct drm_mode_object *obj)
On Tue, Jun 06, 2023 at 08:04:39PM +0530, Siddh Raman Pant wrote:
> On Tue, 06 Jun 2023 19:35:12 +0530, Laurent Pinchart wrote:
> > Hi Siddh,
> >
> > Thank you for the patch.
>
> Anytime :)
>
> > On Tue, Jun 06, 2023 at 04:15:16PM +0530, Siddh Raman P
On Tue, Jun 06, 2023 at 08:08:27PM +0530, Siddh Raman Pant wrote:
> On Tue, 06 Jun 2023 19:53:22 +0530, Laurent Pinchart wrote:
> > Hi Siddh,
> >
> > Thank you for the patch.
>
> Anytime :)
>
> > Any plan to remove it from drivers as well ? If not you shou
gem.c b/drivers/gpu/drm/drm_gem.c
> index 1a5a2cd0d4ec..e0d52e69df15 100644
> --- a/drivers/gpu/drm/drm_gem.c
> +++ b/drivers/gpu/drm/drm_gem.c
> @@ -101,7 +101,7 @@ drm_gem_init(struct drm_device *dev)
> vma_offset_manager = drmm_kzalloc(dev, sizeof(*vma_offset_manager),
>
ier
patch in this series,
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/drm_displayid.c | 2 +-
> drivers/gpu/drm/drm_kms_helper_common.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_displayid.c b/drivers/gpu/drm/drm_displ
(NULL, "SPI speed: %uMHz\n", spi->max_speed_hz / 100);
We don't have access to a struct drm_device pointer here, but we have
access to a struct device through spi_device. It's quite annoying to be
forced by drm_dbg_driver() to use NULL. This isn't a regression, so I'm
fine
drm/drm_pci.c b/drivers/gpu/drm/drm_pci.c
> index 39d35fc3a43b..7dfb837d1325 100644
> --- a/drivers/gpu/drm/drm_pci.c
> +++ b/drivers/gpu/drm/drm_pci.c
> @@ -262,7 +262,7 @@ void drm_legacy_pci_exit(const struct drm_driver *driver,
> }
> mutex_unlock(_dev_list_lock);
> }
> - DRM_INFO("Module unloaded\n");
> + drm_info(NULL, "Module unloaded\n");
> }
> EXPORT_SYMBOL(drm_legacy_pci_exit);
>
--
Regards,
Laurent Pinchart
_debug_enabled(DRM_UT_ ## category) && __ratelimit(_))
> \
> - drm_dev_printk(drm_ ? drm_->dev : NULL, KERN_DEBUG, fmt, ##
> __VA_ARGS__); \
> +#define __DRM_DEFINE_DBG_RATELIMITED(category, drm, fmt, ...)
> \
> +({ \
> + static DEFINE_RATELIMIT_STATE(rs_, DEFAULT_RATELIMIT_INTERVAL, \
> + DEFAULT_RATELIMIT_BURST); \
> + \
> + if (drm_debug_enabled(DRM_UT_ ## category) && __ratelimit(_))\
> + drm_dev_printk(__drm_dev_ptr(drm), KERN_DEBUG, \
> +fmt, ## __VA_ARGS__);\
> })
>
> #define drm_dbg_kms_ratelimited(drm, fmt, ...) \
--
Regards,
Laurent Pinchart
ommit passed mipi_dsi_host ptr.
> It worked by accident due to macro magic.
>
> Reported-by: Jani Nikula
> Reviewed-by: Jani Nikula
> Signed-off-by: Siddh Raman Pant
Reviewed-by: Laurent Pinchart
Any chance we could prevent this from happening by turning the macros
into inline fu
On Sun, Jun 04, 2023 at 10:45:07PM +0900, Masahiro Yamada wrote:
> On Sun, Jun 4, 2023 at 10:26 PM Laurent Pinchart wrote:
> > On Sun, Jun 04, 2023 at 04:57:12PM +0900, Masahiro Yamada wrote:
> > > With CONFIG_DRM_IMX8QM_LDB=m and CONFIG_DRM_IMX8QXP_LDB=y (or vice
> > &g
db.c
> diff --git a/drivers/gpu/drm/bridge/imx/imx8qxp-ldb-drv.c
> b/drivers/gpu/drm/bridge/imx/imx8qxp-ldb.c
> similarity index 100%
> rename from drivers/gpu/drm/bridge/imx/imx8qxp-ldb-drv.c
> rename to drivers/gpu/drm/bridge/imx/imx8qxp-ldb.c
--
Regards,
Laurent Pinchart
ruct drm_bridge_funcs *bridge_funcs)
> @@ -204,6 +217,7 @@ void ldb_add_bridge_helper(struct ldb *ldb,
> drm_bridge_add(_ch->bridge);
> }
> }
> +EXPORT_SYMBOL_GPL(ldb_add_bridge_helper);
>
> void ldb_remove_bridge_helper(struct ldb *ldb)
> {
> @@ -219,3 +233,9 @@ void ldb_remove_bridge_helper(struct ldb *ldb)
> drm_bridge_remove(_ch->bridge);
> }
> }
> +EXPORT_SYMBOL_GPL(ldb_remove_bridge_helper);
> +
> +MODULE_DESCRIPTION("i.MX8 LVDS Display Bridge(LDB)/Pixel Mapper bridge
> helper");
> +MODULE_AUTHOR("Liu Ying ");
> +MODULE_LICENSE("GPL");
> +MODULE_ALIAS("platform:" DRIVER_NAME);
Is the alias needed ? With that fixed (if needed),
Reviewed-by: Laurent Pinchart
--
Regards,
Laurent Pinchart
This should have read v3.
On Sun, Jun 04, 2023 at 01:49:58PM +0300, Laurent Pinchart wrote:
> The (large) rcar_du_modeset_init() function can fail for many reasons,
> two of two involving probe deferral. Use dev_err_probe() in those code
> paths to record the cause of the probe deferral,
The (large) rcar_du_modeset_init() function can fail for many reasons,
two of two involving probe deferral. Use dev_err_probe() in those code
paths to record the cause of the probe deferral, in order to help
debugging probe issues.
Signed-off-by: Laurent Pinchart
---
Change since v1:
- Fix
involving probe deferral. Use dev_err_probe() in those code
> > paths to record the cause of the probe deferral, in order to help
> > debugging probe issues.
> >
> > Signed-off-by: Laurent Pinchart
> > ---
> > drivers/gpu/drm/renesas/rcar-du/rcar_du_drv.c | 4
>
ch->is_available = true;
> + ldb_ch->np = child;
> +
> + ldb->available_ch_cnt++;
> + }
> +
> + return 0;
> +}
> +
> +static inline int ldb_find_next_bridge_helper(struct ldb *ldb)
> +{
> + struct device *dev = ldb->dev;
>
+ err = -ENOMEM;
> + goto free_ddc;
> + }
> +
> + override_desc->bus_format = ret;
> + override_desc->bpc = bpc;
> + panel->desc = override_desc;
> + }
> + }
> +
> connector_type = desc->connector_type;
> /* Catch common mistakes for panels. */
> switch (connector_type) {
--
Regards,
Laurent Pinchart
e = "innolux,g101ice-l01";
> + power-supply = <_lcd_reg>;
> +
> + data-mapping = "jeida-24";
> +
> + port {
> +panel_in_lvds: endpoint {
> + remote-endpoint = <_out_lvds>;
> +};
> + };
> +};
>
--
Regards,
Laurent Pinchart
> +$id: http://devicetree.org/schemas/display/lvds-data-mapping.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: LVDS Data Mapping
> +
> +maintainers:
> + - Laurent Pinchart
> + - Thierry Reding
> +
> +description: |+
> + LVDS is a physic
Hi Geert,
On Fri, Jun 02, 2023 at 01:17:58PM +0200, Geert Uytterhoeven wrote:
> On Fri, Jun 2, 2023 at 1:05 PM Laurent Pinchart wrote:
> > On Fri, Jun 02, 2023 at 11:11:35AM +0200, Geert Uytterhoeven wrote:
> > > The transitional helpers were removed a long time ago, but som
uot;, dev_name(>dev));
> >
> > Use drm_info().
>
> Agreed.
>
> > > +
> > > + drm_fbdev_generic_setup(>ddev, 32);
> > > +
> > > + return 0;
> > > +
> > > +error:
> > > + drm_kms_helper_poll_fini(>ddev);
> > > + return ret;
> > > +}
[snip]
> > > diff --git a/drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.h
> > > b/drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.h
> > > new file mode 100644
> > > index ..3b84e91aa64a
> > > --- /dev/null
> > > +++ b/drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.h
> > > @@ -0,0 +1,89 @@
[snip]
> > > +enum rzg2l_du_output {
> > > + RZG2L_DU_OUTPUT_DSI0,
> > > + RZG2L_DU_OUTPUT_DPAD0,
> > > + RZG2L_DU_OUTPUT_MAX,
> > > +};
> > > +
> > > +/*
> > > + * struct rzg2l_du_output_routing - Output routing specification
> > > + * @possible_crtcs: bitmask of possible CRTCs for the output
> > > + * @port: device tree port number corresponding to this output route
> > > + *
> > > + * The DU has 2 possible outputs (DPAD0, DSI0). Output routing data
> > > + * specify the valid SoC outputs, which CRTCs can drive the output, and
> > > the type
> > > + * of in-SoC encoder for the output.
> > > + */
> > > +struct rzg2l_du_output_routing {
> > > + unsigned int possible_crtcs;
> > > + unsigned int port;
> > > +};
> > > +
> > > +/*
> > > + * struct rzg2l_du_device_info - DU model-specific information
> > > + * @channels_mask: bit mask of available DU channels
> > > + * @routes: array of CRTC to output routes, indexed by output
> > > (RZG2L_DU_OUTPUT_*)
> > > + */
> > > +struct rzg2l_du_device_info {
> > > + unsigned int channels_mask;
> > > + struct rzg2l_du_output_routing routes[RZG2L_DU_OUTPUT_MAX];
> > > +};
> >
> > The driver supports a single SoC, with two outputs, connected to the
> > same DU channel. Do you really need to copy the rzg2l_du_device_info
> > abstraction from the rcar-du driver, or could you simplify the code ?
>
> After adding basic support, as an optimization
> will simplify the code later. Hope it is ok for you??
I'm OK with patches on top. Please don't forget about them :-)
[snip]
--
Regards,
Laurent Pinchart
esas}/shmobile/shmob_drm_drv.c (100%)
rename drivers/gpu/drm/{ => renesas}/shmobile/shmob_drm_drv.h (100%)
rename drivers/gpu/drm/{ => renesas}/shmobile/shmob_drm_kms.c (100%)
rename drivers/gpu/drm/{ => renesas}/shmobile/shmob_drm_kms.h (100%)
rename drivers/gpu/drm/{ => renesas}/shmobile/shmob_drm_plane.c (100%)
rename drivers/gpu/drm/{ => renesas}/shmobile/shmob_drm_plane.h (100%)
rename drivers/gpu/drm/{ => renesas}/shmobile/shmob_drm_regs.h (100%)
--
Regards,
Laurent Pinchart
;
> > OK, I will do so. I've reviewed 4/5 in the meantime, but changes are
> > needed, so I won't wait for v10 before applying 1/5.
>
> I have incorporated review comments for v9. I need to rebase my changes.
>
> Is the pull request being done to drm-misc-next?
I've just sen
exists, but is part of drm_atomic_helper_check_plane_state().
>
> Signed-off-by: Geert Uytterhoeven
Reviewed-by: Laurent Pinchart
> ---
> Interestingly, all these comments appeared only after the commit that
> removed the function...
>
> This is against next-20230602, which does not have the
>
> void (*atomic_update)(struct drm_plane *plane,
> struct drm_atomic_state *state);
> @@ -1376,9 +1371,8 @@ struct drm_plane_helper_funcs {
>* has picked. See drm_atomic_helper_commit_planes() for a discussion of
>* the tradeoffs and variants of plane commit helpers.
>*
> - * This callback is used by the atomic modeset helpers and by the
> - * transitional plane helpers, but it is optional. It's intended to
> - * reverse the effects of @atomic_enable.
> + * This callback is used by the atomic modeset helpers, but it is
> + * optional. It's intended to reverse the effects of @atomic_enable.
>*/
> void (*atomic_disable)(struct drm_plane *plane,
> struct drm_atomic_state *state);
--
Regards,
Laurent Pinchart
non-converted driver (again virtual HW drivers for KVM are still all
> -suitable).
> +suitable). The "Atomic mode setting design overview" series [2][3] at
s/ / /
Reviewed-by: Laurent Pinchart
> +LWN.net can also be helpful.
>
> As part of this drivers also need t
Hi Geert,
On Wed, May 31, 2023 at 02:51:48PM +0200, Geert Uytterhoeven wrote:
> On Wed, May 31, 2023 at 10:59 AM Laurent Pinchart wrote:
> > On Mon, May 29, 2023 at 09:00:43AM +, Biju Das wrote:
> > > > Subject: Re: [PATCH v5 01/11] i2c: Enhance i2c_new_ancillary_device A
this function, where the caller gets the name from.
> > >
> > > Are you ok with these wordings?
> > >
> > > * This function creates and returns an I2C ancillary client whose I2C
> > > address
> > > * is retrieved from the platform firmware based on the given slave name.
> > > If
> > > * aux_device_name is not NULL, the ancillary's device parent
> > > * will be set to the primary device otherwise it will be set to I2C
> > > adapter.
> >
> > The wording is better, but this is not what you have implemented in the
> > code. The name doesn't select which parent is used.
>
> It is the same implemented in the code.
>
> For the existing users, aux_device_name is NULL --> The parent is set
> as "I2C adapter".
>
> For instantiating a "i2c client device", aux_device_name is not NULL
> --> The parent is set as primary device.
>
> The primary device is the one instantiated the "i2c client device" using
> i2c_new_ancillary_device().
>
> Please correct me if anything wrong here.
Before your patch:
struct i2c_client *i2c_new_ancillary_device(struct i2c_client *client,
const char *name,
u16 default_addr)
{
[...]
return i2c_new_dummy_device(client->adapter, addr);
}
struct i2c_client *i2c_new_dummy_device(struct i2c_adapter *adapter, u16
address)
{
struct i2c_board_info info = {
I2C_BOARD_INFO("dummy", address),
};
return i2c_new_client_device(adapter, );
}
struct i2c_client *
i2c_new_client_device(struct i2c_adapter *adap, struct i2c_board_info const
*info)
{
struct i2c_client *client;
int status;
client = kzalloc(sizeof *client, GFP_KERNEL);
if (!client)
return ERR_PTR(-ENOMEM);
client->adapter = adap;
[...]
client->dev.parent = >adapter->dev;
[...]
return client;
[...]
}
i2c_new_ancillary_device() returns an i2c_client with client->dev.parent
set to the I2C adapter device.
After your patch:
struct i2c_client *i2c_new_ancillary_device(struct i2c_client *client,
const char *name,
u16 default_addr,
const char *aux_device_name)
{
[...]
return __i2c_new_dummy_device(client->adapter, addr, aux_device_name,
>dev);
}
static struct i2c_client *__i2c_new_dummy_device(struct i2c_adapter *adapter,
u16 address, const char *name,
struct device *parent)
{
struct i2c_board_info info = {
I2C_BOARD_INFO("dummy", address),
};
[...]
return __i2c_new_client_device(adapter, , parent);
}
static struct i2c_client *
__i2c_new_client_device(struct i2c_adapter *adap,
struct i2c_board_info const *info,
struct device *parent)
{
struct i2c_client *client;
int status;
client = kzalloc(sizeof *client, GFP_KERNEL);
if (!client)
return ERR_PTR(-ENOMEM);
client->adapter = adap;
[...]
client->dev.parent = parent ? parent : >adapter->dev;
[...]
return client;
[...]
}
i2c_new_ancillary_device() returns an i2c_client with client->dev.parent
set to the main i2c_client device, *regardless* of the value of the
aux_device_name parameter.
The behaviour of i2c_new_ancillary_device() has changed for existing
users.
> > > * If no address is specified by the firmware default_addr is used.
> > >
> > > > > > > the ancillary's device parent
> > > > > > > + * will be set to the primary device.
> > > > > >
> > > > > > This doesn't seem to match the implementation. With this patch
> > > > > > the ancillary device's parent is always the primary device. Are
> > > > > > you sure this won't cause any regression ?
> > > > >
> > > > > There is no regression as existing users only instantiate dummy
> > > > > device.
> > > >
> > > > Sorry, I don't follow you here. Existing callers of
> > > > i2c_new_ancillary_device() today get an i2c_client device whose
> > > > parent is the I2C adapter. With this patch they will get an
> > > > i2c_client device whose parent is the main i2c_client. That's a
> > > > change in behaviour, which could cause all sorts of issues.
> > >
> > > Please see the patch snippet below, there is no regression.
> > >
> > > client->dev.parent = parent ? parent : >adapter->dev;
> >
> > When called from i2c_new_ancillary_device(), __i2c_new_dummy_device() as
> > a non-NULL parent argument. There is no change of behaviour *for
> > i2c_new_dummy_device()*, but thre is a change of behaviour *for
> > i2c_new_ancillary_device()*.
>
> I don't think I understand what you mean.
>
> For existing users, i2c_new_ancillary_device(...,
> aux_device_name=NULL) the behaviour is not changed.
>
> Could you please elaborate further?
>
> > > > > > And why do you need this ?
> > > > >
> > > > > As per Krzysztof [2],
> > > > >
> > > > > The DT schema allows multiple addresses for children. But we lack
> > > > > implementation of parent child relationship, As parent owns the
> > > > > resources.
> > > > > Child device needs to parse parent node to get some resource like
> > > > > clocks.
> > > > >
> > > > > [2]
> > > >
> > > > The I2C ancillary clients are not meant to be handled by separate
> > > > drivers.
> > >
> > > Is it a Linux rule??
> >
> > It's an I2C subsystem rule as far as I can tell. This is how it has been
> > designed.
>
> Wolfram/Geert:
>
> Do you agree with Laurent's statement?
--
Regards,
Laurent Pinchart
gt; > i2c_client instances for the secondary I2C addresses. Those i2c_client
> > instances are not bound to a separate driver,
>
> Wolfram/Geert, Is it limitation from i2c?
>
> > so there should be no code
> > that needs to look at the parent for resources.
> >
> > > > > If no address is specified by the firmware
> > > > > + * default_addr is used. If no aux_device_name is specified by
> > > > > + the firmware, it
> > > >
> > > > Same here regarding firmware.
> > > >
> > > > > + * will create an I2C dummy client.
> > > > > *
> > > > > * On DT-based platforms the address is retrieved from the "reg"
> > property entry
> > > > > * cell whose "reg-names" value matches the slave name.
> > > > > @@ -1139,8 +1167,9 @@
> > EXPORT_SYMBOL_GPL(devm_i2c_new_dummy_device);
> > > > > * i2c_unregister_device(); or an ERR_PTR to describe the error.
> > > > > */
> > > > > struct i2c_client *i2c_new_ancillary_device(struct i2c_client
> > *client,
> > > > > - const char *name,
> > > > > - u16 default_addr)
> > > > > + const char *name,
> > > > > + u16 default_addr,
> > > > > + const char *aux_device_name)
> > > > > {
> > > > > struct device_node *np = client->dev.of_node;
> > > > > u32 addr = default_addr;
> > > > > @@ -1153,7 +1182,8 @@ struct i2c_client
> > *i2c_new_ancillary_device(struct i2c_client *client,
> > > > > }
> > > > >
> > > > > dev_dbg(>adapter->dev, "Address for %s : 0x%x\n",
> > name, addr);
> > > > > - return i2c_new_dummy_device(client->adapter, addr);
> > > > > + return __i2c_new_dummy_device(client->adapter, addr,
> > aux_device_name,
> > > > > + >dev);
> > > > > }
> > > > > EXPORT_SYMBOL_GPL(i2c_new_ancillary_device);
> > > > >
> > > > > diff --git a/drivers/media/i2c/adv748x/adv748x-core.c
> > > > > b/drivers/media/i2c/adv748x/adv748x-core.c
> > > > > index 4498d78a2357..5bdf7b0c6bf3 100644
> > > > > --- a/drivers/media/i2c/adv748x/adv748x-core.c
> > > > > +++ b/drivers/media/i2c/adv748x/adv748x-core.c
> > > > > @@ -186,7 +186,7 @@ static int adv748x_initialise_clients(struct
> > > > adv748x_state *state)
> > > > > state->i2c_clients[i] = i2c_new_ancillary_device(
> > > > > state->client,
> > > > > adv748x_default_addresses[i].name,
> > > > > -
> > adv748x_default_addresses[i].default_addr);
> > > > > +
> > > > > adv748x_default_addresses[i].default_addr,
> > > > NULL);
> > > > >
> > > > > if (IS_ERR(state->i2c_clients[i])) {
> > > > > adv_err(state, "failed to create i2c client
> > %u\n", i);
> > > > diff --git
> > > > > a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c index
> > > > > 3d0898c4175e..63fa44c9d27c 100644
> > > > > --- a/drivers/media/i2c/adv7604.c
> > > > > +++ b/drivers/media/i2c/adv7604.c
> > > > > @@ -2935,7 +2935,8 @@ static struct i2c_client
> > > > *adv76xx_dummy_client(struct v4l2_subdev *sd,
> > > > > else
> > > > > new_client = i2c_new_ancillary_device(client,
> > > > > adv76xx_default_addresses[page].name,
> > > > > -
> > adv76xx_default_addresses[page].default_addr);
> > > > > +
> > adv76xx_default_addresses[page].default_addr,
> > > > > + NULL);
> > > > >
> > > > > if (!IS_ERR(new_client))
> > > > > io_write(sd, io_reg, new_client->addr << 1); diff --
> > git
> > > > > a/include/linux/i2c.h b/include/linux/i2c.h index
> > > > > 13a1ce38cb0c..0ce344724209 100644
> > > > > --- a/include/linux/i2c.h
> > > > > +++ b/include/linux/i2c.h
> > > > > @@ -489,7 +489,8 @@ devm_i2c_new_dummy_device(struct device *dev,
> > > > > struct i2c_adapter *adap, u16 addr struct i2c_client *
> > > > > i2c_new_ancillary_device(struct i2c_client *client,
> > > > >const char *name,
> > > > > - u16 default_addr);
> > > > > + u16 default_addr,
> > > > > + const char *aux_device_name);
> > > > >
> > > > > void i2c_unregister_device(struct i2c_client *client);
> > > > >
--
Regards,
Laurent Pinchart
e *np = client->dev.of_node;
> > > u32 addr = default_addr;
> > > @@ -1153,7 +1182,8 @@ struct i2c_client *i2c_new_ancillary_device(struct
> > > i2c_client *client,
> > > }
> > >
> > > dev_dbg(>adapter->dev, "Address for %s : 0x%x\n", name, addr);
> > > - return i2c_new_dummy_device(client->adapter, addr);
> > > + return __i2c_new_dummy_device(client->adapter, addr, aux_device_name,
> > > + >dev);
> > > }
> > > EXPORT_SYMBOL_GPL(i2c_new_ancillary_device);
> > >
> > > diff --git a/drivers/media/i2c/adv748x/adv748x-core.c
> > > b/drivers/media/i2c/adv748x/adv748x-core.c
> > > index 4498d78a2357..5bdf7b0c6bf3 100644
> > > --- a/drivers/media/i2c/adv748x/adv748x-core.c
> > > +++ b/drivers/media/i2c/adv748x/adv748x-core.c
> > > @@ -186,7 +186,7 @@ static int adv748x_initialise_clients(struct
> > adv748x_state *state)
> > > state->i2c_clients[i] = i2c_new_ancillary_device(
> > > state->client,
> > > adv748x_default_addresses[i].name,
> > > - adv748x_default_addresses[i].default_addr);
> > > + adv748x_default_addresses[i].default_addr,
> > NULL);
> > >
> > > if (IS_ERR(state->i2c_clients[i])) {
> > > adv_err(state, "failed to create i2c client %u\n", i);
> > diff --git
> > > a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c index
> > > 3d0898c4175e..63fa44c9d27c 100644
> > > --- a/drivers/media/i2c/adv7604.c
> > > +++ b/drivers/media/i2c/adv7604.c
> > > @@ -2935,7 +2935,8 @@ static struct i2c_client
> > *adv76xx_dummy_client(struct v4l2_subdev *sd,
> > > else
> > > new_client = i2c_new_ancillary_device(client,
> > > adv76xx_default_addresses[page].name,
> > > - adv76xx_default_addresses[page].default_addr);
> > > + adv76xx_default_addresses[page].default_addr,
> > > + NULL);
> > >
> > > if (!IS_ERR(new_client))
> > > io_write(sd, io_reg, new_client->addr << 1); diff --git
> > > a/include/linux/i2c.h b/include/linux/i2c.h index
> > > 13a1ce38cb0c..0ce344724209 100644
> > > --- a/include/linux/i2c.h
> > > +++ b/include/linux/i2c.h
> > > @@ -489,7 +489,8 @@ devm_i2c_new_dummy_device(struct device *dev,
> > > struct i2c_adapter *adap, u16 addr struct i2c_client *
> > > i2c_new_ancillary_device(struct i2c_client *client,
> > >const char *name,
> > > - u16 default_addr);
> > > + u16 default_addr,
> > > + const char *aux_device_name);
> > >
> > > void i2c_unregister_device(struct i2c_client *client);
> > >
--
Regards,
Laurent Pinchart
The (large) rcar_du_modeset_init() function can fail for many reasons,
two of two involving probe deferral. Use dev_err_probe() in those code
paths to record the cause of the probe deferral, in order to help
debugging probe issues.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/renesas
Hi Geert,
On Tue, May 30, 2023 at 11:38:44AM +0200, Geert Uytterhoeven wrote:
> On Tue, May 30, 2023 at 11:34 AM Laurent Pinchart wrote:
> > Replace manual handling of EPROBE_DEFER with dev_err_probe() to simplify
> > the code.
> >
> > Signed-off-by: Laurent Pinchart
drm_info() adds proper context to the kernel log message, as it receives
the drm_device pointer. It is thus preferred over DRM_INFO(). Replace
the latter with the former.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/renesas/rcar-du/rcar_du_drv.c | 2 +-
1 file changed, 1 insertion(+), 1
Replace manual handling of EPROBE_DEFER with dev_err_probe() to simplify
the code.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/renesas/rcar-du/rcar_du_drv.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/renesas/rcar-du/rcar_du_drv.c
b/drivers
; > > Please let me know your preference.
> > >
> > > Cheers,
> > > Biju
> > >
> > >
> > > > -Original Message-
> > > > From: Biju Das
> > > > Sent: Monday, May 15, 2023 8:58 AM
> > > > To: David Airl
Hi Biju,
Thank you for the patch.
This is a partial review, because the driver is big, and because some
changes in v10 will (hopefully) simplify the code and make review
easier.
On Tue, May 02, 2023 at 11:09:11AM +0100, Biju Das wrote:
> The LCD controller is composed of Frame Compression
id Airlie ; Daniel Vetter ;
> > Philipp Zabel ; Geert Uytterhoeven
> > ; Laurent Pinchart
> > ; Kieran Bingham
> >
> > Cc: dri-devel@lists.freedesktop.org; linux-renesas-...@vger.kernel.org;
> > Fabrizio Castro ; Prabhakar Mahadev Lad
> >
> > Subject: RE:
/bindings/display/renesas,rzg2l-du.yaml
> @@ -0,0 +1,124 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/renesas,rzg2l-du.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +titl
0898c4175e..63fa44c9d27c 100644
> --- a/drivers/media/i2c/adv7604.c
> +++ b/drivers/media/i2c/adv7604.c
> @@ -2935,7 +2935,8 @@ static struct i2c_client *adv76xx_dummy_client(struct
> v4l2_subdev *sd,
> else
> new_client = i2c_new_ancillary_device(client,
> adv76xx_default_addresses[page].name,
> - adv76xx_default_addresses[page].default_addr);
> + adv76xx_default_addresses[page].default_addr,
> + NULL);
>
> if (!IS_ERR(new_client))
> io_write(sd, io_reg, new_client->addr << 1);
> diff --git a/include/linux/i2c.h b/include/linux/i2c.h
> index 13a1ce38cb0c..0ce344724209 100644
> --- a/include/linux/i2c.h
> +++ b/include/linux/i2c.h
> @@ -489,7 +489,8 @@ devm_i2c_new_dummy_device(struct device *dev, struct
> i2c_adapter *adap, u16 addr
> struct i2c_client *
> i2c_new_ancillary_device(struct i2c_client *client,
>const char *name,
> - u16 default_addr);
> + u16 default_addr,
> + const char *aux_device_name);
>
> void i2c_unregister_device(struct i2c_client *client);
>
--
Regards,
Laurent Pinchart
p decided to remove upstream support
> for this SoC and prevent booting it. Public users only have ES2 onwards.
>
> Signed-off-by: Wolfram Sang
> Reviewed-by: Kieran Bingham
Reviewed-by: Laurent Pinchart
> ---
>
> This is the last ES1 bit remaining, would be awesome if it could go
gt; description: GPIO signal to enable DDC bus
> maxItems: 1
>
> + hdmi-pwr-supply:
> +description: Power supply for the HDMI 5v pin connector
I'd write
description: Power supply for the HDMI +5V Power pin
to match the HDMI specification. With that,
Reviewed-by: Lau
ee the above
> error(s), then make sure 'yamllint' is installed and dt-schema is up to
> date:
>
> pip3 install dtschema --upgrade
>
> Please check and re-submit after running the above command yourself. Note
> that DT_SCHEMA_FILES can be set to your schema file to speed up checking
> your schema. However, it must be unset to test all examples with your schema.
--
Regards,
Laurent Pinchart
ret = regulator_enable(conn->connector_pwr);
> + if (ret) {
> + dev_err(>dev, "failed to enable DP PWR regulator:
> %d\n", ret);
> + return ret;
> + }
> }
>
> conn->bridge.funcs = _connector_bridge_funcs;
--
Regards,
Laurent Pinchart
tor*connector_pwr;
This makes sense, but I would shorten the name to just "pwr", "power" or
"supply". The field is part of the display_connector structure, so it
implicitly refers to the connector.
With or without that change,
Reviewed-by: Laurent Pinchart
ly convert this driver from always returning zero in the remove
> callback to the void returning variant.
>
> Signed-off-by: Uwe Kleine-König
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/bridge/display-connector.c | 6 ++
> 1 file changed, 2 insertions(+), 4 deletion
ly convert this driver from always returning zero in the remove
> callback to the void returning variant.
>
> Signed-off-by: Uwe Kleine-König
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/bridge/fsl-ldb.c | 6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
ly convert this driver from always returning zero in the remove
> callback to the void returning variant.
>
> Signed-off-by: Uwe Kleine-König
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/bridge/simple-bridge.c | 6 ++
> 1 file changed, 2 insertions(+), 4 deletion
ly convert this driver from always returning zero in the remove
> callback to the void returning variant.
>
> Signed-off-by: Uwe Kleine-König
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/bridge/ti-tfp410.c | 6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-
ly convert this driver from always returning zero in the remove
> callback to the void returning variant.
>
> Signed-off-by: Uwe Kleine-König
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/bridge/thc63lvd1024.c | 6 ++
> 1 file changed, 2 insertions(+), 4 deletion
ly convert this driver from always returning zero in the remove
> callback to the void returning variant.
>
> Signed-off-by: Uwe Kleine-König
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/bridge/lvds-codec.c | 6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
onvert the imx8 drm drivers from always returning zero in the
> remove callback to the void returning variant.
>
> Signed-off-by: Uwe Kleine-König
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/bridge/imx/imx8qm-ldb-drv.c | 6 ++
> drivers/gp
ially convert the drm panel drivers from always returning zero in the
> remove callback to the void returning variant.
>
> Signed-off-by: Uwe Kleine-König
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/panel/panel-lvds.c | 6 ++
> drivers/gpu/drm/panel/panel-
lly convert the rcar-du drm driver from always returning zero in
> the remove callback to the void returning variant.
>
> Signed-off-by: Uwe Kleine-König
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/rcar-du/rcar_cmm.c | 6 ++
> drivers/gpu/drm/rcar-du/rcar_du_d
y convert the hisilicon drm drivers from always returning zero
> in the remove callback to the void returning variant.
>
> Signed-off-by: Uwe Kleine-König
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c| 6 ++
> drivers/gpu/drm/hisilic
ly convert this driver from always returning zero in the remove
> callback to the void returning variant.
>
> Signed-off-by: Uwe Kleine-König
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/shmobile/shmob_drm_drv.c | 6 ++
> 1 file changed, 2 insertions(+), 4 deletions(
convert the omap drm driver from always returning zero in the
> remove callback to the void returning variant.
>
> Signed-off-by: Uwe Kleine-König
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/omapdrm/dss/dispc.c | 5 ++---
> drivers/gpu/drm/omapdrm/dss/dsi.c
ly convert this driver from always returning zero in the remove
> callback to the void returning variant.
>
> Signed-off-by: Uwe Kleine-König
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c | 6 ++
> 1 file changed, 2 insertions(+), 4 d
convert the synopsis bridge drivers from always returning zero
> in the remove callback to the void returning variant.
>
> Signed-off-by: Uwe Kleine-König
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/bridge/synopsys/dw-hdmi-ahb-audio.c | 6 ++
> drivers/gp
ly convert this driver from always returning zero in the remove
> callback to the void returning variant.
>
> Signed-off-by: Uwe Kleine-König
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/bridge/nwl-dsi.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
ly convert this driver from always returning zero in the remove
> callback to the void returning variant.
>
> Signed-off-by: Uwe Kleine-König
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/xlnx/zynqmp_dpsub.c | 6 ++
> 1 file changed, 2 insertions(+), 4 deleti
d-off-by: Alexander Stein
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/bridge/ti-sn65dsi83.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi83.c
> b/drivers/gpu/drm/bridge/ti-sn65dsi83.c
> index 75286c9afbb9..1f5c079
Hi Biju,
Thank you for the patch.
On Mon, Apr 24, 2023 at 05:10:24PM +0100, Biju Das wrote:
> Add my self as maintainer for RZ DU drivers.
> While at it, update the entries for rcar-du and shmobile.
>
> Signed-off-by: Biju Das
Reviewed-by: Laurent Pinchart
> ---
>
by: Rob Herring
Reviewed-by: Laurent Pinchart
> ---
> v7->v8:
> * Fixed the typo vsp2->du
> * Added Rb tag from Rob as the change is trivial.
> v7:
> * New patch.
> ---
> .../devicetree/bindings/display/renesas,rzg2l-du.yaml| 9 +++--
> 1 file changed,
@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/renesas,rzg2l-du.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Renesas RZ/G2L Display Unit (DU)
> +
> +
Hi Biju,
Thank you for the patch.
On Mon, Apr 24, 2023 at 05:10:20PM +0100, Biju Das wrote:
> Create vendor specific renesas directory and move renesas drivers
> to that directory.
>
> Signed-off-by: Biju Das
Reviewed-by: Laurent Pinchart
> ---
ricter.
>
> Signed-off-by: Rob Herring
Reviewed-by: Laurent Pinchart
> ---
> .../devicetree/bindings/display/panel/advantech,idk-1110wr.yaml | 2 +-
> .../devicetree/bindings/display/panel/innolux,ee101ia-01d.yaml | 2 +-
> .../devicetree/bindings/display/panel/mitsubishi,aa104
Hi Geert,
On Tue, Apr 18, 2023 at 10:00:35AM +0200, Geert Uytterhoeven wrote:
> On Tue, Apr 18, 2023 at 9:49 AM Laurent Pinchart wrote:
> > On Mon, Apr 17, 2023 at 03:40:20PM +0200, Geert Uytterhoeven wrote:
> > > Currently, there are two drivers for the LCD controller on Re
nesas SoC platforms
>
> drivers/gpu/drm/shmobile/Kconfig | 4 +--
> drivers/gpu/drm/shmobile/shmob_drm_crtc.c | 35 +++---
> drivers/gpu/drm/shmobile/shmob_drm_drv.c | 3 ++
> drivers/gpu/drm/shmobile/shmob_drm_kms.c | 9 --
> drivers/gpu/dr
301 - 400 of 9011 matches
Mail list logo
