* Re: [PATCH 1/6] ARM: dts: am335x-phycore-som: Update NAND partition table
From: Tony Lindgren @ 2017-01-06 16:14 UTC (permalink / raw)
To: Adam Ford
Cc: Teresa Remmet, Brian Norris, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA, Brian Norris, Rob Herring,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Benoît Cousson,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <CAHCN7xL2n0qsg61i85o7DczanMH1E=HWhNvqUtTH9UhEVBvd8g-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
* Adam Ford <aford173-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> [170106 08:06]:
> On Fri, Jan 6, 2017 at 10:02 AM, Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> wrote:
> > * Teresa Remmet <t.remmet-guT5V/WYfQezQB+pC5nmwQ@public.gmane.org> [170106 01:28]:
> >> Hello Brian,
> >>
> >> Am Donnerstag, den 05.01.2017, 09:56 -0800 schrieb Brian Norris:
> >> > On Thu, Jan 05, 2017 at 09:18:45AM -0800, Tony Lindgren wrote:
> >> > >
> >> > > * Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> [170105 07:37]:
> >> > > >
> >> > > > * Teresa Remmet <t.remmet-guT5V/WYfQezQB+pC5nmwQ@public.gmane.org> [170105 06:57]:
> >> > > > >
> >> > > > > To improve NAND safety we updated the partition layout.
> >> > > > > Added barebox backup partition and removed kernel and oftree
> >> > > > > partition. They are kept in ubi now.
> >> > > > What about the users with earlier partition tables?
> >> > > >
> >> > > > Please read about "flag day" changes, typically they are not
> >> > > > acceptable.
> >> > > Adding Brian and Adam to Cc. Can you guys come up with some
> >> > > solution on this?
> >> > I don't have much context for this thread, and no I don't plan to
> >> > solve
> >> > your problems for you. But I can provide tips!
> >> >
> >> > >
> >> > > I'm suggesting we leave the kernel nodes empty and let u-boot
> >> > > populate them, so maybe you guys can discuss this on the related
> >> > > lists.
> >> > That's an option. I've worked with platforms that did something like
> >> > this, and that's really one of the only ways you can handle putting
> >> > partition information in the device tree. You're really hamstringing
> >> > yourself when you put all the partition information in the device
> >> > tree.
> >> > And it's just dumb once that gets codified in the kernel source tree.
> >> >
> >>
> >> In our case the bootloader does pass the partition table to the kernel.
> >> So it gets overwritten anyway. This was just more for backup,
> >> if someone uses a different bootloader. But I'm fine with removing the
> >> nand partition table completely from the kernel device tree.
> >> Same with the SPI nor partition table.
> >>
> >> I will send patches for this.
> >
> > OK thanks! Also thank you Brian for your comments.
> >
>
> Tony - I tested leaving the partition info as-is with the updates from
> the bootloader and it works. Would you prefer that I match Brian and
> remove the partition table completely, or should I just leave my board
> alone?
>
> I am good either way.
OK. How about let's remove the partitions from kernel for v4.11 as
clean-up then for cases where the bootloader might change them?
Regards,
Tony
--
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 6/9] dt/bindings: Add a serial/UART attached device binding
From: Rob Herring @ 2017-01-06 16:26 UTC (permalink / raw)
To: Greg Kroah-Hartman, Marcel Holtmann, Jiri Slaby,
Sebastian Reichel, Arnd Bergmann, Dr . H . Nikolaus Schaller,
Peter Hurley, Andy Shevchenko, Alan Cox
Cc: Loic Poulain, Pavel Machek, NeilBrown, Linus Walleij,
linux-bluetooth-u79uwXL29TY76Z2rM5mHXA,
linux-serial-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170106162635.19677-1-robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Add a common binding for describing serial/UART attached devices. Common
examples are Bluetooth, WiFi, NFC and GPS devices.
Serial attached devices are represented as child nodes of a UART node.
This may need to be extended for more complex devices with multiple
interfaces, but for the simple cases a child node is sufficient.
Signed-off-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
.../devicetree/bindings/serial/slave-device.txt | 34 ++++++++++++++++++++++
1 file changed, 34 insertions(+)
create mode 100644 Documentation/devicetree/bindings/serial/slave-device.txt
diff --git a/Documentation/devicetree/bindings/serial/slave-device.txt b/Documentation/devicetree/bindings/serial/slave-device.txt
new file mode 100644
index 000000000000..9b7c2d651345
--- /dev/null
+++ b/Documentation/devicetree/bindings/serial/slave-device.txt
@@ -0,0 +1,34 @@
+Serial Slave Device DT binding
+
+This documents the binding structure and common properties for serial
+attached devices. Common examples include Bluetooth, WiFi, NFC and GPS
+devices.
+
+qSerial attached devices shall be a child node of the host UART device the
+slave device is attached to. It is expected that the attached device is
+the only child node of the UART device. The slave device node name shall
+reflect the generic type of device for the node.
+
+Required Properties:
+
+- compatible : A string reflecting the vendor and specific device the node
+ represents.
+
+Optional Properties:
+
+- reg : A single cell representing the port/line number of the
+ host UART. Only used if the host UART is a single node
+ with multiple ports.
+
+Example:
+
+serial@1234 {
+ compatible = "ns16550a";
+ interrupts = <1>;
+
+ bluetooth {
+ compatible = "brcm,bcm43341-bt";
+ interrupt-parent = <&gpio>;
+ interrupts = <10>;
+ };
+};
--
2.10.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 related
* Re: [RFC 1/3] iommu/arm-smmu: Add support to opt-in to stalling
From: Rob Clark @ 2017-01-06 16:26 UTC (permalink / raw)
To: Will Deacon
Cc: Mark Rutland, Rob Herring,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-arm-msm,
Jordan Crouse,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
In-Reply-To: <20170105154950.GM679-5wv7dgnIgG8@public.gmane.org>
On Thu, Jan 5, 2017 at 10:49 AM, Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org> wrote:
> On Thu, Jan 05, 2017 at 10:27:27AM -0500, Rob Clark wrote:
>> On Thu, Jan 5, 2017 at 6:55 AM, Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org> wrote:
>> > On Tue, Jan 03, 2017 at 04:30:54PM -0500, Rob Clark wrote:
>> >> TODO maybe we want two options, one to enable stalling, and 2nd to punt
>> >> handling to wq? I haven't needed to use mm APIs from fault handler yet
>> >> (although it is something that I think we'll want some day). Perhaps
>> >> stalling support is limited to just letting driver dump some extra
>> >> debugging information otherwise. Threaded handling probably only useful
>> >> with stalling, but inverse may not always be true.
>> >
>> > I'd actually like to see this stuck on a worker thread, because I think
>> > that's more generally useful and I don't want to have a situation where
>> > sometimes the IOMMU fault notifier is run in IRQ context and sometimes it's
>> > not.
>>
>> So I was talking a bit w/ Jordan on IRC yesterday.. and we also have
>> the GPU's hw hang-detect to contend with. So I *suspect* that when we
>> get to the point of using this to do things like page in things from
>> swap and resume the faulting transaction, we probably want to get
>> called immediately from the IRQ handler so we can disable the hw
>> hang-detect.
>
> Well, if you want to use an SMMU for paging, then the GPU driver would
> need to request that explicitly when allocating its DMA buffers, to that
> would be the time to either delay or disable the hang detection.
If userspace is using SVM, for example, it is pretty impossible to
know when to expect a fault. The best you could do is keep track that
*some* process which has active work queued up for gpu is using SVM
and disable hang detect for *everyone*.. which is kind of sad.
>> I'm not sure if the better solution then would be to have two fault
>> callbacks, one immediately from the IRQ and a later one from wq. Or
>> let the driver handle the wq business and give it a way to tell the
>> IOMMU when to resume.
>>
>> I kinda think we should punt on the worker thread for now until we are
>> ready to resume faulting transactions, because I guess a strong chance
>> that whatever way we do it now will be wrong ;-)
>
> I guess what I'm after is for you to change the interrupt handlers to be
> threaded, like they are for SMMUv3. I *think* you can do that with a NULL
> thread_fn for now, and just call report_iommu_fault from the handler.
> The return value of that could, in theory, be used to queued the paging
> request and wake the paging thread in future.
If we only pass in the non-threaded irq fxn, I'm not really sure how
that changes anything.. or maybe I'm not understanding what you mean.
But yeah, I guess we could use request_threaded_irq() to get both IRQ
context notification and a later thread context notification rather
than doing the wq thing. Either way the iommu API has to change
slightly.
>> > I wonder if this should also be predicated on the compatible string, so
>> > that the "arm,smmu-enable-stall" property is ignored (with a warning) if
>> > the compatible string isn't specific enough to identify an implementation
>> > with the required SS behaviour? On the other hand, it feels pretty
>> > redundant and a single "stalling works" property is all we need.
>>
>> We could also drop the property and key the behavior on specific
>> compat strings I guess. Having both seems a bit odd. Anyways, I'll
>> defer to DT folks about what the cleaner approach is.
>
> As Robin pointed out, we do need to be able to distinguish the integration
> of the device from the device itself. For example, MMU-9000 might be capable
> of stalling, but if it's bolted to a PCI RC, it's not safe to do so.
Hmm, well we install the fault handler on the iommu_domain.. perhaps
maybe a combo of dts property (or deciding based on more specific
compat string), plus extra param passed in to
iommu_set_fault_hander(). The dts property or compat string to
indicate whether the iommu (and how it is wired up) can handle stalls,
and enable_stall param when fault handler is registered to indicate
whether the device itself can cope.. if either can't do stalling, then
don't set CFCFG.
BR,
-R
^ permalink raw reply
* Re: [PATCH] i2c: core: helper function to detect slave mode
From: Andy Shevchenko @ 2017-01-06 16:29 UTC (permalink / raw)
To: Luis Oliveira
Cc: Wolfram Sang, Rob Herring, Mark Rutland, Jarkko Nikula,
Andy Shevchenko, Mika Westerberg, linux-i2c, devicetree,
linux-kernel@vger.kernel.org, Ramiro.Oliveira, Joao Pinto,
CARLOS.PALMINHA
In-Reply-To: <f4ec62119145bc70c938800c91eb396d30457304.1483636071.git.lolivei@synopsys.com>
On Thu, Jan 5, 2017 at 7:24 PM, Luis Oliveira
<Luis.Oliveira@synopsys.com> wrote:
> This function has the purpose of mode detection by checking the
> device nodes for a reg matching with the I2C_OWN_SLAVE_ADDREESS flag.
> Currently only checks using OF functions (ACPI slave not supported yet).
The code looks good, one important comment below, after addressing it:
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
P.S. Btw, we have Suggested-by tag for giving credit for suggestion.
Please use it.
> --- a/drivers/i2c/i2c-core.c
> +++ b/drivers/i2c/i2c-core.c
> @@ -3691,6 +3691,25 @@ int i2c_slave_unregister(struct i2c_client *client)
Please, add kernel doc description here, important thing is to explain
return codes in Return: section of it.
> +int i2c_slave_mode_detect(struct device *dev)
> +{
> + struct device_node *child;
> + u32 reg;
I would consider them as private to the OF branch. But it's really
minor and up to you (I don't remember if we have such style examples
in i2c core code).
> +
> + if (IS_BUILTIN(CONFIG_OF) && dev->of_node) {
> + for_each_child_of_node(dev->of_node, child) {
> + of_property_read_u32(child, "reg", ®);
> + if (reg & I2C_OWN_SLAVE_ADDRESS)
> + return 1;
> + }
> + } else if (IS_BUILTIN(CONFIG_ACPI) && ACPI_HANDLE(dev)) {
> + dev_dbg(dev, "ACPI slave is not supported yet\n");
> + }
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(i2c_slave_mode_detect);
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [RESEND PATCH] ARM: dts: stm32f469-disco: Fix memory size from 8MB to 16MB
From: Alexandre Torgue @ 2017-01-06 16:33 UTC (permalink / raw)
To: Bruno Meirelles Herrera, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, linux-I+IVW8TIWO2tmTQ+vhA3Yw,
mcoquelin.stm32-Re5JQEeQqe8AvxtiuMwx3w
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20161118145845.30455-1-bmh-Mok47lTHhVP0xEqrn79Vhg@public.gmane.org>
Hi Bruno,
On 11/18/2016 03:58 PM, Bruno Meirelles Herrera wrote:
> From: Bruno Herrera <bruherrera-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>
> This patch fix memory size to support 16MB of external SDRAM.
>
> Signed-off-by: Bruno Herrera <bruherrera-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> ---
> arch/arm/boot/dts/stm32f469-disco.dts | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/stm32f469-disco.dts b/arch/arm/boot/dts/stm32f469-disco.dts
> index 75f4303..fda12a4 100644
> --- a/arch/arm/boot/dts/stm32f469-disco.dts
> +++ b/arch/arm/boot/dts/stm32f469-disco.dts
> @@ -58,7 +58,7 @@
> };
>
> memory {
> - reg = <0x00000000 0x800000>;
> + reg = <0x00000000 0x1000000>;
> };
>
> aliases {
>
After a little cosmetic change in commit header:
Applied on stm32-dt-for-v4.11-1
Thanks!
Alex
--
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: [RESEND PATCH v1] ARM: dts: stm32f429: Add missing USART3 pin config to STM32F469I-DISCO board
From: Alexandre Torgue @ 2017-01-06 16:34 UTC (permalink / raw)
To: Bruno Meirelles Herrera, robh+dt, mark.rutland, linux,
mcoquelin.stm32
Cc: devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <20161118151033.30592-1-bmh@certi.org.br>
Hi Bruno,
On 11/18/2016 04:10 PM, Bruno Meirelles Herrera wrote:
> Including new STM32 maintainer. Rebased at stm32-dt-for-v4.10-1 and
> stm32-dt-for-v4.10-2 branches. It fix the port/pin initialization in
> case boot-loader does not configure/initialize the pins.
> Fixing line wrapping from last patch
>
> This patch adds USART3 pin configuration on PB10/PA11 pins
> for STM32F469I-DISCO board.
>
> Signed-off-by: Bruno Herrera <bruherrera@gmail.com>
> ---
> arch/arm/boot/dts/stm32f429.dtsi | 13 +++++++++++++
> arch/arm/boot/dts/stm32f469-disco.dts | 2 ++
> 2 files changed, 15 insertions(+)
>
> diff --git a/arch/arm/boot/dts/stm32f429.dtsi b/arch/arm/boot/dts/stm32f429.dtsi
> index e4dae0e..1b8b105 100644
> --- a/arch/arm/boot/dts/stm32f429.dtsi
> +++ b/arch/arm/boot/dts/stm32f429.dtsi
> @@ -316,6 +316,19 @@
> };
> };
>
> + usart3_pins_a: usart3@0 {
> + pins1 {
> + pinmux = <STM32F429_PB10_FUNC_USART3_TX>;
> + bias-disable;
> + drive-push-pull;
> + slew-rate = <0>;
> + };
> + pins2 {
> + pinmux = <STM32F429_PB11_FUNC_USART3_RX>;
> + bias-disable;
> + };
> + };
> +
> usbotg_hs_pins_a: usbotg_hs@0 {
> pins {
> pinmux = <STM32F429_PH4_FUNC_OTG_HS_ULPI_NXT>,
> diff --git a/arch/arm/boot/dts/stm32f469-disco.dts b/arch/arm/boot/dts/stm32f469-disco.dts
> index 8877c00..75f4303 100644
> --- a/arch/arm/boot/dts/stm32f469-disco.dts
> +++ b/arch/arm/boot/dts/stm32f469-disco.dts
> @@ -79,5 +79,7 @@
> };
>
> &usart3 {
> + pinctrl-0 = <&usart3_pins_a>;
> + pinctrl-names = "default";
> status = "okay";
> };
>
After a little cosmetic change in commit header:
Applied on stm32-dt-for-v4.11-1
Thanks!
Alex
^ permalink raw reply
* Re: [PATCH] i2c: core: helper function to detect slave mode
From: Rob Herring @ 2017-01-06 16:35 UTC (permalink / raw)
To: Luis Oliveira
Cc: wsa@the-dreams.de, Mark Rutland, jarkko.nikula@linux.intel.com,
Andy Shevchenko, mika.westerberg@linux.intel.com,
linux-i2c@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, roliveir, Joao Pinto,
CARLOS.PALMINHA
In-Reply-To: <f4ec62119145bc70c938800c91eb396d30457304.1483636071.git.lolivei@synopsys.com>
On Thu, Jan 5, 2017 at 11:24 AM, Luis Oliveira
<Luis.Oliveira@synopsys.com> wrote:
> This function has the purpose of mode detection by checking the
> device nodes for a reg matching with the I2C_OWN_SLAVE_ADDREESS flag.
> Currently only checks using OF functions (ACPI slave not supported yet).
>
> Signed-off-by: Luis Oliveira <lolivei@synopsys.com>
> ---
> Due to the need of checking if the I2C slave address is our own (in
> other words: if we are the I2C slave) I created a helper function
> (proposed to me by @Andy) to enable that check.
> Currently (because I am not able to test it using ACPI) it only
> supports devicetree declarations.
>
> drivers/i2c/i2c-core.c | 19 +++++++++++++++++++
> include/linux/i2c.h | 1 +
> 2 files changed, 20 insertions(+)
>
> diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
> index 3de95a29024c..48e705b23c59 100644
> --- a/drivers/i2c/i2c-core.c
> +++ b/drivers/i2c/i2c-core.c
> @@ -3691,6 +3691,25 @@ int i2c_slave_unregister(struct i2c_client *client)
> return ret;
> }
> EXPORT_SYMBOL_GPL(i2c_slave_unregister);
> +
> +int i2c_slave_mode_detect(struct device *dev)
This can be bool instead. Otherwise, looks good to me.
> +{
> + struct device_node *child;
> + u32 reg;
> +
> + if (IS_BUILTIN(CONFIG_OF) && dev->of_node) {
> + for_each_child_of_node(dev->of_node, child) {
> + of_property_read_u32(child, "reg", ®);
> + if (reg & I2C_OWN_SLAVE_ADDRESS)
> + return 1;
> + }
> + } else if (IS_BUILTIN(CONFIG_ACPI) && ACPI_HANDLE(dev)) {
> + dev_dbg(dev, "ACPI slave is not supported yet\n");
> + }
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(i2c_slave_mode_detect);
> +
> #endif
>
> MODULE_AUTHOR("Simon G. Vogl <simon@tk.uni-linz.ac.at>");
> diff --git a/include/linux/i2c.h b/include/linux/i2c.h
> index b2109c522dec..53cf99569af5 100644
> --- a/include/linux/i2c.h
> +++ b/include/linux/i2c.h
> @@ -282,6 +282,7 @@ enum i2c_slave_event {
>
> extern int i2c_slave_register(struct i2c_client *client, i2c_slave_cb_t slave_cb);
> extern int i2c_slave_unregister(struct i2c_client *client);
> +extern int i2c_slave_mode_detect(struct device *dev);
>
> static inline int i2c_slave_event(struct i2c_client *client,
> enum i2c_slave_event event, u8 *val)
> --
> 2.11.0
>
>
^ permalink raw reply
* Re: [RFC 1/3] iommu/arm-smmu: Add support to opt-in to stalling
From: Rob Clark @ 2017-01-06 16:36 UTC (permalink / raw)
To: Will Deacon
Cc: Robin Murphy, Mark Rutland, Rob Herring,
devicetree@vger.kernel.org, linux-arm-msm,
iommu@lists.linux-foundation.org, Jordan Crouse
In-Reply-To: <20170105172557.GS679@arm.com>
On Thu, Jan 5, 2017 at 12:25 PM, Will Deacon <will.deacon@arm.com> wrote:
>> That's still got to be a per-master property, not a SMMU property, I
>> think. To illustrate:
>>
>> [A] [B] [C]
>> | |_____|
>> __|______________|___
>> | TBU | | TBU |
>> |_____| SMMU |_____|
>> |__|______________|__|
>> | |
>>
>> Say A and B are instances of some device happy to be stalled, and C is a
>> PCIe RC, and each is attached to their own context bank - enabling
>> stalls for A is definitely fine. However even though B and C are using
>> different context banks, enabling stalls for B might deadlock C if it
>> results in more total outstanding transactions than the TBU's slave port
>> supports. Therefore A can happily claim to be stall-safe, but B cannot
>> due to its integration with respect to C.
>
> So in this case, don't say that B and C can DMA to unpinned memory. You
> need the third property. This property (property 2) is concerned with the
> SMMU itself because, e.g. the way the walker has been integrated can
> cause a deadlock.
fwiw, I guess I'm mostly thinking about case (A).. but I guess in the
(B) case amend my suggestion about adding param to
iommu_set_fault_handler() slightly to consider the enable_stall param
passed in when both (B) and (C) register their fault handlers?
Or I guess the idea about increasing extra cell (which IIUC would let
us add an extra param in dt in the devices iommus property) could also
work. Unless maybe there could be some cases where whether a device
can do stalling is also a function of the driver as well (ie. some
feature needs to be implemented type thing)..
BR,
-R
^ permalink raw reply
* Re: [PATCH v2] ARM: omap3: beagleboard-xm: dt: Add ethernet to the device tree
From: Tony Lindgren @ 2017-01-06 16:49 UTC (permalink / raw)
To: Rob Herring
Cc: Laurent Pinchart, linux-omap,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Benoît Cousson
In-Reply-To: <CAL_JsqKQLd2SFNVKwZDPTKL-spWknEe5aFDT5RZoCnV1qOP=4Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
* Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> [170105 10:51]:
> On Thu, Jan 5, 2017 at 10:48 AM, Laurent Pinchart
> <laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org> wrote:
> > Hello,
> >
> > On Thursday 05 Jan 2017 08:39:29 Tony Lindgren wrote:
> >> * Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> [170105 08:28]:
> >> > On Fri, Dec 2, 2016 at 3:11 PM, Laurent Pinchart wrote:
> >> >> The Beagleboard-xM has a LAN9514 USB hub and ethernet controller,
> >> >> connected to port 2 of the OMAP EHCI controller. The board however has
> >> >> no EEPROM to store the ethernet MAC address, which is programmed by the
> >> >> boot loader.
> >> >>
> >> >> To allow Linux to use the same MAC address as the boot loader (or for
> >> >> that matter any fixed MAC address), we need a node in the device tree
> >> >> for the ethernet controller that the boot loader can update at runtime
> >> >> with a local-mac-address property. Add it, along with an alias for the
> >> >> ethernet controller to let the boot loader locate it easily.
> >> >>
> >> >> Signed-off-by: Laurent Pinchart <laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org>
> >> >> ---
> >> >> Changes since v1:
> >> >>
> >> >> - Renamed usb2 DT node to hub
> >> >> ---
> >> >>
> >> >> arch/arm/boot/dts/omap3-beagle-xm.dts | 16 ++++++++++++++++
> >> >> 1 file changed, 16 insertions(+)
> >> >>
> >> >> diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts
> >> >> b/arch/arm/boot/dts/omap3-beagle-xm.dts index
> >> >> 85e297ed0ea1..673cee2234b2 100644
> >> >> --- a/arch/arm/boot/dts/omap3-beagle-xm.dts
> >> >> +++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
> >> >> @@ -27,6 +27,7 @@
> >> >> aliases {
> >> >> display0 = &dvi0;
> >> >> display1 = &tv0;
> >> >> + ethernet = ðernet;
> >> >
> >> > Sorry, just noticed this, but this should be dropped. It's not used
> >> > nor do we want an alias here.
> >>
> >> OK, will update locally as I have not pushed out yet.
> >
> > The ethernet alias is used by U-Boot to locate the ethernet controller and
> > update the MAC address.
>
> Okay. Though with only only one, I don't see why that is hard to find.
> Anyway, this is the least of u-boot's DT abuses.
Applying Laurent's original patch then into omap-for-v4.11/dt.
Tony
--
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 v11 0/8] power: add power sequence library
From: Krzysztof Kozlowski @ 2017-01-06 17:08 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Peter Chen, gregkh, stern, ulf.hansson, broonie, sre, robh+dt,
shawnguo, rjw, dbaryshkov, heiko, linux-arm-kernel, p.zabel,
devicetree, pawel.moll, mark.rutland, linux-usb, arnd, s.hauer,
mail, troy.kisky, festevam, oscar, stephen.boyd, linux-pm,
stillcompiling, linux-kernel, mka, vaibhav.hiremath, gary.bisson,
hverkuil
In-Reply-To: <20170106151841.l6ehqmpben4ilkaf@kozik-lap>
On Fri, Jan 06, 2017 at 05:18:41PM +0200, Krzysztof Kozlowski wrote:
> On Thu, Jan 05, 2017 at 02:01:51PM +0800, Peter Chen wrote:
> > Hi all,
> >
> > This is a follow-up for my last power sequence framework patch set [1].
> > According to Rob Herring and Ulf Hansson's comments[2]. The kinds of
> > power sequence instances will be added at postcore_initcall, the match
> > criteria is compatible string first, if the compatible string is not
> > matched between dts and library, it will try to use generic power sequence.
> >
> > The host driver just needs to call of_pwrseq_on/of_pwrseq_off
> > if only one power sequence instance is needed, for more power sequences
> > are used, using of_pwrseq_on_list/of_pwrseq_off_list instead (eg, USB hub driver).
> >
> > In future, if there are special power sequence requirements, the special
> > power sequence library can be created.
> >
> > This patch set is tested on i.mx6 sabresx evk using a dts change, I use
> > two hot-plug devices to simulate this use case, the related binding
> > change is updated at patch [1/6], The udoo board changes were tested
> > using my last power sequence patch set.[3]
> >
> > Except for hard-wired MMC and USB devices, I find the USB ULPI PHY also
> > need to power on itself before it can be found by ULPI bus.
> >
> > [1] http://www.spinics.net/lists/linux-usb/msg142755.html
> > [2] http://www.spinics.net/lists/linux-usb/msg143106.html
> > [3] http://www.spinics.net/lists/linux-usb/msg142815.html
> >
>
> Unfortunately I was unable to utilize this library to solve Odroid U3
> usb3503/lan9730 power sequence (as a continuation of my old series [0][1]).
>
> The main problem is that power sequence instance (pwrseq_generic.c) is
> not a device. I don't get why it is not a device. It would be rather
> intuitive to me to make it a device. Also it would make life easier
> because you could use all device-like consumer APIs (of getting clocks,
> GPIOs etc). Since it is not a device, it is not possible to use
> regulator consumer API.
>
> I need a regulator because I need to toggle the power.
>
> Other encountered issue is that power sequence happens early, before the
> unused regulators are turned off by the system. However maybe this is
> the necessity from other point of view.
>
> My case is annoyingly over-complicated so I am slowly getting sertain
> that it is not generic. Anyway it looks like this:
>
> EHCI controller
> |
> |--HSIC0--lan9730 (reset is done only through regulator)
> |--HSIC1--usb3504 (it has a reset GPIO... but it is toggled by
> usb3504 driver)
>
> Overall, I want to reset the lan9730. This can be done only through
> power - buck8. buck8 state is an logical OR of register set by I2C and
> GPIO. Thus to turn it off, it is not sufficient just to set register to
> 0x0 because the GPIO is keeping it on. The best way is to switch the
> buck8 to gpio-enable-control thus only GPIO will be toggling it... still
> through the regulator consumer API (because it is an GPIO for the
> regulator, not for the reset!).
>
> However these two seems coupled. On invalid reset sequence, both chips
> die. The usb3504 has its own existing reset sequence and my findings
> show that it should happen after lan9730 reset sequence. Otherwise all
> devices might be lost...
Update - it's working! I skipped entirely the regulator API and I am
playing with its GPIO. This sounds like a hack but finally after few
days of different tries I was able to find a working, reproducible
solution. It turned out that the yours pwrseq is working quite good.
I'll send a follow-up for my board soon.
Best regards,
Krzysztof
>
> [0] http://www.spinics.net/lists/linux-mmc/msg37386.html
> [1] https://github.com/krzk/linux/commits/for-next/odroid-u3-usb3503-lan-boot-fixes-v4
>
^ permalink raw reply
* Re: [PATCH] i2c: core: helper function to detect slave mode
From: Luis Oliveira @ 2017-01-06 17:12 UTC (permalink / raw)
To: Rob Herring, Luis Oliveira
Cc: wsa-z923LK4zBo2bacvFa/9K2g@public.gmane.org, Mark Rutland,
jarkko.nikula-VuQAYsv1563Yd54FQh9/CA@public.gmane.org,
Andy Shevchenko,
mika.westerberg-VuQAYsv1563Yd54FQh9/CA@public.gmane.org,
linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, roliveir,
Joao Pinto, CARLOS.PALMINHA-HKixBCOQz3hWk0Htik3J/w
In-Reply-To: <CAL_JsqK1=R6M=vrW5aqmQtMHUGGws_Hb=VHb9RNcvesjfkCjRA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 06-Jan-17 16:35, Rob Herring wrote:
> On Thu, Jan 5, 2017 at 11:24 AM, Luis Oliveira
> <Luis.Oliveira-HKixBCOQz3hWk0Htik3J/w@public.gmane.org> wrote:
>> This function has the purpose of mode detection by checking the
>> device nodes for a reg matching with the I2C_OWN_SLAVE_ADDREESS flag.
>> Currently only checks using OF functions (ACPI slave not supported yet).
>>
>> Signed-off-by: Luis Oliveira <lolivei-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
>> ---
>> Due to the need of checking if the I2C slave address is our own (in
>> other words: if we are the I2C slave) I created a helper function
>> (proposed to me by @Andy) to enable that check.
>> Currently (because I am not able to test it using ACPI) it only
>> supports devicetree declarations.
>>
>> drivers/i2c/i2c-core.c | 19 +++++++++++++++++++
>> include/linux/i2c.h | 1 +
>> 2 files changed, 20 insertions(+)
>>
>> diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
>> index 3de95a29024c..48e705b23c59 100644
>> --- a/drivers/i2c/i2c-core.c
>> +++ b/drivers/i2c/i2c-core.c
>> @@ -3691,6 +3691,25 @@ int i2c_slave_unregister(struct i2c_client *client)
>> return ret;
>> }
>> EXPORT_SYMBOL_GPL(i2c_slave_unregister);
>> +
>> +int i2c_slave_mode_detect(struct device *dev)
>
> This can be bool instead. Otherwise, looks good to me.
>
Ok great, thank you.
>> +{
>> + struct device_node *child;
>> + u32 reg;
>> +
>> + if (IS_BUILTIN(CONFIG_OF) && dev->of_node) {
>> + for_each_child_of_node(dev->of_node, child) {
>> + of_property_read_u32(child, "reg", ®);
>> + if (reg & I2C_OWN_SLAVE_ADDRESS)
>> + return 1;
>> + }
>> + } else if (IS_BUILTIN(CONFIG_ACPI) && ACPI_HANDLE(dev)) {
>> + dev_dbg(dev, "ACPI slave is not supported yet\n");
>> + }
>> + return 0;
>> +}
>> +EXPORT_SYMBOL_GPL(i2c_slave_mode_detect);
>> +
>> #endif
>>
>> MODULE_AUTHOR("Simon G. Vogl <simon-nD9nYVNVf00W+b/DJNNodF6hYfS7NtTn@public.gmane.org>");
>> diff --git a/include/linux/i2c.h b/include/linux/i2c.h
>> index b2109c522dec..53cf99569af5 100644
>> --- a/include/linux/i2c.h
>> +++ b/include/linux/i2c.h
>> @@ -282,6 +282,7 @@ enum i2c_slave_event {
>>
>> extern int i2c_slave_register(struct i2c_client *client, i2c_slave_cb_t slave_cb);
>> extern int i2c_slave_unregister(struct i2c_client *client);
>> +extern int i2c_slave_mode_detect(struct device *dev);
>>
>> static inline int i2c_slave_event(struct i2c_client *client,
>> enum i2c_slave_event event, u8 *val)
>> --
>> 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] i2c: core: helper function to detect slave mode
From: Luis Oliveira @ 2017-01-06 17:15 UTC (permalink / raw)
To: Andy Shevchenko, Luis Oliveira
Cc: Wolfram Sang, Rob Herring, Mark Rutland, Jarkko Nikula,
Andy Shevchenko, Mika Westerberg, linux-i2c, devicetree,
linux-kernel@vger.kernel.org, Ramiro.Oliveira, Joao Pinto,
CARLOS.PALMINHA
In-Reply-To: <CAHp75VdB+pApFgjFOwWYYQFUmxv5k6OYKgB4fstuy=3=2QesBQ@mail.gmail.com>
On 06-Jan-17 16:29, Andy Shevchenko wrote:
> On Thu, Jan 5, 2017 at 7:24 PM, Luis Oliveira
> <Luis.Oliveira@synopsys.com> wrote:
>> This function has the purpose of mode detection by checking the
>> device nodes for a reg matching with the I2C_OWN_SLAVE_ADDREESS flag.
>> Currently only checks using OF functions (ACPI slave not supported yet).
>
> The code looks good, one important comment below, after addressing it:
>
> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
>
> P.S. Btw, we have Suggested-by tag for giving credit for suggestion.
> Please use it.
>
I will do it in the V2, thank you.
>> --- a/drivers/i2c/i2c-core.c
>> +++ b/drivers/i2c/i2c-core.c
>> @@ -3691,6 +3691,25 @@ int i2c_slave_unregister(struct i2c_client *client)
>
> Please, add kernel doc description here, important thing is to explain
> return codes in Return: section of it.
>
>> +int i2c_slave_mode_detect(struct device *dev)
>> +{
>
>> + struct device_node *child;
>> + u32 reg;
>
> I would consider them as private to the OF branch. But it's really
> minor and up to you (I don't remember if we have such style examples
> in i2c core code).
I can change that in the V2 too.
>
>> +
>> + if (IS_BUILTIN(CONFIG_OF) && dev->of_node) {
>> + for_each_child_of_node(dev->of_node, child) {
>> + of_property_read_u32(child, "reg", ®);
>> + if (reg & I2C_OWN_SLAVE_ADDRESS)
>> + return 1;
>> + }
>> + } else if (IS_BUILTIN(CONFIG_ACPI) && ACPI_HANDLE(dev)) {
>> + dev_dbg(dev, "ACPI slave is not supported yet\n");
>> + }
>> + return 0;
>> +}
>> +EXPORT_SYMBOL_GPL(i2c_slave_mode_detect);
>
^ permalink raw reply
* Re: [PATCH] i2c: core: helper function to detect slave mode
From: Andy Shevchenko @ 2017-01-06 17:17 UTC (permalink / raw)
To: Luis Oliveira
Cc: Wolfram Sang, Rob Herring, Mark Rutland, Jarkko Nikula,
Andy Shevchenko, Mika Westerberg,
linux-i2c-u79uwXL29TY76Z2rM5mHXA, devicetree,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Ramiro.Oliveira-HKixBCOQz3hWk0Htik3J/w, Joao Pinto,
CARLOS.PALMINHA-HKixBCOQz3hWk0Htik3J/w
In-Reply-To: <475d9c2a-da11-97d0-d0b6-37ccd4990f18-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
On Fri, Jan 6, 2017 at 7:15 PM, Luis Oliveira
<Luis.Oliveira-HKixBCOQz3hWk0Htik3J/w@public.gmane.org> wrote:
> On 06-Jan-17 16:29, Andy Shevchenko wrote:
>> On Thu, Jan 5, 2017 at 7:24 PM, Luis Oliveira
>> Please, add kernel doc description here, important thing is to explain
>> return codes in Return: section of it.
>>
>>> +int i2c_slave_mode_detect(struct device *dev)
Just to make sure you didn't miss this one.
--
With Best Regards,
Andy Shevchenko
--
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 3/3] Input: pwm-beeper: add optional enable gpio
From: Andy Shevchenko @ 2017-01-06 17:28 UTC (permalink / raw)
To: David Lechner
Cc: Dmitry Torokhov, Rob Herring, Mark Rutland, linux-input,
devicetree, linux-kernel@vger.kernel.org
In-Reply-To: <1483670635-25060-4-git-send-email-david@lechnology.com>
On Fri, Jan 6, 2017 at 4:43 AM, David Lechner <david@lechnology.com> wrote:
> This adds an optional enable gpio to the pwm-beeper device. This gpio is
> used in cases where the beeper needs to be switched on before using it.
Isn't it a property of pin muxing?
> For
> example, there may be an amplifier that is not always powered on.
This looks like GPIO based fixed voltage regulator.
>
> Tested on LEGO MINDSTORMS EV3, which has a speaker connected to PWM through
> an amplifier. The amplifier has an enable pin that is connected to a gpio.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v2 3/3] power: bq27xxx: add support for NVRAM R/W access
From: Sebastian Reichel @ 2017-01-06 17:28 UTC (permalink / raw)
To: Matt Ranostay; +Cc: Tony Lindgren, devicetree, linux-pm
In-Reply-To: <CAJ_EiSQjRn=rot7Zu+oB80DruN0qexd+3_PxjXS6_JaF7CY1Bw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3093 bytes --]
Hi,
On Thu, Jan 05, 2017 at 07:23:48PM -0800, Matt Ranostay wrote:
> On Thu, Jan 5, 2017 at 6:34 PM, Matt Ranostay <matt@ranostay.consulting> wrote:
> > On Thu, Jan 5, 2017 at 5:53 PM, Sebastian Reichel <sre@kernel.org> wrote:
> >> On Wed, Jan 04, 2017 at 06:10:07PM -0800, Matt Ranostay wrote:
> >>> Initial support for access and modification of the non-volatile regions
> >>> of the bq27425 fuel gauge DesignEnergy, DesignCapacity, and
> >>> TerminateVoltage settings.
> >>>
> >>> This is intended for fine tuning the fuel gauge state machine for the
> >>> respective battery specifications.
> >>>
> >>> Cc: Sebastian Reichel <sre@kernel.org>
> >>> Signed-off-by: Matt Ranostay <matt@ranostay.consulting>
> >>> ---
> >>> drivers/power/supply/bq27xxx_battery_i2c.c | 335 +++++++++++++++++++++++++++++
> >>> include/linux/power/bq27xxx_battery.h | 4 +
> >>> 2 files changed, 339 insertions(+)
> >>
> >> I only skipped over this one, as the changed DT binding requires
> >> quite some changes in this patch anyways. Here are a couple of
> >> comments how I would like to see this implemented:
> >>
> >> Add a patch for the power-supply core, which implements a
> >> structure for the battery info. Something like this:
> >>
> >> struct power_supply_battery_info {
> >> uint32 energy; /* µWh */
> >> uint32 power; /* µAh */
> >> uint32 nominal_voltage; /* µV */
> >> /* ... */
> >> };
> >>
> >> And a function in the core framework, which gets the information
> >> from DT. The function itself should *not* be DT specific, so that
> >> ACPI/platformdata/whatever support can be added later without
> >> modifying every single driver.
> >>
> >> static struct power_supply_battery_info*
> >> power_supply_get_battery_info(struct power_supply *psy) {
> >> if (psy->dt) {
> >> /* get battery phandle or return -ENXIO */
> >> /* fill and return struct */
> >> }
> >>
> >> return -ENOTSUP;
> >> }
> >>
> >> Then call power_supply_get_battery_info() during bq27xxx probe and
> >> use the struct to initialize the registers. Also I expect that
> >> functionality in bq27xxx_battery.c instead of bq27xxx_battery_i2c.c,
> >> since it's not I²C specific.
> >
> > They may not be i2c specific but they are only used by the i2c path of
> > the code currently. Do you think that platform data would ever have a
> > struct to pass with the respective data?
I think it is possible, that there will be some non-i2c bq27xxx
device in the future, that needs this feature.
> > Also it would have to be in bq27xxx_battery_setup() and not
> > bq27xxx_battery_platform_probe() since the former is only thing called
> > by both code paths.
bq27xxx_battery_setup is fine.
> Also there is no bq27xxx_battery_platform_write to even write the
> configuration data.
Just check if the callback exists.
The plan is to convert the 1wire bq27xxx to regmap at some point, so
that the bus-specific bq27xxx files can be dropped by just using
regmap in the core bq27xxx driver.
-- Sebastian
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH 1/6] ARM: dts: am335x-phycore-som: Update NAND partition table
From: Ladislav Michl @ 2017-01-06 17:39 UTC (permalink / raw)
To: Brian Norris
Cc: Tony Lindgren, Teresa Remmet, linux-omap-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Benoît Cousson, Rob Herring, Mark Rutland, Adam Ford,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Brian Norris
In-Reply-To: <20170105175619.GA56877-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
On Thu, Jan 05, 2017 at 09:56:20AM -0800, Brian Norris wrote:
[snip]
> The best solution would be to try to migrate away from static device
> tree representations of partition info entirely. UBI volumes are best
> where possible. If not, then some other kind of on-flash data structures
> (along the lines of a GPT) with a corresponding MTD partition parser is
> an OK alternative. Unfortunately, there isn't any good standard format
> for this on MTD, so it's typically all custom -- and so people use the
> easiest approach: device tree. And it's even more difficult with NAND,
> which has reliability problems, especially with static data (e.g., read
> disturb).
Just as a side note, there is some work in this area:
https://www.mail-archive.com/u-boot-0aAXYlwwYIKGBzrmiIFOJg@public.gmane.org/msg232759.html
> Anyway, the parser solution is helpful only if one can properly fix the
> "flag day" first. And it requires a little bit more work to be generally
> useful; I posted some work for this over a year ago, but bikeshedding
> brought it down.
Best regards,
ladis
--
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 3/3] Input: pwm-beeper: add optional enable gpio
From: David Lechner @ 2017-01-06 17:45 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Dmitry Torokhov, Rob Herring, Mark Rutland, linux-input,
devicetree, linux-kernel@vger.kernel.org
In-Reply-To: <CAHp75VfY4CXOmvT5y2NucKLDvdt4i2LhW5rthke1pdvuAVm7gA@mail.gmail.com>
On 01/06/2017 11:28 AM, Andy Shevchenko wrote:
> On Fri, Jan 6, 2017 at 4:43 AM, David Lechner <david@lechnology.com> wrote:
>> This adds an optional enable gpio to the pwm-beeper device. This gpio is
>> used in cases where the beeper needs to be switched on before using it.
>
> Isn't it a property of pin muxing?
You may want to turn if off when not making a sound to save power.
>
>> For
>> example, there may be an amplifier that is not always powered on.
>
> This looks like GPIO based fixed voltage regulator.
Yes, I think a regulator could work here just as well.
>
>>
>> Tested on LEGO MINDSTORMS EV3, which has a speaker connected to PWM through
>> an amplifier. The amplifier has an enable pin that is connected to a gpio.
>
^ permalink raw reply
* Re: [PATCH] i2c: core: helper function to detect slave mode
From: Luis Oliveira @ 2017-01-06 17:46 UTC (permalink / raw)
To: Andy Shevchenko, Luis Oliveira
Cc: Wolfram Sang, Rob Herring, Mark Rutland, Jarkko Nikula,
Andy Shevchenko, Mika Westerberg, linux-i2c, devicetree,
linux-kernel@vger.kernel.org, Ramiro.Oliveira, Joao Pinto,
CARLOS.PALMINHA
In-Reply-To: <CAHp75Vdv3daVnkFmGc7gXWoqcy+CNgyqdtRXkvTJQpjyJX3eDg@mail.gmail.com>
On 06-Jan-17 17:17, Andy Shevchenko wrote:
> On Fri, Jan 6, 2017 at 7:15 PM, Luis Oliveira
> <Luis.Oliveira@synopsys.com> wrote:
>> On 06-Jan-17 16:29, Andy Shevchenko wrote:
>>> On Thu, Jan 5, 2017 at 7:24 PM, Luis Oliveira
>
>>> Please, add kernel doc description here, important thing is to explain
>>> return codes in Return: section of it.
>>>
>>>> +int i2c_slave_mode_detect(struct device *dev)
>
> Just to make sure you didn't miss this one.
>
>
Yes, I saw it. You were talking of something like this, right?
/**
* i2c_slave_mode_detect - detect operation mode
* @dev: The device owning the bus
*
* This checks the device nodes for a I2C slave by checking the address
* used.
*
* Returns true if a I2C slave is detected, otherwise returns false.
*/
^ permalink raw reply
* Re: [PATCH 1/7] ARM: dts: NSP: DT Clean-ups
From: Florian Fainelli @ 2017-01-06 17:47 UTC (permalink / raw)
To: bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w, Jon Mason,
Rob Herring
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1481652831-2744-2-git-send-email-jon.mason-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
On Tue, 13 Dec 2016 13:13:45 -0500, Jon Mason <jon.mason-dY08KVG/lbpWk0Htik3J/w@public.gmane.org> wrote:
> The QSPI entry was added out of the sequental order that the rest of the
> DTSI file is in. Move it to make it fit in properly. Also, some other
> entries have been added in a non-alphabetical order in the DTS files,
> making them different from the other NSP DTS files. Move the relevant
> peices to make it match. Finally, remove errant new lines.
>
> Signed-off-by: Jon Mason <jon.mason-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
> ---
Applied, thanks!
--
Florian
--
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/7] ARM: dts: NSP: Correct NAND partition unit address
From: Florian Fainelli @ 2017-01-06 17:47 UTC (permalink / raw)
To: bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w, Jon Mason,
Rob Herring
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1481652831-2744-3-git-send-email-jon.mason-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
On Tue, 13 Dec 2016 13:13:46 -0500, Jon Mason <jon.mason-dY08KVG/lbpWk0Htik3J/w@public.gmane.org> wrote:
> The NAND partition unit address does not match the other NSP device tree
> files. This change makes them uniform.
>
> Signed-off-by: Jon Mason <jon.mason-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
> ---
Applied, thanks!
--
Florian
--
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 3/7] ARM: dts: NSP: Add QSPI support to missing boards
From: Florian Fainelli @ 2017-01-06 17:48 UTC (permalink / raw)
To: bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w, Jon Mason,
Rob Herring
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1481652831-2744-4-git-send-email-jon.mason-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
On Tue, 13 Dec 2016 13:13:47 -0500, Jon Mason <jon.mason-dY08KVG/lbpWk0Htik3J/w@public.gmane.org> wrote:
> QSPI device tree entries are present in bcm958625k, but missing from
> bcm958522er, bcm958525er, bcm958525xmc, bcm958622hr, bcm958623hr,
> bcm958625hr, and bcm988312hr. Duplicate the entry in bcm958625k for
> all of those that are missing it (as they are identical).
>
> Signed-off-by: Jon Mason <jon.mason-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
> ---
Applied, thanks!
--
Florian
--
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 4/7] ARM: dts: NSP: Add BCM958625K switch ports
From: Florian Fainelli @ 2017-01-06 17:48 UTC (permalink / raw)
To: bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w, Jon Mason,
Rob Herring
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1481652831-2744-5-git-send-email-jon.mason-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
On Tue, 13 Dec 2016 13:13:48 -0500, Jon Mason <jon.mason-dY08KVG/lbpWk0Htik3J/w@public.gmane.org> wrote:
> Add the layout of the switch ports found on the BCM958625K reference
> board. The CPU port is hooked up to the AMAC0 Ethernet controller
> adapter.
>
> Signed-off-by: Jon Mason <jon.mason-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
> ---
Applied, thanks!
--
Florian
--
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 5/7] ARM: dts: NSP: Add and enable amac2
From: Florian Fainelli @ 2017-01-06 17:48 UTC (permalink / raw)
To: bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w, Jon Mason,
Rob Herring
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1481652831-2744-6-git-send-email-jon.mason-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
On Tue, 13 Dec 2016 13:13:49 -0500, Jon Mason <jon.mason-dY08KVG/lbpWk0Htik3J/w@public.gmane.org> wrote:
> Add and enable the third AMAC ethernet interface in the device trees for
> the platforms where it is present. Also, enable amac1 on some of the
> platforms where that was missing.
>
> Signed-off-by: Jon Mason <jon.mason-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
> ---
Applied, thanks!
--
Florian
--
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 6/7] ARM: dts: NSP: Add Ethernet to NSP XMC
From: Florian Fainelli @ 2017-01-06 17:48 UTC (permalink / raw)
To: bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w, Jon Mason,
Rob Herring
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1481652831-2744-7-git-send-email-jon.mason-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
On Tue, 13 Dec 2016 13:13:50 -0500, Jon Mason <jon.mason-dY08KVG/lbpWk0Htik3J/w@public.gmane.org> wrote:
> Enable the ethernet in the NSP XMC (bcm958525xmc) device tree
>
> Signed-off-by: Jon Mason <jon.mason-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
> ---
Applied, thanks!
--
Florian
--
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 7/7] ARM: dts: NSP: Add SD/MMC support
From: Florian Fainelli @ 2017-01-06 17:48 UTC (permalink / raw)
To: bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w, Jon Mason,
Rob Herring
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1481652831-2744-8-git-send-email-jon.mason-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
On Tue, 13 Dec 2016 13:13:51 -0500, Jon Mason <jon.mason-dY08KVG/lbpWk0Htik3J/w@public.gmane.org> wrote:
> Add SD/MMC support to the Broadcom NSP SVK and XMC.
>
> Signed-off-by: Jon Mason <jon.mason-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
> ---
Applied, thanks!
--
Florian
--
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