* 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] 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 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 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 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 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 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 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 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 v6 6/9] ASoC: simple-card-utils: enable "label" on asoc_simple_card_parse_card_name
From: Rob Herring @ 2017-04-19 20:31 UTC (permalink / raw)
To: Kuninori Morimoto; +Cc: Mark Brown, Linux-ALSA, Simon, Linux-DT
In-Reply-To: <87fuh6xwt1.wl%kuninori.morimoto.gx-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org>
On Mon, Apr 17, 2017 at 9:44 PM, Kuninori Morimoto
<kuninori.morimoto.gx-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org> wrote:
> From: Kuninori Morimoto <kuninori.morimoto.gx-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org>
>
> Current asoc_simple_card_parse_card_name() detect [prefix]name,
> but in generally, we uses "label" for user visible names.
> This patch enables [prefix]label too.
>
> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org>
> ---
> v5 -> v6
>
> - used const for names[]
>
> sound/soc/generic/simple-card-utils.c | 18 ++++++++++++++----
> 1 file changed, 14 insertions(+), 4 deletions(-)
>
> diff --git a/sound/soc/generic/simple-card-utils.c b/sound/soc/generic/simple-card-utils.c
> index 343b291..94ceaca 100644
> --- a/sound/soc/generic/simple-card-utils.c
> +++ b/sound/soc/generic/simple-card-utils.c
> @@ -81,15 +81,25 @@ int asoc_simple_card_set_dailink_name(struct device *dev,
> int asoc_simple_card_parse_card_name(struct snd_soc_card *card,
> char *prefix)
> {
> + char * const names[] = {
> + "label", "name"
> + };
> char prop[128];
> + int i;
> int ret;
>
> - snprintf(prop, sizeof(prop), "%sname", prefix);
> + if (!prefix)
> + prefix = "";
>
> /* Parse the card name from DT */
> - ret = snd_soc_of_parse_card_name(card, prop);
> - if (ret < 0)
> - return ret;
> + for (i = 0; i < ARRAY_SIZE(names); i++) {
> + snprintf(prop, sizeof(prop), "%s%s", prefix, names[i]);
> + ret = snd_soc_of_parse_card_name(card, prop);
> + if (ret < 0)
> + return ret;
> + if (card->name)
> + break;
> + }
This is still wrong as you are allowing "<prefix>label" for property
names. I think you want something like this:
ret = snd_soc_of_parse_card_name(card, "label");
if (ret < 0) {
char prop[128];
snprintf(prop, sizeof(prop), "%sname", prefix);
/* Parse the card name from DT */
ret = snd_soc_of_parse_card_name(card, prop);
if (ret < 0)
return ret;
}
--
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 2/2] mmc: dw_mmc-rockchip: parse rockchip,default-num-phases from DT
From: Doug Anderson @ 2017-04-19 20:19 UTC (permalink / raw)
To: Shawn Lin
Cc: Jaehoon Chung, Ulf Hansson, Rob Herring,
linux-mmc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Ziyuan Xu,
open list:ARM/Rockchip SoC...,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <1492592434-81312-3-git-send-email-shawn.lin-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
Hi,
On Wed, Apr 19, 2017 at 2:00 AM, Shawn Lin <shawn.lin-TNX95d0MmH7DzftRWevZcw@public.gmane.org> wrote:
> Currently we unconditionally do tuning for each degree, which
> costs 900ms for each boot and resume.
>
> May someone argue that this is a question of accuracy VS time. But I
> would say it's a trick of how we need to do decision for our boards.
> If we don't care the time we spend at all, we could definitely do tuning
> for each degree. But when we need to improve the user experience, for
> instance, speed up resuming from S3, we should also have the right to
> do that. This patch add parsing "rockchip,default-num-phases", for folks
> to specify the number of doing tuning. If not specified, 360 will be used
> as before.
>
> Signed-off-by: Shawn Lin <shawn.lin-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
>
> ---
>
> drivers/mmc/host/dw_mmc-rockchip.c | 48 ++++++++++++++++++++++++--------------
> 1 file changed, 30 insertions(+), 18 deletions(-)
No huge objection here, but I do remember we ended up at the 360
phases due to some of the craziness with dw_mmc delay elements on
rk3288. IIRC one of the big problems was that the delay elements
changed _a lot_ with the "LOGIC" voltage and we tweaked the voltage at
runtime for DDR DVFS. That imposed an extra need to be very accurate
on that SoC, at least on any board that was designed to support DDR
DVFS.
I also remember there being some weirdness on the Rockchip
implementation where there was a certain set of phases that the MMC
controller was essentially "blind". This blind spot was in the middle
of an otherwise good range of points. Unfortunately this blind spot
was somewhat hard to detect properly because it was not very big.
...the variability of the delay elements meant that there could be big
ranges where we weren't getting any good test coverage, but also the
fact that they changed with the LOGIC voltage might mean that we
weren't in the "blind" spot and then suddenly we were.
One other note is that i remember that the vast majority of time spent
tuning was dealing with "bad" phases, not dealing with "good" phases.
If you're looking to speed things up, maybe finding a way to make
"bad" phases fail faster would be wise? I think one of the reasons
bad phases failed so slowly is because the dw_mmc timeouts are all so
long.
Oh, and I guess one last note is that I have no idea if folks will
like the device bindings here. Part of me thinks it should be
something more "symbolic" like "rockchip,need-accurate-tuning" or
something like that. I guess I'd let the DT experts chime in.
So I guess to summarize:
* On rk3288 boards w/ DDR DVFS (or any other similar boards), 360
seems to provide real benefit.
* On other boards, probably you can get by with fewer phases.
-Doug
--
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] clk: hi6220: Add the hi655x's pmic clock
From: Daniel Lezcano @ 2017-04-19 19:47 UTC (permalink / raw)
To: Stephen Boyd
Cc: mturquette, lee.jones, xuwei5, devicetree, linux-kernel,
linux-arm-kernel, linux-clk
In-Reply-To: <20170419160005.GS7065@codeaurora.org>
On Wed, Apr 19, 2017 at 09:00:05AM -0700, Stephen Boyd wrote:
> On 04/16, Daniel Lezcano wrote:
> > On Wed, Apr 12, 2017 at 08:02:45AM -0700, Stephen Boyd wrote:
> > > On 04/08, Daniel Lezcano wrote:
[ ... ]
> > > > + ret = clk_hw_register_clkdev(&hi655x_clk->clk_hw, clk_name, NULL);
> > >
> > > Missed this last time. Do you use this clkdev lookup? The name is
> > > usually supposed to be based on what the device is expecting,
> > > instead of clk_name, and we would want some device name for the
> > > third argument here.
> >
> > I'm not sure to get your comment. Are you saying the clk_name should be the
> > third argument?
> >
> >
>
> Sorry, no. I meant that con_id is typically something like "core"
> or "ahb" or something like that, and dev_id is something like
> "a456002.pmic_device" or whatever dev_name(pmic_dev) would return for
> the consuming device. That way when we call clk_get(dev, "core")
> it will find the lookup with "core" and "a456002.pmic_device" to
> match up the clk lookup.
>
> If anything, the clk_name should just go into the con_id for now,
> and then it will need to be a globally unique identifier for the
> clk. But that is going against how clkdev is supposed to be used.
> Hence the question if you even need to use it. If not, just don't
> add it. I can fix up v3 of this patch to put clk_name back at
> con_id if you like. No need to resend.
Ok, I'm not very used with the CCF, so perhaps clk_name is not needed at all. I
gave a try with the following combination:
- con_id = NULL, dev_id = clk_name
- con_id = clk_name, dev_id = NULL
- con_id = NULL, dev_id = NULL
All worked.
And finally I removed the clk_hw_register_clkdev() call and it worked also.
So I'm not sure about this function.
Any idea ?
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> a Linux Foundation Collaborative Project
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
^ permalink raw reply
* Re: [PATCH v3] usb: dwc3: add disable u2mac linestate check quirk
From: Guenter Roeck @ 2017-04-19 19:44 UTC (permalink / raw)
To: William Wu
Cc: Felipe Balbi, gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
Heiko Stübner, linux-kernel,
linux-usb-u79uwXL29TY76Z2rM5mHXA, open list:ARM/Rockchip SoC...,
devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Frank Wang,
Tao Huang, Doug Anderson, Brian Norris,
daniel.meng-TNX95d0MmH7DzftRWevZcw,
John.Youn-HKixBCOQz3hWk0Htik3J/w
In-Reply-To: <1492603898-25070-1-git-send-email-william.wu-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
On Wed, Apr 19, 2017 at 5:11 AM, William Wu <william.wu-TNX95d0MmH7DzftRWevZcw@public.gmane.org> wrote:
> This patch adds a quirk to disable USB 2.0 MAC linestate check
> during HS transmit. Refer the dwc3 databook, we can use it for
> some special platforms if the linestate not reflect the expected
> line state(J) during transmission.
>
> When use this quirk, the controller implements a fixed 40-bit
> TxEndDelay after the packet is given on UTMI and ignores the
> linestate during the transmit of a token (during token-to-token
> and token-to-data IPGAP).
>
> On some rockchip platforms (e.g. rk3399), it requires to disable
> the u2mac linestate check to decrease the SSPLIT token to SETUP
> token inter-packet delay from 566ns to 466ns, and fix the issue
> that FS/LS devices not recognized if inserted through USB 3.0 HUB.
>
> Signed-off-by: William Wu <william.wu-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
Reviewed-by: Guenter Roeck <groeck-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
> ---
> Changes in v3:
> - change quirk name
> - only read and write GUCTL1 if dwc3 version >= 2.50a
>
> Changes in v2:
> - fix coding style
>
> Documentation/devicetree/bindings/usb/dwc3.txt | 2 ++
> drivers/usb/dwc3/core.c | 20 ++++++++++++++------
> drivers/usb/dwc3/core.h | 4 ++++
> 3 files changed, 20 insertions(+), 6 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt b/Documentation/devicetree/bindings/usb/dwc3.txt
> index f658f39..52fb410 100644
> --- a/Documentation/devicetree/bindings/usb/dwc3.txt
> +++ b/Documentation/devicetree/bindings/usb/dwc3.txt
> @@ -45,6 +45,8 @@ Optional properties:
> a free-running PHY clock.
> - snps,dis-del-phy-power-chg-quirk: when set core will change PHY power
> from P0 to P1/P2/P3 without delay.
> + - snps,dis-tx-ipgap-linecheck-quirk: when set, disable u2mac linestate check
> + during HS transmit.
> - snps,is-utmi-l1-suspend: true when DWC3 asserts output signal
> utmi_l1_suspend_n, false when asserts utmi_sleep_n
> - snps,hird-threshold: HIRD threshold
> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
> index 455d89a..9d5a67c 100644
> --- a/drivers/usb/dwc3/core.c
> +++ b/drivers/usb/dwc3/core.c
> @@ -796,13 +796,19 @@ static int dwc3_core_init(struct dwc3 *dwc)
> dwc3_writel(dwc->regs, DWC3_GUCTL2, reg);
> }
>
> - /*
> - * Enable hardware control of sending remote wakeup in HS when
> - * the device is in the L1 state.
> - */
> - if (dwc->revision >= DWC3_REVISION_290A) {
> + if (dwc->revision >= DWC3_REVISION_250A) {
> reg = dwc3_readl(dwc->regs, DWC3_GUCTL1);
> - reg |= DWC3_GUCTL1_DEV_L1_EXIT_BY_HW;
> +
> + /*
> + * Enable hardware control of sending remote wakeup
> + * in HS when the device is in the L1 state.
> + */
> + if (dwc->revision >= DWC3_REVISION_290A)
> + reg |= DWC3_GUCTL1_DEV_L1_EXIT_BY_HW;
> +
> + if (dwc->dis_tx_ipgap_linecheck_quirk)
> + reg |= DWC3_GUCTL1_TX_IPGAP_LINECHECK_DIS;
> +
> dwc3_writel(dwc->regs, DWC3_GUCTL1, reg);
> }
>
> @@ -1023,6 +1029,8 @@ static void dwc3_get_properties(struct dwc3 *dwc)
> "snps,dis-u2-freeclk-exists-quirk");
> dwc->dis_del_phy_power_chg_quirk = device_property_read_bool(dev,
> "snps,dis-del-phy-power-chg-quirk");
> + dwc->dis_tx_ipgap_linecheck_quirk = device_property_read_bool(dev,
> + "snps,dis-tx-ipgap-linecheck-quirk");
>
> dwc->tx_de_emphasis_quirk = device_property_read_bool(dev,
> "snps,tx_de_emphasis_quirk");
> diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
> index 981c77f..6f6294d 100644
> --- a/drivers/usb/dwc3/core.h
> +++ b/drivers/usb/dwc3/core.h
> @@ -204,6 +204,7 @@
> #define DWC3_GCTL_DSBLCLKGTNG BIT(0)
>
> /* Global User Control 1 Register */
> +#define DWC3_GUCTL1_TX_IPGAP_LINECHECK_DIS BIT(28)
> #define DWC3_GUCTL1_DEV_L1_EXIT_BY_HW BIT(24)
>
> /* Global USB2 PHY Configuration Register */
> @@ -850,6 +851,8 @@ struct dwc3_scratchpad_array {
> * provide a free-running PHY clock.
> * @dis_del_phy_power_chg_quirk: set if we disable delay phy power
> * change quirk.
> + * @dis_tx_ipgap_linecheck_quirk: set if we disable u2mac linestate
> + * check during HS transmit.
> * @tx_de_emphasis_quirk: set if we enable Tx de-emphasis quirk
> * @tx_de_emphasis: Tx de-emphasis value
> * 0 - -6dB de-emphasis
> @@ -1004,6 +1007,7 @@ struct dwc3 {
> unsigned dis_rxdet_inp3_quirk:1;
> unsigned dis_u2_freeclk_exists_quirk:1;
> unsigned dis_del_phy_power_chg_quirk:1;
> + unsigned dis_tx_ipgap_linecheck_quirk:1;
>
> unsigned tx_de_emphasis_quirk:1;
> unsigned tx_de_emphasis:2;
> --
> 2.0.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 v5 5/8] i2c: i2c-cbus-gpio: Add vendor prefix to retu node in example
From: Wolfram Sang @ 2017-04-19 19:41 UTC (permalink / raw)
To: Javier Martinez Canillas
Cc: linux-kernel, Aaro Koskinen, devicetree, Rob Herring,
Tony Lindgren, Lee Jones, linux-i2c, Mark Rutland
In-Reply-To: <20170412172800.23035-6-javier@osg.samsung.com>
[-- Attachment #1: Type: text/plain, Size: 596 bytes --]
On Wed, Apr 12, 2017 at 02:27:56PM -0300, Javier Martinez Canillas wrote:
> The example contains a device node for a retu device, but
> its compatible string doesn't have a vendor prefix.
>
> While being there, drop the -mfd suffix since isn't correct.
>
> Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
> Acked-by: Rob Herring <robh@kernel.org>
> Acked-by: Aaro Koskinen <aaro.koskinen@iki.fi>
> Acked-by: Tony Lindgren <tony@atomide.com>
>
Reviewed-by: Wolfram Sang <wsa@the-dreams.de>
I assume this goes with the rest of the series and not via my tree.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [v5,4/8] ARM: dts: n8x0: Add vendor prefix to retu node
From: Wolfram Sang @ 2017-04-19 19:40 UTC (permalink / raw)
To: Javier Martinez Canillas
Cc: linux-kernel, Aaro Koskinen, devicetree, Rob Herring,
Tony Lindgren, Lee Jones, Benoît Cousson, Mark Rutland,
linux-omap, Russell King, linux-arm-kernel
In-Reply-To: <20170412172800.23035-5-javier@osg.samsung.com>
[-- Attachment #1: Type: text/plain, Size: 441 bytes --]
On Wed, Apr 12, 2017 at 02:27:55PM -0300, Javier Martinez Canillas wrote:
> The retu device node doesn't have a vendor prefix
> in its compatible string, fix it by adding one.
>
> Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
> Acked-by: Rob Herring <robh@kernel.org>
> Acked-by: Aaro Koskinen <aaro.koskinen@iki.fi>
> Acked-by: Tony Lindgren <tony@atomide.com>
Reviewed-by: Wolfram Sang <wsa@the-dreams.de>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [v5,3/8] mfd: retu: Add OF device ID table
From: Wolfram Sang @ 2017-04-19 19:40 UTC (permalink / raw)
To: Javier Martinez Canillas
Cc: linux-kernel, Aaro Koskinen, devicetree, Rob Herring,
Tony Lindgren, Lee Jones
In-Reply-To: <20170412172800.23035-4-javier@osg.samsung.com>
[-- Attachment #1: Type: text/plain, Size: 825 bytes --]
On Wed, Apr 12, 2017 at 02:27:54PM -0300, Javier Martinez Canillas wrote:
> The driver doesn't have a struct of_device_id table but supported devices
> are registered via Device Trees. This is working on the assumption that a
> I2C device registered via OF will always match a legacy I2C device ID and
> that the MODALIAS reported will always be of the form i2c:<device>.
>
> But this could change in the future so the correct approach is to have a
> OF device ID table if the devices are registered via OF.
>
> Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
> Acked-by: Rob Herring <robh@kernel.org>
> Acked-by: Aaro Koskinen <aaro.koskinen@iki.fi>
> Acked-by: Tony Lindgren <tony@atomide.com>
> Acked-by: Lee Jones <lee.jones@linaro.org>
Reviewed-by: Wolfram Sang <wsa@the-dreams.de>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [v5,2/8] mfd: retu: Drop -mfd suffix from I2C device ID name
From: Wolfram Sang @ 2017-04-19 19:40 UTC (permalink / raw)
To: Javier Martinez Canillas
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA, Aaro Koskinen,
devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Tony Lindgren,
Lee Jones, Benoît Cousson, Mark Rutland,
linux-omap-u79uwXL29TY76Z2rM5mHXA, Russell King,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20170412172800.23035-3-javier-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 735 bytes --]
On Wed, Apr 12, 2017 at 02:27:53PM -0300, Javier Martinez Canillas wrote:
> It's not correct to encode the subsystem in the I2C device name, so
> drop the -mfd suffix. To maintain bisect-ability, change driver and
> platform code / DTS users in the same patch.
>
> Suggested-by: Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> Signed-off-by: Javier Martinez Canillas <javier-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>
> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Acked-by: Aaro Koskinen <aaro.koskinen-X3B1VOXEql0@public.gmane.org>
> Acked-by: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
Reviewed-by: Wolfram Sang <wsa-z923LK4zBo2bacvFa/9K2g@public.gmane.org>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [v5,1/8] dt-bindings: mfd: Add retu/tahvo ASIC chips bindings
From: Wolfram Sang @ 2017-04-19 19:39 UTC (permalink / raw)
To: Javier Martinez Canillas
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA, Aaro Koskinen,
devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Tony Lindgren,
Lee Jones, Mark Rutland
In-Reply-To: <20170412172800.23035-2-javier-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 2869 bytes --]
On Wed, Apr 12, 2017 at 02:27:52PM -0300, Javier Martinez Canillas wrote:
> There are Device Tree source files defining a device node for the
> retu/tahvo I2C chip, but there isn't a DT binding document for it.
>
> Signed-off-by: Javier Martinez Canillas <javier-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>
> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Acked-by: Aaro Koskinen <aaro.koskinen-X3B1VOXEql0@public.gmane.org>
> Acked-by: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
> Acked-by: Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> ---
>
> Changes in v5:
> - Add missing properties for interrupts to DT binding doc (Rob Herring).
> - Add Rob Herring's Acked-by tag.
> - Add Aaro Koskinen's Acked-by tag.
> - Add Acked-by: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>'s Acked-by tag.
> - Add Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>'s Acked-by tag.
>
> Changes in v4:
> - Use "dt-bindings: mfd:" prefix in subject line (Rob Herring).
> - Add information about what functions the device serve (Lee Jones).
> - Avoid using MFD in Device Tree (Lee Jones).
>
> Changes in v3: None
> Changes in v2: None
>
> Documentation/devicetree/bindings/mfd/retu.txt | 23 +++++++++++++++++++++++
> 1 file changed, 23 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mfd/retu.txt
>
> diff --git a/Documentation/devicetree/bindings/mfd/retu.txt b/Documentation/devicetree/bindings/mfd/retu.txt
> new file mode 100644
> index 000000000000..e1ea3a36a038
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/retu.txt
> @@ -0,0 +1,23 @@
> +* Device tree bindings for Nokia Retu and Tahvo multi-function device
> +
> +Retu and Tahvo are a multi-function devices found on Nokia Internet
> +Tablets (770, N800 and N810). The Retu chip provides watchdog timer
> +and power button control functionalities while Tahvo chip provides
> +USB transceiver functionality.
> +
> +Required properties:
> +- compatible: "nokia,retu" or "nokia,tahvo"
> +- reg: Specifies the I2C slave address of the ASIC chip
This should be "CBUS slave address". CBUS is a strange subset of I2C,
yet I'd like the distinction because 0x1 is not a valid I2C address.
> +- interrupts: The interrupt line the device is connected to
> +- interrupt-parent: The parent interrupt controller
> +
> +Example:
> +
> +i2c0 {
To make it super clear, we are talking CBUS here, it might make sense to
add here:
+ compatible = "i2c-cbus-gpio";
+ ...
? It could be argued that the above "i2c0" should be "cbus0" as well but
that is a separate issue, I'd think.
> + retu: retu@1 {
> + compatible = "nokia,retu";
> + interrupt-parent = <&gpio4>;
> + interrupts = <12 IRQ_TYPE_EDGE_RISING>;
> + reg = <0x1>;
> + };
> +};
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH 2/3] drm/vc4: Don't try to initialize FBDEV if we're only bound to V3D.
From: Daniel Vetter @ 2017-04-19 19:36 UTC (permalink / raw)
To: Eric Anholt
Cc: Mark Rutland, devicetree@vger.kernel.org, Rob Herring,
Linux Kernel Mailing List, dri-devel
In-Reply-To: <8760i046zw.fsf@eliezer.anholt.net>
On Wed, Apr 19, 2017 at 7:55 PM, Eric Anholt <eric@anholt.net> wrote:
> Daniel Vetter <daniel@ffwll.ch> writes:
>> On Tue, Apr 18, 2017 at 9:11 PM, Eric Anholt <eric@anholt.net> wrote:
>>> The FBDEV initialization would throw an error in dmesg, when we just
>>> want to silently not initialize fbdev on a V3D-only VC4 instance.
>>>
>>> Signed-off-by: Eric Anholt <eric@anholt.net>
>>
>> Hm, this shouldn't be an error really, you might want to hotplug more
>> connectors later on. What exactly complains?
>
> drm_fb_helper_init() throws an error if the passed in connector count is
> 0, so drm_fb_cma_helper() printks an error.
Oh, _that_ thing. The error in there is correct, but (almost) everyone
gets this parameter wrong. This isn't the max number of connectors the
fb helper will light up, but just the max number of connectors _per_
crtc when driving in hw clone mode. There's two problems with that:
- fb helpers don't support hw clone mode, we select 1:1 crtcs for each
active connector
- I mentioned that everyone gets this wrong?
If you're moderately bored it'd be great to nuke the max_connector
argument from drm_fb_helper_init, and hard-code it to 1 (with a big
comment explaining that this needs to be changed, probably with
dynamic reallocation, once someone gets around to implementing hw
clone mode).
If you're less bored, just hardcode this to 1 in vc4 and done. Plus a
TODO.rst entry would be great in that case.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH v5 5/8] i2c: i2c-cbus-gpio: Add vendor prefix to retu node in example
From: Javier Martinez Canillas @ 2017-04-19 19:13 UTC (permalink / raw)
To: Wolfram Sang
Cc: linux-kernel, Aaro Koskinen, devicetree, Rob Herring,
Tony Lindgren, Lee Jones, linux-i2c, Mark Rutland
In-Reply-To: <20170419185113.msqhjm7fzqfeyjlk@ninjato>
Hello Wolfram,
On 04/19/2017 02:51 PM, Wolfram Sang wrote:
> On Wed, Apr 12, 2017 at 02:27:56PM -0300, Javier Martinez Canillas wrote:
>> The example contains a device node for a retu device, but
>> its compatible string doesn't have a vendor prefix.
>>
>> While being there, drop the -mfd suffix since isn't correct.
>>
>> Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
>> Acked-by: Rob Herring <robh@kernel.org>
>> Acked-by: Aaro Koskinen <aaro.koskinen@iki.fi>
>> Acked-by: Tony Lindgren <tony@atomide.com>
>
> Wouldn't it be nice if we fix the driver also so it actually matches the
> below compatible? I can't find such a change in linux-next.
>
[snip]
>>
>> - retu-mfd: retu@1 {
>> - compatible = "retu-mfd";
>> + retu: retu@1 {
>> + compatible = "nokia,retu";
>> reg = <0x1>;
>> };
You mean having a "nokia,retu" entry in a OF table?
That's done by patch 3/8 in this series:
http://www.spinics.net/lists/devicetree/msg173145.html
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
^ permalink raw reply
* Re: [PATCH v5 5/8] i2c: i2c-cbus-gpio: Add vendor prefix to retu node in example
From: Wolfram Sang @ 2017-04-19 18:51 UTC (permalink / raw)
To: Javier Martinez Canillas
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA, Aaro Koskinen,
devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Tony Lindgren,
Lee Jones, linux-i2c-u79uwXL29TY76Z2rM5mHXA, Mark Rutland
In-Reply-To: <20170412172800.23035-6-javier-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1713 bytes --]
On Wed, Apr 12, 2017 at 02:27:56PM -0300, Javier Martinez Canillas wrote:
> The example contains a device node for a retu device, but
> its compatible string doesn't have a vendor prefix.
>
> While being there, drop the -mfd suffix since isn't correct.
>
> Signed-off-by: Javier Martinez Canillas <javier-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>
> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Acked-by: Aaro Koskinen <aaro.koskinen-X3B1VOXEql0@public.gmane.org>
> Acked-by: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
Wouldn't it be nice if we fix the driver also so it actually matches the
below compatible? I can't find such a change in linux-next.
> ---
>
> Changes in v5:
> - Add Rob Herring's Acked-by tag.
> - Add Aaro Koskinen's Acked-by tag.
> - Add Acked-by: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>'s Acked-by tag.
>
> Changes in v4:
> - Avoid using MFD in Device Tree (Lee Jones).
>
> Changes in v3: None
> Changes in v2: None
>
> Documentation/devicetree/bindings/i2c/i2c-cbus-gpio.txt | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/i2c/i2c-cbus-gpio.txt b/Documentation/devicetree/bindings/i2c/i2c-cbus-gpio.txt
> index 8ce9cd2855b5..c143948b2a37 100644
> --- a/Documentation/devicetree/bindings/i2c/i2c-cbus-gpio.txt
> +++ b/Documentation/devicetree/bindings/i2c/i2c-cbus-gpio.txt
> @@ -20,8 +20,8 @@ i2c@0 {
> #address-cells = <1>;
> #size-cells = <0>;
>
> - retu-mfd: retu@1 {
> - compatible = "retu-mfd";
> + retu: retu@1 {
> + compatible = "nokia,retu";
> reg = <0x1>;
> };
> };
> --
> 2.9.3
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH] of: introduce event tracepoints for dynamic device_node lifecyle
From: Tyrel Datwyler @ 2017-04-19 18:45 UTC (permalink / raw)
To: Steven Rostedt, Frank Rowand
Cc: Tyrel Datwyler, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
nfont-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8,
mpe-Gsx/Oe8HsFggBc27wqDAHg, mingo-H+wXaHxf7aLQT0dZR+AlfA
In-Reply-To: <20170418224953.685943a3-2kNGR76GQU9OHLTnHDQRgA@public.gmane.org>
On 04/18/2017 07:49 PM, Steven Rostedt wrote:
> On Tue, 18 Apr 2017 18:42:32 -0700
> Frank Rowand <frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
>> And of course the other issue with using tracepoints is the extra space
>> required to hold the tracepoint info. With the pr_debug() approach, the
>> space usage can be easily removed for a production kernel via a config
>> option.
>
> Now if you are saying you want to be able to enable debugging without
> the tracing infrastructure I would agree. As the tracing infrastructure
> is large. But I'm working on shrinking it more.
The primary consumers of OF_DYNAMIC seem to be pseries and powernv where
we are generally going to see the trace infrastructure enabled by
default in production.
-Tyrel
>
>>
>> Tracepoints are wonderful technology, but not always the proper tool to
>> use for debug info.
>
> But if you are going to have tracing enabled regardless, adding a few
> more tracepoints isn't going to make the difference.
>
> -- Steve
>
>>
>>> If Rob wants to convert printk() style data to trace data (and I can't
>>> convince him otherwise) then I will have further comments on this specific
>>> patch.
>>>
--
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] mtd: use dev_of_node helper in mtd_get_of_node
From: Brian Norris @ 2017-04-19 18:39 UTC (permalink / raw)
To: Boris Brezillon
Cc: Rafał Miłecki, David Woodhouse, Marek Vasut,
Richard Weinberger, Cyrille Pitchen,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, Rafał Miłecki
In-Reply-To: <20170331114950.726c9cb7@bbrezillon>
On Fri, Mar 31, 2017 at 11:49:50AM +0200, Boris Brezillon wrote:
> On Fri, 31 Mar 2017 11:11:48 +0200
> Rafał Miłecki <zajec5-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
> > From: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
> >
> > This allows better compile-time optimizations with CONFIG_OF disabled.
> >
> > Signed-off-by: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
>
> Not sure we care about such micro-optimizations, but it shouldn't hurst
> so,
>
> Acked-by: Boris Brezillon <boris.brezillon-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Applied
--
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] of: introduce event tracepoints for dynamic device_node lifecyle
From: Tyrel Datwyler @ 2017-04-19 18:33 UTC (permalink / raw)
To: Frank Rowand, Michael Ellerman, Tyrel Datwyler,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
rostedt-nx8X9YLhiw1AfugRpC6u6w, mingo-H+wXaHxf7aLQT0dZR+AlfA,
nfont-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8,
linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ
In-Reply-To: <58F6CBF9.7060000-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On 04/18/2017 07:31 PM, Frank Rowand wrote:
> On 04/18/17 18:31, 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.
>
> Yes, I am talking about pr_debug(), pr_info(), pr_err(), etc.
>
>
>>
>> They also only cover the reconfig case, which is actually less
>> interesting than the much more common and bug-prone get/put logic.
>
> When I was looking at the get/put issue I used pr_debug().
>
>
>>> 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().
>
> Except the existing debug code that uses pr_debug() does not use
> trace_printk().
>
> And "just sort" does not apply to multi-line output like:
>
> cpuhp/23-147 [023] .... 128.324827:
> of_node_put: refcount=5, dn->full_name=/cpus/PowerPC,POWER8@10
> cpuhp/23-147 [023] .... 128.324829:
> of_node_put: refcount=4, dn->full_name=/cpus/PowerPC,POWER8@10
> cpuhp/23-147 [023] .... 128.324829:
> of_node_put: refcount=3, dn->full_name=/cpus/PowerPC,POWER8@10
> cpuhp/23-147 [023] .... 128.324831:
> of_node_put: refcount=2, dn->full_name=/cpus/PowerPC,POWER8@10
> drmgr-7284 [009] .... 128.439000:
> of_node_put: refcount=1, dn->full_name=/cpus/PowerPC,POWER8@10
> drmgr-7284 [009] .... 128.439002:
> of_reconfig_notify: action=DETACH_NODE, dn->full_name=/cpus/PowerPC,POWER8@10,
> prop->name=null, old_prop->name=null
> drmgr-7284 [009] .... 128.439015:
> of_node_put: refcount=0, dn->full_name=/cpus/PowerPC,POWER8@10
> drmgr-7284 [009] .... 128.439016:
> of_node_release: dn->full_name=/cpus/PowerPC,POWER8@10, dn->_flags=4
>
> I was kinda hoping that maybe someone had already created a tool to deal
> with this issue. But not too optimistic.
This output was actually broken into multiple lines for the commit
message. Each trace point is actually a single line in the trace buffer.
This output was pulled from the trace buffer with the following:
cat /sys/kernel/debug/trace/tracing | grep "POWER8@10"
-Tyrel
>
>
>> 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.
>>
>> 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
^ permalink raw reply
* Re: [PATCH 0/8] i.MX7 PCIe related device tree changes
From: Tyler Baker @ 2017-04-19 18:28 UTC (permalink / raw)
To: Andrey Smirnov
Cc: Shawn Guo, yurovsky-Re5JQEeQqe8AvxtiuMwx3w, Sascha Hauer,
Fabio Estevam, Rob Herring, Mark Rutland, Russell King,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel
In-Reply-To: <20170413133242.5068-1-andrew.smirnov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On 13 April 2017 at 06:32, Andrey Smirnov <andrew.smirnov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> Shawn, everyone:
>
> This series includes changes made to device-tree in order to support
> PCIe on i.MX7 platform. They include:
>
> - Bringing 'anatop-enable-bit' property of ANATOP regulators back
> and extending it to all of the HW it is applicable to
>
> - Adding GPCv2 node for i.MX7 (which was missing, despite the
> irqchip driver for it being in the tree for quite some time)
>
> - Adding a PCIe node for i.MX7
>
> - Adding GPIO expander used by PCIe and enabling PCIe node from
> above on i.MX7 based Sabre board
>
> As usual, feedback is welcome.
>
> Thanks,
> Andrey Smrinov
>
> Andrey Smirnov (8):
> Revert "ARM: dts: imx: Remove unexistant property"
> ARM: dts: imx6: Specify 'anatop-enable-bit' where appropriate
> ARM: dts: imx7s: Adjust anatop-enable-bit for 'reg_1p0d'
> ARM: dts: imx7s: Add node for GPC
> ARM: dts: imx7s: Mark 'gpr' compatible with i.MX6 variant
> ARM: dts: imx7d-sdb: Add GPIO expander node
> ARM: dts: imx7d: Add node for PCIe controller
> ARM: dts: imx7d-sdb: Enable PCIe peripheral
FWIW:
Tested-by: Tyler Baker <tyler.baker-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
This whole series on top of v4.11-rc7, with the addition of the iMX7
GPCv2 and reset driver. Tested on a imx7d-cl-som with a CUK Killer
Doubleshot Wireless-AC 1535 wlan/bt radio using a mini pcie to m2
adapter. Confirmed that the radio was able to associate with an AP
using WPA2, and connected to multiple devices using 6lowpan over BLE.
Tyler
--
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