Hi Kishon,
On Thu, Sep 03, 2020 at 05:00:14PM +0530, Kishon Vijay Abraham I wrote:
> On 9/3/2020 4:29 PM, Swapnil Kashinath Jakhade wrote:
> > On Wednesday, September 2, 2020 5:47 PM, Laurent Pinchart wrote:
> >> On Wed, Sep 02, 2020 at 07:09:21AM +, Swapnil Kashi
2_event_time32 ev32;
>
> + memset(, 0, sizeof(ev32));
> + ev32.type = ev->type,
The lines should end with ';', not ','.
With this fixed,
Reviewed-by: Laurent Pinchart
> + ev32.pending= ev->pending,
> + ev32.
Hi Swapnil,
On Wed, Sep 02, 2020 at 07:09:21AM +, Swapnil Kashinath Jakhade wrote:
> On Wednesday, September 2, 2020 6:00 AM Laurent Pinchart wrote:
> > On Mon, Aug 24, 2020 at 08:28:31PM +0200, Swapnil Jakhade wrote:
> > > Use generic PHY framework function phy_set_att
g can access the PHY yet. What race condition are
you trying to protect against with usage of phy_set_attrs() ?
> } else {
> dev_err(dev, "Driver supports only PHY_TYPE_DP\n");
> ret = -ENOTSUPP;
--
Regards,
Laurent Pinchart
t; }
>
> +static inline void phy_get_attrs(struct phy *phy, struct phy_attrs *attrs)
> +{
> + return;
You can drop the return statement.
> +}
> +
> +static inline void phy_set_attrs(struct phy *phy, const struct phy_attrs
> *attrs)
> +{
> + return;
Here too.
> +}
> +
> static inline struct phy *phy_get(struct device *dev, const char *string)
> {
> return ERR_PTR(-ENOSYS);
--
Regards,
Laurent Pinchart
Hi Adam,
On Mon, Aug 24, 2020 at 01:31:54PM -0400, Adam Goode wrote:
> On Mon, Aug 24, 2020 at 10:38 AM Hans Verkuil wrote:
> > On 24/08/2020 15:56, Adam Goode wrote:
> > > On Mon, Aug 24, 2020 at 4:48 AM Hans Verkuil wrote:
> > >> On 23/08/2020 17:08, Laurent Pinch
Hi Swapnil,
Thank you for the patch.
On Mon, Aug 31, 2020 at 10:23:34AM +0200, Swapnil Jakhade wrote:
> Add a new DRM bridge driver for Cadence MHDP8546 DPTX IP used in TI J721E
> SoC. MHDP DPTX IP is the component that complies with VESA DisplayPort (DP)
> and embedded Display Port (eDP)
Hi Jia-Ju,
On Mon, Aug 31, 2020 at 09:45:14PM +0800, Jia-Ju Bai wrote:
> On 2020/8/31 6:25, Laurent Pinchart wrote:
> > On Sun, Aug 30, 2020 at 03:33:11PM +0800, Jia-Ju Bai wrote:
> >> On 2020/8/30 1:16, Laurent Pinchart wrote:
> >>> On Sat, Aug 29, 2020 at 02:10:
Hi Jia-Ju,
On Sun, Aug 30, 2020 at 03:33:11PM +0800, Jia-Ju Bai wrote:
> On 2020/8/30 1:16, Laurent Pinchart wrote:
> > On Sat, Aug 29, 2020 at 02:10:20PM +0200, Pavel Machek wrote:
> >> Hi!
> >>
> >>> The value av7110->debi_virt is stored in DMA memory,
Hi Guenter,
On Sun, Aug 30, 2020 at 01:48:24PM -0700, Guenter Roeck wrote:
> On 8/30/20 8:58 AM, Laurent Pinchart wrote:
> > On Sun, Aug 30, 2020 at 08:04:38AM -0700, Guenter Roeck wrote:
> >> The uvcvideo code has no lock protection against USB disconnects
> >> while v
I_DCS_BUS_TYPE_DBI_SPI_C3,
> >> + .lanes = 1,
> >> +};
> >> +
> >> +static const struct of_device_id ili9341_of_match[] = {
> >> + { .compatible = "adafruit,yx240qv29", .data =
> >> _pdata },
> >> + { }
> >> +};
> >> +MODULE_DEVICE_TABLE(of, ili9341_of_match);
> >> +
> >> +static struct mipi_dsi_driver ili9341_dsi_driver = {
> >> + .probe = ili9341_probe,
> >> + .remove = ili9341_remove,
> >> + .driver = {
> >> + .name = "ili9341-dsi",
> >> + .of_match_table = ili9341_of_match,
> >> + },
> >> +};
> >> +module_mipi_dsi_driver(ili9341_dsi_driver);
> >
> > Again, you treat this driver as a mipi dsi driver but for a MIPI-DBI
> > (I8080/SPI)
> > panel device. That will make developers confused.
> >
> > Is it possible to just add a mipi_dbi_driver for I8080/SPI interface
> > panel?
> > Thanks!
>
> Please read the cover letter, it explains why it's done this way. The
> whole point of this patchset is to merge DSI and DBI frameworks in a
> way that can be maintained.
I think this proves the point that the proposed naming is confusing. At
least a rename would be required.
--
Regards,
Laurent Pinchart
video device is registered
>
> drivers/media/usb/uvc/uvc_ctrl.c | 11 ++
> drivers/media/usb/uvc/uvc_driver.c | 12 ++
> drivers/media/usb/uvc/uvc_queue.c | 32 +--
> drivers/media/usb/uvc/uvc_v4l2.c | 45
> --
> drivers/media/usb/uvc/uvcvideo.h | 1 +
> 5 files changed, 93 insertions(+), 8 deletions(-)
--
Regards,
Laurent Pinchart
[0]].flags = flags;
> > + av7110->ci_slot[data_0].flags = flags;
>
> This does not even do what it says. Compiler is still free to access
> data[0] multiple times. It needs READ_ONCE() to be effective.
Yes, it seems quite dubious to me. If we *really* want to guard against
rogue hardware here, the whole DMA buffer should be copied. I don't
think it's worth it, a rogue PCI device can do much more harm.
--
Regards,
Laurent Pinchart
Hi Paul,
On Tue, Aug 25, 2020 at 08:02:22AM -0700, Paul E. McKenney wrote:
> On Sun, Aug 23, 2020 at 06:04:05AM +0300, Laurent Pinchart wrote:
> > Commit 8344496e8b49 ("rcu-tasks: Conditionally compile
> > show_rcu_tasks_gp_kthreads()") introduced conditional compilation
Hi Mauro,
On Tue, Aug 25, 2020 at 01:30:25PM +0200, Mauro Carvalho Chehab wrote:
> Em Tue, 25 Aug 2020 05:29:29 +1000
> Dave Airlie escreveu:
>
> > On Thu, 20 Aug 2020 at 20:02, Laurent Pinchart
> > wrote:
> > >
> > > Hi Mauro,
> > >
>
Hi Tomi,
On Fri, Aug 14, 2020 at 12:29:35PM +0300, Tomi Valkeinen wrote:
> On 11/08/2020 05:36, Laurent Pinchart wrote:
>
> >> +static int cdns_mhdp_mailbox_write(struct cdns_mhdp_device *mhdp, u8 val)
> >> +{
> >> + int ret, full;
> >> +
&g
Hi Tomi,
On Fri, Aug 14, 2020 at 11:22:09AM +0300, Tomi Valkeinen wrote:
> On 11/08/2020 05:36, Laurent Pinchart wrote:
>
> >> +static int cdns_mhdp_connector_init(struct cdns_mhdp_device *mhdp)
> >> +{
> >> + u32 bus_format = MEDIA_BUS_FMT_RGB121212_1X36;
&
Hi Vishal,
On Wed, Aug 19, 2020 at 07:40:16PM +0300, Laurent Pinchart wrote:
> On Wed, Aug 19, 2020 at 01:45:34PM +, Vishal Sagar wrote:
> > On Wednesday, July 15, 2020 9:59 PM, Laurent Pinchart wrote:
> >> On Mon, Jul 13, 2020 at 12:54:47PM -0600, Rob Herring wrote:
&g
erything seems to match the schematics :-)
Reviewed-by: Laurent Pinchart
> ---
> v1->v2
> * This patch is part of series [1] (rest of the patches have be accepted
> by Geert [2]).
> * Added regulator for lvds
> * Added reset pin for touchpanel
> * This patch is based on s
t also defines a
xlnx,video-format property that uses the values from UG934 for the AXI
streaming interface.
> I agree. The bindings should be in sync with datasheet and not rely on
> software definitions. Since the driver is only in Xilinx vendor tree,
> please send directly to g...@xilinx.com.
--
Regards,
Laurent Pinchart
Hi Qian,
On Fri, Aug 21, 2020 at 09:20:37PM -0400, Qian Cai wrote:
> On Mon, Jun 08, 2020 at 06:16:22AM +0300, Laurent Pinchart wrote:
> > Hi Qian,
> >
> > I forgot to mention, I think the subject line should be
> >
> > drm/rcar-du: Make DRM_RCAR_WRITEBACK dep
Hi Adam,
(CC'ing Hans Verkuil)
On Sun, Aug 23, 2020 at 05:54:24PM +0300, Laurent Pinchart wrote:
> Hi Adam,
>
> Thank you for the patch.
>
> On Sat, Aug 22, 2020 at 09:21:34PM -0400, Adam Goode wrote:
> > The Color Matching Descriptor has been present in USB cameras s
tization range for MJPEG, and
while it doesn't explicitly specify the quantization range for other
formats, we can only assume it should be limited as well ?
The code otherwise looks good to me.
Reviewed-by: Laurent Pinchart
Please let me know if you'd like to address the above issue.
> The q
break;
> + }
> + }
> + if (i == format->nframes) {
> + uvc_trace(UVC_TRACE_FORMAT, "Unknown bFrameIndex %u.\n",
> + probe->bFrameIndex);
> + return -EINVAL;
> + }
This looks good to me. Blank li
it.
Fixes: 8344496e8b49 ("rcu-tasks: Conditionally compile
show_rcu_tasks_gp_kthreads()")
Signed-off-by: Laurent Pinchart
---
kernel/rcu/tasks.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/kernel/rcu/tasks.h b/kernel/rcu/tasks.h
index 835e2df8590a..bddf3968c1eb 100644
--- a/kernel/rcu/
e kernel. I believe this is an issue of the
pm_runtime_get_sync() API, which really shouldn't require a put() when
it fails. For drivers that really don't expect pm_runtime_get_sync() to
fail (no I2C access to a regulator for instance, only SoC-internal
operations) I've instead decided to ignore the error completely. I don't
think poluting the whole kernel code base with this kind of "fixes" is a
good idea.
--
Regards,
Laurent Pinchart
Hi Mauro,
On Thu, Aug 20, 2020 at 09:03:26AM +0200, Mauro Carvalho Chehab wrote:
> Em Wed, 19 Aug 2020 12:52:06 -0700 John Stultz escreveu:
> > On Wed, Aug 19, 2020 at 8:31 AM Laurent Pinchart wrote:
> > > On Wed, Aug 19, 2020 at 05:21:20PM +0200, Sam Ravnborg wrote:
>
Hi Guenter,
On Wed, Aug 19, 2020 at 04:08:51PM -0700, Guenter Roeck wrote:
> On Wed, Aug 19, 2020 at 04:30:02AM +0300, Laurent Pinchart wrote:
> > On Mon, Aug 17, 2020 at 01:00:49PM +0200, Hans Verkuil wrote:
> > > On 17/08/2020 01:51, Laurent Pinchart wrote:
> > > >
Hi Vishal,
(Hans, there's a question for you below)
On Wed, Aug 19, 2020 at 01:47:49PM +, Vishal Sagar wrote:
> On Thursday, July 16, 2020 3:03 AM Laurent Pinchart wrote:
> > On Thu, Jun 25, 2020 at 11:43:01AM +0200, Hans Verkuil wrote:
> > > On 18/06/2020 07:33,
Hi Vishal,
On Wed, Aug 19, 2020 at 01:45:34PM +, Vishal Sagar wrote:
> On Wednesday, July 15, 2020 9:59 PM, Laurent Pinchart wrote:
> > On Mon, Jul 13, 2020 at 12:54:47PM -0600, Rob Herring wrote:
> > > On Thu, Jun 18, 2020 at 11:03:03AM +0530, Vishal Sagar wrote:
&g
; create mode 100644 drivers/staging/hikey9xx/gpu/kirin960_defs.c
> > create mode 100644 drivers/staging/hikey9xx/gpu/kirin960_dpe_reg.h
> > create mode 100644 drivers/staging/hikey9xx/gpu/kirin970_defs.c
> > create mode 100644 drivers/staging/hikey9xx/gpu/kirin970_dpe_reg.h
> > create mode 100644 drivers/staging/hikey9xx/gpu/kirin9xx_dpe.h
> > create mode 100644 drivers/staging/hikey9xx/gpu/kirin9xx_drm_dpe_utils.c
> > create mode 100644 drivers/staging/hikey9xx/gpu/kirin9xx_drm_dpe_utils.h
> > create mode 100644 drivers/staging/hikey9xx/gpu/kirin9xx_drm_drv.c
> > create mode 100644 drivers/staging/hikey9xx/gpu/kirin9xx_drm_drv.h
> > create mode 100644 drivers/staging/hikey9xx/gpu/kirin9xx_drm_dss.c
> > create mode 100644
> > drivers/staging/hikey9xx/gpu/kirin9xx_drm_overlay_utils.c
> > create mode 100644 drivers/staging/hikey9xx/gpu/kirin9xx_dw_drm_dsi.c
> > create mode 100644 drivers/staging/hikey9xx/gpu/kirin9xx_dw_dsi_reg.h
> > create mode 100644 drivers/staging/hikey9xx/gpu/kirin9xx_fb_panel.h
--
Regards,
Laurent Pinchart
leanup crtc_crc_open function")
I think the issue was introduced in d5cc15a0c66e ("drm: crc: Introduce
verify_crc_source callback"). Apart from that,
Reviewed-by: Laurent Pinchart
> Signed-off-by: Dinghao Liu
> ---
> drivers/gpu/drm/drm_debugfs_crc.c | 4 +++-
&g
Hi Hans,
On Wed, Aug 19, 2020 at 09:27:05AM +0200, Hans Verkuil wrote:
> On 19/08/2020 03:30, Laurent Pinchart wrote:
> > On Mon, Aug 17, 2020 at 01:00:49PM +0200, Hans Verkuil wrote:
> >> On 17/08/2020 01:51, Laurent Pinchart wrote:
> >>> On Sun, Aug 16, 2020 at 0
Hi Hans,
On Mon, Aug 17, 2020 at 01:00:49PM +0200, Hans Verkuil wrote:
> On 17/08/2020 01:51, Laurent Pinchart wrote:
> > On Sun, Aug 16, 2020 at 08:54:18AM -0700, Guenter Roeck wrote:
> >> On 8/16/20 5:18 AM, Laurent Pinchart wrote:
> >>> CC'ing Hans Verkuil and S
ent based on this.
Is there no value in warning the user that something went wrong ? Silent
failures are harder to debug.
> Cc: Laurent Pinchart
> Cc: Mauro Carvalho Chehab
> Cc: linux-me...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Greg Kroah-Hartman
> -
i2c-adapter = <>;
> + spi-master = <0>;
> + spi-cs = <0 1>;
> + serdev-controller = <>;
> + pwms = < 0 50 0>;
> + mikrobus-gpios = < 18 0> , < 23 0>,
> + < 30 0> , < 31 0>,
> + < 15 0> , < 14 0>,
> + < 4 0> , < 3 0>,
> + < 2 0> , < 5 0>,
> + < 25 0> , < 3 0>;
> + };
> \ No newline at end of file
--
Regards,
Laurent Pinchart
Hi Guenter,
On Sun, Aug 16, 2020 at 08:54:18AM -0700, Guenter Roeck wrote:
> On 8/16/20 5:18 AM, Laurent Pinchart wrote:
> > Hi Guenter,
> >
> > CC'ing Hans Verkuil and Sakari Ailus for the discussion about handling
> > file operations and disconnect in V4L2.
> >
s
> can happen after the disconnect call.
>
> The only remedy I can see is to rework the usbvideo driver and add the
> necessary protections. At first glance, it looks like this may be a
> substantial amount of work. I'd sign up for that, but before I start,
> I would like to get input from the usbvideo community. Is such an effort
> already going on ? If yes, how can I help ? If not, is the problem
> understood and accepted ? Are there any ideas on how to solve it ?
This is something that has been discussed before, and needs to be solved
in the V4L2 framework itself, not in individual drivers. Not only would
this avoid rolling out the same code manually everywhere (in different
incorrect ways, as races are difficult to solve and implementations are
more often wrong than right), but it will also avoid similar issues for
non-USB devices.
It shouldn't take more than two flags (to track user-space operations in
progress and disconnection), a spinlock and a wait queue entry. I'm not
sure if someone has already given it a try, and don't recall why this
hasn't been done yet, as it should be fairly straightforward.
On the UVC side, the work queue probably has to be flushed in
uvc_disconnect(). I'd keep the destroy call in uvc_delete() though.
Please make sure to look for potential race conditions between the URB
completion handler and the .disconnect() handler (they shouldn't be any,
but I haven't checked lately myself).
--
Regards,
Laurent Pinchart
On Wed, Aug 12, 2020 at 07:36:54PM +0300, Laurent Pinchart wrote:
> Hi Prabhakar,
>
> Thank you for the patch.
>
> On Wed, Aug 12, 2020 at 03:02:17PM +0100, Lad Prabhakar wrote:
> > Setup up the required clocks for the DU to be functional.
> >
> > Signed-off-by:
Hi Prabhakar,
On Thu, Aug 13, 2020 at 12:08:58PM +0100, Lad, Prabhakar wrote:
> On Thu, Aug 13, 2020 at 11:59 AM Laurent Pinchart wrote:
> > On Thu, Aug 13, 2020 at 11:38:03AM +0100, Lad, Prabhakar wrote:
> >> On Thu, Aug 13, 2020 at 10:05 AM Geert Uytterhoeven wrote:
> >
0f040..419d81c7763e 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> @@ -153,7 +153,7 @@ static const struct rcar_du_device_info
> rcar_du_r8a774b1_info = {
> },
> [RCAR_DU_OUTPUT_LVDS0] = {
>
On Thu, Aug 13, 2020 at 10:42:28AM +0300, Pekka Paalanen wrote:
> On Wed, 12 Aug 2020 16:30:17 +0300 Laurent Pinchart wrote:
> > On Wed, Aug 12, 2020 at 07:08:10PM +0800, crj wrote:
> > > 在 2020/8/12 17:33, Laurent Pinchart 写道:
> > > > On Wed, Aug 12, 2020 at 04:
nesas/r8a774e1.dtsi | 61 ++-
> drivers/gpu/drm/rcar-du/rcar_du_drv.c | 30 +
> drivers/gpu/drm/rcar-du/rcar_lvds.c | 1 +
> 7 files changed, 104 insertions(+), 3 deletions(-)
--
Regards,
Laurent Pinchart
;,
> + < 1>,
> + <_clk>,
> + < 2>;
> + clock-names = "du.0", "du.1", "du.3",
> + "dclkin.0", "dclkin.1", "dclkin.3";
I have no reason to doubt this is correct, but I also can't assess that
as I don't have access to the schematics.
Acked-by: Laurent Pinchart
> +};
--
Regards,
Laurent Pinchart
> Signed-off-by: Lad Prabhakar
Reviewed-by: Laurent Pinchart
> ---
> arch/arm64/boot/dts/renesas/r8a774e1.dtsi | 27 +++
> 1 file changed, 27 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/renesas/r8a774e1.dtsi
> b/arch/arm64/boot/dts/renesas/r8a774
DS
> encoder driver.
>
> Signed-off-by: Marian-Cristian Rotariu
>
> Signed-off-by: Lad Prabhakar
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/rcar-du/rcar_lvds.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_lvds.
t; };
> @@ -2650,6 +2660,7 @@
> port@1 {
> reg = <1>;
> du_out_hdmi0: endpoint {
> + remote-endpoint =
> <_hdmi0_in>;
> };
> };
> port@2 {
--
Regards,
Laurent Pinchart
Hi Prabhakar,
Thank you for the patch.
On Wed, Aug 12, 2020 at 03:02:13PM +0100, Lad Prabhakar wrote:
> From: Marian-Cristian Rotariu
>
> Document RZ/G2H (R8A774E1) SoC bindings.
>
> Signed-off-by: Marian-Cristian Rotariu
>
> Signed-off-by: Lad Prabhakar
Reviewed
On Wed, Aug 12, 2020 at 07:17:59PM +0300, Laurent Pinchart wrote:
> Hi Prabhakar,
>
> Thank you for the patch.
>
> On Wed, Aug 12, 2020 at 03:02:12PM +0100, Lad Prabhakar wrote:
> > From: Marian-Cristian Rotariu
> >
> > Document the RZ/G2H (R8A774E1) L
> + - "renesas,r8a774e1-lvds" for R8A774E1 (RZ/G2H) compatible LVDS encoders
>- "renesas,r8a7790-lvds" for R8A7790 (R-Car H2) compatible LVDS encoders
>- "renesas,r8a7791-lvds" for R8A7791 (R-Car M2-W) compatible LVDS encoders
>- "renesas,r8a7793-lvds" for R8A7793 (R-Car M2-N) compatible LVDS encoders
--
Regards,
Laurent Pinchart
Prabhakar
Reviewed-by: Laurent Pinchart
> ---
> arch/arm64/boot/dts/renesas/r8a774e1.dtsi | 19 ++-
> 1 file changed, 18 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/renesas/r8a774e1.dtsi
> b/arch/arm64/boot/dts/renesas/r8a774e1.dtsi
&g
n-Cristian Rotariu
>
> Signed-off-by: Lad Prabhakar
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/rcar-du/rcar_du_drv.c | 30 +++
> 1 file changed, 30 insertions(+)
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> b/drivers/gpu/drm/
off-by: Lad Prabhakar
Reviewed-by: Laurent Pinchart
> ---
> Documentation/devicetree/bindings/display/renesas,du.txt | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/display/renesas,du.txt
> b/Documentation/devicetree/bindings/disp
Hi Algea,
On Wed, Aug 12, 2020 at 07:08:10PM +0800, crj wrote:
> 在 2020/8/12 17:33, Laurent Pinchart 写道:
> > On Wed, Aug 12, 2020 at 04:35:43PM +0800, Algea Cao wrote:
> >> Introduce struct dw_hdmi_property_ops in plat_data to support
> >> vendor hdmi property.
>
Hi Vinay,
On Wed, Aug 12, 2020 at 06:07:52PM +0530, Vinay Simha B N wrote:
> On Wed, Aug 12, 2020 at 3:24 PM Laurent Pinchart wrote:
> > On Wed, Aug 12, 2020 at 12:55:50PM +0530, Vinay Simha BN wrote:
> > > - bus formats read from drm_bridge_state.out
Hi Vinay,
Thank you for the patch.
On Wed, Aug 12, 2020 at 12:55:50PM +0530, Vinay Simha BN wrote:
> - bus formats read from drm_bridge_state.output_bus_cfg.format
> and .atomic_get_input_bus_fmts() instead of connector
>
> Signed-off-by: Vinay Simha BN
>
> ---
> v1:
void *data);
> + void (*destroy_properties)(struct drm_connector *connector,
> + void *data);
> + int (*set_property)(struct drm_connector *connector,
> + struct drm_connector_state *state,
> + struct drm_property *property,
> + u64 val,
> + void *data);
> + int (*get_property)(struct drm_connector *connector,
> + const struct drm_connector_state *state,
> + struct drm_property *property,
> + u64 *val,
> + void *data);
> +};
> +
> struct dw_hdmi_plat_data {
> struct regmap *regm;
>
> @@ -141,6 +160,9 @@ struct dw_hdmi_plat_data {
> const struct drm_display_info *info,
> const struct drm_display_mode *mode);
>
> + /* Vendor Property support */
> + const struct dw_hdmi_property_ops *property_ops;
> +
> /* Vendor PHY support */
> const struct dw_hdmi_phy_ops *phy_ops;
> const char *phy_name;
--
Regards,
Laurent Pinchart
+ void (*atomic_begin)(struct drm_connector *connector,
> + struct drm_connector_state *state);
> +
> + /**
> + * @atomic_begin:
> + *
> + * begin atomic update
> + *
> + * This callback is used by the atomic modeset helpers but it is
> optional.
> + */
> + void (*atomic_flush)(struct drm_connector *connector,
> + struct drm_connector_state *state);
> /**
>* @prepare_writeback_job:
>*
--
Regards,
Laurent Pinchart
; b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.h
> index 1999db05bc3b..05182418efbb 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.h
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.h
> @@ -842,6 +842,10 @@ enum {
> HDMI_FC_AVICONF3_QUANT_RANGE_LIMITED = 0x00,
> HDMI_FC_AVICONF3_QUANT_RANGE_FULL = 0x04,
>
> +/* HDMI_FC_GCP */
> + HDMI_FC_GCP_SET_AVMUTE = 0x2,
> + HDMI_FC_GCP_CLEAR_AVMUTE = 0x1,
> +
> /* FC_DBGFORCE field values */
> HDMI_FC_DBGFORCE_FORCEAUDIO = 0x10,
> HDMI_FC_DBGFORCE_FORCEVIDEO = 0x1,
--
Regards,
Laurent Pinchart
ease validate the bindings with
make dt_binding_check
DT_SCHEMA_FILES=Documentation/devicetree/bindings/display/xlnx/xlnx,dsi.yaml
as explained in Documentation/devicetree/writing-schema.rst ? This will
also compile the example to make sure that everything is right.
> + clocks = <_clk_0>, <_clk_1>;
> + clock-names = "s_axis_aclk", "dphy_clk_200M";
> + xlnx,dsi-num-lanes = <4>;
> + xlnx,dsi-data-type = <1>;
> + xlnx,dsi-cmd-mode = <0>;
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0x0>;
> + dsi_tx_out: endpoint {
> + remote-endpoint = <_in>;
> + };
> + };
> + };
> +};
> +
> +...
--
Regards,
Laurent Pinchart
> 1166if (chan->desc.active) {
> 1167
> vchan_terminate_vdesc(>desc.active->vdesc);
> 1168chan->desc.active = NULL;
> 1169 }
> > 1170spin_unlock_irqrestore(>vchan.lock, flags);
> 1171
> > 1172vchan_synchronize(>vchan);
> 1173}
> 1174
>
--
Regards,
Laurent Pinchart
oking at
them due to this (Greg KH has stated this publicly before for instance).
I assume this is added by the mail server, but it would be good if
someone could get in touch with the IT department to see how this can be
dropped for patches sent to mailing lists. There's no specific urgency,
it can be a background task.
--
Regards,
Laurent Pinchart
Hi Prabhakar,
On Fri, Aug 07, 2020 at 09:20:36PM +0100, Lad, Prabhakar wrote:
> On Wed, Aug 5, 2020 at 1:35 PM Laurent Pinchart wrote:
> > On Wed, Aug 05, 2020 at 10:43:25AM +0200, Geert Uytterhoeven wrote:
> >> On Wed, Aug 5, 2020 at 10:01 AM Lad, Prabhakar wrote:
> >>
= "tpu0_to2";
> + function = "tpu0";
> + };
> +
> i2c2_pins: i2c2 {
> groups = "i2c2_b";
> function = "i2c2";
> @@ -208,6 +277,17 @@
> };
> };
>
> + {
> + status = "okay";
> + ports {
> + port@1 {
> + lvds0_out: endpoint {
> + remote-endpoint = <_receiver_in>;
> + };
> + };
> + };
> +};
> +
> _sound {
> pinctrl-0 = <_pins>;
> pinctrl-names = "default";
> @@ -261,6 +341,10 @@
> shared-pin;
> };
>
> + {
> + status = "okay";
> +};
> +
> {
> status = "okay";
> };
--
Regards,
Laurent Pinchart
Hi Sam,
On Mon, Aug 10, 2020 at 07:54:40PM +0200, Sam Ravnborg wrote:
> Hi Vinay.
>
> Vinay - thanks for following carefully up on the review feedback.
> I know it can be frustrating to wait for feedback.
>
> On Sun, Aug 09, 2020 at 12:30:22AM +0300, Laurent Pinchart w
Hi Tomi, Daniel,
On Thu, Mar 12, 2020 at 09:13:06AM +0200, Tomi Valkeinen wrote:
> On 12/03/2020 00:20, Laurent Pinchart wrote:
> >> + ret = load_firmware(mhdp);
> >> + if (ret)
> >> + goto phy_exit;
> >> +
> >> + drm_bridge_add(>bri
Reviewed-by: Tomi Valkeinen
> Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/bridge/Kconfig | 13 +
> drivers/gpu/drm/bridge/Makefile | 2 +
> drivers/gpu/drm/bridge/cdns-mhdp-core.c | 15 +
> drivers/gpu/drm/bridge/cdns-mhdp-core.h | 1 +
> d
Hi Swapnil,
Thank you for the patch.
On Thu, Aug 06, 2020 at 01:34:31PM +0200, Swapnil Jakhade wrote:
> Add a new DRM bridge driver for Cadence MHDP DPTX IP used in TI J721e SoC.
> MHDP DPTX IP is the component that complies with VESA DisplayPort (DP) and
> embedded Display Port (eDP) standards.
e
> Reviewed-by: Rob Herring
> Reviewed-by: Laurent Pinchart
> ---
> .../bindings/display/bridge/cdns,mhdp.yaml| 139 ++
> 1 file changed, 139 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/bridge/cdns,mhdp.yaml
>
>
s)
> +{
> + return;
> +}
> +
> +static inline void phy_set_attrs(struct phy *phy, struct phy_attrs attrs)
> +{
> + return;
> +}
> +
> static inline struct phy *phy_get(struct device *dev, const char *string)
> {
> return ERR_PTR(-ENOSYS);
--
Regards,
Laurent Pinchart
n of the driver for
> review soon. Please see the responses to comments inline below.
Thank you for the answers. I was reviewing v8 and realized there were a
few things I didn't fully understand related to communication with the
firmware, so I have a few questions here.
> On Thursday, March 1
Hi Prabhakar,
On Sun, Aug 09, 2020 at 09:38:05PM +0100, Lad, Prabhakar wrote:
> On Sat, Aug 8, 2020 at 10:02 PM Laurent Pinchart wrote:
> > On Fri, Aug 07, 2020 at 06:49:49PM +0100, Lad Prabhakar wrote:
> > > Add direct support for the r8a7742 (RZ/G1H).
> > >
>
f uint32_t
> >> - updated alphabetic order of headers
> >> - added SPDX identifier license
> >>
> >> Signed-off-by: Vinay Simha BN
> >>
> >> ---
> >> v1:
> >> Initial version
> >>
> >> v2:
> >> * Andrz
= <_pins>;
> pinctrl-names = "default";
> @@ -165,6 +229,11 @@
> function = "avb";
> };
>
> + backlight_pins: backlight {
> + groups = "tpu0_to2";
> + function = "tpu0";
> + };
> +
> i2c2_pins: i2c2 {
> groups = "i2c2_b";
> function = "i2c2";
> @@ -208,6 +277,17 @@
> };
> };
>
> + {
> + status = "okay";
> + ports {
> + port@1 {
> + lvds0_out: endpoint {
> + remote-endpoint = <_receiver_in>;
> + };
> + };
> + };
> +};
> +
> _sound {
> pinctrl-0 = <_pins>;
> pinctrl-names = "default";
> @@ -261,6 +341,10 @@
> shared-pin;
> };
>
> + {
> + status = "okay";
> +};
> +
> {
> status = "okay";
> };
--
Regards,
Laurent Pinchart
u
>
Reviewed-by: Laurent Pinchart
> ---
> arch/arm/boot/dts/r8a7742.dtsi | 35 ++
> 1 file changed, 35 insertions(+)
>
> diff --git a/arch/arm/boot/dts/r8a7742.dtsi b/arch/arm/boot/dts/r8a7742.dtsi
> index 4a8d27dff9f7..a979a4b3de61 1006
t;0 0xfeb9 0 0x1c>;
Isn't 0x14 enough for the size ? 0x1c won't hurt though. Same comment
below.
With or without this addressed,
Reviewed-by: Laurent Pinchart
> + clocks = < CPG_MOD 726>;
> + power-domain
> Reviewed-by: Marian-Cristian Rotariu
>
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/rcar-du/rcar_lvds.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_lvds.c
> b/drivers/gpu/drm/rcar-du/rcar_lvds.c
> index ab0d49618cf9..
On Sun, Aug 09, 2020 at 12:03:27AM +0300, Laurent Pinchart wrote:
> Hi Prabhakar,
>
> Thank you for the patch.
>
> On Fri, Aug 07, 2020 at 06:49:50PM +0100, Lad Prabhakar wrote:
> > Document the RZ/G1H (R8A7742) LVDS bindings.
> >
> > Signed-off-by: Lad P
Hi Prabhakar,
Thank you for the patch.
On Fri, Aug 07, 2020 at 06:49:50PM +0100, Lad Prabhakar wrote:
> Document the RZ/G1H (R8A7742) LVDS bindings.
>
> Signed-off-by: Lad Prabhakar
> Reviewed-by: Marian-Cristian Rotariu
>
Reviewed-by: Laurent Pinchart
> ---
> ..
rapping this to 80 columns ? I can do
so when applying if it's fine with you.
Reviewed-by: Laurent Pinchart
>*/
> [RCAR_DU_OUTPUT_DPAD0] = {
> .possible_crtcs = BIT(2) | BIT(1) | BIT(0),
> @@ -443,6 +443,7 @@ static const st
Hi Prabhakar,
Thank you for the patch.
On Fri, Aug 07, 2020 at 06:49:48PM +0100, Lad Prabhakar wrote:
> Document the RZ/G1H (R8A7742) SoC in the R-Car DU bindings.
>
> Signed-off-by: Lad Prabhakar
> Reviewed-by: Marian-Cristian Rotariu
>
Reviewed-by: L
1 +
> 6 files changed, 180 insertions(+), 2 deletions(-)
--
Regards,
Laurent Pinchart
Hi Daniel,
On Sat, Aug 08, 2020 at 11:40:13PM +0300, Laurent Pinchart wrote:
> On Fri, Aug 07, 2020 at 05:35:30AM -0300, Daniel W. S. Almeida wrote:
> > From: "Daniel W. S. Almeida"
> >
> > Fixes the following coccinelle report:
> >
> > drivers/me
= pin)
> + if (cursor->id == pin) {
> + iterm = cursor;
> break;
> + }
> }
> }
>
> @@ -1519,4 +1524,3 @@ const struct v4l2_file_operations uvc_fops = {
> .get_unmapped_area = uvc_v4l2_get_unmapped_area,
> #endif
> };
> -
--
Regards,
Laurent Pinchart
en applying. Please let me know how you'd like to proceed.
> uvc_trace(UVC_TRACE_CONTROL, "Extension unit %u not found.\n",
> xqry->unit);
> return -ENOENT;
--
Regards,
Laurent Pinchart
en3 SoCs, but only on a single R-Car Gen2 SoC (V2H).
> >>>>
> >>> YDS mode ?
> >>
> >> No, 10-bit YCbCr-422. But please forget my comment, I was looking at
> >> the wrong table.
> >>
> >> VI1_G[7:2] plus VI1_DATA[7:6] is not even a contiguous subset (I had
> >> misread the used subset to be G[1:0] and B[7:2]), so it cannot be
> >> represented
> >> using just bus-width and bus-shift properties?
> >>
> > Yes and here is my explanation.
> >
> > In Gen1 manual for YDS bit it says the below:
> > 0: Vin_B[7:0] pins
> > 1: Vin_G[7:0] pins
> >
> > And in Gen2 manual it says,
> > 0: Vin_DATA[7:0] pins
> > 1: Vin_DATA[7:0] pins
>
> Vin_DATA[15:8]
>
> The difference is due to some SoCs naming the signals R[7:0], G[7:0], B[7:0],
> while other SoCs use DATA[23:0], the latter presumably to avoid
> confusion when using non-RGB input formats.
> R-Car V2H uses a mix: D[23:16]_R[7:0], D[15:8]_G[7:0], D[7:0]_B[7:0] ;-)
>
> However, the underlying behavior is the same, which is clear from the
> RGB-666 mode, which is not using contiguous DATA[17:0], but sparse
> DATA[23:18], DATA[15:10], DATA[7:2], i.e. the 6 MSB of each color
> component.
>
> > On iwave platform for the VIN2 interface the following G pins are connected:
> >
> > VI2_G0_MARK, VI2_G1_MARK,
> > VI2_G2_MARK, VI2_G3_MARK,
> > VI2_G4_MARK, VI2_G5_MARK,
> > VI2_G6_MARK, VI2_G7_MARK,
> >
> > And for capture to work on this interface the YDS bit has to be set.
> >
> > Now suppose some day we have a platform with 16 bit interface where G
> > and R pins are connected:
> >
> > VI2_G0_MARK, VI2_G1_MARK,
> > VI2_G2_MARK, VI2_G3_MARK,
> > VI2_G4_MARK, VI2_G5_MARK,
> > VI2_G6_MARK, VI2_G7_MARK,
> > /* R */
> > VI2_R0_MARK, VI2_R1_MARK,
> > VI2_R2_MARK, VI2_R3_MARK,
> > VI2_R4_MARK, VI2_R5_MARK,
> > VI2_R6_MARK, VI2_R7_MARK,
> >
> > Scenarios
> > 1: Say we connect a 8-bit camera just with the G pins - YDS has to be
> > 1 for 8-bit YCbCr
> > 2: Say we connect a 8-bit camera just with the R pins - YDS has to be
> > 0 for 8-bit YCbCr
> > 3: Now say we use G2-G7 along with R0 and R1 pins to connect a 8 bit
> > camera - YDS has to be 1 for 8-bit camera
> >
> > And looking at the Gen1 description of YDS bit, having a combination
> > of B and G is not a valid case.
>
> Scenario 3 is indeed not supported. But G[1:0] and B[7:2] (= DATA[9:2])
> could work when using 10-bit YCbCr.
>
> > So my vote is to have a property in the endpoint to say if YDS has to
> > be enabled as done in my first version of the patch.
>
> "YDS" is not a generic property, "data-shift" is.
Agreed, we want something standard.
> Now, how do you specify in DT that RGB-666 mode is to be used?
> "bus-width = <18>"?
> That won't work with the (so far theoretical) case where both contiguous
> and sparse variants are supported by the hardware. And "data-shift"
> won't help here.
>
> Am I overdesigning? ;-)
If bus-width = <18>, VIN would know know that the 6 MSBs of each 8-bit
subset are used, as it doesn't support any other option. There's no need
for data-shift or any other property, as there's nothing to configure
:-) We could even set bus-width = <24>, it wouldn't make a difference.
--
Regards,
Laurent Pinchart
;ep.bus.parallel.flags;
> > > + u8 pclk_pol = 0;
> > > + u8 hsync_pol = 0;
> > > + u8 vsync_pol = 0;
> > > int ret = 0;
> > >
> > > if (on) {
> > > @@ -2014,52 +1929,124 @@ static int ov5640_set_power(struct ov5640_dev
> > > *sensor, bool on)
> > > if (ret)
> > > goto power_off;
> > >
> > > - /* We're done here for DVP bus, while CSI-2 needs setup. */
> > > - if (sensor->ep.bus_type != V4L2_MBUS_CSI2_DPHY)
> > > - return 0;
> > > + /* CSI-2 setup. */
> > > + if (sensor->ep.bus_type == V4L2_MBUS_CSI2_DPHY) {
> > > + /*
> > > + * Power up MIPI HS Tx and LS Rx; 2 data lanes mode
> > > + *
> > > + * 0x300e = 0x40
> > > + * [7:5] = 010 : 2 data lanes mode (see FIXME note
> > > in
> > > + *"ov5640_set_stream_mipi()")
> > > + * [4] = 0 : Power up MIPI HS Tx
> > > + * [3] = 0 : Power up MIPI LS Rx
> > > + * [2] = 0 : MIPI interface disabled
> > > + */
> > > + ret = ov5640_write_reg(sensor,
> > > OV5640_REG_IO_MIPI_CTRL00, 0x40);
> >
> > Please wrap lines over 80 if it can be reasonably one.
>
> checkpatch doesn't complain about it (size is increased to 100)?
--
Regards,
Laurent Pinchart
D OUTPUT ENABLE 01
> + * - 6: VSYNC output enable
> + * - 5: HREF output enable
> + * - 4: PCLK output enable
> + * - [3:0]: D[9:6] output enable
> + */
> + ret = ov5640_write_reg(sensor,
> OV5640_REG_PAD_OUTPUT_ENABLE01, 0x7f);
> + if (ret)
> + goto power_off;
>
> - /* Give lanes some time to coax into LP11 state. */
> - usleep_range(500, 1000);
> + /*
> + * enable D[5:0] DVP data lines
> + *
> + * PAD OUTPUT ENABLE 02
> + * - [7:2]: D[5:0] output enable
> + */
> + ret = ov5640_write_reg(sensor,
> OV5640_REG_PAD_OUTPUT_ENABLE02, 0xfc);
> + if (ret)
> + goto power_off;
> + }
I'd split this to two separate functions, one for CSI-2, one for
parallel, as this is getting difficult to read.
>
> } else {
> if (sensor->ep.bus_type == V4L2_MBUS_CSI2_DPHY) {
--
Regards,
Laurent Pinchart
Hi Kaaira,
On Thu, Jul 30, 2020 at 11:39:49PM +0530, Kaaira Gupta wrote:
> On Thu, Jul 30, 2020 at 01:51:12PM +0300, Laurent Pinchart wrote:
> > On Fri, Jul 24, 2020 at 05:32:10PM +0530, Kaaira Gupta wrote:
> > > This is version 2 of the patch series posted by Niklas for allow
eturn 200 OK and serve the same content:
> Replace HTTP with HTTPS.
>
> Signed-off-by: Alexander A. Klimov
Reviewed-by: Laurent Pinchart
and applied to my tree, for v5.10.
> ---
> Continuing my work started at 93431e0607e5.
> See also: git log --oneline '--
y recently observed with specific compiler options"
* tag 'erofs-for-5.8-rc3-fixes' of
git://git.kernel.org/pub/scm/linux/kernel/git/xiang/erofs:
erofs: fix partially uninitialized misuse in z_erofs_onlinepage_fixup
$ git commit --amend --author 'Laurent Pinchart
'
[tmp 6a7191c2aee9]
+
> +spi-max-frequency = <1500>;
> +spi-3wire;
> +reset-gpios = < 2 GPIO_ACTIVE_LOW>;
> +backlight = <>;
> +power-supply = <>;
> +
> +port {
> + panel_input: endpoint {
> + remote-endpoint = <_output>;
> + };
> +};
> + };
> +};
> +
> +...
--
Regards,
Laurent Pinchart
g
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/xlnx/zynqmp_dp.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/xlnx/zynqmp_dp.c
> b/drivers/gpu/drm/xlnx/zynqmp_dp.c
> index 821f7a71e182..0e1c818746eb 100644
> --- a/driv
lay_ms = 4;
> > module_param_named(power_on_delay_ms, zynqmp_dp_power_on_delay_ms, uint,
> > 0444);
> > -MODULE_PARM_DESC(aux_timeout_ms, "DP power on delay in msec (default: 4)");
> > +MODULE_PARM_DESC(power_on_delay_ms, "DP power on delay in msec (default:
> > 4)");
> >
> > /* Link configuration registers */
> > #define ZYNQMP_DP_LINK_BW_SET 0x0
--
Regards,
Laurent Pinchart
f-by: Wei Yongjun
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/xlnx/zynqmp_dp.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/xlnx/zynqmp_dp.c
> b/drivers/gpu/drm/xlnx/zynqmp_dp.c
> index 821f7a71e182..3d53638ab15e 100644
select DMADEVICES
> is not a good solution. We try very hard not to enable entire
> subsystems with one driver "select". (No doubt you can find a
> few examples that do just that, but it is strongly discouraged.)
If this isn't allowed, then we need to fix this where used, as that's
drivers/dma/ti/omap-dma.c:1892:34: warning: 'omap_dma_match' defined but
> not used [-Wunused-const-variable=]
> 1892 | static const struct of_device_id omap_dma_match[] = {
>
> Signed-off-by: Krzysztof Kozlowski
Reviewed-by: Laurent Pinchart
> ---
> drivers/d
gt; On Wed, Jul 15, 2020 at 06:00:10PM +1000, Dmitry Buzdyk wrote:
> > On Tue, Jun 09, 2020 at 02:57:36PM +1000, Dmitry Buzdyk wrote:
> > Hi Laurent,
> >
> > Please see updated information below
> >
> >> On Sun, Jun 07, 2020 at 04:07:19AM +0300, Lauren
host, );
Two devices for the same OF node is asking for trouble :-S
Looking at the other patches in this series, it seems that what you need
from the DSI framework is DCS. I think we should then extract the DCS
support to mipi_dcs_* functions, with two different backends, one for
DSI and one for DBI. That way you will be able to support DBI panels
with a single driver instead of splutting the support between two
drivers (this one and the corresponding mipi_dsi_driver's).
> + if (IS_ERR(dsi)) {
> + dev_err(dev, "Failed to add DSI device\n");
> + return PTR_ERR(dsi);
> + }
> +
> + return 0;
> +}
> +
> +static const struct of_device_id dbi_spi_of_match[] = {
> + { .compatible = "adafruit,yx240qv29" },
> + { .compatible = "leadtek,ltk035c5444t-spi" },
> + { }
> +};
> +MODULE_DEVICE_TABLE(of, dbi_spi_of_match);
> +
> +static struct spi_driver dbi_spi_driver = {
> + .driver = {
> + .name = "dbi-spi",
> + .of_match_table = dbi_spi_of_match,
> + },
> + .probe = dbi_spi_probe,
> +};
> +module_spi_driver(dbi_spi_driver);
> +
> +MODULE_DESCRIPTION("DBI SPI bus driver");
> +MODULE_AUTHOR("Paul Cercueil ");
> +MODULE_LICENSE("GPL");
--
Regards,
Laurent Pinchart
al
> * @name: DSI peripheral chip type
> + * @bus_type: MIPI bus type (MIPI_DEVICE_TYPE_DSI/...)
> * @channel: virtual channel assigned to the peripheral
> * @format: pixel format for video mode
> * @lanes: number of active data lanes
> @@ -178,6 +189,7 @@ struct mipi_dsi_device {
> struct device dev;
>
> char name[DSI_DEV_NAME_SIZE];
> + unsigned int bus_type;
> unsigned int channel;
> unsigned int lanes;
> enum mipi_dsi_pixel_format format;
--
Regards,
Laurent Pinchart
501 - 600 of 4490 matches
Mail list logo
