* 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
* Re: [PATCH] net: rfkill-regulator: Add devicetree support.
From: Belisko Marek @ 2014-02-10 21:35 UTC (permalink / raw)
To: Mark Rutland
Cc: robh+dt@kernel.org, Pawel Moll, ijc+devicetree@hellion.org.uk,
galak@codeaurora.org, rob@landley.net, linville@tuxdriver.com,
johannes@sipsolutions.net, davem@davemloft.net,
grant.likely@linaro.org, neilb@suse.de, hns@goldelico.com,
devicetree@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-wireless@vger.kernel.org,
netdev@vger.kernel.org
In-Reply-To: <20140210101842.GS25314@e106331-lin.cambridge.arm.com>
On Mon, Feb 10, 2014 at 11:18 AM, Mark Rutland <mark.rutland@arm.com> wrote:
> On Fri, Feb 07, 2014 at 07:48:49PM +0000, Marek Belisko wrote:
>> Signed-off-by: NeilBrown <neilb@suse.de>
>> Signed-off-by: Marek Belisko <marek@goldelico.com>
>> ---
>> Based on Neil's patch and extend for documentation and bindings include.
>>
>> .../bindings/net/rfkill/rfkill-relugator.txt | 28 ++++++++++++++++
>> include/dt-bindings/net/rfkill-regulator.h | 23 +++++++++++++
>> net/rfkill/rfkill-regulator.c | 38 ++++++++++++++++++++++
>> 3 files changed, 89 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/net/rfkill/rfkill-relugator.txt
>> create mode 100644 include/dt-bindings/net/rfkill-regulator.h
>>
>> diff --git a/Documentation/devicetree/bindings/net/rfkill/rfkill-relugator.txt b/Documentation/devicetree/bindings/net/rfkill/rfkill-relugator.txt
>> new file mode 100644
>> index 0000000..cdb7dd7
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/net/rfkill/rfkill-relugator.txt
>> @@ -0,0 +1,28 @@
>> +Regulator consumer for rfkill devices
>
> What exactly is an "rfkill" device? How is it used? How does it relate
> to other devices in the DT?
>
> To me, this looks like a leak of a Linux abstraction.
>
>> +
>> +Required properties:
>> +- compatible : Must be "rfkill-regulator".
>> +- label : Name of rfkill device.
>
> What's this for? Why does this need a label in the DT? Surely this can
> be implied by the relationship to a particular radio device?
This label is used by rfkill (converted to pdata->name in probe
function) and used for displaying.
Maybe label isn't correct name for that purpose.
>
>> +- type : Type of rfkill device.
>> +
>> +Possible values (defined in include/dt-bindings/net/rfkill-regulator.h):
>> + RFKILL_TYPE_ALL
>> + RFKILL_TYPE_WLAN
>> + RFKILL_TYPE_BLUETOOTH
>> + RFKILL_TYPE_UWB
>> + RFKILL_TYPE_WIMAX
>> + RFKILL_TYPE_WWAN
>> + RFKILL_TYPE_GPS
>> + RFKILL_TYPE_FM
>> + RFKILL_TYPE_NFC
>
> What do these mean? Why can these not be implied by a relationship to
> any devices of these particular types?
I did platform data -> DT mapping 1 : 1. Maybe we don't need to export
those to separate
include file and only use raw number instead.
>
>> +
>> +- vrfkill-supply - regulator device.
>
> Why isn't this described on the radio revice node? It's a supply to the
> radio, not to the rfkill concept.
rfkill-regulator in probe check for vrfkill regulator so I've added it
to description as without that rfkill-regulator doesn't make sense.
>
>> +
>> +Example:
>> + gps-rfkill {
>> + compatible = "rfkill-regulator";
>> + label = "GPS";
>> + type = <RFKILL_TYPE_GPS>;
>> + vrfkill-supply = <®>;
>> + };
>
> Why is this not bound to the particular GPS device in some way?
We can do something like:
gps-device {
compatible = "my-desired-gps";
<other device properties>
rfkill = <&gps-rfkill>;
};
>
> What if I have more than one of any of the types of device this
> supports, which device is this expected to control?
rfkill-regulator is linked with regulator so if you have another
device it is probably controlled
with another regulator.
>
> Why is it described as a separate device in the device tree at all?
>
> I do not think this binding is the right way to describe this.
Some time ago was posted rfkill-gpio DT binding conversion and was
using the nearly the same bindings as
we propose and there was no issue with that.
>
> Thanks,
> Mark.
>
>> +
>> diff --git a/include/dt-bindings/net/rfkill-regulator.h b/include/dt-bindings/net/rfkill-regulator.h
>> new file mode 100644
>> index 0000000..ae32273
>> --- /dev/null
>> +++ b/include/dt-bindings/net/rfkill-regulator.h
>> @@ -0,0 +1,23 @@
>> +/*
>> + * This header provides macros for rfkill-regulator bindings.
>> + *
>> + * Copyright (C) 2014 Marek Belisko <marek@goldelico.com>
>> + *
>> + * GPLv2 only
>> + */
>> +
>> +#ifndef __DT_BINDINGS_RFKILL_REGULATOR_H__
>> +#define __DT_BINDINGS_RFKILL_REGULATOR_H__
>> +
>> +
>> +#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)
>> +
>> +#endif /* __DT_BINDINGS_RFKILL_REGULATOR_H__ */
>> diff --git a/net/rfkill/rfkill-regulator.c b/net/rfkill/rfkill-regulator.c
>> index cf5b145..a04aff8 100644
>> --- a/net/rfkill/rfkill-regulator.c
>> +++ b/net/rfkill/rfkill-regulator.c
>> @@ -19,6 +19,7 @@
>> #include <linux/regulator/consumer.h>
>> #include <linux/rfkill.h>
>> #include <linux/rfkill-regulator.h>
>> +#include <linux/of_platform.h>
>>
>> struct rfkill_regulator_data {
>> struct rfkill *rf_kill;
>> @@ -57,6 +58,31 @@ static struct rfkill_ops rfkill_regulator_ops = {
>> .set_block = rfkill_regulator_set_block,
>> };
>>
>> +#ifdef CONFIG_OF
>> +static struct rfkill_regulator_platform_data *
>> +rfkill_regulator_parse_pdata(struct device *dev)
>> +{
>> + struct rfkill_regulator_platform_data *pdata;
>> + struct device_node *np = dev->of_node;
>> + u32 num;
>> + if (!np)
>> + return NULL;
>> + pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
>> + if (!pdata)
>> + return NULL;
>> + if (of_property_read_u32(np, "type", &num) == 0)
>> + pdata->type = num;
>> + of_property_read_string(np, "label", &pdata->name);
>> + return pdata;
>> +}
>> +#else
>> +static inline struct rfkill_regulator_platform_data *
>> +rfkill_regulator_parse_pdata(struct device *dev)
>> +{
>> + return NULL;
>> +}
>> +#endif
>> +
>> static int rfkill_regulator_probe(struct platform_device *pdev)
>> {
>> struct rfkill_regulator_platform_data *pdata = pdev->dev.platform_data;
>> @@ -65,6 +91,9 @@ static int rfkill_regulator_probe(struct platform_device *pdev)
>> struct rfkill *rf_kill;
>> int ret = 0;
>>
>> + if (!pdata)
>> + pdata = rfkill_regulator_parse_pdata(&pdev->dev);
>> +
>> if (pdata == NULL) {
>> dev_err(&pdev->dev, "no platform data\n");
>> return -ENODEV;
>> @@ -137,12 +166,21 @@ static int rfkill_regulator_remove(struct platform_device *pdev)
>> return 0;
>> }
>>
>> +#ifdef CONFIG_OF
>> +static const struct of_device_id rfkill_regulator_match[] = {
>> + {.compatible = "rfkill-regulator"},
>> + {}
>> +};
>> +MODULE_DEVICE_TABLE(of, rfkill_regulator_match);
>> +#endif
>> +
>> static struct platform_driver rfkill_regulator_driver = {
>> .probe = rfkill_regulator_probe,
>> .remove = rfkill_regulator_remove,
>> .driver = {
>> .name = "rfkill-regulator",
>> .owner = THIS_MODULE,
>> + .of_match_table = of_match_ptr(rfkill_regulator_match),
>> },
>> };
>>
>> --
>> 1.8.3.2
>>
>>
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: Mark Brown @ 2014-02-10 21:40 UTC (permalink / raw)
To: Ivan T. Ivanov
Cc: Courtney Cavin, Andy Gross, Grant Likely, Rob Herring,
linux-spi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Alok Chauhan,
Gilad Avidov, Kiran Gunda, Sagar Dharia
In-Reply-To: <1392065994.32668.1.camel@violet>
[-- Attachment #1: Type: text/plain, Size: 624 bytes --]
On Mon, Feb 10, 2014 at 10:59:54PM +0200, Ivan T. Ivanov wrote:
> On Mon, 2014-02-10 at 12:29 -0800, Courtney Cavin wrote:
> > 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?
I'm not sure it actually adds anything meaningful here - if the error
reporting isn't clear enough on use then that's probably an issue anyway
and we may never even use the default.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH v2 4/5] ARM: init: add support for reserved memory defined by device tree
From: Grant Likely @ 2014-02-10 21:59 UTC (permalink / raw)
To: Marek Szyprowski, linux-kernel, linux-arm-kernel, linaro-mm-sig,
devicetree, linux-doc
Cc: Kyungmin Park, Benjamin Herrenschmidt, Arnd Bergmann,
Michal Nazarewicz, Tomasz Figa, Sascha Hauer, Laura Abbott,
Rob Herring, Olof Johansson, Pawel Moll, Mark Rutland,
Stephen Warren, Ian Campbell, Tomasz Figa, Kumar Gala,
Nishanth Peethambaran, Marc, Josh Cartwright
In-Reply-To: <52F38D75.4030704@samsung.com>
On Thu, 06 Feb 2014 14:26:13 +0100, Marek Szyprowski <m.szyprowski@samsung.com> wrote:
> Hello,
>
> On 2014-02-05 11:15, Grant Likely wrote:
> > On Tue, 04 Feb 2014 13:09:32 +0100, Marek Szyprowski <m.szyprowski@samsung.com> wrote:
> > > Enable reserved memory initialization from device tree.
> > >
> > > Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> > > Cc: Laura Abbott <lauraa@codeaurora.org>
> > > Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> > > ---
> > > arch/arm/mm/init.c | 3 +++
> > > 1 file changed, 3 insertions(+)
> > >
> > > diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
> > > index 804d61566a53..ebafdb479410 100644
> > > --- a/arch/arm/mm/init.c
> > > +++ b/arch/arm/mm/init.c
> > > @@ -17,6 +17,7 @@
> > > #include <linux/nodemask.h>
> > > #include <linux/initrd.h>
> > > #include <linux/of_fdt.h>
> > > +#include <linux/of_reserved_mem.h>
> > > #include <linux/highmem.h>
> > > #include <linux/gfp.h>
> > > #include <linux/memblock.h>
> > > @@ -323,6 +324,8 @@ void __init arm_memblock_init(struct meminfo *mi,
> > > if (mdesc->reserve)
> > > mdesc->reserve();
> > >
> > > + early_init_dt_scan_reserved_mem();
> > > +
> >
> > The new binding is being made fundamental. If the reserved-memory node
> > is present, then it needs to be honored, even if the kernel doesn't know
> > how to use the regions. Therefore, This needs to be unconditional for
> > all architectures. The hook should be called in early_init_dt_scan()
> > (drivers/of/fdt.c) immediately after the early_init_dt_scan_memory()
> > hook.
>
> In theory this will be the best solution, but it practice there is a
> problem. early_init_dt_scan() is called as the first function from kernel
> booting code. That time there is no memory yet added to the system, so it
> would be really hard to reserve anything. Memory nodes are being added
> later either with memblock_add() or by some other arch specific way.
Hmmm, depends on the architecture. On ARM the memory is loaded into the
meminfo structure first, and it isn't until arm_memblock_init() that
memblock_add() gets called on all the regions. Some architectures do the
memblock_add() directly from early_init_dt_add_memory_arch() function.
The default early_init_dt_add_memory_arch() in drivers/of/fdt.c is
overridden by ARM and a number of other architectures. However...
> Finally, once all memory has been added to the system we can parse and
> reserve all regions defined in the device tree. This really requires
> creating another function which will be called by arch specific code.
...Or it means getting rid of meminfo entirely so that memblock is
available earlier. Laura Abbott has just posted v2 of her series to do
exactly that. If you base on that then you should be able to do exactly
what I suggested.
g.
^ permalink raw reply
* [PATCH] of/gpio: Define OF_GPIO_OPEN_DRAIN flag for Open Drain outputs.
From: David Daney @ 2014-02-10 22:05 UTC (permalink / raw)
To: Grant Likely, Rob Herring, devicetree, Linus Walleij,
Alexandre Courbot, linux-gpio
Cc: linux-kernel, David Daney
From: David Daney <david.daney@cavium.com>
When we have a GPIO pin connected to an open-drain network, we want a
standard way of specifying this in the device tree. So we choose bit
1 of the flag field to indicate open drain.
A typical use case would be something like:
enum of_gpio_flags f;
.
.
.
reset_gpio = of_get_named_gpio_flags(node, "reset", 0, &f);
.
.
.
ret = gpio_request_one(reset_gpio,
(f & OF_GPIO_OPEN_DRAIN) ? GPIOF_OPEN_DRAIN : 0,
"reset");
.
.
.
gpio_direction_output(reset_gpio, 1);
gpio_set_value(reset_gpio, 0);
msleep(20);
gpio_set_value(reset_gpio, 1);
.
.
.
Signed-off-by: David Daney <david.daney@cavium.com>
---
include/linux/of_gpio.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/linux/of_gpio.h b/include/linux/of_gpio.h
index f14123a..0e374774 100644
--- a/include/linux/of_gpio.h
+++ b/include/linux/of_gpio.h
@@ -30,6 +30,7 @@ struct device_node;
*/
enum of_gpio_flags {
OF_GPIO_ACTIVE_LOW = 0x1,
+ OF_GPIO_OPEN_DRAIN = 0x2,
};
#ifdef CONFIG_OF_GPIO
--
1.7.11.7
^ permalink raw reply related
* Re: [PATCH] DT: net: document Ethernet bindings in one place
From: Grant Likely @ 2014-02-10 22:05 UTC (permalink / raw)
To: Sergei Shtylyov, Florian Fainelli, Rob Herring
Cc: netdev, Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell,
Kumar Gala, devicetree@vger.kernel.org, Rob Landley,
linux-doc@vger.kernel.org
In-Reply-To: <52F396DE.8010306@cogentembedded.com>
On Thu, 06 Feb 2014 18:06:22 +0400, Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> wrote:
> Hello.
>
> On 06-02-2014 13:43, Grant Likely wrote:
>
> >>>>>>>>>>> I'm afraid that's too late, it has spread very far, so that
> >>>>>>>>>>> of_get_phy_mode() handles that property, not "phy-connection-type".
>
> >>>>>>>>>> Uggg, I guess this is a case of a defacto standard then if the kernel
> >>>>>>>>>> doesn't even support it.
>
> >>>>>>>>> Maybe I forgot to CC you on patch sent to Grant only, I sent a patch a
> >>>>>>>>> while ago for of_get_phy_mode() to look for both "phy-mode" and
> >>>>>>>>> "phy-connection-type" since the former has been a Linux invention, but
> >>>>>>>>> the latter is ePAPR specified.
>
> >>>>>>>> Here is a link to the actual patch in question, not sure which tree
> >>>>>>>> Grant applied it to though:
>
> >>>>>>>> http://lkml.indiana.edu/hypermail/linux/kernel/1311.2/00048.html
>
> >>>>>>> It's not the patch mail, it's Grant's "applied" reply, patch is mangled in
> >>>>>>> this reply, and I couldn't follow the thread. Here's the actual patch mail:
>
> >>>>>>> http://marc.info/?l=devicetree&m=138449662807254
>
> >>>>>> Florian, I didn't find this patch in Grant's official tree, so maybe you
> >>>>>> should ask him where is the patch already?
>
> >>>>> Sorry, I accidentally dropped it. It will be in the next merge window.
>
> >>>> Already saw it, thanks. Would that it was in 3.14 instead of course, so
> >>>> that I could use "phy-connection-type" in my binding...
>
> >>> Is 3.14 broken because of missing the patch? If so I'll get it merged as
> >> > a bug fix.
>
> >> No, it's not. I could have used "phy-connection-type" in my binding
> >> destined for 3.15 and document it as a preferred property as well.
>
> > You still can. We just need to make sure that your patch is applied on
>
> Patches.
>
> > top of the phy-connection-type patch.
>
> I'm not sure this trick is possible if the patches are merged via the
> different trees...
There are two ways to do it. A) by having a common merge commit
containing that patch and merged into both branches, or B) just merging
the patch in the same tree.
Normally I'd suggest B), but I've already picked up the patch and I try
very hard not to rebase my commit tree. However, since the branch is
stable, you can ask for my branch to be merged into the net branch
before applying the dependant patches. The relevant commit id is
cf4c9eb5a4, and it is in my devicetree/next branch on
git://git.secretlab.ca/git/linux
g.
^ permalink raw reply
* Re: [PATCH v2 1/3] net: stmmac:sti: Add STi SOC glue driver.
From: David Miller @ 2014-02-10 22:40 UTC (permalink / raw)
To: srinivas.kandagatla
Cc: netdev, robh+dt, pawel.moll, mark.rutland, ijc+devicetree, galak,
rob, linux, stuart.menefy, peppe.cavallaro, devicetree, linux-doc,
linux-kernel, linux-arm-kernel, kernel
In-Reply-To: <1391770525-24349-1-git-send-email-srinivas.kandagatla@st.com>
From: <srinivas.kandagatla@st.com>
Date: Fri, 7 Feb 2014 10:55:25 +0000
> + if (dwmac->interface == PHY_INTERFACE_MODE_MII ||
> + dwmac->interface == PHY_INTERFACE_MODE_GMII) {
This is not indented correctly, the first character on the second line should
line up exactly at the column after the openning parenthesis on the first
line.
The objective is not to indent using only TAB characters, which you
are doing here.
Rather, the objective is to use the appropriate number of TAB _and_
space characters necessary to reach the proper column.
> + const char *rs;
> + err = of_property_read_string(np, "st,tx-retime-src", &rs);
Please add an empty line after the local variable declaration.
> + if (!strcasecmp(rs, "clk_125"))
> + dwmac->is_tx_retime_src_clk_125 = true;
> +
> + }
That empty line is superfluous, please delete it.
^ permalink raw reply
* Re: [PATCH v6 01/19] clocksource: orion: Use atomic access for shared registers
From: Daniel Lezcano @ 2014-02-11 0:06 UTC (permalink / raw)
To: Ezequiel Garcia, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-watchdog-u79uwXL29TY76Z2rM5mHXA, Wim Van Sebroeck,
Jason Cooper
Cc: Thomas Petazzoni, Gregory Clement, Lior Amsalem,
Sebastian Hesselbarth, Andrew Lunn
In-Reply-To: <1391707226-18258-2-git-send-email-ezequiel.garcia-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
On 02/06/2014 06:20 PM, Ezequiel Garcia wrote:
> Replace the driver-specific thread-safe shared register API
> by the recently introduced atomic_io_clear_set().
>
> Cc: Daniel Lezcano <daniel.lezcano-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> Tested-by: Sebastian Hesselbarth <sebastian.hesselbarth-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Tested-by: Willy Tarreau <w@1wt.eu>
> Acked-by: Jason Cooper <jason-NLaQJdtUoK4Be96aLqz0jA@public.gmane.org>
> Signed-off-by: Ezequiel Garcia <ezequiel.garcia-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
The patch looks good for me.
Acked-by: Daniel Lezcano <daniel.lezcano-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
--
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: [RFC 1/6] mailbox: add core framework
From: Courtney Cavin @ 2014-02-11 0:23 UTC (permalink / raw)
To: Rob Herring
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: <CAL_JsqK0YoVu0BfKSUfBQGoriCa4z-teXUQe6RPpjM2KKpeMAw@mail.gmail.com>
On Mon, Feb 10, 2014 at 09:45:07PM +0100, Rob Herring wrote:
> 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.
While I'm not sure the dislike of notifiers entirely justifies not using
them here, where they seem to make sense, I can understand that they
might not fully implement what we need to expose.
Regarding handlers running in IRQ context: currently the API is designed
to do just that. From the use-cases I've found, most message handlers
simply queue something to happen at a later point. This is logical, as
the callback will be async, so you'll need to swap contexts or add locks
in your consumer anyway.
The dma engine is large and confused, so I'm not sure entirely which
part you are refering to. I've looked at having async completion going
both ways, but what I see every time is code complication in both the
adapter and in the consumers in the simple use-case. It doesn't really
make sense to make an API which makes things so generic that it becomes
hard to use. What I tried to follow here when designing the API was
what I saw in the actual implementations, not what was future-proof:
- Message receive callbacks may be called from IRQ context
- Message send implementations may sleep
I think that these allowances enable the simple use-case to be very easy
to write, and the more complex use-cases still possible--albiet
sometimes at a higher level.
What I can do is try to alleviate implementation efforts of future
requirements--as honestly, we can't really say exactly what they are--by
turning the messages into structs themselves, so at a later point flags,
ack callbacks, and rainbows can be added. I can then stop using
notifiers, and re-invent that functionality with a mbox_ prefix.
Comments?
-Courtney
^ permalink raw reply
* Re: [PATCH v2 3/4] video: mmp: add devm_mmp_get_path_by_phandle for DT
From: Zhou Zhu @ 2014-02-11 1:03 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: linux-fbdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Jean-Christophe Plagniol-Villard, Haojian Zhuang, Sascha Hauer,
Jingoo Han, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Chao Xie, Guoqing Li
In-Reply-To: <52F8C6F6.5000200-l0cyMroinI0@public.gmane.org>
On 02/10/2014 08:32 PM, Tomi Valkeinen wrote:
> On 14/01/14 13:16, Zhou Zhu wrote:
>> add devm_mmp_get_path_by_phandle to replace mmp_get_path
>> for DT usage
>>
>> Signed-off-by: Zhou Zhu <zzhu3-eYqpPyKDWXRBDgjK7y7TUQ@public.gmane.org>
>> ---
>> drivers/video/mmp/core.c | 35 +++++++++++++++++++++++++++++++++++
>> include/video/mmp_disp.h | 2 ++
>> 2 files changed, 37 insertions(+)
>>
>> diff --git a/drivers/video/mmp/core.c b/drivers/video/mmp/core.c
>> index b563b92..0538458 100644
>> --- a/drivers/video/mmp/core.c
>> +++ b/drivers/video/mmp/core.c
>> @@ -23,6 +23,7 @@
>> #include <linux/slab.h>
>> #include <linux/dma-mapping.h>
>> #include <linux/export.h>
>> +#include <linux/of.h>
>> #include <video/mmp_disp.h>
>>
>> static struct mmp_overlay *path_get_overlay(struct mmp_path *path,
>> @@ -156,6 +157,40 @@ struct mmp_path *mmp_get_path(const char *name)
>> EXPORT_SYMBOL_GPL(mmp_get_path);
>>
>> /*
>> + * devm_mmp_get_path_by_phandle - get path by phandle
>> + * @dev: device that want to get path
>> + * @phandle: name of phandle in device node that want to get path
>> + *
>> + * this function gets path according to node pointed by phandle
>> + * return NULL if no matching path
>> + */
>> +struct mmp_path *devm_mmp_get_path_by_phandle(struct device *dev,
>> + const char *phandle)
>> +{
>> + struct mmp_path *path;
>> + struct device_node *node;
>> +
>> + if (!dev->of_node) {
>> + dev_err(dev, "device does not have a device node entry\n");
>> + return NULL;
>> + }
>> +
>> + node = of_parse_phandle(dev->of_node, phandle, 0);
>> + if (!node) {
>> + dev_err(dev, "failed to get %s phandle in %s node\n", phandle,
>> + dev->of_node->name);
>> + return NULL;
>> + }
>> +
>> + path = mmp_get_path(node->name);
>> +
>> + of_node_put(node);
>> +
>> + return path;
>> +}
>> +EXPORT_SYMBOL_GPL(devm_mmp_get_path_by_phandle);
>
> Why is this function "devm_"? devm_ functions are supposed to
> automatically free resources when the device is removed, I don't see
> anything like that here.
Thank you for your review, I will remove "devm_" in next version.
>
> Tomi
>
>
--
Thanks, -Zhou
--
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: Kevin Hilman @ 2014-02-11 1:07 UTC (permalink / raw)
To: Nishanth Menon
Cc: Roger Quadros, linux-omap, linux-usb, Balbi, Felipe, linux-next,
devicetree@vger.kernel.org, tony@atomide.com
In-Reply-To: <52F9297A.1080206@ti.com>
Nishanth Menon <nm@ti.com> writes:
> 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", },
This is what I was getting at: an understanding of what caused the
failue in the first place.
> 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.
Right, so I agree that it makes sense to remove a compatible string
where there is no compatability, but a couple other things should happen
here.
1) changelog should describe why this compatible string is in the omap
dtsi files in first place.
2) investigation into the patch that introduced this change to double
check it's not introducing other breakage as well.
Kevin
^ permalink raw reply
* Re: [PATCH v6 1/2] iio:as3935: Add DT binding docs for AS3935 driver
From: Matt Ranostay @ 2014-02-11 1:26 UTC (permalink / raw)
To: Mark Rutland
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-iio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
matt.porter-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org,
pantelis.antoniou-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
In-Reply-To: <20140210105807.GU25314-NuALmloUBlrZROr8t4l/smS4ubULX0JqMm0uRHvK7Nw@public.gmane.org>
On Mon, Feb 10, 2014 at 2:58 AM, Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org> wrote:
> On Mon, Feb 10, 2014 at 04:27:30AM +0000, Matt Ranostay wrote:
>> Document compatible string, required and optional DT properties for
>> AS3935 chipset driver.
>>
>> Signed-off-by: Matt Ranostay <mranostay-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>> ---
>> .../devicetree/bindings/iio/proximity/as3935.txt | 27 ++++++++++++++++++++++
>> .../devicetree/bindings/vendor-prefixes.txt | 1 +
>> 2 files changed, 28 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/iio/proximity/as3935.txt
>>
>> diff --git a/Documentation/devicetree/bindings/iio/proximity/as3935.txt b/Documentation/devicetree/bindings/iio/proximity/as3935.txt
>> new file mode 100644
>> index 0000000..0453254
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/iio/proximity/as3935.txt
>> @@ -0,0 +1,27 @@
>> +Austrian Microsystems AS3935 Franklin lightning sensor device driver
>> +
>> +Required properties:
>> + - compatible: must be "ams,as3935"
>> + - reg: SPI chip select number for the device
>> + - spi-cpha: SPI Mode 1. Refer to spi/spi-bus.txt for generic SPI
>> + slave node bindings.
>> + - interrupt-parent : should be the phandle for the interrupt controller
>> + - interrupts : interrupt mapping
>
> Nit: Please don't use the term "interrupt mapping", as it's undefined
> and clashes with the "interrupt-map" property on an interrupt nexus.
> There are a lot of bindings using it, and it would be nice to get them
> fixed up too.
>
> As interrupts can be described in a couple of ways it probably doesn't
> make sense to state the exact format here, but could this be something
> like the following instead:
>
> - interrupts: the sole interrupt generated by the device.
>
Noted.
>> +
>> + Refer to interrupt-controller/interrupts.txt for generic
>> + interrupt client node bindings.
>> +
>> +Optional properties:
>> + - ams,tune-cap: Calibration tuning capacitor stepping value 0 - 120pF.
>> + This will require using the calibration data from the manufacturer.
>
> I think "tune-cap" is a little terse. Also "cap" is used as an
> abbreviation for "capability" elsewhere, and it would be nice to make
> it clear that in this case it means "capacitor".
>
> Could this be "ams,tuning-capacitor-pf" instead? That would make it
> clear at a glance what the value is and the units (though people would
> still ahve to refer to documentation to figure out precisely what this
> means).
>
Yeah that would be a lot more clear. Noted for next version.
>> +
>> +Example:
>> +
>> +as3935@0 {
>> + compatible = "ams,as3935";
>> + reg = <0>;
>> + spi-cpha;
>> + interrupt-parent = <&gpio1>;
>> + interrupts = <16 1>;
>> + ams,tune-cap = <80>;
>> +};
>> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
>> index e9d19e2..03e50ff 100644
>> --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
>> +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
>> @@ -11,6 +11,7 @@ ak Asahi Kasei Corp.
>> allwinner Allwinner Technology Co., Ltd.
>> altr Altera Corp.
>> amcc Applied Micro Circuits Corporation (APM, formally AMCC)
>> +ams AMS AG
>
> The vendor-prefix addition looks fine to me.
>
> Thanks,
> Mark.
^ permalink raw reply
* [PATCH] bus: imx-weim: support weim-cs-gpr for imx6q-weim
From: Shawn Guo @ 2014-02-11 2:50 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Huang Shijie, Philippe De Muyter, Shawn Guo, kernel, devicetree
For imx6q-weim type of device, there might a WEIM CS space configuration
register in General Purpose Register controller, e.g. IOMUXC_GPR1 on
i.MX6Q.
Depending on which configuration of the following 4 is chosen for given
system, IOMUXC_GPR1[11:0] should be set up as 0x5, 0x1b, 0x4b or 0x249
correspondingly.
CS0(128M) CS1(0M) CS2(0M) CS3(0M)
CS0(64M) CS1(64M) CS2(0M) CS3(0M)
CS0(64M) CS1(32M) CS2(32M) CS3(0M)
CS0(32M) CS1(32M) CS2(32M) CS3(32M)
The patch creates a table in the driver for above configurations, and
detects which one is being used for the booting system by looking at
'ranges' property of WEIM node. Thus the WEIM CS GPR can be set up
automatically at boot time.
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
---
Documentation/devicetree/bindings/bus/imx-weim.txt | 6 ++
drivers/bus/imx-weim.c | 83 ++++++++++++++++++++
2 files changed, 89 insertions(+)
diff --git a/Documentation/devicetree/bindings/bus/imx-weim.txt b/Documentation/devicetree/bindings/bus/imx-weim.txt
index 0fd76c4..d114460f 100644
--- a/Documentation/devicetree/bindings/bus/imx-weim.txt
+++ b/Documentation/devicetree/bindings/bus/imx-weim.txt
@@ -19,6 +19,12 @@ Required properties:
<cs-number> 0 <physical address of mapping> <size>
+Optional properties:
+
+ - fsl,weim-cs-gpr: Should be the phandle to the General Purpose Register
+ controller that contains WEIM CS GPR register, e.g.
+ IOMUXC_GPR1 on i.MX6Q.
+
Timing property for child nodes. It is mandatory, not optional.
- fsl,weim-cs-timing: The timing array, contains timing values for the
diff --git a/drivers/bus/imx-weim.c b/drivers/bus/imx-weim.c
index 3ef58c8..9c8a522 100644
--- a/drivers/bus/imx-weim.c
+++ b/drivers/bus/imx-weim.c
@@ -11,6 +11,9 @@
#include <linux/clk.h>
#include <linux/io.h>
#include <linux/of_device.h>
+#include <linux/mfd/syscon.h>
+#include <linux/mfd/syscon/imx6q-iomuxc-gpr.h>
+#include <linux/regmap.h>
struct imx_weim_devtype {
unsigned int cs_count;
@@ -56,6 +59,83 @@ static const struct of_device_id weim_id_table[] = {
};
MODULE_DEVICE_TABLE(of, weim_id_table);
+struct imx6q_weim_gpr {
+ u32 cssize[4];
+ u32 gprval;
+};
+
+static const struct imx6q_weim_gpr imx6q_weim_gpr_data[] __initconst = {
+ {
+ /* CS0(128M) CS1(0M) CS2(0M) CS3(0M) */
+ .cssize = { 128, 0, 0, 0 },
+ .gprval = 0x5,
+ }, {
+ /* CS0(64M) CS1(64M) CS2(0M) CS3(0M) */
+ .cssize = { 64, 64, 0, 0 },
+ .gprval = 0x1b,
+ }, {
+ /* CS0(64M) CS1(32M) CS2(32M) CS3(0M) */
+ .cssize = { 64, 32, 32, 0 },
+ .gprval = 0x4b,
+ }, {
+ /* CS0(64M) CS1(32M) CS2(32M) CS3(0M) */
+ .cssize = { 32, 32, 32, 32 },
+ .gprval = 0x249,
+ },
+};
+
+static int __init imx6q_weim_gpr_setup(struct platform_device *pdev)
+{
+ struct device_node *np = pdev->dev.of_node;
+ const struct property *prop;
+ struct regmap *gpr;
+ u32 cssize[4] = { 0, 0, 0, 0 };
+ int len;
+ int ret;
+ int i;
+
+ gpr = syscon_regmap_lookup_by_phandle(np, "fsl,weim-cs-gpr");
+ if (IS_ERR(gpr)) {
+ dev_dbg(&pdev->dev, "No weim-cs-gpr to set up\n");
+ return 0;
+ }
+
+ prop = of_find_property(np, "ranges", &len);
+ if (prop == NULL)
+ return -ENOENT;
+ if (len % (sizeof(u32) * 4))
+ return -EINVAL;
+
+ for (i = 0; i < len / (sizeof(u32) * 4); i++) {
+ int cs;
+ /* read cs index */
+ ret = of_property_read_u32_index(np, "ranges", i * 4, &cs);
+ if (ret)
+ return ret;
+ /* read cs size */
+ ret = of_property_read_u32_index(np, "ranges", i * 4 + 3,
+ &cssize[cs]);
+ if (ret)
+ return ret;
+ /* turn to MB */
+ cssize[cs] >>= 20;
+ }
+
+ for (i = 0; i < ARRAY_SIZE(imx6q_weim_gpr_data); i++) {
+ ret = memcmp(cssize, imx6q_weim_gpr_data[i].cssize,
+ sizeof(cssize));
+ if (ret == 0) {
+ /* Find it. Set up IOMUXC_GPR1[11:0] with the gprval. */
+ regmap_update_bits(gpr, IOMUXC_GPR1, 0xfff,
+ imx6q_weim_gpr_data[i].gprval);
+ return 0;
+ }
+ }
+
+ dev_err(&pdev->dev, "Invalid 'ranges' configuration\n");
+ return -EINVAL;
+}
+
/* Parse and set the timing for this device. */
static int __init weim_timing_setup(struct device_node *np, void __iomem *base,
const struct imx_weim_devtype *devtype)
@@ -92,6 +172,9 @@ static int __init weim_parse_dt(struct platform_device *pdev,
struct device_node *child;
int ret;
+ if (of_device_is_compatible(pdev->dev.of_node, "fsl,imx6q-weim"))
+ imx6q_weim_gpr_setup(pdev);
+
for_each_child_of_node(pdev->dev.of_node, child) {
if (!child->name)
continue;
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH v2 4/4] video: mmp: add device tree support
From: Zhou Zhu @ 2014-02-11 3:27 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: linux-fbdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Jean-Christophe Plagniol-Villard, Haojian Zhuang, Sascha Hauer,
Jingoo Han, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Chao Xie, Guoqing Li
In-Reply-To: <52F8C96F.7050107-l0cyMroinI0@public.gmane.org>
On 02/10/2014 08:43 PM, Tomi Valkeinen wrote:
> On 14/01/14 13:16, Zhou Zhu wrote:
>> add device tree support for mmp fb/controller
>> the description of DT config is at
>> Documentation/devicetree/bindings/fb/mmp-disp.txt
>>
>> Signed-off-by: Zhou Zhu <zzhu3-eYqpPyKDWXRBDgjK7y7TUQ@public.gmane.org>
>> ---
>> Documentation/devicetree/bindings/fb/mmp-disp.txt | 60 ++++++++
>> drivers/video/mmp/fb/mmpfb.c | 73 ++++++----
>> drivers/video/mmp/hw/mmp_ctrl.c | 160 ++++++++++++++++-----
>> 3 files changed, 235 insertions(+), 58 deletions(-)
>> create mode 100644 Documentation/devicetree/bindings/fb/mmp-disp.txt
>>
>> diff --git a/Documentation/devicetree/bindings/fb/mmp-disp.txt b/Documentation/devicetree/bindings/fb/mmp-disp.txt
>> new file mode 100644
>> index 0000000..80702f5
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/fb/mmp-disp.txt
>> @@ -0,0 +1,60 @@
>> +* Marvell MMP Display (MMP_DISP)
>> +
>> +To config mmp display, 3 parts are required to be set in dts:
>> +1. mmp fb
>> +Required properties:
>> +- compatible: Should be "marvell,<soc>-fb".
>> +- marvell,path: Should be the path this fb connecting to.
>> +- marvell,overlay-id: Should be the id of overlay this fb is on.
>> +- marvell,dmafetch-id: Should be the dma fetch id this fb using.
>> +- marvell,default-pixfmt: Should be the default pixel format when this fb is
>> +turned on.
>> +
>> +2. mmp controller
>> +Required properties:
>> +- compatible: Should be "marvell,<soc>-disp".
>> +- reg: Should be address and length of the register set for this controller.
>> +- interrupts: Should be interrupt of this controller.
>> +
>> +Required sub-node:
>> +- path:
>> +Required properties in this sub-node:
>> +-- marvell,overlay_num: Should be number of overlay this path has.
>
> If that one tells how many overlays there are, maybe "num_overlays"
> would be better.
I will update it in next version.
>
>> +-- marvell,output-type: Should be output-type settings
>> +-- marvell,path-config: Should be path-config settings
>> +-- marvell,link-config: Should be link-config settings
>> +-- marvell,rbswap: Should be rbswap settings
>
> If these terms (output-type, path-config, ...) are straight from the HW
> manual, then fine. But if they are not clear, or are driver specific,
> the values these can have should be documented here.
Yes, it's straight from HW manual.
>
>> +
>> +3. panel
>> +Required properties:
>> +- marvell,path: Should be path that this panel connected to.
>> +- other properties each panel has.
>> +
>> +Examples:
>> +
>> +fb: mmp-fb {
>> + compatible = "marvell,pxa988-fb";
>> + marvell,path = <&path1>;
>> + marvell,overlay-id = <0>;
>> + marvell,dmafetch-id = <1>;
>> + marvell,default-pixfmt = <0x108>;
>> +};
>> +
>> +disp: mmp-disp@d420b000 {
>> + compatible = "marvell,pxa988-disp";
>> + reg = <0xd420b000 0x1fc>;
>> + interrupts = <0 41 0x4>;
>> + path1: mmp-pnpath {
>> + marvell,overlay-num = <2>;
>> + marvell,output-type = <0>;
>> + marvell,path-config = <0x20000000>;
>> + marvell,link-config = <0x60000001>;
>> + marvell,rbswap = <0>;
>> + };
>> +};
>> +
>> +panel: <panel-name> {
>
> How is the panel linked to all this? The nodes above do not refer to the
> panel.
We are making panel refer to path, so when panel dev probe, it could
register to related path.
The reason we not link from path to panel is our customer sometimes
asked us to use same image pack (include dts) for different panel types
in product. We could only add all these panels in dts and detect panel
dynamically when boot. So moving panel out and making path not link to
panel but panel link to path would be more straight forward.
>
>> + ...
>> + marvell,path = <&path1>;
>> + ...
>> +};
>
> It's a bit difficult to say much about this, as I have no knowledge
> about mmp.
>
> But I don't quite understand what the pxa988-fb is. Is that some kind of
> virtual device, only used to set up fbdev side? And pxa988-disp is the
> actual hardware device?
>
> If so, I don't really think pxa988-fb should exist in the DT data at
> all, as it's not a hardware device.
Yes, fb is a virtual device for fbdev side.
In our platforms we may use more than one fb for different paths/output
panel or multi overlays on same path for composition. So we need to
configure fb settings like which path/overlay/dmafetch it connected to
for one or more fbdev.
Besides, some more configures like yres_virtual size or fixed fb mem
reserved rather than allocated which depends on platforms are also
needed although these features are not upstreamed yet.
So we put fb as a dt node here for these configures.
>
> Why isn't there just one node for pxa988-disp, which would contain all
> the above information?
We have moved out fb/panel from path due to several reasons:
1. To simplify the node. If moved these nodes in, it might be:
disp {
...
path1 {
...
panel-xxx {
}
panel-yyy {
}
...
fb0 {
}
fb1 {
}
}
path2 {
...
panel-zzz {
}
fb3 {
}
}
}
Also due to child node type might be different, we could even not
directly check child of node. The code would be complex.
2. the path of node would be too long and not so common.
e.g. the panel node in dts would be /soc/axi/disp/path1/panel-xxx, and
in sysfs, node would be /sys/devices/platform/soc/axi/path1/panel-xxx.
It would be complex and not compatible for platforms when our
bootloader/user app doing some operations to these nodes.
If we moved them out, we could move fb/panel out of soc directory so the
node would be /panel-xxx or /fb1 and simpler and compatible.
>
> Tomi
>
>
--
Thanks, -Zhou
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* RE: [PATCH V5 4/8] phy: st-miphy-40lp: Add skeleton driver
From: Mohit KUMAR DCG @ 2014-02-11 3:57 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Pratyush ANAND, devicetree@vger.kernel.org, spear-devel,
linux-kernel@vger.kernel.org, Kishon Vijay Abraham I,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <201402101654.22187.arnd@arndb.de>
Hello Arnd,
> -----Original Message-----
> From: Arnd Bergmann [mailto:arnd@arndb.de]
> Sent: Monday, February 10, 2014 9:24 PM
> To: Mohit KUMAR DCG
> Cc: Pratyush ANAND; Kishon Vijay Abraham I; spear-devel; linux-arm-
> kernel@lists.infradead.org; devicetree@vger.kernel.org; linux-
> kernel@vger.kernel.org
> Subject: Re: [PATCH V5 4/8] phy: st-miphy-40lp: Add skeleton driver
>
> On Monday 10 February 2014, Mohit Kumar wrote:
> > diff --git a/Documentation/devicetree/bindings/phy/st-miphy40lp.txt
> > b/Documentation/devicetree/bindings/phy/st-miphy40lp.txt
> > new file mode 100644
> > index 0000000..d0c7096
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/phy/st-miphy40lp.txt
> > @@ -0,0 +1,12 @@
> > +Required properties:
> > +- compatible : should be "st,miphy40lp-phy"
> > + Other supported soc specific compatible:
> > + "st,spear1310-miphy"
> > + "st,spear1340-miphy"
> > +- reg : offset and length of the PHY register set.
> > +- misc: phandle for the syscon node to access misc registers
> > +- phy-id: Instance id of the phy.
> > +- #phy-cells : from the generic PHY bindings, must be 1.
> > + - 1st cell: phandle to the phy node.
> > + - 2nd cell: 0 if phy (in 1st cell) is to be used for SATA, 1 for PCIe
> > + and 2 for Super Speed USB.
>
> It's common to start this file with a small header explaining what this
> hardware is.
- OK
>
> > diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig index
> > afa2354..2f58993 100644
> > --- a/drivers/phy/Kconfig
> > +++ b/drivers/phy/Kconfig
> > @@ -64,4 +64,10 @@ config BCM_KONA_USB2_PHY
> > help
> > Enable this to support the Broadcom Kona USB 2.0 PHY.
> >
> > +config PHY_ST_MIPHY40LP
> > + tristate "ST MIPHY 40LP driver"
> > + help
> > + Support for ST MIPHY 40LP which can be used for PCIe, SATA and
> Super Speed USB.
> > + select GENERIC_PHY
> > +
> > endmenu
>
> The 'select' statement should come before 'help', for consistency with the
> rest of the kernel.
- OK
> Maybe mention that this phy is used inside the spear13xx
> SoC here rather than a standalone phy.
- Yes, for spear13xx its used internally. Do you think that it requires to be mentioned here?
We have few prototype boards that uses this as external phy.
> > + priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
> > + if (!priv) {
> > + dev_err(dev, "can't alloc miphy40lp private date
> memory\n");
> > + return -ENOMEM;
> > + }
> > +
> > + priv->plat_ops = (struct miphy40lp_plat_ops *)of_id->data;
>
> The cast would incorrectly remove the 'const' attribute of the pointer.
> Better remove the cast and make priv->plat_ops const.
- OK
>
> > +static int __init miphy40lp_phy_init(void) {
> > +
> > + return platform_driver_probe(&miphy40lp_driver,
> > + miphy40lp_probe);
> > +}
> > +module_init(miphy40lp_phy_init);
>
> There should certainly be a module_exit() function here so you can unload
> the driver.
- yes, will add it in v6.
Thanks
Mohit
>
> Arnd
^ permalink raw reply
* Re: [PATCH] of/gpio: Define OF_GPIO_OPEN_DRAIN flag for Open Drain outputs.
From: Alexandre Courbot @ 2014-02-11 4:31 UTC (permalink / raw)
To: David Daney
Cc: Grant Likely, Rob Herring, devicetree@vger.kernel.org,
Linus Walleij, linux-gpio@vger.kernel.org,
Linux Kernel Mailing List, David Daney
In-Reply-To: <1392069908-22017-1-git-send-email-ddaney.cavm@gmail.com>
On Tue, Feb 11, 2014 at 7:05 AM, David Daney <ddaney.cavm@gmail.com> wrote:
> From: David Daney <david.daney@cavium.com>
>
> When we have a GPIO pin connected to an open-drain network, we want a
> standard way of specifying this in the device tree. So we choose bit
> 1 of the flag field to indicate open drain.
>
> A typical use case would be something like:
>
> enum of_gpio_flags f;
> .
> .
> .
> reset_gpio = of_get_named_gpio_flags(node, "reset", 0, &f);
> .
> .
> .
> ret = gpio_request_one(reset_gpio,
> (f & OF_GPIO_OPEN_DRAIN) ? GPIOF_OPEN_DRAIN : 0,
> "reset");
> .
> .
> .
> gpio_direction_output(reset_gpio, 1);
> gpio_set_value(reset_gpio, 0);
> msleep(20);
> gpio_set_value(reset_gpio, 1);
This is also useful for gpiod_get(). However, while you are at it,
could you also add a flag for the OF_GPIO_OPEN_SOURCE property? My joy
would be complete if you could also take the time to update
of_find_gpio() to pass these new flags back to the caller as it
already does for OF_GPIO_ACTIVE_LOW.
Then you could even switch your use-case to the gpiod interface and
not bother with passing these flags by yourself anymore. Just sayin'.
;)
Thanks,
Alex.
^ permalink raw reply
* Re: [PATCH V2 2/3] ARM: dts: add dts files for exynos5260 SoC
From: Rahul Sharma @ 2014-02-11 5:22 UTC (permalink / raw)
To: Tomasz Figa
Cc: Rahul Sharma, linux-samsung-soc, Kukjin Kim, Tomasz Figa,
sunil joshi, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, Rob Herring, Mark Rutland,
Grant Likely, Ian Campbell, Pawel Moll, Kumar Gala
In-Reply-To: <52F38C42.5030508@samsung.com>
Hi Tomasz,
On 6 February 2014 18:51, Tomasz Figa <t.figa@samsung.com> wrote:
> Hi Rahul, Pankaj, Arun,
>
> [adding linux-arm-kernel, devicetree MLs and DT people on Cc]
>
> I think it's good time to stop accepting DTS files like this and force new
> ones to use the proper structure with soc node, labels for every node and
> node references.
I am unable to find information on SoC node and grouping inside SoC node. Please
share some pointers.
>
> In case of previous Exynos 5 SoCs I hadn't complained, because they shared a
> lot of data with already existing exynos5.dtsi, but since Exynos5260 is
> completely different, I'd say it should be converted to the new layout.
>
> As an example you can look at arch/arm/boot/dts/s3c64xx.dtsi and files that
> include it or, for more complete structures, DTS of other platforms, such as
> imx6*.
>
> Btw. Please remember that linux-samsung-soc mailing list is just a
> convenient utility for reviewers of Samsung-specific patches to have all of
> them in one place. Sending patches to it alone is not enough - a general
> kernel ML list needs to be CCed as well, in this case linux-arm-kernel.
>
I will take care of this.
> Also, please see my comments inline, for review comments unrelated to the
> issue described above.
>
>
> On 05.02.2014 06:16, Rahul Sharma wrote:
>>
>> The patch adds the dts files for exynos5260.
>>
>> Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
>> Signed-off-by: Rahul Sharma <rahul.sharma@samsung.com>
>> Signed-off-by: Arun Kumar K <arun.kk@samsung.com>
>> ---
>> arch/arm/boot/dts/exynos5260-pinctrl.dtsi | 572
>> +++++++++++++++++++++++++++++
>> arch/arm/boot/dts/exynos5260.dtsi | 317 ++++++++++++++++
>> 2 files changed, 889 insertions(+)
>> create mode 100644 arch/arm/boot/dts/exynos5260-pinctrl.dtsi
>> create mode 100644 arch/arm/boot/dts/exynos5260.dtsi
>>
>> diff --git a/arch/arm/boot/dts/exynos5260-pinctrl.dtsi
>> b/arch/arm/boot/dts/exynos5260-pinctrl.dtsi
>> new file mode 100644
>> index 0000000..3f2c5c4
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/exynos5260-pinctrl.dtsi
>> @@ -0,0 +1,572 @@
>> +/*
>> + * Samsung's Exynos5260 SoC pin-mux and pin-config device tree source
>> + *
>> + * Copyright (c) 2013 Samsung Electronics Co., Ltd.
>> + * http://www.samsung.com
>> + *
>> + * Samsung's Exynos5260 SoC pin-mux and pin-config options are listed as
>> device
>> + * tree nodes are listed in this file.
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> +*/
>> +
>> +/ {
>> + pinctrl@11600000 {
>
>
> [snip]
>
>
>> + spi0_bus: spi0-bus {
>> + samsung,pins = "gpa2-0", "gpa2-1", "gpa2-2",
>> "gpa2-3";
>
>
> What is the reason for SPI0 to have 4 pins, while SPI1 has just 3?
>
I should align SPI1 with SPI0.
>
>> + samsung,pin-function = <2>;
>> + samsung,pin-pud = <3>;
>> + samsung,pin-drv = <0>;
>> + };
>
>
> [snip]
>
>
>> diff --git a/arch/arm/boot/dts/exynos5260.dtsi
>> b/arch/arm/boot/dts/exynos5260.dtsi
>> new file mode 100644
>> index 0000000..32a95c7
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/exynos5260.dtsi
>> @@ -0,0 +1,317 @@
>> +/*
>> + * SAMSUNG EXYNOS5260 SoC device tree source
>> + *
>> + * Copyright (c) 2013 Samsung Electronics Co., Ltd.
>> + * http://www.samsung.com
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> +*/
>> +
>> +#include "skeleton.dtsi"
>> +#include "exynos5260-pinctrl.dtsi"
>> +
>> +#include <dt-bindings/clk/exynos5260-clk.h>
>> +
>> +/ {
>> + compatible = "samsung,exynos5260";
>> + interrupt-parent = <&gic>;
>> +
>> + aliases {
>> + pinctrl0 = &pinctrl_0;
>> + pinctrl1 = &pinctrl_1;
>> + pinctrl2 = &pinctrl_2;
>> + };
>> +
>> + chipid@10000000 {
>> + compatible = "samsung,exynos4210-chipid";
>> + reg = <0x10000000 0x100>;
>> + };
>> +
>> + cpus {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + cpu@0 {
>> + device_type = "cpu";
>> + compatible = "arm,cortex-a15";
>> + reg = <0>;
>
>
> nit: Please make this consistent with CPUs 10x below, by using hex here as
> well.
>
Done.
>
>> + cci-control-port = <&cci_control1>;
>> + };
>
>
> nit: Please keep 1 blank line of spacing between nodes.
>
ok.
>
>> + cpu@1 {
>> + device_type = "cpu";
>> + compatible = "arm,cortex-a15";
>> + reg = <1>;
>> + cci-control-port = <&cci_control1>;
>> + };
>> + cpu@100 {
>> + device_type = "cpu";
>> + compatible = "arm,cortex-a7";
>> + reg = <0x100>;
>> + cci-control-port = <&cci_control0>;
>> + };
>> + cpu@101 {
>> + device_type = "cpu";
>> + compatible = "arm,cortex-a7";
>> + reg = <0x101>;
>> + cci-control-port = <&cci_control0>;
>> + };
>> + cpu@102 {
>> + device_type = "cpu";
>> + compatible = "arm,cortex-a7";
>> + reg = <0x102>;
>> + cci-control-port = <&cci_control0>;
>> + };
>> + cpu@103 {
>> + device_type = "cpu";
>> + compatible = "arm,cortex-a7";
>> + reg = <0x103>;
>> + cci-control-port = <&cci_control0>;
>> + };
>> + };
>> +
>> + cmus {
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + ranges;
>> +
>
>
> I don't think there is a need to group these nodes under a parent node that
> doesn't give any additional information, especially when the CMUs are
> scattered trough the whole address space, while we'd like to keep the nodes
> ordered by their addresses, as most platforms do.
>
This is exactly the same case as "cpus". I mean, "cpus" also doesn't provide
any common information about child cpu nodes. This looks to me as a logical
grouping and I have implemented same thing for cmu nodes.
I am ok with removing this grouping Just want to understand the rational behind
grouping cpus which seems similar to cmus.
Similarly "soc" is just a logical entity used to group SoC elements which looks
optional to me. What are we achieving with this? Please help me in understanding
this better.
>
>> + cmu_top: clock-controller@10010000 {
>> + compatible = "exynos5260-cmu-top",
>> "samsung,exynos5260-clock";
>
>
> I don't think that having the "samsung,exynos5260-clock" compatible string
> for every CMU is appropriate here, because there is no way to automatically
> recognize which CMU it is. Since every CMU instance is different, they need
> to have different compatible strings.
>
Changed.
>
>> + reg = <0x10010000 0x10000>;
>> + #clock-cells = <1>;
>> + };
>
>
> [snip]
>
>
>> + mct@100B0000 {
>> + compatible = "samsung,exynos4210-mct";
>> + reg = <0x100B0000 0x1000>;
>> + interrupt-controller;
>> + #interrups-cells = <1>;
>
>
> MCT is not an interrupt controller, so the 2 properties above are incorrect.
>
Agree. I will change this.
>
>> + interrupt-parent = <&mct_map>;
>> + interrupts = <0>, <1>, <2>, <3>,
>> + <4>, <5>, <6>, <7>,
>> + <8>, <9>, <10>, <11>;
>> + clocks = <&cmu_top FIN_PLL>, <&cmu_peri PERI_CLK_MCT>;
>> + clock-names = "fin_pll", "mct";
>> +
>> + mct_map: mct-map {
>> + #interrupt-cells = <1>;
>> + #address-cells = <0>;
>> + #size-cells = <0>;
>> + interrupt-map = <0 &gic 0 104 0>,
>> + <1 &gic 0 105 0>,
>> + <2 &gic 0 106 0>,
>> + <3 &gic 0 107 0>,
>> + <4 &gic 0 122 0>,
>> + <5 &gic 0 123 0>,
>> + <6 &gic 0 124 0>,
>> + <7 &gic 0 125 0>,
>> + <8 &gic 0 126 0>,
>> + <9 &gic 0 127 0>,
>> + <10 &gic 0 128 0>,
>> + <11 &gic 0 129 0>;
>> + };
>
>
> There is no need for interrupt-map here, because all the interrupts are from
> GIC.
>
Done.
Regards,
Rahul Sharma.
>> + };
>
>
> [snip]
>
>
>> + mmc_0: mmc0@12140000 {
>> + compatible = "samsung,exynos5250-dw-mshc";
>> + reg = <0x12140000 0x2000>;
>> + interrupts = <0 156 0>;
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + clocks = <&cmu_fsys FSYS_CLK_MMC0>, <&cmu_top
>> TOP_SCLK_MMC0>;
>> + clock-names = "biu", "ciu";
>> + fifo-depth = <0x40>;
>
>
> nit: It might be more readable to use decimal 64 here.
>
> Best regards,
> Tomasz
^ permalink raw reply
* Re: [PATCH v3 0/7] Modernize pm8921 with irqdomains, regmap, DT
From: Stephen Boyd @ 2014-02-11 6:35 UTC (permalink / raw)
To: Lee Jones
Cc: linux-kernel, linux-arm-msm, devicetree, Mark Brown,
linux-arm-kernel, Samuel Ortiz
In-Reply-To: <1389206270-3728-1-git-send-email-sboyd@codeaurora.org>
On 01/08, Stephen Boyd wrote:
> These patches lay the groundwork for converting the pm8921 sub-devices
> to devicetree as well as simplify the API by migrating the core code
> to use the regmap API instead of the custom pm8xxx read/write wrapper.
Lee,
Can you pick up these patches now? I don't think we're going to
get an ack from the DT reviewers. Its been over a month and
according to the documentation[1] I think we've done our due
diligence.
[1] Documentation/devicetree/bindings/submitting-patches.txt
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply
* [PATCH v2 07/11] watchdog: xilinx: Use of_property_read_u32
From: Michal Simek @ 2014-02-11 6:55 UTC (permalink / raw)
To: linux-kernel, monstr
Cc: Guenter Roeck, Wim Van Sebroeck, Grant Likely, Rob Herring,
linux-watchdog, linux-arm-kernel, devicetree
In-Reply-To: <f298edd222c57b0ce1ebad3ae50c3f715406c631.1392101734.git.michal.simek@xilinx.com>
[-- Attachment #1: Type: text/plain, Size: 2302 bytes --]
Use of_property_read_u32 functions to clean probe function.
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
---
Changes in v2:
- Fix enable_once logic
- Change patch subject
drivers/watchdog/of_xilinx_wdt.c | 28 ++++++++++++----------------
1 file changed, 12 insertions(+), 16 deletions(-)
diff --git a/drivers/watchdog/of_xilinx_wdt.c b/drivers/watchdog/of_xilinx_wdt.c
index c229cc4..bb03e5b 100644
--- a/drivers/watchdog/of_xilinx_wdt.c
+++ b/drivers/watchdog/of_xilinx_wdt.c
@@ -147,8 +147,7 @@ static u32 xwdt_selftest(struct xwdt_device *xdev)
static int xwdt_probe(struct platform_device *pdev)
{
int rc;
- u32 *tmptr;
- u32 *pfreq;
+ u32 pfreq, enable_once = 0;
struct resource *res;
struct xwdt_device *xdev;
bool no_timeout = false;
@@ -168,32 +167,29 @@ static int xwdt_probe(struct platform_device *pdev)
if (IS_ERR(xdev->base))
return PTR_ERR(xdev->base);
- pfreq = (u32 *)of_get_property(pdev->dev.of_node,
- "clock-frequency", NULL);
-
- if (pfreq == NULL) {
+ rc = of_property_read_u32(pdev->dev.of_node, "clock-frequency", &pfreq);
+ if (rc) {
dev_warn(&pdev->dev,
"The watchdog clock frequency cannot be obtained\n");
no_timeout = true;
}
- tmptr = (u32 *)of_get_property(pdev->dev.of_node,
- "xlnx,wdt-interval", NULL);
- if (tmptr == NULL) {
+ rc = of_property_read_u32(pdev->dev.of_node, "xlnx,wdt-interval",
+ &xdev->wdt_interval);
+ if (rc) {
dev_warn(&pdev->dev,
"Parameter \"xlnx,wdt-interval\" not found\n");
no_timeout = true;
- } else {
- xdev->wdt_interval = *tmptr;
}
- tmptr = (u32 *)of_get_property(pdev->dev.of_node,
- "xlnx,wdt-enable-once", NULL);
- if (tmptr == NULL) {
+ rc = of_property_read_u32(pdev->dev.of_node, "xlnx,wdt-enable-once",
+ &enable_once);
+ if (rc)
dev_warn(&pdev->dev,
"Parameter \"xlnx,wdt-enable-once\" not found\n");
+
+ if (enable_once)
watchdog_set_nowayout(xilinx_wdt_wdd, true);
- }
/*
* Twice of the 2^wdt_interval / freq because the first wdt overflow is
@@ -201,7 +197,7 @@ static int xwdt_probe(struct platform_device *pdev)
*/
if (!no_timeout)
xilinx_wdt_wdd->timeout = 2 * ((1 << xdev->wdt_interval) /
- *pfreq);
+ pfreq);
spin_lock_init(&xdev->spinlock);
watchdog_set_drvdata(xilinx_wdt_wdd, xdev);
--
1.8.2.3
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply related
* [PATCH v2 09/11] watchdog: xilinx: Add missing binding
From: Michal Simek @ 2014-02-11 6:55 UTC (permalink / raw)
To: linux-kernel, monstr
Cc: Guenter Roeck, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala, Rob Landley, Arnd Bergmann, devicetree,
linux-doc, linux-arm-kernel
In-Reply-To: <f298edd222c57b0ce1ebad3ae50c3f715406c631.1392101734.git.michal.simek@xilinx.com>
[-- Attachment #1: Type: text/plain, Size: 1419 bytes --]
Document current driver binding.
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
---
Changes in v2: None
.../devicetree/bindings/watchdog/of-xilinx-wdt.txt | 23 ++++++++++++++++++++++
1 file changed, 23 insertions(+)
create mode 100644 Documentation/devicetree/bindings/watchdog/of-xilinx-wdt.txt
diff --git a/Documentation/devicetree/bindings/watchdog/of-xilinx-wdt.txt b/Documentation/devicetree/bindings/watchdog/of-xilinx-wdt.txt
new file mode 100644
index 0000000..6d63782
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/of-xilinx-wdt.txt
@@ -0,0 +1,23 @@
+Xilinx AXI/PLB soft-core watchdog Device Tree Bindings
+---------------------------------------------------------
+
+Required properties:
+- compatible : Should be "xlnx,xps-timebase-wdt-1.00.a" or
+ "xlnx,xps-timebase-wdt-1.01.a".
+- reg : Physical base address and size
+
+Optional properties:
+- clock-frequency : Frequency of clock in Hz
+- xlnx,wdt-enable-once : 0 - Watchdog can be restarted
+ 1 - Watchdog can be enabled just once
+- xlnx,wdt-interval : Watchdog timeout interval in 2^<val> clock cycles,
+ <val> is integer from 8 to 31.
+
+Example:
+axi-timebase-wdt@40100000 {
+ clock-frequency = <50000000>;
+ compatible = "xlnx,xps-timebase-wdt-1.00.a";
+ reg = <0x40100000 0x10000>;
+ xlnx,wdt-enable-once = <0x0>;
+ xlnx,wdt-interval = <0x1b>;
+} ;
--
1.8.2.3
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply related
* Re: [PATCH] dp83640: Get gpio and master/slave configuration from DT
From: Stefan Sørensen @ 2014-02-11 8:01 UTC (permalink / raw)
To: Richard Cochran; +Cc: grant.likely, robh+dt, netdev, linux-kernel, devicetree
In-Reply-To: <20140210184604.GA4296@netboy>
On Mon, 2014-02-10 at 19:46 +0100, Richard Cochran wrote:
> 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.
I will keep the module parameters as fallback. Will it be OK to split
the gpio_tab parameter into separate calibrate-pin, perout-pins and
extts-pins parameters?
> > 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?
I mean each group of PHYs. I will reword that.
Stefan
^ permalink raw reply
* Re: [PATCH v6 01/19] clocksource: orion: Use atomic access for shared registers
From: Ezequiel Garcia @ 2014-02-11 8:30 UTC (permalink / raw)
To: Daniel Lezcano
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-watchdog-u79uwXL29TY76Z2rM5mHXA, Wim Van Sebroeck,
Jason Cooper, Thomas Petazzoni, Gregory Clement, Lior Amsalem,
Sebastian Hesselbarth, Andrew Lunn
In-Reply-To: <52F96993.9090007-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
On Tue, Feb 11, 2014 at 01:06:43AM +0100, Daniel Lezcano wrote:
> On 02/06/2014 06:20 PM, Ezequiel Garcia wrote:
> > Replace the driver-specific thread-safe shared register API
> > by the recently introduced atomic_io_clear_set().
> >
> > Cc: Daniel Lezcano <daniel.lezcano-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> > Tested-by: Sebastian Hesselbarth <sebastian.hesselbarth-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > Tested-by: Willy Tarreau <w@1wt.eu>
> > Acked-by: Jason Cooper <jason-NLaQJdtUoK4Be96aLqz0jA@public.gmane.org>
> > Signed-off-by: Ezequiel Garcia <ezequiel.garcia-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
>
> The patch looks good for me.
>
> Acked-by: Daniel Lezcano <daniel.lezcano-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
>
Daniel,
Jason acked this patch for you to take it. Or do you prefer that we
merge it with the rest of the watchdog series?
--
Ezequiel García, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com
--
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: [RFC 1/6] mailbox: add core framework
From: Arnd Bergmann @ 2014-02-11 8:35 UTC (permalink / raw)
To: Courtney Cavin
Cc: Rob Herring, Josh Cartwright, 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: <20140211002347.GW1706@sonymobile.com>
On Monday 10 February 2014 16:23:48 Courtney Cavin wrote:
> While I'm not sure the dislike of notifiers entirely justifies not using
> them here, where they seem to make sense, I can understand that they
> might not fully implement what we need to expose.
I think we need to look at a few more examples of things that people
want to with the framework to come up with a good interface. It's
possible that we end up with multiple alternative notification
methods, but it would be good to come up with one that works well
for everyone.
> Regarding handlers running in IRQ context: currently the API is designed
> to do just that. From the use-cases I've found, most message handlers
> simply queue something to happen at a later point. This is logical, as
> the callback will be async, so you'll need to swap contexts or add locks
> in your consumer anyway.
Right. You may also have some handlers that need to run with extreme
latency constraints, so we need at least the option of getting the
callback from hardirq context, or possibly from softirq/tasklet
as in the dmaengine case.
> The dma engine is large and confused, so I'm not sure entirely which
> part you are refering to. I've looked at having async completion going
> both ways, but what I see every time is code complication in both the
> adapter and in the consumers in the simple use-case. It doesn't really
> make sense to make an API which makes things so generic that it becomes
> hard to use. What I tried to follow here when designing the API was
> what I saw in the actual implementations, not what was future-proof:
> - Message receive callbacks may be called from IRQ context
> - Message send implementations may sleep
I can imagine cases where you want to send messages from softirq
context, or from the same context in which you received the incoming
mail, so it would be good to have the API flexible enough to deal
with that. As a first step, always allowing send to sleep seems
fine. Alternatively, we could have a 'sync' flag in the send
API, to choose between "arrange this message to be sent out as
soon as possible, but don't sleep" and "send this message and
make sure it has arrived at the other end" as you do now.
> What I can do is try to alleviate implementation efforts of future
> requirements--as honestly, we can't really say exactly what they are--by
> turning the messages into structs themselves, so at a later point flags,
> ack callbacks, and rainbows can be added. I can then stop using
> notifiers, and re-invent that functionality with a mbox_ prefix.
I don't think there is a point in reimplementing notifiers under a
different name. The question is rather how we want to deal with
the 'multiple listener' case. If this case is the exception rather
than the rule, I'd prefer making the callback API handle only
single listeners and adding higher-level abstractions for the
cases where we do need multiple listeners, but it really depends
on what people need.
Arnd
^ permalink raw reply
* Re: [PATCH] net: rfkill-regulator: Add devicetree support.
From: Marc Dietrich @ 2014-02-11 8:42 UTC (permalink / raw)
To: Mark Rutland
Cc: Marek Belisko, robh+dt@kernel.org, Pawel Moll,
ijc+devicetree@hellion.org.uk, galak@codeaurora.org,
rob@landley.net, linville@tuxdriver.com,
johannes@sipsolutions.net, davem@davemloft.net,
grant.likely@linaro.org, neilb@suse.de, hns@goldelico.com,
devicetree@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-wireless@vger.kernel.org,
netdev@vger.kernel.org
In-Reply-To: <20140210101842.GS25314@e106331-lin.cambridge.arm.com>
Am Montag, 10. Februar 2014, 10:18:42 schrieb Mark Rutland:
> On Fri, Feb 07, 2014 at 07:48:49PM +0000, Marek Belisko wrote:
> > Signed-off-by: NeilBrown <neilb@suse.de>
> > Signed-off-by: Marek Belisko <marek@goldelico.com>
> > ---
> > Based on Neil's patch and extend for documentation and bindings include.
> >
> > .../bindings/net/rfkill/rfkill-relugator.txt | 28 ++++++++++++++++
> > include/dt-bindings/net/rfkill-regulator.h | 23 +++++++++++++
> > net/rfkill/rfkill-regulator.c | 38
> > ++++++++++++++++++++++ 3 files changed, 89 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/net/rfkill/rfkill-relugator.txt create
> > mode 100644 include/dt-bindings/net/rfkill-regulator.h
> >
> > diff --git
> > a/Documentation/devicetree/bindings/net/rfkill/rfkill-relugator.txt
> > b/Documentation/devicetree/bindings/net/rfkill/rfkill-relugator.txt new
> > file mode 100644
> > index 0000000..cdb7dd7
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/net/rfkill/rfkill-relugator.txt
> > @@ -0,0 +1,28 @@
> > +Regulator consumer for rfkill devices
>
> What exactly is an "rfkill" device? How is it used? How does it relate
> to other devices in the DT?
>
> To me, this looks like a leak of a Linux abstraction.
>
> > +
> > +Required properties:
> > +- compatible : Must be "rfkill-regulator".
> > +- label : Name of rfkill device.
>
> What's this for? Why does this need a label in the DT? Surely this can
> be implied by the relationship to a particular radio device?
>
> > +- type : Type of rfkill device.
> > +
> > +Possible values (defined in include/dt-bindings/net/rfkill-regulator.h):
> > + RFKILL_TYPE_ALL
> > + RFKILL_TYPE_WLAN
> > + RFKILL_TYPE_BLUETOOTH
> > + RFKILL_TYPE_UWB
> > + RFKILL_TYPE_WIMAX
> > + RFKILL_TYPE_WWAN
> > + RFKILL_TYPE_GPS
> > + RFKILL_TYPE_FM
> > + RFKILL_TYPE_NFC
>
> What do these mean? Why can these not be implied by a relationship to
> any devices of these particular types?
This problem comes up from time to time. rfkill-gpio has a similar problem,
btw. You can of course list an rfkill property inside the device node where it
is connected to, but what are you going to to if there is no device node, e.g.
the device is enumerated on a bus (e.g. usb, pci, ...)?
In such cases it may be better to define a standalone rfkill node similar to
the "backlight" device, even if it just contains a gpio or regulator.
Marc
^ permalink raw reply
* [PATCH 1/2] ARM: shmobile: r8a7778/r8a7779 dtsi: Improve and correct HSPI bindings
From: Geert Uytterhoeven @ 2014-02-11 8:56 UTC (permalink / raw)
To: Simon Horman, Kuninori Morimoto
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-spi-u79uwXL29TY76Z2rM5mHXA, linux-sh-u79uwXL29TY76Z2rM5mHXA,
Geert Uytterhoeven, Mark Brown
From: Geert Uytterhoeven <geert+renesas-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org>
Binding documentation:
- Add future-proof "renesas,hspi-<soctype>" compatible values,
- Add "interrupt-parent", "#address-cells" and "#size-cells" properties,
- Add reference to pinctrl documentation,
- Add example bindings.
r8a7778 and r8a7779 dtsi:
- Add "renesas,hspi-r8a7778" resp. "renesas,hspi-r8a7779" compatible
values,
- Correct reference to parent interrupt controller
(use "interrupt-parent" instead of "interrupt-controller"),
- Add missing "#address-cells" and "#size-cells" properties, which are
needed when populating the SPI buses.
Signed-off-by: Geert Uytterhoeven <geert+renesas-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org>
Cc: Mark Brown <broonie-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
---
Untested due to lack of hardware
Documentation/devicetree/bindings/spi/sh-hspi.txt | 27 ++++++++++++++++++---
arch/arm/boot/dts/r8a7778.dtsi | 18 +++++++++-----
arch/arm/boot/dts/r8a7779.dtsi | 18 +++++++++-----
3 files changed, 48 insertions(+), 15 deletions(-)
diff --git a/Documentation/devicetree/bindings/spi/sh-hspi.txt b/Documentation/devicetree/bindings/spi/sh-hspi.txt
index 30b57b1c8a13..d43080eb6b3a 100644
--- a/Documentation/devicetree/bindings/spi/sh-hspi.txt
+++ b/Documentation/devicetree/bindings/spi/sh-hspi.txt
@@ -1,7 +1,28 @@
Renesas HSPI.
Required properties:
-- compatible : "renesas,hspi"
-- reg : Offset and length of the register set for the device
-- interrupts : interrupt line used by HSPI
+- compatible : "renesas,hspi-<soctype>", "renesas,hspi" as fallback.
+ Examples of valid soctypes are "r8a7778" (R-Car M1),
+ and "r8a7779" (R-Car H1)
+- reg : Offset and length of the register set for the device
+- interrupt-parent : The phandle for the interrupt controller that
+ services interrupts for this device
+- interrupts : Interrupt specifier
+- #address-cells : Must be <1>
+- #size-cells : Must be <0>
+
+Pinctrl properties might be needed, too. See
+Documentation/devicetree/bindings/pinctrl/renesas,*.
+
+Example:
+
+ hspi0: spi@fffc7000 {
+ compatible = "renesas,hspi-r8a7778", "renesas,hspi";
+ reg = <0xfffc7000 0x18>;
+ interrupt-parent = <&gic>;
+ interrupts = <0 63 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
diff --git a/arch/arm/boot/dts/r8a7778.dtsi b/arch/arm/boot/dts/r8a7778.dtsi
index 85c5b3b99f5e..3c6fab5c9702 100644
--- a/arch/arm/boot/dts/r8a7778.dtsi
+++ b/arch/arm/boot/dts/r8a7778.dtsi
@@ -204,26 +204,32 @@
};
hspi0: spi@fffc7000 {
- compatible = "renesas,hspi";
+ compatible = "renesas,hspi-r8a7778", "renesas,hspi";
reg = <0xfffc7000 0x18>;
- interrupt-controller = <&gic>;
+ interrupt-parent = <&gic>;
interrupts = <0 63 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
status = "disabled";
};
hspi1: spi@fffc8000 {
- compatible = "renesas,hspi";
+ compatible = "renesas,hspi-r8a7778", "renesas,hspi";
reg = <0xfffc8000 0x18>;
- interrupt-controller = <&gic>;
+ interrupt-parent = <&gic>;
interrupts = <0 84 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
status = "disabled";
};
hspi2: spi@fffc6000 {
- compatible = "renesas,hspi";
+ compatible = "renesas,hspi-r8a7778", "renesas,hspi";
reg = <0xfffc6000 0x18>;
- interrupt-controller = <&gic>;
+ interrupt-parent = <&gic>;
interrupts = <0 85 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
status = "disabled";
};
};
diff --git a/arch/arm/boot/dts/r8a7779.dtsi b/arch/arm/boot/dts/r8a7779.dtsi
index d0561d4c7c46..8b1a336ee401 100644
--- a/arch/arm/boot/dts/r8a7779.dtsi
+++ b/arch/arm/boot/dts/r8a7779.dtsi
@@ -256,26 +256,32 @@
};
hspi0: spi@fffc7000 {
- compatible = "renesas,hspi";
+ compatible = "renesas,hspi-r8a7779", "renesas,hspi";
reg = <0xfffc7000 0x18>;
- interrupt-controller = <&gic>;
+ interrupt-parent = <&gic>;
interrupts = <0 73 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
status = "disabled";
};
hspi1: spi@fffc8000 {
- compatible = "renesas,hspi";
+ compatible = "renesas,hspi-r8a7779", "renesas,hspi";
reg = <0xfffc8000 0x18>;
- interrupt-controller = <&gic>;
+ interrupt-parent = <&gic>;
interrupts = <0 74 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
status = "disabled";
};
hspi2: spi@fffc6000 {
- compatible = "renesas,hspi";
+ compatible = "renesas,hspi-r8a7779", "renesas,hspi";
reg = <0xfffc6000 0x18>;
- interrupt-controller = <&gic>;
+ interrupt-parent = <&gic>;
interrupts = <0 75 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
status = "disabled";
};
};
--
1.7.9.5
--
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 related
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