diff mbox

[RFC,07/13] dt-bindings: i2c: Add support for 'i2c-bus' subnode

Message ID 1466165027-17917-8-git-send-email-jonathanh@nvidia.com
State Superseded
Headers show

Commit Message

Jon Hunter June 17, 2016, 12:03 p.m. UTC
The I2C driver core for boards using device-tree assumes any subnode of
an I2C adapter in the device-tree blob as being a I2C slave device.
Although this makes complete sense, some I2C adapters may have subnodes
which are not I2C slaves but subnodes presenting other features. For
example some Tegra devices have an I2C interface which may share its
pins with other devices and to share these pins subnodes for
representing these pins so they have be shared via the pinctrl framework
are needed.

To allow I2C adapters to have non-I2C specific subnodes in device-tree
that are not parsed by the I2C driver core by adding support for a
'i2c-bus' subnode where I2C slaves can be placed. If the 'i2c-bus'
subnode is present then all I2C slaves must be placed under this subnode.

Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
---
 Documentation/devicetree/bindings/i2c/i2c.txt | 8 ++++++++
 1 file changed, 8 insertions(+)

Comments

Thierry Reding June 17, 2016, 4:23 p.m. UTC | #1
On Fri, Jun 17, 2016 at 01:03:41PM +0100, Jon Hunter wrote:
> The I2C driver core for boards using device-tree assumes any subnode of
> an I2C adapter in the device-tree blob as being a I2C slave device.
> Although this makes complete sense, some I2C adapters may have subnodes
> which are not I2C slaves but subnodes presenting other features. For
> example some Tegra devices have an I2C interface which may share its
> pins with other devices and to share these pins subnodes for
> representing these pins so they have be shared via the pinctrl framework
> are needed.
> 
> To allow I2C adapters to have non-I2C specific subnodes in device-tree
> that are not parsed by the I2C driver core by adding support for a
> 'i2c-bus' subnode where I2C slaves can be placed. If the 'i2c-bus'
> subnode is present then all I2C slaves must be placed under this subnode.
> 
> Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
> ---
>  Documentation/devicetree/bindings/i2c/i2c.txt | 8 ++++++++
>  1 file changed, 8 insertions(+)

I think this makes a lot of sense, so:

Acked-by: Thierry Reding <treding@nvidia.com>

One minor inconsistency below...

> diff --git a/Documentation/devicetree/bindings/i2c/i2c.txt b/Documentation/devicetree/bindings/i2c/i2c.txt
> index f31b2ad1552b..ed56b08c7e6e 100644
> --- a/Documentation/devicetree/bindings/i2c/i2c.txt
> +++ b/Documentation/devicetree/bindings/i2c/i2c.txt
> @@ -32,6 +32,14 @@ wants to support one of the below features, it should adapt the bindings below.
>  - clock-frequency
>  	frequency of bus clock in Hz.
>  
> +- i2c-bus
> +	For I2C adapters that have child nodes that are a mixture of both I2C
> +	devices and non-I2C devices (such as a pin controller), the 'i2c-bus'
> +	subnode can be used for populating I2C devices to prevent the I2C core
> +	from attempting to add any non-i2c nodes as I2C devices. If 'i2c-bus'

"non-I2C"

Thierry
Mark Rutland June 17, 2016, 4:30 p.m. UTC | #2
On Fri, Jun 17, 2016 at 01:03:41PM +0100, Jon Hunter wrote:
> The I2C driver core for boards using device-tree assumes any subnode of
> an I2C adapter in the device-tree blob as being a I2C slave device.
> Although this makes complete sense, some I2C adapters may have subnodes
> which are not I2C slaves but subnodes presenting other features. For
> example some Tegra devices have an I2C interface which may share its
> pins with other devices and to share these pins subnodes for
> representing these pins so they have be shared via the pinctrl framework
> are needed.
> 
> To allow I2C adapters to have non-I2C specific subnodes in device-tree
> that are not parsed by the I2C driver core by adding support for a
> 'i2c-bus' subnode where I2C slaves can be placed. If the 'i2c-bus'
> subnode is present then all I2C slaves must be placed under this subnode.
> 
> Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
> ---
>  Documentation/devicetree/bindings/i2c/i2c.txt | 8 ++++++++
>  1 file changed, 8 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/i2c/i2c.txt b/Documentation/devicetree/bindings/i2c/i2c.txt
> index f31b2ad1552b..ed56b08c7e6e 100644
> --- a/Documentation/devicetree/bindings/i2c/i2c.txt
> +++ b/Documentation/devicetree/bindings/i2c/i2c.txt
> @@ -32,6 +32,14 @@ wants to support one of the below features, it should adapt the bindings below.
>  - clock-frequency
>  	frequency of bus clock in Hz.
>  
> +- i2c-bus
> +	For I2C adapters that have child nodes that are a mixture of both I2C
> +	devices and non-I2C devices (such as a pin controller), the 'i2c-bus'
> +	subnode can be used for populating I2C devices to prevent the I2C core
> +	from attempting to add any non-i2c nodes as I2C devices. If 'i2c-bus'
> +	subnode is present then all I2C slaves must be added under this
> +	subnode.

The general idea seems sound.

It would be good if we could remove the mention of the I2C core,
something like:

  - i2c-bus
	For I2C adapters that have child nodes that are a mixture of both I2C
	devices and non-I2C devices (such as a pin controller), the 'i2c-bus'
	subnode can be used for populating I2C devices. If an 'i2c-bus'
	subnode is present, only subnodes of this will be considered as
	I2C slaves.

How are #address-cells and #size-cells handled in this case? I assume
that they should live under the i2c-bus subnode, which should be called
out.

Thanks,
Mark.
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Thierry Reding June 17, 2016, 4:45 p.m. UTC | #3
On Fri, Jun 17, 2016 at 05:30:54PM +0100, Mark Rutland wrote:
> On Fri, Jun 17, 2016 at 01:03:41PM +0100, Jon Hunter wrote:
> > The I2C driver core for boards using device-tree assumes any subnode of
> > an I2C adapter in the device-tree blob as being a I2C slave device.
> > Although this makes complete sense, some I2C adapters may have subnodes
> > which are not I2C slaves but subnodes presenting other features. For
> > example some Tegra devices have an I2C interface which may share its
> > pins with other devices and to share these pins subnodes for
> > representing these pins so they have be shared via the pinctrl framework
> > are needed.
> > 
> > To allow I2C adapters to have non-I2C specific subnodes in device-tree
> > that are not parsed by the I2C driver core by adding support for a
> > 'i2c-bus' subnode where I2C slaves can be placed. If the 'i2c-bus'
> > subnode is present then all I2C slaves must be placed under this subnode.
> > 
> > Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
> > ---
> >  Documentation/devicetree/bindings/i2c/i2c.txt | 8 ++++++++
> >  1 file changed, 8 insertions(+)
> > 
> > diff --git a/Documentation/devicetree/bindings/i2c/i2c.txt b/Documentation/devicetree/bindings/i2c/i2c.txt
> > index f31b2ad1552b..ed56b08c7e6e 100644
> > --- a/Documentation/devicetree/bindings/i2c/i2c.txt
> > +++ b/Documentation/devicetree/bindings/i2c/i2c.txt
> > @@ -32,6 +32,14 @@ wants to support one of the below features, it should adapt the bindings below.
> >  - clock-frequency
> >  	frequency of bus clock in Hz.
> >  
> > +- i2c-bus
> > +	For I2C adapters that have child nodes that are a mixture of both I2C
> > +	devices and non-I2C devices (such as a pin controller), the 'i2c-bus'
> > +	subnode can be used for populating I2C devices to prevent the I2C core
> > +	from attempting to add any non-i2c nodes as I2C devices. If 'i2c-bus'
> > +	subnode is present then all I2C slaves must be added under this
> > +	subnode.
> 
> The general idea seems sound.
> 
> It would be good if we could remove the mention of the I2C core,
> something like:
> 
>   - i2c-bus
> 	For I2C adapters that have child nodes that are a mixture of both I2C
> 	devices and non-I2C devices (such as a pin controller), the 'i2c-bus'
> 	subnode can be used for populating I2C devices. If an 'i2c-bus'
> 	subnode is present, only subnodes of this will be considered as
> 	I2C slaves.
> 
> How are #address-cells and #size-cells handled in this case? I assume
> that they should live under the i2c-bus subnode, which should be called
> out.

