From: Ray Jui <ray.jui@broadcom.com>
To: Rob Herring <robh@kernel.org>
Cc: Wolfram Sang <wsa@the-dreams.de>,
Mark Rutland <mark.rutland@arm.com>,
linux-i2c@vger.kernel.org, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org,
bcm-kernel-feedback-list@broadcom.com,
Rayagonda Kokatanur <rayagonda.kokatanur@broadcom.com>
Subject: Re: [PATCH v4 3/8] dt-bindings: i2c: iproc: make 'interrupts' optional
Date: Wed, 13 Feb 2019 14:06:38 -0800 [thread overview]
Message-ID: <796d9a96-f3f9-cb9a-faa3-4baf0e72da65@broadcom.com> (raw)
In-Reply-To: <20190213211651.GA10705@bogus>
Hi Rob,
On 2/13/2019 1:16 PM, Rob Herring wrote:
> On Mon, Feb 04, 2019 at 03:15:49PM -0800, Ray Jui wrote:
>> In prep for the introduction of polling mode into the driver, update the
>> binding document to make the 'interrupts' property optional
>>
>> Signed-off-by: Ray Jui <ray.jui@broadcom.com>
>> Signed-off-by: Rayagonda Kokatanur <rayagonda.kokatanur@broadcom.com>
>> ---
>> .../devicetree/bindings/i2c/brcm,iproc-i2c.txt | 10 +++++++---
>> 1 file changed, 7 insertions(+), 3 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/i2c/brcm,iproc-i2c.txt b/Documentation/devicetree/bindings/i2c/brcm,iproc-i2c.txt
>> index 81f982ccca31..d3a3620b1f06 100644
>> --- a/Documentation/devicetree/bindings/i2c/brcm,iproc-i2c.txt
>> +++ b/Documentation/devicetree/bindings/i2c/brcm,iproc-i2c.txt
>> @@ -9,9 +9,6 @@ Required properties:
>> Define the base and range of the I/O address space that contain the iProc
>> I2C controller registers
>>
>> -- interrupts:
>> - Should contain the I2C interrupt
>> -
>> - clock-frequency:
>> This is the I2C bus clock. Need to be either 100000 or 400000
>>
>> @@ -21,6 +18,13 @@ Required properties:
>> - #size-cells:
>> Always 0
>>
>> +Optional properties:
>> +
>> +- interrupts:
>> + Should contain the I2C interrupt. If unspecified, driver will fall back to
>> + polling mode
>
> What determines when you want to use polling mode? I'm not sure DT
> is the best way to control this unless it's really a property of
> the h/w. Driver behavior is really outside the scope of the DT. u-boot
> would use polling even if an interrupt is specified, for example.
>
It's tied to the particular revision of the I2C controller, i.e., the
iProc NIC i2c controller does not have interrupt line wired. In this
case, the behavior is determined by the DT compatible string of the
iProc I2C device. I thought that it makes sense to now move the
'interrupts' property to be under "Optional" than "Required" which is
basically what this change is.
> Rob
>
next prev parent reply other threads:[~2019-02-13 22:06 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-04 23:15 [PATCH v4 0/8] iProc I2C slave mode and NIC mode Ray Jui
2019-02-04 23:15 ` [PATCH v4 1/8] i2c: iproc: Extend I2C read up to 255 bytes Ray Jui
2019-02-04 23:15 ` [PATCH v4 2/8] i2c: iproc: Add slave mode support Ray Jui
2019-02-04 23:15 ` [PATCH v4 3/8] dt-bindings: i2c: iproc: make 'interrupts' optional Ray Jui
2019-02-13 21:16 ` Rob Herring
2019-02-13 22:06 ` Ray Jui [this message]
2019-02-14 14:16 ` Rob Herring
2019-02-14 17:36 ` Ray Jui
2019-02-04 23:15 ` [PATCH v4 4/8] i2c: iproc: add polling support Ray Jui
2019-02-04 23:15 ` [PATCH v4 5/8] i2c: iproc: use wrapper for read/write access Ray Jui
2019-02-04 23:15 ` [PATCH v4 6/8] dt-bindings: i2c: iproc: add "brcm,iproc-nic-i2c" compatible string Ray Jui
2019-02-13 21:18 ` Rob Herring
2019-02-13 22:09 ` Ray Jui
2019-02-14 14:02 ` [PATCH v4 6/8] dt-bindings: i2c: iproc: add "brcm, iproc-nic-i2c" " Rob Herring
2019-02-14 17:36 ` [PATCH v4 6/8] dt-bindings: i2c: iproc: add "brcm,iproc-nic-i2c" " Ray Jui
2019-02-04 23:15 ` [PATCH v4 7/8] i2c: iproc: add NIC I2C support Ray Jui
2019-02-04 23:15 ` [PATCH v4 8/8] arm64: dts: Stingray: Add NIC i2c device node Ray Jui
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=796d9a96-f3f9-cb9a-faa3-4baf0e72da65@broadcom.com \
--to=ray.jui@broadcom.com \
--cc=bcm-kernel-feedback-list@broadcom.com \
--cc=devicetree@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=rayagonda.kokatanur@broadcom.com \
--cc=robh@kernel.org \
--cc=wsa@the-dreams.de \
/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