dri-devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Sam Ravnborg <sam@ravnborg.org>
To: Xin Ji <xji@analogixsemi.com>
Cc: devel@driverdev.osuosl.org,
	Jernej Skrabec <jernej.skrabec@siol.net>,
	Pi-Hsun Shih <pihsun@chromium.org>,
	Jonas Karlman <jonas@kwiboo.se>, David Airlie <airlied@linux.ie>,
	Neil Armstrong <narmstrong@baylibre.com>,
	linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
	Andrzej Hajda <a.hajda@samsung.com>,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	Dan Carpenter <dan.carpenter@oracle.com>,
	Sheng Pan <span@analogixsemi.com>
Subject: Re: [PATCH v8 2/2] drm/bridge: anx7625: Add anx7625 MIPI DSI/DPI to DP bridge driver
Date: Thu, 30 Apr 2020 09:03:24 +0200	[thread overview]
Message-ID: <20200430070324.GA9545@ravnborg.org> (raw)
In-Reply-To: <20200430062416.GD6645@xin-VirtualBox>

Hi Xin Ji.

> > > +static void anx7625_power_on_init(struct anx7625_data *ctx)
> > > +{
> > > +	int retry_count, i;
> > > +	int ret;
> > > +	struct device *dev = &ctx->client->dev;
> > > +
> > > +	for (retry_count = 0; retry_count < 3; retry_count++) {
> > > +		anx7625_power_on(ctx);
> > > +		anx7625_config(ctx);
> > > +
> > > +		for (i = 0; i < OCM_LOADING_TIME; i++) {
> > Code in this for loop is a candidate for a helper function.
> I didn't find any helper function can be used, so I'll keep it.
I was not very clear in my way to express this, sorry.

> > 
> > > +			/* check interface workable */
> > > +			ret = anx7625_reg_read(ctx, ctx->i2c.rx_p0_client,
> > > +					       FLASH_LOAD_STA);
> > > +			if (ret < 0) {
> > > +				DRM_ERROR("IO error : access flash load.\n");
> > > +				return;
> > > +			}
> > > +			if ((ret & FLASH_LOAD_STA_CHK) == FLASH_LOAD_STA_CHK) {
> > > +				anx7625_disable_pd_protocol(ctx);
> > > +				DRM_DEV_DEBUG_DRIVER(dev,
> > > +						     "Firmware ver %02x%02x,",
> > > +					anx7625_reg_read(ctx,
> > > +							 ctx->i2c.rx_p0_client,
> > > +							 OCM_FW_VERSION),
> > > +					anx7625_reg_read(ctx,
> > > +							 ctx->i2c.rx_p0_client,
> > > +							 OCM_FW_REVERSION));
> > > +				DRM_DEV_DEBUG_DRIVER(dev, "Driver version %s\n",
> > > +						     ANX7625_DRV_VERSION);
> > > +
> > > +				return;
> > > +			}
> > > +			usleep_range(1000, 1100);
> > > +		}
What I wanted to express is that the for loop is heavily indented.
So create a small function like:

anx7625_power_on_interface(ctx)
{
	/* check interface workable */
	ret = anx7625_reg_read(ctx, ctx->i2c.rx_p0_client, FLASH_LOAD_STA);
	if (ret < 0) {
	        DRM_ERROR("IO error : access flash load.\n");
	        return;
	}
	if ((ret & FLASH_LOAD_STA_CHK) == FLASH_LOAD_STA_CHK) {
	        anx7625_disable_pd_protocol(ctx);
	        DRM_DEV_DEBUG_DRIVER(dev, "Firmware ver %02x%02x,",
	                anx7625_reg_read(ctx, ctx->i2c.rx_p0_client,
                                         OCM_FW_VERSION), anx7625_reg_read(ctx,
	                                 ctx->i2c.rx_p0_client, OCM_FW_REVERSION));
	        DRM_DEV_DEBUG_DRIVER(dev, "Driver version %s\n",
	                             ANX7625_DRV_VERSION);
		retunrn 1;
	}
	return 0;
}

and then

	for (i = 0; i < OCM_LOADING_TIME; i++) {
		if (anx7625_power_on_interface(ctx))
			return;
		else
			usleep_range(1000, 1100);
	}

Or something like that. To make it more readable.
I think you get the idea now.


> > > +		container_of(work, struct anx7625_data, extcon_wq);
> > > +	int state = extcon_get_state(ctx->extcon, EXTCON_DISP_DP);
> > > +
> > > +	mutex_lock(&ctx->lock);
> > > +	anx7625_chip_control(ctx, state);
> > > +	mutex_unlock(&ctx->lock);
> > I tried to follow the locking - but failed.
> > Could you check that locking seems correct.
> > 
> > A standard bridge driver do not need locking,
> > but this is no small bridge driver so I do not imply that
> > locking is not needed. Only that I would like you
> > to check it again as I could not follow it.
> OK, it seems lock is not necessary, I'll remove itA
It has a worker, so please be careful in you analysis.

> > 
> > > +
> > > +	if (pdata->panel_flags == 1)
> > > +		pdata->internal_panel = 1;
> > > +	else if (pdata->panel_flags == 2)
> > > +		pdata->extcon_supported = 1;
> > > +	DRM_DEV_DEBUG_DRIVER(dev, "%s support extcon, %s internal panel\n",
> > > +			     pdata->extcon_supported ? "" : "not",
> > > +			     pdata->internal_panel ? "has" : "no");
> > > +
> > The way the internal panel - versus external connector is modelled
> > looks like it could use some of the abstractions used by other bridge
> > drivers.
> > 
> > The connector_type shall for example for internal panels come
> > form the panel.
> > And use the panel bridge driver - see examples in patches I referenced
> > before.
> > 
> > And external connectors may beneft from using the
> > display-connector bridge driver.
> I'm not familiar with it, the extcon interface is Google engineer give
> to me, I just follow their sample driver. If you think it is not good,
> I'll remove the extcon support.
It would be better to start without, and then add it later
so we end up with a clean design.

I for one would have an easier time reviewing.

So please go ahead and remove it for now.


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

  reply	other threads:[~2020-04-30  7:03 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-27  6:16 [PATCH v8 0/2] Add initial support for slimport anx7625 Xin Ji
2020-04-27  6:17 ` [PATCH v8 1/2] dt-bindings: drm/bridge: anx7625: MIPI to DP transmitter binding Xin Ji
2020-04-27 18:49   ` Sam Ravnborg
2020-04-30  6:01     ` Xin Ji
2020-04-27  6:18 ` [PATCH v8 2/2] drm/bridge: anx7625: Add anx7625 MIPI DSI/DPI to DP bridge driver Xin Ji
2020-04-27 20:00   ` Sam Ravnborg
2020-04-30  6:24     ` Xin Ji
2020-04-30  7:03       ` Sam Ravnborg [this message]
2020-04-30  7:11         ` Xin Ji
2020-04-29  2:10   ` Nicolas Boichat
2020-04-30  6:30     ` Xin Ji
2020-04-27 18:53 ` [PATCH v8 0/2] Add initial support for slimport anx7625 Sam Ravnborg
2020-04-30  6:03   ` Xin Ji

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=20200430070324.GA9545@ravnborg.org \
    --to=sam@ravnborg.org \
    --cc=a.hajda@samsung.com \
    --cc=airlied@linux.ie \
    --cc=dan.carpenter@oracle.com \
    --cc=devel@driverdev.osuosl.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=jernej.skrabec@siol.net \
    --cc=jonas@kwiboo.se \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=narmstrong@baylibre.com \
    --cc=pihsun@chromium.org \
    --cc=span@analogixsemi.com \
    --cc=xji@analogixsemi.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox