Re: [RFC PATCH 1/5] Documentation: dt-bindings: add documentation on new DT binding format
On Tue, Sep 01, 2015 at 09:59:14AM -0700, Tim Bird wrote: > On Thu, Aug 27, 2015 at 10:23 PM, Matt Porter wrote: > > Documentation explaining the syntax and format of the YAML-based DT binding > > documentation. > > > > Signed-off-by: Matt Porter > > --- > > .../devicetree/bindings/dt-binding-format.txt | 106 > > + > > 1 file changed, 106 insertions(+) > > create mode 100644 Documentation/devicetree/bindings/dt-binding-format.txt > > > > diff --git a/Documentation/devicetree/bindings/dt-binding-format.txt > > b/Documentation/devicetree/bindings/dt-binding-format.txt > > new file mode 100644 > > index 000..f9acc22 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/dt-binding-format.txt > > @@ -0,0 +1,106 @@ > > +-- > > +Device Tree Binding Format > > +-- > > + > > +Background > > +-- > > + > > +DT bindings historically were written as text in prose format which > > +led to issues in usability of that source documentation. Some of > > +these issues include the need to programmatically process binding > > +source documentation to do DTS validation, perform mass updates to > > +format/style, and to generate publishable documentation in HTML or > > +PDF form. > > + > > +Overview > > + > > + > > +The DT binding format is based on the YAML text markup language. > > +Although there are many text markup options available, YAML > > +fulfills all requirements considered for a DT binding source format > > +which include: > > + > > +1) Must be human readable > > +2) Must be easily translated to other data formats (XML, JSON, etc). > > +3) Must have sufficient tools and libraries to enable developers to > > + build new tools for DT binding processing > > +4) Must have a complete spec to refer to syntax > > + > > +YAML is documentated in the specification found at > > +http://www.yaml.org/spec/1.2/spec.html > > + > > +The required YAML DT binding tag format and syntax are defined in > > +the following sections. > > + > > +YAML DT Binding Syntax > > +-- > > + > > +* Lines starting with "#" are comments and not part of the binding itself > > +* "%YAML 1.2" starts a file, indicating the version of YAML in use > > I think it would be good to specify a DT Binding Format version as well. > I would expect we may expand the syntax, or we may alter it, so it > would be good to have a number for our specific syntax. This would > help in some circumstances, if we make multiple passes over the > documents to achieve our conversion. Maybe this should be added > below. Added this in v2, thanks. > > > +* "---" starts a binding document > > +* "..." ends a binding document > > +* Multiple binding documents may exist in a single file > > +* Tabs are not permitted > > +* Scope is denoted by indentation of two spaces > > +* Key value pairs are denoted by "key: value" > > +* Sequences are denoted by "- " > > +* Scalar values may convert newlines to spaces and preserve blank > > + lines for long description formatting using ">" > > +* Scalar values may escape all reserved characters and preserve > > + newlines by using "|" to denote literal style > > + > > +For additional information on YAML syntax, refer to the specification > > +at http://www.yaml.org/spec/1.2/spec.html > > + > > +YAML DT Binding Format > > +-- > > + > > +The following YAML types are supported in the DT binding format: > > + > > Based on my comment above, I recommend: > [R] binding-format: 1 > > > +* [R] id: unique identifier in property form (e.g. skel-device) > > + > > +* [R] title: title of the binding > > + > > +* [O] maintainer: sequence of maintainers > > + [R] name: name and email of maintainer or mailing list in RFC822 > > +form. > > + > > +* [O] description: full description of the binding > > + > > +* [O] compatible: sequence of valid compatible descriptors > > + [R] name: the compatible string surrounded in double quotes > > + [O] deprecated: a deprecated compatible string surrounded in > > + double quotes > > + [O] description: description of the compatible string > > compatible is a property like all the others, and I think it's confusing > to have it in a separate secti
Re: [RFC PATCH 2/5] Documentation: dt-bindings: add example DT binding document
On Thu, Sep 10, 2015 at 05:08:50PM +1000, David Gibson wrote:
> On Fri, Aug 28, 2015 at 09:53:06AM -0500, Rob Herring wrote:
> > On Fri, Aug 28, 2015 at 12:23 AM, Matt Porter wrote:
> > > Add a skeleton DT binding document that serves as the canonical
> > > example for implementing YAML-based DT bindings documentation.
> > > The skeleton binding illustrates use of all fields and variations
> > > described in the dt-binding-format.txt documentation.
> > >
> > > Signed-off-by: Matt Porter
> > > ---
> > > Documentation/devicetree/bindings/skeleton.yaml | 98
> > > +
> > > 1 file changed, 98 insertions(+)
> > > create mode 100644 Documentation/devicetree/bindings/skeleton.yaml
> > >
> > > diff --git a/Documentation/devicetree/bindings/skeleton.yaml
> > > b/Documentation/devicetree/bindings/skeleton.yaml
> > > new file mode 100644
> > > index 000..175965f
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/skeleton.yaml
> > > @@ -0,0 +1,98 @@
> > > +%YAML 1.2
> > > +---
> > > +id: skel-device
> > > +
> > > +title: Skeleton Device
> > > +
> > > +maintainer:
> > > + - name: Skeleton Person
> >
> > We'd want to tie this into get_maintainers.pl obviously.
> >
> > > +
> > > +description: >
> > > + The Skeleton Device binding represents the SK11 device produced by
> > > + the Skeleton Corporation. The binding can also support compatible
> > > + clones made by second source vendors.
> > > +
> > > +compatible:
> > > + - name: "skel,sk11"
> > > + - name: "faux,fx11"
> >
> > Is this an OR or AND? We need both.
>
> Hrm. So, from the example below it's an OR. But.. I think the
> considerations here change when you separate out "tag" information as
> I've suggested elsewhere.
>
> The command AND case, I can think of is where you want both
> "foo,new-model-device" and "foo,old-model-device". I think the first
> belongs in the "tag", but the second in the body of the requirements.
>
> The OR case demonstrated here strikes me as very poor binding design -
> but that doesn't mean we can totally avoid it, since we do have poor
> bindings we want to convert.
>
> Fwiw, I think the right way to encode "OR" at least in the "tag" is to
> pick just the preferred form, then have additional bindings tagged on
> the alternative forms and inheriting the main binding. I don't know
> if that's practical in the short term though.
I reworked this as a constraint key with C-like syntax to express
allowable compatible strings. It's got some warts but let's take
a look at v2 and see if good constraint syntax can handle all these
cases. I use some macro like constructs to denote a generic compatible
string that must be included in addition to the part-specific string.
>
> > The complicated case is "one of {specific names} followed by {generic
> > name}."
> >
> > > +description: A clone of the original sk11 device
> > > +
> > > +required:
> > > + - name: "reg"
> >
> > We definitely need type info from the start.
>
> It's interesting you should mention that here, because 'reg' is
> actually a hard case for describint the type: because it's format is
> determined as much by the parent bus binding as this node's binding.
>
> I suspect it will be worth special-casing "reg" in order to make
> common bindings more compact, but again, probably not in the first
> pass.
I've added type in v2 and in comments note the "reg" is indeed a
special case and derived not so much from the inherited binding but
from the actual parent node as used in an implementation.
>
> > > +description: chip select address of skeleton device
> > > +reference: spi-slave
> >
> > I would like to not have to list properties if the inherited binding
> > lists it. The problem is we need to say how many cells and the order
> > (not a problem here, but for mmio devices).
> >
> > Perhaps we can list the reference at the top level for the node
> > instead of for every property.
>
> Yeah, I think it would be worth having a top-level "inherits" field.
Added in v2
> > > + - name: "spi-max-frequency"
> > > +description: >
> > > + Maximum SPI clocking speed of skeleton device in Hz, m
[RFC PATCH v2 2/3] Documentation: dt-bindings: spi: add generic YAML SPI slave binding
Convert the SPI slave portion of the spi-bus.txt binding to the
standard YAML DT binding format.
Signed-off-by: Matt Porter
---
.../devicetree/bindings/spi/spi-slave.yaml | 108 +
1 file changed, 108 insertions(+)
create mode 100644 Documentation/devicetree/bindings/spi/spi-slave.yaml
diff --git a/Documentation/devicetree/bindings/spi/spi-slave.yaml
b/Documentation/devicetree/bindings/spi/spi-slave.yaml
new file mode 100644
index 000..8447bb9
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/spi-slave.yaml
@@ -0,0 +1,108 @@
+%YAML 1.2
+---
+version: 1
+
+id: spi-slave
+
+title: SPI Slave Devices
+
+maintainer:
+- name: Mark Brown
+
+description: >
+SPI (Serial Peripheral Interface) slave bus devices are children of
+of a SPI master bus device.
+properties:
+- name: "reg"
+category: required
+type: int
+description: chip select address of device
+
+- name: "compatible"
+category: required
+type: string
+description: compatible strings
+
+- name: "spi-max-frequency"
+category: required
+type: int
+description: Maximum SPI clocking speed of device in Hz
+
+- name: "spi-cpol"
+category: optional
+type: empty
+description: >
+Empty property indicating device requires
+inverse clock polarity (CPOL) mode
+
+- name: "spi-cpha"
+category: optional
+type: empty
+description: >
+Empty property indicating device requires
+shifted clock phase (CPHA) mode
+
+- name: "spi-cs-high"
+category: optional
+type: empty
+description: >
+Empty property indicating device requires
+chip select active high
+
+- name: "spi-3wire"
+category: optional
+type: empty
+description: >
+Empty property indicating device requires
+3-wire mode.
+
+- name: "spi-lsb-first"
+category: optional
+type: empty
+description: >
+Empty property indicating device requires
+LSB first mode.
+
+- name: "spi-tx-bus-width"
+category: optional
+type: int
+constraint: 1 || 2 || 4
+description: >
+The bus width(number of data wires) that
+used for MOSI. Defaults to 1 if not present.
+
+- name: "spi-rx-bus-width"
+category: optional
+type: int
+constraint: 1 || 2 || 4
+description: >
+The bus width(number of data wires) that
+used for MISO. Defaults to 1 if not present.
+
+notes: >
+Some SPI controllers and devices support Dual and Quad SPI transfer mode.
+It allows data in the SPI system to be transferred in 2 wires(DUAL) or
+4 wires(QUAD).
+Now the value that spi-tx-bus-width and spi-rx-bus-width can receive is
+only 1(SINGLE), 2(DUAL) and 4(QUAD). Dual/Quad mode is not allowed when
+3-wire mode is used.
+If a gpio chipselect is used for the SPI slave the gpio number will be
+passed via the SPI master node cs-gpios property.
+
+examples:
+- dts: |
+spi@f00 {
+...
+ethernet-switch@0 {
+compatible = "micrel,ks8995m";
+spi-max-frequency = <100>;
+reg = <0>;
+};
+
+codec@1 {
+compatible = "ti,tlv320aic26";
+spi-max-frequency = <10>;
+reg = <1>;
+};
+};
+...
--
2.5.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH v2 3/3] Documentation: dt-bindings: add example DT binding document
Add a skeleton DT binding document that serves as the canonical
example for implementing YAML-based DT bindings documentation.
The skeleton binding illustrates use of all fields and variations
described in the dt-binding-format.txt documentation.
Signed-off-by: Matt Porter
---
Documentation/devicetree/bindings/skeleton.yaml | 138
1 file changed, 138 insertions(+)
create mode 100644 Documentation/devicetree/bindings/skeleton.yaml
diff --git a/Documentation/devicetree/bindings/skeleton.yaml
b/Documentation/devicetree/bindings/skeleton.yaml
new file mode 100644
index 000..d7a27cb
--- /dev/null
+++ b/Documentation/devicetree/bindings/skeleton.yaml
@@ -0,0 +1,138 @@
+%YAML 1.2
+---
+version: 1
+
+id: skel-device
+
+title: Skeleton Device
+
+maintainer:
+- name: Skeleton Person
+
+description: >
+The Skeleton Device binding represents the SK11 device produced by
+the Skeleton Corporation. The binding can also support compatible
+clones made by second source vendors.
+
+# This binding inherits property characteristics from the generic
+# spi-slave binding
+
+inherits:
+- id: spi-slave
+
+properties:
+
+# The compatible property is a reserved name. The type is always "string"
+# and should not be repeated device binding.
+
+- name: "compatible"
+constraint: |
+"skel,sk11" || "faux,fx11" , BASE("skel,sk11")
+description: FX11 is a clone of the original SK11 device
+
+# The reg property is a reserved name. The type is always "int" and
+# should not be repeated in a device binding. Constraints are defined
+# only in the context of the parent node's address, size, and ranges
+# cells. The description is inherited from the spi-slave binding.
+
+- name: "reg"
+
+# spi-max-frequency needs the device-specific constraint to be supplied
+
+- name: "spi-max-frequency"
+constraint: |
+if (compatible == "skel,sk11") c <= 1000 else c <= 100
+
+# This property overrides the generic binding description with
+# a device specific description in order to mention the chip's
+# h/w cfg strapping pins.
+
+- name: "spi-cs-high"
+description: >
+Set if skeleton device configuration pins are set for chip
+select polarity high
+
+# Device specific properties don't inherit characteristic from a generic
+# binding so category, type, constraint, and description must be specified
+# if needed.
+
+- name: "skel,deprecated1"
+category: deprecated
+type: int
+constraint: |
+(c >= 10) && (c <= 20)
+description: >
+First of two deprecated properties.
+
+# There are no constraints for properties of empty type
+
+- name: "skel,deprecated2"
+category: deprecated
+type: empty
+description: >
+Second of two deprecated properties.
+
+# This example could be auto-generated rather than explicitly included
+# in the yaml source.
+
+example:
+- dts: |
+sk11@0 {
+compatible = "skel,sk11";
+reg = <0>;
+spi-max-frequency = <100>;
+spi-cs-high;
+};
+...
+
+---
+version: 1
+
+id: skel-mini
+
+title: Skeleton Mini Device
+
+maintainer:
+- name: Rogue Developer
+
+description: >
+The Skeleton Mini Device binding represents the SK47x series devices
+produced by the Skeleton Corporation.
+
+properties:
+- name: "compatible"
+category: required
+constraint: |
+"skel,sk472" || skel,sk473" || "skel,sk474" , BASE("skel,sk472")
+deprecated: "skel,sk47x"
+description: >
+SK472 is the original part in the family. SK473/4 are later
releases
+with minor register changes.
+
+- name: "reg"
+category: required
+description: Address and size of Skeleton Mini register range.
+
+- name: "skel,sync-mode"
+category: optional
+type: empty
+description: Enable synchronous transfer mode
+
+example:
+- dts: |
+sk472@beef {
+compatible = "skel,sk472";
+reg = <0xbeef 0x100>;
+};
+description: >
+Demonstrates an SK472 in normal mode.
+
+- dts: |
+sk474@dead {
+compatible = "skel,sk474", "skel,sk472";
+reg = <0xdead 0x100>;
+skel,sync-mode;
+};
+description: >
+Demonstrates an SK474 in synchronous mode.
+...
--
2.5.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH v2 1/3] Documentation: dt-bindings: add documentation on new DT binding format
Documentation explaining the syntax and format of the YAML-based DT binding
documentation.
Signed-off-by: Matt Porter
---
.../devicetree/bindings/dt-binding-format.txt | 105 +
1 file changed, 105 insertions(+)
create mode 100644 Documentation/devicetree/bindings/dt-binding-format.txt
diff --git a/Documentation/devicetree/bindings/dt-binding-format.txt
b/Documentation/devicetree/bindings/dt-binding-format.txt
new file mode 100644
index 000..3763487
--- /dev/null
+++ b/Documentation/devicetree/bindings/dt-binding-format.txt
@@ -0,0 +1,105 @@
+--
+Device Tree Binding Format
+--
+
+Background
+--
+
+DT bindings historically were written as text in prose format which
+led to issues in usability of that source documentation. Some of
+these issues include the need to programmatically process binding
+source documentation to do DTS validation, perform mass updates to
+format/style, and to generate publishable documentation in HTML or
+PDF form.
+
+Overview
+
+
+The DT binding format is based on the YAML text markup language.
+Although there are many text markup options available, YAML
+fulfills all requirements considered for a DT binding source format
+which include:
+
+1) Must be human readable
+2) Must be easily translated to other data formats (XML, JSON, etc).
+3) Must have sufficient tools and libraries to enable developers to
+ build new tools for DT binding processing
+4) Must have a complete spec to refer to syntax
+
+YAML is documentated in the specification found at
+http://www.yaml.org/spec/1.2/spec.html
+
+The required YAML DT binding tag format and syntax are defined in
+the following sections.
+
+YAML DT Binding Syntax
+--
+
+* Lines starting with "#" are comments and not part of the binding itself
+* "%YAML 1.2" starts a file, indicating the version of YAML in use
+* "---" starts a binding document
+* "..." ends a binding document
+* Multiple binding documents may exist in a single file
+* Tabs are not permitted
+* Scope is denoted by indentation of four spaces
+* Key value pairs are denoted by "key: value"
+* Sequences are denoted by "-"
+* Scalar values may convert newlines to spaces and preserve blank
+ lines for long description formatting using ">"
+* Scalar values may escape all reserved characters and preserve
+ newlines by using "|" to denote literal style
+
+For additional information on YAML syntax, refer to the specification
+at http://www.yaml.org/spec/1.2/spec.html
+
+YAML DT Binding Format
+--
+
+The DT binding format is based on the YAML Core schema defined in the
+specification. The following YAML sequences and keys are supported in
+the DT binding format:
+
+[Note: [R] and [O] denote required and optional sequences/keys,respectively]
+
+* [R] version: DT binding format version. Currently 1.
+
+* [R] id: unique identifier in property form (e.g. skel-device)
+
+* [R] title: title of the binding
+
+* [R] maintainer: sequence of maintainers
+ [R] name: name and email of maintainer or mailing list in RFC822
+form.
+
+* [O] description: full description of the binding
+
+* [O] inherits: sequence of inherited bindings
+ [R] id: unique identifier of inherited binding
+
+* [R] properties: sequence of properties
+ [R] name: name of property surrounded in double quotes
+ [R} category: category of property. One of "required",
+"optional", or "deprecated".
+ [R] type: type of property. One of "string", "int", "empty",
+"phandle", or "array".
+ [O] constraint: constraint expression using C syntax
+ [O] deprecated: C syntax expression of deprecated compatible
+ strings.
+ [O] description: description of the property
+
+* [O] notes: Any additional notes about properties in this binding.
+
+* [O] example: sequence of examples:
+ [R] dts: DT source of example usage. The example text must use
+ literal style ("|") so that it retains indentation and
+ newlines.
+ [O] description: description of the example
+
+Skeleton Binding
+
+
+The skeleton.yaml binding found in the top of the DT binding tree
+is the canonical example of syntax and format to use when writing
+a DT binding document. It is maintained with the latest formatting
+conventions, making it the best starting point when writing a new DT
+binding.
--
2.5.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH v2 0/3] DT binding documents using text markup
Changes since v1: * Add dt binding format version * Treat compatible strings as another property * Required, optional, deprecated now a property field * Add property type field * Add property constraint field using C syntax for constraints * Move binding references to a top level inherits sequence * Dropped eeprom and phy examples. Example bindings are now only the spi-slave binding and the skeleton device binding which inherits the spi-slave binding. * Added notes field to capture any notes on properties * Update DT format docs to match new format. * Add language about use of YAML core binding * Refer to defined YAML sequences/keys consistently as such, remove all vague reference to types and tags. TODO: * reach agreement on format of sequences/keys * need a flexible constraint syntax. this is only described in examples but needs a specific description in the format document. * determine if compatibles can be handled generically in the property sequence or are better handled in their own specific compatible sequence * compatibles as properties have the ugliness of how to handle deprecated strings, for now this is a "deprecated" key that contains a C-syntax expression of all deprecated strings. * simple binding doc validator * simple checkpatch.pl dts compatible string validator against yaml binding doc compatible property constraints * update dtdocgen.py to process inherited bindings and current sequence/key format. --- During the Device Tree microconference at Linux Plumbers 2015, we had a short discussion about how to improve DT Binding Documentation. A number of issues were raised (again, as these things have been discussed in the past) including: * Inconsistency between binding documents due to prose text format. * Inability to reliably machine read bindings for mass update or search. * Bit rot of bindings as new conventions are agreed upon but only new bindings are changed. When the topic of needing the bindings in a rigid format was raised, there was general head nodding that this was needed. It was noted that this has been discussed many times before and nothing has been done. My proposed solution to the problem is to convert all DT bindings a rigid text markup format. In choosing a text markup language my requirements were: 1) Human readable 2) Well documented 3) Easy to translate to other data formats 4) Well supported by tools and libraries After looking at a number of markup options, YAML stood out as the one that meets all of these requirements. The YAML syntax is adopted in many projects specifically because of the high level of readability. A comprehensive spec is at http://www.yaml.org/spec/1.2/spec.html. There's a number of tools to convert between YAML and other popular data formats such as JSON and XML. XML was cited by Behan Webster during the microconference as an important data format as the type of developers that may produce comprehensive DTS Binding validation tools will want to use XML. Every major scripting language has a high level binding to the low level libyaml C library to facilitate handling of YAML data files. This series is broken up into three parts: 1) The documentation defining the YAML DT binding format 2) A conversion of the generic SPI slave binding 2) A skeleton device binding example illustrating use of this format and inheriting the generic SPI slave binding properties. As a proof of concept of what can be done with a proper machine readable DT binding source file, there's a simple markdown document generator at https://github.com/konsulko/dtgendoc. Also, to see actual output from the generator, the generated markdown from those bindings is viewable at https://github.com/konsulko/dtgendoc/wiki (Note: this is not updated yet for v2, see TODO list) There's a lot of other possibilities for validation tools using only the data we have today in the bindings. In addition, Frank Rowand covered some DT debug techniques that would benefit from the binding documentation being 100% reliably searchable. -Matt Matt Porter (3): Documentation: dt-bindings: add documentation on new DT binding format Documentation: dt-bindings: spi: add generic YAML SPI slave binding Documentation: dt-bindings: add example DT binding document .../devicetree/bindings/dt-binding-format.txt | 105 Documentation/devicetree/bindings/skeleton.yaml| 138 + .../devicetree/bindings/spi/spi-slave.yaml | 108 3 files changed, 351 insertions(+) create mode 100644
Re: [RFC PATCH 1/5] Documentation: dt-bindings: add documentation on new DT binding format
On Sun, Aug 30, 2015 at 03:04:33PM -0700, Frank Rowand wrote: > On 8/27/2015 10:23 PM, Matt Porter wrote: > > Documentation explaining the syntax and format of the YAML-based DT binding > > documentation. > > > > Signed-off-by: Matt Porter > > --- > > .../devicetree/bindings/dt-binding-format.txt | 106 > > + > > 1 file changed, 106 insertions(+) > > create mode 100644 Documentation/devicetree/bindings/dt-binding-format.txt > > > > diff --git a/Documentation/devicetree/bindings/dt-binding-format.txt > > b/Documentation/devicetree/bindings/dt-binding-format.txt > > new file mode 100644 > > index 000..f9acc22 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/dt-binding-format.txt > > @@ -0,0 +1,106 @@ > > +-- > > +Device Tree Binding Format > > +-- > > + > > +Background > > +-- > > + > > +DT bindings historically were written as text in prose format which > > +led to issues in usability of that source documentation. Some of > > +these issues include the need to programmatically process binding > > +source documentation to do DTS validation, perform mass updates to > > +format/style, and to generate publishable documentation in HTML or > > +PDF form. > > + > > +Overview > > + > > + > > +The DT binding format is based on the YAML text markup language. > > +Although there are many text markup options available, YAML > > +fulfills all requirements considered for a DT binding source format > > +which include: > > + > > +1) Must be human readable > > +2) Must be easily translated to other data formats (XML, JSON, etc). > > +3) Must have sufficient tools and libraries to enable developers to > > + build new tools for DT binding processing > > +4) Must have a complete spec to refer to syntax > > + > > +YAML is documentated in the specification found at > > +http://www.yaml.org/spec/1.2/spec.html > > + > > +The required YAML DT binding tag format and syntax are defined in > > +the following sections. > > + > > +YAML DT Binding Syntax > > +-- > > + > > +* Lines starting with "#" are comments and not part of the binding itself > > +* "%YAML 1.2" starts a file, indicating the version of YAML in use > > +* "---" starts a binding document > > +* "..." ends a binding document > > +* Multiple binding documents may exist in a single file > > +* Tabs are not permitted > > +* Scope is denoted by indentation of two spaces > > +* Key value pairs are denoted by "key: value" > > +* Sequences are denoted by "- " > > +* Scalar values may convert newlines to spaces and preserve blank > > + lines for long description formatting using ">" > > +* Scalar values may escape all reserved characters and preserve > > + newlines by using "|" to denote literal style > > + > > +For additional information on YAML syntax, refer to the specification > > +at http://www.yaml.org/spec/1.2/spec.html > > + > > +YAML DT Binding Format > > +-- > > + > > +The following YAML types are supported in the DT binding format: > > + > > +* [R] id: unique identifier in property form (e.g. skel-device) > > + > > +* [R] title: title of the binding > > + > > +* [O] maintainer: sequence of maintainers > > + [R] name: name and email of maintainer or mailing list in RFC822 > > +form. > > + > > +* [O] description: full description of the binding > > + > > +* [O] compatible: sequence of valid compatible descriptors > > + [R] name: the compatible string surrounded in double quotes > > + [O] deprecated: a deprecated compatible string surrounded in > > + double quotes > > + [O] description: description of the compatible string > > + > > +* [O] required: sequence of required properties: > > + [R] name: name of the property surrounded in double quotes > > + [R] description: description of the property > > + [O] reference: optional reference to a binding id > > + > > +* [O] optional: sequence of optional properties: > > + [R] name: name of the property surrounded in double quotes > > + [R] description: description of the property > > + [O] reference: optional reference to a binding id > > + > > +* [O] deprecated: sequence of deprecated properties:
Re: [RFC PATCH 2/5] Documentation: dt-bindings: add example DT binding document
On Wed, Sep 02, 2015 at 10:45:13AM +0200, Nicolas Ferre wrote:
> Le 01/09/2015 19:35, Tim Bird a écrit :
> > On Fri, Aug 28, 2015 at 7:53 AM, Rob Herring wrote:
> >> On Fri, Aug 28, 2015 at 12:23 AM, Matt Porter wrote:
> > ...
> >>> +example:
> >>> + - dts: |
> >>> + sk11@0 {
> >>> + compatible = "skel,sk11";
> >>> + reg = <0>;
> >>> + spi-max-frequency = <100>;
> >>> + spi-cs-high;
> >>> + };
> >>
> >> At least in this example, we could generate it. Examples are nice, but
> >> we have dts files full of examples already. I get a fair number of
> >> "fix the example" patches, so maybe we should eliminate the simple
> >> ones.
> >
> > I would hesitate to eliminate examples. I've been saved by them on
> > a few occasions, when the dts files only had one or two instances
> > of a type of binding, somewhat different from each other, and the example
> > helped
> > break the tie. If there's something wrong with the example, it's a sign
> > of an out-of-date binding doc, just as much as if the text were wrong.
> > It ought to be possible to validate the example versus the binding doc
> > (as Pantelis says), so ultimately we should be able to catch errors here
> > as well.
>
> I back Tim's advice.
> Example are so important that I regularly find myself thinking "ah-ha,
> okay that's supposed to work like that" after having read the binding
> documentation.
See my comments on Tim's post. In summary, we'd retain the complex type
examples but allow the trivial ones to not bother with it in explicit
source. OTOH, this would have to be a final change in the conversion
process, most likely, because we need all the type: and constraints:
tags present in order to generate a working example.
Of course, that's the same info necessary to validate a dts as well.
Perhaps it's best to look at this as the automated conversion process
that Rob suggested. That is, we'll have the current text (including
all examples) brought into the .yaml file as comments. So we aren't
eliminating examples. Later, if those examples are too trivial to
bother capturing as above, we simply remove and one can dump an example
via a doc generator not unlike my markdown example (which can spit out
pasteable text).
-Matt
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 2/5] Documentation: dt-bindings: add example DT binding document
On Tue, Sep 01, 2015 at 10:35:44AM -0700, Tim Bird wrote:
> On Fri, Aug 28, 2015 at 7:53 AM, Rob Herring wrote:
> > On Fri, Aug 28, 2015 at 12:23 AM, Matt Porter wrote:
> ...
> >> +example:
> >> + - dts: |
> >> + sk11@0 {
> >> + compatible = "skel,sk11";
> >> + reg = <0>;
> >> + spi-max-frequency = <100>;
> >> + spi-cs-high;
> >> + };
> >
> > At least in this example, we could generate it. Examples are nice, but
> > we have dts files full of examples already. I get a fair number of
> > "fix the example" patches, so maybe we should eliminate the simple
> > ones.
>
> I would hesitate to eliminate examples. I've been saved by them on
> a few occasions, when the dts files only had one or two instances
> of a type of binding, somewhat different from each other, and the example
> helped
> break the tie. If there's something wrong with the example, it's a sign
> of an out-of-date binding doc, just as much as if the text were wrong.
> It ought to be possible to validate the example versus the binding doc
> (as Pantelis says), so ultimately we should be able to catch errors here
> as well.
I think part of the suggestion is that we can simply generate the common
examples from the tags (as part of formatted doc generation) rather than it
being a verbatim paste from a dts file. This has the benefit of not
getting that verbatim text of of sync with a dts (because we'll
eventually validating the dts files versus the binding doc). Does that
still achieve what you want? Keep in mind that we aren't talking about
taking away the ability to put an explicit verbatim example, but rather
making it an exception case to demonstrate some variants where an author
wants to point out different common use cases.
-Matt
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 2/5] Documentation: dt-bindings: add example DT binding document
On Sun, Aug 30, 2015 at 03:18:19PM -0700, Frank Rowand wrote:
> On 8/28/2015 11:55 AM, Rob Herring wrote:
> > On Fri, Aug 28, 2015 at 12:49 PM, Matt Porter wrote:
> >> On Fri, Aug 28, 2015 at 09:53:06AM -0500, Rob Herring wrote:
> >>> On Fri, Aug 28, 2015 at 12:23 AM, Matt Porter
> >>> wrote:
> >>>> Add a skeleton DT binding document that serves as the canonical
> >>>> example for implementing YAML-based DT bindings documentation.
> >>>> The skeleton binding illustrates use of all fields and variations
> >>>> described in the dt-binding-format.txt documentation.
> >>>>
> >>>> Signed-off-by: Matt Porter
> >>>> ---
> >>>> Documentation/devicetree/bindings/skeleton.yaml | 98
> >>>> +
> >>>> 1 file changed, 98 insertions(+)
> >>>> create mode 100644 Documentation/devicetree/bindings/skeleton.yaml
> >>>>
> >>>> diff --git a/Documentation/devicetree/bindings/skeleton.yaml
> >>>> b/Documentation/devicetree/bindings/skeleton.yaml
> >>>> new file mode 100644
> >>>> index 000..175965f
> >>>> --- /dev/null
> >>>> +++ b/Documentation/devicetree/bindings/skeleton.yaml
> >>>> @@ -0,0 +1,98 @@
> >>>> +%YAML 1.2
> >>>> +---
> >>>> +id: skel-device
> >>>> +
> >>>> +title: Skeleton Device
> >>>> +
> >>>> +maintainer:
> >>>> + - name: Skeleton Person
> >>>
> >>> We'd want to tie this into get_maintainers.pl obviously.
> >>
> >> Right, I broke my rule of "no new tags for content we don't already
> >> have" by adding this. It stems out of the discussion at LPC where
> >> Mark suggested we could avoid the core bindings being moved by adding
> >> maintainer info into the binding itself.
> >
> > If you stated that rule, I missed it...
> >
> >> This is an area where more docs are needed. Ideally, on the first pass
> >> conversion we would not attempt to populate these. I had considered
> >> that we *could* only add maintainer: tags on core bindings to and
> >> adjust get_maintainers.pl to use that info to override the standard
> >> directory-based info if it exists. I don't think it's necessary to add
> >> a specific maintainer for all of the peripheral bindings if the default
> >> is the subsystem maintainer and the dt list. We could at least start
> >> directing core binding discussion to the -spec list which is where I
> >> think you'd like it.
>
> I think that adding the maintainer: tags for core bindings in the conversion
> process (and optionally add the tag for other bindings in the person
> converting has the driver and subsystem knowledge to intelligently
> do so -- not just a blind list from get_maintainer) would be a valid
> exception to your desire to not add new information on the conversion
> step. As much as other uses of information from bindings is near and
> dear to me, I think that throttling the binding review fire hose is
> the highest priority use of additional information.
Ok, and the other suggestion is to just populate it with the original
author so that's straightforward enough to do.
>
>
> > Yes, certainly this can solve my problem around handling core bindings.
> >
> > Some subsystem maintainers require a driver have a maintainer. We
> > could certainly enforce that too. We could probably automatically
> > populate this with the original author as a starting point. OTOH,
> > bindings should not change frequently.
> >
> >>
> >>>> +
> >>>> +description: >
> >>>> + The Skeleton Device binding represents the SK11 device produced by
> >>>> + the Skeleton Corporation. The binding can also support compatible
> >>>> + clones made by second source vendors.
> >>>> +
> >>>> +compatible:
> >>>> + - name: "skel,sk11"
> >>>> + - name: "faux,fx11"
> >>>
> >>> Is this an OR or AND? We need both.
> >>
> >> True, this only covers the OR case atm.
> >>
> >>> The complicated case is "one of {specific names} followed by {generic
> >>> name}."
> >>
> >> I need to rethink these. I do have deprecated: tag for that case and
> >> possibly "name:" gets split to "generi
Re: [RFC PATCH 0/5] DT binding documents using text markup
On Tue, Sep 01, 2015 at 01:24:17PM -0500, Rob Herring wrote: > On Tue, Sep 1, 2015 at 1:03 PM, Tim Bird wrote: > > On Tue, Sep 1, 2015 at 10:35 AM, Frank Rowand > > wrote: > >> On 9/1/2015 10:14 AM, Tim Bird wrote: > >>> On Fri, Aug 28, 2015 at 10:13 AM, Matt Porter > >>> wrote: > >> > >> < snip > > >> > >>>> > >>>> But to answer your question, if we get a format I'll do > >>>> conversions and hope I'm not alone. > >>> > >>> I'm sure others will help out. I will, and I'm pretty sure we can get > >>> some conversion sprints set up at conferences (I know I can set aside > >>> some time or resources at ELC in the spring - it might be too late for > >>> ELCE in October to set up a scheduled block of time, but we can start > >>> getting the word out.) As I said in my other e-mail, one doesn't have > >>> to be a kernel coder to do this, and the conversions should be pretty > >>> straight-forward. > >>> -- Tim > >>> > >> > >> A conversion sprint at ELCE sounds like a good idea if we can find a > >> good time to schedule it. I can help, so there will be at least two > >> of us who can help people as they encounter issues. > > > > Even if we don't find a block of time, we can do something like > > announce a "contest", ask people to do something in their spare time, > > and find some way to get them a raffle ticket if they submit a patch > > with a conversion. Then hold an extra prize drawing during the > > closing session, with just those raffle tickets, and give someone a > > nice award for contributing. Of course, there's always the adage that > > you should be careful what you measure and reward... We don't want a > > flood of crappy conversions, with a time constraint on the review. > > I'll think some more about this. An alternative would be to have a > > contest announced ahead of the event, with enough time for people to > > submit and get reviewed. > > Sounds like a review nightmare. That's another reason why as much > automated conversion we can do, the better. I don't want to discount the value of interested people getting together f2f to review these and potentially clean them up for submission. That depends on what we thinking is the minimal "in progress" conversion that can be place upstream. i.e. is it simply compatible strings autoconverted to tags and the entire current document in comments? > > By the way - I presume the new docs will replace the existing ones, > > but I could imagine wanting to have them live side-by-side > > temporarily. Any thoughts on this? Will file name or location > > changes be allowed during the conversion? > > I proposed some ideas earlier in the thread. Either we can have both > side by side or do a mass conversion to YAML making the existing doc a > comment (add # prefix). > Were you thinking that this automated conversion would be sufficient for an initial commit? I'm not sure if I misunderstood in your separate comments and was looking at this as something that would be hand edited to move the existing doc (# prefix) into description tags where appropriate. > Any renames/moving should be separate (there's some clean-up I'd like > to there as well). Exact rules depend on the approach, but we need to > be able to tell which bindings conversions are not started, in > progress, or complete. If we add .yaml in place we can identify what's in progress by the fact that a .yaml exists with the same filename and then based on which tags have been populated (such as type: and constraints: not yet populated) then we know the state. -Matt -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 0/5] DT binding documents using text markup
On Tue, Sep 01, 2015 at 11:03:50AM -0700, Tim Bird wrote: > On Tue, Sep 1, 2015 at 10:35 AM, Frank Rowand wrote: > > On 9/1/2015 10:14 AM, Tim Bird wrote: > >> On Fri, Aug 28, 2015 at 10:13 AM, Matt Porter wrote: > > > > < snip > > > > >>> > >>> But to answer your question, if we get a format I'll do > >>> conversions and hope I'm not alone. > >> > >> I'm sure others will help out. I will, and I'm pretty sure we can get > >> some conversion sprints set up at conferences (I know I can set aside > >> some time or resources at ELC in the spring - it might be too late for > >> ELCE in October to set up a scheduled block of time, but we can start > >> getting the word out.) As I said in my other e-mail, one doesn't have > >> to be a kernel coder to do this, and the conversions should be pretty > >> straight-forward. > >> -- Tim > >> > > > > A conversion sprint at ELCE sounds like a good idea if we can find a > > good time to schedule it. I can help, so there will be at least two > > of us who can help people as they encounter issues. > > Even if we don't find a block of time, we can do something like > announce a "contest", ask people to do something in their spare time, > and find some way to get them a raffle ticket if they submit a patch > with a conversion. Then hold an extra prize drawing during the > closing session, with just those raffle tickets, and give someone a > nice award for contributing. Of course, there's always the adage that > you should be careful what you measure and reward... We don't want a > flood of crappy conversions, with a time constraint on the review. > I'll think some more about this. An alternative would be to have a > contest announced ahead of the event, with enough time for people to > submit and get reviewed. > > By the way - I presume the new docs will replace the existing ones, > but I could imagine wanting to have them live side-by-side > temporarily. Any thoughts on this? Will file name or location > changes be allowed during the conversion? Good question. As a starting point I simply changed the file extension and they live in the same directory structure with the .txt versions. I can't think of an advantage to moving locations or file names initially. Certainly some file names could use improvement but changing them introduces confusion. -Matt -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 0/5] DT binding documents using text markup
On Tue, Sep 01, 2015 at 10:35:30AM -0700, Frank Rowand wrote: > On 9/1/2015 10:14 AM, Tim Bird wrote: > > On Fri, Aug 28, 2015 at 10:13 AM, Matt Porter wrote: > > < snip > > > >> > >> But to answer your question, if we get a format I'll do > >> conversions and hope I'm not alone. > > > > I'm sure others will help out. I will, and I'm pretty sure we can get > > some conversion sprints set up at conferences (I know I can set aside > > some time or resources at ELC in the spring - it might be too late for > > ELCE in October to set up a scheduled block of time, but we can start > > getting the word out.) As I said in my other e-mail, one doesn't have > > to be a kernel coder to do this, and the conversions should be pretty > > straight-forward. > > -- Tim > > > > A conversion sprint at ELCE sounds like a good idea if we can find a > good time to schedule it. I can help, so there will be at least two > of us who can help people as they encounter issues. I'll be there as well. -Matt -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 0/5] DT binding documents using text markup
On Tue, Sep 01, 2015 at 10:14:06AM -0700, Tim Bird wrote: > On Fri, Aug 28, 2015 at 10:13 AM, Matt Porter wrote: > > > Now, I would caution about trying to do too much on Day 1 or we > > could end up back at the "never doing anything" stage. > > I strongly agree with that (despite my having just sent a bunch of comments > on the binding format document). > > > It would > > be an improvement to simply check that the basic tags exist as > > shown in the [R] or [O] fields in the documentation. One thing > > I should point out is that I carefully avoided marking some tags > > as [R] where existing bindings don't have them...even if logically, > > a description should be required on every binding. The idea here > > is to avoid updating content at the same time that we are updating > > the format. > > I strongly agree with this as well. I think that the goal for the first > pass should be "no lost text". That is, if it doesn't convert into something > in the binding format, it should still be preserved somewhere, for evaluation > and formatting on a subsequent pass. > > > Rather, I think it would be better to get the base > > format updated, then come back with a janitorial team and add > > descriptions (since now we can generate a worklist of those > > bindings missing a top-level description) and systematically > > fix those and review with the appropriate maintainers. > > Agreed. It will be very useful, once we get our first pass done, to > be able to find: 1) documents not converted yet, 2) property definitions > that are missing certain fields, 3) things that could still be formatted, > from text that is remaining in the description strings or other free-form > text. > This should be easy to script. Exactly, if we were to avoid populating type: and constraints: flags then it is very easy to identify those bindings not yet converted to using those tags. > >> An example such as checking that compatible strings are documented as > >> checkpatch.pl does would be nice. Roughly, that would be just list all > >> compatible values. > > > > Ok, so my comments above were strictly about a validator for the > > binding doc submission itself. I can add an example based on your > > checkpatch.pl to adapt it to the .yaml compatible tags. > > > >> > The scope of the initial YAML DT Binding format was specifically > >> > limited to supporting *only* the content we have in bindings today. > >> > The idea here is to propose and agree on something that will take > >> > us just a few steps in the right direction. If we move *all* current > >> > binding content to a machine parseable format, additional features > >> > can be added with more automation and scripting. As it stands today, > >> > because of the inconsistency of the wording of the files, we can't > >> > add a lot of new features to the content until we convert what we > >> > have today into a standard format. > >> > > >> > With that said, it should be noted that some new features such as > >> > "type" tags to indicate cell types could be added to support > >> > additional DTS validation beyond what the current content supports. > >> > Another possibility is adding "range" type information to validate > >> > the legal values for a cell. > >> > > >> > This series is broken up into three major parts: > >> > > >> > 1) The documentation defining the YAML DT binding format > >> > 2) A skeleton device binding example illustrating use of this format > >> > 3) Some real binding conversions (eeprom.txt, phy-bindings.txt, and > >> >ti-phy.txt > >> > > >> > As a proof of concept of what can be done with a proper machine > >> > readable DT binding source file, there's a simple markdown document > >> > generator at https://github.com/konsulko/dtgendoc. Also, to see > >> > actual output from the generator, the generated markdown from those > >> > bindings is viewable at https://github.com/konsulko/dtgendoc/wiki > >> > >> Nice. > >> > >> > There's a lot of other possibilities for validation tools using > >> > only the data we have today in the bindings. In addition, Frank > >> > Rowand covered some DT debug techniques that would benefit from > >> > the binding documentation being 100% reliably searchable. > >> > > >> > I found it useful to see a side-by-side view of a conve
Re: [RFC PATCH 0/5] DT binding documents using text markup
On Mon, Aug 31, 2015 at 09:05:00AM -0500, Rob Herring wrote: > On Fri, Aug 28, 2015 at 12:13 PM, Matt Porter wrote: > > On Fri, Aug 28, 2015 at 09:26:17AM -0500, Rob Herring wrote: > >> On Fri, Aug 28, 2015 at 12:23 AM, Matt Porter wrote: > >> > During the Device Tree microconference at Linux Plumbers 2015, we had > >> > a short discussion about how to improve DT Binding Documentation. A > > [...] > > >> > One caveat with YAML is it does not tolerate tabs. Yes, I said it. > >> > No tabs! This can be managed with proper editor modes and also with > >> > helper scripts to strip tabs to aid in people passing planned > >> > checkpatch.pl checks that would run YAML DT Binding specific tag > >> > validators for new bindings. > >> > >> What do parsers do with tabs? Throw an error? > > > > Yes, they throw an error. Keep in mind that most of what I used to start > > are general purpose conversion tools on top of a particular scripting > > languages's high level binding to libyaml. The error output leaves a > > bit to be desired for our use case. In any case, when I was developing > > the skeleton.yaml I used the yaml script from > > https://github.com/ryo/yamltools to catch all these syntax errors I > > was inserting..like tabs. the PyYaml binding being used in my PoC > > dtgendoc does the same thing but I don't gracefully handle those > > errors like we could. > > > >> Beyond tabs, how do we check files can be parsed both generically and > >> for any binding specific requirements. We now need a schema for > >> checking the schema. We need some equivalent to compile testing. > > > > Right. So, I think what you are touching on is something I should > > have expanded on in the TODO list. Basically, we need a scripted > > tool that we run from checkpatch.pl that 1) reads the .yaml and > > validates the YAML itself (that comes for free in the high level > > parsers) reporting errors in a sensical manner 2) validates our > > DT binding specific tags > > We all know that no one runs checkpatch.pl. ;) I really want the basic > checking of the doc files to run from make (and run by 0-day). The > tool dependency could be an issue though. However, DocBook builds from > make and I don't think many people check that regularly. Then there is > using the binding docs to check dts files. That should probably be > part of the dtb building. Ok, makes sense. We can do that. I get this uneasy feeling about what happens to all of this *when* bindings and dts files move out of the kernel. > > Now, I would caution about trying to do too much on Day 1 or we > > could end up back at the "never doing anything" stage. > > Certainly, but I would like to have a plan for what Day 2 and 3 look like. Sure. > > > It would > > be an improvement to simply check that the basic tags exist as > > shown in the [R] or [O] fields in the documentation. One thing > > I should point out is that I carefully avoided marking some tags > > as [R] where existing bindings don't have them...even if logically, > > a description should be required on every binding. The idea here > > is to avoid updating content at the same time that we are updating > > the format. Rather, I think it would be better to get the base > > format updated, then come back with a janitorial team and add > > descriptions (since now we can generate a worklist of those > > bindings missing a top-level description) and systematically > > fix those and review with the appropriate maintainers. > > Yes. Any checking would be a great improvement. > > [...] > > >> > When we decide on a text markup format that is acceptable, then the > >> > next step is to convert all the bindings. That process would start > >> > with the complete set of generic bindings as they will be referenced > >> > by the actual device bindings. > >> > >> You are going to do that for everyone, right? ;) > > > > Let's just say that I'm banking on others helping here once we have > > a format agreed upon. If we can hold the binding doc schema definition > > initially to just define tags for content that already exists in our > > textual binding docs, the effort for conversion is tolerable. To give > > an example, that phy-bindings.txt, it took 15 minutes to convert and > > and pass through the yaml parser and dtgendoc. The reason is that it's > > pure reformatting work. It doesn't take any special knowledge of the > > hardware and it doesn't involve r
Re: [RFC PATCH 5/5] Documentation: dt-bindings: phy: add YAML TI PHY binding
On Tue, Sep 01, 2015 at 10:42:25AM -0700, Tim Bird wrote: > On Thu, Aug 27, 2015 at 10:23 PM, Matt Porter wrote: > > Convert the ti-phy.txt binding to standard YAML DT binding > > format. This binding references the YAML generic PHY binding. > > > > Signed-off-by: Matt Porter > > --- > > Documentation/devicetree/bindings/phy/ti-phy.yaml | 166 > > ++ > > 1 file changed, 166 insertions(+) > > create mode 100644 Documentation/devicetree/bindings/phy/ti-phy.yaml > > > > diff --git a/Documentation/devicetree/bindings/phy/ti-phy.yaml > > b/Documentation/devicetree/bindings/phy/ti-phy.yaml > > new file mode 100644 > > index 000..ec93501 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/phy/ti-phy.yaml > > @@ -0,0 +1,166 @@ > > +%YAML 1.2 > > +--- > > +id: omap-control-phy > > + > > +title: OMAP Control PHY > > + > > +compatible: > > + - name: "ti,control-phy-otghs" > > +description: if it has otghs_control mailbox register as on OMAP4. > > + - name: "ti,control-phy-usb2" > > +description: if it has Power down bit in control_dev_conf register > > + e.g. USB2_PHY on OMAP5. > > + - name: "ti,control-phy-pipe3" > > +description: if it has DPLL and individual Rx & Tx power control > > + e.g. USB3 PHY and SATA PHY on OMAP5. > > + - name: "ti,control-phy-pcie" > > +description: for pcie to support external clock for pcie and to > > + set PCS delay value. e.g. PCIE PHY in DRA7x > > + - name: "ti,control-phy-usb2-dra7" > > +description: if it has power down register like USB2 PHY on DRA7 > > + DRA7 platform. > > + - name: "ti,control-phy-usb2-am437" > > +description: if it has power down register like USB2 PHY on AM437 > > + platform. > > I'm confused. If these descriptions are multi-line, don't they need the '>' > syntax? Consider that a bug ;) Yes, they should have '>'. Since I'm just using the default core yaml schema validator this is perfectly legal when I run it through yaml. It would mess up formating when output to a document. > Also, I'm still confused by the "name:" field in this section. These are > possible *values* for the compatible property, not the name of the field, > as all other property descriptions are. Ok, so that's a legacy artifact of several incarnations of these tags before I posted initially. I agree, it should be "string" or "value", probably the latter as you suggest. -Matt -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 0/5] DT binding documents using text markup
On Tue, Sep 01, 2015 at 09:14:24AM -0700, Tim Bird wrote: > On Thu, Aug 27, 2015 at 10:23 PM, Matt Porter wrote: > > During the Device Tree microconference at Linux Plumbers 2015, we had > > a short discussion about how to improve DT Binding Documentation. A > > number of issues were raised (again, as these things have been > > discussed in the past) including: > > > > * Inconsistency between binding documents due to prose text > > format. > > * Inability to reliably machine read bindings for mass update > > or search. > > * Bit rot of bindings as new conventions are agreed upon but > > only new bindings are changed. > > > > Grant Likely probably summed up the issue best with "...as long as > > bindings are human readable, we'll have issues...". > I'd rephrase that to "... as long as bindings are not machine readable, > we'll have issues...". Human readable and machine readable are not > mutually exclusive. XML is not, IMHO, human readable, but YAML looks > pretty good, so I think it's a good choice. Yes, that's exactly what I hoped to find with this experiment...that we can have both. > > The context > > of that comment was, of course, regarding our current documents > > written in very inconsistent prose style. When the topic of needing > > the bindings in a rigid format was raised, there was general head > > nodding that this was needed. It was noted that this has been > > discussed many times before and nothing has been done. > > > > My proposed solution to the problem is to convert all DT bindings > > a rigid text markup format. In choosing a text markup language my > > requirements were: > > > > 1) Human readable > > 2) Well documented > > 3) Easy to translate to other data formats > > 4) Well supported by tools and libraries > > > > After looking at a number of markup options, YAML stood out as the > > one that meets all of these requirements. The YAML syntax is adopted > > in many projects specifically because of the high level of readability. > > A comprehensive spec is at http://www.yaml.org/spec/1.2/spec.html. > > There's a number of tools to convert between YAML and other popular > > data formats such as JSON and XML. XML was cited by Behan Webster > > during the microconference as an important data format as the type > > of developers that may produce comprehensive DTS Binding validation > > tools will want to use XML. Every major scripting language has a > > high level binding to the low level libyaml C library to facilitate > > handling of YAML data files. > > > > One caveat with YAML is it does not tolerate tabs. Yes, I said it. > > No tabs! This can be managed with proper editor modes and also with > > helper scripts to strip tabs to aid in people passing planned > > checkpatch.pl checks that would run YAML DT Binding specific tag > > validators for new bindings. > > This will be an endless source of pain. Based on your examples, > it looks like we only need a very small subset of YAML. I'd be willing > to write a parser for the language, but we might lose the ability to > do conversions to other formats. It depends on how comprehensive > and automatic the helper scripts to strip tabs would be. We need something to validate that a binding meets our binding schema so it shouldn't a huge problem to have it warn and by option, reformat the binding with tabs stripped. Having an appropriate mode available for vim/emacs would go a long way to helping here too. > > The scope of the initial YAML DT Binding format was specifically > > limited to supporting *only* the content we have in bindings today. > > The idea here is to propose and agree on something that will take > > us just a few steps in the right direction. If we move *all* current > > binding content to a machine parseable format, additional features > > can be added with more automation and scripting. As it stands today, > > because of the inconsistency of the wording of the files, we can't > > add a lot of new features to the content until we convert what we > > have today into a standard format. > > > > With that said, it should be noted that some new features such as > > "type" tags to indicate cell types could be added to support > > additional DTS validation beyond what the current content supports. > > Another possibility is adding "range" type information to validate > > the legal values for a cell. > > I would recommend we add type and somethin
Re: [RFC PATCH 0/5] DT binding documents using text markup
On Sun, Aug 30, 2015 at 03:04:20PM -0700, Frank Rowand wrote: > On 8/27/2015 10:23 PM, Matt Porter wrote: > > During the Device Tree microconference at Linux Plumbers 2015, we had > > a short discussion about how to improve DT Binding Documentation. A > > number of issues were raised (again, as these things have been > > discussed in the past) including: > > > > * Inconsistency between binding documents due to prose text > > format. > > * Inability to reliably machine read bindings for mass update > > or search. > > * Bit rot of bindings as new conventions are agreed upon but > > only new bindings are changed. > > > > Grant Likely probably summed up the issue best with "...as long as > > bindings are human readable, we'll have issues...". The context > > of that comment was, of course, regarding our current documents > > written in very inconsistent prose style. When the topic of needing > > the bindings in a rigid format was raised, there was general head > > nodding that this was needed. It was noted that this has been > > discussed many times before and nothing has been done. > > > > My proposed solution to the problem is to convert all DT bindings > > a rigid text markup format. In choosing a text markup language my > > requirements were: > > > > 1) Human readable > > 2) Well documented > > 3) Easy to translate to other data formats > > 4) Well supported by tools and libraries > > Thanks for taking this on! The proposal looks like a great start. > The requirements look good. > > > > After looking at a number of markup options, YAML stood out as the > > one that meets all of these requirements. The YAML syntax is adopted > > in many projects specifically because of the high level of readability. > > A comprehensive spec is at http://www.yaml.org/spec/1.2/spec.html. > > There's a number of tools to convert between YAML and other popular > > data formats such as JSON and XML. XML was cited by Behan Webster > > during the microconference as an important data format as the type > > of developers that may produce comprehensive DTS Binding validation > > tools will want to use XML. Every major scripting language has a > > high level binding to the low level libyaml C library to facilitate > > handling of YAML data files. > > > > One caveat with YAML is it does not tolerate tabs. Yes, I said it. > > No tabs! This can be managed with proper editor modes and also with > > helper scripts to strip tabs to aid in people passing planned > > checkpatch.pl checks that would run YAML DT Binding specific tag > > validators for new bindings. > > I'm just a casual user of some markup languages, nowhere near knowledgeable > or an expert, so will be listening to reasoned opinions on the choice of > YAML. But a quick look at the spec you referenced and the examples you > provided gives me some confidence that YAML will work. > > > > The scope of the initial YAML DT Binding format was specifically > > limited to supporting *only* the content we have in bindings today. > > The idea here is to propose and agree on something that will take > > us just a few steps in the right direction. If we move *all* current > > Yes, this is a great approach so we can start making reasonable progress. > (Caveat below.) > > > binding content to a machine parseable format, additional features > > can be added with more automation and scripting. As it stands today, > > because of the inconsistency of the wording of the files, we can't > > add a lot of new features to the content until we convert what we > > have today into a standard format. > > > > With that said, it should be noted that some new features such as > > "type" tags to indicate cell types could be added to support > > additional DTS validation beyond what the current content supports. > > Another possibility is adding "range" type information to validate > > the legal values for a cell. > > The caveat: I think we should look at some obvious features (such as > "type" that you mention) to make sure that YAML and the chosen > structuring will easily and effectively support the features. > > Thinking about how some features might be implemented led to comments > that I will make in replies to the other patches. > > I agree that we should not attempt to add the additional information > enabled by the new features if the information is not in the present > bindings. Adding the new information in a subsequent pass seems
Re: [RFC PATCH 2/5] Documentation: dt-bindings: add example DT binding document
On Fri, Aug 28, 2015 at 01:55:11PM -0500, Rob Herring wrote:
> On Fri, Aug 28, 2015 at 12:49 PM, Matt Porter wrote:
> > On Fri, Aug 28, 2015 at 09:53:06AM -0500, Rob Herring wrote:
> >> On Fri, Aug 28, 2015 at 12:23 AM, Matt Porter wrote:
> >> > Add a skeleton DT binding document that serves as the canonical
> >> > example for implementing YAML-based DT bindings documentation.
> >> > The skeleton binding illustrates use of all fields and variations
> >> > described in the dt-binding-format.txt documentation.
> >> >
> >> > Signed-off-by: Matt Porter
> >> > ---
> >> > Documentation/devicetree/bindings/skeleton.yaml | 98
> >> > +
> >> > 1 file changed, 98 insertions(+)
> >> > create mode 100644 Documentation/devicetree/bindings/skeleton.yaml
> >> >
> >> > diff --git a/Documentation/devicetree/bindings/skeleton.yaml
> >> > b/Documentation/devicetree/bindings/skeleton.yaml
> >> > new file mode 100644
> >> > index 000..175965f
> >> > --- /dev/null
> >> > +++ b/Documentation/devicetree/bindings/skeleton.yaml
> >> > @@ -0,0 +1,98 @@
> >> > +%YAML 1.2
> >> > +---
> >> > +id: skel-device
> >> > +
> >> > +title: Skeleton Device
> >> > +
> >> > +maintainer:
> >> > + - name: Skeleton Person
> >>
> >> We'd want to tie this into get_maintainers.pl obviously.
> >
> > Right, I broke my rule of "no new tags for content we don't already
> > have" by adding this. It stems out of the discussion at LPC where
> > Mark suggested we could avoid the core bindings being moved by adding
> > maintainer info into the binding itself.
>
> If you stated that rule, I missed it...
Mental list of rules I made for my initial cut at this. I was trying
really hard to have this be a cut and paste reformatting to start and
then see where comments take us.
> > This is an area where more docs are needed. Ideally, on the first pass
> > conversion we would not attempt to populate these. I had considered
> > that we *could* only add maintainer: tags on core bindings to and
> > adjust get_maintainers.pl to use that info to override the standard
> > directory-based info if it exists. I don't think it's necessary to add
> > a specific maintainer for all of the peripheral bindings if the default
> > is the subsystem maintainer and the dt list. We could at least start
> > directing core binding discussion to the -spec list which is where I
> > think you'd like it.
>
> Yes, certainly this can solve my problem around handling core bindings.
>
> Some subsystem maintainers require a driver have a maintainer. We
> could certainly enforce that too. We could probably automatically
> populate this with the original author as a starting point. OTOH,
> bindings should not change frequently.
Populating with the original author seems easy enough.
> >> > +description: >
> >> > + The Skeleton Device binding represents the SK11 device produced by
> >> > + the Skeleton Corporation. The binding can also support compatible
> >> > + clones made by second source vendors.
> >> > +
> >> > +compatible:
> >> > + - name: "skel,sk11"
> >> > + - name: "faux,fx11"
> >>
> >> Is this an OR or AND? We need both.
> >
> > True, this only covers the OR case atm.
> >
> >> The complicated case is "one of {specific names} followed by {generic
> >> name}."
> >
> > I need to rethink these. I do have deprecated: tag for that case and
> > possibly "name:" gets split to "generic:" and "specific:" and we can
> > then do the right thing.
> >
> > For the above I would have:
> >
> > compatible:
> > - specific: "skel,sk11"
> > - specific: "faux,fx11"
>
> This can still be an AND or OR relationship.
Ok, so this might need to be sequences of and: and or:
key value pairs to reflect the combinations.
> > and something like the Allwinner simple framebuffer would be:
> >
> > compatible:
> > - generic: "simple-framebuffer"
> > - specific: "allwinner,simple-framebuffer"
> >
> > where our validator would insist on seeing one of the specific: tags
> > along with the generic: tag. A lot of bindings, given current doc
> > patterns would just have two tags like above.
>
> We
Re: [RFC PATCH 2/5] Documentation: dt-bindings: add example DT binding document
On Fri, Aug 28, 2015 at 09:53:06AM -0500, Rob Herring wrote:
> On Fri, Aug 28, 2015 at 12:23 AM, Matt Porter wrote:
> > Add a skeleton DT binding document that serves as the canonical
> > example for implementing YAML-based DT bindings documentation.
> > The skeleton binding illustrates use of all fields and variations
> > described in the dt-binding-format.txt documentation.
> >
> > Signed-off-by: Matt Porter
> > ---
> > Documentation/devicetree/bindings/skeleton.yaml | 98
> > +
> > 1 file changed, 98 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/skeleton.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/skeleton.yaml
> > b/Documentation/devicetree/bindings/skeleton.yaml
> > new file mode 100644
> > index 000..175965f
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/skeleton.yaml
> > @@ -0,0 +1,98 @@
> > +%YAML 1.2
> > +---
> > +id: skel-device
> > +
> > +title: Skeleton Device
> > +
> > +maintainer:
> > + - name: Skeleton Person
>
> We'd want to tie this into get_maintainers.pl obviously.
Right, I broke my rule of "no new tags for content we don't already
have" by adding this. It stems out of the discussion at LPC where
Mark suggested we could avoid the core bindings being moved by adding
maintainer info into the binding itself.
This is an area where more docs are needed. Ideally, on the first pass
conversion we would not attempt to populate these. I had considered
that we *could* only add maintainer: tags on core bindings to and
adjust get_maintainers.pl to use that info to override the standard
directory-based info if it exists. I don't think it's necessary to add
a specific maintainer for all of the peripheral bindings if the default
is the subsystem maintainer and the dt list. We could at least start
directing core binding discussion to the -spec list which is where I
think you'd like it.
> > +
> > +description: >
> > + The Skeleton Device binding represents the SK11 device produced by
> > + the Skeleton Corporation. The binding can also support compatible
> > + clones made by second source vendors.
> > +
> > +compatible:
> > + - name: "skel,sk11"
> > + - name: "faux,fx11"
>
> Is this an OR or AND? We need both.
True, this only covers the OR case atm.
> The complicated case is "one of {specific names} followed by {generic name}."
I need to rethink these. I do have deprecated: tag for that case and
possibly "name:" gets split to "generic:" and "specific:" and we can
then do the right thing.
For the above I would have:
compatible:
- specific: "skel,sk11"
- specific: "faux,fx11"
and something like the Allwinner simple framebuffer would be:
compatible:
- generic: "simple-framebuffer"
- specific: "allwinner,simple-framebuffer"
where our validator would insist on seeing one of the specific: tags
along with the generic: tag. A lot of bindings, given current doc
patterns would just have two tags like above.
> > +description: A clone of the original sk11 device
> > +
> > +required:
> > + - name: "reg"
>
> We definitely need type info from the start.
Are you sure? Ugh.
My big contention here is that we don't carry that content in the
docs today so we shouldn't try to add it in the initial conversion.
I think you are right in that we should have it documented in the
schema but I'm concerned that we make the starting conversion
effort too large by adding type info to all converted docs.
I think we gain a lot even without at the start, but I understand
why we need it and how it will help reduce the review firehose
with the associated validation tools.
>
> > +description: chip select address of skeleton device
> > +reference: spi-slave
>
> I would like to not have to list properties if the inherited binding
> lists it. The problem is we need to say how many cells and the order
> (not a problem here, but for mmio devices).
Yeah, make sense.
> Perhaps we can list the reference at the top level for the node
> instead of for every property.
That's a good point. I was wondering if per prop references would
get unwieldy once we actually add them into all the converted docs.
There's a huge number of existing docs without proper references.
Ok, I'll take a look at collecting references per group of properties.
>
> > + - name: "spi-max-frequency"
> > +description: >
> > + Maximum SPI clocking speed of skeleton device in Hz, must be
> > + 100
> > +ref
Re: [RFC PATCH 0/5] DT binding documents using text markup
On Fri, Aug 28, 2015 at 09:26:17AM -0500, Rob Herring wrote: > On Fri, Aug 28, 2015 at 12:23 AM, Matt Porter wrote: > > During the Device Tree microconference at Linux Plumbers 2015, we had > > a short discussion about how to improve DT Binding Documentation. A > > number of issues were raised (again, as these things have been > > discussed in the past) including: > > > > * Inconsistency between binding documents due to prose text > > format. > > * Inability to reliably machine read bindings for mass update > > or search. > > * Bit rot of bindings as new conventions are agreed upon but > > only new bindings are changed. > > Thanks for pulling this together. > > > Grant Likely probably summed up the issue best with "...as long as > > bindings are human readable, we'll have issues...". The context > > of that comment was, of course, regarding our current documents > > written in very inconsistent prose style. When the topic of needing > > the bindings in a rigid format was raised, there was general head > > nodding that this was needed. It was noted that this has been > > discussed many times before and nothing has been done. > > > > My proposed solution to the problem is to convert all DT bindings > > a rigid text markup format. In choosing a text markup language my > > requirements were: > > > > 1) Human readable > > 2) Well documented > > 3) Easy to translate to other data formats > > 4) Well supported by tools and libraries > > > > After looking at a number of markup options, YAML stood out as the > > one that meets all of these requirements. The YAML syntax is adopted > > in many projects specifically because of the high level of readability. > > A comprehensive spec is at http://www.yaml.org/spec/1.2/spec.html. > > There's a number of tools to convert between YAML and other popular > > data formats such as JSON and XML. XML was cited by Behan Webster > > during the microconference as an important data format as the type > > of developers that may produce comprehensive DTS Binding validation > > tools will want to use XML. Every major scripting language has a > > high level binding to the low level libyaml C library to facilitate > > handling of YAML data files. > > Being markup language novice, this looks good to me. > > > One caveat with YAML is it does not tolerate tabs. Yes, I said it. > > No tabs! This can be managed with proper editor modes and also with > > helper scripts to strip tabs to aid in people passing planned > > checkpatch.pl checks that would run YAML DT Binding specific tag > > validators for new bindings. > > What do parsers do with tabs? Throw an error? Yes, they throw an error. Keep in mind that most of what I used to start are general purpose conversion tools on top of a particular scripting languages's high level binding to libyaml. The error output leaves a bit to be desired for our use case. In any case, when I was developing the skeleton.yaml I used the yaml script from https://github.com/ryo/yamltools to catch all these syntax errors I was inserting..like tabs. the PyYaml binding being used in my PoC dtgendoc does the same thing but I don't gracefully handle those errors like we could. > Beyond tabs, how do we check files can be parsed both generically and > for any binding specific requirements. We now need a schema for > checking the schema. We need some equivalent to compile testing. Right. So, I think what you are touching on is something I should have expanded on in the TODO list. Basically, we need a scripted tool that we run from checkpatch.pl that 1) reads the .yaml and validates the YAML itself (that comes for free in the high level parsers) reporting errors in a sensical manner 2) validates our DT binding specific tags Now, I would caution about trying to do too much on Day 1 or we could end up back at the "never doing anything" stage. It would be an improvement to simply check that the basic tags exist as shown in the [R] or [O] fields in the documentation. One thing I should point out is that I carefully avoided marking some tags as [R] where existing bindings don't have them...even if logically, a description should be required on every binding. The idea here is to avoid updating content at the same time that we are updating the format. Rather, I think it would be better to get the base format updated, then come back with a janitorial team and add descriptions (since now we can generate a worklist of those bindings missing a top-level description) and systematically fix those and review with the appropriate maintainers. > An
[RFC PATCH 3/5] Documentation: dt-bindings: add YAML eeprom binding
Convert the eeprom.txt binding to standard YAML DT
binding format.
Signed-off-by: Matt Porter
---
Documentation/devicetree/bindings/eeprom.yaml | 44 +++
1 file changed, 44 insertions(+)
create mode 100644 Documentation/devicetree/bindings/eeprom.yaml
diff --git a/Documentation/devicetree/bindings/eeprom.yaml
b/Documentation/devicetree/bindings/eeprom.yaml
new file mode 100644
index 000..bf1244b
--- /dev/null
+++ b/Documentation/devicetree/bindings/eeprom.yaml
@@ -0,0 +1,44 @@
+%YAML 1.2
+---
+id: eeprom-i2c
+
+title: EEPROMs (I2C)
+
+compatible:
+ - name: ",24c00"
+ - name: ",24c01"
+ - name: ",24c02"
+ - name: ",24c04"
+ - name: ",24c08"
+ - name: ",24c16"
+ - name: ",24c32"
+ - name: ",24c64"
+ - name: ",24c128"
+ - name: ",24c256"
+ - name: ",24c512"
+ - name: ",24c1024"
+ - name: ",spd"
+
+required:
+ - name: "reg"
+description: the I2c address of the EEPROM
+
+optional:
+ - name: "pagesize"
+description: >
+ the length of the pagesize for writing. Please consult the
+ manual of your device, that value varies a lot. A wrong value
+ may result in data loss! If not specified, a safety value of
+ '1' is used which will be very slow.
+ - name: "read-only"
+description: >
+ this parameterless property disables writes to the eeprom
+
+example:
+ - dts: |
+ eeprom@52 {
+ compatible = "atmel,24c32";
+ reg = <0x52>;
+ pagesize = <32>;
+ };
+...
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 5/5] Documentation: dt-bindings: phy: add YAML TI PHY binding
Convert the ti-phy.txt binding to standard YAML DT binding
format. This binding references the YAML generic PHY binding.
Signed-off-by: Matt Porter
---
Documentation/devicetree/bindings/phy/ti-phy.yaml | 166 ++
1 file changed, 166 insertions(+)
create mode 100644 Documentation/devicetree/bindings/phy/ti-phy.yaml
diff --git a/Documentation/devicetree/bindings/phy/ti-phy.yaml
b/Documentation/devicetree/bindings/phy/ti-phy.yaml
new file mode 100644
index 000..ec93501
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/ti-phy.yaml
@@ -0,0 +1,166 @@
+%YAML 1.2
+---
+id: omap-control-phy
+
+title: OMAP Control PHY
+
+compatible:
+ - name: "ti,control-phy-otghs"
+description: if it has otghs_control mailbox register as on OMAP4.
+ - name: "ti,control-phy-usb2"
+description: if it has Power down bit in control_dev_conf register
+ e.g. USB2_PHY on OMAP5.
+ - name: "ti,control-phy-pipe3"
+description: if it has DPLL and individual Rx & Tx power control
+ e.g. USB3 PHY and SATA PHY on OMAP5.
+ - name: "ti,control-phy-pcie"
+description: for pcie to support external clock for pcie and to
+ set PCS delay value. e.g. PCIE PHY in DRA7x
+ - name: "ti,control-phy-usb2-dra7"
+description: if it has power down register like USB2 PHY on DRA7
+ DRA7 platform.
+ - name: "ti,control-phy-usb2-am437"
+description: if it has power down register like USB2 PHY on AM437
+ platform.
+required:
+ - name: "reg"
+description: register ranges as listed in the reg-names property
+ - name: "reg-names"
+description: >
+ "otghs_control" for control-phy-otghs "power",
+ "pcie_pcs" and "control_sma" for control-phy-pcie
+ "power" for all other types
+
+example:
+ - dts: |
+ omap_control_usb: omap-control-usb@4a002300 {
+ compatible = "ti,control-phy-otghs";
+ reg = <0x4a00233c 0x4>;
+ reg-names = "otghs_control";
+ };
+...
+
+---
+id: omap-usb2-phy
+
+title: OMAP USB2 PHY
+
+compatible:
+ - name: "ti,omap-usb2"
+
+required:
+ - name: "reg"
+description: >
+ Address and length of the register set for the device.
+ - name: "#phy-cells"
+description: >
+ determine the number of cells that should be given in
+ the phandle while referencing this phy.
+reference: phy-device
+ - name: "clocks"
+description: >
+ a list of phandles and clock-specifier pairs, one for
+ each entry in clock-names.
+reference: clock-consumer
+ - name: "clock-names"
+description: >
+ should include:
+ * "wkupclk" - wakeup clock.
+ * "refclk" - reference clock (optional).
+reference: clock-consumer
+
+optional:
+ - name: "ctrl-module"
+description: >
+ phandle of the control module used by PHY driver to
+ power on the PHY.
+
+example:
+ - dts: |
+ usb2phy@4a0ad080 {
+compatible = "ti,omap-usb2";
+reg = <0x4a0ad080 0x58>;
+ctrl-module = <&omap_control_usb>;
+#phy-cells = <0>;
+clocks = <&usb_phy_cm_clk32k>, <&usb_otg_ss_refclk960m>;
+clock-names = "wkupclk", "refclk";
+ };
+description: >
+ This is usually a subnode of ocp2scp to which it is
+ connected.
+...
+
+---
+id: ti-pipe3-phy
+
+title: TI Pipe3 PHY
+
+compatible:
+ - name: "ti,phy-usb3"
+ - name: "ti,phy-pipe3-sata"
+ - name: "ti,phy-pipe3-pcie"
+ - deprecated: "ti,omap-usb3"
+
+required:
+ - name: "reg"
+description: >
+ Address and length of the register set for the device.
+ - name: "reg-names"
+description: >
+ The names of the register addresses corresponding to
+ the registers filled in "reg".
+ - name: "#phy-cells"
+description: >
+ determine the number of cells that should be given in
+ the phandle while referencing this phy.
+reference: phy-device
+ - name: "clocks"
+description: >
+ a list of phandles and clock-specifier pairs, one for
+ each entry in clock-names.
+reference: clock-consumer
+ - name: "clock-names"
+description: >
+ should include:
+ * "wkupclk" - wakeup clock
[RFC PATCH 4/5] Documentation: dt-bindings: phy: add YAML generic PHY binding
Convert the generic phy-bindings.txt binding to standard YAML
DT binding format.
Signed-off-by: Matt Porter
---
.../devicetree/bindings/phy/phy-bindings.yaml | 89 ++
1 file changed, 89 insertions(+)
create mode 100644 Documentation/devicetree/bindings/phy/phy-bindings.yaml
diff --git a/Documentation/devicetree/bindings/phy/phy-bindings.yaml
b/Documentation/devicetree/bindings/phy/phy-bindings.yaml
new file mode 100644
index 000..9b164d1
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/phy-bindings.yaml
@@ -0,0 +1,89 @@
+%YAML 1.2
+---
+id: phy-device
+
+title: PHY device
+
+description: >
+ This document explains only the device tree data binding. For general
+ information about PHY subsystem refer to Documentation/phy.txt
+
+required:
+ - name: "#phy-cells"
+description: >
+ number of cells in a PHY specifier. The meaning of all those
+ cells is defined by the binding for the phy node. The PHY
+ provider can use the values in cells to find the appropriate
+ PHY.
+
+optional:
+ - name: "phy-supply"
+description: >
+ phandle to a regulator that provides power to the PHY. This
+ regulator will be managed during the PHY power on/off sequence.
+
+example:
+ - dts: |
+ phys: phy {
+ compatible = "xxx";
+ reg = <...>;
+ .
+ .
+ #phy-cells = <1>;
+ .
+ .
+ };
+description: >
+ Describes an IP block (PHY provider) that implements 2 different
+ PHYs. In order to differentiate between these 2 PHYs, an
+ additional specifier should be given while trying to get a
+ reference to it.
+...
+
+---
+id: phy-user
+
+title: PHY user
+
+required:
+ - name: "phys"
+description: >
+ the phandle for the PHY device (used by the PHY subsystem)
+ - name: "phy-names"
+description: >
+ the names of the PHY corresponding to the PHYs present in the
+ *phys* phandle
+
+example:
+ - dts: |
+ usb1: usb_otg_ss@xxx {
+ compatible = "xxx";
+ reg = ;
+ .
+ .
+ phys = <&usb2_phy>, <&usb3_phy>;
+ phy-names = "usb2phy", "usb3phy";
+ .
+ .
+ };
+description: >
+ Represents a controller that uses two PHYs, one for usb2 and one
+ for usb3.
+
+ - dts: |
+ usb2: usb_otg_ss@xxx {
+ compatible = "xxx";
+ reg = ;
+ .
+ .
+ phys = <&phys 1>;
+ phy-names = "usbphy";
+ .
+ .
+ };
+description: >
+ Represents a controller that uses one of the PHYs of the PHY
+ provider device defined previously. Note that the phy handle
+ has an additional specifier "1" to differentiate between the
+ two PHYs.
+...
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 0/5] DT binding documents using text markup
During the Device Tree microconference at Linux Plumbers 2015, we had a short discussion about how to improve DT Binding Documentation. A number of issues were raised (again, as these things have been discussed in the past) including: * Inconsistency between binding documents due to prose text format. * Inability to reliably machine read bindings for mass update or search. * Bit rot of bindings as new conventions are agreed upon but only new bindings are changed. Grant Likely probably summed up the issue best with "...as long as bindings are human readable, we'll have issues...". The context of that comment was, of course, regarding our current documents written in very inconsistent prose style. When the topic of needing the bindings in a rigid format was raised, there was general head nodding that this was needed. It was noted that this has been discussed many times before and nothing has been done. My proposed solution to the problem is to convert all DT bindings a rigid text markup format. In choosing a text markup language my requirements were: 1) Human readable 2) Well documented 3) Easy to translate to other data formats 4) Well supported by tools and libraries After looking at a number of markup options, YAML stood out as the one that meets all of these requirements. The YAML syntax is adopted in many projects specifically because of the high level of readability. A comprehensive spec is at http://www.yaml.org/spec/1.2/spec.html. There's a number of tools to convert between YAML and other popular data formats such as JSON and XML. XML was cited by Behan Webster during the microconference as an important data format as the type of developers that may produce comprehensive DTS Binding validation tools will want to use XML. Every major scripting language has a high level binding to the low level libyaml C library to facilitate handling of YAML data files. One caveat with YAML is it does not tolerate tabs. Yes, I said it. No tabs! This can be managed with proper editor modes and also with helper scripts to strip tabs to aid in people passing planned checkpatch.pl checks that would run YAML DT Binding specific tag validators for new bindings. The scope of the initial YAML DT Binding format was specifically limited to supporting *only* the content we have in bindings today. The idea here is to propose and agree on something that will take us just a few steps in the right direction. If we move *all* current binding content to a machine parseable format, additional features can be added with more automation and scripting. As it stands today, because of the inconsistency of the wording of the files, we can't add a lot of new features to the content until we convert what we have today into a standard format. With that said, it should be noted that some new features such as "type" tags to indicate cell types could be added to support additional DTS validation beyond what the current content supports. Another possibility is adding "range" type information to validate the legal values for a cell. This series is broken up into three major parts: 1) The documentation defining the YAML DT binding format 2) A skeleton device binding example illustrating use of this format 3) Some real binding conversions (eeprom.txt, phy-bindings.txt, and ti-phy.txt As a proof of concept of what can be done with a proper machine readable DT binding source file, there's a simple markdown document generator at https://github.com/konsulko/dtgendoc. Also, to see actual output from the generator, the generated markdown from those bindings is viewable at https://github.com/konsulko/dtgendoc/wiki There's a lot of other possibilities for validation tools using only the data we have today in the bindings. In addition, Frank Rowand covered some DT debug techniques that would benefit from the binding documentation being 100% reliably searchable. I found it useful to see a side-by-side view of a converted doc versus the original content, so here's a screenshot of eeprom.txt vs. eeprom.yaml: https://github.com/konsulko/dtgendoc/wiki#eepromtxt-vs-eepromyaml When we decide on a text markup format that is acceptable, then the next step is to convert all the bindings. That process would start with the complete set of generic bindings as they will be referenced by the actual device bindings. If the RFC wasn't explicit enough...comments welcome. -Matt Matt Porter (5): Documentation: dt-bindings: add documentation on new DT binding format Documentation: dt-bindings: add example DT binding document Documentation: dt-bindings: add YAML eeprom binding Documentation: dt-bindings: phy: add YAML generic PHY binding Documentation: dt-bindings: phy: add YAML TI PHY binding .../devicetree/bindings/dt-binding-format.txt | 106 + Documentation/devicetree/bindin
[RFC PATCH 2/5] Documentation: dt-bindings: add example DT binding document
Add a skeleton DT binding document that serves as the canonical
example for implementing YAML-based DT bindings documentation.
The skeleton binding illustrates use of all fields and variations
described in the dt-binding-format.txt documentation.
Signed-off-by: Matt Porter
---
Documentation/devicetree/bindings/skeleton.yaml | 98 +
1 file changed, 98 insertions(+)
create mode 100644 Documentation/devicetree/bindings/skeleton.yaml
diff --git a/Documentation/devicetree/bindings/skeleton.yaml
b/Documentation/devicetree/bindings/skeleton.yaml
new file mode 100644
index 000..175965f
--- /dev/null
+++ b/Documentation/devicetree/bindings/skeleton.yaml
@@ -0,0 +1,98 @@
+%YAML 1.2
+---
+id: skel-device
+
+title: Skeleton Device
+
+maintainer:
+ - name: Skeleton Person
+
+description: >
+ The Skeleton Device binding represents the SK11 device produced by
+ the Skeleton Corporation. The binding can also support compatible
+ clones made by second source vendors.
+
+compatible:
+ - name: "skel,sk11"
+ - name: "faux,fx11"
+description: A clone of the original sk11 device
+
+required:
+ - name: "reg"
+description: chip select address of skeleton device
+reference: spi-slave
+ - name: "spi-max-frequency"
+description: >
+ Maximum SPI clocking speed of skeleton device in Hz, must be
+ 100
+reference: spi-slave
+
+optional:
+ - name: "spi-cs-high"
+description: >
+ Set if skeleton device configuration straps are set for chip
+ select polarity high
+reference: spi-slave
+
+deprecated:
+ - name: "skel,deprecated1"
+description: >
+ First of two deprecated properties.
+ - name: "skel,deprecated2"
+description: >
+ Second of two deprecated properties.
+
+example:
+ - dts: |
+ sk11@0 {
+ compatible = "skel,sk11";
+ reg = <0>;
+ spi-max-frequency = <100>;
+ spi-cs-high;
+ };
+...
+
+---
+id: skel-mini
+
+title: Skeleton Mini Device
+
+maintainer:
+ - name: Rogue Developer
+
+description: >
+ The Skeleton Mini Device binding represents the SK47x series devices
+ produced by the Skeleton Corporation.
+
+compatible:
+ - name: "skel,sk472"
+ - name: "skel,sk473"
+ - name: "skel,sk474"
+ - deprecated: "skel,sk47x"
+
+required:
+ - name: "reg"
+description: offset and length of the registers
+
+optional:
+ - name: "skel,sync-mode"
+description: Enable synchronous transfer mode
+
+example:
+ - dts: |
+ sk472@beef {
+ compatible = "skel,sk472";
+ reg = <0xbeef 0x100>;
+ };
+description: >
+ Demonstrates an SK472 in normal mode.
+
+ - dts: |
+ sk474@dead {
+ compatible = "skel,sk474";
+ reg = <0xdead 0x100>;
+ skel,sync-mode;
+ };
+description: >
+ Demonstrates an SK474 in synchronous mode.
+...
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 1/5] Documentation: dt-bindings: add documentation on new DT binding format
Documentation explaining the syntax and format of the YAML-based DT binding
documentation.
Signed-off-by: Matt Porter
---
.../devicetree/bindings/dt-binding-format.txt | 106 +
1 file changed, 106 insertions(+)
create mode 100644 Documentation/devicetree/bindings/dt-binding-format.txt
diff --git a/Documentation/devicetree/bindings/dt-binding-format.txt
b/Documentation/devicetree/bindings/dt-binding-format.txt
new file mode 100644
index 000..f9acc22
--- /dev/null
+++ b/Documentation/devicetree/bindings/dt-binding-format.txt
@@ -0,0 +1,106 @@
+--
+Device Tree Binding Format
+--
+
+Background
+--
+
+DT bindings historically were written as text in prose format which
+led to issues in usability of that source documentation. Some of
+these issues include the need to programmatically process binding
+source documentation to do DTS validation, perform mass updates to
+format/style, and to generate publishable documentation in HTML or
+PDF form.
+
+Overview
+
+
+The DT binding format is based on the YAML text markup language.
+Although there are many text markup options available, YAML
+fulfills all requirements considered for a DT binding source format
+which include:
+
+1) Must be human readable
+2) Must be easily translated to other data formats (XML, JSON, etc).
+3) Must have sufficient tools and libraries to enable developers to
+ build new tools for DT binding processing
+4) Must have a complete spec to refer to syntax
+
+YAML is documentated in the specification found at
+http://www.yaml.org/spec/1.2/spec.html
+
+The required YAML DT binding tag format and syntax are defined in
+the following sections.
+
+YAML DT Binding Syntax
+--
+
+* Lines starting with "#" are comments and not part of the binding itself
+* "%YAML 1.2" starts a file, indicating the version of YAML in use
+* "---" starts a binding document
+* "..." ends a binding document
+* Multiple binding documents may exist in a single file
+* Tabs are not permitted
+* Scope is denoted by indentation of two spaces
+* Key value pairs are denoted by "key: value"
+* Sequences are denoted by "- "
+* Scalar values may convert newlines to spaces and preserve blank
+ lines for long description formatting using ">"
+* Scalar values may escape all reserved characters and preserve
+ newlines by using "|" to denote literal style
+
+For additional information on YAML syntax, refer to the specification
+at http://www.yaml.org/spec/1.2/spec.html
+
+YAML DT Binding Format
+--
+
+The following YAML types are supported in the DT binding format:
+
+* [R] id: unique identifier in property form (e.g. skel-device)
+
+* [R] title: title of the binding
+
+* [O] maintainer: sequence of maintainers
+ [R] name: name and email of maintainer or mailing list in RFC822
+form.
+
+* [O] description: full description of the binding
+
+* [O] compatible: sequence of valid compatible descriptors
+ [R] name: the compatible string surrounded in double quotes
+ [O] deprecated: a deprecated compatible string surrounded in
+ double quotes
+ [O] description: description of the compatible string
+
+* [O] required: sequence of required properties:
+ [R] name: name of the property surrounded in double quotes
+ [R] description: description of the property
+ [O] reference: optional reference to a binding id
+
+* [O] optional: sequence of optional properties:
+ [R] name: name of the property surrounded in double quotes
+ [R] description: description of the property
+ [O] reference: optional reference to a binding id
+
+* [O] deprecated: sequence of deprecated properties:
+ [R] name: name of the property surrounded in double quotes
+ [R] description: description of the property
+ [O] reference: optional reference to a binding id
+
+* [R] example: sequence of examples:
+ [R] dts: DT source of example usage. The example text must use
+ literal style ("|") so that it retains indentation and
+ newlines.
+ [O] description: description of the example
+
+Note: [R] and [O] denote required and optional fields, respectively.
+
+Skeleton Binding
+
+
+The skeleton.yaml binding found in the top of the DT binding tree
+is the canonical example of syntax and format to use when writing
+a DT binding document. It is maintained with the latest formatting
+conventions, making it the best starting point when writing a new DT
+binding.
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH-v5 1/5] Documentation: binding: add new property 'disable_after_xfer' to i2c-pxa
On Wed, Aug 05, 2015 at 10:49:18AM +0200, Wolfram Sang wrote: > > > Yeah, we could start i2c.txt, probably better to have separate new > > patch all together. > > I will start such a file today as part of the i2c slave framework > update which introduces flags to the reg property. Will post to the i2c > list this week. > That sounds great, Wolfram, that will be a nice improvement for the binding docs. Thanks, Matt signature.asc Description: Digital signature
Re: [PATCH-v5 1/5] Documentation: binding: add new property 'disable_after_xfer' to i2c-pxa
On Wed, Aug 05, 2015 at 12:04:25PM +0530, Vaibhav Hiremath wrote: > > > On Monday 27 July 2015 07:39 PM, Matt Porter wrote: > >On Tue, Jul 21, 2015 at 06:11:02PM +0530, Vaibhav Hiremath wrote: > >>Driver will now supports enable/disable across msg xfer, which user > >>can control it by new DT property - > >> > >>i2c-disable-after-xfer : If set, driver will disable I2C module after msg > >> xfer and enable it back before xfer. > > > >If this is a new property specific to this Marvell part, it needs > >the vendor prefix as in mrvl,i2c-disable-after-xfer > > > > We discussed about this, I think in V1 or V2. Decided to use generic > name, as feature (in turn property) could be used by other drivers as > well. Ahh, ok, thanks...coming in too late on this one. :) > >Or, it couldn't hurt to start an i2c.txt for generic i2c bindings > >and store it there as this and others later in this series would > >reasonably apply to other controllers. > > > > Yeah, we could start i2c.txt, probably better to have separate new > patch all together. Great, yes, I've always found it hard to follow i2c generic bindings since they aren't defined in a clear place like other similar hardware (e.g. SPI). -Matt -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] MAX6675 IIO temperature driver
On Wed, Aug 05, 2015 at 11:33:25AM +0300, Daniel Baluta wrote: > On Tue, Aug 4, 2015 at 8:34 PM, Matt Porter wrote: > > On Tue, Aug 04, 2015 at 05:52:17PM +0100, Jonathan Cameron wrote: > >> > >> > >> On 3 August 2015 21:56:47 BST, Matt Porter wrote: > >> >This series adds a driver for the MAX6675 SPI thermocouple converter. > >> >The device supports temperature measurements via type-K thermocouples > >> >and implements cold-junction compensation within the part. The > >> >datasheet > >> >can be found at http://datasheets.maximintegrated.com/en/ds/MAX6675.pdf > >> For a device like this where perhaps it's position wrt iio/hwmon boundary > >> is unclear > >> I want to see an argument for why IIO makes more sense in the cover letter > >> + cc > >> at least the hwmon MAINTAINERS if not the list... > > > > Will do. Just to summarize here, the typical use case for this type of > > thermocouple converter involves sample rates that are relatively high > > compared to what the hwmon interface can support. The upcoming hrtimer > > trigger will match up well with this to support fine-grained > > periodic samples. I'll add this in the v2 cover latter. > > Are we talking about this hrtimer trigger patches: > > http://marc.info/?l=linux-iio&m=143109196107382&w=2 > > Right? I've been busy with some other things, but I hope to have a > final version by Sunday :). That's it! Thanks. :) -Matt -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] MAX6675 IIO temperature driver
On Tue, Aug 04, 2015 at 05:52:17PM +0100, Jonathan Cameron wrote: > > > On 3 August 2015 21:56:47 BST, Matt Porter wrote: > >This series adds a driver for the MAX6675 SPI thermocouple converter. > >The device supports temperature measurements via type-K thermocouples > >and implements cold-junction compensation within the part. The > >datasheet > >can be found at http://datasheets.maximintegrated.com/en/ds/MAX6675.pdf > For a device like this where perhaps it's position wrt iio/hwmon boundary is > unclear > I want to see an argument for why IIO makes more sense in the cover letter + > cc > at least the hwmon MAINTAINERS if not the list... Will do. Just to summarize here, the typical use case for this type of thermocouple converter involves sample rates that are relatively high compared to what the hwmon interface can support. The upcoming hrtimer trigger will match up well with this to support fine-grained periodic samples. I'll add this in the v2 cover latter. -Matt > >Matt Porter (3): > > iio: temperature: add max6675 dt binding > > iio: temperature: add max6675 thermocouple converter driver > > MAINTAINERS: add max6675 driver > > > > .../bindings/iio/temperature/max6675.txt | 19 +++ > > MAINTAINERS| 7 + > > drivers/iio/temperature/Kconfig| 11 ++ > > drivers/iio/temperature/Makefile | 1 + > >drivers/iio/temperature/max6675.c | 155 > >+ > > 5 files changed, 193 insertions(+) > >create mode 100644 > >Documentation/devicetree/bindings/iio/temperature/max6675.txt > > create mode 100644 drivers/iio/temperature/max6675.c > > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] iio: temperature: add max6675 thermocouple converter driver
On Tue, Aug 04, 2015 at 11:30:36AM +0200, Paul Bolle wrote:
> On ma, 2015-08-03 at 16:56 -0400, Matt Porter wrote:
> > --- /dev/null
> > +++ b/drivers/iio/temperature/max6675.c
> > +static const struct spi_device_id max6675_spi_ids[] = {
> > + {"max6675", 0},
> > + {},
> > +};
> > +MODULE_DEVICE_TABLE(spi, max6675_spi_ids);
>
> > +MODULE_ALIAS("spi:max6675");
>
> For the "spi" alias this is "belt and suspenders":
> modinfo ./max6675.ko | grep alias
> alias: spi:max6675
> alias: acpi*:MXIM6675:*
> alias: of:N*T*Cmaxim,max6675*
> alias: spi:max6675
>
> I'd drop the MODULE_ALIAS().
Ok, given that it generates a redundant alias I'll drop it.
> (Mark Brown made it quite clear I shouldn't nag people about the origin
> of the various strings used in these module aliases. So I won't. But if
> you'd volunteer to explain me where "max6675" might come from for the
> spi alias that would, at least, satisfy my curiosity.)
Sure, one might hotplug in an entire SPI master and this SPI slave device
via any discoverable bus and need the alias to match the module. It's
also typically used in a board file on embedded x86 stuff where overriding
the DSDT is not desirable.
-Matt
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] iio: temperature: add max6675 thermocouple converter driver
On Tue, Aug 04, 2015 at 10:50:32AM +0300, Daniel Baluta wrote:
> On Mon, Aug 3, 2015 at 11:56 PM, Matt Porter wrote:
> > Add a driver for the MAX6675 thermocouple converter. This
> > device interfaces with K-type thermocouples and provides
> > cold-junction compensated temperature readings via a
> > SPI interface.
>
> ./scripts/checkpatch.pl --strict says:
>
> CHECK: braces {} should be used on all arms of this statement
> #118: FILE: drivers/iio/temperature/max6675.c:61:
Will address in v2, thanks.
-Matt
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] iio: temperature: add max6675 thermocouple converter driver
On Mon, Aug 03, 2015 at 03:39:00PM -0700, Matt Ranostay Matt Ranostay wrote:
> On Mon, Aug 3, 2015 at 1:56 PM, Matt Porter wrote:
...
> > +static int max6675_probe(struct spi_device *spi)
> > +{
> > + struct iio_dev *indio_dev;
> > + struct max6675_state *st;
> > + int ret = 0;
> > +
> > + indio_dev = devm_iio_device_alloc(&spi->dev, sizeof(*st));
> > + if (!indio_dev)
> > + return -ENOMEM;
> > +
> > + st = iio_priv(indio_dev);
> > + st->spi = spi;
> > +
> > + spi->mode = SPI_MODE_1;
> > + spi->bits_per_word = 16;
>
> Have this error or display a warning when it doesn't match the passed
> DT binding settings. Otherwise it may get confusing why other SPI
> modes and word sizes don't work.
Ok, good point. The only thing here is that I've specified that spi-cpha
is required in the binding, indicating that Mode 1 will be used. I need
this driver to be instantiated via three methods: ACPI, DT, and "board
file" so for the latter I'm hardcoding in the driver the mode. The
device only works in Mode 1 so this seems sane, it's not configurable.
I don't parse that mode from either DT or ACPI data since it's not
needed. About the only thing I could do is pedantically check for
spi-cpha and if not present complain..but I think it's fine to simply
not parse at all given that we've hardcoded this for the allowed mode.
There's no property for bits_per_word, it's configured on a per-transfer
basis. In this case, this configures the default to do a 16-bit transfer
as required by the device. There is no way to modify this by a client of
this driver.
-Matt
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] iio: temperature: add max6675 dt binding
Add a DT binding for the MAX6675 SPI thermocouple converter.
The datasheet for this device may be found at
http://datasheets.maximintegrated.com/en/ds/MAX6675.pdf
Signed-off-by: Matt Porter
---
.../devicetree/bindings/iio/temperature/max6675.txt | 19 +++
1 file changed, 19 insertions(+)
create mode 100644
Documentation/devicetree/bindings/iio/temperature/max6675.txt
diff --git a/Documentation/devicetree/bindings/iio/temperature/max6675.txt
b/Documentation/devicetree/bindings/iio/temperature/max6675.txt
new file mode 100644
index 000..4e643e9
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/temperature/max6675.txt
@@ -0,0 +1,19 @@
+Maxim MAX6675 thermocouple converter
+
+Required properties:
+
+ - compatible: must be "maxim,max6675"
+ - reg: SPI chip select number for the device
+ - spi-max-frequency: must be 430
+ - spi-cpha: SPI Mode 1.
+
+ Refer to spi/spi-bus.txt for generic SPI slave bindings
+
+Example:
+
+ max6675@0 {
+ compatible = "maxim,max6675";
+ reg = <0>;
+ spi-max-frequency = <430>;
+ spi-cpha;
+ };
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] MAINTAINERS: add max6675 driver
Add myself as the MAX6675 driver maintainer. Signed-off-by: Matt Porter --- MAINTAINERS | 7 +++ 1 file changed, 7 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index a226416..355cc09 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -6543,6 +6543,13 @@ S: Maintained F: Documentation/hwmon/max6650 F: drivers/hwmon/max6650.c +MAX6675 THERMOCOUPLE CONVERTER DRIVER +M: Matt Porter +L: linux-...@vger.kernel.org +S: Maintained +F: Documentation/devicetree/bindings/iio/temperature/max6675.txt +F: drivers/iio/temperature/max6675.c + MAX6697 HARDWARE MONITOR DRIVER M: Guenter Roeck L: lm-sens...@lm-sensors.org -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] iio: temperature: add max6675 thermocouple converter driver
Add a driver for the MAX6675 thermocouple converter. This
device interfaces with K-type thermocouples and provides
cold-junction compensated temperature readings via a
SPI interface.
Signed-off-by: Matt Porter
---
drivers/iio/temperature/Kconfig | 11 +++
drivers/iio/temperature/Makefile | 1 +
drivers/iio/temperature/max6675.c | 155 ++
3 files changed, 167 insertions(+)
create mode 100644 drivers/iio/temperature/max6675.c
diff --git a/drivers/iio/temperature/Kconfig b/drivers/iio/temperature/Kconfig
index 21feaa4..b73fbf4 100644
--- a/drivers/iio/temperature/Kconfig
+++ b/drivers/iio/temperature/Kconfig
@@ -3,6 +3,17 @@
#
menu "Temperature sensors"
+config MAX6675
+ tristate "MAX6675 thermocouple converter"
+ depends on SPI
+ help
+ If you say yes here you get support for the Maxim
+ MAX6675 thermocouple converter connected with SPI.
+
+ This driver can also be built as a module. If so, the module will
+ be called max6675.
+
+
config MLX90614
tristate "MLX90614 contact-less infrared sensor"
depends on I2C
diff --git a/drivers/iio/temperature/Makefile b/drivers/iio/temperature/Makefile
index 40710a8..d67ef40 100644
--- a/drivers/iio/temperature/Makefile
+++ b/drivers/iio/temperature/Makefile
@@ -2,5 +2,6 @@
# Makefile for industrial I/O temperature drivers
#
+obj-$(CONFIG_MAX6675) += max6675.o
obj-$(CONFIG_MLX90614) += mlx90614.o
obj-$(CONFIG_TMP006) += tmp006.o
diff --git a/drivers/iio/temperature/max6675.c
b/drivers/iio/temperature/max6675.c
new file mode 100644
index 000..2d1fda2
--- /dev/null
+++ b/drivers/iio/temperature/max6675.c
@@ -0,0 +1,155 @@
+/*
+ * max6675.c - MAX6675 thermocouple converter driver
+ *
+ * Copyright (C) 2015 Konsulko Group, Matt Porter
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct max6675_state {
+ struct spi_device *spi;
+};
+
+static const struct iio_chan_spec max6675_channels[] = {
+ {
+ .type = IIO_TEMP,
+ .info_mask_separate =
+ BIT(IIO_CHAN_INFO_RAW) |
+ BIT(IIO_CHAN_INFO_SCALE),
+ },
+};
+
+static int max6675_read(struct max6675_state *st, int *val)
+{
+ int ret;
+
+ ret = spi_read(st->spi, val, 2);
+ if (ret < 0)
+ return ret;
+
+ /* Temperature is bits 14..3 */
+ *val = (*val >> 3) & 0xfff;
+
+ return ret;
+}
+
+static int max6675_read_raw(struct iio_dev *indio_dev,
+ struct iio_chan_spec const *chan,
+ int *val,
+ int *val2,
+ long m)
+{
+ struct max6675_state *st = iio_priv(indio_dev);
+ int ret;
+
+ if (m == IIO_CHAN_INFO_RAW) {
+ *val2 = 0;
+ ret = max6675_read(st, val);
+ if (ret)
+ return ret;
+ } else if (m == IIO_CHAN_INFO_SCALE) {
+ *val = 250;
+ *val2 = 0;
+ } else
+ return -EINVAL;
+
+ return IIO_VAL_INT;
+}
+
+static const struct iio_info max6675_info = {
+ .driver_module = THIS_MODULE,
+ .read_raw = &max6675_read_raw,
+};
+
+static int max6675_probe(struct spi_device *spi)
+{
+ struct iio_dev *indio_dev;
+ struct max6675_state *st;
+ int ret = 0;
+
+ indio_dev = devm_iio_device_alloc(&spi->dev, sizeof(*st));
+ if (!indio_dev)
+ return -ENOMEM;
+
+ st = iio_priv(indio_dev);
+ st->spi = spi;
+
+ spi->mode = SPI_MODE_1;
+ spi->bits_per_word = 16;
+
+ spi_set_drvdata(spi, indio_dev);
+
+ indio_dev->dev.parent = &spi->dev;
+ indio_dev->name = spi_get_device_id(spi)->name;
+ indio_dev->channels = max6675_channels;
+ indio_dev->num_channels = ARRAY_SIZE(max6675_channels);
+ indio_dev->modes = INDIO_DIRECT_MODE;
+ indio_dev->info = &max6675_info;
+
+ ret = iio_device_register(indio_dev);
+ if (ret < 0)
+ dev_err(&spi->dev, "unable to register device\n");
+
+ return ret;
+}
+
+static int max6675_remove(struct spi_device *spi)
+{
+ struct iio_dev *indio_dev = spi_get_drvdata(spi);
+
+ iio_device_unregister(i
[PATCH 0/3] MAX6675 IIO temperature driver
This series adds a driver for the MAX6675 SPI thermocouple converter. The device supports temperature measurements via type-K thermocouples and implements cold-junction compensation within the part. The datasheet can be found at http://datasheets.maximintegrated.com/en/ds/MAX6675.pdf Matt Porter (3): iio: temperature: add max6675 dt binding iio: temperature: add max6675 thermocouple converter driver MAINTAINERS: add max6675 driver .../bindings/iio/temperature/max6675.txt | 19 +++ MAINTAINERS| 7 + drivers/iio/temperature/Kconfig| 11 ++ drivers/iio/temperature/Makefile | 1 + drivers/iio/temperature/max6675.c | 155 + 5 files changed, 193 insertions(+) create mode 100644 Documentation/devicetree/bindings/iio/temperature/max6675.txt create mode 100644 drivers/iio/temperature/max6675.c -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ARM: dts: Add support for phyCORE-AM335x SoM
On Tue, Jul 28, 2015 at 10:47:28AM +0200, Teresa Remmet wrote:
> Hello Igor,
>
> Am Dienstag, den 28.07.2015, 11:29 +0300 schrieb Igor Grinberg:
> > Hi Matt,
> >
> > On 07/27/15 17:34, Matt Porter wrote:
> > > On Thu, Jul 16, 2015 at 10:30:48AM +0200, Teresa Remmet wrote:
> > >> phyCORE-AM335x is a SoM (System on Module) containing
> > >> a AM335x SOC. The module can be connected to different
> > >> carrier boards.
> > >>
> > >> Some hardware parts are configurable on the phyCORE-AM335x.
> > >> So they are disabled on default in this som dtsi file.
> > >> They will be enabled in the board dts files, when populated.
> > >>
> > >> * RAM up to 1GiB
> > >> * PMIC
> > >> * NAND flash up to 1GiB
> > >> * Eth PHY on SOM: 1x RMII
> > >> * SPI NOR flash 8MiB (optional)
> > >> * i2c RTC (optional)
> > >> * i2c EEPROM 4kiB (optional)
> > >>
> > >> Signed-off-by: Teresa Remmet
> > >> ---
> > >> arch/arm/boot/dts/am335x-phycore-som.dtsi | 368
> > >> ++
> > >> 1 file changed, 368 insertions(+)
> > >> create mode 100644 arch/arm/boot/dts/am335x-phycore-som.dtsi
> > >>
> > >> diff --git a/arch/arm/boot/dts/am335x-phycore-som.dtsi
> > >> b/arch/arm/boot/dts/am335x-phycore-som.dtsi
> > >> new file mode 100644
> > >> index 000..4d28fc3
> > >> --- /dev/null
> > >> +++ b/arch/arm/boot/dts/am335x-phycore-som.dtsi
> >
> > [...]
> >
> > >> +#include "am33xx.dtsi"
> > >> +
> > >> +/ {
> > >> +model = "Phytec AM335x phyCORE";
> > >> +compatible = "phytec,am335x-phycore-som", "ti,am33xx";
> > >
> > > One minor thing here...wildcards in compatible strings aren't permitted.
> > > However, family compatibles like "ti,am33xx" that came in before this
> > > was enforced are grandfathered. Ideally, the newly introced board/som
> > > specific strings should not propagate that wildcard. i.e. something
> > > like "phytec,am3352-phycore-som" or whatever is the base family part
> > > on these SOMs.
> > >
> >
> > I'm not sure this is wild card.
> > I tend to think that it is the real name of the som [1], no?
> >
> > http://phytec.com/products/system-on-modules/phycore/am335x/
>
> Yes, your right. This is the name of the SoM. The phyCORE may have
> different am335x versions mounted. So there is not the one am3352 or
> am3359 always used.
Ok, great. Disregard then.
-Matt
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ARM: dts: Add support for phyCORE-AM335x SoM
On Thu, Jul 16, 2015 at 10:30:48AM +0200, Teresa Remmet wrote:
> phyCORE-AM335x is a SoM (System on Module) containing
> a AM335x SOC. The module can be connected to different
> carrier boards.
>
> Some hardware parts are configurable on the phyCORE-AM335x.
> So they are disabled on default in this som dtsi file.
> They will be enabled in the board dts files, when populated.
>
> * RAM up to 1GiB
> * PMIC
> * NAND flash up to 1GiB
> * Eth PHY on SOM: 1x RMII
> * SPI NOR flash 8MiB (optional)
> * i2c RTC (optional)
> * i2c EEPROM 4kiB (optional)
>
> Signed-off-by: Teresa Remmet
> ---
> arch/arm/boot/dts/am335x-phycore-som.dtsi | 368
> ++
> 1 file changed, 368 insertions(+)
> create mode 100644 arch/arm/boot/dts/am335x-phycore-som.dtsi
>
> diff --git a/arch/arm/boot/dts/am335x-phycore-som.dtsi
> b/arch/arm/boot/dts/am335x-phycore-som.dtsi
> new file mode 100644
> index 000..4d28fc3
> --- /dev/null
> +++ b/arch/arm/boot/dts/am335x-phycore-som.dtsi
> @@ -0,0 +1,368 @@
> +/*
> + * Copyright (C) 2015 Phytec Messtechnik GmbH
> + * Author: Teresa Remmet
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include "am33xx.dtsi"
> +
> +/ {
> + model = "Phytec AM335x phyCORE";
> + compatible = "phytec,am335x-phycore-som", "ti,am33xx";
One minor thing here...wildcards in compatible strings aren't permitted.
However, family compatibles like "ti,am33xx" that came in before this
was enforced are grandfathered. Ideally, the newly introced board/som
specific strings should not propagate that wildcard. i.e. something
like "phytec,am3352-phycore-som" or whatever is the base family part
on these SOMs.
-Matt
> +
> + aliases {
> + rtc0 = &i2c_rtc;
> + rtc1 = &rtc;
> + };
> +
> + cpus {
> + cpu@0 {
> + cpu0-supply = <&vdd1_reg>;
> + };
> + };
> +
> + memory {
> + device_type = "memory";
> + reg = <0x8000 0x1000>; /* 256 MB */
> + };
> +
> + vbat: fixedregulator@0 {
> + compatible = "regulator-fixed";
> + };
> +};
> +
> +/* Crypto Module */
> +&aes {
> + status = "okay";
> +};
> +
> +&sham {
> + status = "okay";
> +};
> +
> +/* Ethernet */
> +&am33xx_pinmux {
> + ethernet0_pins: pinmux_ethernet0 {
> + pinctrl-single,pins = <
> + 0x10c (PIN_INPUT_PULLDOWN | MUX_MODE1) /*
> mii1_crs.rmii1_crs_dv */
> + 0x110 (PIN_INPUT_PULLDOWN | MUX_MODE1) /*
> mii1_rxerr.rmii1_rxerr */
> + 0x114 (PIN_OUTPUT | MUX_MODE1) /*
> mii1_txen.rmii1_txen */
> + 0x124 (PIN_OUTPUT | MUX_MODE1) /*
> mii1_txd1.rmii1_txd1 */
> + 0x128 (PIN_OUTPUT | MUX_MODE1) /*
> mii1_txd0.rmii1_txd0 */
> + 0x13c (PIN_INPUT_PULLDOWN | MUX_MODE1) /*
> mii1_rxd1.rmii1_rxd1 */
> + 0x140 (PIN_INPUT_PULLDOWN | MUX_MODE1) /*
> mii1_rxd0.rmii1_rxd0 */
> + 0x144 (PIN_INPUT_PULLDOWN | MUX_MODE0) /*
> rmii1_refclk.rmii1_refclk */
> + >;
> + };
> +
> + mdio_pins: pinmux_mdio {
> + pinctrl-single,pins = <
> + /* MDIO */
> + 0x148 (PIN_INPUT_PULLUP | SLEWCTRL_FAST | MUX_MODE0)
> /* mdio_data.mdio_data */
> + 0x14c (PIN_OUTPUT_PULLUP | MUX_MODE0)
> /* mdio_clk.mdio_clk */
> + >;
> + };
> +};
> +
> +&cpsw_emac0 {
> + phy_id = <&davinci_mdio>, <0>;
> + phy-mode = "rmii";
> + dual_emac_res_vlan = <1>;
> +};
> +
> +&davinci_mdio {
> + pinctrl-names = "default";
> + pinctrl-0 = <&mdio_pins>;
> + status = "okay";
> +};
> +
> +&mac {
> + slaves = <1>;
> + pinctrl-names = "default";
> + pinctrl-0 = <ðernet0_pins>;
> + status = "okay";
> +};
> +
> +&phy_sel {
> + rmii-clock-ext;
> +};
> +
> +/* I2C Busses */
> +&am33xx_pinmux {
> + i2c0_pins: pinmux_i2c0 {
> + pinctrl-single,pins = <
> + 0x188 (PIN_INPUT | MUX_MODE0) /* i2c0_sda.i2c0_sda */
> + 0x18c (PIN_INPUT | MUX_MODE0) /* i2c0_scl.i2c0_scl */
> + >;
> + };
> +};
> +
> +&i2c0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&i2c0_pins>;
> + clock-frequency = <40>;
> + status = "okay";
> +
> + tps: pmic@2d {
> + reg = <0x2d>;
> + };
> +
> + i2c_eeprom: eeprom@52 {
> + compatible = "atmel,24c32";
> + pagesize = <32>;
> + reg = <0x52>;
> + status = "disabled";
> + };
> +
> + i2c_rtc: rtc@68 {
> + compatible = "rv4162";
> + reg = <0x68>;
> + status = "disabled";
> + };
> +};
> +
> +/* NAND
Re: [PATCH-v5 4/5] Documentation: binding: add sclk adjustment properties to i2c-pxa
On Tue, Jul 21, 2015 at 06:11:05PM +0530, Vaibhav Hiremath wrote:
> With addition of PXA910 family of devices, the TWSI module supports
> new feature which allows us to adjust SCLK. i2c-pxa driver takes input
> configuration in nsec and converts it to respective bit-fields,
>
> - i2c-sclk-low-time-ns : SCLK low time (tlow)
>This property is used along with mode selection.
> - i2c-sclk-high-time-ns : SCLK high time (thigh)
> - i2c-start-hold-time-ns : Used in case of high speed mode for start bit
>hold/setup wait counter.
> - i2c-stop-hold-time-ns : Used in case of high speed mode for stop bit
>hold/setup wait counter.
> - i2c-sda-hold-time-ns : Used to calculate hold/setup wait counter for
>standard and fast mode.
Again, these should have a mrvl prefix..very specific to this PXA
controller.
-Matt
> Signed-off-by: Vaibhav Hiremath
> ---
> Documentation/devicetree/bindings/i2c/i2c-pxa.txt | 13 +
> 1 file changed, 13 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/i2c/i2c-pxa.txt
> b/Documentation/devicetree/bindings/i2c/i2c-pxa.txt
> index 9657db5..bb4df60 100644
> --- a/Documentation/devicetree/bindings/i2c/i2c-pxa.txt
> +++ b/Documentation/devicetree/bindings/i2c/i2c-pxa.txt
> @@ -23,12 +23,25 @@ Optional properties :
> - i2c-disable-after-xfer : If set, driver will disable I2C module
> after msg xfer and enable it again before xfer.
>
> + (Applicable to PXA910 family):
> +
> + - i2c-sclk-low-time-ns : SCLK low time (tlow), for standard/fast/high
> + speed mode.
> + This property is used along with mode selection. Driver uses this property
> + to set low/high time for standard and fast speed mode, as HW counter
> + bit-field is same for both.
> + - i2c-sclk-high-time-ns : SCLK high time (thigh), Used in case of high speed
> + mode only.
> +
> Examples:
> twsi1: i2c@d4011000 {
> compatible = "mrvl,mmp-twsi";
> reg = <0xd4011000 0x1000>;
> interrupts = <7>;
> mrvl,i2c-fast-mode;
> +
> + i2c-sclk-low-time-ns = <988>;
> + i2c-sclk-high-time-ns = <988>;
> };
>
> twsi2: i2c@d4025000 {
> --
> 1.9.1
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH-v5 1/5] Documentation: binding: add new property 'disable_after_xfer' to i2c-pxa
On Tue, Jul 21, 2015 at 06:11:02PM +0530, Vaibhav Hiremath wrote:
> Driver will now supports enable/disable across msg xfer, which user
> can control it by new DT property -
>
> i2c-disable-after-xfer : If set, driver will disable I2C module after msg
> xfer and enable it back before xfer.
If this is a new property specific to this Marvell part, it needs
the vendor prefix as in mrvl,i2c-disable-after-xfer
Or, it couldn't hurt to start an i2c.txt for generic i2c bindings
and store it there as this and others later in this series would
reasonably apply to other controllers.
-Matt
> Signed-off-by: Vaibhav Hiremath
> ---
> Documentation/devicetree/bindings/i2c/i2c-pxa.txt | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/i2c/i2c-pxa.txt
> b/Documentation/devicetree/bindings/i2c/i2c-pxa.txt
> index 12b78ac..9657db5 100644
> --- a/Documentation/devicetree/bindings/i2c/i2c-pxa.txt
> +++ b/Documentation/devicetree/bindings/i2c/i2c-pxa.txt
> @@ -18,6 +18,11 @@ Recommended properties :
> status register of i2c controller instead.
> - mrvl,i2c-fast-mode : Enable fast mode of i2c controller.
>
> +Optional properties :
> +
> + - i2c-disable-after-xfer : If set, driver will disable I2C module
> + after msg xfer and enable it again before xfer.
> +
> Examples:
> twsi1: i2c@d4011000 {
> compatible = "mrvl,mmp-twsi";
> --
> 1.9.1
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/2] doc: dt: add documentation for nxp,lpc1788-rtc
On Sat, Jul 11, 2015 at 07:28:50PM +0200, Joachim Eastwood wrote:
> Signed-off-by: Joachim Eastwood
> ---
> .../devicetree/bindings/rtc/nxp,lpc1788-rtc.txt | 21
> +
> 1 file changed, 21 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/rtc/nxp,lpc1788-rtc.txt
>
> diff --git a/Documentation/devicetree/bindings/rtc/nxp,lpc1788-rtc.txt
> b/Documentation/devicetree/bindings/rtc/nxp,lpc1788-rtc.txt
> new file mode 100644
> index ..ad41a040432c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/rtc/nxp,lpc1788-rtc.txt
> @@ -0,0 +1,21 @@
> +NXP LPC1788 real-time clock
> +
> +The LPC1788 RTC provides calendar and clock functionality
> +together with periodic tick and alarm interrupt support.
> +
> +Required properties:
> +- compatible : must contain "nxp,lpc1788-rtc"
> +- reg: Specifies base physical address and size of the
> registers.
> +- interrupts : A single interrupt specifier.
> +- clocks : Must contain entries for rtc and register clock
"Must contain clock specifiers for rtc and register clock" ?
-Matt
> +- clock-names: Must contain "rtc" and "reg"
> + See ../clocks/clock-bindings.txt for details.
> +
> +Example:
> +rtc: rtc@40046000 {
> + compatible = "nxp,lpc1788-rtc";
> + reg = <0x40046000 0x1000>;
> + interrupts = <47>;
> + clocks = <&creg_clk 0>, <&ccu1 CLK_CPU_BUS>;
> + clock-names = "rtc", "reg";
> +};
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 05/10] eeprom: Add bindings for simple eeprom framework
On Tue, Apr 07, 2015 at 07:03:30PM +0100, Srinivas Kandagatla wrote: > > > On 07/04/15 18:46, Mark Brown wrote: > >On Tue, Apr 07, 2015 at 06:35:49PM +0100, Srinivas Kandagatla wrote: > >>On 06/04/15 16:04, Matt Porter wrote: > >>>On Mon, Apr 06, 2015 at 09:11:05AM -0500, Rob Herring wrote: > > > >>>>>The generic binding could really use a "read-only" property here as this > >>>>>is a common hardware attribute for many nvmem devices. A serial EEPROM > > > >>Correct me If am wrong. > > > >>Regarding write protection/read-only, regmap already has provisions to > >>support this feature. regmap would bail out with errors if any attempt to > >>write to non-writable regions. It all depends on the data providers how they > >>setup the regmap and the bindings for those are specific individual data > >>providers I think. > > > >There is the ability to flag read/write permissions in regmap but I > >think there's some suggestion that this should be exposed to userspace > >so that it's easier for it to handle things rather than just writing > >then coping with any errors. > > Yes, That's possible if the data provider use the "read-only" generic > binding like MTD partitions which the eeprom framwork could use to set the > binary file mode appropriately. Right, that's what Rob suggested as to how it should be exposed to userspace. I think Mark is suggesting that it can also be done by returning appropriately fine-grained error codes from a writeable attribute. Just to clarify here, I brought this up because if we only allow the writes to fail, there's not necessarily not enough information available to know if they failed due to a real error (perhaps write cycles for the underlying nvmem device have been exhausted) or is it simply that the underlying device has been hardware write protected (such as as the write protect pin hardwired that way or it's an OTP device). The client, whether userspace or otherwise is going to need to know this information to make informed policy decisions. -Matt > "read-only" property seems to be more generic for all types of data > providers. > > I will give it a try and document this in the bindings too in next version. > > --srini > > -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 05/10] eeprom: Add bindings for simple eeprom framework
On Mon, Apr 06, 2015 at 09:11:05AM -0500, Rob Herring wrote: > On Mon, Apr 6, 2015 at 8:32 AM, Matt Porter wrote: > > On Mon, Mar 30, 2015 at 10:57:59PM +0100, Srinivas Kandagatla wrote: > >> This patch adds bindings for simple eeprom framework which allows eeprom > >> consumers to talk to eeprom providers to get access to eeprom cell data. > >> > >> Signed-off-by: Maxime Ripard > >> [Maxime Ripard: intial version of eeprom framework] > >> Signed-off-by: Srinivas Kandagatla > >> --- > >> .../devicetree/bindings/eeprom/eeprom.txt | 58 > >> ++ > >> 1 file changed, 58 insertions(+) > >> create mode 100644 Documentation/devicetree/bindings/eeprom/eeprom.txt > >> > >> diff --git a/Documentation/devicetree/bindings/eeprom/eeprom.txt > >> b/Documentation/devicetree/bindings/eeprom/eeprom.txt > >> new file mode 100644 > >> index 000..fb71d46 > >> --- /dev/null > >> +++ b/Documentation/devicetree/bindings/eeprom/eeprom.txt > >> @@ -0,0 +1,58 @@ > >> += EEPROM Data Device Tree Bindings = > >> + > >> +This binding is intended to represent the location of hardware > >> +configuration data stored in EEPROMs. > >> + > >> +On a significant proportion of boards, the manufacturer has stored > >> +some data on an EEPROM-like device, for the OS to be able to retrieve > >> +these information and act upon it. Obviously, the OS has to know > >> +about where to retrieve these data from, and where they are stored on > >> +the storage device. > > > > Since this binding (and the kernel framework supporting it) describes > > non-volatile memory devices other than EEPROMs (e.g. EFuses) it should > > be named more generically like "nvmem". > > > >> + > >> +This document is here to document this. > >> + > >> += Data providers = > >> +Contains bindings specific to provider drivers and data cells as children > >> +to this node. > >> + > >> += Data cells = > >> +These are the child nodes of the provider which contain data cell > >> +information like offset and size in eeprom provider. > >> + > >> +Required properties: > >> +reg: specifies the offset in byte within that storage device, and the > >> length > >> + in bytes of the data we care about. > >> + There could be more then one offset-length pairs in this property. > >> + > >> +Optional properties: > >> +As required by specific data parsers/interpreters. > > > > The generic binding could really use a "read-only" property here as this > > is a common hardware attribute for many nvmem devices. A serial EEPROM > > commonly has a write protect pin which may be hard-wired such that the > > hardware description should reflect that. An EFuse is typically blown with > > the required information at manufacturing time (for an end product case) > > and would be marked with the "read-only" flag. > > > > Having this optional flag in the generic binding would allow the > > framework to hint to consumers about the inability to write to the > > provided region. > > This could get fairly complex if you wanted to describe grouping of WP > regions which could have different layout than the fields here. This > may be better left as a device property listing addr & size pairs. > However, there is the notion of s/w "read-only" which means the OS > should not allow write access. The MTD partition binding supports this > with the "read-only" property. Yes, if the backing device has the capability to hw write protect regions the exported fields overlap those then it does get ugly. The MTD partition property was the inspiration here so perhaps it's best to term this as a property indicating how the data region is used in an implementation. If it's left as a device property, then a binding with this property would need to be defined for the Efuse, etc. cases..or a simple-nvmem binding to handle the various OTP technologies. > > The framework sysfs attributes provide a userspace EEPROM consumer where > > it would be useful information to know that a data provider region is > > read only rather than having the exported writeable attribute simply > > fail a write cycle. This would allow the consumer to be aware that a > > failed write (if even attempted) is expected if the data provider > > advertised itself as read-only. > > You could distinguish with RW versus RO file attributes. Right, that would be preferred, based on the what the data provider advertises. -Matt -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/2] dt-bindings: Document the hi6220 thermal sensor bindings
On Tue, Mar 31, 2015 at 02:59:21PM +0800, Xinwei Kong wrote:
> From: kongxinwei
>
> This adds documentation of device tree bindings for the
> thermal sensor controller of hi6220 SoC.
>
> Signed-off-by: Leo Yan
> Signed-off-by: kongxinwei
> ---
> .../bindings/thermal/hisilicon-thermal.txt | 45
> ++
> 1 file changed, 45 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/thermal/hisilicon-thermal.txt
>
> diff --git a/Documentation/devicetree/bindings/thermal/hisilicon-thermal.txt
> b/Documentation/devicetree/bindings/thermal/hisilicon-thermal.txt
> new file mode 100644
> index 000..ceb6e2e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/thermal/hisilicon-thermal.txt
> @@ -0,0 +1,45 @@
> +* Hisilicon Thermal
> +
> +This driver is for hi6220 SoC which contain 4 thermal sensor.
> +
> + 1. sensor 0: local sensor;
> + 2. sensor 1: remote sensor for ACPU cluster 1;
> + 3. sensor 2: remote sensor for ACPU cluster 2;
> + 4. sensor 3: remote sensor for GPU.
> +
> +Every sensor use one child node to represent it, so thermal sensor include
> +parent node and four child node. The parent node describe common feature and
> +child node describe private feature for thermal sensor;
> +
> +** Required properties :
> +
> +- compatible: "hisilicon,tsensor".
> +- reg: physical base address of thermal sensor and length of memory mapped
> + region.
> +- interrupt: The interrupt number to the cpu. Defines the interrupt used
> + by SOCTHERM.
> +- clock-names: Input clock name, should be 'thermal_clk'.
> +- clocks: phandles for clock specified in "clock-names" property.
> +- #thermal-sensor-cells: Should be 1. See ./thermal.txt for a description.
> +
> +** Required properties for child nodes :
> +
> +- hisilicon,tsensor-id: the index of thermal sensor and use it to distinguish
> + thermal sensor. For example: <0> stands for local sensor; <1> stands for
> + acpu1 sensor;
Please show an example illustrating why this property is needed. The
example below doesn't show any per sensor properties aside from the
sensor id. Other bindings with a similar sub-sensor hardware design like
tegra-soctherm and rockchip-thermal don't have a need for a vendor
specific property like this. Their drivers simply iterate over an id
index during thermal sensor registration.
-Matt
> +
> +Example :
> +
> + tsensor: tsensor@0,f7030700 {
> + compatible = "hisilicon,tsensor";
> + reg = <0x0 0xf7030700 0x0 0x1000>;
> + interrupts = <0 7 0x4>;
> + clocks = <&clock_sys HI6220_TSENSOR_CLK>;
> + clock-names = "thermal_clk";
> + #thermal-sensor-cells = <1>;
> +
> + local_sensor {
> + hisilicon,tsensor-id = <0>;
> + }
> + ...
> + }
> --
> 1.9.1
>
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 05/10] eeprom: Add bindings for simple eeprom framework
On Mon, Mar 30, 2015 at 10:57:59PM +0100, Srinivas Kandagatla wrote:
> This patch adds bindings for simple eeprom framework which allows eeprom
> consumers to talk to eeprom providers to get access to eeprom cell data.
>
> Signed-off-by: Maxime Ripard
> [Maxime Ripard: intial version of eeprom framework]
> Signed-off-by: Srinivas Kandagatla
> ---
> .../devicetree/bindings/eeprom/eeprom.txt | 58
> ++
> 1 file changed, 58 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/eeprom/eeprom.txt
>
> diff --git a/Documentation/devicetree/bindings/eeprom/eeprom.txt
> b/Documentation/devicetree/bindings/eeprom/eeprom.txt
> new file mode 100644
> index 000..fb71d46
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/eeprom/eeprom.txt
> @@ -0,0 +1,58 @@
> += EEPROM Data Device Tree Bindings =
> +
> +This binding is intended to represent the location of hardware
> +configuration data stored in EEPROMs.
> +
> +On a significant proportion of boards, the manufacturer has stored
> +some data on an EEPROM-like device, for the OS to be able to retrieve
> +these information and act upon it. Obviously, the OS has to know
> +about where to retrieve these data from, and where they are stored on
> +the storage device.
Since this binding (and the kernel framework supporting it) describes
non-volatile memory devices other than EEPROMs (e.g. EFuses) it should
be named more generically like "nvmem".
> +
> +This document is here to document this.
> +
> += Data providers =
> +Contains bindings specific to provider drivers and data cells as children
> +to this node.
> +
> += Data cells =
> +These are the child nodes of the provider which contain data cell
> +information like offset and size in eeprom provider.
> +
> +Required properties:
> +reg: specifies the offset in byte within that storage device, and the length
> + in bytes of the data we care about.
> + There could be more then one offset-length pairs in this property.
> +
> +Optional properties:
> +As required by specific data parsers/interpreters.
The generic binding could really use a "read-only" property here as this
is a common hardware attribute for many nvmem devices. A serial EEPROM
commonly has a write protect pin which may be hard-wired such that the
hardware description should reflect that. An EFuse is typically blown with
the required information at manufacturing time (for an end product case)
and would be marked with the "read-only" flag.
Having this optional flag in the generic binding would allow the
framework to hint to consumers about the inability to write to the
provided region.
The framework sysfs attributes provide a userspace EEPROM consumer where
it would be useful information to know that a data provider region is
read only rather than having the exported writeable attribute simply
fail a write cycle. This would allow the consumer to be aware that a
failed write (if even attempted) is expected if the data provider
advertised itself as read-only.
-Matt
> +
> +For example:
> +
> + /* Provider */
> + qfprom: qfprom@0070 {
> + compatible = "qcom,qfprom";
> + reg = <0x0070 0x8000>;
> + ...
> +
> + /* Data cells */
> + tsens_calibration: calib@4404 {
> + reg = <0x4404 0x10>;
> + };
> +
> + serial_number: sn {
> + reg = <0x104 0x4>, <0x204 0x4>, <0x30c 0x4>;
> +
> + };
> + ...
> + };
> +
> += Data consumers =
> +Are device nodes which consume eeprom data cells.
> +
> +For example:
> +
> + tsens {
> + ...
> + calibration = <&tsens_calibration>;
> + };
> --
> 1.9.1
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] pwm: imx-pwm: add explicit compatible strings and required clock properties
The imx-pwm binding contains language indicating compatible
strings to be used that is not valid for all supported parts
e.g. Should be "fsl,-pwm". Fix this by enumerating the
valid compatible strings that represent the two versions of
this peripheral in use.
The binding is also missing the clocks/clock-names properties
so document these,the two required ipg and per clocks, and add
add these properties to the example.
Signed-off-by: Matt Porter
---
Changes since v1:
- compatible strings include the actual soc and one of the two specific
compatible parts.
Documentation/devicetree/bindings/pwm/imx-pwm.txt | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/pwm/imx-pwm.txt
b/Documentation/devicetree/bindings/pwm/imx-pwm.txt
index b50d7a6d..e00c2e9 100644
--- a/Documentation/devicetree/bindings/pwm/imx-pwm.txt
+++ b/Documentation/devicetree/bindings/pwm/imx-pwm.txt
@@ -1,10 +1,17 @@
Freescale i.MX PWM controller
Required properties:
-- compatible: should be "fsl,-pwm"
+- compatible : should be "fsl,-pwm" and one of the following
+ compatible strings:
+ - "fsl,imx1-pwm" for PWM compatible with the one integrated on i.MX1
+ - "fsl,imx27-pwm" for PWM compatible with the one integrated on i.MX27
- reg: physical base address and length of the controller's registers
- #pwm-cells: should be 2. See pwm.txt in this directory for a description of
the cells format.
+- clocks : Clock specifiers for both ipg and per clocks.
+- clock-names : Clock names should include both "ipg" and "per"
+See the clock consumer binding,
+ Documentation/devicetree/bindings/clock/clock-bindings.txt
- interrupts: The interrupt for the pwm controller
Example:
@@ -13,5 +20,8 @@ pwm1: pwm@53fb4000 {
#pwm-cells = <2>;
compatible = "fsl,imx53-pwm", "fsl,imx27-pwm";
reg = <0x53fb4000 0x4000>;
+ clocks = <&clks IMX5_CLK_PWM1_IPG_GATE>,
+<&clks IMX5_CLK_PWM1_HF_GATE>;
+ clock-names = "ipg", "per";
interrupts = <61>;
};
--
1.8.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] pwm: imx-pwm: add explicit compatible strings and required clock properties
On Fri, Mar 06, 2015 at 09:16:44AM -0600, Rob Herring wrote:
> On Fri, Mar 6, 2015 at 9:09 AM, Matt Porter wrote:
> > The imx-pwm binding contains language indicating compatible
> > strings to be used that is not valid for all supported parts
> > e.g. Should be "fsl,-pwm". Fix this by enumerating the
> > valid compatible strings that represent the two versions of
> > this peripheral in use.
> >
> > The binding is also missing the clocks/clock-names properties
> > so document these,the two required ipg and per clocks, and add
> > add these properties to the example.
> >
> > Signed-off-by: Matt Porter
> > ---
> > Documentation/devicetree/bindings/pwm/imx-pwm.txt | 11 ++-
> > 1 file changed, 10 insertions(+), 1 deletion(-)
> >
> > diff --git a/Documentation/devicetree/bindings/pwm/imx-pwm.txt
> > b/Documentation/devicetree/bindings/pwm/imx-pwm.txt
> > index b50d7a6d..30d2b82 100644
> > --- a/Documentation/devicetree/bindings/pwm/imx-pwm.txt
> > +++ b/Documentation/devicetree/bindings/pwm/imx-pwm.txt
> > @@ -1,10 +1,16 @@
> > Freescale i.MX PWM controller
> >
> > Required properties:
> > -- compatible: should be "fsl,-pwm"
> > +- compatible :
> > + - "fsl,imx1-pwm" for PWM compatible with the one integrated on i.MX1
> > + - "fsl,imx27-pwm" for PWM compatible with the one integrated on i.MX27
>
> This should be one of these and a more specific value as the example
> below shows.
Ok, yes, I wasn't sure if that was expected to be explicit in the bindings
or not as others don't seem to represent that properly. What about this?
- compatible: should be "fsl,-pwm" and one of the following
compatible strings:
"fsl,imx1-pwm" for an iMX1 compatible PWM
"fsl,imx27-pwm" for an iMX27 compatible PWM
> > - reg: physical base address and length of the controller's registers
> > - #pwm-cells: should be 2. See pwm.txt in this directory for a description
> > of
> >the cells format.
> > +- clocks : Clock specifiers for both ipg and per clocks.
> > +- clock-names : Clock names should include both "ipg" and "per"
> > +See the clock consumer binding,
> > + Documentation/devicetree/bindings/clock/clock-bindings.txt
> > - interrupts: The interrupt for the pwm controller
> >
> > Example:
> > @@ -13,5 +19,8 @@ pwm1: pwm@53fb4000 {
> > #pwm-cells = <2>;
> > compatible = "fsl,imx53-pwm", "fsl,imx27-pwm";
> > reg = <0x53fb4000 0x4000>;
> > + clocks = <&clks IMX5_CLK_PWM1_IPG_GATE>,
> > +<&clks IMX5_CLK_PWM1_HF_GATE>;
> > + clock-names = "ipg", "per";
> > interrupts = <61>;
> > };
> > --
> > 1.8.4
> >
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH RESEND] serial: omap_serial: document missing properties and add an example
The omap_serial.txt binding documentation lacks a number of properties
that are used in DTS files for platforms incorporating this peripheral.
Fix this by documenting the missing required and optional fields and
add an example.
Signed-off-by: Matt Porter
---
.../devicetree/bindings/serial/omap_serial.txt | 20
1 file changed, 20 insertions(+)
diff --git a/Documentation/devicetree/bindings/serial/omap_serial.txt
b/Documentation/devicetree/bindings/serial/omap_serial.txt
index 342eedd..54c2a15 100644
--- a/Documentation/devicetree/bindings/serial/omap_serial.txt
+++ b/Documentation/devicetree/bindings/serial/omap_serial.txt
@@ -4,7 +4,27 @@ Required properties:
- compatible : should be "ti,omap2-uart" for OMAP2 controllers
- compatible : should be "ti,omap3-uart" for OMAP3 controllers
- compatible : should be "ti,omap4-uart" for OMAP4 controllers
+- reg : address and length of the register space
+- interrupts or interrupts-extended : Should contain the uart interrupt
+ specifier or both the interrupt
+ controller phandle and interrupt
+ specifier.
- ti,hwmods : Must be "uart", n being the instance number (1-based)
Optional properties:
- clock-frequency : frequency of the clock input to the UART
+- dmas : DMA specifier, consisting of a phandle to the DMA controller
+ node and a DMA channel number.
+- dma-names : "rx" for receive channel, "tx" for transmit channel.
+
+Example:
+
+uart4: serial@49042000 {
+compatible = "ti,omap3-uart";
+reg = <0x49042000 0x400>;
+interrupts = <80>;
+dmas = <&sdma 81 &sdma 82>;
+dma-names = "tx", "rx";
+ti,hwmods = "uart4";
+clock-frequency = <4800>;
+};
--
1.8.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] pwm: imx-pwm: add explicit compatible strings and required clock properties
The imx-pwm binding contains language indicating compatible
strings to be used that is not valid for all supported parts
e.g. Should be "fsl,-pwm". Fix this by enumerating the
valid compatible strings that represent the two versions of
this peripheral in use.
The binding is also missing the clocks/clock-names properties
so document these,the two required ipg and per clocks, and add
add these properties to the example.
Signed-off-by: Matt Porter
---
Documentation/devicetree/bindings/pwm/imx-pwm.txt | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/pwm/imx-pwm.txt
b/Documentation/devicetree/bindings/pwm/imx-pwm.txt
index b50d7a6d..30d2b82 100644
--- a/Documentation/devicetree/bindings/pwm/imx-pwm.txt
+++ b/Documentation/devicetree/bindings/pwm/imx-pwm.txt
@@ -1,10 +1,16 @@
Freescale i.MX PWM controller
Required properties:
-- compatible: should be "fsl,-pwm"
+- compatible :
+ - "fsl,imx1-pwm" for PWM compatible with the one integrated on i.MX1
+ - "fsl,imx27-pwm" for PWM compatible with the one integrated on i.MX27
- reg: physical base address and length of the controller's registers
- #pwm-cells: should be 2. See pwm.txt in this directory for a description of
the cells format.
+- clocks : Clock specifiers for both ipg and per clocks.
+- clock-names : Clock names should include both "ipg" and "per"
+See the clock consumer binding,
+ Documentation/devicetree/bindings/clock/clock-bindings.txt
- interrupts: The interrupt for the pwm controller
Example:
@@ -13,5 +19,8 @@ pwm1: pwm@53fb4000 {
#pwm-cells = <2>;
compatible = "fsl,imx53-pwm", "fsl,imx27-pwm";
reg = <0x53fb4000 0x4000>;
+ clocks = <&clks IMX5_CLK_PWM1_IPG_GATE>,
+<&clks IMX5_CLK_PWM1_HF_GATE>;
+ clock-names = "ipg", "per";
interrupts = <61>;
};
--
1.8.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] dt: submitting-patches: clarify that DT maintainers are to be cced on bindings
The exact steps provided for submitting binding patches can be read as requiring the bindings to be sent only to the devicetree@vger.kernel.org list. Since the DT maintainers would like to be Cced on any binding submissions, make this requirement explicit in step 2. Signed-off-by: Matt Porter --- Documentation/devicetree/bindings/submitting-patches.txt | 3 +++ 1 file changed, 3 insertions(+) diff --git a/Documentation/devicetree/bindings/submitting-patches.txt b/Documentation/devicetree/bindings/submitting-patches.txt index 56742bc..7d44eae 100644 --- a/Documentation/devicetree/bindings/submitting-patches.txt +++ b/Documentation/devicetree/bindings/submitting-patches.txt @@ -12,6 +12,9 @@ I. For patch submitters devicetree@vger.kernel.org + and Cc: the DT maintainers. Use scripts/get_maintainer.pl to identify + all of the DT maintainers. + 3) The Documentation/ portion of the patch should come in the series before the code implementing the binding. -- 1.8.4 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] dt: spi: fsl-imx-cspi: add explicit compatible strings and required clock properties
The fsl-imx-cspi binding contains language indicating compatible strings to be used that is not valid for all supported parts e.g. Should be "fsl,-cspi" or "fsl,-ecspi". Fix this by enumerating the set of valid compatible strings. The binding is also missing the clocks/clock-names properties so document these and the two required ipg and per clocks. Signed-off-by: Matt Porter --- Documentation/devicetree/bindings/spi/fsl-imx-cspi.txt | 12 +++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/spi/fsl-imx-cspi.txt b/Documentation/devicetree/bindings/spi/fsl-imx-cspi.txt index aad527b..523341a 100644 --- a/Documentation/devicetree/bindings/spi/fsl-imx-cspi.txt +++ b/Documentation/devicetree/bindings/spi/fsl-imx-cspi.txt @@ -2,11 +2,21 @@ (CSPI/eCSPI) for i.MX Required properties: -- compatible : Should be "fsl,-cspi" or "fsl,-ecspi" +- compatible : + - "fsl,imx1-cspi" for SPI compatible with the one integrated on i.MX1 + - "fsl,imx21-cspi" for SPI compatible with the one integrated on i.MX21 + - "fsl,imx27-cspi" for SPI compatible with the one integrated on i.MX27 + - "fsl,imx31-cspi" for SPI compatible with the one integrated on i.MX31 + - "fsl,imx35-cspi" for SPI compatible with the one integrated on i.MX35 + - "fsl,imx51-ecspi" for SPI compatible with the one integrated on i.MX51 - reg : Offset and length of the register set for the device - interrupts : Should contain CSPI/eCSPI interrupt - fsl,spi-num-chipselects : Contains the number of the chipselect - cs-gpios : Specifies the gpio pins to be used for chipselects. +- clocks : Clock specifiers for both ipg and per clocks. +- clock-names : Clock names should include both "ipg" and "per" +See the clock consumer binding, + Documentation/devicetree/bindings/clock/clock-bindings.txt - dmas: DMA specifiers for tx and rx dma. See the DMA client binding, Documentation/devicetree/bindings/dma/dma.txt - dma-names: DMA request names should include "tx" and "rx" if present. -- 1.8.4 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] i2c: imx: add required clocks property to binding
A clock specifier is required for i.MX I2C and is provided in all DTS implementations. Add this to the list of required properties in the binding. Signed-off-by: Matt Porter --- Documentation/devicetree/bindings/i2c/i2c-imx.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/i2c/i2c-imx.txt b/Documentation/devicetree/bindings/i2c/i2c-imx.txt index 52d37fd..ce4311d 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-imx.txt +++ b/Documentation/devicetree/bindings/i2c/i2c-imx.txt @@ -7,6 +7,7 @@ Required properties: - "fsl,vf610-i2c" for I2C compatible with the one integrated on Vybrid vf610 SoC - reg : Should contain I2C/HS-I2C registers location and length - interrupts : Should contain I2C/HS-I2C interrupt +- clocks : Should contain the I2C/HS-I2C clock specifier Optional properties: - clock-frequency : Constains desired I2C/HS-I2C bus clock frequency in Hz. -- 1.8.4 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: imx: Add dr_mode host setting to all host-only usb instances
On Tue, Mar 03, 2015 at 12:43:36PM +0800, Peter Chen wrote: > On Tue, Mar 03, 2015 at 11:41:35AM +0800, Shawn Guo wrote: > > > > On Fri, Feb 27, 2015 at 09:06:00AM -0500, Matt Porter wrote: > > > The chipidea driver adds an extra line of spam to the log when a > > > host-only chipidea instance is left set to the default of a dual role > > > controller. > > > > > > [2.010873] ci_hdrc ci_hdrc.1: doesn't support gadget > > > > > > Set the dr_mode property to host on all the host-only nodes > > > to avoid this warning. > > It is not an warning, it is dev_info. True enough, it's info level but is essentially warning that, in the case of instances that are restricted to host only (at the SoC level), that the DT hardware description is incorrect. Yes, it's benign, but if the dtsi is corrected for those parts we don't have to see that message. > In fact, imx28, imx6sl and imx6sx's second controller is dual-role > controller, we only set dr_mode at board's dts according to design > unless the controller's capability register is incorrect. The patch doesn't set dr_mode to host on the second controller for the imx6sl or imx6sx, only on the third host-only controller. If imx28's second controller is really dual-role capable then the reference manual is incorrect and I can drop that hunk in v2. I only have imx6q and imx6d parts in hand to verify so for the rest I went by the RM claim of which controllers were host-only. > So, sorry, I don't think this change is necessary. I can correct the set of instances that should have dr_mode set to host in v2 of this. We clearly have some that should have this set in their SoC .dtsi to have the hardware description correct. Will that work for you or do you want the SoC-specific cases of this property to be only reflected in the board level dts? -Matt -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: hummingboard: enable pcf8523 rtc for i2eX
On Mon, Mar 02, 2015 at 08:43:26PM +, Russell King wrote: > On Mon, Mar 02, 2015 at 03:25:40PM -0500, Matt Porter wrote: > > On Mon, Mar 02, 2015 at 07:49:08PM +, Russell King wrote: > > > It's a bit like the MMC stuff, I'm still carrying Olof's solution for > > > the SDIO wifi/bt power and reset control stuff, and I'm not at present > > > intending to do anything with it other than continue forward-porting it. > > > I'm not interested in wasting free time trying to re-work that to suit > > > some other solution, especially as people couldn't settle on a solution > > > when I /did/ have an interest in it (not that I have much interest in > > > wifi or BT - I tend to prefer old fashioned wired connections. It also > > > doesn't help that the Broadcom driver seemed to be very flakey with > > > brcm4329 hardware for quite some time.) > > > > > > Anyway, you can find all my kernel patches in a suitably trimmed version > > > of the above URL, and on http://ftp.arm.linux.org.uk/cgit/ is a huge pile > > > of effort I put into an accelerated X server with etnaviv and /my/ kernel > > > version of etnaviv drm, complete with Xv support. > > > > Excellent, so I feel like you ultimately giving me mixed messages here. > > Yes, I am - partly because I don't know what to do with many of the > patches I seem to be endlessly carrying (which depresses me). I look > back to the days when I could be sure of completely emptying my tree > at each merge window, something which /never/ happens anymore. > > > You said you need to take care of this licensing issue and I think you > > implied you'd take care of the audio and rtc stuff as you have that > > patch in your backlog. > > As you may have seen, I've mailed out the licensing patch, and I've > also mailed out two patches - one for PWM stuff and the second one > being the RTC change broken out from my sgtl5000 hacks patch. > > I've also cut a v4.0-rc1 patch set, in the usual diff.bz2, tar.bz2, > and separate patch forms which include those three patches. Ok, caught up on those now, thanks. > > However, sounds like you've given up on pushing > > the bigger things upstream given the problem with getting agreement > > on those pieces. Are you just going to be submitting the > > less controversial portions like the audio and dts updates? My goal for > > HB initially is just to have all the low-hanging fruit (like rtc and audio) > > working on mainline...besides the stuff that's already there. > > RTC is the easiest bit of the problem, as you've discovered it's just > a matter of uncommenting the bit in DT. (It's even better if you have > a battery to plug into the little connector!) > > Audio needs more than just DT changes, and there's recently been some > SGTL5000 patches submitted which change the way power is controlled > in the SGTL5000. I don't yet know whether those patches solve the > problems I was seeing with the kernel powering down the SGTL5000's > internal regulator, thereby making the device totally inaccessible > until the next power cycle or not. Ok, I'll take a look at those here. > Whether I'll get a chance to look at that this week or not, I don't > know... (see my privately shared G+ status from yesterday, which > people in my G+ circles should be able to see.) Aha, ok, I only saw your last public mention of the 4.0-rc1 breakage on the ethernet clock. Now I know why. -Matt -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: hummingboard: enable pcf8523 rtc for i2eX
On Mon, Mar 02, 2015 at 07:49:08PM +, Russell King wrote: > On Mon, Mar 02, 2015 at 02:21:16PM -0500, Matt Porter wrote: > > [added Rabeeh] > > > > On Mon, Mar 02, 2015 at 07:06:16PM +, Russell King wrote: > > > On Mon, Mar 02, 2015 at 07:02:04PM +, Russell King - ARM Linux wrote: > > > > On Mon, Mar 02, 2015 at 01:50:06PM -0500, Matt Porter wrote: > > > > > The PCF8523 RTC is populated on the i2eX boards so > > > > > enable the i2c1 controller and enable the device on > > > > > that bus. > > > > > > > > Hmm, I wonder where my update patches went... oh, they're still sitting > > > > in my excessive backlog of patches in my tree as part of my "sgtl5000 > > > > hacks" patch... > > > > > > Also note that before we accept patches to the SolidRun stuff, we should > > > first re-license the file as GPLv2/X11. > > > > Hi Russell, > > > > Given that there's no license information at all on any of these three > > dts files I think that's a good idea. I just realized I didn't copy > > Rabeeh on this and he's apparently the original submitter based on > > your work. Ideally Rabeeh should send a license update but I could do > > so if you'd like and gather some acks. > > It's more up to me, as I ended up being the initial author of the > mainline files - and if you look at: > > http://www.home.arm.linux.org.uk/~rmk/cubox/hummingboard-cubox-i-v3.16-rc2-20140624/0041-sgtl5000-hacks.patch > > you'll see the patch I refer to above, which is my own work, and it's > hardly changed to the 3.18 patch: > > http://www.home.arm.linux.org.uk/~rmk/cubox/hummingboard-cubox-i-v3.18-20141216/0113-sgtl5000-hacks.patch Ok > > OTOH, did you already have a license update somewhere in your backlog > > of patches? > > Well, I do now. :) Ok :) > I had dropped the ball on a load of kernel stuff as it seemed to be going > nowhere, no one seemed interested in it, and my massive backlog of patches > (especially things like the ethernet driver) just became far too difficult > both to merge into mainline and to keep forward-porting. Understood, I recall that thread but didn't have the hardware back then. ;) > In any case, anyone who is serious about using the SolidRun hardware runs > Jon Nettleton's fully featured kernel (which is the basis for SR's kernel) > - sadly something which mainline likely is never going to be. Right, I also make use of that kernel, of course. It's just too old to make me completely happy. > It's a bit like the MMC stuff, I'm still carrying Olof's solution for > the SDIO wifi/bt power and reset control stuff, and I'm not at present > intending to do anything with it other than continue forward-porting it. > I'm not interested in wasting free time trying to re-work that to suit > some other solution, especially as people couldn't settle on a solution > when I /did/ have an interest in it (not that I have much interest in > wifi or BT - I tend to prefer old fashioned wired connections. It also > doesn't help that the Broadcom driver seemed to be very flakey with > brcm4329 hardware for quite some time.) > > Anyway, you can find all my kernel patches in a suitably trimmed version > of the above URL, and on http://ftp.arm.linux.org.uk/cgit/ is a huge pile > of effort I put into an accelerated X server with etnaviv and /my/ kernel > version of etnaviv drm, complete with Xv support. Excellent, so I feel like you ultimately giving me mixed messages here. You said you need to take care of this licensing issue and I think you implied you'd take care of the audio and rtc stuff as you have that patch in your backlog. However, sounds like you've given up on pushing the bigger things upstream given the problem with getting agreement on those pieces. Are you just going to be submitting the less controversial portions like the audio and dts updates? My goal for HB initially is just to have all the low-hanging fruit (like rtc and audio) working on mainline...besides the stuff that's already there. Hrm, I also don't care about WiFi/BT on this board, I also prefer wired, but on a custom board I'll have to support a different WiFi/BT vendor so I'll take a look at that reset solution you are carrying. Thanks, Matt -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: hummingboard: enable pcf8523 rtc for i2eX
[added Rabeeh] On Mon, Mar 02, 2015 at 07:06:16PM +, Russell King wrote: > On Mon, Mar 02, 2015 at 07:02:04PM +, Russell King - ARM Linux wrote: > > On Mon, Mar 02, 2015 at 01:50:06PM -0500, Matt Porter wrote: > > > The PCF8523 RTC is populated on the i2eX boards so > > > enable the i2c1 controller and enable the device on > > > that bus. > > > > Hmm, I wonder where my update patches went... oh, they're still sitting > > in my excessive backlog of patches in my tree as part of my "sgtl5000 > > hacks" patch... > > Also note that before we accept patches to the SolidRun stuff, we should > first re-license the file as GPLv2/X11. Hi Russell, Given that there's no license information at all on any of these three dts files I think that's a good idea. I just realized I didn't copy Rabeeh on this and he's apparently the original submitter based on your work. Ideally Rabeeh should send a license update but I could do so if you'd like and gather some acks. OTOH, did you already have a license update somewhere in your backlog of patches? -Matt -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: dts: hummingboard: enable pcf8523 rtc for i2eX
The PCF8523 RTC is populated on the i2eX boards so
enable the i2c1 controller and enable the device on
that bus.
Signed-off-by: Matt Porter
---
arch/arm/boot/dts/imx6qdl-hummingboard.dtsi | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/imx6qdl-hummingboard.dtsi
b/arch/arm/boot/dts/imx6qdl-hummingboard.dtsi
index 62841e8..38ebba9 100644
--- a/arch/arm/boot/dts/imx6qdl-hummingboard.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-hummingboard.dtsi
@@ -73,18 +73,15 @@
};
&i2c1 {
+ clock-frequency = <40>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_hummingboard_i2c1>;
-
- /*
-* Not fitted on Carrier-1 board... yet
status = "okay";
rtc: pcf8523@68 {
compatible = "nxp,pcf8523";
reg = <0x68>;
};
-*/
};
&i2c2 {
--
1.8.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: dts: imx: Add dr_mode host setting to all host-only usb instances
The chipidea driver adds an extra line of spam to the log when a host-only chipidea instance is left set to the default of a dual role controller. [2.010873] ci_hdrc ci_hdrc.1: doesn't support gadget Set the dr_mode property to host on all the host-only nodes to avoid this warning. Signed-off-by: Matt Porter --- arch/arm/boot/dts/imx27.dtsi | 2 ++ arch/arm/boot/dts/imx28.dtsi | 1 + arch/arm/boot/dts/imx35.dtsi | 1 + arch/arm/boot/dts/imx50.dtsi | 3 +++ arch/arm/boot/dts/imx51.dtsi | 3 +++ arch/arm/boot/dts/imx53.dtsi | 3 +++ arch/arm/boot/dts/imx6qdl.dtsi | 3 +++ arch/arm/boot/dts/imx6sl.dtsi | 1 + arch/arm/boot/dts/imx6sx.dtsi | 1 + 9 files changed, 18 insertions(+) diff --git a/arch/arm/boot/dts/imx27.dtsi b/arch/arm/boot/dts/imx27.dtsi index 4b063b6..6951b66 100644 --- a/arch/arm/boot/dts/imx27.dtsi +++ b/arch/arm/boot/dts/imx27.dtsi @@ -488,6 +488,7 @@ interrupts = <54>; clocks = <&clks IMX27_CLK_USB_IPG_GATE>; fsl,usbmisc = <&usbmisc 1>; + dr_mode = "host"; status = "disabled"; }; @@ -497,6 +498,7 @@ interrupts = <55>; clocks = <&clks IMX27_CLK_USB_IPG_GATE>; fsl,usbmisc = <&usbmisc 2>; + dr_mode = "host"; status = "disabled"; }; diff --git a/arch/arm/boot/dts/imx28.dtsi b/arch/arm/boot/dts/imx28.dtsi index 47f68ac..02330f4 100644 --- a/arch/arm/boot/dts/imx28.dtsi +++ b/arch/arm/boot/dts/imx28.dtsi @@ -1197,6 +1197,7 @@ interrupts = <92>; clocks = <&clks 61>; fsl,usbphy = <&usbphy1>; + dr_mode = "host"; status = "disabled"; }; diff --git a/arch/arm/boot/dts/imx35.dtsi b/arch/arm/boot/dts/imx35.dtsi index 6932928..b6478e9 100644 --- a/arch/arm/boot/dts/imx35.dtsi +++ b/arch/arm/boot/dts/imx35.dtsi @@ -318,6 +318,7 @@ clocks = <&clks 73>; fsl,usbmisc = <&usbmisc 1>; fsl,usbphy = <&usbphy1>; + dr_mode = "host"; status = "disabled"; }; diff --git a/arch/arm/boot/dts/imx50.dtsi b/arch/arm/boot/dts/imx50.dtsi index 620b0f0..e245713 100644 --- a/arch/arm/boot/dts/imx50.dtsi +++ b/arch/arm/boot/dts/imx50.dtsi @@ -197,6 +197,7 @@ reg = <0x53f80200 0x0200>; interrupts = <14>; clocks = <&clks IMX5_CLK_USB_PHY2_GATE>; + dr_mode = "host"; status = "disabled"; }; @@ -205,6 +206,7 @@ reg = <0x53f80400 0x0200>; interrupts = <16>; clocks = <&clks IMX5_CLK_USBOH3_GATE>; + dr_mode = "host"; status = "disabled"; }; @@ -213,6 +215,7 @@ reg = <0x53f80600 0x0200>; interrupts = <17>; clocks = <&clks IMX5_CLK_USBOH3_GATE>; + dr_mode = "host"; status = "disabled"; }; diff --git a/arch/arm/boot/dts/imx51.dtsi b/arch/arm/boot/dts/imx51.dtsi index c0116cf..f46fe9b 100644 --- a/arch/arm/boot/dts/imx51.dtsi +++ b/arch/arm/boot/dts/imx51.dtsi @@ -265,6 +265,7 @@ interrupts = <14>; clocks = <&clks IMX5_CLK_USBOH3_GATE>; fsl,usbmisc = <&usbmisc 1>; + dr_mode = "host"; status = "disabled"; }; @@ -274,6 +275,7 @@ interrupts = <16>; clocks = <&clks IMX5_CLK_USBOH3_GATE>; fsl,usbmisc = <&usbmisc 2>; + dr_mode = "host"; status = "disabled"; }; @@ -283,6 +285,7 @@ interrupts = <17>;
[PATCH] Documentation: DT: omap_serial: document missing properties and add an example
The omap_serial.txt binding documentation lacks a number of properties
that are used in DTS files for platforms incorporating this peripheral.
Fix this by documenting the missing required and optional fields and
add an example.
Signed-off-by: Matt Porter
---
.../devicetree/bindings/serial/omap_serial.txt | 20
1 file changed, 20 insertions(+)
diff --git a/Documentation/devicetree/bindings/serial/omap_serial.txt
b/Documentation/devicetree/bindings/serial/omap_serial.txt
index 342eedd..54c2a15 100644
--- a/Documentation/devicetree/bindings/serial/omap_serial.txt
+++ b/Documentation/devicetree/bindings/serial/omap_serial.txt
@@ -4,7 +4,27 @@ Required properties:
- compatible : should be "ti,omap2-uart" for OMAP2 controllers
- compatible : should be "ti,omap3-uart" for OMAP3 controllers
- compatible : should be "ti,omap4-uart" for OMAP4 controllers
+- reg : address and length of the register space
+- interrupts or interrupts-extended : Should contain the uart interrupt
+ specifier or both the interrupt
+ controller phandle and interrupt
+ specifier.
- ti,hwmods : Must be "uart", n being the instance number (1-based)
Optional properties:
- clock-frequency : frequency of the clock input to the UART
+- dmas : DMA specifier, consisting of a phandle to the DMA controller
+ node and a DMA channel number.
+- dma-names : "rx" for receive channel, "tx" for transmit channel.
+
+Example:
+
+uart4: serial@49042000 {
+compatible = "ti,omap3-uart";
+reg = <0x49042000 0x400>;
+interrupts = <80>;
+dmas = <&sdma 81 &sdma 82>;
+dma-names = "tx", "rx";
+ti,hwmods = "uart4";
+clock-frequency = <4800>;
+};
--
1.8.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] of: DT quirks infrastructure
On Wed, Feb 18, 2015 at 05:53:50PM +0200, Pantelis Antoniou wrote: > Hi Mark, > > > On Feb 18, 2015, at 17:41 , Mark Rutland wrote: > > > > Hi Pantelis, > > > > On Wed, Feb 18, 2015 at 02:59:34PM +, Pantelis Antoniou wrote: > >> Implement a method of applying DT quirks early in the boot sequence. > >> > >> A DT quirk is a subtree of the boot DT that can be applied to > >> a target in the base DT resulting in a modification of the live > >> tree. The format of the quirk nodes is that of a device tree overlay. > >> > >> For details please refer to Documentation/devicetree/quirks.txt > >> > >> Signed-off-by: Pantelis Antoniou > >> --- > >> Documentation/devicetree/quirks.txt | 101 ++ > >> drivers/of/dynamic.c| 358 > >> > >> include/linux/of.h | 16 ++ > >> 3 files changed, 475 insertions(+) > >> create mode 100644 Documentation/devicetree/quirks.txt > >> > >> diff --git a/Documentation/devicetree/quirks.txt > >> b/Documentation/devicetree/quirks.txt > >> new file mode 100644 > >> index 000..789319a > >> --- /dev/null > >> +++ b/Documentation/devicetree/quirks.txt > >> @@ -0,0 +1,101 @@ > >> +A Device Tree quirk is the way which allows modification of the > >> +boot device tree under the control of a per-platform specific method. > >> + > >> +Take for instance the case of a board family that comprises of a > >> +number of different board revisions, all being incremental changes > >> +after an initial release. > >> + > >> +Since all board revisions must be supported via a single software image > >> +the only way to support this scheme is by having a different DTB for each > >> +revision with the bootloader selecting which one to use at boot time. > > > > Not necessarily at boot time. The boards don't have to run the exact > > same FW/bootloader binary, so the relevant DTB could be programmed onto > > each board. > > > > That has not been the case in any kind of board I’ve worked with. > > A special firmware image that requires a different programming step at > the factory to select the correct DTB for each is always one more thing > that can go wrong. > > >> +While this may in theory work, in practice it is very cumbersome > >> +for the following reasons: > >> + > >> +1. The act of selecting a different boot device tree blob requires > >> +a reasonably advanced bootloader with some kind of configuration or > >> +scripting capabilities. Sadly this is not the case many times, the > >> +bootloader is extremely dumb and can only use a single dt blob. > > > > You can have several bootloader builds, or even a single build with > > something like appended DTB to get an appropriate DTB if the same binary > > will otherwise work across all variants of a board. > > > > No, the same DTB will not work across all the variants of a board. > > > So it's not necessarily true that you need a complex bootloader. > > > > >> +2. On many instances boot time is extremely critical; in some cases > >> +there are hard requirements like having working video feeds in under > >> +2 seconds from power-up. This leaves an extremely small time budget for > >> +boot-up, as low as 500ms to kernel entry. The sanest way to get there > >> +is by removing the standard bootloader from the normal boot sequence > >> +altogether by having a very small boot shim that loads the kernel and > >> +immediately jumps to kernel, like falcon-boot mode in u-boot does. > > > > Given my previous comments above I don't see why this is relevant. > > You're already passing _some_ DTB here, so if you can organise for the > > board to statically provide a sane DTB that's fine, or you can resort to > > appended DTB if it's not possible to update the board configuration. > > > > You’re missing the point. I can’t use the same DTB for each revision of the > board. Each board is similar but it’s not identical. > > >> +3. Having different DTBs/DTSs for different board revisions easily leads > >> to > >> +drift between versions. Since no developer is expected to have every > >> single > >> +board revision at hand, things are easy to get out of sync, with board > >> versions > >> +failing to boot even though the kernel is up to date. > > > > I'm not sure I follow. Surely if you don't have every board revision at > > hand you can't test quirks exhaustively either? > > > > It’s one less thing to worry about. For example in the current mainline kernel > already there is a drift between the beaglebone white and the beaglebone > black. > > Having the same DTS is just easier to keep things in sync. Absolutely, we have the problem in the dts files today where we have lots of duplicated bits. I know one case that I think you are alluding to is how BBW has the aes and sham enabled but BBB does not. That's with just two variants. :( This would definitely drive better organization of dtses and cure a lot of bitrot if they could share a common file. OTOH, some might arg
Re: [PATCH v8 01/11] ARM: brcmstb: add infrastructure for ARM-based Broadcom STB SoCs
On Fri, Aug 01, 2014 at 12:29:11PM -0700, Florian Fainelli wrote: > Hello, > > 2014-08-01 7:33 GMT-07:00 Rob Herring : > > On Wed, Jul 30, 2014 at 9:23 PM, Brian Norris > > wrote: > >> Hi Rob, > >> > >> I appreciate your comments, but where were many of these 5 months ago on > >> the first 7 revisions? :) > > > > Sorry, but that is the nature of upstreaming. But given some of the > > issues, it is obvious the reviews were not sufficient. > > > >> On a practical note: v9 is already queued for 3.17. Should I send > >> patches for the 3.17 cycle (or later) to fixup some of these issues? Or > >> would you recommend pulling the patches out of Matt Porter's tree now, > >> and reintroducing for 3.18? (I would be much happier with the first.) > > > > Things can always be un-queued. I guess that's Matt's and arm-soc's > > decision. > > Does that mean we should get all those patches un-queued, because that > specific patch adding SMP support that needs to be reworked, or does > that mean that if we drop this specific patch we are good with the > remainder of the patch series? Well, keep in mind that there's no specific patch adding SMP support. The patch here contains *all* of the actual code that goes through mach-bcm. The rest will go through Russell. Given what was missed, if we drop just this patch, we're left with just the DT, Kconfig, and MAINTAINERS changes. It doesn't seem like there's time to fix the problems now. It might be better to drop the whole series from arm-soc since it won't be functional in 3.17 if we drop just this patch. I'd like to see what Arnd and Olof think. I think there's value in leaving all the DT bits for 3.17. -Matt -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] devicetree: bindings: document Broadcom CPU enable method
On Mon, Jun 30, 2014 at 05:09:45PM -0500, Alex Elder wrote: > Broadcom mobile SoCs use a ROM-implemented holding pen for > controlled boot of secondary cores. A special register is > used to communicate to the ROM that a secondary core should > start executing kernel code. This enable method is currently > used for members of the bcm281xx and bcm21664 SoC families. > > The use of an enable method also allows the SMP operation vector to > be assigned as a result of device tree content for these SoCs. > > Signed-off-by: Alex Elder Applied to mach-bcm for-3.17/dt Thanks, Matt -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8 00/11] ARM: brcmstb: Add Broadcom STB SoC support
On Tue, Jul 22, 2014 at 10:57:17PM +0200, Arnd Bergmann wrote:
> On Tuesday 22 July 2014 13:44:31 Brian Norris wrote:
> > > For the platform changes in the first patch, I would prefer to have
> > > Matt pick up the first patch, but we can also apply it directly into
> > > arm-soc if he prefers that.
> >
> > That brings up a question related to PATCH 11 in the series (MAINTAINERS
> > update); who will be maintaining arch/arm/mach-bcm/*brcmstb*, and how
> > will code go upstream? It seems like Matt and Christian are officially
> > mach-bcm maintainers, although I don't know if Christian is still
> > involved.
>
> You have to solve that question together with Matt. From my perspective
> it would be easier if I only have to deal with one person for mach-bcm,
> but it's really up to you.
>
>
> > Also, BCM7xxx shares little in common with the rest of mach-bcm, except
> > a company name, so we'd really like at least the 'Maintainer' entries
> > for the CC. I was planning on a separate git tree too, although it could
> > have conflicts if we touch arch/arm/mach-bcm/{Makefile,Kconfig}.
> >
> > So would we send a separate arm-soc pull request for the arm-soc
> > targeted changes (and all future development)?
>
> You can definitely have the separate MAINTAINERS entry without necessarily
> becoming a maintainer at the same level. I know Matt is very responsive
> and can forward your patches to arm-soc if that works for you.
We had this discussion wrt Hauke's BCM5301x support. The situation is
basically the same. To date, every instance of a BCM ARM SoC shares
nothing more than the company name and in some rare cases a piece of
licensed IP like the Arasan sdhci or dwc2. I can't recall who asked
for it, but I think Olof asked to have one pull request for all of
mach-bcm to keep things simple. So we ended up with:
BROADCOM BCM5301X ARM ARCHICTURE
M: Hauke Mehrtens
L: linux-arm-ker...@lists.infradead.org
S: Maintained
F: arch/arm/mach-bcm/bcm_5301x.c
F: arch/arm/boot/dts/bcm5301x.dtsi
F: arch/arm/boot/dts/bcm470*
which could be a model for BCM7xxx maintainership and Christian and I
can aggregate this stuff in the mach-bcm tree for pull requests to the
arm-soc team as we are doing now. bcm2835 is an exception case since
that was living elsewhere before the new platforms colocated in
mach-bcm.
> > For the reset of mach-bcm stuff, I'll just send an arm-soc pull request
> > soon enough, unless Matt/Arnd/Olof object.
>
> I'll wait for Matt to comment before pulling it, otherwise that sounds
> fine.
I'm fine with it, but we were asked to have one request for bcm5301x to
make life easy for the arm-soc team. If we want each platform to do pull
requests directly with arm-soc we should advise Hauke to do the same as
well with bcm5301x. I think the chances of Kconfig/Makefile conflicts are
relatively low as there's a dwindling amount of code of interest in new
platform mach directories like ours.
I would like to see a consistent path for all BCM platform maintainers.
-Matt
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv7 2/5] mailbox: Introduce framework for mailbox
On Fri, Jun 20, 2014 at 01:59:30AM +0530, Jassi Brar wrote:
> On 20 June 2014 00:33, Matt Porter wrote:
> > On Thu, Jun 19, 2014 at 07:17:11PM +0100, Sudeep Holla wrote:
> >
> >> >+ * After startup and before shutdown any data received on the chan
> >> >+ * is passed on to the API via atomic mbox_chan_received_data().
> >> >+ * The controller should ACK the RX only after this call returns.
> >>
> >> Does this mean we can't support asynchronous messages from the remote.
> >> One possible scenario I can think is if the remote system power controller
> >> has feature to configure the bounds for thermal sensors and it can send
> >> async interrupt when the bounds are crossed. We can't just block one
> >> channel
> >> for this always. Again this might have been discussed before and you might
> >> have
> >> solution, I could not gather it with my brief look at older discussions.
> >
> > The way I see it we are simply putting the burden on the client to
> > implement very little in the rx_callback. In my case, we will have a
> > single client which is the IPC layer. The controller driver will notify
> > the IPC client layer which will do as little as possible in the
> > rx_callback before returning. We'll handle asynchronous dispatch of
> > events within our IPC layer to the real client drivers rather than in
> > the controller driver.
> >
> Yes. So do I.
>
> >> >+/**
> >> >+ * mbox_client_peek_data - A way for client driver to pull data
> >> >+ * received from remote by the controller.
> >> >+ * @chan: Mailbox channel assigned to this client.
> >> >+ *
> >> >+ * A poke to controller driver for any received data.
> >> >+ * The data is actually passed onto client via the
> >> >+ * mbox_chan_received_data()
> >> >+ * The call can be made from atomic context, so the controller's
> >> >+ * implementation of peek_data() must not sleep.
> >> >+ *
> >> >+ * Return: True, if controller has, and is going to push after this,
> >> >+ * some data.
> >> >+ * False, if controller doesn't have any data to be read.
> >> >+ */
> >> >+bool mbox_client_peek_data(struct mbox_chan *chan)
> >> >+{
> >> >+ if (chan->mbox->ops->peek_data)
> >> >+ return chan->mbox->ops->peek_data(chan);
> >> >+
> >> >+ return false;
> >> >+}
> >> >+EXPORT_SYMBOL_GPL(mbox_client_peek_data);
> >>
> >> I am unable to understand how this API will be used. IIUC when the
> >> controller
> >> receives any data from remote, it calls mbox_chan_received_data to push
> >> data to
> >> client.
> >
> > Good question.
> >
> > That function is a no-op if your client chooses not to populate
> > rx_callback. It's not explicitly stated, but the implementation is a
> > no-op if rx_callback is NULL so rx_callback seems to be intended as an
> > optional field in the client data.
> >
> > I'm also not clear of the scenario where this could be used. I
> > originally thought .peek_data() was an alternative to the callback for
> > polling purposes except it clearly states it needs the callback to carry
> > the data.
> >
> > I probably missed earlier discussion that explains this.
> >
> peek_data is just a trigger for controller to flush out any buffered
> RX via mbox_chan_received_data() to upper layer. Intended usecase is
> irq-mitigation for QMTM driver, as Arnd pointed out a few months ago.
Ok, that makes much more sense now.
Thanks,
Matt
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Unifying cape overlays into boot .dtb for BeagleBoard.org boards
On Tue, Jun 17, 2014 at 02:15:22PM +0100, Russell King wrote: > On Tue, Jun 17, 2014 at 08:58:31AM -0400, Matt Porter wrote: > > On Tue, Jun 17, 2014 at 10:09:31AM +0100, Russell King wrote: > > > Why should kernel developers go to the extent of adding support for DT > > > modification at runtime when the platform you want this for doesn't even > > > support hotplugging of these capes? > > > > It's important to note that Jason's use case is not the real one driving > > runtime DT modification. You'll have to go back to threads like > > https://lkml.org/lkml/2013/2/22/255 over a year ago where this was all > > hashed out. The clearest use cases are the FPGA folks that are loading > > their bitstream from userspace and due to DT-everywhere also need to > > initiate runtime modification of the live DT tree from userspace. > > There's a lot of discussion over many threads where this has been > > debated. > > Okay, so it was debated, and the outcome of that debate has been... no > change. That's probably because it is an incredible amount of work to > achieve it, and none of the overloaded DT maintainers (who don't have > enough time to review new bindings) have any intention of putting their > precious resources towards it. I don't believe this is completely true. Pantelis and Grant are working together on getting DT overlays upstream. It's pretty far along. It doesn't mean there aren't serious issues with the way the DT core code was implement assuming it would be static. > From my rudimentary understanding of the OF code, it seems to mean that > the way devices are created from the parsed OF tree structures (the > device_node structures) needs to change such that when an OF tree node > is removed, its corresponding device is also removed. This probably > needs a struct device pointer in the device_node struct. > > Then there needs to be support to modify the parsed OF tree (not only > to add nodes but also to remove nodes) and do the right thing when a > node is added and/or removed. > > However, there's harder cases to solve. There's several instances where > device nodes do not correspond with a struct device, and these nodes are > parsed by the driver. Such things as the of_graph stuff, which describes > the inter-connectivity of a display subsystem or v4l2 subsystem. The > nodes may be specified, but the target device for one of the links may > be disabled at original probe time, but later becomes enabled via > modification - this is one of the difficult cases since it needs the > driver to cooperate with the change, and there's no existing way to > notify it of that change. > > As with any kernel change, it needs people to write code. If no one writes > code, no change happens. Endlessly discussing it on mailing lists does not > result in code being written. Yes, I suppose you missed the active work on the DT overlay series. As I mentioned, there's active development on these things. There's also active discussion on some of the challenges. > However, going back to the original stated platform - none of this > complexity is required there. Once power is applied, the platform > hardware configuration is fixed (unless you want to yank a board off > and risk destroying the hardware in doing so.) So, if Jason's interest > is in the capes, then the simplest and easiest approach is to have the > boot loader deal with it. If it's about FPGAs and dynamically loading > bitstreams into them, then maybe a dynamic device tree is the answer - > but /someone/ then has to create patches to achieve that. If no one is > willing to create those patches, then forget the idea of a dynamic > device tree, because it won't happen on its own. https://lkml.org/lkml/2014/5/28/280 -Matt -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Unifying cape overlays into boot .dtb for BeagleBoard.org boards
On Tue, Jun 17, 2014 at 10:09:31AM +0100, Russell King wrote: > On Mon, Jun 16, 2014 at 09:22:50AM -0400, Jason Kridner wrote: > > Adding devicetree and linux-arm-kernel lists based on feedback on IRC... > > > > On Tue, Jun 10, 2014 at 12:46 PM, Jason Kridner wrote: > > > I'd like to discuss moving our current library of cape devicetree > > > overlay sources into a single tree, including the boot .dtb files for > > > BeagleBoard.org boards and moving towards enabling as much of the cape > > > support into a single boot-time .dtb file with an approach similar to > > > the cape-universal overlay > > > (https://github.com/cdsteinkuehler/beaglebone-universal-io), but not > > > in an overlay. > > > > > > First of all, I want to note this doesn't change my view on the > > > importance of mainline support for devicetree overlays. They are still > > > absolutely critical and highly useful, solving problems that cannot be > > > solved through boot-time devicetrees. I'm simply looking for an > > > approach that will complement the availability of overlays and provide > > > the best user experience. > > Here's the most obvious question in the world on this topic. Are capes > hot-pluggable? > > Looking at the posts on google+ from David Anders, they're using pin > headers for connectivity, with no additional protection against hot- > plugging, and no sequencing of pin connection. In other words, they are > not hot-pluggable. > > So, why do we need to add a load of infrastructure to the kernel to allow > the device tree to be modified at run time? At present, the way the > entire DT infrastructure works is that it assumes the DT remains static > and never changes - this applies not only to the core DT code, but also > to all the drivers which have been converted. > > So, you're asking for a feature which is impossible to really make use > of on the hardware which you want to use it. > > Why should kernel developers go to the extent of adding support for DT > modification at runtime when the platform you want this for doesn't even > support hotplugging of these capes? It's important to note that Jason's use case is not the real one driving runtime DT modification. You'll have to go back to threads like https://lkml.org/lkml/2013/2/22/255 over a year ago where this was all hashed out. The clearest use cases are the FPGA folks that are loading their bitstream from userspace and due to DT-everywhere also need to initiate runtime modification of the live DT tree from userspace. There's a lot of discussion over many threads where this has been debated. -Matt -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv5 2/4] mailbox: Introduce framework for mailbox
On Tue, Jun 03, 2014 at 03:51:55PM +0530, Jassi Brar wrote:
> On 3 June 2014 15:05, Sudeep Holla wrote:
> > Hi Jassi,
> >
> > On Mon, Jun 2, 2014 at 6:11 PM, Jassi Brar wrote:
> >> On Mon, Jun 2, 2014 at 8:44 PM, Matt Porter wrote:
> >>> On Fri, May 30, 2014 at 11:01:55AM +0530, Jassi Brar wrote:
> >>>
> >>>> Being more specific to your platform, I think you need some server
> >>>> code (mailbox's client) that every driver (like clock, pmu, pinmux
> >>>> etc) registers with to send messages to remote and receive commands
> >>>> from remote ... perhaps by registering some filter to sort out
> >>>> messages for each driver.
> >>>
> >>> Right, and here's where you hit on the problem. This server you mention
> >>> is not a piece of hardware, it would be a software construct. As such, it
> >>> doesn't fit into the DT binding as it exists. It's probably best to
> >>> illustrate in DT syntax.
> >>>
> >>> If I were to represent the hardware relationship in the DT binding now
> >>> it would look like this:
> >>>
> >>> ---
> >>> cpm: mailbox@deadbeef {
> >>> compatible = "brcm,bcm-cpm-mailbox";
> >>> reg = <...>;
> >>> #mbox-cells <1>;
> >>> interrupts = <...>;
> >>> };
> >>>
> >>> /* clock complex */
> >>> ccu {
> >>> compatible = "brcm,bcm-foo-ccu";
> >>> mbox = <&cpm CPM_SYSTEM_CHANNEL>;
> >>> mbox-names = "system";
> >>> /* leaving out other mailboxes for brevity */
> >>> #clock-cells <1>;
> >>> clock-output-names = "bar",
> >>> "baz";
> >>> };
> >>>
> >>> pmu {
> >>> compatible = "brcm,bcm-foo-pmu"
> >>> mbox = <&cpm CPM_SYSTEM_CHANNEL>;
> >>> mbox-names = "system";
> >>> };
> >>>
> >>> pinmux {
> >>> compatible = "brcm,bcm-foo-pinctrl";
> >>> mbox = <&cpm CPM_SYSTEM_CHANNEL>;
> >>> mbox-names = "system";
> >>> };
> >>> ---
> >> Yeah, I too don't think its a good idea.
> >>
> >>
> >>> What we would need to do is completely ignore this information in each
> >>> of the of the client drivers associated with the clock, pmu, and pinmux
> >>> devices. This IPC server would need to be instantiated and get the
> >>> mailbox information from some source. mbox_request_channel() only works
> >>> when the client has an of_node with the mbox-names property present.
> >>> Let's say we follow this model and represent it in DT:
> >>>
> >>> --
> >>> cpm: mailbox@deadbeef {
> >>> compatible = "brcm,bcm-cpm-mailbox";
> >>> reg = <...>;
> >>> #mbox-cells <1>;
> >>> interrupts = <...>;
> >>> };
> >>>
> >>> cpm_ipc {
> >>> compatible = "brcm,bcm-cpm-ipc";
> >>> mbox = <&cpm CPM_SYSTEM_CHANNEL>;
> >>> mbox-names = "system";
> >>> /* leaving out other mailboxes for brevity */
> >>> };
> >>> ---
> >>>
> >>> This would allow an ipc driver to exclusively own this system channel,
> >>> but now we've invented a binding that doesn't reflect the hardware at
> >>> all. It's describing software so I don't believe the DT maintainers will
> >>> allow this type of construct.
> >>>
> >> Must the server node specify MMIO and an IRQ, to be acceptable? Like ...
> >>
> >> cpm_ipc : cpm@deadbeef {
> >> compatible = "brcm,bcm-cpm-ipc";
> >>/* reg = <0xdeadbeef 0x100>; */
> >>/* interrupts = <0 123 4>; */
> >> mbox = <&cpm CPM_SYSTEM_CHANNEL>;
> >> mbox-names = "system";
> >> };
> >>
> >> cpm_ipc already specifies a hardware resource (mbox) that its driver
> >> needs, I think that should be enough reason. If it were some purely
>
Re: [PATCHv5 2/4] mailbox: Introduce framework for mailbox
[Adding devicetree list]
On Mon, Jun 02, 2014 at 10:41:44PM +0530, Jassi Brar wrote:
> On Mon, Jun 2, 2014 at 8:44 PM, Matt Porter wrote:
> > On Fri, May 30, 2014 at 11:01:55AM +0530, Jassi Brar wrote:
> >
> >> Being more specific to your platform, I think you need some server
> >> code (mailbox's client) that every driver (like clock, pmu, pinmux
> >> etc) registers with to send messages to remote and receive commands
> >> from remote ... perhaps by registering some filter to sort out
> >> messages for each driver.
> >
> > Right, and here's where you hit on the problem. This server you mention
> > is not a piece of hardware, it would be a software construct. As such, it
> > doesn't fit into the DT binding as it exists. It's probably best to
> > illustrate in DT syntax.
> >
> > If I were to represent the hardware relationship in the DT binding now
> > it would look like this:
> >
> > ---
> > cpm: mailbox@deadbeef {
> > compatible = "brcm,bcm-cpm-mailbox";
> > reg = <...>;
> > #mbox-cells <1>;
> > interrupts = <...>;
> > };
> >
> > /* clock complex */
> > ccu {
> > compatible = "brcm,bcm-foo-ccu";
> > mbox = <&cpm CPM_SYSTEM_CHANNEL>;
> > mbox-names = "system";
> > /* leaving out other mailboxes for brevity */
> > #clock-cells <1>;
> > clock-output-names = "bar",
> > "baz";
> > };
> >
> > pmu {
> > compatible = "brcm,bcm-foo-pmu"
> > mbox = <&cpm CPM_SYSTEM_CHANNEL>;
> > mbox-names = "system";
> > };
> >
> > pinmux {
> > compatible = "brcm,bcm-foo-pinctrl";
> > mbox = <&cpm CPM_SYSTEM_CHANNEL>;
> > mbox-names = "system";
> > };
> > ---
> Yeah, I too don't think its a good idea.
>
>
> > What we would need to do is completely ignore this information in each
> > of the of the client drivers associated with the clock, pmu, and pinmux
> > devices. This IPC server would need to be instantiated and get the
> > mailbox information from some source. mbox_request_channel() only works
> > when the client has an of_node with the mbox-names property present.
> > Let's say we follow this model and represent it in DT:
> >
> > --
> > cpm: mailbox@deadbeef {
> > compatible = "brcm,bcm-cpm-mailbox";
> > reg = <...>;
> > #mbox-cells <1>;
> > interrupts = <...>;
> > };
> >
> > cpm_ipc {
> > compatible = "brcm,bcm-cpm-ipc";
> > mbox = <&cpm CPM_SYSTEM_CHANNEL>;
> > mbox-names = "system";
> > /* leaving out other mailboxes for brevity */
> > };
> > ---
> >
> > This would allow an ipc driver to exclusively own this system channel,
> > but now we've invented a binding that doesn't reflect the hardware at
> > all. It's describing software so I don't believe the DT maintainers will
> > allow this type of construct.
> >
> Must the server node specify MMIO and an IRQ, to be acceptable? Like ...
My bad, that was a cut and paste typo..I intended to remove those
properties as you do below.
>
> cpm_ipc : cpm@deadbeef {
> compatible = "brcm,bcm-cpm-ipc";
>/* reg = <0xdeadbeef 0x100>; */
>/* interrupts = <0 123 4>; */
> mbox = <&cpm CPM_SYSTEM_CHANNEL>;
> mbox-names = "system";
> };
Correct, this should have been:
cpm_ipc {
compatible = "brcm,bcm-cpm-ipc";
mbox = <&cpm CPM_SYSTEM_CHANNEL>;
mbox-names = "system";
};
> cpm_ipc already specifies a hardware resource (mbox) that its driver
> needs, I think that should be enough reason. If it were some purely
> soft property for the driver like
> mode = "poll"; //or "irq"
> then the node wouldn't be justified because that is the job of a
> build-time config or run-time module option.
Hrm, this is where I'd like to hear from the DT maintainers since we
have to live with this generic binding. If they are ok with us creating
bindings for a virtual device that exists only to match with our ipc
driver then it will work. I'm not aware of other similar examples though.
-Matt
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 4/4] ARM: dts: bcm590xx: add support for GPLDO and VBUS regulators
On Wed, Apr 23, 2014 at 07:21:33PM -0400, Matt Porter wrote:
> Adds additional nodes to support GPLDO1-6 and VBUS regulators which
> are now supported in the bcm590xx regulator driver.
Applied to mach-bcm for-3.16/dt
> arch/arm/boot/dts/bcm59056.dtsi | 21 +
> 1 file changed, 21 insertions(+)
>
> diff --git a/arch/arm/boot/dts/bcm59056.dtsi b/arch/arm/boot/dts/bcm59056.dtsi
> index dfadaaa..066adfb 100644
> --- a/arch/arm/boot/dts/bcm59056.dtsi
> +++ b/arch/arm/boot/dts/bcm59056.dtsi
> @@ -70,5 +70,26 @@
>
> vsr_reg: vsr {
> };
> +
> + gpldo1_reg: gpldo1 {
> + };
> +
> + gpldo2_reg: gpldo2 {
> + };
> +
> + gpldo3_reg: gpldo3 {
> + };
> +
> + gpldo4_reg: gpldo4 {
> + };
> +
> + gpldo5_reg: gpldo5 {
> + };
> +
> + gpldo6_reg: gpldo6 {
> + };
> +
> + vbus_reg: vbus {
> + };
> };
> };
> --
> 1.8.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 4/4] ARM: dts: bcm590xx: add support for GPLDO and VBUS regulators
On Wed, May 21, 2014 at 10:29:13AM +0100, Lee Jones wrote:
> > Adds additional nodes to support GPLDO1-6 and VBUS regulators which
> > are now supported in the bcm590xx regulator driver.
> >
> > Signed-off-by: Matt Porter
> > ---
> > arch/arm/boot/dts/bcm59056.dtsi | 21 +
> > 1 file changed, 21 insertions(+)
>
> I'm not going to apply this with the rest of the set. It will have to
> go in via your normal arch/arm route.
Ok
> > diff --git a/arch/arm/boot/dts/bcm59056.dtsi
> > b/arch/arm/boot/dts/bcm59056.dtsi
> > index dfadaaa..066adfb 100644
> > --- a/arch/arm/boot/dts/bcm59056.dtsi
> > +++ b/arch/arm/boot/dts/bcm59056.dtsi
> > @@ -70,5 +70,26 @@
> >
> > vsr_reg: vsr {
> > };
> > +
> > + gpldo1_reg: gpldo1 {
> > + };
>
> What do these empty nodes do in any case?
They instantiate regulators. The bcm590xx binding specifies the
allowable subnode names permitted here. This replaces the old method
of specifying an index or the deprecated regulator-compatible property.
The board-specific dts includes this dtsi and applies any board
constraints to a subset of regulators that need them. Unused regulators
are all disabled which is what we want.
> Don't you at least need a status property in there or something?
Not necessary for these subnodes.
-Matt
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/4] mfd: bcm590xx: add support for secondary I2C slave address
On Tue, May 20, 2014 at 10:44:39PM +0100, Mark Brown wrote: > On Tue, May 20, 2014 at 04:29:23PM -0400, Matt Porter wrote: > > > Just resent the v2 series. > > I looked at that but it seems I already acked the regulator part of the > series and nothing else looked immediately relevant? The series has cross dependencies (shared header include) and thus needs to have both the mfd and regulator portions merged together. You had mentioned in the v1 version that you'd like to take it through the regulator tree and so Lee's comments earlier were with regard to you taking the mfd portions. -Matt signature.asc Description: Digital signature
[PATCH RESEND v2 1/4] mfd: bcm590xx: update binding with additional BCM59056 regulators
The BCM59056 supports GPLDO1-6 and VBUS regulators in a secondary
I2C slave address space. Add these regulators to the list of valid
regulator node names for BCM59056.
Signed-off-by: Matt Porter
---
Documentation/devicetree/bindings/mfd/bcm590xx.txt | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/mfd/bcm590xx.txt
b/Documentation/devicetree/bindings/mfd/bcm590xx.txt
index 1fe30e2..be51a15 100644
--- a/Documentation/devicetree/bindings/mfd/bcm590xx.txt
+++ b/Documentation/devicetree/bindings/mfd/bcm590xx.txt
@@ -19,7 +19,9 @@ Optional child nodes:
The valid regulator node names for BCM59056 are:
rfldo, camldo1, camldo2, simldo1, simldo2, sdldo, sdxldo,
mmcldo1, mmcldo2, audldo, micldo, usbldo, vibldo,
- csr, iosr1, iosr2, msr, sdsr1, sdsr2, vsr
+ csr, iosr1, iosr2, msr, sdsr1, sdsr2, vsr,
+ gpldo1, gpldo2, gpldo3, gpldo4, gpldo5, gpldo6,
+ vbus
Example:
pmu: bcm59056@8 {
--
1.8.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH RESEND v2 0/4] Support additional regulators on BCM590xx
Changes since v1: - Fix a several commit log typos and capitalization - Drop use of addmap[0|1] in favor of i2c_[pri|sec] - Replace regmap[0|1] with regmap_[pri|sec] This series enables support for 7 additional regulators on the BCM59056 PMU. These regulators are accessed via a secondary I2C slave address. The MFD driver exposes an additional regmap descriptor for the additional address space and the regulator implements support for GPLDO1-6 and VBUS regulators. Matt Porter (4): mfd: bcm590xx: update binding with additional BCM59056 regulators mfd: bcm590xx: add support for secondary I2C slave address regulator: bcm590xx: add support for regulators on secondary I2C slave ARM: dts: bcm590xx: add support for GPLDO and VBUS regulators Documentation/devicetree/bindings/mfd/bcm590xx.txt | 4 +- arch/arm/boot/dts/bcm59056.dtsi| 21 + drivers/mfd/bcm590xx.c | 60 ++ drivers/regulator/bcm590xx-regulator.c | 92 +++--- include/linux/mfd/bcm590xx.h | 9 ++- 5 files changed, 158 insertions(+), 28 deletions(-) -- 1.8.4 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/4] mfd: bcm590xx: add support for secondary I2C slave address
On Tue, May 20, 2014 at 08:00:55PM +0100, Mark Brown wrote: > On Tue, May 20, 2014 at 05:11:31PM +0100, Lee Jones wrote: > > > > > > drivers/mfd/bcm590xx.c | 60 > > > > > +--- > > > > > include/linux/mfd/bcm590xx.h | 9 --- > > > > > 2 files changed, 52 insertions(+), 17 deletions(-) > > > > There's cross-deps so the regulator driver will need to go with it. > > > Mark mentioned earlier in the thread that he wanted to merge through > > > the regulator tree though. > > > Still nothing. > > > Mark, > > Can I apply this set and supply you with a pull-request? > > Can someone please send me whatever it is you want me to look at, the > above diffstat doesn't look relevant. Given the frequency of respins > I'm not always paying a huge amount of attention to MFD serieses which > look like they're going to be resent. Just resent the v2 series. -Matt signature.asc Description: Digital signature
[PATCH RESEND v2 3/4] regulator: bcm590xx: add support for regulators on secondary I2C slave
The bcm590xx MFD driver now exposes a secondary regmap descriptor
making the registers for regulators on the secondary I2C slave address
available. Add support for GPLDO1-6 and VBUS regulators found within
this register range.
Signed-off-by: Matt Porter
Acked-by: Mark Brown
---
drivers/regulator/bcm590xx-regulator.c | 92 ++
1 file changed, 82 insertions(+), 10 deletions(-)
diff --git a/drivers/regulator/bcm590xx-regulator.c
b/drivers/regulator/bcm590xx-regulator.c
index c3750c5..57544e2 100644
--- a/drivers/regulator/bcm590xx-regulator.c
+++ b/drivers/regulator/bcm590xx-regulator.c
@@ -22,7 +22,7 @@
#include
#include
-/* Register defs */
+/* I2C slave 0 registers */
#define BCM590XX_RFLDOPMCTRL1 0x60
#define BCM590XX_IOSR1PMCTRL1 0x7a
#define BCM590XX_IOSR2PMCTRL1 0x7c
@@ -31,13 +31,34 @@
#define BCM590XX_SDSR2PMCTRL1 0x86
#define BCM590XX_MSRPMCTRL10x8a
#define BCM590XX_VSRPMCTRL10x8e
-#define BCM590XX_REG_ENABLEBIT(7)
-
#define BCM590XX_RFLDOCTRL 0x96
#define BCM590XX_CSRVOUT1 0xc0
+
+/* I2C slave 1 registers */
+#define BCM590XX_GPLDO5PMCTRL1 0x16
+#define BCM590XX_GPLDO6PMCTRL1 0x18
+#define BCM590XX_GPLDO1CTRL0x1a
+#define BCM590XX_GPLDO2CTRL0x1b
+#define BCM590XX_GPLDO3CTRL0x1c
+#define BCM590XX_GPLDO4CTRL0x1d
+#define BCM590XX_GPLDO5CTRL0x1e
+#define BCM590XX_GPLDO6CTRL0x1f
+#define BCM590XX_OTG_CTRL 0x40
+#define BCM590XX_GPLDO1PMCTRL1 0x57
+#define BCM590XX_GPLDO2PMCTRL1 0x59
+#define BCM590XX_GPLDO3PMCTRL1 0x5b
+#define BCM590XX_GPLDO4PMCTRL1 0x5d
+
+#define BCM590XX_REG_ENABLEBIT(7)
+#define BCM590XX_VBUS_ENABLE BIT(2)
#define BCM590XX_LDO_VSEL_MASK GENMASK(5, 3)
#define BCM590XX_SR_VSEL_MASK GENMASK(5, 0)
+/*
+ * RFLDO to VSR regulators are
+ * accessed via I2C slave 0
+ */
+
/* LDO regulator IDs */
#define BCM590XX_REG_RFLDO 0
#define BCM590XX_REG_CAMLDO1 1
@@ -62,9 +83,25 @@
#define BCM590XX_REG_SDSR2 18
#define BCM590XX_REG_VSR 19
-#define BCM590XX_NUM_REGS 20
+/*
+ * GPLDO1 to VBUS regulators are
+ * accessed via I2C slave 1
+ */
+
+#define BCM590XX_REG_GPLDO120
+#define BCM590XX_REG_GPLDO221
+#define BCM590XX_REG_GPLDO322
+#define BCM590XX_REG_GPLDO423
+#define BCM590XX_REG_GPLDO524
+#define BCM590XX_REG_GPLDO625
+#define BCM590XX_REG_VBUS 26
+
+#define BCM590XX_NUM_REGS 27
#define BCM590XX_REG_IS_LDO(n) (n < BCM590XX_REG_CSR)
+#define BCM590XX_REG_IS_GPLDO(n) \
+ ((n > BCM590XX_REG_VSR) && (n < BCM590XX_REG_VBUS))
+#define BCM590XX_REG_IS_VBUS(n)(n == BCM590XX_REG_VBUS)
struct bcm590xx_board {
struct regulator_init_data *bcm590xx_pmu_init_data[BCM590XX_NUM_REGS];
@@ -149,6 +186,12 @@ static struct bcm590xx_info bcm590xx_regs[] = {
BCM590XX_REG_RANGES(sdsr1, dcdc_sdsr1_ranges),
BCM590XX_REG_RANGES(sdsr2, dcdc_iosr1_ranges),
BCM590XX_REG_RANGES(vsr, dcdc_iosr1_ranges),
+ BCM590XX_REG_TABLE(gpldo1, ldo_a_table),
+ BCM590XX_REG_TABLE(gpldo2, ldo_a_table),
+ BCM590XX_REG_TABLE(gpldo3, ldo_a_table),
+ BCM590XX_REG_TABLE(gpldo4, ldo_a_table),
+ BCM590XX_REG_TABLE(gpldo5, ldo_a_table),
+ BCM590XX_REG_TABLE(gpldo6, ldo_a_table),
};
struct bcm590xx_reg {
@@ -161,6 +204,8 @@ static int bcm590xx_get_vsel_register(int id)
{
if (BCM590XX_REG_IS_LDO(id))
return BCM590XX_RFLDOCTRL + id;
+ else if (BCM590XX_REG_IS_GPLDO(id))
+ return BCM590XX_GPLDO1CTRL + id;
else
return BCM590XX_CSRVOUT1 + (id - BCM590XX_REG_CSR) * 3;
}
@@ -171,6 +216,8 @@ static int bcm590xx_get_enable_register(int id)
if (BCM590XX_REG_IS_LDO(id))
reg = BCM590XX_RFLDOPMCTRL1 + id * 2;
+ else if (BCM590XX_REG_IS_GPLDO(id))
+ reg = BCM590XX_GPLDO1PMCTRL1 + id * 2;
else
switch (id) {
case BCM590XX_REG_CSR:
@@ -191,8 +238,11 @@ static int bcm590xx_get_enable_register(int id)
case BCM590XX_REG_SDSR2:
reg = BCM590XX_SDSR2PMCTRL1;
break;
+ case BCM590XX_REG_VBUS:
+ reg = BCM590XX_OTG_CTRL;
};
+
return reg;
}
@@ -216,6 +266,12 @@ static struct regulator_ops bcm590xx_ops_dcdc = {
.map_voltage= regulator_map_voltage_linear_range,
};
+static struct regulator_ops bcm590xx_ops_vbus = {
+ .is_enabled = regulator_is_enabled_regmap,
+ .enable = regulator_enable_regmap,
+ .disable= regulator_disable_regmap,
+};
+
#define BCM590XX_MATCH(_name, _id) \
{ \
.name = #_name, \
@@ -243,6 +299,13 @@ static struct of_regulator_match bcm590xx_matches[] = {
BCM590XX_MATCH(sdsr1, SDSR1),
BCM590XX_MATCH(sdsr2, SDSR2),
BCM590XX_MATCH(vsr, VSR),
+ BCM590XX_MAT
[PATCH RESEND v2 4/4] ARM: dts: bcm590xx: add support for GPLDO and VBUS regulators
Adds additional nodes to support GPLDO1-6 and VBUS regulators which
are now supported in the bcm590xx regulator driver.
Signed-off-by: Matt Porter
---
arch/arm/boot/dts/bcm59056.dtsi | 21 +
1 file changed, 21 insertions(+)
diff --git a/arch/arm/boot/dts/bcm59056.dtsi b/arch/arm/boot/dts/bcm59056.dtsi
index dfadaaa..066adfb 100644
--- a/arch/arm/boot/dts/bcm59056.dtsi
+++ b/arch/arm/boot/dts/bcm59056.dtsi
@@ -70,5 +70,26 @@
vsr_reg: vsr {
};
+
+ gpldo1_reg: gpldo1 {
+ };
+
+ gpldo2_reg: gpldo2 {
+ };
+
+ gpldo3_reg: gpldo3 {
+ };
+
+ gpldo4_reg: gpldo4 {
+ };
+
+ gpldo5_reg: gpldo5 {
+ };
+
+ gpldo6_reg: gpldo6 {
+ };
+
+ vbus_reg: vbus {
+ };
};
};
--
1.8.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH RESEND v2 2/4] mfd: bcm590xx: add support for secondary I2C slave address
BCM590xx utilizes a secondary I2C slave address to access additional
register space. Add support for the secondary address space by
instantiating a dummy I2C device with the appropriate secondary
I2C slave address. Also expose a secondary regmap register space so
that MFD drivers can access this secondary i2c slave address space.
Signed-off-by: Matt Porter
---
drivers/mfd/bcm590xx.c | 60 +---
include/linux/mfd/bcm590xx.h | 9 ---
2 files changed, 52 insertions(+), 17 deletions(-)
diff --git a/drivers/mfd/bcm590xx.c b/drivers/mfd/bcm590xx.c
index e9a33c7..43cba1a 100644
--- a/drivers/mfd/bcm590xx.c
+++ b/drivers/mfd/bcm590xx.c
@@ -28,39 +28,71 @@ static const struct mfd_cell bcm590xx_devs[] = {
},
};
-static const struct regmap_config bcm590xx_regmap_config = {
+static const struct regmap_config bcm590xx_regmap_config_pri = {
.reg_bits = 8,
.val_bits = 8,
- .max_register = BCM590XX_MAX_REGISTER,
+ .max_register = BCM590XX_MAX_REGISTER_PRI,
.cache_type = REGCACHE_RBTREE,
};
-static int bcm590xx_i2c_probe(struct i2c_client *i2c,
+static const struct regmap_config bcm590xx_regmap_config_sec = {
+ .reg_bits = 8,
+ .val_bits = 8,
+ .max_register = BCM590XX_MAX_REGISTER_SEC,
+ .cache_type = REGCACHE_RBTREE,
+};
+
+static int bcm590xx_i2c_probe(struct i2c_client *i2c_pri,
const struct i2c_device_id *id)
{
struct bcm590xx *bcm590xx;
int ret;
- bcm590xx = devm_kzalloc(&i2c->dev, sizeof(*bcm590xx), GFP_KERNEL);
+ bcm590xx = devm_kzalloc(&i2c_pri->dev, sizeof(*bcm590xx), GFP_KERNEL);
if (!bcm590xx)
return -ENOMEM;
- i2c_set_clientdata(i2c, bcm590xx);
- bcm590xx->dev = &i2c->dev;
- bcm590xx->i2c_client = i2c;
+ i2c_set_clientdata(i2c_pri, bcm590xx);
+ bcm590xx->dev = &i2c_pri->dev;
+ bcm590xx->i2c_pri = i2c_pri;
- bcm590xx->regmap = devm_regmap_init_i2c(i2c, &bcm590xx_regmap_config);
- if (IS_ERR(bcm590xx->regmap)) {
- ret = PTR_ERR(bcm590xx->regmap);
- dev_err(&i2c->dev, "regmap initialization failed: %d\n", ret);
+ bcm590xx->regmap_pri = devm_regmap_init_i2c(i2c_pri,
+&bcm590xx_regmap_config_pri);
+ if (IS_ERR(bcm590xx->regmap_pri)) {
+ ret = PTR_ERR(bcm590xx->regmap_pri);
+ dev_err(&i2c_pri->dev, "primary regmap init failed: %d\n", ret);
return ret;
}
- ret = mfd_add_devices(&i2c->dev, -1, bcm590xx_devs,
+ /* Secondary I2C slave address is the base address with A(2) asserted */
+ bcm590xx->i2c_sec = i2c_new_dummy(i2c_pri->adapter,
+ i2c_pri->addr | BIT(2));
+ if (IS_ERR_OR_NULL(bcm590xx->i2c_sec)) {
+ dev_err(&i2c_pri->dev, "failed to add secondary I2C device\n");
+ return -ENODEV;
+ }
+ i2c_set_clientdata(bcm590xx->i2c_sec, bcm590xx);
+
+ bcm590xx->regmap_sec = devm_regmap_init_i2c(bcm590xx->i2c_sec,
+ &bcm590xx_regmap_config_sec);
+ if (IS_ERR(bcm590xx->regmap_sec)) {
+ ret = PTR_ERR(bcm590xx->regmap_sec);
+ dev_err(&bcm590xx->i2c_sec->dev,
+ "secondary regmap init failed: %d\n", ret);
+ goto err;
+ }
+
+ ret = mfd_add_devices(&i2c_pri->dev, -1, bcm590xx_devs,
ARRAY_SIZE(bcm590xx_devs), NULL, 0, NULL);
- if (ret < 0)
- dev_err(&i2c->dev, "failed to add sub-devices: %d\n", ret);
+ if (ret < 0) {
+ dev_err(&i2c_pri->dev, "failed to add sub-devices: %d\n", ret);
+ goto err;
+ }
+
+ return 0;
+err:
+ i2c_unregister_device(bcm590xx->i2c_sec);
return ret;
}
diff --git a/include/linux/mfd/bcm590xx.h b/include/linux/mfd/bcm590xx.h
index 434df2d..267aede 100644
--- a/include/linux/mfd/bcm590xx.h
+++ b/include/linux/mfd/bcm590xx.h
@@ -19,12 +19,15 @@
#include
/* max register address */
-#define BCM590XX_MAX_REGISTER 0xe7
+#define BCM590XX_MAX_REGISTER_PRI 0xe7
+#define BCM590XX_MAX_REGISTER_SEC 0xf0
struct bcm590xx {
struct device *dev;
- struct i2c_client *i2c_client;
- struct regmap *regmap;
+ struct i2c_client *i2c_pri;
+ struct i2c_client *i2c_sec;
+ struct regmap *regmap_pri;
+ struct regmap *regmap_sec;
unsigned int id;
};
--
1.8.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 RESEND 2/5] ARM: add SMP support for Broadcom mobile SoCs
On Thu, May 15, 2014 at 01:17:00PM -0500, Alex Elder wrote: > On 05/15/2014 01:03 PM, Florian Fainelli wrote: > > Hi Alex, > > > > 2014-05-15 10:58 GMT-07:00 Alex Elder : > >> This patch adds SMP support for BCM281XX and BCM21664 family SoCs. > >> > >> This feature is controlled with a distinct config option such that a > >> SMP-enabled multi-v7 binary can be configured to run these SoCs in > >> uniprocessor mode. Since this SMP functionality is used for > >> multiple Broadcom mobile chip families the config option is called > >> ARCH_BCM_MOBILE_SMP (for lack of a better name). > >> > >> On SoCs of this type, the secondary core is not held in reset on > >> power-on. Instead it loops in a ROM-based holding pen. To release > >> it, one must write into a special register a jump address whose > >> low-order bits have been replaced with a secondary core's id, then > >> trigger an event with SEV. On receipt of an event, the ROM code > >> will examine the register's contents, and if the low-order bits > >> match its cpu id, it will clear them and write the value back to the > >> register just prior to jumping to the address specified. > >> > >> The location of the special register is defined in the device tree > >> using a "secondary-boot-reg" property in a node whose "enable-method" > >> matches. > >> > >> Derived from code originally provided by Ray Jui > >> > >> Signed-off-by: Alex Elder > >> --- > >> arch/arm/mach-bcm/Kconfig | 18 +++- > >> arch/arm/mach-bcm/Makefile | 3 + > >> arch/arm/mach-bcm/platsmp.c | 201 > >> > > > > Could we make that name a little bit more specific to the mobile SoCs? > > Sure. I thought about that but naming stuff here has been a sort > of ongoing struggle... "Kona" made some sense, in some cases, > but it's not perfect. Simlar with "mobile." > > I'll propose "kona_smp.c". OK with you? Unless I get a better > suggestion I'll plan to go with that next time around. Works for me. -Matt -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 RESEND 2/5] ARM: add SMP support for Broadcom mobile SoCs
On Thu, May 15, 2014 at 11:03:49AM -0700, Florian Fainelli wrote: > Hi Alex, > > 2014-05-15 10:58 GMT-07:00 Alex Elder : > > This patch adds SMP support for BCM281XX and BCM21664 family SoCs. > > > > This feature is controlled with a distinct config option such that a > > SMP-enabled multi-v7 binary can be configured to run these SoCs in > > uniprocessor mode. Since this SMP functionality is used for > > multiple Broadcom mobile chip families the config option is called > > ARCH_BCM_MOBILE_SMP (for lack of a better name). > > > > On SoCs of this type, the secondary core is not held in reset on > > power-on. Instead it loops in a ROM-based holding pen. To release > > it, one must write into a special register a jump address whose > > low-order bits have been replaced with a secondary core's id, then > > trigger an event with SEV. On receipt of an event, the ROM code > > will examine the register's contents, and if the low-order bits > > match its cpu id, it will clear them and write the value back to the > > register just prior to jumping to the address specified. > > > > The location of the special register is defined in the device tree > > using a "secondary-boot-reg" property in a node whose "enable-method" > > matches. > > > > Derived from code originally provided by Ray Jui > > > > Signed-off-by: Alex Elder > > --- > > arch/arm/mach-bcm/Kconfig | 18 +++- > > arch/arm/mach-bcm/Makefile | 3 + > > arch/arm/mach-bcm/platsmp.c | 201 > > > > Could we make that name a little bit more specific to the mobile SoCs? > There are other BCM SoCs either currently supported in this directory > (BCM5310X), or making their way to be supported (brcmstb, bcm63xx), > and those share nothing with the Mobile SoC SMP code. Right. > Maybe we should create another level directory within mach-bcm... Let's not go that far. The general direction we need to go is to work toward removing this code from mach-bcm/ completely. I don't really want to see us adding directories and encouraging burying a lot of new files in them. A unique name will be enough and then we can work toward moving things out to drivers/ over time. -Matt -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] ARM: dts: am335x-bone-common: Add i2c2 definition
On Tue, May 13, 2014 at 04:06:02PM +0200, Javier Martinez Canillas wrote:
> On Tue, May 13, 2014 at 2:53 PM, Tom Rini wrote:
> > On 05/12/2014 04:57 PM, Robert Nelson wrote:
> Either case if fine with me. As who knows when the dtc "overlay" will
> every truly make it mainline, as the capemgr was the only real kernel
> user of the i2c/at24 eeprom information.
> >>>
> >>> Sounds like we should keep it disabled though so u-boot can be used
> >>> to toggle it while waiting for the capemgr. That's because the board
> >>> has a header for pins, so it's not exactly limited to just the capes.
> >>>
> >>> Anybody working on enabling/disabling cape dtb configurations in u-boot?
> >>
> >> Well,
> >>
> >> Would Tom even approve of that in mainline u-boot? He didn't want my
> >> "invert" the gpio to enable the usb hub on the older beagle xm A/B..
> >>
> >> http://lists.denx.de/pipermail/u-boot/2014-January/172154.html
> >>
> >> http://lists.denx.de/pipermail/u-boot/2014-January/172274.html
>
> Using fdt set from the bootloader to use the same FDT for similar
> boards (like the example with Beagle xM variants) is kind of trying to
> replicate what we used to do from boards files where it was possible
> to manage a set of boards using the same platform code.
>
> But Device Trees are meant to describe hardware and thus should be
> static, if two board are almost identical but slightly different, then
> are two different hardware where each need its proper FDT that
> describes it.
>
> >
> > I would think that using the 'fdt' command in U-Boot to add all
> > properties of every cape found on a running system would drive someone
> > to madness quite quickly. Moving all of Pantelis' work for dynamic
> > device trees from the kernel to N bootloaders (U-Boot, barebox, UEFI,
> > etc) sounds like a step in the wrong direction.
> >
>
> Agreed. I think that until the device tree overlay and the cape
> manager find their way into mainline we should treat capes as if they
> were expansion boards attached to a Computer-on-Module. That is, a
> static based board which its own DTS including the BB{B,W} as an dtsi
> and not something that can be added on runtime.
It's far more complicated than a SOM plus carrier board. Consider that
you can have any 4 of these capes stacked on the BBB/BBW in any
combination (assuming no resource conflicts). Capturing all possible
combinations in static dtsis is not practical.
-Matt
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 RESEND 0/5] Add Broadcom Kona PWM Support
On Mon, Apr 28, 2014 at 08:00:39AM -0700, Tim Kryger wrote: > On Mon, Apr 28, 2014 at 4:07 AM, Thierry Reding > wrote: > > On Fri, Apr 25, 2014 at 11:31:10AM -0700, Tim Kryger wrote: > >> This series introduces the driver for the Kona PWM controller found in > >> Broadcom mobile SoCs like bcm281xx and updates the device tree and the > >> defconfig to enable use of this hardware on the bcm28155 AP board. > >> > > >> Tim Kryger (5): > >> Documentation: dt: Add Kona PWM binding > >> pwm: kona: Introduce Kona PWM controller support > >> ARM: dts: Declare the PWM for bcm11351 (bcm281xx) > >> ARM: dts: Enable the PWM for bcm28155 AP board > >> ARM: bcm_defconfig: Enable PWM and Backlight > > > I've applied patches 1 and 2 (with two tiny whitespace cleanups) to my > > for-next branch. > > Sounds good. Thank you. > > Matt and Christian, are you okay taking patches 3-5 through your tree? Yes, I've now applied them to the appropropriate mach-bcm 3.16 branches. -Matt -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/4] mfd: bcm590xx: add support for secondary I2C slave address
On Mon, Apr 28, 2014 at 12:56:27PM +0100, Lee Jones wrote: > On Wed, 23 Apr 2014, Matt Porter wrote: > > > BCM590xx utilizes a secondary I2C slave address to access additional > > register space. Add support for the secondary address space by > > instantiating a dummy I2C device with the appropriate secondary > > I2C slave address. Also expose a secondary regmap register space so > > that MFD drivers can access this secondary i2c slave address space. > > > > Signed-off-by: Matt Porter > > --- > > drivers/mfd/bcm590xx.c | 60 > > +--- > > include/linux/mfd/bcm590xx.h | 9 --- > > 2 files changed, 52 insertions(+), 17 deletions(-) > > Nice, flows much better now. > > Can I just apply the two MFD patches, or are there cross-deps? There's cross-deps so the regulator driver will need to go with it. Mark mentioned earlier in the thread that he wanted to merge through the regulator tree though. -Matt -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 RESEND 0/5] clk: bcm21664: add common clock support
On Fri, Apr 25, 2014 at 05:09:15PM -0700, Mike Turquette wrote: > Quoting Alex Elder (2014-04-21 14:26:22) > > This is series has two parts. The first two patches are changes > > to the existing Broadcom Kona family clock code to prepare for the > > addition of support for another SoC, bcm21664. > > > > The remaining three define the binding and code for bcm21664, and > > replace the use of "fake" clocks in the device tree with the real > > ones. This ends up being a fairly straightforward definition of > > the clocks on this SoC; the rest of the clock code is shared with > > other SoCs that use the Kona style clock system. > > Hi Alex, > > I'm happy to take only the clk patches or I can take the DT stuff as > well if it gets some Acks. Let me know how you want it handled. Hi Mike, Since there's a strict ordering requirement in this series (due to shared use of a DT include by the driver and dts) I'd like it if you could take the entire series through your tree to keep these together. I've acked the dts patch. Thanks, Matt > > This series depends on the following patch, which has been taken > > into the clk-fixes tree: > > clk: bcm281xx: don't use unnamed structs or unions > > https://lkml.org/lkml/2014/4/7/322 > > > > In addition, it depends on the version 4 of the following series, > > just (re)posted for review: > > clk: bcm281xx: updates > > https://lkml.org/lkml/2014/4/8/485 > > > > The patches in this series--based on the current linus/master branch > > plus the patches mentioned above--are available here: > > http://git.linaro.org/git/landing-teams/working/broadcom/kernel.git > > Branch review/bcm21664-clock-v2 > > > > Alex Elder (5): > > clk: bcm281xx: move compatible string definitions > > ARM: dts: revise kona clock binding document > > ARM: dts: define clock binding for bcm21664 > > clk: bcm21664: use common clock framework > > ARM: dts: use real clocks for bcm21664 > > > > .../devicetree/bindings/clock/bcm-kona-clock.txt | 116 ++--- > > arch/arm/boot/dts/bcm21664.dtsi| 190 +- > > drivers/clk/bcm/Kconfig| 2 +- > > drivers/clk/bcm/Makefile | 1 + > > drivers/clk/bcm/clk-bcm21664.c | 290 > > + > > drivers/clk/bcm/clk-bcm281xx.c | 12 - > > include/dt-bindings/clock/bcm21664.h | 62 + > > include/dt-bindings/clock/bcm281xx.h | 12 + > > 8 files changed, 565 insertions(+), 120 deletions(-) > > create mode 100644 drivers/clk/bcm/clk-bcm21664.c > > create mode 100644 include/dt-bindings/clock/bcm21664.h > > > > -- > > 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 RESEND 5/5] ARM: dts: use real clocks for bcm21664
On Mon, Apr 21, 2014 at 04:26:27PM -0500, Alex Elder wrote:
> Replace the "fake" fixed-rate clocks used previously for the
> bcm21664 family with "real" ones.
>
> Signed-off-by: Alex Elder
Acked-by: Matt Porter
> ---
> arch/arm/boot/dts/bcm21664.dtsi | 190
> +---
> 1 file changed, 118 insertions(+), 72 deletions(-)
>
> diff --git a/arch/arm/boot/dts/bcm21664.dtsi b/arch/arm/boot/dts/bcm21664.dtsi
> index 08a44d4..8b36682 100644
> --- a/arch/arm/boot/dts/bcm21664.dtsi
> +++ b/arch/arm/boot/dts/bcm21664.dtsi
> @@ -14,6 +14,8 @@
> #include
> #include
>
> +#include "dt-bindings/clock/bcm21664.h"
> +
> #include "skeleton.dtsi"
>
> / {
> @@ -43,7 +45,7 @@
> compatible = "brcm,bcm21664-dw-apb-uart", "snps,dw-apb-uart";
> status = "disabled";
> reg = <0x3e00 0x118>;
> - clocks = <&uartb_clk>;
> + clocks = <&slave_ccu BCM21664_SLAVE_CCU_UARTB>;
> interrupts = ;
> reg-shift = <2>;
> reg-io-width = <4>;
> @@ -53,7 +55,7 @@
> compatible = "brcm,bcm21664-dw-apb-uart", "snps,dw-apb-uart";
> status = "disabled";
> reg = <0x3e001000 0x118>;
> - clocks = <&uartb2_clk>;
> + clocks = <&slave_ccu BCM21664_SLAVE_CCU_UARTB2>;
> interrupts = ;
> reg-shift = <2>;
> reg-io-width = <4>;
> @@ -63,7 +65,7 @@
> compatible = "brcm,bcm21664-dw-apb-uart", "snps,dw-apb-uart";
> status = "disabled";
> reg = <0x3e002000 0x118>;
> - clocks = <&uartb3_clk>;
> + clocks = <&slave_ccu BCM21664_SLAVE_CCU_UARTB3>;
> interrupts = ;
> reg-shift = <2>;
> reg-io-width = <4>;
> @@ -85,7 +87,7 @@
> compatible = "brcm,kona-timer";
> reg = <0x35006000 0x1c>;
> interrupts = ;
> - clocks = <&hub_timer_clk>;
> + clocks = <&aon_ccu BCM21664_AON_CCU_HUB_TIMER>;
> };
>
> gpio: gpio@35003000 {
> @@ -106,7 +108,7 @@
> compatible = "brcm,kona-sdhci";
> reg = <0x3f18 0x801c>;
> interrupts = ;
> - clocks = <&sdio1_clk>;
> + clocks = <&master_ccu BCM21664_MASTER_CCU_SDIO1>;
> status = "disabled";
> };
>
> @@ -114,7 +116,7 @@
> compatible = "brcm,kona-sdhci";
> reg = <0x3f19 0x801c>;
> interrupts = ;
> - clocks = <&sdio2_clk>;
> + clocks = <&master_ccu BCM21664_MASTER_CCU_SDIO2>;
> status = "disabled";
> };
>
> @@ -122,7 +124,7 @@
> compatible = "brcm,kona-sdhci";
> reg = <0x3f1a 0x801c>;
> interrupts = ;
> - clocks = <&sdio3_clk>;
> + clocks = <&master_ccu BCM21664_MASTER_CCU_SDIO3>;
> status = "disabled";
> };
>
> @@ -130,7 +132,7 @@
> compatible = "brcm,kona-sdhci";
> reg = <0x3f1b 0x801c>;
> interrupts = ;
> - clocks = <&sdio4_clk>;
> + clocks = <&master_ccu BCM21664_MASTER_CCU_SDIO4>;
> status = "disabled";
> };
>
> @@ -140,7 +142,7 @@
> interrupts = ;
> #address-cells = <1>;
> #size-cells = <0>;
> - clocks = <&bsc1_clk>;
> + clocks = <&slave_ccu BCM21664_SLAVE_CCU_BSC1>;
> status = "disabled";
> };
>
> @@ -150,7 +152,7 @@
> interrupts = ;
> #address-cells = <1>;
> #size-cells = <0>;
> - clocks = <&bsc2_clk>;
> + clocks = <&slave_ccu BCM21664_SLAVE_CCU_BSC2>;
> status = "disabled";
> };
>
> @@ -160,7 +162,7 @@
> interrupts = ;
> #address-cells = <1>;
> #size-cells = <0>;
> - clocks = <&bsc3_clk>;
> +
[PATCH] dt: bindings: dwc2: fix required value for the phy-names property
"7408484 usb: gadget: s3c-hsotg: enable generic phy support" introduces generic phy support to the dwc2.txt binding and the s3c-hsotg driver which implements support for the binding. The binding documentation incorrectly states that the phy-names property will be "device". The binding example, driver, and one dts user all implement the phy-names property as requiring "usb2-phy". Fix the dwc2.txt binding documentation to correctly specify "usb2-phy" as the appropriate value for phy-names. Reported-by: Tomasz Figa Signed-off-by: Matt Porter --- Documentation/devicetree/bindings/usb/dwc2.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/usb/dwc2.txt b/Documentation/devicetree/bindings/usb/dwc2.txt index b8b6871..467ddd1 100644 --- a/Documentation/devicetree/bindings/usb/dwc2.txt +++ b/Documentation/devicetree/bindings/usb/dwc2.txt @@ -13,7 +13,7 @@ Refer to clk/clock-bindings.txt for generic clock consumer properties Optional properties: - phys: phy provider specifier -- phy-names: shall be "device" +- phy-names: shall be "usb2-phy" Refer to phy/phy-bindings.txt for generic phy consumer properties Example: -- 1.8.4 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/4] mfd: bcm590xx: update binding with additional BCM59056 regulators
The BCM59056 supports GPLDO1-6 and VBUS regulators in a secondary
I2C slave address space. Add these regulators to the list of valid
regulator node names for BCM59056.
Signed-off-by: Matt Porter
---
Documentation/devicetree/bindings/mfd/bcm590xx.txt | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/mfd/bcm590xx.txt
b/Documentation/devicetree/bindings/mfd/bcm590xx.txt
index 1fe30e2..be51a15 100644
--- a/Documentation/devicetree/bindings/mfd/bcm590xx.txt
+++ b/Documentation/devicetree/bindings/mfd/bcm590xx.txt
@@ -19,7 +19,9 @@ Optional child nodes:
The valid regulator node names for BCM59056 are:
rfldo, camldo1, camldo2, simldo1, simldo2, sdldo, sdxldo,
mmcldo1, mmcldo2, audldo, micldo, usbldo, vibldo,
- csr, iosr1, iosr2, msr, sdsr1, sdsr2, vsr
+ csr, iosr1, iosr2, msr, sdsr1, sdsr2, vsr,
+ gpldo1, gpldo2, gpldo3, gpldo4, gpldo5, gpldo6,
+ vbus
Example:
pmu: bcm59056@8 {
--
1.8.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/4] mfd: bcm590xx: add support for secondary I2C slave address
BCM590xx utilizes a secondary I2C slave address to access additional
register space. Add support for the secondary address space by
instantiating a dummy I2C device with the appropriate secondary
I2C slave address. Also expose a secondary regmap register space so
that MFD drivers can access this secondary i2c slave address space.
Signed-off-by: Matt Porter
---
drivers/mfd/bcm590xx.c | 60 +---
include/linux/mfd/bcm590xx.h | 9 ---
2 files changed, 52 insertions(+), 17 deletions(-)
diff --git a/drivers/mfd/bcm590xx.c b/drivers/mfd/bcm590xx.c
index e9a33c7..43cba1a 100644
--- a/drivers/mfd/bcm590xx.c
+++ b/drivers/mfd/bcm590xx.c
@@ -28,39 +28,71 @@ static const struct mfd_cell bcm590xx_devs[] = {
},
};
-static const struct regmap_config bcm590xx_regmap_config = {
+static const struct regmap_config bcm590xx_regmap_config_pri = {
.reg_bits = 8,
.val_bits = 8,
- .max_register = BCM590XX_MAX_REGISTER,
+ .max_register = BCM590XX_MAX_REGISTER_PRI,
.cache_type = REGCACHE_RBTREE,
};
-static int bcm590xx_i2c_probe(struct i2c_client *i2c,
+static const struct regmap_config bcm590xx_regmap_config_sec = {
+ .reg_bits = 8,
+ .val_bits = 8,
+ .max_register = BCM590XX_MAX_REGISTER_SEC,
+ .cache_type = REGCACHE_RBTREE,
+};
+
+static int bcm590xx_i2c_probe(struct i2c_client *i2c_pri,
const struct i2c_device_id *id)
{
struct bcm590xx *bcm590xx;
int ret;
- bcm590xx = devm_kzalloc(&i2c->dev, sizeof(*bcm590xx), GFP_KERNEL);
+ bcm590xx = devm_kzalloc(&i2c_pri->dev, sizeof(*bcm590xx), GFP_KERNEL);
if (!bcm590xx)
return -ENOMEM;
- i2c_set_clientdata(i2c, bcm590xx);
- bcm590xx->dev = &i2c->dev;
- bcm590xx->i2c_client = i2c;
+ i2c_set_clientdata(i2c_pri, bcm590xx);
+ bcm590xx->dev = &i2c_pri->dev;
+ bcm590xx->i2c_pri = i2c_pri;
- bcm590xx->regmap = devm_regmap_init_i2c(i2c, &bcm590xx_regmap_config);
- if (IS_ERR(bcm590xx->regmap)) {
- ret = PTR_ERR(bcm590xx->regmap);
- dev_err(&i2c->dev, "regmap initialization failed: %d\n", ret);
+ bcm590xx->regmap_pri = devm_regmap_init_i2c(i2c_pri,
+&bcm590xx_regmap_config_pri);
+ if (IS_ERR(bcm590xx->regmap_pri)) {
+ ret = PTR_ERR(bcm590xx->regmap_pri);
+ dev_err(&i2c_pri->dev, "primary regmap init failed: %d\n", ret);
return ret;
}
- ret = mfd_add_devices(&i2c->dev, -1, bcm590xx_devs,
+ /* Secondary I2C slave address is the base address with A(2) asserted */
+ bcm590xx->i2c_sec = i2c_new_dummy(i2c_pri->adapter,
+ i2c_pri->addr | BIT(2));
+ if (IS_ERR_OR_NULL(bcm590xx->i2c_sec)) {
+ dev_err(&i2c_pri->dev, "failed to add secondary I2C device\n");
+ return -ENODEV;
+ }
+ i2c_set_clientdata(bcm590xx->i2c_sec, bcm590xx);
+
+ bcm590xx->regmap_sec = devm_regmap_init_i2c(bcm590xx->i2c_sec,
+ &bcm590xx_regmap_config_sec);
+ if (IS_ERR(bcm590xx->regmap_sec)) {
+ ret = PTR_ERR(bcm590xx->regmap_sec);
+ dev_err(&bcm590xx->i2c_sec->dev,
+ "secondary regmap init failed: %d\n", ret);
+ goto err;
+ }
+
+ ret = mfd_add_devices(&i2c_pri->dev, -1, bcm590xx_devs,
ARRAY_SIZE(bcm590xx_devs), NULL, 0, NULL);
- if (ret < 0)
- dev_err(&i2c->dev, "failed to add sub-devices: %d\n", ret);
+ if (ret < 0) {
+ dev_err(&i2c_pri->dev, "failed to add sub-devices: %d\n", ret);
+ goto err;
+ }
+
+ return 0;
+err:
+ i2c_unregister_device(bcm590xx->i2c_sec);
return ret;
}
diff --git a/include/linux/mfd/bcm590xx.h b/include/linux/mfd/bcm590xx.h
index 434df2d..267aede 100644
--- a/include/linux/mfd/bcm590xx.h
+++ b/include/linux/mfd/bcm590xx.h
@@ -19,12 +19,15 @@
#include
/* max register address */
-#define BCM590XX_MAX_REGISTER 0xe7
+#define BCM590XX_MAX_REGISTER_PRI 0xe7
+#define BCM590XX_MAX_REGISTER_SEC 0xf0
struct bcm590xx {
struct device *dev;
- struct i2c_client *i2c_client;
- struct regmap *regmap;
+ struct i2c_client *i2c_pri;
+ struct i2c_client *i2c_sec;
+ struct regmap *regmap_pri;
+ struct regmap *regmap_sec;
unsigned int id;
};
--
1.8.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 4/4] ARM: dts: bcm590xx: add support for GPLDO and VBUS regulators
Adds additional nodes to support GPLDO1-6 and VBUS regulators which
are now supported in the bcm590xx regulator driver.
Signed-off-by: Matt Porter
---
arch/arm/boot/dts/bcm59056.dtsi | 21 +
1 file changed, 21 insertions(+)
diff --git a/arch/arm/boot/dts/bcm59056.dtsi b/arch/arm/boot/dts/bcm59056.dtsi
index dfadaaa..066adfb 100644
--- a/arch/arm/boot/dts/bcm59056.dtsi
+++ b/arch/arm/boot/dts/bcm59056.dtsi
@@ -70,5 +70,26 @@
vsr_reg: vsr {
};
+
+ gpldo1_reg: gpldo1 {
+ };
+
+ gpldo2_reg: gpldo2 {
+ };
+
+ gpldo3_reg: gpldo3 {
+ };
+
+ gpldo4_reg: gpldo4 {
+ };
+
+ gpldo5_reg: gpldo5 {
+ };
+
+ gpldo6_reg: gpldo6 {
+ };
+
+ vbus_reg: vbus {
+ };
};
};
--
1.8.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 3/4] regulator: bcm590xx: add support for regulators on secondary I2C slave
The bcm590xx MFD driver now exposes a secondary regmap descriptor
making the registers for regulators on the secondary I2C slave address
available. Add support for GPLDO1-6 and VBUS regulators found within
this register range.
Signed-off-by: Matt Porter
Acked-by: Mark Brown
---
drivers/regulator/bcm590xx-regulator.c | 92 ++
1 file changed, 82 insertions(+), 10 deletions(-)
diff --git a/drivers/regulator/bcm590xx-regulator.c
b/drivers/regulator/bcm590xx-regulator.c
index c3750c5..57544e2 100644
--- a/drivers/regulator/bcm590xx-regulator.c
+++ b/drivers/regulator/bcm590xx-regulator.c
@@ -22,7 +22,7 @@
#include
#include
-/* Register defs */
+/* I2C slave 0 registers */
#define BCM590XX_RFLDOPMCTRL1 0x60
#define BCM590XX_IOSR1PMCTRL1 0x7a
#define BCM590XX_IOSR2PMCTRL1 0x7c
@@ -31,13 +31,34 @@
#define BCM590XX_SDSR2PMCTRL1 0x86
#define BCM590XX_MSRPMCTRL10x8a
#define BCM590XX_VSRPMCTRL10x8e
-#define BCM590XX_REG_ENABLEBIT(7)
-
#define BCM590XX_RFLDOCTRL 0x96
#define BCM590XX_CSRVOUT1 0xc0
+
+/* I2C slave 1 registers */
+#define BCM590XX_GPLDO5PMCTRL1 0x16
+#define BCM590XX_GPLDO6PMCTRL1 0x18
+#define BCM590XX_GPLDO1CTRL0x1a
+#define BCM590XX_GPLDO2CTRL0x1b
+#define BCM590XX_GPLDO3CTRL0x1c
+#define BCM590XX_GPLDO4CTRL0x1d
+#define BCM590XX_GPLDO5CTRL0x1e
+#define BCM590XX_GPLDO6CTRL0x1f
+#define BCM590XX_OTG_CTRL 0x40
+#define BCM590XX_GPLDO1PMCTRL1 0x57
+#define BCM590XX_GPLDO2PMCTRL1 0x59
+#define BCM590XX_GPLDO3PMCTRL1 0x5b
+#define BCM590XX_GPLDO4PMCTRL1 0x5d
+
+#define BCM590XX_REG_ENABLEBIT(7)
+#define BCM590XX_VBUS_ENABLE BIT(2)
#define BCM590XX_LDO_VSEL_MASK GENMASK(5, 3)
#define BCM590XX_SR_VSEL_MASK GENMASK(5, 0)
+/*
+ * RFLDO to VSR regulators are
+ * accessed via I2C slave 0
+ */
+
/* LDO regulator IDs */
#define BCM590XX_REG_RFLDO 0
#define BCM590XX_REG_CAMLDO1 1
@@ -62,9 +83,25 @@
#define BCM590XX_REG_SDSR2 18
#define BCM590XX_REG_VSR 19
-#define BCM590XX_NUM_REGS 20
+/*
+ * GPLDO1 to VBUS regulators are
+ * accessed via I2C slave 1
+ */
+
+#define BCM590XX_REG_GPLDO120
+#define BCM590XX_REG_GPLDO221
+#define BCM590XX_REG_GPLDO322
+#define BCM590XX_REG_GPLDO423
+#define BCM590XX_REG_GPLDO524
+#define BCM590XX_REG_GPLDO625
+#define BCM590XX_REG_VBUS 26
+
+#define BCM590XX_NUM_REGS 27
#define BCM590XX_REG_IS_LDO(n) (n < BCM590XX_REG_CSR)
+#define BCM590XX_REG_IS_GPLDO(n) \
+ ((n > BCM590XX_REG_VSR) && (n < BCM590XX_REG_VBUS))
+#define BCM590XX_REG_IS_VBUS(n)(n == BCM590XX_REG_VBUS)
struct bcm590xx_board {
struct regulator_init_data *bcm590xx_pmu_init_data[BCM590XX_NUM_REGS];
@@ -149,6 +186,12 @@ static struct bcm590xx_info bcm590xx_regs[] = {
BCM590XX_REG_RANGES(sdsr1, dcdc_sdsr1_ranges),
BCM590XX_REG_RANGES(sdsr2, dcdc_iosr1_ranges),
BCM590XX_REG_RANGES(vsr, dcdc_iosr1_ranges),
+ BCM590XX_REG_TABLE(gpldo1, ldo_a_table),
+ BCM590XX_REG_TABLE(gpldo2, ldo_a_table),
+ BCM590XX_REG_TABLE(gpldo3, ldo_a_table),
+ BCM590XX_REG_TABLE(gpldo4, ldo_a_table),
+ BCM590XX_REG_TABLE(gpldo5, ldo_a_table),
+ BCM590XX_REG_TABLE(gpldo6, ldo_a_table),
};
struct bcm590xx_reg {
@@ -161,6 +204,8 @@ static int bcm590xx_get_vsel_register(int id)
{
if (BCM590XX_REG_IS_LDO(id))
return BCM590XX_RFLDOCTRL + id;
+ else if (BCM590XX_REG_IS_GPLDO(id))
+ return BCM590XX_GPLDO1CTRL + id;
else
return BCM590XX_CSRVOUT1 + (id - BCM590XX_REG_CSR) * 3;
}
@@ -171,6 +216,8 @@ static int bcm590xx_get_enable_register(int id)
if (BCM590XX_REG_IS_LDO(id))
reg = BCM590XX_RFLDOPMCTRL1 + id * 2;
+ else if (BCM590XX_REG_IS_GPLDO(id))
+ reg = BCM590XX_GPLDO1PMCTRL1 + id * 2;
else
switch (id) {
case BCM590XX_REG_CSR:
@@ -191,8 +238,11 @@ static int bcm590xx_get_enable_register(int id)
case BCM590XX_REG_SDSR2:
reg = BCM590XX_SDSR2PMCTRL1;
break;
+ case BCM590XX_REG_VBUS:
+ reg = BCM590XX_OTG_CTRL;
};
+
return reg;
}
@@ -216,6 +266,12 @@ static struct regulator_ops bcm590xx_ops_dcdc = {
.map_voltage= regulator_map_voltage_linear_range,
};
+static struct regulator_ops bcm590xx_ops_vbus = {
+ .is_enabled = regulator_is_enabled_regmap,
+ .enable = regulator_enable_regmap,
+ .disable= regulator_disable_regmap,
+};
+
#define BCM590XX_MATCH(_name, _id) \
{ \
.name = #_name, \
@@ -243,6 +299,13 @@ static struct of_regulator_match bcm590xx_matches[] = {
BCM590XX_MATCH(sdsr1, SDSR1),
BCM590XX_MATCH(sdsr2, SDSR2),
BCM590XX_MATCH(vsr, VSR),
+ BCM590XX_MAT
[PATCH v2 0/4] Support additional regulators on BCM590xx
Changes since v1: - Fix a several commit log typos and capitalization - Drop use of addmap[0|1] in favor of i2c_[pri|sec] - Replace regmap[0|1] with regmap_[pri|sec] This series enables support for 7 additional regulators on the BCM59056 PMU. These regulators are accessed via a secondary I2C slave address. The MFD driver exposes an additional regmap descriptor for the additional address space and the regulator implements support for GPLDO1-6 and VBUS regulators. Matt Porter (4): mfd: bcm590xx: update binding with additional BCM59056 regulators mfd: bcm590xx: add support for secondary I2C slave address regulator: bcm590xx: add support for regulators on secondary I2C slave ARM: dts: bcm590xx: add support for GPLDO and VBUS regulators Documentation/devicetree/bindings/mfd/bcm590xx.txt | 4 +- arch/arm/boot/dts/bcm59056.dtsi| 21 + drivers/mfd/bcm590xx.c | 60 ++ drivers/regulator/bcm590xx-regulator.c | 92 +++--- include/linux/mfd/bcm590xx.h | 9 ++- 5 files changed, 158 insertions(+), 28 deletions(-) -- 1.8.4 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] mfd: bcm590xx: add support for second i2c slave address space
On Wed, Apr 23, 2014 at 06:01:26PM -0400, Matt Porter wrote:
> On Tue, Apr 22, 2014 at 09:21:39AM +0100, Lee Jones wrote:
> > > > > > s/regmap/Regmap
> > > > >
> > > > > It's consistently written regmap in all the documentation and so on :)
> > > >
> > > > Furry muff; but the comments still stand for the acronyms.
> > > >
> > > > > > addmap{0,1} doesn't quite sit right with me.
> > > > >
> > > > > > REVISIT: Ah, it's address-map, rather than add map. Okay, not as bad
> > > > > > as I first thought, but still, is there a better naming convention
> > > > > > you
> > > > > > could use?
> > > > >
> > > > > addrmap or something?
> > > >
> > > > Right, that was what I was thinking. However, I prefer something along
> > > > the lines of 'i2c' and 'i2c_sec' or 'client' and 'client_slv' etc.
> > >
> > > FWIW, the reason it's addmap{0,1} is that the datasheet has documents
> > > ADDMAP=0 and the first bank of registers and ADDMAP=1 as the second bank
> > > of registers. I adopted that to match the docs for the part.
> > >
> > > I guess we could do i2c and i2c_sec, I'll just have to put a comment
> > > correlating it to the h/w. Calling it 'slv' implies something else
> > > so we should avoid that here. The notion of a "secondary" i2c device
> > > is completely a Linux I2C subsystem fabrication which wouldn't exist
> > > if it allowed multiple slave addresses per device. From a h/w
> > > perspective there is really no primary and secondary relationship.
> > >
> > > I'm fine with i2c/i2c_sec or addrmap0/1 and I will just comment to
> > > correlate with the datasheet..pick one.
> >
> > Let's stick method fabricated by the I2C subsystem. It may seem strange
> > from a h/w perspective, but it is the way we (you) have coded it, as
> > the first parameter of i2c_new_dummy() is the 'managing' (primary,
> > parent, master, whatever) device, so '_sec' would suit as an
> > identifying appendage for the resultant device.
>
> That works, I'll also switch to addrmap_[pri|sec] which touches the
> regulator driver as well. That will keep the relationship between device
> and regmap clear.
Misspoke...I'm switching regmap[0|1] to regmap_[pri|sec] to keep that
synced with i2c_[pri|sec]
-Matt
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] mfd: bcm590xx: add support for second i2c slave address space
On Tue, Apr 22, 2014 at 09:21:39AM +0100, Lee Jones wrote:
> > > > > s/regmap/Regmap
> > > >
> > > > It's consistently written regmap in all the documentation and so on :)
> > >
> > > Furry muff; but the comments still stand for the acronyms.
> > >
> > > > > addmap{0,1} doesn't quite sit right with me.
> > > >
> > > > > REVISIT: Ah, it's address-map, rather than add map. Okay, not as bad
> > > > > as I first thought, but still, is there a better naming convention you
> > > > > could use?
> > > >
> > > > addrmap or something?
> > >
> > > Right, that was what I was thinking. However, I prefer something along
> > > the lines of 'i2c' and 'i2c_sec' or 'client' and 'client_slv' etc.
> >
> > FWIW, the reason it's addmap{0,1} is that the datasheet has documents
> > ADDMAP=0 and the first bank of registers and ADDMAP=1 as the second bank
> > of registers. I adopted that to match the docs for the part.
> >
> > I guess we could do i2c and i2c_sec, I'll just have to put a comment
> > correlating it to the h/w. Calling it 'slv' implies something else
> > so we should avoid that here. The notion of a "secondary" i2c device
> > is completely a Linux I2C subsystem fabrication which wouldn't exist
> > if it allowed multiple slave addresses per device. From a h/w
> > perspective there is really no primary and secondary relationship.
> >
> > I'm fine with i2c/i2c_sec or addrmap0/1 and I will just comment to
> > correlate with the datasheet..pick one.
>
> Let's stick method fabricated by the I2C subsystem. It may seem strange
> from a h/w perspective, but it is the way we (you) have coded it, as
> the first parameter of i2c_new_dummy() is the 'managing' (primary,
> parent, master, whatever) device, so '_sec' would suit as an
> identifying appendage for the resultant device.
That works, I'll also switch to addrmap_[pri|sec] which touches the
regulator driver as well. That will keep the relationship between device
and regmap clear.
-Matt
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RESEND 4/5] ARM: BCM63XX: add BCM963138DVT Reference platform DTS
On Mon, Apr 21, 2014 at 06:39:17PM -0700, Florian Fainelli wrote:
> Add a DTS file for the Broadcom BCM963138DVT reference platform board
> which leverages the bcm63138.dtsi SoC DTSi file.
>
> Signed-off-by: Florian Fainelli
> ---
> arch/arm/boot/dts/Makefile| 3 +++
> arch/arm/boot/dts/bcm63138dvt.dts | 18 ++
> 2 files changed, 21 insertions(+)
> create mode 100644 arch/arm/boot/dts/bcm63138dvt.dts
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 35c146f31e46..2738fa6e950d 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -53,8 +53,11 @@ dtb-$(CONFIG_ARCH_ATLAS6) += atlas6-evb.dtb
> dtb-$(CONFIG_ARCH_BCM2835) += bcm2835-rpi-b.dtb
> dtb-$(CONFIG_ARCH_BCM_MOBILE) += bcm28155-ap.dtb \
> bcm21664-garnet.dtb
> +dtb-$(CONFIG_ARCH_BCM_MOBILE) += bcm11351-brt.dtb \
> + bcm28155-ap.dtb
Remove this stray change.
> dtb-$(CONFIG_ARCH_BCM2835) += bcm2835-rpi-b.dtb
> dtb-$(CONFIG_ARCH_BCM_5301X) += bcm4708-netgear-r6250.dtb
> +dtb-$(CONFIG_ARCH_BCM_63XX) += bcm63138dvt.dtb
> dtb-$(CONFIG_ARCH_BERLIN) += \
> berlin2-sony-nsz-gs7.dtb\
> berlin2cd-google-chromecast.dtb
> diff --git a/arch/arm/boot/dts/bcm63138dvt.dts
> b/arch/arm/boot/dts/bcm63138dvt.dts
> new file mode 100644
> index ..e212b4731978
> --- /dev/null
> +++ b/arch/arm/boot/dts/bcm63138dvt.dts
> @@ -0,0 +1,18 @@
> +/*
> + * Broadcom BCM63138 Reference Board DTS
> + *
> + * Copyright (C) 2014 Broadcom Corporation
> + */
> +
> +/dts-v1/;
> +
> +#include "bcm63138.dtsi"
> +
> +/ {
> + compatible = "BCM963138DVT", "brcm,bcm63138";
The specific board compatible string needs a vendor prefix. Also,
there's only some rare old examples that use upper case in their
compatible strings. Let's conform to what 99% of compatible strings
do here and have:
compatible = "brcm,bcm963138dvt", "brcm,bcm63138";
Along the lines of Jonas' question? Is there really a "9" prepended in
this board name given that the filename is bcm63138dvt.dts? Either way,
this should be consistent between compatible and filename.
-Matt
> + model = "Broadcom BCM963138DVT";
> +
> + memory {
> + reg = <0x0 0x0800>;
> + };
> +};
> --
> 1.9.1
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] mfd: bcm590xx: add support for second i2c slave address space
On Wed, Apr 16, 2014 at 12:06:03PM +0100, Lee Jones wrote:
> On Mon, 14 Apr 2014, Matt Porter wrote:
>
> > BCM590xx utilizes a second i2c slave address to access additional
>
> s/i2c/I2C
>
> > register space. Add support for the second address space by
> > instantiated a dummy i2c device with the appropriate secondary
>
> s/instantiated/instantiating
>
> > i2c slave address. Expose a second regmap register space so that
>
> s/i2c/I2C
>
> Exposing?
>
> s/regmap/Regmap
>
> > mfd drivers can access this secondary i2c slave address space.
>
> s/mfd/MFD
>
> s/i2c/I2C
Ok, I'll fix the capitalization and wording..except for regmap as
noted by Mark.
>
> > Signed-off-by: Matt Porter
> > ---
> > drivers/mfd/bcm590xx.c | 60
> > +---
> > include/linux/mfd/bcm590xx.h | 9 ---
> > 2 files changed, 52 insertions(+), 17 deletions(-)
> >
> > diff --git a/drivers/mfd/bcm590xx.c b/drivers/mfd/bcm590xx.c
> > index e9a33c7..b710ffa 100644
> > --- a/drivers/mfd/bcm590xx.c
> > +++ b/drivers/mfd/bcm590xx.c
> > @@ -28,39 +28,71 @@ static const struct mfd_cell bcm590xx_devs[] = {
> > },
> > };
> >
> > -static const struct regmap_config bcm590xx_regmap_config = {
> > +static const struct regmap_config bcm590xx_regmap_config_0 = {
>
> Not loving _0 and _1 appendages.
>
> Is one of them {primary|master} and the other {secondary|slave}?
I guess from a Linux I2C subsystem, we can view _1 as the
"secondary"...it does correspond the the i2c_new_dummy() device
that we create in the mfd probe. That device corresponds to the
ADDMAP=1 address on the PMU. This is why I used those appendages.
-Matt
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] mfd: bcm590xx: add support for second i2c slave address space
On Thu, Apr 17, 2014 at 07:57:53AM +0100, Lee Jones wrote:
> > > s/regmap/Regmap
> >
> > It's consistently written regmap in all the documentation and so on :)
>
> Furry muff; but the comments still stand for the acronyms.
>
> > > addmap{0,1} doesn't quite sit right with me.
> >
> > > REVISIT: Ah, it's address-map, rather than add map. Okay, not as bad
> > > as I first thought, but still, is there a better naming convention you
> > > could use?
> >
> > addrmap or something?
>
> Right, that was what I was thinking. However, I prefer something along
> the lines of 'i2c' and 'i2c_sec' or 'client' and 'client_slv' etc.
FWIW, the reason it's addmap{0,1} is that the datasheet has documents
ADDMAP=0 and the first bank of registers and ADDMAP=1 as the second bank
of registers. I adopted that to match the docs for the part.
I guess we could do i2c and i2c_sec, I'll just have to put a comment
correlating it to the h/w. Calling it 'slv' implies something else
so we should avoid that here. The notion of a "secondary" i2c device
is completely a Linux I2C subsystem fabrication which wouldn't exist
if it allowed multiple slave addresses per device. From a h/w
perspective there is really no primary and secondary relationship.
I'm fine with i2c/i2c_sec or addrmap0/1 and I will just comment to
correlate with the datasheet..pick one.
-Matt
>
> --
> Lee Jones
> Linaro STMicroelectronics Landing Team Lead
> Linaro.org │ Open source software for ARM SoCs
> Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/4] mfd: bcm590xx: add support for second i2c slave address space
BCM590xx utilizes a second i2c slave address to access additional
register space. Add support for the second address space by
instantiated a dummy i2c device with the appropriate secondary
i2c slave address. Expose a second regmap register space so that
mfd drivers can access this secondary i2c slave address space.
Signed-off-by: Matt Porter
---
drivers/mfd/bcm590xx.c | 60 +---
include/linux/mfd/bcm590xx.h | 9 ---
2 files changed, 52 insertions(+), 17 deletions(-)
diff --git a/drivers/mfd/bcm590xx.c b/drivers/mfd/bcm590xx.c
index e9a33c7..b710ffa 100644
--- a/drivers/mfd/bcm590xx.c
+++ b/drivers/mfd/bcm590xx.c
@@ -28,39 +28,71 @@ static const struct mfd_cell bcm590xx_devs[] = {
},
};
-static const struct regmap_config bcm590xx_regmap_config = {
+static const struct regmap_config bcm590xx_regmap_config_0 = {
.reg_bits = 8,
.val_bits = 8,
- .max_register = BCM590XX_MAX_REGISTER,
+ .max_register = BCM590XX_MAX_REGISTER_0,
.cache_type = REGCACHE_RBTREE,
};
-static int bcm590xx_i2c_probe(struct i2c_client *i2c,
+static const struct regmap_config bcm590xx_regmap_config_1 = {
+ .reg_bits = 8,
+ .val_bits = 8,
+ .max_register = BCM590XX_MAX_REGISTER_1,
+ .cache_type = REGCACHE_RBTREE,
+};
+
+static int bcm590xx_i2c_probe(struct i2c_client *addmap0,
const struct i2c_device_id *id)
{
struct bcm590xx *bcm590xx;
int ret;
- bcm590xx = devm_kzalloc(&i2c->dev, sizeof(*bcm590xx), GFP_KERNEL);
+ bcm590xx = devm_kzalloc(&addmap0->dev, sizeof(*bcm590xx), GFP_KERNEL);
if (!bcm590xx)
return -ENOMEM;
- i2c_set_clientdata(i2c, bcm590xx);
- bcm590xx->dev = &i2c->dev;
- bcm590xx->i2c_client = i2c;
+ i2c_set_clientdata(addmap0, bcm590xx);
+ bcm590xx->dev = &addmap0->dev;
+ bcm590xx->addmap0 = addmap0;
- bcm590xx->regmap = devm_regmap_init_i2c(i2c, &bcm590xx_regmap_config);
- if (IS_ERR(bcm590xx->regmap)) {
- ret = PTR_ERR(bcm590xx->regmap);
- dev_err(&i2c->dev, "regmap initialization failed: %d\n", ret);
+ bcm590xx->regmap0 = devm_regmap_init_i2c(addmap0,
+&bcm590xx_regmap_config_0);
+ if (IS_ERR(bcm590xx->regmap0)) {
+ ret = PTR_ERR(bcm590xx->regmap0);
+ dev_err(&addmap0->dev, "regmap 0 init failed: %d\n", ret);
return ret;
}
- ret = mfd_add_devices(&i2c->dev, -1, bcm590xx_devs,
+ /* Second I2C slave address is the base address with A(2) asserted */
+ bcm590xx->addmap1 = i2c_new_dummy(addmap0->adapter,
+ addmap0->addr | BIT(2));
+ if (IS_ERR_OR_NULL(bcm590xx->addmap1)) {
+ dev_err(&addmap0->dev, "failed to add address map 1 device\n");
+ return -ENODEV;
+ }
+ i2c_set_clientdata(bcm590xx->addmap1, bcm590xx);
+
+ bcm590xx->regmap1 = devm_regmap_init_i2c(bcm590xx->addmap1,
+ &bcm590xx_regmap_config_1);
+ if (IS_ERR(bcm590xx->regmap1)) {
+ ret = PTR_ERR(bcm590xx->regmap1);
+ dev_err(&bcm590xx->addmap1->dev,
+ "regmap 1 init failed: %d\n", ret);
+ goto err;
+ }
+
+ ret = mfd_add_devices(&addmap0->dev, -1, bcm590xx_devs,
ARRAY_SIZE(bcm590xx_devs), NULL, 0, NULL);
- if (ret < 0)
- dev_err(&i2c->dev, "failed to add sub-devices: %d\n", ret);
+ if (ret < 0) {
+ dev_err(&addmap0->dev, "failed to add sub-devices: %d\n", ret);
+ goto err;
+ }
+
+ return 0;
+err:
+ i2c_unregister_device(bcm590xx->addmap1);
return ret;
}
diff --git a/include/linux/mfd/bcm590xx.h b/include/linux/mfd/bcm590xx.h
index 434df2d..a2723f2 100644
--- a/include/linux/mfd/bcm590xx.h
+++ b/include/linux/mfd/bcm590xx.h
@@ -19,12 +19,15 @@
#include
/* max register address */
-#define BCM590XX_MAX_REGISTER 0xe7
+#define BCM590XX_MAX_REGISTER_00xe7
+#define BCM590XX_MAX_REGISTER_10xf0
struct bcm590xx {
struct device *dev;
- struct i2c_client *i2c_client;
- struct regmap *regmap;
+ struct i2c_client *addmap0;
+ struct i2c_client *addmap1;
+ struct regmap *regmap0;
+ struct regmap *regmap1;
unsigned int id;
};
--
1.8.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/4] ARM: dts: bcm590xx: add support for GPLDO and VBUS regulators
Adds additional nodes to support GPLDO1-6 and VBUS regulators which
are not supported in the bcm590xx regulator driver.
Signed-off-by: Matt Porter
---
arch/arm/boot/dts/bcm59056.dtsi | 21 +
1 file changed, 21 insertions(+)
diff --git a/arch/arm/boot/dts/bcm59056.dtsi b/arch/arm/boot/dts/bcm59056.dtsi
index dfadaaa..066adfb 100644
--- a/arch/arm/boot/dts/bcm59056.dtsi
+++ b/arch/arm/boot/dts/bcm59056.dtsi
@@ -70,5 +70,26 @@
vsr_reg: vsr {
};
+
+ gpldo1_reg: gpldo1 {
+ };
+
+ gpldo2_reg: gpldo2 {
+ };
+
+ gpldo3_reg: gpldo3 {
+ };
+
+ gpldo4_reg: gpldo4 {
+ };
+
+ gpldo5_reg: gpldo5 {
+ };
+
+ gpldo6_reg: gpldo6 {
+ };
+
+ vbus_reg: vbus {
+ };
};
};
--
1.8.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/4] regulator: bcm590xx: add support for regulators on secondary i2c slave
The bcm590xx mfd driver now exposes a second regmap descriptor making
the registers for regulators on the secondary i2c slave address
available. Add support for GPLDO1-6 and VBUS regulators found within
this register range.
Signed-off-by: Matt Porter
---
drivers/regulator/bcm590xx-regulator.c | 92 ++
1 file changed, 82 insertions(+), 10 deletions(-)
diff --git a/drivers/regulator/bcm590xx-regulator.c
b/drivers/regulator/bcm590xx-regulator.c
index c3750c5..4f0b5d9 100644
--- a/drivers/regulator/bcm590xx-regulator.c
+++ b/drivers/regulator/bcm590xx-regulator.c
@@ -22,7 +22,7 @@
#include
#include
-/* Register defs */
+/* I2C slave 0 registers */
#define BCM590XX_RFLDOPMCTRL1 0x60
#define BCM590XX_IOSR1PMCTRL1 0x7a
#define BCM590XX_IOSR2PMCTRL1 0x7c
@@ -31,13 +31,34 @@
#define BCM590XX_SDSR2PMCTRL1 0x86
#define BCM590XX_MSRPMCTRL10x8a
#define BCM590XX_VSRPMCTRL10x8e
-#define BCM590XX_REG_ENABLEBIT(7)
-
#define BCM590XX_RFLDOCTRL 0x96
#define BCM590XX_CSRVOUT1 0xc0
+
+/* I2C slave 1 registers */
+#define BCM590XX_GPLDO5PMCTRL1 0x16
+#define BCM590XX_GPLDO6PMCTRL1 0x18
+#define BCM590XX_GPLDO1CTRL0x1a
+#define BCM590XX_GPLDO2CTRL0x1b
+#define BCM590XX_GPLDO3CTRL0x1c
+#define BCM590XX_GPLDO4CTRL0x1d
+#define BCM590XX_GPLDO5CTRL0x1e
+#define BCM590XX_GPLDO6CTRL0x1f
+#define BCM590XX_OTG_CTRL 0x40
+#define BCM590XX_GPLDO1PMCTRL1 0x57
+#define BCM590XX_GPLDO2PMCTRL1 0x59
+#define BCM590XX_GPLDO3PMCTRL1 0x5b
+#define BCM590XX_GPLDO4PMCTRL1 0x5d
+
+#define BCM590XX_REG_ENABLEBIT(7)
+#define BCM590XX_VBUS_ENABLE BIT(2)
#define BCM590XX_LDO_VSEL_MASK GENMASK(5, 3)
#define BCM590XX_SR_VSEL_MASK GENMASK(5, 0)
+/*
+ * RFLDO to VSR regulators are
+ * accessed via I2C slave 0
+ */
+
/* LDO regulator IDs */
#define BCM590XX_REG_RFLDO 0
#define BCM590XX_REG_CAMLDO1 1
@@ -62,9 +83,25 @@
#define BCM590XX_REG_SDSR2 18
#define BCM590XX_REG_VSR 19
-#define BCM590XX_NUM_REGS 20
+/*
+ * GPLDO1 to VBUS regulators are
+ * accessed via I2C slave 1
+ */
+
+#define BCM590XX_REG_GPLDO120
+#define BCM590XX_REG_GPLDO221
+#define BCM590XX_REG_GPLDO322
+#define BCM590XX_REG_GPLDO423
+#define BCM590XX_REG_GPLDO524
+#define BCM590XX_REG_GPLDO625
+#define BCM590XX_REG_VBUS 26
+
+#define BCM590XX_NUM_REGS 27
#define BCM590XX_REG_IS_LDO(n) (n < BCM590XX_REG_CSR)
+#define BCM590XX_REG_IS_GPLDO(n) \
+ ((n > BCM590XX_REG_VSR) && (n < BCM590XX_REG_VBUS))
+#define BCM590XX_REG_IS_VBUS(n)(n == BCM590XX_REG_VBUS)
struct bcm590xx_board {
struct regulator_init_data *bcm590xx_pmu_init_data[BCM590XX_NUM_REGS];
@@ -149,6 +186,12 @@ static struct bcm590xx_info bcm590xx_regs[] = {
BCM590XX_REG_RANGES(sdsr1, dcdc_sdsr1_ranges),
BCM590XX_REG_RANGES(sdsr2, dcdc_iosr1_ranges),
BCM590XX_REG_RANGES(vsr, dcdc_iosr1_ranges),
+ BCM590XX_REG_TABLE(gpldo1, ldo_a_table),
+ BCM590XX_REG_TABLE(gpldo2, ldo_a_table),
+ BCM590XX_REG_TABLE(gpldo3, ldo_a_table),
+ BCM590XX_REG_TABLE(gpldo4, ldo_a_table),
+ BCM590XX_REG_TABLE(gpldo5, ldo_a_table),
+ BCM590XX_REG_TABLE(gpldo6, ldo_a_table),
};
struct bcm590xx_reg {
@@ -161,6 +204,8 @@ static int bcm590xx_get_vsel_register(int id)
{
if (BCM590XX_REG_IS_LDO(id))
return BCM590XX_RFLDOCTRL + id;
+ else if (BCM590XX_REG_IS_GPLDO(id))
+ return BCM590XX_GPLDO1CTRL + id;
else
return BCM590XX_CSRVOUT1 + (id - BCM590XX_REG_CSR) * 3;
}
@@ -171,6 +216,8 @@ static int bcm590xx_get_enable_register(int id)
if (BCM590XX_REG_IS_LDO(id))
reg = BCM590XX_RFLDOPMCTRL1 + id * 2;
+ else if (BCM590XX_REG_IS_GPLDO(id))
+ reg = BCM590XX_GPLDO1PMCTRL1 + id * 2;
else
switch (id) {
case BCM590XX_REG_CSR:
@@ -191,8 +238,11 @@ static int bcm590xx_get_enable_register(int id)
case BCM590XX_REG_SDSR2:
reg = BCM590XX_SDSR2PMCTRL1;
break;
+ case BCM590XX_REG_VBUS:
+ reg = BCM590XX_OTG_CTRL;
};
+
return reg;
}
@@ -216,6 +266,12 @@ static struct regulator_ops bcm590xx_ops_dcdc = {
.map_voltage= regulator_map_voltage_linear_range,
};
+static struct regulator_ops bcm590xx_ops_vbus = {
+ .is_enabled = regulator_is_enabled_regmap,
+ .enable = regulator_enable_regmap,
+ .disable= regulator_disable_regmap,
+};
+
#define BCM590XX_MATCH(_name, _id) \
{ \
.name = #_name, \
@@ -243,6 +299,13 @@ static struct of_regulator_match bcm590xx_matches[] = {
BCM590XX_MATCH(sdsr1, SDSR1),
BCM590XX_MATCH(sdsr2, SDSR2),
BCM590XX_MATCH(vsr, VSR),
+ BCM590XX_MATCH(gpldo1, GPLDO1),
+
