All of lore.kernel.org
 help / color / mirror / Atom feed
From: Maxime Ripard <maxime@cerno.tech>
To: Kevin Tang <kevin3.tang@gmail.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
	Sean Paul <sean@poorly.run>, David Airlie <airlied@linux.ie>,
	Daniel Vetter <daniel@ffwll.ch>, Rob Herring <robh+dt@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Orson Zhai <orsonzhai@gmail.com>,
	Chunyan Zhang <zhang.lyra@gmail.com>,
	"Linux-Kernel@Vger. Kernel. Org" <linux-kernel@vger.kernel.org>,
	ML dri-devel <dri-devel@lists.freedesktop.org>,
	devicetree@vger.kernel.org
Subject: Re: [PATCH v5 6/6] drm/sprd: add Unisoc's drm mipi dsi&dphy driver
Date: Tue, 18 May 2021 16:20:59 +0200	[thread overview]
Message-ID: <20210518142059.o7ql6de4src53y4l@gilmour> (raw)
In-Reply-To: <CAFPSGXZR9cSneohFk-5RQbqgkvQHFU0=Te=J1m+k=xqcWWrp4A@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 5064 bytes --]

On Wed, May 12, 2021 at 09:53:06PM +0800, Kevin Tang wrote:
> > > +struct dsi_reg {
> > > +     union _0x00 {
> > > +             u32 val;
> > > +             struct _DSI_VERSION {
> > > +             u32 dsi_version: 16;
> > > +             u32 reserved: 16;
> > > +             } bits;
> > > +     } DSI_VERSION;
> >
> > Using unions and structures to define the register is really frowned
> > upon in favor of defines, like you rightfully did in the crtc driver.
>
> This workload is too big, this design has been used for many years,
> so I actually want to keep it the same, but if it really doesn’t meet
> the current design.
>
> I can change the design, but it may take a lot of time......

There's no rush :)

> > > +static int sprd_dsi_find_panel(struct sprd_dsi *dsi)
> > > +{
> > > +     struct device *dev = dsi->host.dev;
> > > +     struct device_node *child, *lcds_node;
> > > +     struct drm_panel *panel;
> > > +
> > > +     /* search /lcds child node first */
> > > +     lcds_node = of_find_node_by_path("/lcds");
> > > +     for_each_child_of_node(lcds_node, child) {
> > > +             panel = of_drm_find_panel(child);
> > > +             if (!IS_ERR(panel)) {
> > > +                     dsi->panel = panel;
> > > +                     return 0;
> > > +             }
> > > +     }
> >
> > That's not part of your binding
> Ok, i will remove it.
> >
> > > +
> > > +     /*
> > > +      * If /lcds child node search failed, we search
> > > +      * the child of dsi host node.
> > > +      */
> > > +     for_each_child_of_node(dev->of_node, child) {
> > > +             panel = of_drm_find_panel(child);
> > > +             if (!IS_ERR(panel)) {
> > > +                     dsi->panel = panel;
> > > +                     return 0;
> > > +             }
> > > +     }
> >
> > And you don't need this either. You'll register a mipi_dsi_host,
> > that will in turn probe all the devices under that bus, and will
> > then call the .attach callback.
>
> This should be move to the .attach callback?

The panel pointer assignment can. The rest is useless.

> > > +     drm_err(dsi->drm, "of_drm_find_panel() failed\n");
> > > +     return -ENODEV;
> > > +}
> > > +
> > > +static int sprd_dsi_host_attach(struct mipi_dsi_host *host,
> > > +                        struct mipi_dsi_device *slave)
> > > +{
> > > +     struct sprd_dsi *dsi = host_to_dsi(host);
> > > +     struct dsi_context *ctx = &dsi->ctx;
> > > +     int ret;
> > > +
> > > +     dsi->slave = slave;
> > > +     ctx->lanes = slave->lanes;
> > > +     ctx->format = slave->format;
> > > +     ctx->byte_clk = slave->hs_rate / 8;
> > > +     ctx->esc_clk = slave->lp_rate;
> > > +
> > > +     if (slave->mode_flags & MIPI_DSI_MODE_VIDEO)
> > > +             ctx->work_mode = DSI_MODE_VIDEO;
> > > +     else
> > > +             ctx->work_mode = DSI_MODE_CMD;
> > > +
> > > +     if (slave->mode_flags & MIPI_DSI_MODE_VIDEO_BURST)
> > > +             ctx->burst_mode = VIDEO_BURST_WITH_SYNC_PULSES;
> > > +     else if (slave->mode_flags & MIPI_DSI_MODE_VIDEO_SYNC_PULSE)
> > > +             ctx->burst_mode = VIDEO_NON_BURST_WITH_SYNC_PULSES;
> > > +     else
> > > +             ctx->burst_mode = VIDEO_NON_BURST_WITH_SYNC_EVENTS;
> > > +
> > > +     if (slave->mode_flags & MIPI_DSI_CLOCK_NON_CONTINUOUS)
> > > +             ctx->nc_clk_en = true;
> >
> > I'm not sure why you need to duplicate all this, can't you just
> > dereference the dsi->slave pointer when you need it?
>
> Sorry, can you help me with a demo?

In your sprd_dsi_encoder_enable function, you call sprd_dphy_init which
takes a pointer to struct dsi_context, and will call, say,
dsi_phy_datalane_en, using ctx->lanes.

Since you have access to the struct sprd_dsi in sprd_dsi_encoder_enable,
why not pass it and the mipi_dsi_device pointer to sprd_dphy_init, and
dereference slave->lanes in dsi_phy_datalane_en?

This will greatly reduce the size of the dsi_context structure.

> > > +static enum drm_mode_status
> > > +sprd_dsi_connector_mode_valid(struct drm_connector *connector,
> > > +                      struct drm_display_mode *mode)
> > > +{
> > > +     struct sprd_dsi *dsi = connector_to_dsi(connector);
> > > +
> > > +     drm_dbg(dsi->drm, "%s() mode: "DRM_MODE_FMT"\n", __func__, DRM_MODE_ARG(mode));
> > > +
> > > +     if (mode->type & DRM_MODE_TYPE_PREFERRED) {
> > > +             dsi->mode = mode;
> > > +             drm_display_mode_to_videomode(dsi->mode, &dsi->ctx.vm);
> > > +     }
> >
> > Again, what happens if the mode isn't the preferred one?
>
> We hope to restore the low-resolution image to the original resolution
> through the scaling algorithm while keeping the resolution unchanged.
> So whether it's dpu or dsi, must be keeping on preferred mode.

Is there any particular reason to do so? Why do you need to take the
preferred mode into account in the first place? Can't you just use
whatever drm_display_mode is being passed?

Maxime

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: Maxime Ripard <maxime@cerno.tech>
To: Kevin Tang <kevin3.tang@gmail.com>
Cc: Mark Rutland <mark.rutland@arm.com>,
	devicetree@vger.kernel.org, David Airlie <airlied@linux.ie>,
	Chunyan Zhang <zhang.lyra@gmail.com>,
	"Linux-Kernel@Vger. Kernel. Org" <linux-kernel@vger.kernel.org>,
	ML dri-devel <dri-devel@lists.freedesktop.org>,
	Rob Herring <robh+dt@kernel.org>,
	Orson Zhai <orsonzhai@gmail.com>, Sean Paul <sean@poorly.run>
Subject: Re: [PATCH v5 6/6] drm/sprd: add Unisoc's drm mipi dsi&dphy driver
Date: Tue, 18 May 2021 16:20:59 +0200	[thread overview]
Message-ID: <20210518142059.o7ql6de4src53y4l@gilmour> (raw)
In-Reply-To: <CAFPSGXZR9cSneohFk-5RQbqgkvQHFU0=Te=J1m+k=xqcWWrp4A@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 5064 bytes --]

On Wed, May 12, 2021 at 09:53:06PM +0800, Kevin Tang wrote:
> > > +struct dsi_reg {
> > > +     union _0x00 {
> > > +             u32 val;
> > > +             struct _DSI_VERSION {
> > > +             u32 dsi_version: 16;
> > > +             u32 reserved: 16;
> > > +             } bits;
> > > +     } DSI_VERSION;
> >
> > Using unions and structures to define the register is really frowned
> > upon in favor of defines, like you rightfully did in the crtc driver.
>
> This workload is too big, this design has been used for many years,
> so I actually want to keep it the same, but if it really doesn’t meet
> the current design.
>
> I can change the design, but it may take a lot of time......

There's no rush :)

> > > +static int sprd_dsi_find_panel(struct sprd_dsi *dsi)
> > > +{
> > > +     struct device *dev = dsi->host.dev;
> > > +     struct device_node *child, *lcds_node;
> > > +     struct drm_panel *panel;
> > > +
> > > +     /* search /lcds child node first */
> > > +     lcds_node = of_find_node_by_path("/lcds");
> > > +     for_each_child_of_node(lcds_node, child) {
> > > +             panel = of_drm_find_panel(child);
> > > +             if (!IS_ERR(panel)) {
> > > +                     dsi->panel = panel;
> > > +                     return 0;
> > > +             }
> > > +     }
> >
> > That's not part of your binding
> Ok, i will remove it.
> >
> > > +
> > > +     /*
> > > +      * If /lcds child node search failed, we search
> > > +      * the child of dsi host node.
> > > +      */
> > > +     for_each_child_of_node(dev->of_node, child) {
> > > +             panel = of_drm_find_panel(child);
> > > +             if (!IS_ERR(panel)) {
> > > +                     dsi->panel = panel;
> > > +                     return 0;
> > > +             }
> > > +     }
> >
> > And you don't need this either. You'll register a mipi_dsi_host,
> > that will in turn probe all the devices under that bus, and will
> > then call the .attach callback.
>
> This should be move to the .attach callback?

The panel pointer assignment can. The rest is useless.

> > > +     drm_err(dsi->drm, "of_drm_find_panel() failed\n");
> > > +     return -ENODEV;
> > > +}
> > > +
> > > +static int sprd_dsi_host_attach(struct mipi_dsi_host *host,
> > > +                        struct mipi_dsi_device *slave)
> > > +{
> > > +     struct sprd_dsi *dsi = host_to_dsi(host);
> > > +     struct dsi_context *ctx = &dsi->ctx;
> > > +     int ret;
> > > +
> > > +     dsi->slave = slave;
> > > +     ctx->lanes = slave->lanes;
> > > +     ctx->format = slave->format;
> > > +     ctx->byte_clk = slave->hs_rate / 8;
> > > +     ctx->esc_clk = slave->lp_rate;
> > > +
> > > +     if (slave->mode_flags & MIPI_DSI_MODE_VIDEO)
> > > +             ctx->work_mode = DSI_MODE_VIDEO;
> > > +     else
> > > +             ctx->work_mode = DSI_MODE_CMD;
> > > +
> > > +     if (slave->mode_flags & MIPI_DSI_MODE_VIDEO_BURST)
> > > +             ctx->burst_mode = VIDEO_BURST_WITH_SYNC_PULSES;
> > > +     else if (slave->mode_flags & MIPI_DSI_MODE_VIDEO_SYNC_PULSE)
> > > +             ctx->burst_mode = VIDEO_NON_BURST_WITH_SYNC_PULSES;
> > > +     else
> > > +             ctx->burst_mode = VIDEO_NON_BURST_WITH_SYNC_EVENTS;
> > > +
> > > +     if (slave->mode_flags & MIPI_DSI_CLOCK_NON_CONTINUOUS)
> > > +             ctx->nc_clk_en = true;
> >
> > I'm not sure why you need to duplicate all this, can't you just
> > dereference the dsi->slave pointer when you need it?
>
> Sorry, can you help me with a demo?

In your sprd_dsi_encoder_enable function, you call sprd_dphy_init which
takes a pointer to struct dsi_context, and will call, say,
dsi_phy_datalane_en, using ctx->lanes.

Since you have access to the struct sprd_dsi in sprd_dsi_encoder_enable,
why not pass it and the mipi_dsi_device pointer to sprd_dphy_init, and
dereference slave->lanes in dsi_phy_datalane_en?

This will greatly reduce the size of the dsi_context structure.

> > > +static enum drm_mode_status
> > > +sprd_dsi_connector_mode_valid(struct drm_connector *connector,
> > > +                      struct drm_display_mode *mode)
> > > +{
> > > +     struct sprd_dsi *dsi = connector_to_dsi(connector);
> > > +
> > > +     drm_dbg(dsi->drm, "%s() mode: "DRM_MODE_FMT"\n", __func__, DRM_MODE_ARG(mode));
> > > +
> > > +     if (mode->type & DRM_MODE_TYPE_PREFERRED) {
> > > +             dsi->mode = mode;
> > > +             drm_display_mode_to_videomode(dsi->mode, &dsi->ctx.vm);
> > > +     }
> >
> > Again, what happens if the mode isn't the preferred one?
>
> We hope to restore the low-resolution image to the original resolution
> through the scaling algorithm while keeping the resolution unchanged.
> So whether it's dpu or dsi, must be keeping on preferred mode.

Is there any particular reason to do so? Why do you need to take the
preferred mode into account in the first place? Can't you just use
whatever drm_display_mode is being passed?

Maxime

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

  reply	other threads:[~2021-05-18 14:21 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-25 12:36 [PATCH v5 0/6] Add Unisoc's drm kms module Kevin Tang
2021-04-25 12:36 ` Kevin Tang
2021-04-25 12:36 ` [PATCH v5 1/6] dt-bindings: display: add Unisoc's drm master bindings Kevin Tang
2021-04-25 12:36   ` Kevin Tang
2021-04-30  9:12   ` Maxime Ripard
2021-04-30  9:12     ` Maxime Ripard
2021-04-25 12:36 ` [PATCH v5 2/6] drm/sprd: add Unisoc's drm kms master Kevin Tang
2021-04-25 12:36   ` Kevin Tang
2021-04-25 12:36 ` [PATCH v5 3/6] dt-bindings: display: add Unisoc's dpu bindings Kevin Tang
2021-04-25 12:36   ` Kevin Tang
2021-04-25 12:36 ` [PATCH v5 4/6] drm/sprd: add Unisoc's drm display controller driver Kevin Tang
2021-04-25 12:36   ` Kevin Tang
2021-04-30  9:22   ` Maxime Ripard
2021-04-30  9:22     ` Maxime Ripard
2021-04-30 12:20     ` Kevin Tang
2021-04-30 12:20       ` Kevin Tang
2021-05-17  9:27       ` Joerg Roedel
2021-05-17  9:27         ` Joerg Roedel
2021-05-17 16:35         ` Robin Murphy
2021-05-17 16:35           ` Robin Murphy
2021-05-26  7:59           ` Chunyan Zhang
2021-05-26  8:07             ` Chunyan Zhang
2021-05-26  8:07               ` Chunyan Zhang
2021-05-14 13:18     ` Kevin Tang
2021-05-14 13:18       ` Kevin Tang
2021-05-18 14:23       ` Maxime Ripard
2021-05-18 14:23         ` Maxime Ripard
2021-05-12  6:25   ` Chunyan Zhang
2021-05-12  6:25     ` Chunyan Zhang
2021-04-25 12:36 ` [PATCH v5 5/6] dt-bindings: display: add Unisoc's mipi dsi controller bindings Kevin Tang
2021-04-25 12:36   ` Kevin Tang
2021-04-25 12:36 ` [PATCH v5 6/6] drm/sprd: add Unisoc's drm mipi dsi&dphy driver Kevin Tang
2021-04-25 12:36   ` Kevin Tang
2021-04-25 16:27   ` kernel test robot
2021-04-30  9:35   ` Maxime Ripard
2021-05-12 13:53     ` Kevin Tang
2021-05-18 14:20       ` Maxime Ripard [this message]
2021-05-18 14:20         ` Maxime Ripard
2021-04-27  0:21 kernel test robot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210518142059.o7ql6de4src53y4l@gilmour \
    --to=maxime@cerno.tech \
    --cc=airlied@linux.ie \
    --cc=daniel@ffwll.ch \
    --cc=devicetree@vger.kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=kevin3.tang@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=mark.rutland@arm.com \
    --cc=orsonzhai@gmail.com \
    --cc=robh+dt@kernel.org \
    --cc=sean@poorly.run \
    --cc=zhang.lyra@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.