* Re: regression(ti platforms): next-20140210 (ehci?)
From: Roger Quadros @ 2014-02-10 18:16 UTC (permalink / raw)
To: Nishanth Menon, linux-omap, linux-usb, Balbi, Felipe
Cc: linux-next, devicetree@vger.kernel.org, tony@atomide.com
In-Reply-To: <52F91451.8050802@ti.com>
On 02/10/2014 08:02 PM, Nishanth Menon wrote:
> On 02/10/2014 11:50 AM, Roger Quadros wrote:
>> +devicetree
>>
> [...]
>> In the DT node we have compatible ids for both. e.g. for omap4.dtsi
>>
>> usbhsehci: ehci@4a064c00 {
>> compatible = "ti,ehci-omap", "usb-ehci";
>> reg = <0x4a064c00 0x400>;
>> interrupt-parent = <&gic>;
>> interrupts = <GIC_SPI 77 IRQ_TYPE_LEVEL_HIGH>;
>> };
>>
>> Shouldn't ehci-omap driver be getting a higher priority than usb-ehci?
>>
>> A quick fix would be to eliminate "usb-ehci" from the DT node of all failing platforms.
>
> If the driver is not compatible with "usb-ehci", not sure why do we
> even state that in dts node?
>
>
I'm not sure either. Let's get rid of it.
Patch to fix the reported issue.
http://article.gmane.org/gmane.linux.drivers.devicetree/61204
cheers,
-roger
^ permalink raw reply
* [PATCH 8/8] serial: max310x: Add bindings documentation for the MAX310X UARTs
From: Alexander Shiyan @ 2014-02-10 18:17 UTC (permalink / raw)
To: linux-serial-u79uwXL29TY76Z2rM5mHXA
Cc: Greg Kroah-Hartman, Jiri Slaby, devicetree-u79uwXL29TY76Z2rM5mHXA,
Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala,
Grant Likely, Alexander Shiyan
This patch adds the devicetree documentation for the Maxim MAX310X UARTs.
Signed-off-by: Alexander Shiyan <shc_work-JGs/UdohzUI@public.gmane.org>
---
.../devicetree/bindings/serial/maxim,max310x.txt | 36 ++++++++++++++++++++++
1 file changed, 36 insertions(+)
create mode 100644 Documentation/devicetree/bindings/serial/maxim,max310x.txt
diff --git a/Documentation/devicetree/bindings/serial/maxim,max310x.txt b/Documentation/devicetree/bindings/serial/maxim,max310x.txt
new file mode 100644
index 0000000..0daf780
--- /dev/null
+++ b/Documentation/devicetree/bindings/serial/maxim,max310x.txt
@@ -0,0 +1,36 @@
+* Maxim MAX310X advanced Universal Asynchronous Receiver-Transmitter (UART)
+
+Required properties:
+- compatible: Should be one of the following:
+ - "maxim,max3107" for Maxim MAX3107,
+ - "maxim,max3108" for Maxim MAX3108,
+ - "maxim,max3109" for Maxim MAX3109,
+ - "maxim,max14830" for Maxim MAX14830.
+- reg: SPI chip select number.
+- interrupt-parent: The phandle for the interrupt controller that
+ services interrupts for this IC.
+- interrupts: Specifies the interrupt source of the parent interrupt
+ controller. The format of the interrupt specifier depends on the
+ parent interrupt controller.
+- clocks: phandle to the IC source clock.
+- clock-names: Should be "osc" if clock is an external crystal or
+ "xtal" if an external clock source is used.
+
+Optional properties:
+- gpio-controller: Marks the device node as a GPIO controller.
+- #gpio-cells: Should be two. The first cell is the GPIO number and
+ the second cell is used to specify the GPIO polarity:
+ 0 = active high,
+ 1 = active low.
+
+Example:
+ max14830: max14830@0 {
+ compatible = "maxim,max14830";
+ reg = <0>;
+ clocks = <&clk20m>;
+ clock-names = "osc";
+ interrupt-parent = <&gpio3>;
+ interrupts = <7 IRQ_TYPE_EDGE_FALLING>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH 01/17] Documentation: i2c: describe devicetree method for instantiating devices
From: linux @ 2014-02-10 18:21 UTC (permalink / raw)
To: Wolfram Sang
Cc: linux-i2c, devicetree, linux-arm-kernel, Rob Landley, linux-doc,
linux-kernel
In-Reply-To: <1392026654-5343-2-git-send-email-wsa@the-dreams.de>
Quoting Wolfram Sang <wsa@the-dreams.de>:
> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
> Cc: devicetree@vger.kernel.org
> Cc: linux-arm-kernel@lists.infradead.org
> ---
>
> Documentation/i2c/instantiating-devices | 34
> +++++++++++++++++++++++++++++++--
> 1 file changed, 32 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/i2c/instantiating-devices
> b/Documentation/i2c/instantiating-devices
> index c70e7a7..6df095a 100644
> --- a/Documentation/i2c/instantiating-devices
> +++ b/Documentation/i2c/instantiating-devices
> @@ -8,8 +8,8 @@ reason, the kernel code must instantiate I2C devices
> explicitly. There are
> several ways to achieve this, depending on the context and requirements.
>
>
> -Method 1: Declare the I2C devices by bus number
> ------------------------------------------------
> +Method 1a: Declare the I2C devices by bus number
> +------------------------------------------------
>
> This method is appropriate when the I2C bus is a system bus as is the case
> for many embedded systems. On such systems, each I2C bus has a number
> @@ -51,6 +51,36 @@ The devices will be automatically unbound and
> destroyed when the I2C bus
> they sit on goes away (if ever.)
>
>
> +Method 1b: Declare the I2C devices via devicetree
> +-------------------------------------------------
> +
Hi Wolfram,
There is now also a means to instantiate I2C devices through
ACPI. This is documented in Documentation/acpi/enumeration.txt.
Might be worthwhile to reference it from instantiating-devices.
I guess that would be a separate patch though.
Thanks,
Guenter
^ permalink raw reply
* Re: [RFC 3/6] mailbox: pl320: migrate to mbox framework
From: Rob Herring @ 2014-02-10 18:28 UTC (permalink / raw)
To: Courtney Cavin
Cc: s-anna, Wysocki, Rafael J, Tony Lindgren, omar.ramirez,
Greg Kroah-Hartman, Pawel Moll, Mark Rutland, Ian Campbell,
Kumar Gala, Rob Landley, linux-doc@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
Mark Langsdorf
In-Reply-To: <1391820619-25487-4-git-send-email-courtney.cavin@sonymobile.com>
On Fri, Feb 7, 2014 at 6:50 PM, Courtney Cavin
<courtney.cavin@sonymobile.com> wrote:
> We don't remove the legacy methods here, but we mark them as deprecated
> in the hopes that people with the ability to properly test modifications
> can adapt its users.
The DT for highbank is pretty much fixed at this point. So adopting
this will need a way to register without DT. Unfortunately, I don't
have access to h/w either ATM.
I should note that this driver is very much highbank specific and not
really a generic pl320 driver. The pl320 has up to 8 mailboxes and 8
interrupts. How it is used from there is a software decision. I've
never seen any other user, but it could be done quite differently from
how it is used in highbank. In the case of highbank, we assigned a tx
and rx mailbox. While both the management core and linux side have all
8 interrupts wired up, we have assigned an interrupt to each side. I
suppose you could have the interrupt tied to each mailbox, but really
they are unrelated in the pl320 as each mailbox message could have
multiple targets (interrupts). Probably splitting this between a pl320
lib and platform specific drivers would be the right split if there
are ever other users.
> - ipc_irq = adev->irq[0];
> - ret = request_irq(ipc_irq, ipc_handler, 0, dev_name(&adev->dev), NULL);
> + pl->adapter.dev = &adev->dev;
> + pl->adapter.ops = &pl320_mbox_ops;
> + pl->adapter.nchannels = 1;
Shouldn't this be 2? The 2 channels here are not a single
bi-directional channel in any way. They are completely independent and
have unrelated events. For example we originally defined having 3
mailboxes where we had 2 tx mailboxes for fast and slow messages, but
we ultimately decided everything could be a single tx mailbox. Event
completion is handled synchronously via the pl320's handshake
mechanism. I'd imagine you could have a protocol where you have async
completions via an rx mailbox instead.
Rob
^ permalink raw reply
* Re: regression(ti platforms): next-20140210 (ehci?)
From: Kevin Hilman @ 2014-02-10 18:28 UTC (permalink / raw)
To: Roger Quadros
Cc: Nishanth Menon, linux-omap, linux-usb, Balbi, Felipe, linux-next,
devicetree@vger.kernel.org, tony@atomide.com
In-Reply-To: <52F9117C.8000405@ti.com>
Roger Quadros <rogerq@ti.com> writes:
> +devicetree
>
> On 02/10/2014 05:59 PM, Nishanth Menon wrote:
>> Hi,
>>
>> A quick note to report that I saw regression in today's next tag (logs
>> indicate around EHCI) boot on various TI platforms:
>>
>> Note: crane and sdp2430 are not expected to pass with
>> multi_v7_defconfig (note: omap2plus_defconfig boot seems to be sane
>> but USB is disabled there)
>>
>> next-20140210-multi_v7_defconfig
>> 1: am335x-evm: Boot PASS: http://slexy.org/raw/s2zYHdPb94
>> 2: am335x-sk: Boot PASS: http://slexy.org/raw/s2UChLyzSE
>> 3: am3517-evm: Boot FAIL: http://slexy.org/raw/s20Br9XLO1
>> around ehci
>>
>> 4: am37x-evm: Boot FAIL: http://slexy.org/raw/s20mVz9Wc7
>> around ehci
>>
>> 5: am43xx-epos: Boot PASS: http://slexy.org/raw/s2byveBYtT
>> 6: BeagleBoard-XM: Boot FAIL: http://slexy.org/raw/s21sOgJNwK
>> around ehci
>>
>> 7: BeagleBone-Black: Boot PASS: http://slexy.org/raw/s2ovVNAmO7
>> 8: crane: No Image built - Missing platform support?:
>> 9: dra7: Boot PASS: http://slexy.org/raw/s217qwaXsM
>> 10: ldp: Boot FAIL: http://slexy.org/raw/s203IvjE23
>> around ehci
>>
>> 11: PandaBoard-ES: Boot FAIL: http://slexy.org/raw/s2NvkRx2YJ
>> around ehci
>
> I think the problem is that ehci-platform driver gets loaded instead of ehci-omap.
>
> In the DT node we have compatible ids for both. e.g. for omap4.dtsi
>
> usbhsehci: ehci@4a064c00 {
> compatible = "ti,ehci-omap", "usb-ehci";
> reg = <0x4a064c00 0x400>;
> interrupt-parent = <&gic>;
> interrupts = <GIC_SPI 77 IRQ_TYPE_LEVEL_HIGH>;
> };
>
> Shouldn't ehci-omap driver be getting a higher priority than usb-ehci?
>
> A quick fix would be to eliminate "usb-ehci" from the DT node of all failing platforms.
I can confirm that simply remvoing usb-ehci from omap[34].dtsi nodes
fixed the problem for me on 3530/overo, 3730/beagle-xM and
4460/panda-es. But I don't think that's the right fix. First we have
to figure out why ehci-omap stopped getting loaded first.
Kevin
^ permalink raw reply
* Re: [PATCH] dp83640: Get gpio and master/slave configuration from DT
From: Richard Cochran @ 2014-02-10 18:46 UTC (permalink / raw)
To: Stefan Sørensen
Cc: grant.likely-QSEj5FYQhm4dnm+yROfE0A,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1392037240-30913-1-git-send-email-stefan.sorensen-usnHOLptxrsHrNJx0XZkJA@public.gmane.org>
On Mon, Feb 10, 2014 at 02:00:40PM +0100, Stefan Sørensen wrote:
> This patch removes the module parameters gpio_tab and chosen_phy in favour of
> retrieving the configuration from DT through the properties
Can we please keep the module parameters? I have two platforms with
phyters neither of which will ever support DT, namely ixp and m68k,
and I want to run recent kernels on them.
Are module parameters even considered user ABI?
Even if not, still I want to retain the module params until there is
an alternative for non-DT platforms.
> dp83640,slave
> dp83640,calibrate-gpio
> dp83640,perout-gpios
> dp83640,extts-gpios
> The configuration is now stored for each master clock device, allowing different
> gpio setups for each master.
What do you mean by "each master"? Do you mean each individual PHY device
or each group of PHYs on the same MDIO bus?
Thanks,
Richard
--
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] ARM: dts: MSM8974: Add pinctrl node
From: Bjorn Andersson @ 2014-02-10 18:55 UTC (permalink / raw)
To: Ivan T. Ivanov
Cc: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala,
Russell King, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-arm-msm
In-Reply-To: <1391700529-11816-2-git-send-email-iivanov@mm-sol.com>
On Thu, Feb 6, 2014 at 7:28 AM, Ivan T. Ivanov <iivanov@mm-sol.com> wrote:
> From: "Ivan T. Ivanov" <iivanov@mm-sol.com>
>
> Add the pin control node and pin definitions of SPI8.
>
> Signed-off-by: Ivan T. Ivanov <iivanov@mm-sol.com>
> ---
> arch/arm/boot/dts/qcom-msm8974.dtsi | 29 +++++++++++++++++++++++++++++
> 1 file changed, 29 insertions(+)
>
> diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi b/arch/arm/boot/dts/qcom-msm8974.dtsi
> index 9e5dadb..395603f 100644
> --- a/arch/arm/boot/dts/qcom-msm8974.dtsi
> +++ b/arch/arm/boot/dts/qcom-msm8974.dtsi
> @@ -117,5 +117,34 @@
> clocks = <&gcc GCC_BLSP1_UART2_APPS_CLK>, <&gcc GCC_BLSP1_AHB_CLK>;
> clock-names = "core", "iface";
> };
> +
> + msmgpio: pinctrl@fd510000 {
> + compatible = "qcom,msm8974-pinctrl";
> + reg = <0xfd510000 0x4000>;
> + gpio-controller;
> + #gpio-cells = <2>;
> + interrupt-controller;
> + #interrupt-cells = <2>;
> + interrupts = <0 208 0>;
> +
> + spi8_default: spi8_default {
> + mosi {
> + pins = "gpio45";
> + function = "blsp_spi8";
> + };
> + miso {
> + pins = "gpio46";
> + function = "blsp_spi8";
> + };
> + cs {
> + pins = "gpio47";
> + function = "blsp_spi8";
> + };
> + clk {
> + pins = "gpio48";
> + function = "blsp_spi8";
> + };
> + };
> + };
> };
> };
Nice, listing it like this makes it easy to add the electrical
properties when inheriting these nodes, closer to the product dts
files.
Reviewed-by: Bjorn Andersson <bjorn.andersson@sonymobile.com>
^ permalink raw reply
* Re: [RFC 1/6] mailbox: add core framework
From: Josh Cartwright @ 2014-02-10 19:09 UTC (permalink / raw)
To: Rob Herring
Cc: Arnd Bergmann, Courtney Cavin, s-anna, Rob Herring,
Wysocki, Rafael J, Mark Langsdorf, Tony Lindgren, omar.ramirez,
Greg Kroah-Hartman, Pawel Moll, Mark Rutland, Ian Campbell,
Kumar Gala, Rob Landley, linux-doc@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <CAL_JsqKa6nyPOa0M67svUR20Y3JNZcFhsTZE=ooV-eg6_ZBaMw@mail.gmail.com>
On Mon, Feb 10, 2014 at 11:52:05AM -0600, Rob Herring wrote:
> On Mon, Feb 10, 2014 at 8:11 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Friday 07 February 2014 16:50:14 Courtney Cavin wrote:
[..]
> >> +int mbox_channel_notify(struct mbox_channel *chan,
> >> + const void *data, unsigned int len)
> >> +{
> >> + return atomic_notifier_call_chain(&chan->notifier, len, (void *)data);
> >> +}
> >> +EXPORT_SYMBOL(mbox_channel_notify);
> >
> > What is the reason to use a notifier chain here? Isn't a simple
> > callback function pointer enough? I would expect that each mailbox
> > can have exactly one consumer, not multiple ones.
>
> It probably can be a callback, but there can be multiple consumers. It
> was only a notifier on the pl320 as there was no framework at the time
> and to avoid creating custom interfaces between drivers. On highbank
> for example, we can asynchronously receive the events for temperature
> change, power off, and reset. So either there needs to be an event
> demux somewhere or callbacks have to return whether they handled an
> event or not.
I'm not familiar with highbank IPC, but with these requirements should
the mailbox core even bother with asynchronous notifier chain? It
sounds like a better fit might be for the mailbox core to implement a
proper adapter-specific irqdomain and used a chained irq handler to
demux (or have consumers request with IRQF_SHARED in the shared case).
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply
* Re: [RFC 3/6] mailbox: pl320: migrate to mbox framework
From: Courtney Cavin @ 2014-02-10 19:12 UTC (permalink / raw)
To: Rob Herring
Cc: s-anna@ti.com, Wysocki, Rafael J, Tony Lindgren,
omar.ramirez@copitl.com, Greg Kroah-Hartman, Pawel Moll,
Mark Rutland, Ian Campbell, Kumar Gala, Rob Landley,
linux-doc@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, Mark Langsdorf
In-Reply-To: <CAL_JsqL7Ba2KJCP7YoUU-Z-rdq6zzWiRM3E3gbs7wgDZxVCtww@mail.gmail.com>
On Mon, Feb 10, 2014 at 07:28:54PM +0100, Rob Herring wrote:
> On Fri, Feb 7, 2014 at 6:50 PM, Courtney Cavin
> <courtney.cavin@sonymobile.com> wrote:
> > We don't remove the legacy methods here, but we mark them as deprecated
> > in the hopes that people with the ability to properly test modifications
> > can adapt its users.
>
> The DT for highbank is pretty much fixed at this point. So adopting
> this will need a way to register without DT. Unfortunately, I don't
> have access to h/w either ATM.
That's fine. The lookup table stuff (see mbox_channel_lookup() and
mbox_add_table()) should solve this.
Hopefully we'll find someone with a test-setup for this.
> I should note that this driver is very much highbank specific and not
> really a generic pl320 driver. The pl320 has up to 8 mailboxes and 8
> interrupts. How it is used from there is a software decision. I've
> never seen any other user, but it could be done quite differently from
> how it is used in highbank. In the case of highbank, we assigned a tx
> and rx mailbox. While both the management core and linux side have all
> 8 interrupts wired up, we have assigned an interrupt to each side. I
> suppose you could have the interrupt tied to each mailbox, but really
> they are unrelated in the pl320 as each mailbox message could have
> multiple targets (interrupts). Probably splitting this between a pl320
> lib and platform specific drivers would be the right split if there
> are ever other users.
I'm not exactly sure I follow, and I probably should lookup the pl320
spec, but from the way you describe it and the simplicity of the
existing implementation, it seems to me that one could easily implement
this using DT to decribe how the hardware is hooked up.
> > - ipc_irq = adev->irq[0];
> > - ret = request_irq(ipc_irq, ipc_handler, 0, dev_name(&adev->dev), NULL);
> > + pl->adapter.dev = &adev->dev;
> > + pl->adapter.ops = &pl320_mbox_ops;
> > + pl->adapter.nchannels = 1;
>
> Shouldn't this be 2? The 2 channels here are not a single
> bi-directional channel in any way. They are completely independent and
> have unrelated events. For example we originally defined having 3
> mailboxes where we had 2 tx mailboxes for fast and slow messages, but
> we ultimately decided everything could be a single tx mailbox. Event
> completion is handled synchronously via the pl320's handshake
> mechanism. I'd imagine you could have a protocol where you have async
> completions via an rx mailbox instead.
I generally see a mailbox as having both rx & tx, and I thought that
this was what this driver was attempting to model, so I implemented it
that way. If the channels are completely independent, there's no reason
why we can't model this as one rx, and one tx. The proposed API for
this should be suitable.
If I understand what you mean, "event completion" in this case is an ACK
for each event. Async event ACKing sounds pretty dirty, and I don't
really want to touch on that in the core implementation, but there
should be nothing stopping you from exposing a mailbox which uses
.put_message() to ACK an RX event.
> Rob
I'm glad you found this, as apparently I got your email address all
wrong.
Thanks for the comments!
-Courtney
^ permalink raw reply
* Re: [PATCHv4 4/7] hwspinlock/core: add common OF helpers
From: Suman Anna @ 2014-02-10 19:14 UTC (permalink / raw)
To: Bjorn Andersson, Ohad Ben-Cohen
Cc: Mark Rutland, Tony Lindgren, Kumar Gala,
linux-kernel@vger.kernel.org, linux-omap,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org
In-Reply-To: <CAJAp7Oi7wD+VsMAd37gT04yZ4TH4ygXFmheDhvmWuanUjpBmVQ@mail.gmail.com>
Bjorn,
On 02/07/2014 04:49 PM, Bjorn Andersson wrote:
> On Mon, Jan 13, 2014 at 4:19 PM, Suman Anna <s-anna@ti.com> wrote:
>> This patch adds three new OF helper functions to use/request
>> locks from a hwspinlock device instantiated through a
>> device-tree blob.
>
> Nice, I ran in to the problem of needing a probe deferral on a
> hwspinlock earlier this week so I implemented this yesterday...then I
> got a pointer to your series.
>
> [snip]
>> /**
>> + * of_hwspin_lock_request_specific() - request a OF phandle-based specific lock
>> + * @np: device node from which to request the specific hwlock
>> + * @propname: property name containing hwlock specifier(s)
>> + * @index: index of the hwlock
>> + *
>> + * This function is the OF equivalent of hwspin_lock_request_specific(). This
>> + * function provides a means for users of the hwspinlock module to request a
>> + * specific hwspinlock using the phandle of the hwspinlock device. The requested
>> + * lock number is indexed relative to the hwspinlock device, unlike the
>> + * hwspin_lock_request_specific() which is an absolute lock number.
>> + *
>> + * Returns the address of the assigned hwspinlock, or NULL on error
>> + */
>> +struct hwspinlock *of_hwspin_lock_request_specific(struct device_node *np,
>> + const char *propname, int index)
>> +{
>> + struct hwspinlock_device *bank;
>> + struct of_phandle_args args;
>> + int id;
>> + int ret;
>> +
>> + ret = of_parse_phandle_with_args(np, propname, "#hwlock-cells", index,
>> + &args);
>> + if (ret) {
>> + pr_warn("%s: can't parse hwlocks property of node '%s[%d]' ret = %d\n",
>> + __func__, np->full_name, index, ret);
>> + return NULL;
>> + }
>
> of_parse_phandle_with_args() already does pr_err if it can't find the
> phandle and on some of the issues related to arguments. So please
> remove this pr_warn().
Yes, I will clean this up.
>
> It seems to be standard practice to pass the error value back to the
> consumer, so you should
> return ERR_PTR(ret); here instead of the NULL...
I have modelled the return values in this function based on the return
values in the existing hwspin_lock_request interfaces. I would need to
change those functions as well.
Ohad,
Do you have any objections to the return code convention change? I agree
with Bjorn on the changes. If you are ok, then I will add a separate
patch for the existing functions and revise this patch as well.
>
>> +
>> + mutex_lock(&hwspinlock_tree_lock);
>> + list_for_each_entry(bank, &hwspinlock_devices, list)
>> + if (bank->dev->of_node == args.np)
>> + break;
>> + mutex_unlock(&hwspinlock_tree_lock);
>> + if (&bank->list == &hwspinlock_devices) {
>> + pr_warn("%s: requested hwspinlock device %s is not registered\n",
>> + __func__, args.np->full_name);
>> + return NULL;
>
> ...especially since you want the consumer to have the ability to
> identify this error. Here you should
> return ERR_PTR(-EPROBE_DEFER); so that the consumer knows that this
> lock is not _yet_ registered, but will be in the future.
>
> You should remove this pr_warn as well. The standard use of this
> function would be in a probe() and just returning this error value
> from that probe will give you a line in the log indicating that this
> was in fact the issue.
OK.
>
>> + }
>> +
>> + id = bank->ops->of_xlate(bank, &args);
>> + if (id < 0 || id >= bank->num_locks) {
>> + pr_warn("%s: requested lock %d is either out of range [0, %d] or failed translation\n",
>> + __func__, id, bank->num_locks - 1);
>> + return NULL;
>
> Please return ERR_PTR(-EINVAL); here.
OK, will change this based on Ohad's ack/nack.
>
> Looking forward to your next spin, as I will actually use this interface :)
Thanks for your comments. I will wait to see if there are any additional
comments before I refresh the series later this week.
regards
Suman
^ permalink raw reply
* [RFC] dt: bindings: add bindings for Broadcom bcm43xx sdio devices
From: Arend van Spriel @ 2014-02-10 19:17 UTC (permalink / raw)
To: Rob Herring
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Arend van Spriel,
Chen-Yu Tsai, Tomasz Figa
The Broadcom bcm43xx sdio devices are fullmac devices that may be
integrated in ARM platforms. Currently, the brcmfmac driver for
these devices support use of platform data. This patch specifies
the bindings that allow this platform data to be expressed in the
devicetree.
Cc: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
Cc: Tomasz Figa <tomasz.figa-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Reviewed-by: Hante Meuleman <meuleman-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
Reviewed-by: Pieter-Paul Giesberts <pieterpg-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
Signed-off-by: Arend van Spriel <arend-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
---
This devicetree binding proposal is intended for platforms with
Broadcom wireless device in MMC sdio slot. These devices may
have their own interrupt and power line. Also the SDIO drive
strength is often hardware dependent and expressed in this
binding.
Not sure if this should go in staging or not. Feel free to
comment on this proposal.
Regards,
Arend
---
.../staging/net/wireless/brcm,bcm43xx-fmac.txt | 37 ++++++++++++++++++++
1 file changed, 37 insertions(+)
create mode 100644 Documentation/devicetree/bindings/staging/net/wireless/brcm,bcm43xx-fmac.txt
diff --git a/Documentation/devicetree/bindings/staging/net/wireless/brcm,bcm43xx-fmac.txt b/Documentation/devicetree/bindings/staging/net/wireless/brcm,bcm43xx-fmac.txt
new file mode 100644
index 0000000..535f343
--- /dev/null
+++ b/Documentation/devicetree/bindings/staging/net/wireless/brcm,bcm43xx-fmac.txt
@@ -0,0 +1,37 @@
+Broadcom BCM43xx Fullmac wireless SDIO devices
+
+This node provides properties for controlling the Broadcom wireless device. The
+node is expected to be specified as a child node to the MMC controller that
+connects the device to the system.
+
+Required properties:
+
+ - compatible : Should be "brcm,bcm43xx-fmac".
+ - wlan-supply : phandle for fixed regulator used to control power for
+ the device/module.
+
+Optional properties:
+ - drive-strength : drive strength used for SDIO pins on device (default = 6mA).
+ - interrupt-parent : the phandle for the interrupt controller to which the
+ device interrupt (HOST_WAKE) is connected.
+ - interrupts : interrupt specifier encoded according the interrupt controller
+ specified by interrupt-parent property.
+
+Example:
+
+mmc3: mmc@01c20000 {
+ pinctrl-0 = <&mmc3_pins>;
+ pinctrl-1 = <&wifi_host_wake>;
+ vmmc-supply = <&mmc3_supply>;
+ bus-width = <4>;
+
+ bcm4335: bcm4335@0 {
+ compatible = "brcm,bcm43xx-fmac";
+ wlan-supply = <&wlan-reg>;
+ drive-strength = <4>;
+ interrupt-parent = <&gpx2>;
+ interrupts = <5 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "HOST_WAKE";
+ };
+};
+
--
1.7.10.4
--
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: [PATCHv4 0/7] omap hwspinlock dt support
From: Suman Anna @ 2014-02-10 19:27 UTC (permalink / raw)
To: Ohad Ben-Cohen, Mark Rutland
Cc: Tony Lindgren, Kumar Gala, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Suman Anna
In-Reply-To: <1389658764-39199-1-git-send-email-s-anna-l0cyMroinI0@public.gmane.org>
Mark,
On 01/13/2014 06:19 PM, Suman Anna wrote:
> Hi,
>
> This is an updated series mainly addressing Mark Rutland's comments
> about hwlock specifier being always one-cell. The series adds the
> support for #hwlock-cells property and adds a simple default OF
> translate function.
>
> The DTS patches from previous series have already been merged, and
> needs this property to be added. This is handled in a separate series
> that only deals with OMAP hwspinlock DTS patches.
>
> The series, along with the DTS patches, is tested on top of v3.13-rc8
> plus Tero's v13 clock DT series and Tony's 3.14 staged branches. The
> validation on OMAP5, DRA7, AM437 requires Tero's series with couple of
> additional base patches for AM43xx. AM43xx functionality needs a hwmod
> fix [1] for creating the associated omap_device as well.
>
Can you please take a look at this series and give your ack on the
bindings if you do not have any further comments? The only comments so
far are from Bjorn on the OF helpers.
regards
Suman
--
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: regression(ti platforms): next-20140210 (ehci?)
From: Nishanth Menon @ 2014-02-10 19:33 UTC (permalink / raw)
To: Kevin Hilman, Roger Quadros
Cc: linux-omap, linux-usb, Balbi, Felipe, linux-next,
devicetree@vger.kernel.org, tony@atomide.com
In-Reply-To: <7h61omakk9.fsf@paris.lan>
On 02/10/2014 12:28 PM, Kevin Hilman wrote:
> Roger Quadros <rogerq@ti.com> writes:
>
>> +devicetree
>>
>> On 02/10/2014 05:59 PM, Nishanth Menon wrote:
>>> Hi,
>>>
>>> A quick note to report that I saw regression in today's next tag (logs
>>> indicate around EHCI) boot on various TI platforms:
>>>
>>> Note: crane and sdp2430 are not expected to pass with
>>> multi_v7_defconfig (note: omap2plus_defconfig boot seems to be sane
>>> but USB is disabled there)
>>>
>>> next-20140210-multi_v7_defconfig
>>> 1: am335x-evm: Boot PASS: http://slexy.org/raw/s2zYHdPb94
>>> 2: am335x-sk: Boot PASS: http://slexy.org/raw/s2UChLyzSE
>>> 3: am3517-evm: Boot FAIL: http://slexy.org/raw/s20Br9XLO1
>>> around ehci
>>>
>>> 4: am37x-evm: Boot FAIL: http://slexy.org/raw/s20mVz9Wc7
>>> around ehci
>>>
>>> 5: am43xx-epos: Boot PASS: http://slexy.org/raw/s2byveBYtT
>>> 6: BeagleBoard-XM: Boot FAIL: http://slexy.org/raw/s21sOgJNwK
>>> around ehci
>>>
>>> 7: BeagleBone-Black: Boot PASS: http://slexy.org/raw/s2ovVNAmO7
>>> 8: crane: No Image built - Missing platform support?:
>>> 9: dra7: Boot PASS: http://slexy.org/raw/s217qwaXsM
>>> 10: ldp: Boot FAIL: http://slexy.org/raw/s203IvjE23
>>> around ehci
>>>
>>> 11: PandaBoard-ES: Boot FAIL: http://slexy.org/raw/s2NvkRx2YJ
>>> around ehci
>>
>> I think the problem is that ehci-platform driver gets loaded instead of ehci-omap.
>>
>> In the DT node we have compatible ids for both. e.g. for omap4.dtsi
>>
>> usbhsehci: ehci@4a064c00 {
>> compatible = "ti,ehci-omap", "usb-ehci";
>> reg = <0x4a064c00 0x400>;
>> interrupt-parent = <&gic>;
>> interrupts = <GIC_SPI 77 IRQ_TYPE_LEVEL_HIGH>;
>> };
>>
>> Shouldn't ehci-omap driver be getting a higher priority than usb-ehci?
>>
>> A quick fix would be to eliminate "usb-ehci" from the DT node of all failing platforms.
>
> I can confirm that simply remvoing usb-ehci from omap[34].dtsi nodes
> fixed the problem for me on 3530/overo, 3730/beagle-xM and
> 4460/panda-es. But I don't think that's the right fix. First we have
> to figure out why ehci-omap stopped getting loaded first.
Wont that depend on driver probe order? of_match_device is fairly
simple compatible walk through without looking at other drivers which
might also be compatible, but not yet probed?
The issue started I think with the following patch getting merged:
ehci-platform: Add support for clks and phy passed through devicetree
some version of http://www.spinics.net/lists/linux-usb/msg101061.html
introduced { .compatible = "usb-ehci", },
Now, in the build we have two drivers which dts claims compatibility
with, but only 1 driver actually works (drivers/usb/host/ehci-omap.c)
for the platform. Thinking that way, in fact, the current
compatibility even matches drivers/usb/host/ehci-ppc-of.c which
obviously wont work either.
--
Regards,
Nishanth Menon
^ permalink raw reply
* Re: [PATCH 2/2] spi: Add Qualcomm QUP SPI controller support
From: Ivan T. Ivanov @ 2014-02-10 19:41 UTC (permalink / raw)
To: Andy Gross
Cc: Mark Brown, Grant Likely, Rob Herring,
linux-spi-u79uwXL29TY76Z2rM5mHXA,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Alok Chauhan, Gilad Avidov,
Kiran Gunda, Sagar Dharia
In-Reply-To: <20140210174738.GA31596-zC7DfRvBq/JWk0Htik3J/w@public.gmane.org>
Hi,
On Mon, 2014-02-10 at 11:47 -0600, Andy Gross wrote:
> On Mon, Feb 10, 2014 at 06:55:02PM +0200, Ivan T. Ivanov wrote:
>
> [....]
>
> > > > > Bail here?
> > > >
> > > > I don't know. What will be the consequences if controller continue to
> > > > operate on its default rate?
> > > >
> > >
> > > It is unclear. But if you can't set the rate that is configured or if there is
> > > a misconfiguration, it's probably better to exit the probe and catch it here.
> >
> >
> > My preference is to delay clock speed change till first
> > SPI transfer. And use wherever transfer itself mandate.
> >
>
> That works. My only concern is that it might be nice to catch a configuration
> problem early rather than wait for the SPI transfer to fail continuously.
If developer is skilled enough to know which version controller is,
(s)he will be able to put the right frequency constrain here :-)
>
> [....]
>
> > > > My understanding is:
> > > >
> > > > Disabling clocks will timeout transaction, if any. Core Device driver
> > > > will call: devm_spi_unregister(), which will wait pending transactions
> > > > to complete and then remove the SPI master.
> > >
> > > Disabling clocks will confuse the hardware. We cannot disable clocks while the
> > > spi core is active and transferring data.
> >
> > I could follow approach taken by other SPI drivers, just reset
> > controller and disable clocks.
>
> You have to wait until the hardware is in a sane state. For the QUP, that means
> in a RUN/PAUSE/RESET state. It cannot be in transition when you cut the clocks.
> The safest thing to do is to get the QUP into the RESET state and then cut the
> clocks.
>
Sure. will do.
> [.....]
>
> > > > I am not aware of the difference. My board report v.20020000.
> > > > Is there difference of handling these controllers?
> > >
> > > There were some bug fixes between versions. None of those affect SPI (that I
> > > can tell), but it's better to be more descriptive and use the full versions in
> > > the compatible tags.
> >
> > No strong preference here. Should I add qcom,spi-qup-v2.2.0, then? :-)
>
> According to the documentation, there is no v2.2.0. It appears there is some
> disconnect between the specific HW revision and the documentation. I'll see if
> I can get some clarification from the hardware guys. For now, I think the 2.1.1
> and 2.2.1 tags are fine.
Ok. Thanks,
Ivan
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v4 0/8] Add Allwinner A20 GMAC ethernet support
From: Maxime Ripard @ 2014-02-10 19:47 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Emilio Lopez, Mike Turquette,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1392028554-32545-1-git-send-email-wens-jdAy2FN1RRM@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 817 bytes --]
Hi Chen-Yu,
On Mon, Feb 10, 2014 at 06:35:46PM +0800, Chen-Yu Tsai wrote:
> Hi,
>
> This is the v4 of the remaining Allwinner A20 GMAC glue layer patches.
> The stmmac driver changes have been merged through net-next. The
> remaining bits are clock and DT patches. The patches should be applied
> over my clock renaming patches.
>
> The Allwinner A20 SoC integrates an early version of dwmac
> IP from Synopsys. On top of that is a hardware glue layer.
> This layer needs to be configured before the dwmac can be
> used.
>
> Part of the glue layer is a clock mux, which controls the
> source and direction of the TX clock used by GMAC.
Just merged patches 2-8.
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* [PATCHv3 1/2] net: stmmac: Add SOCFPGA glue driver
From: dinguyen @ 2014-02-10 19:48 UTC (permalink / raw)
To: netdev, devicetree
Cc: dinh.linux, Dinh Nguyen, Giuseppe Cavallaro, Rob Herring,
Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala,
Vince Bridgers
From: Dinh Nguyen <dinguyen@altera.com>
Like the STi series SOCs, Altera's SOCFPGA also needs a glue layer on top of the
Synopsys gmac IP.
This patch adds the platform driver for the glue layer which configures the IP
before the generic STMMAC driver takes over.
Signed-off-by: Dinh Nguyen <dinguyen@altera.com>
Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
Cc: Kumar Gala <galak@codeaurora.org>
Cc: Vince Bridgers <vbridgers2013@gmail.com>
---
v3: Remove stray empty line at end of dwmac-socfpga.c.
v2: Use the dwmac-sti as an example for a glue layer and split patch up
to have dts as a separate patch. Also cc dts maintainers since there is
a new binding.
---
drivers/net/ethernet/stmicro/stmmac/Makefile | 1 +
.../net/ethernet/stmicro/stmmac/dwmac-socfpga.c | 183 ++++++++++++++++++++
2 files changed, 184 insertions(+)
create mode 100644 drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
diff --git a/drivers/net/ethernet/stmicro/stmmac/Makefile b/drivers/net/ethernet/stmicro/stmmac/Makefile
index ecadece..73df8b6 100644
--- a/drivers/net/ethernet/stmicro/stmmac/Makefile
+++ b/drivers/net/ethernet/stmicro/stmmac/Makefile
@@ -1,4 +1,5 @@
obj-$(CONFIG_STMMAC_ETH) += stmmac.o
+stmmac-$(CONFIG_ARCH_SOCFPGA) += dwmac-socfpga.o
stmmac-$(CONFIG_STMMAC_PLATFORM) += stmmac_platform.o
stmmac-$(CONFIG_STMMAC_PCI) += stmmac_pci.o
stmmac-$(CONFIG_DWMAC_SUNXI) += dwmac-sunxi.o
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
new file mode 100644
index 0000000..c7f034b
--- /dev/null
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
@@ -0,0 +1,183 @@
+/* Copyright (C) 2014 Altera Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see <http://www.gnu.org/licenses/>.
+ *
+ * Adopted from dwmac-sti.c
+ */
+
+#include <linux/clk.h>
+#include <linux/module.h>
+#include <linux/kernel.h>
+#include <linux/mfd/syscon.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/of_net.h>
+#include <linux/of_platform.h>
+#include <linux/phy.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+#include <linux/stmmac.h>
+
+#define SYSMGR_EMACGRP_CTRL_PHYSEL_ENUM_GMII_MII 0x0
+#define SYSMGR_EMACGRP_CTRL_PHYSEL_ENUM_RGMII 0x1
+#define SYSMGR_EMACGRP_CTRL_PHYSEL_ENUM_RMII 0x2
+#define SYSMGR_EMACGRP_CTRL_PHYSEL_WIDTH 2
+#define SYSMGR_EMACGRP_CTRL_PHYSEL_MASK 0x00000003
+
+struct socfpga_dwmac {
+ int interface;
+ u32 reg_offset;
+ struct device *dev;
+ struct regmap *sys_mgr_base_addr;
+ struct device_node *dwmac_np;
+};
+
+static int socfpga_dwmac_parse_data(struct socfpga_dwmac *dwmac, struct device *dev)
+{
+ struct device_node *np = dev->of_node;
+ struct device_node *stmmac_np;
+ struct regmap *sys_mgr_base_addr;
+ u32 reg_offset;
+ int ret;
+
+ stmmac_np = of_get_next_available_child(np, NULL);
+ if (!stmmac_np) {
+ dev_info(dev, "No dwmac node found\n");
+ return -EINVAL;
+ }
+
+ if (!of_device_is_compatible(stmmac_np, "snps,dwmac")) {
+ dev_info(dev, "dwmac node isn't compatible with snps,dwmac\n");
+ return -EINVAL;
+ }
+
+ dwmac->interface = of_get_phy_mode(stmmac_np);
+ of_node_put(stmmac_np);
+
+ sys_mgr_base_addr = syscon_regmap_lookup_by_phandle(np, "altr,sysmgr-syscon");
+ if (IS_ERR(sys_mgr_base_addr)) {
+ dev_info(dev, "No sysmgr-syscon node found\n");
+ return PTR_ERR(sys_mgr_base_addr);
+ }
+
+ ret = of_property_read_u32_index(np, "altr,sysmgr-syscon", 1, ®_offset);
+ if (ret) {
+ dev_info(dev, "Could not reg_offset into sysmgr-syscon!\n");
+ return -EINVAL;
+ }
+
+ dwmac->reg_offset = reg_offset;
+ dwmac->sys_mgr_base_addr = sys_mgr_base_addr;
+ dwmac->dwmac_np = stmmac_np;
+ dwmac->dev = dev;
+
+ return 0;
+}
+
+static int socfpga_dwmac_setup(struct socfpga_dwmac *dwmac)
+{
+ struct regmap *sys_mgr_base_addr = dwmac->sys_mgr_base_addr;
+ int phymode = dwmac->interface;
+ u32 reg_offset = dwmac->reg_offset;
+ u32 ctrl, val, shift = 0;
+
+ if (of_machine_is_compatible("altr,socfpga-vt"))
+ return 0;
+
+ switch (phymode) {
+ case PHY_INTERFACE_MODE_RGMII:
+ val = SYSMGR_EMACGRP_CTRL_PHYSEL_ENUM_RGMII;
+ break;
+ case PHY_INTERFACE_MODE_MII:
+ case PHY_INTERFACE_MODE_GMII:
+ val = SYSMGR_EMACGRP_CTRL_PHYSEL_ENUM_GMII_MII;
+ break;
+ default:
+ dev_err(dwmac->dev, "bad phy mode %d\n", phymode);
+ return -EINVAL;
+ }
+
+ regmap_read(sys_mgr_base_addr, reg_offset, &ctrl);
+ ctrl &= ~(SYSMGR_EMACGRP_CTRL_PHYSEL_MASK << shift);
+ ctrl |= val << shift;
+
+ regmap_write(sys_mgr_base_addr, reg_offset, ctrl);
+ return 0;
+}
+
+static int socfpga_dwmac_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct device_node *node = dev->of_node;
+ int ret = -ENOMEM;
+ struct socfpga_dwmac *dwmac;
+
+ dwmac = devm_kzalloc(dev, sizeof(*dwmac), GFP_KERNEL);
+ if (!dwmac)
+ return -ENOMEM;
+
+ ret = socfpga_dwmac_parse_data(dwmac, dev);
+ if (ret) {
+ dev_err(dev, "Unable to parse OF data\n");
+ return ret;
+ }
+
+ ret = socfpga_dwmac_setup(dwmac);
+ if (ret) {
+ dev_err(dev, "couldn't setup SoC glue (%d)\n", ret);
+ return ret;
+ }
+
+ if (node) {
+ ret = of_platform_populate(node, NULL, NULL, dev);
+ if (ret) {
+ dev_err(dev, "failed to add dwmac core\n");
+ return ret;
+ }
+ } else {
+ dev_err(dev, "no device node, failed to add dwmac core\n");
+ return -ENODEV;
+ }
+
+ platform_set_drvdata(pdev, dwmac);
+
+ return 0;
+}
+
+static int socfpga_dwmac_remove(struct platform_device *pdev)
+{
+ return 0;
+}
+
+static const struct of_device_id socfpga_dwmac_match[] = {
+ { .compatible = "altr,socfpga-stmmac" },
+ {},
+};
+MODULE_DEVICE_TABLE(of, socfpga_dwmac_match);
+
+static struct platform_driver socfpga_dwmac_driver = {
+ .probe = socfpga_dwmac_probe,
+ .remove = socfpga_dwmac_remove,
+ .driver = {
+ .name = "socfpga-dwmac",
+ .of_match_table = of_match_ptr(socfpga_dwmac_match),
+ },
+};
+
+module_platform_driver(socfpga_dwmac_driver);
+
+MODULE_ALIAS("platform:socfpga-dwmac");
+MODULE_AUTHOR("Dinh Nguyen <dinguyen@altera.com>");
+MODULE_LICENSE("GPL v2");
+MODULE_DESCRIPTION("Altera SOCFPGA DWMAC Glue Layer");
--
1.7.9.5
^ permalink raw reply related
* [PATCHv3 2/2] dts: socfpga: Add DTS entry for adding the stmmac glue layer for stmmac.
From: dinguyen @ 2014-02-10 19:48 UTC (permalink / raw)
To: netdev, devicetree
Cc: dinh.linux, Dinh Nguyen, Giuseppe Cavallaro, Rob Herring,
Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala,
Vince Bridgers
In-Reply-To: <1392061697-20193-1-git-send-email-dinguyen@altera.com>
From: Dinh Nguyen <dinguyen@altera.com>
This patch adds the dts bindings documenation for the Altera SOCFPGA glue
layer for the Synopsys STMMAC ethernet driver.
Signed-off-by: Dinh Nguyen <dinguyen@altera.com>
Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
Cc: Kumar Gala <galak@codeaurora.org>
Cc: Vince Bridgers <vbridgers2013@gmail.com>
---
v3: Remove stray empty line at end of socfpga_cyclone5_socdk.dts
v2: Use the dwmac-sti as an example for a glue layer and split patch up
to have dts as a separate patch. Also cc dts maintainers since there is
a new binding.
---
.../devicetree/bindings/net/socfpga-dwmac.txt | 35 ++++++++++++++
arch/arm/boot/dts/socfpga.dtsi | 51 +++++++++++++-------
arch/arm/boot/dts/socfpga_arria5_socdk.dts | 24 +++++++++
arch/arm/boot/dts/socfpga_cyclone5.dtsi | 6 ---
arch/arm/boot/dts/socfpga_cyclone5_socdk.dts | 17 +++++++
arch/arm/boot/dts/socfpga_cyclone5_sockit.dts | 22 ++++++++-
arch/arm/boot/dts/socfpga_vt.dts | 13 +++--
7 files changed, 139 insertions(+), 29 deletions(-)
create mode 100644 Documentation/devicetree/bindings/net/socfpga-dwmac.txt
diff --git a/Documentation/devicetree/bindings/net/socfpga-dwmac.txt b/Documentation/devicetree/bindings/net/socfpga-dwmac.txt
new file mode 100644
index 0000000..d53d376
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/socfpga-dwmac.txt
@@ -0,0 +1,35 @@
+Altera SOCFPGA SoC DWMAC controller
+
+The device node has following properties.
+
+Required properties:
+ - compatible : Should contain "altr,socfpga-stmmac"
+ - altr,sysmgr-syscon : Should be the phandle to the system manager node that
+ encompasses the glue register, and the register offset.
+
+Sub-nodes:
+The dwmac core should be added as subnode to SOCFPGA dwmac glue.
+- dwmac : The binding details of dwmac can be found in
+ Documentation/devicetree/bindings/net/stmmac.txt
+
+Example:
+
+ethernet0: ethernet0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ compatible = "altr,socfpga-stmmac";
+ altr,sysmgr-syscon = <&sysmgr 0x60>;
+ status = "disabled";
+ ranges;
+
+ gmac0: gmac0@ff700000 {
+ compatible = "snps,dwmac-3.70a", "snps,dwmac";
+ reg = <0xff700000 0x2000>;
+ interrupts = <0 115 4>;
+ interrupt-names = "macirq";
+ mac-address = [00 00 00 00 00 00];/* Filled in by U-Boot */
+ clocks = <&emac0_clk>;
+ clock-names = "stmmaceth";
+ };
+};
diff --git a/arch/arm/boot/dts/socfpga.dtsi b/arch/arm/boot/dts/socfpga.dtsi
index 8c4adb7..ebf6113 100644
--- a/arch/arm/boot/dts/socfpga.dtsi
+++ b/arch/arm/boot/dts/socfpga.dtsi
@@ -442,26 +442,43 @@
};
};
- gmac0: ethernet@ff700000 {
- compatible = "altr,socfpga-stmmac", "snps,dwmac-3.70a", "snps,dwmac";
- reg = <0xff700000 0x2000>;
- interrupts = <0 115 4>;
- interrupt-names = "macirq";
- mac-address = [00 00 00 00 00 00];/* Filled in by U-Boot */
- clocks = <&emac0_clk>;
- clock-names = "stmmaceth";
+ ethernet0: ethernet0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "altr,socfpga-stmmac";
+ altr,sysmgr-syscon = <&sysmgr 0x60>;
status = "disabled";
+ ranges;
+
+ gmac0: gmac0@ff700000 {
+ compatible = "snps,dwmac-3.70a", "snps,dwmac";
+ reg = <0xff700000 0x2000>;
+ interrupts = <0 115 4>;
+ interrupt-names = "macirq";
+ mac-address = [00 00 00 00 00 00];/* Filled in by U-Boot */
+ clocks = <&emac0_clk>;
+ clock-names = "stmmaceth";
+ };
};
- gmac1: ethernet@ff702000 {
- compatible = "altr,socfpga-stmmac", "snps,dwmac-3.70a", "snps,dwmac";
- reg = <0xff702000 0x2000>;
- interrupts = <0 120 4>;
- interrupt-names = "macirq";
- mac-address = [00 00 00 00 00 00];/* Filled in by U-Boot */
- clocks = <&emac1_clk>;
- clock-names = "stmmaceth";
+ ethernet1: ethernet1 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "altr,socfpga-stmmac";
+ altr,sysmgr-syscon = <&sysmgr 0x60>;
status = "disabled";
+ ranges;
+
+ gmac1: gmac1@ff702000 {
+ device_type = "network";
+ compatible = "snps,dwmac-3.70a", "snps,dwmac";
+ reg = <0xff702000 0x2000>;
+ interrupts = <0 120 4>;
+ interrupt-names = "macirq";
+ mac-address = [00 00 00 00 00 00];/* Filled in by U-Boot */
+ clocks = <&emac1_clk>;
+ clock-names = "stmmaceth";
+ };
};
L2: l2-cache@fffef000 {
@@ -538,7 +555,7 @@
reg = <0xffd05000 0x1000>;
};
- sysmgr@ffd08000 {
+ sysmgr: sysmgr@ffd08000 {
compatible = "altr,sys-mgr", "syscon";
reg = <0xffd08000 0x4000>;
};
diff --git a/arch/arm/boot/dts/socfpga_arria5_socdk.dts b/arch/arm/boot/dts/socfpga_arria5_socdk.dts
index 5beffb2..2d6b38b 100644
--- a/arch/arm/boot/dts/socfpga_arria5_socdk.dts
+++ b/arch/arm/boot/dts/socfpga_arria5_socdk.dts
@@ -37,4 +37,28 @@
*/
ethernet0 = &gmac1;
};
+
+ aliases {
+ /* this allow the ethaddr uboot environmnet variable contents
+ * to be added to the gmac1 device tree blob.
+ */
+ ethernet0 = &gmac1;
+ };
+};
+
+ðernet1 {
+ status = "okay";
+};
+
+&gmac1 {
+ phy-mode = "rgmii";
+
+ rxd0-skew-ps = <0>;
+ rxd1-skew-ps = <0>;
+ rxd2-skew-ps = <0>;
+ rxd3-skew-ps = <0>;
+ txen-skew-ps = <0>;
+ txc-skew-ps = <2600>;
+ rxdv-skew-ps = <0>;
+ rxc-skew-ps = <2000>;
};
diff --git a/arch/arm/boot/dts/socfpga_cyclone5.dtsi b/arch/arm/boot/dts/socfpga_cyclone5.dtsi
index ca41b0e..454148d 100644
--- a/arch/arm/boot/dts/socfpga_cyclone5.dtsi
+++ b/arch/arm/boot/dts/socfpga_cyclone5.dtsi
@@ -39,12 +39,6 @@
};
};
- ethernet@ff702000 {
- phy-mode = "rgmii";
- phy-addr = <0xffffffff>; /* probe for phy addr */
- status = "okay";
- };
-
timer0@ffc08000 {
clock-frequency = <100000000>;
};
diff --git a/arch/arm/boot/dts/socfpga_cyclone5_socdk.dts b/arch/arm/boot/dts/socfpga_cyclone5_socdk.dts
index 2ee52ab..26c63a0 100644
--- a/arch/arm/boot/dts/socfpga_cyclone5_socdk.dts
+++ b/arch/arm/boot/dts/socfpga_cyclone5_socdk.dts
@@ -38,3 +38,20 @@
ethernet0 = &gmac1;
};
};
+
+ðernet1 {
+ status = "okay";
+};
+
+&gmac1 {
+ phy-mode = "rgmii";
+
+ rxd0-skew-ps = <0>;
+ rxd1-skew-ps = <0>;
+ rxd2-skew-ps = <0>;
+ rxd3-skew-ps = <0>;
+ txen-skew-ps = <0>;
+ txc-skew-ps = <2600>;
+ rxdv-skew-ps = <0>;
+ rxc-skew-ps = <2000>;
+};
diff --git a/arch/arm/boot/dts/socfpga_cyclone5_sockit.dts b/arch/arm/boot/dts/socfpga_cyclone5_sockit.dts
index 50b99a2..469bb5c 100644
--- a/arch/arm/boot/dts/socfpga_cyclone5_sockit.dts
+++ b/arch/arm/boot/dts/socfpga_cyclone5_sockit.dts
@@ -30,8 +30,28 @@
device_type = "memory";
reg = <0x0 0x40000000>; /* 1GB */
};
+
+ aliases {
+ /* this allow the ethaddr uboot environmnet variable contents
+ * to be added to the gmac1 device tree blob.
+ */
+ ethernet0 = &gmac1;
+ };
};
-&gmac1 {
+ðernet1 {
status = "okay";
};
+
+&gmac1 {
+ phy-mode = "rgmii";
+
+ rxd0-skew-ps = <0>;
+ rxd1-skew-ps = <0>;
+ rxd2-skew-ps = <0>;
+ rxd3-skew-ps = <0>;
+ txen-skew-ps = <0>;
+ txc-skew-ps = <2600>;
+ rxdv-skew-ps = <0>;
+ rxc-skew-ps = <2000>;
+};
diff --git a/arch/arm/boot/dts/socfpga_vt.dts b/arch/arm/boot/dts/socfpga_vt.dts
index 222313f..418472c 100644
--- a/arch/arm/boot/dts/socfpga_vt.dts
+++ b/arch/arm/boot/dts/socfpga_vt.dts
@@ -52,11 +52,6 @@
};
};
- ethernet@ff700000 {
- phy-mode = "gmii";
- status = "okay";
- };
-
timer0@ffc08000 {
clock-frequency = <7000000>;
};
@@ -86,3 +81,11 @@
};
};
};
+
+ðernet0 {
+ status = "okay";
+};
+
+&gmac0 {
+ phy-mode = "gmii";
+};
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH v4 1/8] clk: sunxi: Add Allwinner A20/A31 GMAC clock unit
From: Maxime Ripard @ 2014-02-10 19:48 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Emilio Lopez, Mike Turquette,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1392028554-32545-2-git-send-email-wens-jdAy2FN1RRM@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 544 bytes --]
On Mon, Feb 10, 2014 at 06:35:47PM +0800, Chen-Yu Tsai wrote:
> The Allwinner A20/A31 clock module controls the transmit clock source
> and interface type of the GMAC ethernet controller. Model this as
> a single clock for GMAC drivers to use.
>
> Signed-off-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
Acked-by: Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] ARM: dts: OMAP2+: Fix boot with multi_v7_defconfig
From: Nishanth Menon @ 2014-02-10 19:50 UTC (permalink / raw)
To: Roger Quadros, tony
Cc: bcousson, balbi, linux-omap, linux-arm-kernel, linux-kernel,
devicetree
In-Reply-To: <1392055835-6494-1-git-send-email-rogerq@ti.com>
$subject probably needs clarity.
On 02/10/2014 12:10 PM, Roger Quadros wrote:
> The OMAP EHCI controller is not compatible with the EHCI
> platform HCD driver so don't claim that we are.
might want to refer to the change in drivers/usb/host/ehci-platform.c
that created this regression as well.
we also probably want to make better explanation about this issue and
why we think this is the correct fix for it - for example, question
Kevin asked in [1]
>
> This fixes boot on OMAP platforms with CONFIG_USB_EHCI_HCD_PLATFORM=y
> e.g. multi_v7_defconfig
>
> Reported-by: Nishanth Menon <nm@ti.com>
> Signed-off-by: Roger Quadros <rogerq@ti.com>
> ---
[1] http://marc.info/?t=139204803900004&r=1&w=2
--
Regards,
Nishanth Menon
^ permalink raw reply
* Re: [RFC 1/6] mailbox: add core framework
From: Courtney Cavin @ 2014-02-10 19:59 UTC (permalink / raw)
To: Josh Cartwright
Cc: Rob Herring, Arnd Bergmann, s-anna@ti.com, Rob Herring,
Wysocki, Rafael J, Mark Langsdorf, Tony Lindgren,
omar.ramirez@copitl.com, Greg Kroah-Hartman, Pawel Moll,
Mark Rutland, Ian Campbell, Kumar Gala, Rob Landley,
linux-doc@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20140210190934.GA841@joshc.qualcomm.com>
On Mon, Feb 10, 2014 at 08:09:34PM +0100, Josh Cartwright wrote:
> On Mon, Feb 10, 2014 at 11:52:05AM -0600, Rob Herring wrote:
> > On Mon, Feb 10, 2014 at 8:11 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> > > On Friday 07 February 2014 16:50:14 Courtney Cavin wrote:
> [..]
> > >> +int mbox_channel_notify(struct mbox_channel *chan,
> > >> + const void *data, unsigned int len)
> > >> +{
> > >> + return atomic_notifier_call_chain(&chan->notifier, len, (void *)data);
> > >> +}
> > >> +EXPORT_SYMBOL(mbox_channel_notify);
> > >
> > > What is the reason to use a notifier chain here? Isn't a simple
> > > callback function pointer enough? I would expect that each mailbox
> > > can have exactly one consumer, not multiple ones.
> >
> > It probably can be a callback, but there can be multiple consumers. It
> > was only a notifier on the pl320 as there was no framework at the time
> > and to avoid creating custom interfaces between drivers. On highbank
> > for example, we can asynchronously receive the events for temperature
> > change, power off, and reset. So either there needs to be an event
> > demux somewhere or callbacks have to return whether they handled an
> > event or not.
>
> I'm not familiar with highbank IPC, but with these requirements should
> the mailbox core even bother with asynchronous notifier chain? It
> sounds like a better fit might be for the mailbox core to implement a
> proper adapter-specific irqdomain and used a chained irq handler to
> demux (or have consumers request with IRQF_SHARED in the shared case).
Although modeling this using irqdomains makes sense for the notification
bit, and would probably suit most adapters, there's the issue of data
being passed around which doesn't quite fit. "Ok, I have mail... where
is it?" Did you have something in mind for that?
Frankly, I don't see the notifier chain as being extraneous or
over-complicated here core-wise or implementation-wise, and unless I
understand Rob incorrectly, should suit the existing use-cases. Am I
missing something?
-Courtney
^ permalink raw reply
* Re: [PATCH] net: rfkill-regulator: Add devicetree support.
From: Belisko Marek @ 2014-02-10 20:05 UTC (permalink / raw)
To: Dr. H. Nikolaus Schaller
Cc: Johannes Berg, Rob Herring, Pawel Moll, Mark Rutland,
ijc+devicetree@hellion.org.uk, Kumar Gala, Rob Landley,
John W. Linville, David Miller, Grant Likely, NeilBrown Brown,
devicetree@vger.kernel.org, linux-doc@vger.kernel.org, LKML,
linux-wireless, netdev
In-Reply-To: <BF9457FD-CEED-4290-9150-57F51F6E42FC@goldelico.com>
On Mon, Feb 10, 2014 at 9:54 AM, Dr. H. Nikolaus Schaller
<hns@goldelico.com> wrote:
> Am 10.02.2014 um 09:27 schrieb Johannes Berg:
>
>> On Fri, 2014-02-07 at 20:48 +0100, Marek Belisko wrote:
>>
>>> +#define RFKILL_TYPE_ALL (0)
>>> +#define RFKILL_TYPE_WLAN (1)
>>> +#define RFKILL_TYPE_BLUETOOTH (2)
>>> +#define RFKILL_TYPE_UWB (3)
>>> +#define RFKILL_TYPE_WIMAX (4)
>>> +#define RFKILL_TYPE_WWAN (5)
>>> +#define RFKILL_TYPE_GPS (6)
>>> +#define RFKILL_TYPE_FM (7)
>>> +#define RFKILL_TYPE_NFC (8)
>>
>> This seems like a bad idea since there's an enum elsewhere in userspace
>> API already.
I know this is duplicate but in device tree we cannot use enums
(AFAIU include/dt-bindings are defines used in device tree files)
>
> Yes,
> you are right. It is defined in include/uapi/linux/rfkill.h
>
> Tnx,
> Nikolaus
>
BR,
marek
--
as simple and primitive as possible
-------------------------------------------------
Marek Belisko - OPEN-NANDRA
Freelance Developer
Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
^ permalink raw reply
* Re: [PATCH 2/2] spi: Add Qualcomm QUP SPI controller support
From: Courtney Cavin @ 2014-02-10 20:29 UTC (permalink / raw)
To: Ivan T. Ivanov
Cc: Andy Gross, Mark Brown, Grant Likely, Rob Herring,
linux-spi@vger.kernel.org, linux-arm-msm@vger.kernel.org,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
Alok Chauhan, Gilad Avidov, Kiran Gunda, Sagar Dharia
In-Reply-To: <1392061304.24621.17.camel@violet>
On Mon, Feb 10, 2014 at 08:41:44PM +0100, Ivan T. Ivanov wrote:
>
> Hi,
>
> On Mon, 2014-02-10 at 11:47 -0600, Andy Gross wrote:
> > On Mon, Feb 10, 2014 at 06:55:02PM +0200, Ivan T. Ivanov wrote:
> >
> > [....]
> >
> > > > > > Bail here?
> > > > >
> > > > > I don't know. What will be the consequences if controller continue to
> > > > > operate on its default rate?
> > > > >
> > > >
> > > > It is unclear. But if you can't set the rate that is configured or if there is
> > > > a misconfiguration, it's probably better to exit the probe and catch it here.
> > >
> > >
> > > My preference is to delay clock speed change till first
> > > SPI transfer. And use wherever transfer itself mandate.
> > >
> >
> > That works. My only concern is that it might be nice to catch a configuration
> > problem early rather than wait for the SPI transfer to fail continuously.
>
> If developer is skilled enough to know which version controller is,
> (s)he will be able to put the right frequency constrain here :-)
A developer doesn't have to have much skill at all to copy-paste DT
configurations around and muck with numbers.... I agree with Andy here,
early validation is a good idea here, at the very least, some sanity
checks.
-Courtney
^ permalink raw reply
* Re: [PATCH v2] ARM: sunxi: Add driver for sunxi usb phy
From: Maxime Ripard @ 2014-02-10 20:43 UTC (permalink / raw)
To: Hans de Goede
Cc: Kishon Vijay Abraham I,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, devicetree,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <52F56BEE.8070703-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 13967 bytes --]
Hi,
On Sat, Feb 08, 2014 at 12:27:42AM +0100, Hans de Goede wrote:
> Hi,
>
> On 02/07/2014 11:36 PM, Maxime Ripard wrote:
> >Hi Hans,
> >
> >It looks very nice, I just have a few comments below though.
> >
> >On Fri, Feb 07, 2014 at 05:33:21PM +0100, Hans de Goede wrote:
> >>The Allwinner A1x / A2x SoCs have 2 or 3 usb phys which are all accessed
> >>through a single set of registers. Besides this there are also some other
> >>phy related bits which need poking, which are per phy, but shared between the
> >>ohci and ehci controllers, so these are also controlled from this new phy
> >>driver.
> >>
> >>Signed-off-by: Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> >>---
> >> .../devicetree/bindings/phy/sun4i-usb-phy.txt | 28 ++
> >> drivers/phy/Kconfig | 11 +
> >> drivers/phy/Makefile | 1 +
> >> drivers/phy/phy-sun4i-usb.c | 326 +++++++++++++++++++++
> >> 4 files changed, 366 insertions(+)
> >> create mode 100644 Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
> >> create mode 100644 drivers/phy/phy-sun4i-usb.c
> >>
> >>diff --git a/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt b/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
> >>new file mode 100644
> >>index 0000000..f7eccb2
> >>--- /dev/null
> >>+++ b/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
> >>@@ -0,0 +1,28 @@
> >>+Allwinner sun4i USB PHY
> >>+-----------------------
> >>+
> >>+Required properties:
> >>+- compatible : should be one of "allwinner,sun4i-a10-usb-phy",
> >>+ "allwinner,sun5i-a13-usb-phy" or "allwinner,sun7i-a20-usb-phy"
> >>+- reg : a list of offset + length pairs, the 1st list entry should point to
> >>+ the phy base regs, the 2nd entry to the pmu reg for phy1, and the 3th
> >>+ entry to the pmu reg of phy2 (for devices which have a phy2).
> >
> >I'm concerned about devices that would only have a phy2 for some
> >reason.
>
> phy1 and phy2 are identical, so in that case we would just call the phy
> phy1 I guess, and specify its register where ever it lives and be done with
> it.
>
> >Using reg-names would be much more robust, and is quite painless to
> >use. Just use platform_get_resource_by_name instead of
> >platform_get_resource, and that's pretty much it.
>
> The above argument does not really help to convince me to use
> register-names, I don't really see them as useful / necessary,
> adding support for them will just grow the driver-code, as well
> as the devicetree bindings docs, as well as the dts files.
>
> But if you really really want me to use register-names, just say so
> and I'll modify the patch.
Yep, overall, whenever there's several resources involved, I very much
prefer to differentiate them by name, rather than by index, which is
much more fragile.
And the overhead is of one single line in the DT, one single line in
the doc, and a few of them in the driver. It doesn't look like it
bloats the code that much...
>
>
> >
> >>+- #phy-cells : from the generic phy bindings, must be 1
> >>+
> >>+Optional properties:
> >>+- clocks : phandle + clock specifier for the phy clock
> >>+- clock-names : "usb_phy"
> >>+- resets : a list of phandle + reset specifier pairs
> >>+- reset-names : "usb0_reset", "usb1_reset", and / or "usb2_reset"
> >>+
> >>+Example:
> >>+ usbphy: phy@0x01c13400 {
> >>+ #phy-cells = <1>;
> >>+ compatible = "allwinner,sun4i-a10-usb-phy";
> >>+ /* phy base regs, phy1 pmu reg, phy2 pmu reg */
> >>+ reg = <0x01c13400 0x10 0x01c14800 0x4 0x01c1c800 0x4>;
> >>+ clocks = <&usb_clk 8>;
> >>+ clock-names = "usb_phy";
> >>+ resets = <&usb_clk 1>, <&usb_clk 2>;
> >>+ reset-names = "usb1_reset", "usb2_reset";
> >>+ };
> >>diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> >>index afa2354..6070c99 100644
> >>--- a/drivers/phy/Kconfig
> >>+++ b/drivers/phy/Kconfig
> >>@@ -64,4 +64,15 @@ config BCM_KONA_USB2_PHY
> >> help
> >> Enable this to support the Broadcom Kona USB 2.0 PHY.
> >>
> >>+config PHY_SUN4I_USB
> >>+ tristate "Allwinner sunxi SoC USB PHY driver"
> >>+ depends on ARCH_SUNXI
> >>+ select GENERIC_PHY
> >>+ help
> >>+ Enable this to support the transceiver that is part of Allwinner
> >>+ sunxi SoCs.
> >>+
> >>+ This driver controls the entire USB PHY block, both the USB OTG
> >>+ parts, as well as the 2 regular USB 2 host PHYs.
> >>+
> >> endmenu
> >>diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
> >>index b57c253..9d4f8bb 100644
> >>--- a/drivers/phy/Makefile
> >>+++ b/drivers/phy/Makefile
> >>@@ -9,3 +9,4 @@ obj-$(CONFIG_PHY_EXYNOS_MIPI_VIDEO) += phy-exynos-mipi-video.o
> >> obj-$(CONFIG_PHY_MVEBU_SATA) += phy-mvebu-sata.o
> >> obj-$(CONFIG_OMAP_USB2) += phy-omap-usb2.o
> >> obj-$(CONFIG_TWL4030_USB) += phy-twl4030-usb.o
> >>+obj-$(CONFIG_PHY_SUN4I_USB) += phy-sun4i-usb.o
> >>diff --git a/drivers/phy/phy-sun4i-usb.c b/drivers/phy/phy-sun4i-usb.c
> >>new file mode 100644
> >>index 0000000..bd9cb7fa
> >>--- /dev/null
> >>+++ b/drivers/phy/phy-sun4i-usb.c
> >>@@ -0,0 +1,326 @@
> >>+/*
> >>+ * Allwinner sun4i USB phy driver
> >>+ *
> >>+ * Copyright (C) 2014 Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> >>+ *
> >>+ * Based on code from
> >>+ * Allwinner Technology Co., Ltd. <www.allwinnertech.com>
> >>+ *
> >>+ * Modelled after: Samsung S5P/EXYNOS SoC series MIPI CSIS/DSIM DPHY driver
> >>+ * Copyright (C) 2013 Samsung Electronics Co., Ltd.
> >>+ * Author: Sylwester Nawrocki <s.nawrocki-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
> >>+ *
> >>+ * This program is free software; you can redistribute it and/or modify
> >>+ * it under the terms of the GNU General Public License as published by
> >>+ * the Free Software Foundation; either version 2 of the License, or
> >>+ * (at your option) any later version.
> >>+ *
> >>+ * This program is distributed in the hope that it will be useful,
> >>+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
> >>+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> >>+ * GNU General Public License for more details.
> >>+ */
> >>+
> >>+#include <linux/clk.h>
> >>+#include <linux/io.h>
> >>+#include <linux/kernel.h>
> >>+#include <linux/module.h>
> >>+#include <linux/mutex.h>
> >>+#include <linux/of.h>
> >>+#include <linux/of_address.h>
> >>+#include <linux/phy/phy.h>
> >>+#include <linux/platform_device.h>
> >>+#include <linux/regulator/consumer.h>
> >>+#include <linux/reset.h>
> >>+
> >>+#define REG_ISCR 0x00
> >>+#define REG_PHYCTL 0x04
> >>+#define REG_PHYBIST 0x08
> >>+#define REG_PHYTUNE 0x0c
> >>+
> >>+#define SUNXI_AHB_ICHR8_EN BIT(10)
> >>+#define SUNXI_AHB_INCR4_BURST_EN BIT(9)
> >>+#define SUNXI_AHB_INCRX_ALIGN_EN BIT(8)
> >>+#define SUNXI_ULPI_BYPASS_EN BIT(0)
> >>+
> >>+/* Common Control Bits for Both PHYs */
> >>+#define PHY_PLL_BW 0x03
> >>+#define PHY_RES45_CAL_EN 0x0c
> >>+
> >>+/* Private Control Bits for Each PHY */
> >>+#define PHY_TX_AMPLITUDE_TUNE 0x20
> >>+#define PHY_TX_SLEWRATE_TUNE 0x22
> >>+#define PHY_VBUSVALID_TH_SEL 0x25
> >>+#define PHY_PULLUP_RES_SEL 0x27
> >>+#define PHY_OTG_FUNC_EN 0x28
> >>+#define PHY_VBUS_DET_EN 0x29
> >>+#define PHY_DISCON_TH_SEL 0x2a
> >>+
> >>+#define MAX_PHYS 3
> >>+
> >>+struct sun4i_usb_phy_data {
> >>+ struct clk *clk;
> >>+ void __iomem *base;
> >>+ struct mutex mutex;
> >>+ int num_phys;
> >>+ u32 disc_thresh;
> >>+ struct sun4i_usb_phy {
> >>+ struct phy *phy;
> >>+ void __iomem *pmu;
> >>+ struct regulator *vbus;
> >>+ struct reset_control *reset;
> >>+ int index;
> >>+ } phys[MAX_PHYS];
> >>+};
> >>+
> >>+#define to_sun4i_usb_phy_data(phy) \
> >>+ container_of((phy), struct sun4i_usb_phy_data, phys[(phy)->index])
> >>+
> >>+static void sun4i_usb_phy_write(struct sun4i_usb_phy *phy, u32 addr, u32 data,
> >>+ int len)
> >>+{
> >>+ struct sun4i_usb_phy_data *phy_data = to_sun4i_usb_phy_data(phy);
> >>+ u32 temp, usbc_bit = BIT(phy->index * 2);
> >>+ int i;
> >>+
> >>+ mutex_lock(&phy_data->mutex);
> >>+
> >>+ for (i = 0; i < len; i++) {
> >>+ temp = readl(phy_data->base + REG_PHYCTL);
> >>+
> >>+ /* clear the address portion */
> >>+ temp &= ~(0xff << 8);
> >>+
> >>+ /* set the address */
> >>+ temp |= ((addr + i) << 8);
> >>+ writel(temp, phy_data->base + REG_PHYCTL);
> >>+
> >>+ /* set the data bit and clear usbc bit*/
> >>+ temp = readb(phy_data->base + REG_PHYCTL);
> >>+ if (data & 0x1)
> >>+ temp |= BIT(7);
> >>+ else
> >>+ temp &= ~BIT(7);
> >>+ temp &= ~usbc_bit;
> >>+ writeb(temp, phy_data->base + REG_PHYCTL);
> >>+
> >>+ /* pulse usbc_bit */
> >>+ temp = readb(phy_data->base + REG_PHYCTL);
> >>+ temp |= usbc_bit;
> >>+ writeb(temp, phy_data->base + REG_PHYCTL);
> >>+
> >>+ temp = readb(phy_data->base + REG_PHYCTL);
> >>+ temp &= ~usbc_bit;
> >>+ writeb(temp, phy_data->base + REG_PHYCTL);
> >>+
> >>+ data >>= 1;
> >>+ }
> >>+ mutex_unlock(&phy_data->mutex);
> >>+}
> >>+
> >>+static void sun4i_usb_phy_passby(struct sun4i_usb_phy *phy, int enable)
> >>+{
> >>+ u32 bits, reg_value;
> >>+
> >>+ if (!phy->pmu)
> >>+ return;
> >>+
> >>+ bits = SUNXI_AHB_ICHR8_EN | SUNXI_AHB_INCR4_BURST_EN |
> >>+ SUNXI_AHB_INCRX_ALIGN_EN | SUNXI_ULPI_BYPASS_EN;
> >>+
> >>+ reg_value = readl(phy->pmu);
> >>+
> >>+ if (enable)
> >>+ reg_value |= bits;
> >>+ else
> >>+ reg_value &= ~bits;
> >>+
> >>+ writel(reg_value, phy->pmu);
> >>+}
> >>+
> >>+static int sun4i_usb_phy_init(struct phy *_phy)
> >>+{
> >>+ struct sun4i_usb_phy *phy = phy_get_drvdata(_phy);
> >>+ struct sun4i_usb_phy_data *data = to_sun4i_usb_phy_data(phy);
> >>+ int ret;
> >>+
> >>+ ret = clk_prepare_enable(data->clk);
> >>+ if (ret)
> >>+ return ret;
> >>+
> >>+ ret = reset_control_deassert(phy->reset);
> >>+ if (ret) {
> >>+ clk_disable_unprepare(data->clk);
> >>+ return ret;
> >>+ }
> >>+
> >>+ /* Adjust PHY's magnitude and rate */
> >>+ sun4i_usb_phy_write(phy, PHY_TX_AMPLITUDE_TUNE, 0x14, 5);
> >>+
> >>+ /* Disconnect threshold adjustment */
> >>+ sun4i_usb_phy_write(phy, PHY_DISCON_TH_SEL, data->disc_thresh, 2);
> >>+
> >>+ sun4i_usb_phy_passby(phy, 1);
> >>+
> >>+ return 0;
> >>+}
> >>+
> >>+static int sun4i_usb_phy_exit(struct phy *_phy)
> >>+{
> >>+ struct sun4i_usb_phy *phy = phy_get_drvdata(_phy);
> >>+ struct sun4i_usb_phy_data *data = to_sun4i_usb_phy_data(phy);
> >>+
> >>+ sun4i_usb_phy_passby(phy, 0);
> >>+ reset_control_assert(phy->reset);
> >>+ clk_disable_unprepare(data->clk);
> >>+
> >>+ return 0;
> >>+}
> >>+
> >>+static int sun4i_usb_phy_power_on(struct phy *_phy)
> >>+{
> >>+ struct sun4i_usb_phy *phy = phy_get_drvdata(_phy);
> >>+ int ret = 0;
> >>+
> >>+ if (phy->vbus)
> >>+ ret = regulator_enable(phy->vbus);
> >>+
> >>+ return ret;
> >>+}
> >>+
> >>+static int sun4i_usb_phy_power_off(struct phy *_phy)
> >>+{
> >>+ struct sun4i_usb_phy *phy = phy_get_drvdata(_phy);
> >>+
> >>+ if (phy->vbus)
> >>+ regulator_disable(phy->vbus);
> >>+
> >>+ return 0;
> >>+}
> >>+
> >>+static struct phy_ops sun4i_usb_phy_ops = {
> >>+ .init = sun4i_usb_phy_init,
> >>+ .exit = sun4i_usb_phy_exit,
> >>+ .power_on = sun4i_usb_phy_power_on,
> >>+ .power_off = sun4i_usb_phy_power_off,
> >>+ .owner = THIS_MODULE,
> >>+};
> >>+
> >>+static struct phy *sun4i_usb_phy_xlate(struct device *dev,
> >>+ struct of_phandle_args *args)
> >>+{
> >>+ struct sun4i_usb_phy_data *data = dev_get_drvdata(dev);
> >>+
> >>+ if (WARN_ON(args->args[0] == 0 || args->args[0] >= data->num_phys))
> >>+ return ERR_PTR(-ENODEV);
> >>+
> >>+ return data->phys[args->args[0]].phy;
> >>+}
> >>+
> >>+static int sun4i_usb_phy_probe(struct platform_device *pdev)
> >>+{
> >>+ struct sun4i_usb_phy_data *data;
> >>+ struct device *dev = &pdev->dev;
> >>+ struct device_node *np = dev->of_node;
> >>+ void __iomem *pmu = NULL;
> >>+ struct phy_provider *phy_provider;
> >>+ struct reset_control *reset;
> >>+ struct regulator *vbus;
> >>+ struct phy *phy;
> >>+ char name[16];
> >>+ int i;
> >>+
> >>+ data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
> >>+ if (!data)
> >>+ return -ENOMEM;
> >>+
> >>+ mutex_init(&data->mutex);
> >>+
> >>+ if (of_device_is_compatible(np, "allwinner,sun5i-a13-usb-phy"))
> >>+ data->num_phys = 2;
> >>+ else
> >>+ data->num_phys = 3;
> >>+
> >>+ if (of_device_is_compatible(np, "allwinner,sun4i-a10-usb-phy"))
> >>+ data->disc_thresh = 3;
> >>+ else
> >>+ data->disc_thresh = 2;
> >
> >I'd still prefer to pass this through the .data field of of_device_id,
> >but it looks much cleaner already :)
>
> The problem with using the .data field is that I can only store a single
> integer there. To store 2 I need to: define a struct, create an array
> of these structs with initialization. Create an enum for indexing the
> array which must be kept in sync with the initializers manually, store
> either the index, or a direct pointer to the correct array entry into
> the .data field, add code to get the of_device_id from the compatible
> string, and then finally extract the settings from the struct again.
>
> See IE how this is done in drivers/ata/ahci_platform.c, I've tried
> to come up with a simpler way and failed, for ahci_platform.c the
> struct with per compatible-string data is quite big so it makes some
> sense to use this construction. Here however not so much, this adds a
> whole lot of unnecessary extra code + indirection. I esp. object against
> the indirection as that unnecessarily makes it harder to follow whats
> going on.
Ok, thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [RFC 1/6] mailbox: add core framework
From: Rob Herring @ 2014-02-10 20:45 UTC (permalink / raw)
To: Courtney Cavin
Cc: Josh Cartwright, Arnd Bergmann, s-anna@ti.com, Rob Herring,
Wysocki, Rafael J, Mark Langsdorf, Tony Lindgren,
omar.ramirez@copitl.com, Greg Kroah-Hartman, Pawel Moll,
Mark Rutland, Ian Campbell, Kumar Gala, Rob Landley,
linux-doc@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20140210195914.GU1706@sonymobile.com>
On Mon, Feb 10, 2014 at 1:59 PM, Courtney Cavin
<courtney.cavin@sonymobile.com> wrote:
> On Mon, Feb 10, 2014 at 08:09:34PM +0100, Josh Cartwright wrote:
>> On Mon, Feb 10, 2014 at 11:52:05AM -0600, Rob Herring wrote:
>> > On Mon, Feb 10, 2014 at 8:11 AM, Arnd Bergmann <arnd@arndb.de> wrote:
>> > > On Friday 07 February 2014 16:50:14 Courtney Cavin wrote:
>> [..]
>> > >> +int mbox_channel_notify(struct mbox_channel *chan,
>> > >> + const void *data, unsigned int len)
>> > >> +{
>> > >> + return atomic_notifier_call_chain(&chan->notifier, len, (void *)data);
>> > >> +}
>> > >> +EXPORT_SYMBOL(mbox_channel_notify);
>> > >
>> > > What is the reason to use a notifier chain here? Isn't a simple
>> > > callback function pointer enough? I would expect that each mailbox
>> > > can have exactly one consumer, not multiple ones.
>> >
>> > It probably can be a callback, but there can be multiple consumers. It
>> > was only a notifier on the pl320 as there was no framework at the time
>> > and to avoid creating custom interfaces between drivers. On highbank
>> > for example, we can asynchronously receive the events for temperature
>> > change, power off, and reset. So either there needs to be an event
>> > demux somewhere or callbacks have to return whether they handled an
>> > event or not.
>>
>> I'm not familiar with highbank IPC, but with these requirements should
>> the mailbox core even bother with asynchronous notifier chain? It
>> sounds like a better fit might be for the mailbox core to implement a
>> proper adapter-specific irqdomain and used a chained irq handler to
>> demux (or have consumers request with IRQF_SHARED in the shared case).
>
> Although modeling this using irqdomains makes sense for the notification
> bit, and would probably suit most adapters, there's the issue of data
> being passed around which doesn't quite fit. "Ok, I have mail... where
> is it?" Did you have something in mind for that?
>
> Frankly, I don't see the notifier chain as being extraneous or
> over-complicated here core-wise or implementation-wise, and unless I
> understand Rob incorrectly, should suit the existing use-cases. Am I
> missing something?
Well, I think notifiers are not liked very much. I don't know that irq
handlers would be the right answer either as these are not h/w events
really and we may not want handlers to run in irq context. I would say
a callback similar to how the dma engine framework works is the right
answer. On the send side, you may want to have completion callbacks as
well.
Rob
^ permalink raw reply
* Re: [PATCH 2/2] spi: Add Qualcomm QUP SPI controller support
From: Ivan T. Ivanov @ 2014-02-10 20:59 UTC (permalink / raw)
To: Courtney Cavin
Cc: Andy Gross, Mark Brown, Grant Likely, Rob Herring,
linux-spi@vger.kernel.org, linux-arm-msm@vger.kernel.org,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
Alok Chauhan, Gilad Avidov, Kiran Gunda, Sagar Dharia
In-Reply-To: <20140210202926.GV1706@sonymobile.com>
Hi,
On Mon, 2014-02-10 at 12:29 -0800, Courtney Cavin wrote:
> On Mon, Feb 10, 2014 at 08:41:44PM +0100, Ivan T. Ivanov wrote:
> >
> > Hi,
> >
> > On Mon, 2014-02-10 at 11:47 -0600, Andy Gross wrote:
> > > On Mon, Feb 10, 2014 at 06:55:02PM +0200, Ivan T. Ivanov wrote:
> > >
> > > [....]
> > >
> > > > > > > Bail here?
> > > > > >
> > > > > > I don't know. What will be the consequences if controller continue to
> > > > > > operate on its default rate?
> > > > > >
> > > > >
> > > > > It is unclear. But if you can't set the rate that is configured or if there is
> > > > > a misconfiguration, it's probably better to exit the probe and catch it here.
> > > >
> > > >
> > > > My preference is to delay clock speed change till first
> > > > SPI transfer. And use wherever transfer itself mandate.
> > > >
> > >
> > > That works. My only concern is that it might be nice to catch a configuration
> > > problem early rather than wait for the SPI transfer to fail continuously.
> >
> > If developer is skilled enough to know which version controller is,
> > (s)he will be able to put the right frequency constrain here :-)
>
> A developer doesn't have to have much skill at all to copy-paste DT
> configurations around and muck with numbers.... I agree with Andy here,
> early validation is a good idea here, at the very least, some sanity
> checks.
>
So, probably first variant with just warning will be good enough?
Regards,
Ivan
> -Courtney
^ 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