Good catch. Yes, I think the i2c-bus subnode would be the right place
for #address-cells and #size-cells.

Thierry
Jon Hunter June 20, 2016, 11:15 a.m. UTC | #4
On 17/06/16 17:45, Thierry Reding wrote:
> * PGP Signed by an unknown key
> 
> On Fri, Jun 17, 2016 at 05:30:54PM +0100, Mark Rutland wrote:
>> On Fri, Jun 17, 2016 at 01:03:41PM +0100, Jon Hunter wrote:
>>> The I2C driver core for boards using device-tree assumes any subnode of
>>> an I2C adapter in the device-tree blob as being a I2C slave device.
>>> Although this makes complete sense, some I2C adapters may have subnodes
>>> which are not I2C slaves but subnodes presenting other features. For
>>> example some Tegra devices have an I2C interface which may share its
>>> pins with other devices and to share these pins subnodes for
>>> representing these pins so they have be shared via the pinctrl framework
>>> are needed.
>>>
>>> To allow I2C adapters to have non-I2C specific subnodes in device-tree
>>> that are not parsed by the I2C driver core by adding support for a
>>> 'i2c-bus' subnode where I2C slaves can be placed. If the 'i2c-bus'
>>> subnode is present then all I2C slaves must be placed under this subnode.
>>>
>>> Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
>>> ---
>>>  Documentation/devicetree/bindings/i2c/i2c.txt | 8 ++++++++
>>>  1 file changed, 8 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/i2c/i2c.txt b/Documentation/devicetree/bindings/i2c/i2c.txt
>>> index f31b2ad1552b..ed56b08c7e6e 100644
>>> --- a/Documentation/devicetree/bindings/i2c/i2c.txt
>>> +++ b/Documentation/devicetree/bindings/i2c/i2c.txt
>>> @@ -32,6 +32,14 @@ wants to support one of the below features, it should adapt the bindings below.
>>>  - clock-frequency
>>>  	frequency of bus clock in Hz.
>>>  
>>> +- i2c-bus
>>> +	For I2C adapters that have child nodes that are a mixture of both I2C
>>> +	devices and non-I2C devices (such as a pin controller), the 'i2c-bus'
>>> +	subnode can be used for populating I2C devices to prevent the I2C core
>>> +	from attempting to add any non-i2c nodes as I2C devices. If 'i2c-bus'
>>> +	subnode is present then all I2C slaves must be added under this
>>> +	subnode.
>>
>> The general idea seems sound.
>>
>> It would be good if we could remove the mention of the I2C core,
>> something like:
>>
>>   - i2c-bus
>> 	For I2C adapters that have child nodes that are a mixture of both I2C
>> 	devices and non-I2C devices (such as a pin controller), the 'i2c-bus'
>> 	subnode can be used for populating I2C devices. If an 'i2c-bus'
>> 	subnode is present, only subnodes of this will be considered as
>> 	I2C slaves.
>>
>> How are #address-cells and #size-cells handled in this case? I assume
>> that they should live under the i2c-bus subnode, which should be called
>> out.
> 
> Good catch. Yes, I think the i2c-bus subnode would be the right place
> for #address-cells and #size-cells.

Yes, indeed. Thanks. Will fix.

Cheers
Jon
diff mbox

Patch

diff --git a/Documentation/devicetree/bindings/i2c/i2c.txt b/Documentation/devicetree/bindings/i2c/i2c.txt
index f31b2ad1552b..ed56b08c7e6e 100644
--- a/Documentation/devicetree/bindings/i2c/i2c.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c.txt
@@ -32,6 +32,14 @@  wants to support one of the below features, it should adapt the bindings below.
 - clock-frequency
 	frequency of bus clock in Hz.
 
+- i2c-bus
+	For I2C adapters that have child nodes that are a mixture of both I2C
+	devices and non-I2C devices (such as a pin controller), the 'i2c-bus'
+	subnode can be used for populating I2C devices to prevent the I2C core
+	from attempting to add any non-i2c nodes as I2C devices. If 'i2c-bus'
+	subnode is present then all I2C slaves must be added under this
+	subnode.
+
 - i2c-scl-falling-time-ns
 	Number of nanoseconds the SCL signal takes to fall; t(f) in the I2C
 	specification.