* Re: [PATCH V5 1/3] dt-bindings: mtd: document linux,part-probe property
From: Brian Norris @ 2017-04-19 20:37 UTC (permalink / raw)
To: Rafał Miłecki
Cc: David Woodhouse, Boris Brezillon, Marek Vasut, Richard Weinberger,
Cyrille Pitchen, Rob Herring, Mark Rutland, Frank Rowand,
Linus Walleij, linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, Rafał Miłecki
In-Reply-To: <20170417194746.10697-1-zajec5-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Hi,
On Mon, Apr 17, 2017 at 09:47:44PM +0200, Rafał Miłecki wrote:
> From: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
>
> Support for this property has been introduced in 2010 with commit
> 9d5da3a9b849 ("mtd: extend physmap_of to let the device tree specify the
> parition probe") but it was never documented. Fix this by adding a
> proper description and example.
>
> Signed-off-by: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Acked-by: Boris Brezillon <boris.brezillon-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> ---
> Documentation/devicetree/bindings/mtd/common.txt | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/mtd/common.txt b/Documentation/devicetree/bindings/mtd/common.txt
> index fc068b923d7a..1ada70e718b2 100644
> --- a/Documentation/devicetree/bindings/mtd/common.txt
> +++ b/Documentation/devicetree/bindings/mtd/common.txt
> @@ -6,10 +6,17 @@ Optional properties:
> controller based name) in order to ease flash device identification
> and/or describe what they are used for.
>
> +- linux,part-probe: if present, this property should contain a list of strings
> + with partition probes to be used for the flash device. A role of partition
> + probe (parser) is to read/construct partition table and register found
> + partitions. Getting partition table may be platform or device specific so
> + various devices may use various Linux drivers for this purpose.
Have you reviewed the old threads about this? I thought I already
discouraged extending this binding to be generic. Particularly, we do
*not* want to codify things like 'linux,part-probe = "bcm47xxpart"',
which doesn't follow any accepted practice about naming. And you've also
failed to document any actual strings to put here, which hides the fact
that you're opening a can of worms.
Piece of a previous thread:
http://lists.infradead.org/pipermail/linux-mtd/2015-October/062613.html
[PATCH] mtd: document linux-specific partition parser DT binding
I attempted to resolve that here, but never made time to address the few
not-so-constructive comments I received:
https://mail-archive.com/linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org/msg1035539.html
[RFC PATCH 0/7] mtd: partitions: add of_match_table support
I'd still prefer that approach to supporting this shortcut for all MTDs.
Brian
> +
> Example:
>
> flash@0 {
> label = "System-firmware";
> + linux,part-probe = "cmdlinepart", "ofpart";
>
> /* flash type specific properties */
> };
> --
> 2.11.0
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3 3/4] bluetooth: hci_uart: add LL protocol serdev driver support
From: Rob Herring @ 2017-04-19 20:47 UTC (permalink / raw)
To: Adam Ford
Cc: Marcel Holtmann, open list:BLUETOOTH DRIVERS, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Johan Hedberg,
Gustavo Padovan, Satish Patel, Wei Xu, Eyal Reizer, netdev,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
In-Reply-To: <CAHCN7xLNcD1rmifEOyPhG2rpB_C81hsyzV9W2q6kCQkKa69sZg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Mon, Apr 17, 2017 at 3:11 PM, Adam Ford <aford173-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On Thu, Apr 13, 2017 at 10:03 AM, Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
>> Turns out that the LL protocol and the TI-ST are the same thing AFAICT.
>> The TI-ST adds firmware loading, GPIO control, and shared access for
>> NFC, FM radio, etc. For now, we're only implementing what is needed for
>> BT. This mirrors other drivers like BCM and Intel, but uses the new
>> serdev bus.
>>
>> The firmware loading is greatly simplified by using existing
>> infrastructure to send commands. It may be a bit slower than the
>> original code using synchronous functions, but the real bottleneck is
>> likely doing firmware load at 115.2kbps.
>
> I am using pdata-quirks to drive my wl1283 Bluetooth on a DM3730. I
> have the Bluetooth set to 3000000 baud in pdata quirks. Looking at
> the binding, I don't see an option to set the baudrate. Is there (or
> will there) be a way to set the baud rate of the Bluetooth?
If you read hci_ti_probe, you will see it is already there. The
default is 3Mbps and the DT can override that with "max-speed". The
intent is that 3Mbps is the max the device can do and max-speed is
only for board or host limitations. Though I just checked the
datasheet on the 1835 and it can go up to 4364kbps. No datasheets for
wl1283, so I have no idea what the max is.
>> +static int hci_ti_probe(struct serdev_device *serdev)
>> +{
>> + struct hci_uart *hu;
>> + struct ll_device *lldev;
>> + u32 max_speed = 3000000;
[...]
>> + of_property_read_u32(serdev->dev.of_node, "max-speed", &max_speed);
>> + hci_uart_set_speeds(hu, 115200, max_speed);
^ permalink raw reply
* Re: [PATCH v3 1/4] dt-bindings: net: Add TI WiLink shared transport binding
From: Rob Herring @ 2017-04-19 20:49 UTC (permalink / raw)
To: Adam Ford
Cc: Mark Rutland, Johan Hedberg, Wei Xu, Eyal Reizer,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
open list:BLUETOOTH DRIVERS, Gustavo Padovan, Marcel Holtmann,
Satish Patel,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
netdev
In-Reply-To: <CAHCN7x+G_jbQTDfyPBZ4Er8vz46tEojrWf29Eztq56c9zBnMeA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Sun, Apr 16, 2017 at 9:09 AM, Adam Ford <aford173-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
>
> On Apr 13, 2017 10:04 AM, "Rob Herring" <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
>
> Add serial slave device binding for the TI WiLink series of Bluetooth/FM/GPS
> devices.
>
> Signed-off-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Cc: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
> Cc: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> ---
> v3:
> - rebase on bluetooth-next
>
> .../devicetree/bindings/net/ti,wilink-st.txt | 35
> ++++++++++++++++++++++
> 1 file changed, 35 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/net/ti,wilink-st.txt
>
> diff --git a/Documentation/devicetree/bindings/net/ti,wilink-st.txt
> b/Documentation/devicetree/bindings/net/ti,wilink-st.txt
> new file mode 100644
> index 000000000000..cbad73a84ac4
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/ti,wilink-st.txt
> @@ -0,0 +1,35 @@
> +TI WiLink 7/8 (wl12xx/wl18xx) Shared Transport BT/FM/GPS devices
> +
> +TI WiLink devices have a UART interface for providing Bluetooth, FM radio,
> +and GPS over what's called "shared transport". The shared transport is
> +standard BT HCI protocol with additional channels for the other functions.
> +
> +These devices also have a separate WiFi interface as described in
> +wireless/ti,wlcore.txt.
> +
> +This bindings follows the UART slave device binding in
> +../serial/slave-device.txt.
> +
> +Required properties:
> + - compatible: should be one of the following:
> + "ti,wl1271-st"
> + "ti,wl1273-st"
> + "ti,wl1831-st"
> + "ti,wl1835-st"
> + "ti,wl1837-st"
> +
>
>
> Would you expect the wl1283 chipset too?
Probably, but I left it out as there's no public information.
> I can help test this if you like after the holiday weekend. I have a board
> with WL1283 and currently using pdata-quirks to support it.
^ permalink raw reply
* Re: [PATCH V5 1/3] dt-bindings: mtd: document linux,part-probe property
From: Boris Brezillon @ 2017-04-19 20:55 UTC (permalink / raw)
To: Brian Norris
Cc: Rafał Miłecki, David Woodhouse, Marek Vasut,
Richard Weinberger, Cyrille Pitchen, Rob Herring, Mark Rutland,
Frank Rowand, Linus Walleij,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, Rafał Miłecki
In-Reply-To: <20170419203705.GF20555-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
On Wed, 19 Apr 2017 13:37:05 -0700
Brian Norris <computersforpeace-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> Hi,
>
> On Mon, Apr 17, 2017 at 09:47:44PM +0200, Rafał Miłecki wrote:
> > From: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
> >
> > Support for this property has been introduced in 2010 with commit
> > 9d5da3a9b849 ("mtd: extend physmap_of to let the device tree specify the
> > parition probe") but it was never documented. Fix this by adding a
> > proper description and example.
> >
> > Signed-off-by: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
> > Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> > Acked-by: Boris Brezillon <boris.brezillon-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> > ---
> > Documentation/devicetree/bindings/mtd/common.txt | 7 +++++++
> > 1 file changed, 7 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/mtd/common.txt b/Documentation/devicetree/bindings/mtd/common.txt
> > index fc068b923d7a..1ada70e718b2 100644
> > --- a/Documentation/devicetree/bindings/mtd/common.txt
> > +++ b/Documentation/devicetree/bindings/mtd/common.txt
> > @@ -6,10 +6,17 @@ Optional properties:
> > controller based name) in order to ease flash device identification
> > and/or describe what they are used for.
> >
> > +- linux,part-probe: if present, this property should contain a list of strings
> > + with partition probes to be used for the flash device. A role of partition
> > + probe (parser) is to read/construct partition table and register found
> > + partitions. Getting partition table may be platform or device specific so
> > + various devices may use various Linux drivers for this purpose.
>
> Have you reviewed the old threads about this? I thought I already
> discouraged extending this binding to be generic. Particularly, we do
> *not* want to codify things like 'linux,part-probe = "bcm47xxpart"',
> which doesn't follow any accepted practice about naming. And you've also
> failed to document any actual strings to put here, which hides the fact
> that you're opening a can of worms.
>
> Piece of a previous thread:
> http://lists.infradead.org/pipermail/linux-mtd/2015-October/062613.html
> [PATCH] mtd: document linux-specific partition parser DT binding
>
> I attempted to resolve that here, but never made time to address the few
> not-so-constructive comments I received:
>
> https://mail-archive.com/linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org/msg1035539.html
> [RFC PATCH 0/7] mtd: partitions: add of_match_table support
Oops, completely forgot you had proposed an alternative solution. Sorry
about that.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v13 03/10] mux: minimal mux subsystem and gpio-based mux controller
From: Peter Rosin @ 2017-04-19 21:04 UTC (permalink / raw)
To: Philipp Zabel
Cc: linux-kernel, Greg Kroah-Hartman, Wolfram Sang, Rob Herring,
Mark Rutland, Jonathan Cameron, Hartmut Knaack,
Lars-Peter Clausen, Peter Meerwald-Stadler, Jonathan Corbet,
linux-i2c, devicetree, linux-iio, linux-doc, Andrew Morton,
Colin Ian King, Paul Gortmaker, kernel
In-Reply-To: <1492609756.2970.131.camel@pengutronix.de>
On 2017-04-19 15:49, Philipp Zabel wrote:
> On Wed, 2017-04-19 at 14:00 +0200, Peter Rosin wrote:
> [...]
>>>> +int mux_control_select(struct mux_control *mux, int state)
>>>
>>> If we let two of these race, ...
>>
>> The window for this "race" is positively huge. If there are several
>> mux consumers of a single mux controller, it is self-evident that
>> if one of them grabs the mux for a long time, the others will suffer.
>>
>> The design is that the rwsem is reader-locked for the full duration
>> of a select/deselect operation by the mux consumer.
>
> I was not clear. I meant: I think this can also happen if we let them
> race with the same state target.
Right, but there is another glaring problem with the v13 implementation
of select/deselect. If there are three consumers and the first one
holds the mux while the other two tries to select it to some other
position, then even if the two "new" consumers agree on the mux state,
then both of them will end up in the "it's just contended" case and
then be serialized. So, yes, the select/deselect implementation is not
perfect. To quote the cover letter:
I'm using an rwsem to lock a mux, but that isn't really a
perfect fit. Is there a better locking primitive that I don't
know about that fits better? I had a mutex at one point, but
that didn't allow any concurrent accesses at all. At least
the rwsem allows concurrent access as long as all users
agree on the mux state, but I suspect that the rwsem will
degrade to the mutex situation pretty quickly if there is
any contention.
But with your discovery that there's a race when two consumers go
for the same state in a free mux, in addition to the above contention
problem, I'm about ready to go with Greg's suggestion and just use a
mutex. I.e. ignore the desire to allow concurrent use. Because it's
not like the sketchy thing I threw out in the other part of the thread
solves any of these problems. I can live without the concurrency, and
I guess I can also live with passing the buck to the poor sod that
eventually needs it.
>>>> +{
>>>> + int ret;
>>>> +
>>>> + if (down_read_trylock(&mux->lock)) {
>>>> + if (mux->cached_state == state)
>>>> + return 0;
>
> This check makes it clear that a second select call is not intended to
> block if the intended state is already selected. But if the instance we
> will lose the race against has not yet updated cached_state, ...
>
>>>> + /* Sigh, the mux needs updating... */
>>>> + up_read(&mux->lock);
>>>> + }
>>>> +
>>>> + /* ...or it's just contended. */
>>>> + down_write(&mux->lock);
>
> ... we are blocking here until the other instance calls up_read. Even
> though in this case (same state target) we would only have to block
> until the other instance calls downgrade_write after the mux control is
> set to the correct state.
>
> Basically there is a small window before down_write with no lock at all,
> where multiple instances can already have decided they must change the
> mux (to the same state). If this happens, they go on to block each other
> unnecessarily.
>
>>> ... then the last to get to down_write will just wait here forever (or
>>> until the first consumer calls mux_control_deselect, which may never
>>> happen)?
>>
>> It is vital that the mux consumer call _deselect when it is done with
>> the mux. Not doing so will surely starve out any other mux consumers.
>> The whole thing is designed around the fact that mux consumers should
>> deselect the mux as soon as it's no longer needed.
>
> I'd like to use this for video bus multiplexers. Those would not be
> selected for the duration of an i2c transfer, but for the duration of a
> running video capture stream, or for the duration of an enabled display
> path. While I currently have no use case for multiple consumers
> controlling the same mux, this scenario is what shapes my perspective.
> For such long running selections the consumer should have the option to
> return -EBUSY instead of blocking when the lock can't be taken.
I'll see if I can implement a try variant for the mutex based select I
will probably end up with in v14...
Cheers,
peda
^ permalink raw reply
* Re: [PATCH v2 2/2] devicetree: Document the max31760 device binding.
From: Rob Herring @ 2017-04-19 21:04 UTC (permalink / raw)
To: John Muir
Cc: Jean Delvare, Guenter Roeck, Jonathan Corbet, Pawel Moll,
Ian Campbell, Kumar Gala, devicetree, linux-hwmon, linux-doc,
Anatol Pomazau, Mark Segal
In-Reply-To: <20170411213218.138718-3-john@jmuir.com>
On Tue, Apr 11, 2017 at 02:32:18PM -0700, John Muir wrote:
> v2:
> - Fixup based on comments.
While you should have a commit msg here, the patch versioning goes below
the '---'.
This history is not too useful either. You should describe what you
changed so reviewers don't have to go find the previous versions. I may
remember reviewing a patch, but I likely don't remember what I said.
>
> Signed-off-by: John Muir <john@jmuir.com>
> ---
> .../devicetree/bindings/hwmon/max31760.txt | 72 ++++++++++++++++++++++
> 1 file changed, 72 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/hwmon/max31760.txt
>
> diff --git a/Documentation/devicetree/bindings/hwmon/max31760.txt b/Documentation/devicetree/bindings/hwmon/max31760.txt
> new file mode 100644
> index 000000000000..760fdf0b55e0
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/hwmon/max31760.txt
> @@ -0,0 +1,72 @@
> +MAX31760 fan controller
> +-----------------------
> +
> +This device supports I2C only. Fan sub-nodes must be defined in order to enable
> +the fan tachometer input. See also the datasheet:
> +https://datasheets.maximintegrated.com/en/ds/MAX31760.pdf
> +
> +Required node properties:
> + - compatible: "maxim,max31760"
> + - reg: The I2C address of the device. This is 0x50 - 0x57 depending on the
> + hardware configuration.
> + - #address-cells: Must be 1.
> + - #size-cells: Must be 0.
> +
> +Optional node properties:
> + - maxim,fan-fail-full-only: Boolean; Assert a fan failure only when the PWM is
> + at 100%.
> + - maxim,fan-rd-signal: Boolean; Fans provide a rotation detection (RD) signal
> + instead of generating square-wave pulses.
> + - maxim,fan-rd-polarity-high: Boolean; RD is high when the fan is running, not
> + low. Only relevant when fan-rd-signal is true.
> + - maxim,fan-signal-enabled: Boolean; Externally driving FF/FS low should force
> + PWM output to 100%.
> + - maxim,fan-spin-up-enabled: Boolean; For fan startup set the PWM to 100% until
> + tach is detected or two seconds have passed before reducing to the target
> + value.
> + - maxim,pwm-polarity-negative: Boolean; 100% PWM is when PWM is low, not high.
> + - maxim,pwm-pulse-stretch-enabled: Boolean; Enable PWM pulse stretching.
> + - maxim,pwm-zero-fan-can-fail: Boolean; Enable fan failure detection while
> + ramping to 0% PWM.
> +
> +Fan sub-nodes must be present in order to enable the fan.
> +
> +Required fan sub-node properties:
> + - reg: Fan address. Must be <0x00> or <0x01>.
> +
> +Optional fan sub-node properties:
> + - label: String; Assigned to the hwmon fanX_label property.
> +
> +Temperature sub-nodes are optional.
> +
> +Required temp sub-node properties:
> + - reg: Temperature sensor address. Must be <0x00> or <0x01>.
> +
> +Optional temp sub-node properties:
> + - label: String; Assigned to the hwmon tempX_label property.
> + - ideality: For temperature node with reg 1 only: Set ideality factor for the
This too needs a maxim prefix.
> + remote temperature sensor. Integer with range 0 to 63, representing a
> + multiplication factor of 0.9844 to 1.0489. Default: 24 (1.0080).
> +
> +Example:
> + max31760@50 {
> + compatible = "maxim,max31760";
> + reg = <0x50>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + maxim,fan-spin-up-enabled;
> +
> + fan@0 {
> + reg = <0x00>;
> + label = "Left";
> + };
> + fan@1 {
> + reg = <0x01>;
> + label = "Right";
> + };
> + temp@1 {
> + reg = <0x01>;
> + label = "CPU";
> + };
> + };
> --
> 2.12.2.715.g7642488e1d-goog
>
^ permalink raw reply
* Re: [PATCH v4 04/18] dt-bindings: syscon: Add DT bindings documentation for Allwinner syscon
From: Rob Herring @ 2017-04-19 21:06 UTC (permalink / raw)
To: Corentin Labbe
Cc: mark.rutland-5wv7dgnIgG8,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8, wens-jdAy2FN1RRM,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, catalin.marinas-5wv7dgnIgG8,
will.deacon-5wv7dgnIgG8, peppe.cavallaro-qxv4g6HH51o,
alexandre.torgue-qxv4g6HH51o, linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20170412111400.2296-5-clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Wed, Apr 12, 2017 at 01:13:46PM +0200, Corentin Labbe wrote:
> This patch adds documentation for Device-Tree bindings for the
> syscon present in allwinner devices.
>
> Signed-off-by: Corentin Labbe <clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> ---
> .../devicetree/bindings/misc/allwinner,syscon.txt | 19 +++++++++++++++++++
> 1 file changed, 19 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/misc/allwinner,syscon.txt
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
^ permalink raw reply
* Re: [PATCH] of: introduce event tracepoints for dynamic device_node lifecyle
From: Tyrel Datwyler @ 2017-04-19 21:13 UTC (permalink / raw)
To: Michael Ellerman, Oliver O'Halloran, Rob Herring
Cc: devicetree@vger.kernel.org, linuxppc-dev,
linux-kernel@vger.kernel.org, rostedt, Ingo Molnar,
Tyrel Datwyler, Nathan Fontenot, Frank Rowand
In-Reply-To: <87y3uw66y5.fsf@concordia.ellerman.id.au>
On 04/19/2017 03:13 AM, Michael Ellerman wrote:
> Oliver O'Halloran <oohall@gmail.com> writes:
>
>> On Wed, Apr 19, 2017 at 2:46 AM, Rob Herring <robh+dt@kernel.org> wrote:
>>> On Mon, Apr 17, 2017 at 7:32 PM, Tyrel Datwyler
>>> <tyreld@linux.vnet.ibm.com> wrote:
>>>> This patch introduces event tracepoints for tracking a device_nodes
>>>> reference cycle as well as reconfig notifications generated in response
>>>> to node/property manipulations.
>>>>
>>>> With the recent upstreaming of the refcount API several device_node
>>>> underflows and leaks have come to my attention in the pseries (DLPAR) dynamic
>>>> logical partitioning code (ie. POWER speak for hotplugging virtual and physcial
>>>> resources at runtime such as cpus or IOAs). These tracepoints provide a
>>>> easy and quick mechanism for validating the reference counting of
>>>> device_nodes during their lifetime.
>>>
>>> Not really relevant for this patch, but since you are looking at
>>> pseries and refcounting, the refcounting largely exists for pseries.
>>> It's also hard to get right as this type of fix is fairly common. It's
>>> now used for overlays, but we really probably only need to refcount
>>> the overlays or changesets as a whole, not at a node level. If you
>>> have any thoughts on how a different model of refcounting could work
>>> for pseries, I'd like to discuss it.
>>
>> One idea I've been kicking around is differentiating short and long
>> term references to a node.
>
> I actually did this a long time ago, but balked at the size of the patch
> to do the conversion. Let me see if I can find it lying around ...
It would be interesting to revisit this, and toss around any other ideas
anyone may have.
-Tyrel
>
> cheers
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: add vendor prefix for NLT Technologies, Ltd.
From: Rob Herring @ 2017-04-19 21:14 UTC (permalink / raw)
To: Lucas Stach; +Cc: Mark Rutland, devicetree, dri-devel, patchwork-lst, kernel
In-Reply-To: <20170412171526.32393-1-l.stach@pengutronix.de>
On Wed, Apr 12, 2017 at 07:15:25PM +0200, Lucas Stach wrote:
> NLT technologies is the former NEC display business, but changed its
> name to NLT Technologies when forming a joint venture with
> Shenzhen AVIC OPTOELECTRONICS, Ltd.
>
> Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
> ---
> Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
> 1 file changed, 1 insertion(+)
Acked-by: Rob Herring <robh@kernel.org>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH 2/2] drm/panel: simple: add support for NLT NL192108AC18-02D
From: Rob Herring @ 2017-04-19 21:15 UTC (permalink / raw)
To: Lucas Stach; +Cc: Mark Rutland, devicetree, dri-devel, patchwork-lst, kernel
In-Reply-To: <20170412171526.32393-2-l.stach@pengutronix.de>
On Wed, Apr 12, 2017 at 07:15:26PM +0200, Lucas Stach wrote:
> This adds support for the NLT Technologies NL192108AC18-02D
> 15.6" LVDS FullHD TFT LCD panel, which can be supported
> by the simple panel driver.
>
> Timings are taken from the preliminary datasheet, as a final
> one is not yet available.
>
> Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
> ---
> .../display/panel/nlt,nl192108ac18-02d.txt | 7 ++++++
> drivers/gpu/drm/panel/panel-simple.c | 29 ++++++++++++++++++++++
> 2 files changed, 36 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/display/panel/nlt,nl192108ac18-02d.txt
>
> diff --git a/Documentation/devicetree/bindings/display/panel/nlt,nl192108ac18-02d.txt b/Documentation/devicetree/bindings/display/panel/nlt,nl192108ac18-02d.txt
> new file mode 100644
> index 000000000000..edc34fbd2131
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/panel/nlt,nl192108ac18-02d.txt
> @@ -0,0 +1,7 @@
> +NLT Technologies, Ltd. 15.6" FHD (1920x1080) LVDS TFT LCD panel
> +
> +Required properties:
> +- compatible: should be "nlt,nl192108ac18-02d"
Please define the power supply. Is power-supply used or are there
multiple supplies?
> +
> +This binding is compatible with the simple-panel binding, which is specified
> +in simple-panel.txt in this directory.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: hwrng: Add Mediatek hardware random generator bindings
From: Rob Herring @ 2017-04-19 21:23 UTC (permalink / raw)
To: sean.wang-NuS5LvNUpcJWk0Htik3J/w
Cc: herbert-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q,
mpm-VDJrAJ4Gl5ZBDgjK7y7TUQ, mark.rutland-5wv7dgnIgG8,
clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w,
prasannatsmkumar-Re5JQEeQqe8AvxtiuMwx3w,
romain.perier-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
shannon.nelson-QHcLZuEGTsvQT0dZR+AlfA,
weiyongjun1-hv44wF8Li93QT0dZR+AlfA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-crypto-u79uwXL29TY76Z2rM5mHXA,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
keyhaede-Re5JQEeQqe8AvxtiuMwx3w
In-Reply-To: <1492067108-14748-2-git-send-email-sean.wang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
On Thu, Apr 13, 2017 at 03:05:07PM +0800, sean.wang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org wrote:
> From: Sean Wang <sean.wang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
>
> Document the devicetree bindings for Mediatek random number
> generator which could be found on MT7623 SoC or other similar
> Mediatek SoCs.
>
> Signed-off-by: Sean Wang <sean.wang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
> ---
> Documentation/devicetree/bindings/rng/mtk-rng.txt | 18 ++++++++++++++++++
> 1 file changed, 18 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/rng/mtk-rng.txt
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: mt8173: Fix mdp device tree
From: Rob Herring @ 2017-04-19 21:35 UTC (permalink / raw)
To: Minghsiu Tsai
Cc: Hans Verkuil, daniel.thompson-QSEj5FYQhm4dnm+yROfE0A,
Mauro Carvalho Chehab, Matthias Brugger, Daniel Kurtz,
Pawel Osciak, Houlong Wei, srv_heupstream-NuS5LvNUpcJWk0Htik3J/w,
Eddie Huang, Yingjoe Chen, Wu-Cheng Li,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-media-u79uwXL29TY76Z2rM5mHXA,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1492068787-17838-2-git-send-email-minghsiu.tsai-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
On Thu, Apr 13, 2017 at 03:33:05PM +0800, Minghsiu Tsai wrote:
> If the mdp_* nodes are under an mdp sub-node, their corresponding
> platform device does not automatically get its iommu assigned properly.
>
> Fix this by moving the mdp component nodes up a level such that they are
> siblings of mdp and all other SoC subsystems. This also simplifies the
> device tree.
It may simplify the DT, but it also breaks compatibility with old DT.
Not sure if that's a problem on Mediatek platforms, but please be
explicit here that you are breaking compatibility and why that is okay.
>
> Signed-off-by: Daniel Kurtz <djkurtz-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
> Signed-off-by: Minghsiu Tsai <minghsiu.tsai-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
Should this have Daniel as the author?
>
> ---
> Documentation/devicetree/bindings/media/mediatek-mdp.txt | 12 +++---------
> 1 file changed, 3 insertions(+), 9 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/media/mediatek-mdp.txt b/Documentation/devicetree/bindings/media/mediatek-mdp.txt
> index 4182063..0d03e3a 100644
> --- a/Documentation/devicetree/bindings/media/mediatek-mdp.txt
> +++ b/Documentation/devicetree/bindings/media/mediatek-mdp.txt
> @@ -2,7 +2,7 @@
>
> Media Data Path is used for scaling and color space conversion.
>
> -Required properties (controller (parent) node):
> +Required properties (controller node):
> - compatible: "mediatek,mt8173-mdp"
> - mediatek,vpu: the node of video processor unit, see
> Documentation/devicetree/bindings/media/mediatek-vpu.txt for details.
> @@ -32,21 +32,16 @@ Required properties (DMA function blocks, child node):
> for details.
>
> Example:
> -mdp {
> - compatible = "mediatek,mt8173-mdp";
> - #address-cells = <2>;
> - #size-cells = <2>;
> - ranges;
> - mediatek,vpu = <&vpu>;
> -
> mdp_rdma0: rdma@14001000 {
> compatible = "mediatek,mt8173-mdp-rdma";
> + "mediatek,mt8173-mdp";
> reg = <0 0x14001000 0 0x1000>;
> clocks = <&mmsys CLK_MM_MDP_RDMA0>,
> <&mmsys CLK_MM_MUTEX_32K>;
> power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
> iommus = <&iommu M4U_PORT_MDP_RDMA0>;
> mediatek,larb = <&larb0>;
> + mediatek,vpu = <&vpu>;
> };
>
> mdp_rdma1: rdma@14002000 {
> @@ -106,4 +101,3 @@ mdp {
> iommus = <&iommu M4U_PORT_MDP_WROT1>;
> mediatek,larb = <&larb4>;
> };
> -};
> --
> 1.9.1
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 1/4] dt-bindings: gpio - add exar to vendor prefixes list
From: Rob Herring @ 2017-04-19 21:48 UTC (permalink / raw)
To: Nandor Han
Cc: gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
davem-fT/PcQaiUtIeIZ0/mPfg9Q, geert-Td1EMuHUCqxL1ZNQvxDV9g,
mchehab-DgEjT+Ai2ygdnm+yROfE0A, daniel.vetter-/w4YWyX8dFk,
linus.walleij-QSEj5FYQhm4dnm+yROfE0A,
gnurou-Re5JQEeQqe8AvxtiuMwx3w, mark.rutland-5wv7dgnIgG8,
linux-gpio-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <f02af49f4d72326c455c9137ffb2714e7236cbab.1492077070.git.nandor.han-JJi787mZWgc@public.gmane.org>
On Thu, Apr 13, 2017 at 01:27:48PM +0300, Nandor Han wrote:
> Add Exar Corporation to vendors list.
This patch has nothing to do with gpio, so that should be dropped from
the subject.
>
> Signed-off-by: Nandor Han <nandor.han-JJi787mZWgc@public.gmane.org>
> ---
> Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
Otherwise,
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH V2] ARM: dts: BCM5301X: Specify MDIO bus in the DT
From: Rafał Miłecki @ 2017-04-19 21:54 UTC (permalink / raw)
To: Florian Fainelli
Cc: Hauke Mehrtens, Rob Herring, Mark Rutland, Russell King,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w,
devicetree-u79uwXL29TY76Z2rM5mHXA, Rafał Miłecki
In-Reply-To: <20170402210840.11429-1-zajec5-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
From: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
Northstar devices have MDIO bus that may contain various PHYs attached.
A common example is USB 3.0 PHY (that doesn't have an MDIO driver yet).
Signed-off-by: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
---
V2: Disable MDIO bus by default.
Add mdio label to allow enabling it easily per board
---
arch/arm/boot/dts/bcm5301x.dtsi | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/bcm5301x.dtsi b/arch/arm/boot/dts/bcm5301x.dtsi
index acee36a61004..1f34bc6905f2 100644
--- a/arch/arm/boot/dts/bcm5301x.dtsi
+++ b/arch/arm/boot/dts/bcm5301x.dtsi
@@ -320,6 +320,14 @@
};
};
+ mdio: mdio@18003000 {
+ compatible = "brcm,iproc-mdio";
+ reg = <0x18003000 0x8>;
+ #size-cells = <1>;
+ #address-cells = <0>;
+ status = "disabled";
+ };
+
i2c0: i2c@18009000 {
compatible = "brcm,iproc-i2c";
reg = <0x18009000 0x50>;
--
2.11.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH v2 3/4] doc,dts - add XRA1403 DTS binding documentation
From: Rob Herring @ 2017-04-19 21:55 UTC (permalink / raw)
To: Nandor Han
Cc: gregkh, davem, geert, mchehab, daniel.vetter, linus.walleij,
gnurou, mark.rutland, linux-gpio, devicetree, linux-kernel
In-Reply-To: <0d970c6a929597804eae3577ed24f57ee23b820a.1492077070.git.nandor.han@ge.com>
On Thu, Apr 13, 2017 at 01:27:50PM +0300, Nandor Han wrote:
> Add the XRA1403 DTS binding documentation.
"dt-bindings: gpio: ..." for the subject.
>
> Signed-off-by: Nandor Han <nandor.han@ge.com>
> ---
> .../devicetree/bindings/gpio/gpio-xra1403.txt | 46 ++++++++++++++++++++++
> 1 file changed, 46 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/gpio/gpio-xra1403.txt
Otherwise,
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH 2/4] net: macb: Add tsu_clk to device tree
From: Rob Herring @ 2017-04-19 21:57 UTC (permalink / raw)
To: Rafal Ozieblo
Cc: David Miller, nicolas.ferre-AIFe0yeh4nAAvxtiuMwx3w,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
harinikatakamlinux-Re5JQEeQqe8AvxtiuMwx3w,
harini.katakam-gjFFaj9aHVfQT0dZR+AlfA,
richardcochran-Re5JQEeQqe8AvxtiuMwx3w,
Andrei.Pistirica-UWL1GkI3JZL3oGB3hsPCZA
In-Reply-To: <1492090686-14778-1-git-send-email-rafalo-vna1KIf7WgpBDgjK7y7TUQ@public.gmane.org>
On Thu, Apr 13, 2017 at 02:38:06PM +0100, Rafal Ozieblo wrote:
> Signed-off-by: Rafal Ozieblo <rafalo-vna1KIf7WgpBDgjK7y7TUQ@public.gmane.org>
> ---
> Documentation/devicetree/bindings/net/macb.txt | 1 +
> 1 file changed, 1 insertion(+)
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH V3] PM / OPP: Use - instead of @ for DT entries
From: Rafael J. Wysocki @ 2017-04-19 22:06 UTC (permalink / raw)
To: Olof Johansson
Cc: Viresh Kumar, arm, Chanwoo Choi, MyungJoo Ham, Kyungmin Park,
Kukjin Kim, Krzysztof Kozlowski, Javier Martinez Canillas,
Viresh Kumar, Nishanth Menon, Stephen Boyd, Beno??t Cousson,
Tony Lindgren, Rob Herring, Mark Rutland, Daniel Mack,
Haojian Zhuang, Robert Jarzmik, Maxime Ripard, Chen-Yu Tsai,
Masahiro
In-Reply-To: <20170419142215.GA12105@localhost>
On Wednesday, April 19, 2017 07:22:15 AM Olof Johansson wrote:
> Hi Viresh,
>
> On Tue, Apr 18, 2017 at 10:44:50AM +0530, Viresh Kumar wrote:
> > Compiling the DT file with W=1, DTC warns like follows:
> >
> > Warning (unit_address_vs_reg): Node /opp_table0/opp@1000000000 has a
> > unit name, but no reg property
> >
> > Fix this by replacing '@' with '-' as the OPP nodes will never have a
> > "reg" property.
> >
> > Reported-by: Krzysztof Kozlowski <krzk@kernel.org>
> > Reported-by: Masahiro Yamada <yamada.masahiro@socionext.com>
> > Suggested-by: Mark Rutland <mark.rutland@arm.com>
> > Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> > Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com> (sunxi)
> > Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com>
> > Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
> > Acked-by: Masahiro Yamada <yamada.masahiro@socionext.com> (uniphier)
> > Acked-by: Rob Herring <robh@kernel.org>
> > Acked-by: Tony Lindgren <tony@atomide.com>
>
> We've already turned down other patches that does this in a sweeping manner
> like this, since they tend to be conflict prone with other DT changes.
>
> Please split per platform and merge with each maintainer.
OK
So I'm assuming that you guys will take care of this going forward.
Thanks,
Rafael
^ permalink raw reply
* Re: [RFC 1/2] dt-bindings: add mmio-based syscon mux controller DT bindings
From: Rob Herring @ 2017-04-19 22:09 UTC (permalink / raw)
To: Philipp Zabel
Cc: Peter Rosin, Mark Rutland, Sakari Ailus, Steve Longerbeam,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
kernel-bIcnvbaLZ9MEGnE8C9+IrQ
In-Reply-To: <20170413154812.19597-1-p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
On Thu, Apr 13, 2017 at 05:48:11PM +0200, Philipp Zabel wrote:
> This adds device tree binding documentation for mmio-based syscon
> multiplexers controlled by a single bitfield in a syscon register
> range.
>
> Signed-off-by: Philipp Zabel <p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
> ---
> Documentation/devicetree/bindings/mux/mmio-mux.txt | 56 ++++++++++++++++++++++
> 1 file changed, 56 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mux/mmio-mux.txt
>
> diff --git a/Documentation/devicetree/bindings/mux/mmio-mux.txt b/Documentation/devicetree/bindings/mux/mmio-mux.txt
> new file mode 100644
> index 0000000000000..11d96f5d98583
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mux/mmio-mux.txt
> @@ -0,0 +1,56 @@
> +MMIO bitfield-based multiplexer controller bindings
> +
> +Define a syscon bitfield to be used to control a multiplexer. The parent
> +device tree node must be a syscon node to provide register access.
> +
> +Required properties:
> +- compatible : "gpio-mux"
?
> +- reg : register base of the register containing the control bitfield
> +- bit-mask : bitmask of the control bitfield in the control register
> +- bit-shift : bit offset of the control bitfield in the control register
> +- #mux-control-cells : <0>
> +* Standard mux-controller bindings as decribed in mux-controller.txt
> +
> +Optional properties:
> +- idle-state : if present, the state the mux will have when idle. The
> + special state MUX_IDLE_AS_IS is the default.
> +
> +The multiplexer state is defined as the value of the bitfield described
> +by the reg, bit-mask, and bit-shift properties, accessed through the parent
> +syscon.
> +
> +Example:
> +
> + syscon {
> + compatible = "syscon";
> +
> + mux: mux-controller@3 {
> + compatible = "mmio-mux";
> + reg = <0x3>;
> + bit-mask = <0x1>;
> + bit-shift = <5>;
This pattern doesn't scale once you have multiple fields @ addr 3. I
also don't really think a node per register field in DT really scales.
I think the parent should be declared as a mux controller instead. You
could encode the mux addr and bit position in the mux cells.
> + #mux-control-cells = <0>;
> + };
> + };
> +
> + video-mux {
> + compatible = "video-mux";
> + mux-controls = <&mux>;
The mux binding was largely defined for a single control controling
multiple muxes. This doesn't really fit that, but I guess this is an
improvement over a custom syscon phandle.
> +
> + ports {
> + /* input 0 */
> + port@0 {
> + reg = <0>;
> + };
> +
> + /* input 1 */
> + port@1 {
> + reg = <1>;
> + };
> +
> + /* output */
> + port@2 {
> + reg = <2>;
> + };
> + };
> + };
> --
> 2.11.0
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] ASoC: cs35l35: Allow user to configure IMON SCALE
From: Rob Herring @ 2017-04-19 22:32 UTC (permalink / raw)
To: Charles Keepax
Cc: broonie-DgEjT+Ai2ygdnm+yROfE0A, lgirdwood-Re5JQEeQqe8AvxtiuMwx3w,
mark.rutland-5wv7dgnIgG8, brian.austin-jGc1dHjMKG3QT0dZR+AlfA,
Paul.Handrigan-jGc1dHjMKG3QT0dZR+AlfA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw,
patches-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E
In-Reply-To: <1492098729-30491-1-git-send-email-ckeepax-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
On Thu, Apr 13, 2017 at 04:52:09PM +0100, Charles Keepax wrote:
> On the chip the IMON signal is a full 24-bits however normally only
> some of the bits will be sent over the bus. The chip provides a field
> to select which bits of the IMON will be sent back, this is the only
> feedback signal that has this feature.
>
> Add an additional entry to the cirrus,imon device tree property to
> allow the IMON scale parameter to be passed.
>
> Signed-off-by: Charles Keepax <ckeepax-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
> ---
>
> I realise this is changing the binding slightly, but thought
> we might be able to sneak it before cs35l35 ships as it hasn't
> shipped in a kernel yet. However, it would be relatively simple
> (although makes the code a little messier) to support both the 3
> and 4 entry versions of the binding if people prefer?
Given it is new, I'm okay with the change if you are.
>
> Thanks,
> Charles
>
> .../devicetree/bindings/sound/cs35l35.txt | 4 ++--
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> include/sound/cs35l35.h | 1 +
> sound/soc/codecs/cs35l35.c | 22 +++++++++++++++-------
> sound/soc/codecs/cs35l35.h | 3 +++
> 4 files changed, 21 insertions(+), 9 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v4 1/2] dt-bindings: Document the STM32 QSPI bindings
From: Rob Herring @ 2017-04-19 22:35 UTC (permalink / raw)
To: Ludovic Barre
Cc: Cyrille Pitchen, Marek Vasut, David Woodhouse, Brian Norris,
Boris Brezillon, Richard Weinberger, Alexandre Torgue,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1492103757-22375-2-git-send-email-ludovic.Barre-qxv4g6HH51o@public.gmane.org>
On Thu, Apr 13, 2017 at 07:15:56PM +0200, Ludovic Barre wrote:
> From: Ludovic Barre <ludovic.barre-qxv4g6HH51o@public.gmane.org>
>
> This patch adds documentation of device tree bindings for the STM32
> QSPI controller.
>
> Signed-off-by: Ludovic Barre <ludovic.barre-qxv4g6HH51o@public.gmane.org>
> ---
> .../devicetree/bindings/mtd/stm32-quadspi.txt | 43 ++++++++++++++++++++++
> 1 file changed, 43 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mtd/stm32-quadspi.txt
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3] pinctrl: sh-pfc: r8a7791: add R8A7743 support
From: Rob Herring @ 2017-04-19 22:36 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: Mark Rutland, Laurent Pinchart, Geert Uytterhoeven, Linus Walleij,
devicetree, linux-renesas-soc, linux-gpio
In-Reply-To: <20170413201346.358012116@cogentembedded.com>
On Thu, Apr 13, 2017 at 11:13:32PM +0300, Sergei Shtylyov wrote:
> Renesas RZ/G1M (R8A7743) is pin compatible with R-Car M2-W/N (R8A7791/3),
> however it doesn't have several automotive specific peripherals. Annotate
> all the items that only exist on the R-Car SoCs and only supply the pin
> groups/functions existing on a given SoC...
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>
> ---
> This patch is against the 'devel' branch of Linus Walleij's 'linux-pinctrl.git'
> repo plus 4 R8A7791 PFC fixes and the "grand I2C rename" patch...
>
> Changes in version 3:
> - updated the PFC bindings.
>
> Changes in version 2:
> - switch to supplying exactly the groups/functions existing on a given SoC,
> update the patch descriptions accordingly;
> - resolved rejects due to the "grand I2C rename" patch being updated.
>
> Documentation/devicetree/bindings/pinctrl/renesas,pfc-pinctrl.txt | 1
Acked-by: Rob Herring <robh@kernel.org>
> drivers/pinctrl/sh-pfc/Kconfig | 5
> drivers/pinctrl/sh-pfc/Makefile | 1
> drivers/pinctrl/sh-pfc/core.c | 6
> drivers/pinctrl/sh-pfc/pfc-r8a7791.c | 1889 +++++-----
> drivers/pinctrl/sh-pfc/sh_pfc.h | 1
> 6 files changed, 1023 insertions(+), 880 deletions(-)
^ permalink raw reply
* Re: [PATCH v2] pinctrl: sh-pfc: r8a7794: add R8A7745 support
From: Rob Herring @ 2017-04-19 22:46 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: Mark Rutland, Laurent Pinchart, Geert Uytterhoeven, Linus Walleij,
devicetree, linux-renesas-soc, linux-gpio
In-Reply-To: <20170413201932.890107963@cogentembedded.com>
On Thu, Apr 13, 2017 at 11:19:24PM +0300, Sergei Shtylyov wrote:
> Renesas RZ/G1E (R8A7745) is pin compatible with R-Car E2 (R8A7794),
> however it doesn't have several automotive specific peripherals.
Is a single space between words really so hard for you? You've been told
to write proper sentences multiple times.
Yes, kernel developers suffer from OCD. Sorry.
> Annotate all the items that only exist on the R-Car SoCs and only
> supply the pin groups/functions existing on a given SoC (that required
> splitting of the AVB function)...
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>
> ---
> This patch is against the 'devel' branch of Linus Walleij's 'linux-pinctrl.git'
> repo plus R8A7794 PFC fix and R8A7743 PFC support patch...
>
> Changes in version 2:
> - fixed indentation to use tabs instead of spaces;
> - updated the PFC bindings.
>
> Documentation/devicetree/bindings/pinctrl/renesas,pfc-pinctrl.txt | 1
But given it's a one line DT change:
Acked-by: Rob Herring <robh@kernel.org>
> drivers/pinctrl/sh-pfc/Kconfig | 5
> drivers/pinctrl/sh-pfc/Makefile | 1
> drivers/pinctrl/sh-pfc/core.c | 6
> drivers/pinctrl/sh-pfc/pfc-r8a7794.c | 1970 +++++-----
> drivers/pinctrl/sh-pfc/sh_pfc.h | 1
> 6 files changed, 1140 insertions(+), 844 deletions(-)
^ permalink raw reply
* Re: [PATCH] of: introduce event tracepoints for dynamic device_node lifecyle
From: Tyrel Datwyler @ 2017-04-19 23:27 UTC (permalink / raw)
To: Michael Ellerman, Frank Rowand, Tyrel Datwyler,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A
Cc: linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
nfont-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8,
rostedt-nx8X9YLhiw1AfugRpC6u6w, mingo-H+wXaHxf7aLQT0dZR+AlfA
In-Reply-To: <87efwp6v4e.fsf-W0DJWXSxmBNbyGPkN3NxC2scP1bn1w/D@public.gmane.org>
On 04/18/2017 06:31 PM, Michael Ellerman wrote:
> Frank Rowand <frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
>
>> On 04/17/17 17:32, Tyrel Datwyler wrote:
>>> This patch introduces event tracepoints for tracking a device_nodes
>>> reference cycle as well as reconfig notifications generated in response
>>> to node/property manipulations.
>>>
>>> With the recent upstreaming of the refcount API several device_node
>>> underflows and leaks have come to my attention in the pseries (DLPAR) dynamic
>>> logical partitioning code (ie. POWER speak for hotplugging virtual and physcial
>>> resources at runtime such as cpus or IOAs). These tracepoints provide a
>>> easy and quick mechanism for validating the reference counting of
>>> device_nodes during their lifetime.
>>>
>>> Further, when pseries lpars are migrated to a different machine we
>>> perform a live update of our device tree to bring it into alignment with the
>>> configuration of the new machine. The of_reconfig_notify trace point
>>> provides a mechanism that can be turned for debuging the device tree
>>> modifications with out having to build a custom kernel to get at the
>>> DEBUG code introduced by commit 00aa3720.
>>
>> I do not like changing individual (or small groups of) printk() style
>> debugging information to tracepoint style.
>
> I'm not quite sure which printks() you're referring to.
>
> The only printks that are removed in this series are under #ifdef DEBUG,
> and so are essentially not there unless you build a custom kernel.
>
> They also only cover the reconfig case, which is actually less
> interesting than the much more common and bug-prone get/put logic.
>
>> As far as I know, there is no easy way to combine trace data and printk()
>> style data to create a single chronology of events. If some of the
>> information needed to debug an issue is trace data and some is printk()
>> style data then it becomes more difficult to understand the overall
>> situation.
>
> If you enable CONFIG_PRINTK_TIME then you should be able to just sort
> the trace and the printk output by the timestamp. If you're really
> trying to correlate the two then you should probably just be using
> trace_printk().
>
> But IMO this level of detail, tracing every get/put, does not belong in
> printk. Trace points are absolutely the right solution for this type of
> debugging.
Something else to keep in mind is that while pr_debugs could be used to
provide feedback on the reference counts and of_reconfig events they
don't in anyway tell us where they are happening in the kernel. The
trace infrastructure provides the ability to stack trace those events.
The following example provides me a lot more information about who is
doing what and where after I hot-add an ethernet adapter:
# echo stacktrace > /sys/kernel/debug/tracing/trace_options
# cat trace | grep -A6 "/pci@800000020000018"
...
drmgr-7349 [006] d... 7138.821875: of_node_get: refcount=8,
dn->full_name=/pci@800000020000018
drmgr-7349 [006] d... 7138.821876: <stack trace>
=> .msi_quota_for_device
=> .rtas_setup_msi_irqs
=> .arch_setup_msi_irqs
=> .__pci_enable_msix
=> .pci_enable_msix_range
--
drmgr-7349 [006] d... 7138.821876: of_node_put: refcount=2,
dn->full_name=/pci@800000020000018/ethernet@0
drmgr-7349 [006] d... 7138.821877: <stack trace>
=> .msi_quota_for_device
=> .rtas_setup_msi_irqs
=> .arch_setup_msi_irqs
=> .__pci_enable_msix
=> .pci_enable_msix_range
--
drmgr-7349 [006] .... 7138.821878: of_node_put: refcount=7,
dn->full_name=/pci@800000020000018
drmgr-7349 [006] .... 7138.821879: <stack trace>
=> .rtas_setup_msi_irqs
=> .arch_setup_msi_irqs
=> .__pci_enable_msix
=> .pci_enable_msix_range
=> .bnx2x_enable_msix
--
To get that same info as far as I know is to add a dump_stack() after
each pr_debug.
Further, filters can be set on the tracepoint event fields such that
trace data could be restricted to a particular device_node or refcount
threshold. For example:
# cd /sys/kernel/debug/tracing# cat events/of/of_node_get/format
# echo "dn_name == /pci@800000020000018" > events/of/filter
# cat trace
drmgr-10542 [003] .... 9630.677001: of_node_put: refcount=5,
dn->full_name=/pci@800000020000018
drmgr-10542 [003] d... 9631.677368: of_node_get: refcount=6,
dn->full_name=/pci@800000020000018
drmgr-10542 [003] .... 9631.677389: of_node_put: refcount=5,
dn->full_name=/pci@800000020000018
drmgr-10542 [003] .... 9631.677390: of_reconfig_notify:
action=DETACH_NODE, dn->full_name=/pci@800000020000018, prop->name=null,
old_prop->name=null
drmgr-10542 [003] .n.. 9632.025656: of_node_put: refcount=4,
dn->full_name=/pci@800000020000018
drmgr-10542 [003] .n.. 9632.025657: of_node_put: refcount=3,
dn->full_name=/pci@800000020000018
After setting the filter and doing a hot-remove of the pci device in
question the trace quickly tells me 3 references are being leaked. In
combination with the stacktrace option I can quickly correlate call
sites that take references without releasing them.
-Tyrel
>
> cheers
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3 01/21] dt-bindings: i2c: eeprom: Document manufacturer used as generic fallback
From: Rob Herring @ 2017-04-19 23:27 UTC (permalink / raw)
To: Javier Martinez Canillas
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA, Wolfram Sang, Simon Horman,
devicetree-u79uwXL29TY76Z2rM5mHXA, Sekhar Nori, David Lechner,
Alexandre Belloni, Mark Rutland
In-Reply-To: <20170414010445.21727-2-javier-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>
On Thu, Apr 13, 2017 at 10:04:25PM -0300, Javier Martinez Canillas wrote:
> The at24 driver allows to register I2C EEPROM chips using different vendor
> and devices, but the I2C subsystem does not take the vendor into account
> when matching using the I2C table since it only has device entries.
>
> But when matching using an OF table, both the vendor and device has to be
> taken into account so the driver defines only a set of compatible strings
> using the "atmel" vendor as a generic fallback for compatible I2C devices.
>
> Document in the Device Tree binding document that this manufacturer should
> be used as the generic fallback.
>
> Suggested-by: Wolfram Sang <wsa-z923LK4zBo2bacvFa/9K2g@public.gmane.org>
> Signed-off-by: Javier Martinez Canillas <javier-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>
>
> ---
>
> Changes in v3: None
> Changes in v2: None
>
> Documentation/devicetree/bindings/eeprom/eeprom.txt | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/eeprom/eeprom.txt b/Documentation/devicetree/bindings/eeprom/eeprom.txt
> index 5696eb508e95..d0395f14e2b3 100644
> --- a/Documentation/devicetree/bindings/eeprom/eeprom.txt
> +++ b/Documentation/devicetree/bindings/eeprom/eeprom.txt
> @@ -17,7 +17,8 @@ Required properties:
> "renesas,r1ex24002"
>
> If there is no specific driver for <manufacturer>, a generic
> - driver based on <type> is selected. Possible types are:
> + driver based on <type> and manufacturer "atmel" is selected.
> + Possible types are:
This isn't quite right. What the driver does isn't really relevant to
the binding.
These types with no vendor are used as the compatible string, so we have
to allow them. But it should be clear that no vendor is deprecated.
Ironically, it is a lot of Atmel boards that do this.
We should also explicitly list what are valid manufacturers. We also
have "at" as a vendor prefix which perhaps we should explicitly say is
deprecated.
Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3 01/21] dt-bindings: i2c: eeprom: Document manufacturer used as generic fallback
From: Rob Herring @ 2017-04-19 23:35 UTC (permalink / raw)
To: Javier Martinez Canillas
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Wolfram Sang, Simon Horman,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Sekhar Nori,
David Lechner, Alexandre Belloni, Mark Rutland
In-Reply-To: <20170419232759.mw6g6fwy4xvjaopv@rob-hp-laptop>
On Wed, Apr 19, 2017 at 6:27 PM, Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> On Thu, Apr 13, 2017 at 10:04:25PM -0300, Javier Martinez Canillas wrote:
>> The at24 driver allows to register I2C EEPROM chips using different vendor
>> and devices, but the I2C subsystem does not take the vendor into account
>> when matching using the I2C table since it only has device entries.
>>
>> But when matching using an OF table, both the vendor and device has to be
>> taken into account so the driver defines only a set of compatible strings
>> using the "atmel" vendor as a generic fallback for compatible I2C devices.
>>
>> Document in the Device Tree binding document that this manufacturer should
>> be used as the generic fallback.
>>
>> Suggested-by: Wolfram Sang <wsa-z923LK4zBo2bacvFa/9K2g@public.gmane.org>
>> Signed-off-by: Javier Martinez Canillas <javier-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>
>>
>> ---
>>
>> Changes in v3: None
>> Changes in v2: None
>>
>> Documentation/devicetree/bindings/eeprom/eeprom.txt | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/devicetree/bindings/eeprom/eeprom.txt b/Documentation/devicetree/bindings/eeprom/eeprom.txt
>> index 5696eb508e95..d0395f14e2b3 100644
>> --- a/Documentation/devicetree/bindings/eeprom/eeprom.txt
>> +++ b/Documentation/devicetree/bindings/eeprom/eeprom.txt
>> @@ -17,7 +17,8 @@ Required properties:
>> "renesas,r1ex24002"
>>
>> If there is no specific driver for <manufacturer>, a generic
>> - driver based on <type> is selected. Possible types are:
>> + driver based on <type> and manufacturer "atmel" is selected.
>> + Possible types are:
>
> This isn't quite right. What the driver does isn't really relevant to
> the binding.
>
> These types with no vendor are used as the compatible string, so we have
> to allow them. But it should be clear that no vendor is deprecated.
> Ironically, it is a lot of Atmel boards that do this.
>
> We should also explicitly list what are valid manufacturers. We also
> have "at" as a vendor prefix which perhaps we should explicitly say is
> deprecated.
I should perhaps look at the rest of the series before replying..
Based on that, the only comment that applies is listing the
manufacturers that are valid. From a DT perspective, I should not have
to know what the OS driver supports. If the device is compatible with
atmel, then that is required. If not, then the specific manufacturer's
compatible alone is enough and the OS has to match to that.
Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox