From: Ian Arkver <ian.arkver.dev@gmail.com>
To: Michael Tretter <m.tretter@pengutronix.de>,
Philipp Zabel <p.zabel@pengutronix.de>,
linux-media@vger.kernel.org, devicetree@vger.kernel.org,
Marek Vasut <marex@denx.de>, Rob Herring <robh+dt@kernel.org>,
Mauro Carvalho Chehab <mchehab@kernel.org>,
Sakari Ailus <sakari.ailus@linux.intel.com>,
kernel@pengutronix.de
Subject: Re: [PATCH v5 3/3] media: i2c: isl7998x: Add driver for Intersil ISL7998x
Date: Thu, 14 Oct 2021 13:07:07 +0100 [thread overview]
Message-ID: <8d18cba6-1eb0-ae82-a8e2-1c39d694a77f@gmail.com> (raw)
In-Reply-To: <20211014110459.GD31981@pengutronix.de>
On 14/10/2021 12:04, Michael Tretter wrote:
> On Thu, 14 Oct 2021 11:45:25 +0100, Ian Arkver wrote:
>> On 14/10/2021 11:17, Philipp Zabel wrote:
>>> On Thu, 2021-10-14 at 11:34 +0200, Michael Tretter wrote:
>>>> On Wed, 13 Oct 2021 10:05:30 +0200, Michael Tretter wrote:
>>>>> On Tue, 12 Oct 2021 15:27:11 +0200, Philipp Zabel wrote:
>>> [...]
>>>>>>> +static int isl7998x_wait_power_on(struct isl7998x *isl7998x)
>>>>>>> +{
>>>>>>> + struct device *dev = isl7998x->subdev.dev;
>>>>>>> + unsigned int retry;
>>>>>>> + u32 chip_id;
>>>>>>> + int ret = -ETIMEDOUT;
>>>>>>> +
>>>>>>> + for (retry = 10; ret && retry > 0; retry--) {
>>>>>>> + ret = regmap_read(isl7998x->regmap,
>>>>>>> + ISL7998x_REG_P0_PRODUCT_ID_CODE, &chip_id);
>>>>>>> + usleep_range(1000, 2000);
>>>>>>> + }
>>>>>>
>>>>>> Consider using regmap_read_poll_timeout() here.
>>>>>
>>>>> Ack. I forgot about this function.
>>>>
>>>> regmap_read_poll_timeout() cannot be used here, because it returns if
>>>> regmap_read() returns an error. The driver uses the return value of
>>>> regmap_read() to detect, if the chip is available, and should continue polling
>>>> if regmap_read() failed. I can implement the necessary behavior with
>>>> read_poll_timeout(), but am not sure if it is really worth it.
>>>
>>> Oh, right. I still think so, but your call.
>>>
>> This wait_power_on function seems odd to me. Wouldn't it be better to just
>> wait for the power-on delay specified in the datasheet and then
>> unconditionally go into isl7998x_init? If the device has failed to come up,
>> that init will fail in its regmap accesses. If you're trying to do the init
>> earlier than the datasheet specified time then being able to read the
>> product id code doesn't guarantee the rest of the chip is ready. If there's
>> no datasheet specification maybe just wait 10ms to 20ms?
>
> The datasheet does not specify the power-on delay. The wait_power_on() enables
> the driver to at least tell the user that the chip was not detected and print
> the exact chip variant if it was detected. I think this is still better than
> waiting some arbitrary time and hoping for the best.
Thanks Michael, I can see how the prints could be useful and I'd
neglected them before. I see now this is the only place the device ID is
read and reported.
Regards,
Ian
prev parent reply other threads:[~2021-10-14 12:07 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-12 8:41 [PATCH v5 0/3] media: i2c: isl7998x: Add driver for Intersil ISL7998x Michael Tretter
2021-10-12 8:41 ` [PATCH v5 1/3] media: imx6-mipi-csi2: use pre_streamon callback to set sensor into LP11 Michael Tretter
2021-10-12 12:22 ` Philipp Zabel
2021-10-12 8:41 ` [PATCH v5 2/3] media: dt-bindings: Add Intersil ISL79987 DT bindings Michael Tretter
2021-10-12 8:41 ` [PATCH v5 3/3] media: i2c: isl7998x: Add driver for Intersil ISL7998x Michael Tretter
2021-10-12 13:27 ` Philipp Zabel
2021-10-13 8:05 ` Michael Tretter
2021-10-14 9:34 ` Michael Tretter
2021-10-14 10:17 ` Philipp Zabel
2021-10-14 10:45 ` Ian Arkver
2021-10-14 11:04 ` Michael Tretter
2021-10-14 12:07 ` Ian Arkver [this message]
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=8d18cba6-1eb0-ae82-a8e2-1c39d694a77f@gmail.com \
--to=ian.arkver.dev@gmail.com \
--cc=devicetree@vger.kernel.org \
--cc=kernel@pengutronix.de \
--cc=linux-media@vger.kernel.org \
--cc=m.tretter@pengutronix.de \
--cc=marex@denx.de \
--cc=mchehab@kernel.org \
--cc=p.zabel@pengutronix.de \
--cc=robh+dt@kernel.org \
--cc=sakari.ailus@linux.intel.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;
as well as URLs for NNTP newsgroup(s).