Re: [PATCH v3 5/5] arm: dts: Add pinctrl/GPIO/EINT node for mt2701
On Thu, Dec 31, 2015 at 12:23 PM, Matthias Brugger wrote: > On 28/12/15 08:09, Biao Huang wrote: >> >> Add pinctrl and GPIO node to mt2701.dtsi >> >> Signed-off-by: Biao Huang >> Acked-by: Linus Walleij >> --- >> arch/arm/boot/dts/mt2701.dtsi | 19 +++ >> 1 file changed, 19 insertions(+) >> > > Signed-off-by: Matthias Brugger > > Linus, will you take this patch through your branch? No I prefer anything in arch/arm/boot/dts/* to go in through the ARM SoC tree. It can usually be merged orthogonally anyways. I take Documenation/devicetree/bindings/* and patches to the driver itself in drivers/pinctrl/* Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/5] dt-bindings: mediatek: Modify pinctrl bindings for mt2701
On Mon, Dec 28, 2015 at 8:09 AM, Biao Huang wrote: > Signed-off-by: Biao Huang Patch applied with the ACKs. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] gpiolib: always initialize *flags from of_get_named_gpio_flags
On Fri, Jan 1, 2016 at 11:40 PM, Arnd Bergmann wrote: > The of_get_named_gpio_flags() function does nothing other than returning > an error when CONFIG_OF_GPIO is disabled, but that causes spurious > warnings about possible use of uninitialized variables in any code that > does not check the of_get_named_gpio_flags() return value before trying > to use the flags: > > drivers/input/misc/rotary_encoder.c: In function 'rotary_encoder_probe': > drivers/input/misc/rotary_encoder.c:223:28: warning: 'flags' may be used > uninitialized in this function [-Wmaybe-uninitialized] > drivers/power/bq24735-charger.c: In function 'bq24735_charger_probe': > drivers/power/bq24735-charger.c:227:12: warning: 'flags' may be used > uninitialized in this function [-Wmaybe-uninitialized] > drivers/power/sbs-battery.c: In function 'sbs_probe': > drivers/power/sbs-battery.c:782:17: warning: 'gpio_flags' may be used > uninitialized in this function [-Wmaybe-uninitialized] > > This changes the behavior of the inline helper to set the flags to zero > when OF_GPIO is disabled, to avoid the warnings. In all cases I've > encountered, we don't actually get to the place that uses the flags > if CONFIG_OF is disabled because we won't enter the DT parser code. > > Signed-off-by: Arnd Bergmann Patch applied! Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL 5/9] ARM: EXYNOS: Drivers for v4.5
On Wed, Dec 2, 2015 at 2:39 AM, Krzysztof Kozlowski wrote: > The following changes since commit 8005c49d9aea74d382f474ce11afbbc7d7130bec: > > Linux 4.4-rc1 (2015-11-15 17:00:27 -0800) > > are available in the git repository at: > > https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git > tags/samsung-drivers-4.5 > > for you to fetch changes up to 023e06dfa6882f500b9c86fd61f0b1913aa07f36: > > pinctrl: exynos: add exynos5410 SoC specific data (2015-11-16 10:54:43 > +0900) OK I pulled this into the pinctrl tree, cheers! Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] of/irq: Export of_irq_count()
On Tue, Dec 22, 2015 at 6:12 PM, Rob Herring wrote: > On Tue, Dec 22, 2015 at 6:22 AM, Mark Brown wrote: >> Some of the Qualcomm pinctrl drivers have started trying to use >> of_irq_count() in modular code but this fails to build as the symbol is >> not exported. Since there doesn't seem to be any reason not to export >> the symbol make it available to modules. > > The reason it has not been exported is because we want to stick with > the platform_* APIs for IRQs. There's not really an equivalent > function though. Perhaps we should make one? Usually it is just used > for allocating some driver data. If that is the case, is it really > enough data to not just allocate the max? Hm that seems like a bigger solution. Should we try to mitigate the issue by making the Qualcomm drivers builtin for the time being? Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] of/irq: Export of_irq_count()
On Tue, Dec 22, 2015 at 1:22 PM, Mark Brown wrote: > Some of the Qualcomm pinctrl drivers have started trying to use > of_irq_count() in modular code but this fails to build as the symbol is > not exported. Since there doesn't seem to be any reason not to export > the symbol make it available to modules. > > Signed-off-by: Mark Brown Thanks Mark. Reviewed-by: Linus Walleij Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2 v2] ARM: l2x0: make it possible to disable outer sync from DT
On Sun, Dec 20, 2015 at 5:11 PM, Russell King - ARM Linux wrote: > It would be nice to have a faster response though, because Linus Walleij > put this in the patch system on the 15th December, and I could have > applied it without waiting for DT people to comment. The good thing is > that I _have_ the patch system, which allows me to temporarily ignore > patches (provided I remember) while people chew the cud on stuff like > this. > > However, I'd _much_ rather prefer the authors to hold back the patches > until they get "approved" *before* sending them there, so I don't have > to find and remember to track the status of each patch on the mailing > list. OK sorry, I guess I was a bit trigger happy as my RealView was booting so nicely and all. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] gpio: sx150x: Add support for sx1502
On Tue, Dec 15, 2015 at 11:01 PM, Peter Rosin wrote: > From: Peter Rosin > > Signed-off-by: Peter Rosin Patch applied with Rob's ACK. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] dt-bindings: GPIO: Add generic serializer binding
On Tue, Dec 15, 2015 at 12:19 AM, Andrew F. Davis wrote: > [Rob] >> I agree the generic version is fine (or find who made the first part >> ;)). What "pisosr" is is not very obvious though. Having 74165 in the >> compatible would make it somewhat more obvious it is a standard logic >> part. >> > > A quick search shows shift-registers being made from vacuum tubes for > the Colossus! Those might work with this driver if you could match the > voltage to an SPI bus... :) > > I agree about the name not being very good, but I'm not sure about > 74165 ether as it is also just a single part number. We can add many compatible strings so it's not an issue. "ti,74165" works for me as TI invented the 74xx series. > The idea was to > have a non-part number compatible string for any shift-register you > can hook to the SPI line. Again, one does not exclude the other. I'm happy with a generic compatible *and* "ti,74165". > That way when we have boards with a sn65x882 > or something we wont have to call it a 74165. But I guess that's why > it's a "compatible:" string, and not "is-a:" string. Compatible ranges from the specific to the more generic so compatible = "ti,74165", "pisosr"; is just fine. Something will match if there is a suitable driver. The OS may choose to provide something part-specific or something more generic. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH resend] pinctrl: sunxi: Add A80 special pin controller
On Wed, Dec 16, 2015 at 5:39 PM, Chen-Yu Tsai wrote: > From: Maxime Ripard > > Like the previous designs, the A80 has a special pin controller for the > critical pins, like the PMIC bus. > > Add a driver for this controller. > > Signed-off-by: Maxime Ripard > [wens: Add A80 compatible strings to bindings doc; fix pin function >names based on v1.3 datasheet; constify of_device_id table] > Signed-off-by: Chen-Yu Tsai > Acked-by: Rob Herring > --- > > Linus, can we have this one included for 4.5? Yep. Patch rebased and applied! Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] Add support for monitoring gpio switches
On Wed, Dec 16, 2015 at 11:11 AM, Martyn Welch wrote: >> Patches like that has however already been suggested, and I have NACKed >> them because the GPIO sysfs ABI is insane, and that is why I am >> refactoring >> the world to create a proper chardev ABI for GPIO instead. See: >> http://marc.info/?l=linux-gpio&m=144550276512673&w=2 > > I can certainly understand the rationale for the changes that you are > proposing, though do worry that it does make it a bit tougher to use from > scripting languages. The idea is to provide commandline tools in the kernel tools/gpio subdir to satisfy the needs of scripting. "lsgpio" today is just one example, nothing stops us from having a tool called just "gpio-sak" (GPIO swiss army knife) that will be tailored for scripting. > I see that the question of how to provide functionality > equivalent to the above was raised and no answer was forthcoming. Is there a > plan for supporting the identification of a GPIO line serving a specific > purpose? Yes by name. > What is the status of the mentioned patch series? They stubled into a few dozen architecture issues in the GPIO subsystem so I am busy refactoring the whole know universe :D But I still intend to persue the series. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 0/5] mfd: tps65912: Driver rewrite with DT support
On Tue, Dec 15, 2015 at 5:16 PM, Andrew F. Davis wrote: > Is there anything I can do to help this along? This series > and the tps65086 series have been blocked for months on > trivial issues. (Not sure why the tps65086 hasn't been taken, > it doesn't have this problem, I'd be OK with this getting > stalled for a bit longer if someone could look at the other > one) Lee can you merge the core driver if it's OK? Then we have includes etc in place to merge subdrivers for the next merge window. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2 v2] ARM: l2x0: make it possible to disable outer sync from DT
According to commit 2503a5ecd86c002506001eba432c524ea009fe7f
"ARM: 6201/1: RealView: Do not use outer_sync() on ARM11MPCore
boards with L220" Some PB11MPCore RealView core tiles have broken
outer_sync.
We got rid of the custom barriers from the machine by disabling
outer sync, but that was just for the boardfile case. We have
to be able to do the same in the device tree case.
Since __l2c_init() is cloning and copying the L2C vtable,
we pass an argument to this function to optionally numb
the outer sync operation if desired, before initializing
the cache.
After this we can set up the cache correctly on the RealView
PB11MPCore. This was tested on a PB11MPCore known to have the
issue. Before this, spurious crashes would occur if we try to
set up the cache properly, after this it boots rock solid.
Cc: Russell King
Cc: Arnd Bergmann
Cc: devicetree@vger.kernel.org
Signed-off-by: Linus Walleij
---
ChangeLog v2->v3:
- Update description, reference Catalins initial commit in the
commit blurb.
---
Documentation/devicetree/bindings/arm/l2cc.txt | 3 +++
arch/arm/mm/cache-l2x0.c | 13 ++---
2 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/l2cc.txt
b/Documentation/devicetree/bindings/arm/l2cc.txt
index d181b7c4c522..416864e9dc92 100644
--- a/Documentation/devicetree/bindings/arm/l2cc.txt
+++ b/Documentation/devicetree/bindings/arm/l2cc.txt
@@ -75,6 +75,9 @@ Optional properties:
specified to indicate that such transforms are precluded.
- arm,parity-enable : enable parity checking on the L2 cache (L220 or PL310).
- arm,parity-disable : disable parity checking on the L2 cache (L220 or PL310).
+- arm,outer-sync-disable : disable the outer sync operation on the L2 cache.
+ Some core tiles, especially ARM PB11MPCore have a faulty L220 cache that
+ will randomly hang unless outer sync operations are disabled.
- prefetch-data : Data prefetch. Value: <0> (forcibly disable), <1>
(forcibly enable), property absent (retain settings set by firmware)
- prefetch-instr : Instruction prefetch. Value: <0> (forcibly disable),
diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
index 3f3008e5c662..9f9d54271aad 100644
--- a/arch/arm/mm/cache-l2x0.c
+++ b/arch/arm/mm/cache-l2x0.c
@@ -790,7 +790,7 @@ static const struct l2c_init_data l2c310_init_fns
__initconst = {
};
static int __init __l2c_init(const struct l2c_init_data *data,
-u32 aux_val, u32 aux_mask, u32 cache_id)
+u32 aux_val, u32 aux_mask, u32 cache_id, bool
nosync)
{
struct outer_cache_fns fns;
unsigned way_size_bits, ways;
@@ -866,6 +866,10 @@ static int __init __l2c_init(const struct l2c_init_data
*data,
fns.configure = outer_cache.configure;
if (data->fixup)
data->fixup(l2x0_base, cache_id, &fns);
+ if (nosync) {
+ pr_info("L2C: disabling outer sync\n");
+ fns.sync = NULL;
+ }
/*
* Check if l2x0 controller is already enabled. If we are booting
@@ -925,7 +929,7 @@ void __init l2x0_init(void __iomem *base, u32 aux_val, u32
aux_mask)
if (data->save)
data->save(l2x0_base);
- __l2c_init(data, aux_val, aux_mask, cache_id);
+ __l2c_init(data, aux_val, aux_mask, cache_id, false);
}
#ifdef CONFIG_OF
@@ -1724,6 +1728,7 @@ int __init l2x0_of_init(u32 aux_val, u32 aux_mask)
struct resource res;
u32 cache_id, old_aux;
u32 cache_level = 2;
+ bool nosync = false;
np = of_find_matching_node(NULL, l2x0_ids);
if (!np)
@@ -1762,6 +1767,8 @@ int __init l2x0_of_init(u32 aux_val, u32 aux_mask)
if (cache_level != 2)
pr_err("L2C: device tree specifies invalid cache level\n");
+ nosync = of_property_read_bool(np, "arm,outer-sync-disable");
+
/* Read back current (default) hardware configuration */
if (data->save)
data->save(l2x0_base);
@@ -1776,6 +1783,6 @@ int __init l2x0_of_init(u32 aux_val, u32 aux_mask)
else
cache_id = readl_relaxed(l2x0_base + L2X0_CACHE_ID);
- return __l2c_init(data, aux_val, aux_mask, cache_id);
+ return __l2c_init(data, aux_val, aux_mask, cache_id, nosync);
}
#endif
--
2.4.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] Device tree binding documentation for gpio-switch
On Fri, Dec 11, 2015 at 3:06 PM, Rob Herring wrote:
> On Fri, Dec 11, 2015 at 6:39 AM, Linus Walleij
> wrote:
>> On Fri, Dec 4, 2015 at 6:31 PM, Martyn Welch
>> wrote:
>>
>>> This patch adds documentation for the gpio-switch binding. This binding
>>> provides a mechanism to bind named links to gpio, with the primary
>>> purpose of enabling standardised access to switches that might be standard
>>> across a group of devices but implemented differently on each device.
>>>
>>> Signed-off-by: Martyn Welch
>>
>> As mentioned in the comment to the second patch, this solves the
>> following generic problem:
>>
>> Expose a GPIO line to userspace using a specific name
>>
>> That means basically naming GPIO lines and marking them as
>> "not used by the operating system".
>>
>> This is something that has been proposed before, and postponed
>> because the kernel lacks the right infrastructure.
>
> That doesn't necessarily mean we can't define a binding.
Yeah that's true. just saying that the other stuff was not merged
for this reason, but then we can have a look at Markus' bindings
in parallell, Markus can you repost them to this audience? Only
the bindings I mean.
>> Markus Pargmann also did a series that add initial values to
>> hogs, which is the inverse usecase of this, where you want to
>> *output* something by default, then maybe also make it available
>> to userspace.
>>
>> So what we need to see here is a patch series that does all of these
>> things:
>>
>> - Name lines
>>
>> - Sets them to initial values
>>
>> - Mark them as read-only
>>
>> - Mark them as "not used by the operating system" so that they
>> can be default-exported to userspace.
>
> No! This should not be a DT property.
>
> Whether I want to control a GPIO in the kernel or userspace is not
> known and can change over time. It could simply depend on kernel
> config. There is also the case that a GPIO has no connection or kernel
> driver until some time later when a DT overlay for an expansion board
> is applied.
That's correct. So from a DT point of view, what really matters is
to give things a name, and the hogs and initvals syntax already
has a structure for this that is in use
(from Documentation/devicetree/bindings/gpio/gpio.txt):
qe_pio_a: gpio-controller@1400 {
compatible = "fsl,qe-pario-bank-a", "fsl,qe-pario-bank";
reg = <0x1400 0x18>;
gpio-controller;
#gpio-cells = <2>;
line_b {
gpio-hog;
gpios = <6 0>;
output-low;
line-name = "foo-bar-gpio";
};
};
Markus use this also for initial values. That could easily be used in
a budget version like this:
line_b {
/* Just naming */
gpios = <6 0>;
line-name = "foo-bar-gpio";
};
That could grow kind of big though. Or maybe not? How many
GPIO lines are actually properly named in a typical system?
The problem is that naming is usually imposed by consumers (they
are the ones who know how the line is used).
And then I do not mean naming it after the pin on the capsule
where it comes out as per the datasheet, but
naming it after the actual use.
Naming it after the hardware specs is something the operating
system can do, in Linux' case by the array char *names; inside the
struct gpio_chip and should not be part of the bindings IMO.
I would rather imagine this is something used in a top-level board
file naming it: "header-2-22" for the 22nd pin on some second header
on my BeagleBone Black or something like that. And those may not
be so vast in numbers so they could be named using this pattern.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ARM: l2x0: make it possible to disable outer sync from DT
On Thu, Dec 10, 2015 at 3:32 PM, Mark Rutland wrote: > On Thu, Dec 10, 2015 at 03:14:15PM +0100, Linus Walleij wrote: >> Some RealView platforms have broken outer_sync, see: >> http://marc.info/?l=linux-kernel&m=144846940516899&w=2 >> >> We got rid of the custom barriers from the machine by disabling >> outer sync, but that was just for the boardfile case. We have >> to be able to do the same in the device tree case. >> >> Since __l2c_init() is cloning and copying the L2C vtable, >> we pass an argument to this function to optionally numb >> the outer sync operation if desired, before initializing >> the cache. >> >> After this we can set up the cache correctly on the RealView >> PB11MPCore, and it boots rock solid with the cache enabled. >> Before this, spurious crashes would occur if we try to set >> up the cache properly. >> >> Cc: Russell King >> Cc: Arnd Bergmann >> Cc: devicetree@vger.kernel.org >> Signed-off-by: Linus Walleij >> --- >> Documentation/devicetree/bindings/arm/l2cc.txt | 1 + >> arch/arm/mm/cache-l2x0.c | 13 ++--- >> 2 files changed, 11 insertions(+), 3 deletions(-) >> >> diff --git a/Documentation/devicetree/bindings/arm/l2cc.txt >> b/Documentation/devicetree/bindings/arm/l2cc.txt >> index d181b7c4c522..aae7387acbdb 100644 >> --- a/Documentation/devicetree/bindings/arm/l2cc.txt >> +++ b/Documentation/devicetree/bindings/arm/l2cc.txt >> @@ -75,6 +75,7 @@ Optional properties: >>specified to indicate that such transforms are precluded. >> - arm,parity-enable : enable parity checking on the L2 cache (L220 or >> PL310). >> - arm,parity-disable : disable parity checking on the L2 cache (L220 or >> PL310). >> +- arm,outer-sync-disable : disable the outer sync operation on the L2 cache. > > I'm not sure what this means from a HW perspective. The "outer sync" > operation is Linux terminology and doesn't show up in the TRM for L220. > > What is the (integration? HW?) bug that we're trying to avoid the effect > of? It sounds like we should be describing that. > > We should at least have a better definition of what this means we must > avoid. So this code is a bit ancient, and we're trying to migrate it to device tree. It was inspired by this board file patch from Arnd: http://marc.info/?l=linux-arm-kernel&m=144846938616893&w=2 Then I go back and dig in the code and I find this: commit 2503a5ecd86c002506001eba432c524ea009fe7f Author: Catalin Marinas Date: Thu Jul 1 13:21:47 2010 +0100 ARM: 6201/1: RealView: Do not use outer_sync() on ARM11MPCore boards with L220 RealView boards with certain revisions of the L220 cache controller (ARM11* processors only) may have issues (hardware deadlock) with the recent changes to the mb() barrier implementation (DSB followed by an L2 cache sync). The patch redefines the RealView ARM11MPCore mandatory barriers without the outer_sync() call. Cc: Tested-by: Linus Walleij Signed-off-by: Catalin Marinas Signed-off-by: Russell King And that is as much as it says. It is working around a hardware lockup in some core tiles. Is it enough if I add this to the explanation or do we need to send Catalin or Will down in the archives to read netlists? ;) Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ARM: l2x0: make it possible to disable outer sync from DT
On Thu, Dec 10, 2015 at 3:20 PM, Arnd Bergmann wrote: > On Thursday 10 December 2015 15:14:15 Linus Walleij wrote: >> Some RealView platforms have broken outer_sync, see: >> http://marc.info/?l=linux-kernel&m=144846940516899&w=2 >> >> We got rid of the custom barriers from the machine by disabling >> outer sync, but that was just for the boardfile case. We have >> to be able to do the same in the device tree case. >> >> Since __l2c_init() is cloning and copying the L2C vtable, >> we pass an argument to this function to optionally numb >> the outer sync operation if desired, before initializing >> the cache. >> >> After this we can set up the cache correctly on the RealView >> PB11MPCore, and it boots rock solid with the cache enabled. >> Before this, spurious crashes would occur if we try to set >> up the cache properly. >> >> Cc: Russell King >> Cc: Arnd Bergmann >> Cc: devicetree@vger.kernel.org >> Signed-off-by: Linus Walleij > > This has the same effect as my "ARM: realview: remove private barrier > implementation" patch and replaces part of that, correct? Yes, but applied to a DT-only bootpath with a minimum of board file code, kept in l2x0.c just this bool in the DT node. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] gpio: Add driver for SPI serializers
On Fri, Dec 11, 2015 at 8:46 PM, Andrew F. Davis wrote:
> Add generic parallel-in/serial-out shift register GPIO driver.
>
> This includes SPI compatible devices like SN74165 serial-out shift
> registers and the SN65HVS88x series of industrial serializers that can
> be read over the SPI bus and used for GPI (General Purpose Input).
>
> Signed-off-by: Andrew F. Davis
(...)
> +#include
> +#include
Use #include instead.
> +#include
> +#include
> +#include
> +
> +#define DEFAULT_NGPIO 8
> +
> +struct pisosr_gpio {
> + struct gpio_chip chip;
> + struct spi_device *spi;
> + u8 *buffer;
> + size_t buffer_size;
> + struct gpio_desc *load_gpio;
> + struct mutex lock;
> +};
Add kerneldoc to this struct.
> +static inline struct pisosr_gpio *to_pisosr_gpio(struct gpio_chip *chip)
> +{
> + return container_of(chip, struct pisosr_gpio, chip);
> +}
We are doing away with this, but I can fix up the driver by a separate
patch later of we merge it.
> +static int pisosr_gpio_refresh(struct pisosr_gpio *gpio)
> +{
> + int ret;
> +
> + mutex_lock(&gpio->lock);
> +
> + if (gpio->load_gpio) {
> + gpiod_set_value(gpio->load_gpio, 1);
> + udelay(1); /* registers load time (~10ns) */
> + gpiod_set_value(gpio->load_gpio, 0);
> + udelay(1); /* registers recovery time (~5ns) */
So aren't these load/recovery times dependent on the device?
I think these should come from the compatible string.
> +static int pisosr_gpio_get_direction(struct gpio_chip *chip,
> +unsigned offset)
> +{
> + return GPIOF_DIR_IN;
> +}
Just return 1, GPIOF_DIR_IN is for the external API.
> +static int pisosr_gpio_get(struct gpio_chip *chip, unsigned offset)
> +{
> + struct pisosr_gpio *gpio = to_pisosr_gpio(chip);
> +
> + /* Refresh may not always be needed */
> + pisosr_gpio_refresh(gpio);
> +
> + return (gpio->buffer[offset / 8] >> (offset % 8)) & 0x1;
> +}
This looks like a good reason to implement .get_multiple() in the
same way that we have .set_multiple(), so you agree?
But it's not like I'm requiring you to engineer all that. Just an
academic reflection of the fact.
> +static int pisosr_gpio_probe(struct spi_device *spi)
> +{
> + struct pisosr_gpio *gpio;
> + struct device_node *np = spi->dev.of_node;
> + int ret;
To match and get a pointer to a compatible-string-specific data variant,
look at the example in drivers/mfd/tc3589x.c
> + gpio = devm_kzalloc(&spi->dev, sizeof(*gpio), GFP_KERNEL);
> + if (!gpio)
> + return -ENOMEM;
> +
> + spi_set_drvdata(spi, gpio);
> +
> + gpio->chip = template_chip;
> + gpio->chip.parent = &spi->dev;
> + of_property_read_u16(np, "ngpios", &gpio->chip.ngpio);
As I wrote elsewhere, should come from the variant data, based on the
compatible string. ngpios is in case you're not using all of them and
need to restrict the number of used GPIOs. Usually this only applies to
on-SoC GPIOs that are unrouted.
> + gpio->spi = spi;
> +
> + gpio->buffer_size = DIV_ROUND_UP(gpio->chip.ngpio, 8);
> + gpio->buffer = devm_kzalloc(&spi->dev, gpio->buffer_size, GFP_KERNEL);
> + if (!gpio->buffer)
> + return -ENOMEM;
> +
> + gpio->load_gpio = devm_gpiod_get(&spi->dev, "load", GPIOD_OUT_LOW);
> + if (IS_ERR(gpio->load_gpio)) {
> + ret = PTR_ERR(gpio->load_gpio);
> + if (ret != -ENOENT && ret != -ENOSYS) {
> + if (ret != -EPROBE_DEFER)
> + dev_err(&spi->dev, "Unable to allocate reset
> gpio\n");
Reset gpio? Really? Load GPIO?
Apart from that it looks good.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] dt-bindings: GPIO: Add generic serializer binding
On Fri, Dec 11, 2015 at 8:46 PM, Andrew F. Davis wrote: > Add binding for generic parallel-in/serial-out shift register devices > used as GPIO. > > Signed-off-by: Andrew F. Davis > +Generic Parallel-in/Serial-out Shift Register GPIO Driver > + > +This binding describes generic parallel-in/serial-out shift register > +devices that can be used for GPI (General Purpose Input). This includes > +SN74165 serial-out shift registers and the SN65HVS88x series of > +industrial serializers. > + > +Required properties: > + - compatible : Should be "pisosr-gpio". I think it should also define compatible strings on the "vendor,device" format apart from the generic compatible. Sooner or later we may need to differentiate them and then that comes in handy. > + - gpio-controller : Marks the device node as a GPIO controller. > + - #gpio-cells : Should be two. For consumer use see gpio.txt. > + > +Optional properties: > + - ngpios : Number of GPIO lines, default is 8. If you didn't do "pisosr-gpio" but instead "foo,sn74165", maybe you don't need to have this in the device tree but instead it can be determined from the compatible string? In that case do that. > + - load-gpios : GPIO pin specifier attached to load enable, this > + pin is pulsed before reading from the device to > + load input pin values into the the device. OK seems necessary. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] gpio: Add driver for SPI serializers
On Fri, Dec 11, 2015 at 8:46 PM, Andrew F. Davis wrote: > This series adds a GPI(General Purpose Input) driver for generic > parallel-in/serial-out shift registers, such as the SN65HVS882 > that this driver was tested on. This should also work for the rest > of the SN65HVS88x series as well as other 74x165 style devices. Pretty interesting, I'd like you to CC SPI maintainer Mark Brown on this patch series, and the SPI mailing list. Looking closer at the code. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ARM: mvebu: add kirkwood compatibles for cloudengine boards
On Wed, Dec 9, 2015 at 4:27 PM, Gregory CLEMENT wrote: > Hi Linus, > > On mer., déc. 09 2015, Linus Walleij wrote: > >> On Fri, Nov 27, 2015 at 12:00 AM, Linus Walleij >> wrote: >> >>> This adds the compatible strings for Cloudengine PogoPlug E02 and >>> series 4. The former already has a devicetree in the kernel. >>> >>> Cc: devicetree@vger.kernel.org >>> Signed-off-by: Linus Walleij >> >> Kirkwood maintainers: are you queueing this patch with Rob's >> ACK? > > Actually I was waiting for a new version of the series with Adrew's > comment addressed in the 2nd patch before applying the whole series. OK I sent a new one of that earlier today, but I did not resend this one. I think it stand on its own though? The compatible string for the machine was never target of review comments. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/4] pinctrl: rockchip: add support for the rk3228
On Fri, Dec 11, 2015 at 2:30 AM, Jeffy Chen wrote: > The pinctrl of rk3228 is much the same as rk3288's, but > without pmu. > > Signed-off-by: Jeffy Chen > Reviewed-by: Heiko Stuebner > Acked-by: Rob Herring > > --- > > Changes in v2: None Same as I applied then, I also added the same Review/ACKs. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1 1/8] pinctrl: rockchip: add support for the rk3228
On Wed, Dec 9, 2015 at 10:04 AM, Jeffy Chen wrote: > The pinctrl of rk3228 is much the same as rk3288's, but > without pmu. > > Signed-off-by: Jeffy Chen Patch applied with Heiko's and Rob's Review/ACKs. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] Device tree binding documentation for gpio-switch
On Fri, Dec 4, 2015 at 6:31 PM, Martyn Welch
wrote:
> This patch adds documentation for the gpio-switch binding. This binding
> provides a mechanism to bind named links to gpio, with the primary
> purpose of enabling standardised access to switches that might be standard
> across a group of devices but implemented differently on each device.
>
> Signed-off-by: Martyn Welch
As mentioned in the comment to the second patch, this solves the
following generic problem:
Expose a GPIO line to userspace using a specific name
That means basically naming GPIO lines and marking them as
"not used by the operating system".
This is something that has been proposed before, and postponed
because the kernel lacks the right infrastructure.
Markus Pargmann also did a series that add initial values to
hogs, which is the inverse usecase of this, where you want to
*output* something by default, then maybe also make it available
to userspace.
So what we need to see here is a patch series that does all of these
things:
- Name lines
- Sets them to initial values
- Mark them as read-only
- Mark them as "not used by the operating system" so that they
can be default-exported to userspace.
Making *USE* of this naming etc inside the Linux kernel
> +gpio-switch {
> +compatible = "gpio-switch";
> +
> +write-protect {
> +label = "write-protect";
> +gpios = <&gpx3 0 GPIO_ACTIVE_LOW>;
> +read-only;
> +};
This should not need new structures and nodes like this. It should
be part of Documentation/devicetree/bindings/gpio/gpio.txt
and put directly in the gpiochip node.
Maybe as an extension of the existing hogs, but that has already
been tried.
While we can agree on a device tree binding, the kernel still needs
major refactoring to actually expose named GPIOs to userspace,
and that should be done using the new chardev, not with sysfs
links.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 2/4] pinctrl: sunxi: Add H3 PIO controller support
On Fri, Dec 4, 2015 at 10:24 PM, Jens Kuske wrote: > The H3 uses the same pin controller as previous SoC's from Allwinner. > Add support for the pins controlled by the main PIO controller. > > Signed-off-by: Jens Kuske Patch applied with Rob's & Maxime's ACKs. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] Add support for monitoring gpio switches
On Fri, Dec 4, 2015 at 6:31 PM, Martyn Welch wrote: > Select Chromebooks have gpio attached to switches used to cause the > firmware to enter alternative modes of operation and/or control other > device characteristics (such as write protection on flash devices). This > patch adds a driver that exposes a read-only interface to allow these > signals to be read from user space. > > This functionality has been generalised to provide support for any device > with device tree support which needs to identify a gpio as being used for a > specific task. > > Signed-off-by: Martyn Welch If you want to do this thing, also propose a device tree binding document for "gpio-switch". But first (from Documentation/gpio/drivers-on-gpio.txt): - gpio-keys: drivers/input/keyboard/gpio_keys.c is used when your GPIO line can generate interrupts in response to a key press. Also supports debounce. - gpio-keys-polled: drivers/input/keyboard/gpio_keys_polled.c is used when your GPIO line cannot generate interrupts, so it needs to be periodically polled by a timer. - extcon-gpio: drivers/extcon/extcon-gpio.c is used when you need to read an external connector status, such as a headset line for an audio driver or an HDMI connector. It will provide a better userspace sysfs interface than GPIO. So you mean none of these apply for this case? Second: what you want to do is export a number of GPIOs with certain names to userspace. This is something very generic and should be implemented as such, not as something Chromebook-specific. Patches like that has however already been suggested, and I have NACKed them because the GPIO sysfs ABI is insane, and that is why I am refactoring the world to create a proper chardev ABI for GPIO instead. See: http://marc.info/?l=linux-gpio&m=144550276512673&w=2 So for the moment, NACK on this, please participate in creating the *right* ABI for GPIO instead of trying to shoehorn stuff into the dying sysfs ABI. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/3] ARM: dts: enable GPIO-a for Broadcom NSP
On Fri, Dec 4, 2015 at 6:12 PM, Yendapally Reddy Dhananjaya Reddy wrote: > This enables the GPIO-a support for Broadcom NSP SoC > > Signed-off-by: Yendapally Reddy Dhananjaya Reddy Acked-by: Linus Walleij Please merge this through the ARM SoC tree or BCM upstream tree, however that works. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 5/5] gpio: tps65912: Add GPIO driver for the TPS65912 PMIC
On Tue, Dec 1, 2015 at 8:40 PM, Andrew F. Davis wrote: > On 11/30/2015 02:26 AM, Linus Walleij wrote: >> >> On Wed, Nov 18, 2015 at 6:59 PM, Andrew F. Davis wrote: >> >>> This patch adds support for the TPS65912 PMIC GPIOs. >>> >>> TPS65912 has five configurable GPIOs that can be used for several >>> purposes. >>> >>> Signed-off-by: Andrew F. Davis >>> Reviewed-by: Linus Walleij >> >> >> (...) >>> >>> + gpio->tps = dev_get_drvdata(pdev->dev.parent); >>> + gpio->gpio_chip = template_chip; >>> + gpio->gpio_chip.dev = tps->dev; >> >> >> This is now renamed .parent in linux-next. It needs to be changed if the >> code should compile after merge. >> > > Are you able to make this change when you pick this up or would you > like me to resend this? I guess all these need to be applied together? It's probably best if Lee apply all and provide them on an immutable branch, and I will apply fixes on top after pulling that in. I recently did exactly that with an AC97 driver from ALSA SoC. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/6] pinctrl: meson: enable support for external GPIO interrupts
On Tue, Dec 1, 2015 at 5:24 PM, Carlo Caione wrote: > From: Carlo Caione > > In Meson SoCs we have 8 independent GPIO interrupts that can be programmed to > use any of the GPIOs in the chip as interrupt source. > > These GPIOs are managed by GIC but they can be conditioned (and enabled) by > some registers external to the GIC. > > GPIOs |--[mux1 or mux2]--[polarity]--[filter]--[edge_select]--> GIC > > Changelog: > > * V2: > - Introduced .irq_request_resources() and .irq_release_resources() > - s/virq/irq/ and s/pin/hwirq/ > - Moved to the new irq_fwspec > > * V3: > - EXPORT_SYMBOL_GPL for of_irq_find_parent() > - split GPIO management and irqchip side > - the GIC IRQs list is not kept as set of fwspecs. it's now a regular > integer array. > - irq_of_phandle_args_to_fwspec discarded I don't know where this patch set is standing but I get the impression that it still needs revising so waiting for a v4. Given the complex nature of the IRQs I will probably want Marc to provide his Review/ACK before applying. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 4/9] pinctrl: Add support STM32 MCUs
On Tue, Dec 1, 2015 at 10:53 AM, Maxime Coquelin wrote: > 2015-10-17 19:23 GMT+02:00 Maxime Coquelin : >> This patch adds pinctrl and GPIO support to STMicroelectronic's STM32 >> family of MCUs. >> >> While it only supports STM32F429 for now, it has been designed to enable >> support of other MCUs of the family (e.g. STM32F746). >> >> Signed-off-by: Maxime Coquelin >> --- >> drivers/pinctrl/Kconfig |1 + >> drivers/pinctrl/Makefile |1 + >> drivers/pinctrl/stm32/Kconfig | 16 + >> drivers/pinctrl/stm32/Makefile|5 + >> drivers/pinctrl/stm32/pinctrl-stm32.c | 856 +++ >> drivers/pinctrl/stm32/pinctrl-stm32.h | 43 + >> drivers/pinctrl/stm32/pinctrl-stm32f429.c | 1598 >> + >> 7 files changed, 2520 insertions(+) >> create mode 100644 drivers/pinctrl/stm32/Kconfig >> create mode 100644 drivers/pinctrl/stm32/Makefile >> create mode 100644 drivers/pinctrl/stm32/pinctrl-stm32.c >> create mode 100644 drivers/pinctrl/stm32/pinctrl-stm32.h >> create mode 100644 drivers/pinctrl/stm32/pinctrl-stm32f429.c >> > > Gentle reminder, do you know when you will be able to review this driver? I'm a bit overloaded so reviewing of large chunks of code takes time. It would be great if I could have some Reviewed-by tags from someone else who's familiar with pin control. Patrice: do you have a chance to review this driver and help us? Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] dt-bindings: gpio: update desription of LPC32xx GPIO controller
On Mon, Nov 30, 2015 at 1:13 PM, Vladimir Zapolskiy wrote: > [Me] >> The node name is unique enough and is what we use in device >> trees. Get rid of this. > > The node name in most cases and in the example below is "gpio-controller", > at least in this particular case I find it insufficiently informative, P0 > bank is sensibly different from P2, as well as it is different from GPI, > GPIO or GPO. A good mechanism to understand in userspace what particular > bank is involved is wanted here, probably I can add a "label" property? Or > should I replace gpio-controller@xxx device node names with p0@xxx etc.? Userspace is supposed to use the whole filepath in sysfs to identify a device. That should be enough, no matter what name the chip has. Also: see the ongoing discussion and proposed patch for a new userspace ABI based on a character device. We're not too happy about new userspace usecases for GPIO right now, we need to fix the ABI. >>> +- gpio-offset: property of P3/GPIO bank, offset of bits representing >>> + GPIO lines in output and direction registers, >> >> Explain more. I think this should probably be generic and >> described together with ngpios. > > The necessity comes from the fact that there is an intersection of register > spaces for banks P2 and GPIO, when it concerns GPIO, DIR_CLR/DIR_STATE > registers has a bit offset to control GPIO bank lines. So do we think that other hardware will have this property too or is it an nxp,* thing? >>> +- gpios: number of GPIO lines per GPIO bank, if this property is >>> + omitted, then gpio-input-mask must be present, >> >> Use the generic ngpios, also one does not exclude the other, e.g >> if there is 32 gpios, offset it 8 ngpios is 8, we know that >> bits 8..15 are GPIO lines. > > Ok, will use ngpios. Offset feature won't help, because there is no uniform > offset (except 0) for any of the banks... OK let's look closer at it. >>> +- gpio-input-mask: should contain two bitmasks, the first bitmask is >>> + the mapping of GPIO lines to input status register, the second >>> + bitmask should be a subset of the first bitmask and it represents >>> + input GPIO lines, which may serve as an interrupt source, >>> + if gpio-input-mask roperty is omitted, gpios property should be >>> + present, >> >> This is really hopeless to understand. This document needs a >> detailed description about how this GPIO block works so we >> have the background for this. > > I'll add more info, shortly if you once find LPC32xx User's Manual (it is > public), this property contains two values, the first one repeats mapping of > P3_INP_STATE bits to bank specific lines, the second one (subset of the > first) lists input lines, which can produce an interrupt. OK, and should it be an nxp,* property? >>> +- interrupts: list of parent interrupts mapped to input GPIO lines, >>> +- interrupts-extended: list of parent interrupts mapped to input GPIO >>> + lines, used if parent interrupts are provided by more than one >>> + interrupt controller, this option is used by GPI bank, >>> +- interrupt-controller: indicates that GPIO bank may serve as an >>> + interrupt controller, >>> +- #interrupt-cells: if interrupt-controller property is present, >>> + it should be 2, interrupt id and its flags. >> >> You need to add a description of how the block maps IRQs >> to GPIO lines. It seems like it is doing some kind of >> phone-exchange type of thing and just latches the GPIO line >> out to an IRQ line on the interrupt controller, and that is >> why even setting up trigger type has to percolate up to >> the parent? Explain this in this document. > > Will extend this description. Generally your understanding is correct, a > requested GPIO interrupt is propagated to an IRQ chip interrupt, the handled > IRQ chip interrupt is cascaded to the GPIO interrupt, but some specific > handling of both edges type of interrupt is done on GPIO interrupt > controller side, because IRQ chip interrupt can not support edge-both type > of interrupts. OMG that sounds so weird. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] ARM: l2x0: make it possible to disable outer sync from DT
Some RealView platforms have broken outer_sync, see:
http://marc.info/?l=linux-kernel&m=144846940516899&w=2
We got rid of the custom barriers from the machine by disabling
outer sync, but that was just for the boardfile case. We have
to be able to do the same in the device tree case.
Since __l2c_init() is cloning and copying the L2C vtable,
we pass an argument to this function to optionally numb
the outer sync operation if desired, before initializing
the cache.
After this we can set up the cache correctly on the RealView
PB11MPCore, and it boots rock solid with the cache enabled.
Before this, spurious crashes would occur if we try to set
up the cache properly.
Cc: Russell King
Cc: Arnd Bergmann
Cc: devicetree@vger.kernel.org
Signed-off-by: Linus Walleij
---
Documentation/devicetree/bindings/arm/l2cc.txt | 1 +
arch/arm/mm/cache-l2x0.c | 13 ++---
2 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/l2cc.txt
b/Documentation/devicetree/bindings/arm/l2cc.txt
index d181b7c4c522..aae7387acbdb 100644
--- a/Documentation/devicetree/bindings/arm/l2cc.txt
+++ b/Documentation/devicetree/bindings/arm/l2cc.txt
@@ -75,6 +75,7 @@ Optional properties:
specified to indicate that such transforms are precluded.
- arm,parity-enable : enable parity checking on the L2 cache (L220 or PL310).
- arm,parity-disable : disable parity checking on the L2 cache (L220 or PL310).
+- arm,outer-sync-disable : disable the outer sync operation on the L2 cache.
- prefetch-data : Data prefetch. Value: <0> (forcibly disable), <1>
(forcibly enable), property absent (retain settings set by firmware)
- prefetch-instr : Instruction prefetch. Value: <0> (forcibly disable),
diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
index 3f3008e5c662..9f9d54271aad 100644
--- a/arch/arm/mm/cache-l2x0.c
+++ b/arch/arm/mm/cache-l2x0.c
@@ -790,7 +790,7 @@ static const struct l2c_init_data l2c310_init_fns
__initconst = {
};
static int __init __l2c_init(const struct l2c_init_data *data,
-u32 aux_val, u32 aux_mask, u32 cache_id)
+u32 aux_val, u32 aux_mask, u32 cache_id, bool
nosync)
{
struct outer_cache_fns fns;
unsigned way_size_bits, ways;
@@ -866,6 +866,10 @@ static int __init __l2c_init(const struct l2c_init_data
*data,
fns.configure = outer_cache.configure;
if (data->fixup)
data->fixup(l2x0_base, cache_id, &fns);
+ if (nosync) {
+ pr_info("L2C: disabling outer sync\n");
+ fns.sync = NULL;
+ }
/*
* Check if l2x0 controller is already enabled. If we are booting
@@ -925,7 +929,7 @@ void __init l2x0_init(void __iomem *base, u32 aux_val, u32
aux_mask)
if (data->save)
data->save(l2x0_base);
- __l2c_init(data, aux_val, aux_mask, cache_id);
+ __l2c_init(data, aux_val, aux_mask, cache_id, false);
}
#ifdef CONFIG_OF
@@ -1724,6 +1728,7 @@ int __init l2x0_of_init(u32 aux_val, u32 aux_mask)
struct resource res;
u32 cache_id, old_aux;
u32 cache_level = 2;
+ bool nosync = false;
np = of_find_matching_node(NULL, l2x0_ids);
if (!np)
@@ -1762,6 +1767,8 @@ int __init l2x0_of_init(u32 aux_val, u32 aux_mask)
if (cache_level != 2)
pr_err("L2C: device tree specifies invalid cache level\n");
+ nosync = of_property_read_bool(np, "arm,outer-sync-disable");
+
/* Read back current (default) hardware configuration */
if (data->save)
data->save(l2x0_base);
@@ -1776,6 +1783,6 @@ int __init l2x0_of_init(u32 aux_val, u32 aux_mask)
else
cache_id = readl_relaxed(l2x0_base + L2X0_CACHE_ID);
- return __l2c_init(data, aux_val, aux_mask, cache_id);
+ return __l2c_init(data, aux_val, aux_mask, cache_id, nosync);
}
#endif
--
2.4.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/5] pinctrl: mediatek: Add Pinctrl/GPIO/EINT driver for mt2701
On Thu, Nov 26, 2015 at 9:44 AM, Biao Huang wrote: > Add mt2701 support using mediatek common pinctrl driver. > MT2701 have some special pins need an extra setting register > than other ICs, so adding this support to common code. > > Signed-off-by: Biao Huang This looks uncontroversial, but I would like to have some of the other Mediatek driver authors send their Ack/Review tags, so Hongzhou & Yingjoe: can you review this and the other patch to the pin control driver? Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/5] arm: dts: Add pinctrl/GPIO/EINT node for mt2701
On Thu, Nov 26, 2015 at 9:44 AM, Biao Huang wrote: > Add pinctrl and GPIO node to mt2701.dtsi > > Signed-off-by: Biao Huang Acked-by: Linus Walleij Take this through the ARM SoC tree as well. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/5] pinctrl: dt bindings: Add pinfunc header file for mt2701
On Thu, Nov 26, 2015 at 9:44 AM, Biao Huang wrote: > Add pinfunc header file, mt2701 related dts will include it > > Signed-off-by: Biao Huang Acked-by: Linus Walleij Take this through ARM SoC as well. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] ARM: mediatek: Add MT2701 config options for mediatek SoCs.
On Thu, Nov 26, 2015 at 9:44 AM, Biao Huang wrote: > From: Erin Lo > > The upcoming MTK pinctrl driver have a big pin table for each SoC > and we don't want to bloat the kernel binary if we don't need it. > Add config options so we can build for one SoC only. Add MT2701. > > Signed-off-by: Erin Lo Acked-by: Linus Walleij FWIW, take this through the ARM SoC tree, since it's just a Kconfig symbol, the pin control patches should be possible to merge orthogonally. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ARM: mvebu: add kirkwood compatibles for cloudengine boards
On Fri, Nov 27, 2015 at 12:00 AM, Linus Walleij wrote: > This adds the compatible strings for Cloudengine PogoPlug E02 and > series 4. The former already has a devicetree in the kernel. > > Cc: devicetree@vger.kernel.org > Signed-off-by: Linus Walleij Kirkwood maintainers: are you queueing this patch with Rob's ACK? Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 0/5] mfd: tps65912: Driver rewrite with DT support
On Tue, Dec 8, 2015 at 8:16 PM, Mark Brown wrote: > On Mon, Dec 07, 2015 at 01:58:47PM -0600, Andrew F. Davis wrote: > >> As all of this driver should be taken though the MFD tree how >> can this gpiolib change be handled? If we have gpio.parent it >> will not build on MFD, with gpio.dev it will fail to build when >> the changes are merged from the gpio subsystem. As the change >> has not been merged into linux-next as far a I can tell maybe >> this should be taken as is, then when the gpiolib change is >> made this can be changed with all the other drivers? > > Do a cross tree merge in one direction or the other between MFD and GPIO. If Lee makes an immutable branch with this stuff on it I can pull that in and put a fix on top of it (like I recently did with the ASoC AC97 codec). I have "only" renamed the .dev field of struct gpio_chip to .parent but I'm bombing out another 150 or so patches today, ridding all GPIO drivers in the kernel of container_of(). A bit painful but nothing to what tglx has gone through for refactoring IRQ chips... Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] ARM: dts: enable pinctrl for Broadcom NSP
On Wed, Nov 25, 2015 at 1:08 AM, Florian Fainelli wrote: > On 20/11/15 09:58, Yendapally Reddy Dhananjaya Reddy wrote: >> This enables the pinctrl support for Broadcom NSP SoC >> >> Signed-off-by: Yendapally Reddy Dhananjaya Reddy > > Looks like a sane pinctrl node here, unless there are objections, I > would like to go ahead and apply this for v4.5, thanks! I'm waiting for an indication from the other BCM pinctrl maintainers to tell whether this SoC is unique enough to deserve its own driver. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 1/5] Documentation: tps65912: Add DT bindings for the TPS65912 PMIC
On Wed, Nov 18, 2015 at 6:59 PM, Andrew F. Davis wrote: > The TPS65912 PMIC contains several regulators and a GPIO controller. > Add bindings for the TPS65912 PMIC. > > Signed-off-by: Andrew F. Davis Acked-by: Linus Walleij Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] pinctrl: qcom: spmi-mpp: Add pm8994 mpp support
On Wed, Nov 18, 2015 at 1:52 AM, Stephen Boyd wrote: > Update the driver and binding for pm8994-mpp devices. > > Cc: > Cc: "Ivan T. Ivanov" > Cc: Bjorn Andersson > Signed-off-by: Stephen Boyd Patch applied with the ACKs! Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] pinctrl: qcom: spmi-gpio: Add pm8994 gpio support
On Wed, Nov 18, 2015 at 1:52 AM, Stephen Boyd wrote: > Update the binding and driver for pm8994-gpio devices. > > Cc: > Cc: "Ivan T. Ivanov" > Cc: Bjorn Andersson > Signed-off-by: Stephen Boyd Patch applied with the ACKs. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] pinctrl: qcom: Add msm8996 pinctrl driver
On Wed, Nov 18, 2015 at 1:35 AM, Stephen Boyd wrote: > From: Joonwoo Park > > Add initial pinctrl driver to support pin configuration with > pinctrl framework for msm8996. > > Cc: > Cc: Bjorn Andersson > Signed-off-by: Joonwoo Park > [sb...@codeaurora.org: Remove duplicate entries and enums] > Signed-off-by: Stephen Boyd Patch applied with the ACKs! Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/5] pinctrl: meson: enable support for external GPIO interrupts
On Mon, Nov 23, 2015 at 11:16 AM, Carlo Caione wrote: > From: Carlo Caione > > In Meson SoCs we have 8 independent GPIO interrupts that can be programmed to > use any of the GPIOs in the chip as interrupt source. > > These GPIOs are managed by GIC but they can be conditioned (and enabled) by > some registers external to the GIC. > > GPIOs |--[mux1 or mux2]--[polarity]--[filter]--[edge_select]--> GIC > > For discussion see comment to the [PATCH 3/5]. > > Changelog: > > * V2: > - Introduced .irq_request_resources() and .irq_release_resources() > - s/virq/irq/ and s/pin/hwirq/ > - Moved to the new irq_fwspec I'm waiting for the next version of this patch set. However I am a bit concerned that we're starting to have a few GPIO controllers now that are not really cascaded irqchips, but instead just shunt the line through to some other interrupt controller through a mux or latch. We might need to add some handling to gpiolib core that does this, like gpiochip_add_irq_mux() that sets up the irqdomain we have for GPIOLIB_IRQCHIP to be used like this and pull this code into gpiolib to avoid duplication of code and bugs. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/5] of/irq: export of_irq_find_parent again
On Mon, Nov 23, 2015 at 11:16 AM, Carlo Caione wrote: > From: Carlo Caione > > of_irq_find_parent was made static since it had no users outside of > of_irq.c. Export it again since we are going to use it again. > > Signed-off-by: Carlo Caione > --- > drivers/of/irq.c | 2 +- > include/linux/of_irq.h | 6 ++ > 2 files changed, 7 insertions(+), 1 deletion(-) > > diff --git a/drivers/of/irq.c b/drivers/of/irq.c > index 902b89b..45735d5 100644 > --- a/drivers/of/irq.c > +++ b/drivers/of/irq.c > @@ -53,7 +53,7 @@ EXPORT_SYMBOL_GPL(irq_of_parse_and_map); > * Returns a pointer to the interrupt parent node, or NULL if the interrupt > * parent could not be determined. > */ > -static struct device_node *of_irq_find_parent(struct device_node *child) > +struct device_node *of_irq_find_parent(struct device_node *child) If you're making this public you should also EXPORT_SYMBOL_GPL(of_irq_find_parent) I need an ACK from Rob if this should be merged through the GPIO tree. If it is going through the OF tree we'll have to defer the resto of the stuff to the next merge window or set it up on an immutable branch I can pull. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 5/5] pinctrl/lantiq: Implement gpio_chip.to_irq
On Thu, Nov 26, 2015 at 11:00 AM, Martin Schiller wrote:
Please write a commit message.
> From: John Crispin
>
> Signed-off-by: John Crispin
> Signed-off-by: Martin Schiller
> ---
> Changes in v3:
> - Moved this change into a separate patch
(...)
> +static int xway_gpio_to_irq(struct gpio_chip *chip, unsigned offset)
> +{
> + struct ltq_pinmux_info *info = dev_get_drvdata(chip->dev);
> + int i;
> +
> + for (i = 0; i < info->num_exin; i++)
> + if (info->exin[i] == offset)
> + return ltq_eiu_get_irq(i);
> +
> + return -1;
> +}
> +
(...)
> + .to_irq = xway_gpio_to_irq,
Can you explain this a bit, and add a comment in the code as to
what is going on?
I take it that the Lantiq has a dedicated IRQ line for some of the
GPIO lines, referred to as external interrupts, and then you just
go in and grab that frm the external interrupt unit like this?
Looks OK, just send an updated patch with some more
explanations.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 4/5] pinctrl/lantiq: Fix GPIO Setup of GPIO Port3
On Thu, Nov 26, 2015 at 11:00 AM, Martin Schiller wrote: > From: John Crispin > > Signed-off-by: John Crispin > Signed-off-by: Martin Schiller > --- > Changes in v3: > - Moved this change into a separate patch Patch applied, I conjured a commit blurb because this was missing one. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 3/5] pinctrl/lantiq: update devicetree binding in dts file
On Thu, Nov 26, 2015 at 11:00 AM, Martin Schiller wrote: > This patch updates the compatible string in the easy50712.dts file to the new > "lantiq,danube-pinctrl". > > Signed-off-by: Martin Schiller > --- > Changes in v3: > None Acked-by: Linus Walleij Please merge this through the MIPS tree. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/5] pinctrl/lantiq: introduce new dedicated devicetree bindings
On Thu, Nov 26, 2015 at 11:00 AM, Martin Schiller wrote: > This patch introduces new dedicated "lantiq,-pinctrl" devicetree > bindings, where is one of "ase", "danube", "xrx100", "xrx200" or > "xrx300" and marks the "lantiq,pinctrl-xway", "lantiq,pinctrl-ase" and > "lantiq,pinctrl-xr9" bindings as DEPRECATED. > > Based on the newest Lantiq Hardware Description it turend out, that there are > some differences in the GPIO alternative functions of the Danube, xRX100 and > xRX200 families, which makes it impossible to use only one xway_mfp table. > > This patch also adds support for the xRX300 family. > > Signed-off-by: Martin Schiller > --- > Changes in v3: > None Patch applied. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/5] pinctrl/lantiq: updating devicetree binding description
On Thu, Nov 26, 2015 at 11:00 AM, Martin Schiller wrote: > This patch adds the new dedicated "lantiq,-pinctrl" compatible strings > to the devicetree bindings Documentation, where is one of "ase", > "danube", "xrx100", "xrx200" or "xrx300" and marks the "lantiq,pinctrl-xway", > "lantiq,pinctrl-ase" and "lantiq,pinctrl-xr9" compatible strings as > DEPRECATED. > > Signed-off-by: Martin Schiller > Acked-by: Rob Herring > --- > Changes in v3: > None Patch applied. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] dt-bindings: gpio: update desription of LPC32xx GPIO controller
On Fri, Nov 20, 2015 at 2:29 AM, Vladimir Zapolskiy wrote: > For the purpose of better description of NXP LPC32xx GPIO controller > hardware in device tree format, extend the existing description with > device tree subnodes, which represent 6 GPIO banks within the > controller. > > Note, client interface to the GPIO controller is untouched. > > Signed-off-by: Vladimir Zapolskiy (...) > + > +Required properties: > +- reg: should contain 3 integer values: > + 1) GPIO bank id from 0 to 5, > + 2) physical base address of this GPIO bank, > + 3) total size of the GPIO bank registers. If each bank has a unique physical address, it should be a unique device with a compatible string. Below: rethink this. All are named gpio-* which is the generic GPIO namespace and should be documented in Documentation/devicetree/bindings/gpio/gpio.txt so figure out if what you're adding is generic or not. > +Optional properties: > +- gpio-bank-name: human readable name of a GPIO bank, The node name is unique enough and is what we use in device trees. Get rid of this. > +- gpio-no-output-state: property of P2 bank, which has special, > + mapping of its control registers, Looks like it should be nxp,no-output-state > +- gpio-offset: property of P3/GPIO bank, offset of bits representing > + GPIO lines in output and direction registers, Explain more. I think this should probably be generic and described together with ngpios. > +- gpios: number of GPIO lines per GPIO bank, if this property is > + omitted, then gpio-input-mask must be present, Use the generic ngpios, also one does not exclude the other, e.g if there is 32 gpios, offset it 8 ngpios is 8, we know that bits 8..15 are GPIO lines. > +- gpio-input-mask: should contain two bitmasks, the first bitmask is > + the mapping of GPIO lines to input status register, the second > + bitmask should be a subset of the first bitmask and it represents > + input GPIO lines, which may serve as an interrupt source, > + if gpio-input-mask roperty is omitted, gpios property should be > + present, This is really hopeless to understand. This document needs a detailed description about how this GPIO block works so we have the background for this. > +- interrupts: list of parent interrupts mapped to input GPIO lines, > +- interrupts-extended: list of parent interrupts mapped to input GPIO > + lines, used if parent interrupts are provided by more than one > + interrupt controller, this option is used by GPI bank, > +- interrupt-controller: indicates that GPIO bank may serve as an > + interrupt controller, > +- #interrupt-cells: if interrupt-controller property is present, > + it should be 2, interrupt id and its flags. You need to add a description of how the block maps IRQs to GPIO lines. It seems like it is doing some kind of phone-exchange type of thing and just latches the GPIO line out to an IRQ line on the interrupt controller, and that is why even setting up trigger type has to percolate up to the parent? Explain this in this document. > + gpio-output-only; You forgot to documen this property. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] gpio: lpc32xx: add new LPC32xx GPIO controller driver
;
> + if (!bank->base) {
> + dev_err(dev, "cannot map GPIO registers\n");
> + return -ENOMEM;
> + }
If every bank has its own register range it *should* be its own device
too.
> + bank->input_only = of_property_read_bool(node, "gpio-input-only");
> + bank->output_only = of_property_read_bool(node, "gpio-output-only");
> + if (bank->input_only && bank->output_only) {
> + dev_err(dev, "%s: input-only and output-only is invalid\n",
> + node->full_name);
> + return -EINVAL;
> + }
Since these properties are named "gpio-*" not "nxp,*" they should
be documented in Documentation/devicetree/bindings/gpio/gpio.txt
before you use them. (They seem totally reasonable and useful
to me!)
> + of_property_read_u32(node, "gpio-offset", &bank->offset);
What is this exactly?
> +
> + if (of_find_property(node, "gpio-input-mask", &id)) {
> + if (id < 2 * sizeof(u32)) {
> + dev_err(dev, "invalid format of gpio-input-mask\n");
> + return -EINVAL;
> + }
> +
> + of_property_read_u32_index(node, "gpio-input-mask",
> + 0, &bank->input_mask);
> + of_property_read_u32_index(node, "gpio-input-mask",
> + 1, &bank->interrupt_mask);
> +
> + if ((bank->input_mask & bank->interrupt_mask) !=
> + bank->interrupt_mask) {
> + dev_err(dev, "interrupt mask must be a subset of
> input mask\n");
> + return -EINVAL;
> + }
> +
> + ret = lpc32xx_set_irqs(bank, node);
> + if (ret)
> + return ret;
> + }
> +
> + if (bank->input_mask)
> + ngpio = bit_count(bank->input_mask);
> + else
> + of_property_read_u32(node, "gpios", &ngpio);
> + if (!ngpio) {
> + dev_err(dev, "cannot get number of gpios\n");
> + return -EINVAL;
> + }
> +
> + /*
> +* Special handling of P2, the bank does not have output state
> +* register and its mapping starts from direction control registers
> +*/
> + if (of_property_read_bool(node, "gpio-no-output-state")) {
> + bank->output_states = devm_kzalloc(dev, ngpio * (sizeof(u32)),
> + GFP_KERNEL);
> + if (!bank->output_states)
> + return -ENOMEM;
> +
> + bank->input = bank->base + LPC32XX_GPIO_P2_INPUT;
> + bank->output = bank->base + LPC32XX_GPIO_P2_OUTPUT;
> + bank->dir = bank->base + LPC32XX_GPIO_P2_DIR;
> + } else {
> + bank->input = bank->base + LPC32XX_GPIO_INPUT;
> + bank->output = bank->base + LPC32XX_GPIO_OUTPUT;
> + bank->dir = bank->base + LPC32XX_GPIO_DIR;
> + }
> +
> + of_property_read_string(node, "gpio-bank-name", &bank->chip.label);
> + if (bank->chip.label) {
> + ret = lpc32xx_set_gpio_names(bank, ngpio);
> + if (ret)
> + return ret;
> + }
> +
> + /* Default GPIO bank enumeration, first address cell from reg */
> + ret = of_property_read_u32(node, "reg", &id);
> + if (ret < 0 || id >= LPC32XX_GPIO_BANKS) {
> + dev_err(dev, "can not get valid GPIO bank id\n");
> + return -EINVAL;
> + }
> +
> + lpc32xx_gpio_chips[id] = bank;
> +
> + bank->chip.dev = dev;
> +
> + bank->chip.direction_input = lpc32xx_gpio_dir_input;
> + bank->chip.direction_output = lpc32xx_gpio_dir_output;
> + bank->chip.get_direction= lpc32xx_gpio_dir_get;
> +
> + bank->chip.get = lpc32xx_gpio_get;
> + bank->chip.set = lpc32xx_gpio_set;
> +
> + bank->chip.to_irq = lpc32xx_gpio_to_irq;
> +
> + bank->chip.base = id * 32;
Use -1 instead so you get a dynamically assigned base.
> + bank->chip.ngpio= ngpio;
> + bank->chip.names= bank->gpio_names;
> + bank->chip.can_sleep= false;
> +
> + bank->chip.of_xlate = lpc32xx_of_xlate;
> + bank->chip.of_gpio_n_cells = 3;
I wonder if you even need your own translation functions.
With one device per bank, certainly not.
> + bank->chip.of_node = dev->of_node;
> +
> + ret = gpiochip_add(&bank->chip);
> + if (ret)
> + return ret;
> +
> + if (of_find_property(node, "interrupt-controller", NULL)) {
> + if (bank->input_mask)
> + ret = lpc32xx_add_irqchip(bank, node);
> + }
> +
> + return ret;
> +}
> +
> +static int lpc32xx_gpio_remove(struct platform_device *pdev);
> +static int lpc32xx_gpio_probe(struct platform_device *pdev)
> +{
> + struct device_node *child;
> + int ret;
> +
> + for_each_available_child_of_node(pdev->dev.of_node, child) {
> + ret = of_node_to_gpio(&pdev->dev, child);
> + if (ret)
> + goto error;
> + }
If the node in the device tree just declares "simple-bus"
it will spawn devices for all subnodes, if they have
compatible ="" strings.
> +static int lpc32xx_gpio_remove(struct platform_device *pdev)
> +{
> + u32 idx, i;
> + struct irq_domain *irqd;
> +
> + for (idx = 0; idx < LPC32XX_GPIO_BANKS; idx++) {
> + if (!lpc32xx_gpio_chips[idx])
> + continue;
Use the platform device data to find a reference to the chip
and remove it. Get rid of this complicated array. Look
at how other drivers do it.
Just use platform_set_drvdata(pdev, foo); in probe()
then in remove():
struct my_gpio *foo = platform_get_drvdata(pdev);
gpiochip_remove(&foo->gc);
Like that.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] gpio: lpc32xx: add new LPC32xx GPIO controller driver
On Fri, Nov 20, 2015 at 2:29 AM, Vladimir Zapolskiy wrote: > Unfortunately the old driver has too many hacks inherited from the > ancient legacy NXP BSP and I find it can not be maintained, the new > driver has compatible interface to device tree clients, so moving > to the new driver should not impact any GPIO consumers. Has it been tested on the old hardware too? Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 4/4] gpio: tps65086: Add GPO driver for the TPS65086 PMIC
On Fri, Nov 20, 2015 at 12:01 AM, Andrew F. Davis wrote: > Add support for the TPS65086 PMIC GPOs. > > TPS65086 has four configurable GPOs that can be used for several > purposes. These are output only. > > Signed-off-by: Andrew F. Davis (...) > + gpio->tps = dev_get_drvdata(pdev->dev.parent); > + gpio->chip = template_chip; > + gpio->chip.dev = gpio->tps->dev; We have renamed this to .parent in linux-next and it needs to be altered to compile upstream. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 7/7] pinctrl: Rename gpio driver from cygnus to iproc
On Thu, Nov 19, 2015 at 4:52 AM, Pramod Kumar wrote: > Rename gpio driver file name from pinctrl-cygnus-gpio.c to > pinctrl-iproc-gpio.c to make it more generic so that all > iproc based future SoCs using the same gpio block could > use this driver. > > Signed-off-by: Pramod Kumar > Reviewed-by: Ray Jui > Reviewed-by: Scott Branden > Acked-by: Rob Herring Patch applied. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 6/7] Documentation: Rename gpio controller name from cygnus to iproc
On Thu, Nov 19, 2015 at 4:52 AM, Pramod Kumar wrote: > Renamed gpio controller's driver name from cygnus to iproc to make it > more generic so that all iProc based SoCs having the same gpio controller > could use this. > > Signed-off-by: Pramod Kumar > Reviewed-by: Ray Jui > Reviewed-by: Scott Branden Patch applied. Added Rob Herring's ACK. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 5/7] gpio: Rename func/macro/var to IP-block,iproc
On Thu, Nov 19, 2015 at 4:52 AM, Pramod Kumar wrote: > Change functions, macros and variables name from cygnus to IP block, > iproc, so that it could be used in all iproc based future SoCs having > same GPIO controller block. > > Signed-off-by: Pramod Kumar > Reviewed-by: Ray Jui > Reviewed-by: Scott Branden Patch applied. Required some rebasing so check the result. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 4/7] pinctrl: Add new compatible string to GPIO controller driver
On Thu, Nov 19, 2015 at 4:52 AM, Pramod Kumar wrote: > This compatible string should be used for all new iproc based future > SoCs having the same GPIO controller hardware. > > Signed-off-by: Pramod Kumar > Reviewed-by: Ray Jui > Reviewed-by: Scott Branden Patch applied. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/7] pinctrl: use ngpios propety from DT
On Thu, Nov 19, 2015 at 4:52 AM, Pramod Kumar wrote: > Since identical hardware is used in several instances and every > instance will have different in-use pins. Hence extracting this > number from DT via "ngpios" property. > > Signed-off-by: Pramod Kumar > Reviewed-by: Ray Jui > Reviewed-by: Scott Branden Patch applied. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/7] dts: define ngpios property in gpio controller's node
On Thu, Nov 19, 2015 at 4:52 AM, Pramod Kumar wrote: > Add ngpios property in cygnus ASIU, CCM and CRMU gpio controller's node > > Signed-off-by: Pramod Kumar > Reviewed-by: Ray Jui > Reviewed-by: Scott Branden Acked-by I see that Florian has already picked it up, nice! Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/7] dt-binding: Add ngpios property to GPIO controller node
On Thu, Nov 19, 2015 at 4:52 AM, Pramod Kumar wrote: > Add ngpios property to the gpio controller's DT node so that controller > driver extracts total number of in-use gpio lines from DT and removes > dependency on driver. > > Signed-off-by: Pramod Kumar > Reviewed-by: Ray Jui > Reviewed-by: Scott Branden Patch applied with Rob's ACK. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 6/6] gpio: tps65086: Add GPIO driver for the TPS65086 PMIC
On Wed, Nov 4, 2015 at 6:12 PM, Andrew F. Davis wrote: > Add support for the TPS65086 PMIC GPOs. > > TPS65086 has four configurable GPOs that can be used for several > purposes. > > Signed-off-by: Andrew F. Davis (...) > + gpio->tps = dev_get_drvdata(pdev->dev.parent); > + gpio->gpio_chip = template_chip; No gpio->gpio_chip.parent = &pdev->dev? Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 5/5] gpio: tps65912: Add GPIO driver for the TPS65912 PMIC
On Wed, Nov 18, 2015 at 6:59 PM, Andrew F. Davis wrote: > This patch adds support for the TPS65912 PMIC GPIOs. > > TPS65912 has five configurable GPIOs that can be used for several > purposes. > > Signed-off-by: Andrew F. Davis > Reviewed-by: Linus Walleij (...) > + gpio->tps = dev_get_drvdata(pdev->dev.parent); > + gpio->gpio_chip = template_chip; > + gpio->gpio_chip.dev = tps->dev; This is now renamed .parent in linux-next. It needs to be changed if the code should compile after merge. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/2] gpiolib: Add GPIO initialization
On Tue, Nov 17, 2015 at 11:21 AM, Markus Pargmann wrote:
>> +int gpiod_initialize(struct gpio_desc *desc, unsigned long lflags,
>> + enum gpiod_flags dflags)
>> +{
>> + int status;
>> +
>
> Sorry, this is missing a gpiod_parse_flags(). Will fix this and resend
> tomorrow.
I haven't seen a new version, am I looking in the wrong places?
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] ARM: mvebu: add kirkwood compatibles for cloudengine boards
This adds the compatible strings for Cloudengine PogoPlug E02 and series 4. The former already has a devicetree in the kernel. Cc: devicetree@vger.kernel.org Signed-off-by: Linus Walleij --- Documentation/devicetree/bindings/arm/marvell,kirkwood.txt | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/arm/marvell,kirkwood.txt b/Documentation/devicetree/bindings/arm/marvell,kirkwood.txt index 5171ad8f48ff..ab0c9cdf388e 100644 --- a/Documentation/devicetree/bindings/arm/marvell,kirkwood.txt +++ b/Documentation/devicetree/bindings/arm/marvell,kirkwood.txt @@ -24,6 +24,8 @@ board. Currently known boards are: "buffalo,lswxl" "buffalo,lsxhl" "buffalo,lsxl" +"cloudengines,pogo02" +"cloudengines,pogoplugv4" "dlink,dns-320" "dlink,dns-320-a1" "dlink,dns-325" -- 2.4.3 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/2] dt-bindings: GPIO: Add gpio-initval
On Tue, Nov 17, 2015 at 9:35 PM, Rob Herring wrote: > On Tue, Nov 17, 2015 at 11:07:57AM +0100, Markus Pargmann wrote: >> Add a binding for GPIO initialization. > > Some comments, but they are really more on the gpio hog. I must have > missed them. They are already merged, and in use :( >> +Optional properties: >> +- line-name: The GPIO label name. If not present the node name is used. > > We already have "label" for this purpose. I would rather say we already have another instance of "line-name" for this purpose. See Documentation/devicetree/bindings/gpio/gpio.txt "label" was not chosen because it's a Linuxism (that is what the internal API is using) and not to the point. I like the clear "line" specifier over "pin" etc since GPIOs can be chip-internal and what not. >> + The following two options are mutually exclusive. One of them should be >> + specified, but not both: >> +- gpio-hog: A property specifying that this child node represent a GPIO >> hog. >> +- gpio-initval: This GPIO should be initialized to the specified >> configuration. >> + >> + The following three options are mutually exclusive. They change the >> setting of >> + the GPIO pin. One of them should be specified: >> - input: A property specifying to set the GPIO direction as input. >> - output-low A property specifying to set the GPIO direction as output with >> the value low. >> - output-high A property specifying to set the GPIO direction as output with >> the value high. > > If they are mutually exclusive, then it should just be one property with > values. That is much more simple to validate. > > But none of this is really even needed. We can do all this with existing > bindings. Most gpio controllers use 2 cells and the 2nd cell was > reserved for something like this. Simply adding a -gpios property in the > gpio controller node would do the job: > > init-gpios = <&self n (GPIO_ACTIVE_HIGH | GPIO_OUTPUT)>; > hog-gpios = <&self m GPIO_INPUT>; > > Perhaps we don't want to use GPIO_ACTIVE_x here, but we have 31 more > free bits to use. I prefer if the flags to be used for characteristics of the line rather than driving it in any way. Anyway the input/output-low/output-high is already merged, and in use for hogs. We looked at using -gpios in a self-referential manner, but that made it impossible to name the lines, and that is a desired property. Hogged lines need names so we can figure out who is using them during debug etc. It also makes the DT more human-readable. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 6/6] gpio: tps65086: Add GPIO driver for the TPS65086 PMIC
On Tue, Nov 17, 2015 at 5:11 PM, Andrew F. Davis wrote: > On 11/17/2015 03:17 AM, Linus Walleij wrote: >> >> On Wed, Nov 4, 2015 at 6:12 PM, Andrew F. Davis wrote: >> >>> Add support for the TPS65086 PMIC GPOs. >>> >>> TPS65086 has four configurable GPOs that can be used for several >>> purposes. >>> >>> Signed-off-by: Andrew F. Davis >> >> >> OK... >> >>> +static int tps65086_gpio_get(struct gpio_chip *gc, unsigned offset) >>> +static void tps65086_gpio_set(struct gpio_chip *gc, unsigned offset, >> >> >> Just get/set and no get_direction/direction_input/direction_output? >> Are you sure? >> > > Yeah, these are output only, I could probably add get_direction and just > always return output, but setters wouldn't make sense here. It's important that you note in the driver, commit blurb and maybe even Kconfig that these GPIOs are output-only. Someone could get confused. You should implement .direction_output() and return 0, and implement .direction_input and return negative error code. As it is now, it will seem like input is working, while it's not, right? Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ls2080a/dts: Add little endian property for GPIO IP block
On Mon, Nov 16, 2015 at 7:56 PM, Li Yang wrote: > On Mon, Nov 16, 2015 at 9:11 AM, Linus Walleij > wrote: >> On Tue, Nov 3, 2015 at 12:19 PM, Liu Gang wrote: >> >>> The GPIO block for ls2080a platform has little endian registers, >>> the GPIO driver needs this property to read/write registers by >>> right interface. >>> >>> Signed-off-by: Liu Gang >>> >>> diff --git a/Documentation/devicetree/bindings/gpio/gpio-mpc8xxx.txt >>> b/Documentation/devicetree/bindings/gpio/gpio-mpc8xxx.txt >>> index f2455c5..c836dab 100644 >>> --- a/Documentation/devicetree/bindings/gpio/gpio-mpc8xxx.txt >>> +++ b/Documentation/devicetree/bindings/gpio/gpio-mpc8xxx.txt >>> @@ -10,6 +10,9 @@ Required properties: >>>the second cell is used to specify the gpio polarity: >>>0 = active high >>>1 = active low >>> +- little-endian : Should be set if the GPIO has little endian >>> + registers. No the property means the GPIO >>> + registers are big endian mode. >> >> That is a very generic binding and I would like the devicetree >> maintainers to say something about this. >> >> I would be OK if this is specified for *all* gpiochips in >> Documentation/devicetree/bindings/gpio/gpio.txt >> or even higher up in the desriptions. >> >> Just for Freescale seems a bit too local. > > There is already a generic definition at > Documentation/devicetree/bindings/common-properties.txt. But it will > be special for Freescale controller to say that the default is > big-endian for backward compatibility. OK! Why not reference that just like you reference gpio.txt? It fooled me so it will fool others. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] ARM: u300: remove regulator-compatible usage
On Fri, Sep 25, 2015 at 3:51 PM, Javier Martinez Canillas wrote: > The regulator-compatible property from the regulator DT binding was > deprecated and the correct approach is to use the node's name. > > This patch has no functional changes since the values of the node's > name and the regulator-compatible match for all the regulators. > > Signed-off-by: Javier Martinez Canillas Patch applied to ux500-devicetree. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ARM: ux500: remove regulator-compatible usage
On Fri, Sep 25, 2015 at 3:51 PM, Javier Martinez Canillas wrote: > The regulator-compatible property from the regulator DT binding was > deprecated and the correct approach is to use the node's name. > > This patch has no functional changes since the values of the node's > name and the regulator-compatible match for all the regulators. > > Signed-off-by: Javier Martinez Canillas Patch applied on my ux500-devicetree branch, will be in my first pull request to ARM SoC. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 4/7] ARM: at91/dt: sama5d2: add pio controller node
On Tue, Nov 10, 2015 at 1:30 AM, Olof Johansson wrote: > On Mon, Sep 21, 2015 at 11:24 AM, Linus Walleij > wrote: >> On Wed, Sep 16, 2015 at 8:37 AM, Ludovic Desroches >> wrote: >> >>> Add pio4 controller node to enable pinmux and gpio. >>> >>> Signed-off-by: Ludovic Desroches >> >> Patch applied. > > Please don't merge DT changes through driver trees unless there's a > very specific reason to do so, since it introduces random conflicts. Sorry :( Even noted this in the pull request to Torvalds, it was in the bottom of my patch stack so had been in -next for ages, I was afraid it would create more problem than it solves if I reverted the patch, but I guess I should have done so anyways. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/9] includes: dt-bindings: Add STM32F429 pinctrl DT bindings
On Fri, Nov 6, 2015 at 1:57 PM, Maxime Coquelin wrote: > Thinking again at it, I persist to believe have the defines makes it > easier to use. > With auto-completion, it makes it faster and less error prone to > select the right > alternate function without parsing the datasheet. Auto-completion ... should we design our source code to fit certain editors? > But as these defines are not actually used on driver side, maybe I > could just move > them to the dts directory? No strong opinion there. include/dt-bindings is part of the bindings documentation actually so I guess it goes there. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/3] Adding support for NI Ettus Research USRP E3XX pinconf
On Fri, Nov 6, 2015 at 12:41 AM, Moritz Fischer wrote: > I'm planning to use this pinctrl driver to set pins to either > input (do nothing, default), or output with a value of (1 or 0). > > Can I use the 'output-low', 'output-high' bindings to achieve this, > or am I supposed to implement a gpio controller to do this kind of stuff? I'm pretty sure you should implement a GPIO chip for this. output-low and output-high are for things like lines going to a RAM memory that need to be set up as part of a pin control state. > I'm not sure if I'm using the pinctrl framework correctly to achieve this, > any suggestions on how to change a pin from output to input, as the bindings > documentation explicitly states 'input-enable' does *not* affect output. Look at pin controllers also implementing GPIO chips. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 6/6] gpio: tps65086: Add GPIO driver for the TPS65086 PMIC
On Wed, Nov 4, 2015 at 6:12 PM, Andrew F. Davis wrote: > Add support for the TPS65086 PMIC GPOs. > > TPS65086 has four configurable GPOs that can be used for several > purposes. > > Signed-off-by: Andrew F. Davis OK... > +static int tps65086_gpio_get(struct gpio_chip *gc, unsigned offset) > +static void tps65086_gpio_set(struct gpio_chip *gc, unsigned offset, Just get/set and no get_direction/direction_input/direction_output? Are you sure? Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 3/6] Documentation: tps65086: Add DT bindings for the TPS65086 GPO controller
On Wed, Nov 4, 2015 at 6:12 PM, Andrew F. Davis wrote: > The TPS65086 PMIC contains several regulators and a GPO controller. > Add bindings for the TPS65086 GPO controller. > > Signed-off-by: Andrew F. Davis Patch applied to the GPIO tree with Rob's ACK. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RESEND v2 3/4] ARM: BCM: Add SMP support for Broadcom NSP
On Tue, Nov 10, 2015 at 5:21 PM, Kapil Hali wrote: > On 11/10/2015 7:59 AM, Florian Fainelli wrote: >>> Also give it a sane name, bcm_sec_boot_address or so. >>> "secondary_boot" sounds like a function you call to boot >>> the second core. >> >> Agree with that, there could be a better name which better reflects >> this is a variable. >> > As this change is consolidating SMP implementation, I kept the same > name of the variable which was used in kona_smp.c so that the changes > in the common code is minimal. Also, the fact that the change is part > of up-streamed code, I didn't alter with the variable name. Shall I > change it in the next patch? Sure do it any way as long as the end result looks fine. It was not a big issue anyways. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ls2080a/dts: Add little endian property for GPIO IP block
On Tue, Nov 3, 2015 at 12:19 PM, Liu Gang wrote: > The GPIO block for ls2080a platform has little endian registers, > the GPIO driver needs this property to read/write registers by > right interface. > > Signed-off-by: Liu Gang > > diff --git a/Documentation/devicetree/bindings/gpio/gpio-mpc8xxx.txt > b/Documentation/devicetree/bindings/gpio/gpio-mpc8xxx.txt > index f2455c5..c836dab 100644 > --- a/Documentation/devicetree/bindings/gpio/gpio-mpc8xxx.txt > +++ b/Documentation/devicetree/bindings/gpio/gpio-mpc8xxx.txt > @@ -10,6 +10,9 @@ Required properties: >the second cell is used to specify the gpio polarity: >0 = active high >1 = active low > +- little-endian : Should be set if the GPIO has little endian > + registers. No the property means the GPIO > + registers are big endian mode. That is a very generic binding and I would like the devicetree maintainers to say something about this. I would be OK if this is specified for *all* gpiochips in Documentation/devicetree/bindings/gpio/gpio.txt or even higher up in the desriptions. Just for Freescale seems a bit too local. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] drivers/gpio: Port gpio driver to layerscape platform
On Tue, Nov 3, 2015 at 12:19 PM, Liu Gang wrote: > Layerscape has the same ip block/controller as > GPIO on powerpc platform(MPC8XXX). > > So use portable i/o accessors, as in_be32/out_be32 > accessors are Power architecture specific whereas > ioread32/iowrite32 and ioread32be/iowrite32be are > available in other architectures. > > Layerscape GPIO controller's registers may be big > or little endian, so the code needs to get the > endian property from DTB, then make additional > functions to fit right register read/write > operations. > > Currently the code can support ls2080a GPIO with > little endian registers. And it can also work well > on other layerscape platform with big endian GPIO > registers. > > Signed-off-by: Liu Gang > Signed-off-by: Shaveta Leekha This doesn't seem good. You are starting to duplicate stuff that is already available inside the gpio-generic.c driver. Why can't this driver just select GPIO_GENERIC in Kconfig and use the common code for handling the endianness accessors? bgpio_init() takes a flag BGPIOF_BIG_ENDIAN_BYTE_ORDER to make all accesses big endian, so using the generic GPIO library would save you a lot of code. Just look at other drivers for those selecting GPIO_GENERIC, including and calling bgpio_init(). You might want to keep some local custom BE code around the IRQ parts. But I would do two patches: - One that switches MPC8xxx to using GENERIC_GPIO - One that adds BE support using that infrastructure It will result in a lot less code. I think. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] iio: st_sensors: support open drain mode
On Mon, Nov 16, 2015 at 9:57 AM, Linus Walleij wrote: > On Mon, Nov 16, 2015 at 7:15 AM, Denis Ciocca wrote: > >> I'm not convinced about this one. If we declare sensors output as open drain, >> interrupt can be shared (as you also say). >> >> So, the irq management function should first check source registers if >> interrupt is really generated by sensor or not. > > Yeah I was not testing actually using two sensors at the time so far, only > setting this property in the device tree for two sensors so that it was > possible to share a line between two sensors, but I only use one at a > time, I didn't try to start generic_buffer on both similtaneously... > > OK I'll see if we can get the trigger to return IRQ_HANDLED or > IRQ_NO_IRQ. Actually this ties into the IRQ request discussion: to read the status from the sensor, we need to do some I2C traffic, and for that, we need to have a threaded IRQ handler (today we don't have that, we just request a fastpath IRQ using the request_threaded() function), leading back to the other discussion about any_context_irq() and how we should just call down to the trigger layer if we are running a real thread in the IRQ handler. It's a can of worms :D Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] iio: st_sensors: support open drain mode
On Mon, Nov 16, 2015 at 7:15 AM, Denis Ciocca wrote: > I'm not convinced about this one. If we declare sensors output as open drain, > interrupt can be shared (as you also say). > > So, the irq management function should first check source registers if > interrupt is really generated by sensor or not. Yeah I was not testing actually using two sensors at the time so far, only setting this property in the device tree for two sensors so that it was possible to share a line between two sensors, but I only use one at a time, I didn't try to start generic_buffer on both similtaneously... OK I'll see if we can get the trigger to return IRQ_HANDLED or IRQ_NO_IRQ. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] mtd: create a partition type device tree binding
On Fri, Nov 13, 2015 at 11:00 PM, Brian Norris
wrote:
(...)
> (2) we should define a comptible property for the hard-coded
> partitioning case (e.g., compatible = "partitions")
(...)
> If we went with option (2), then ofpart.c could just check only for
> 'compatible = "partitions"' (or similar), and if not found bail out.
So this "hard-coded partitioning case" the case is where all partitions
are defined in the device tree as described in
Documentation/devicetree/bindings/mtd/partition.txt ?
Or is it a way to indicate that this array
static const char * const part_probe_types_def[] = {
"cmdlinepart", "RedBoot", "ofpart", "ofoldpart", NULL };
in physmap_of.c should be used?
Sorry if I don't fully follow, I'm a bit stupid when it comes to the MTD
helicopter view of the situation :(
> I think option (2) makes more sense. But it would require an update to
> the binding and code for 4.4, since [1] was only introduced during this
> release cycle.
Does that mean all old device trees that specify no compatible
string all of a sudden stop working? We can't break the DT ABI, so I
guess not.
A bit confused here, I can't really see what I should do with the patch...
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] iio: st_sensors: support open drain mode
Some types of ST Sensors can be connected to the same IRQ line
as other peripherals using open drain. Add a device tree binding
and a sensor data property to flip the right bit in the interrupt
control register to enable open drain mode on the INT line.
If the line is set to be open drain, also tag on IRQF_SHARED
to the IRQ flags when requesting the interrupt, as the whole
point of using open drain interrupt lines is to share them with
more than one peripheral (wire-or).
Cc: devicetree@vger.kernel.org
Cc: Giuseppe Barba
Cc: Denis Ciocca
Signed-off-by: Linus Walleij
---
Documentation/devicetree/bindings/iio/st-sensors.txt | 3 +++
drivers/iio/accel/st_accel_core.c| 8
drivers/iio/common/st_sensors/st_sensors_core.c | 20
drivers/iio/common/st_sensors/st_sensors_trigger.c | 9 +
drivers/iio/gyro/st_gyro_core.c | 12
drivers/iio/pressure/st_pressure_core.c | 8
include/linux/iio/common/st_sensors.h| 6 ++
include/linux/platform_data/st_sensors_pdata.h | 2 ++
8 files changed, 68 insertions(+)
diff --git a/Documentation/devicetree/bindings/iio/st-sensors.txt
b/Documentation/devicetree/bindings/iio/st-sensors.txt
index d3ccdb190c53..4ac20cb2ae8d 100644
--- a/Documentation/devicetree/bindings/iio/st-sensors.txt
+++ b/Documentation/devicetree/bindings/iio/st-sensors.txt
@@ -16,6 +16,9 @@ Optional properties:
- st,drdy-int-pin: the pin on the package that will be used to signal
"data ready" (valid values: 1 or 2). This property is not configurable
on all sensors.
+- st,int-pin-open-drain: the interrupt/data ready line will be configured
+ as open drain, which is useful if several sensors share the same
+ interrupt line.
Sensors may also have applicable pin control settings, those use the
standard bindings from pinctrl/pinctrl-bindings.txt.
diff --git a/drivers/iio/accel/st_accel_core.c
b/drivers/iio/accel/st_accel_core.c
index 1132224cbc10..888682b95693 100644
--- a/drivers/iio/accel/st_accel_core.c
+++ b/drivers/iio/accel/st_accel_core.c
@@ -96,6 +96,8 @@
#define ST_ACCEL_2_DRDY_IRQ_INT2_MASK 0x10
#define ST_ACCEL_2_IHL_IRQ_ADDR0x22
#define ST_ACCEL_2_IHL_IRQ_MASK0x80
+#define ST_ACCEL_2_OD_IRQ_ADDR 0x22
+#define ST_ACCEL_2_OD_IRQ_MASK 0x40
#define ST_ACCEL_2_MULTIREAD_BIT true
/* CUSTOM VALUES FOR SENSOR 3 */
@@ -177,6 +179,8 @@
#define ST_ACCEL_5_DRDY_IRQ_INT2_MASK 0x20
#define ST_ACCEL_5_IHL_IRQ_ADDR0x22
#define ST_ACCEL_5_IHL_IRQ_MASK0x80
+#define ST_ACCEL_5_OD_IRQ_ADDR 0x22
+#define ST_ACCEL_5_OD_IRQ_MASK 0x40
#define ST_ACCEL_5_IG1_EN_ADDR 0x21
#define ST_ACCEL_5_IG1_EN_MASK 0x08
#define ST_ACCEL_5_MULTIREAD_BIT false
@@ -366,6 +370,8 @@ static const struct st_sensor_settings
st_accel_sensors_settings[] = {
.mask_int2 = ST_ACCEL_2_DRDY_IRQ_INT2_MASK,
.addr_ihl = ST_ACCEL_2_IHL_IRQ_ADDR,
.mask_ihl = ST_ACCEL_2_IHL_IRQ_MASK,
+ .addr_od = ST_ACCEL_2_OD_IRQ_ADDR,
+ .mask_od = ST_ACCEL_2_OD_IRQ_MASK,
},
.multi_read_bit = ST_ACCEL_2_MULTIREAD_BIT,
.bootime = 2,
@@ -552,6 +558,8 @@ static const struct st_sensor_settings
st_accel_sensors_settings[] = {
.mask_int2 = ST_ACCEL_5_DRDY_IRQ_INT2_MASK,
.addr_ihl = ST_ACCEL_5_IHL_IRQ_ADDR,
.mask_ihl = ST_ACCEL_5_IHL_IRQ_MASK,
+ .addr_od = ST_ACCEL_5_OD_IRQ_ADDR,
+ .mask_od = ST_ACCEL_5_OD_IRQ_MASK,
},
.multi_read_bit = ST_ACCEL_5_MULTIREAD_BIT,
.bootime = 2, /* guess */
diff --git a/drivers/iio/common/st_sensors/st_sensors_core.c
b/drivers/iio/common/st_sensors/st_sensors_core.c
index ed6f54d5c932..bff469dd9583 100644
--- a/drivers/iio/common/st_sensors/st_sensors_core.c
+++ b/drivers/iio/common/st_sensors/st_sensors_core.c
@@ -302,6 +302,14 @@ static int st_sensors_set_drdy_int_pin(struct iio_dev
*indio_dev,
return -EINVAL;
}
+ if (pdata->open_drain) {
+ if (!sdata->sensor_settings->drdy_irq.addr_od)
+ dev_err(&indio_dev->dev,
+ "open drain requested but unsupported.\n");
+ else
+ sdata->int_pin_open_drain = true;
+ }
+
return 0;
}
@@ -322,6 +330,8 @@ static struct st_sensors_platform_data
*st_sensors_of_probe(struct device *dev,
else
pdata->drdy_int_pin = defdata ? defdata->drdy_int_pin : 0;
+ pdata-&g
Re: [PATCH 1/3] mtd: create a partition type device tree binding
On Tue, Nov 10, 2015 at 4:26 AM, Brian Norris wrote: > On Fri, Nov 06, 2015 at 08:13:13AM -0600, Rob Herring wrote: >> Since we now have partitions contained in a sub node, how about using >> compatible for that sub node instead. > > That seems like a pretty good idea to me. Hm! That's a clever idea. I'll take a spin on that. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 2/3] pinctrl: e3xx: Adding support for NI Ettus Research USRP E3xx pinconf
On Fri, Nov 6, 2015 at 12:41 AM, Moritz Fischer
wrote:
> The USRP E3XX series requires pinctrl to configure the idle state
> FPGA image for minimizing power consumption.
> This is required since different daughtercards have different uses
> for pins on a common connector.
>
> Signed-off-by: Moritz Fischer
(...)
> +static const struct pinctrl_pin_desc e3xx_pins[] = {
> + /* pin0 doesn't exist */
> + PINCTRL_PIN(1, "DB_1"),
> + PINCTRL_PIN(2, "DB_2"),
(...)
> + PINCTRL_PIN(119, "DB_119"),
> + PINCTRL_PIN(120, "DB_120"),
> +};
These should be the names on the data sheet for the balls/pins on the ASIC.
Is this the case? I saw some discussion with Arnd that indicated it was
rather rail names for a certain board and that is not OK.
> +static int e3xx_pinctrl_get_groups_count(struct pinctrl_dev *pctldev)
> +{
> + return 0;
> +}
> +
> +static const char *e3xx_pinctrl_get_group_name(struct pinctrl_dev *pctldev,
> + unsigned selector)
> +{
> + return NULL;
> +}
> +
> +static int e3xx_pinctrl_get_group_pins(struct pinctrl_dev *pctldev,
> + unsigned selector,
> + const unsigned **pins,
> + unsigned *num_pins)
> +{
> + return -ENOTSUPP;
> +}
Hm maybe we should make these group callbacks optional
in the pinctrl core?
> +static int e3xx_pinconf_cfg_set(struct pinctrl_dev *pctldev,
> + unsigned pin,
> + unsigned long *configs,
> + unsigned num_configs)
> +{
> + u32 reg, mask;
> + int i;
> + struct e3xx_pinctrl *pctrl;
> + unsigned int param, arg;
> +
> + if (pin >= E3XX_NUM_DB_PINS)
> + return -ENOTSUPP;
> + mask = BIT(pin % E3XX_PINS_PER_REG);
> +
> + pctrl = pinctrl_dev_get_drvdata(pctldev);
> +
> + clk_enable(pctrl->clk);
Have you considered using pm_runtime_get_sync() etc with
callbacks instead of hammering clk_enable/disable all the
time? See
drivers/hwtracing/coresight/coresight-replicator.c
for an example of how to do it in the runtime PM ops
callbacks. It requires some tweaks (look closely at all setup
there) but it pays off.
> +static int e3xx_pinconf_group_set(struct pinctrl_dev *pctldev,
> + unsigned selector,
> + unsigned long *configs,
> + unsigned num_configs)
> +{
> + return -EAGAIN;
> +}
Maybe you should group this with the other group callbacks.
Apart from these remarks it looks pretty nice.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RESEND v2 3/4] ARM: BCM: Add SMP support for Broadcom NSP
On Fri, Nov 6, 2015 at 8:49 PM, Kapil Hali wrote:
> Add SMP support for Broadcom's Northstar Plus SoC
> cpu enable method. This changes also consolidates
> iProc family's - BCM NSP and BCM Kona, platform
> SMP handling in a common file.
>
> Northstar Plus SoC is based on ARM Cortex-A9
> revision r3p0 which requires configuration for ARM
> Errata 764369 for SMP. This change adds the needed
> configuration option.
>
> Signed-off-by: Kapil Hali
This version looks saner to me.
> +static int nsp_write_lut(void)
> +{
> + void __iomem *sku_rom_lut;
> + phys_addr_t secondary_startup_phy;
> +
> + if (!secondary_boot) {
> + pr_warn("required secondary boot register not specified\n");
> + return -EINVAL;
> + }
> +
> + sku_rom_lut = ioremap_nocache((phys_addr_t)secondary_boot,
> + sizeof(secondary_boot));
Why is this address not just taken directly from the device tree?
If it is not in the device tree: why?
Also give it a sane name, bcm_sec_boot_address or so.
"secondary_boot" sounds like a function you call to boot
the second core.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RESEND 3/4] ARM: BCM: Add SMP support for Broadcom NSP
On Thu, Nov 5, 2015 at 6:51 AM, Kapil Hali wrote: > Add SMP support for Broadcom's Northstar Plus SoC, > cpu enable method and pen_release procedures. This > changes also consolidates iProc family's - BCM NSP > and BCM Kona, SMP handling in a common file. > > Northstar Plus SoC is based on ARM Cortex-A9 > revision r3p0 which requires configuration for ARM > Errata 764369 for SMP. This change adds the needed > configuration option. > > Signed-off-by: Kapil Hali (...) > +/* > + * iProc specific entry point for secondary CPUs. This provides > + * a "holding pen" into which all secondary cores are held until > + * we are ready for them to initialise. > + */ Do you *REALLY* need the complex pen hold/release semaphore stuff? Consult for example commit c00def71efd919e8ae835a25f4f4c80a4b2d36d3 "ARM: ux500: simplify secondary CPU boot" I realized the pen hold/release stuff was totally surplus on the ux500 platform, it was probably just copied from the Vexpress or RealView reference design and kept around because ARM did things that way. And you are copying the same code from other platforms again. Do you *really* understand the pen hold/release code? (I don't.) In our case it turned out that all that was really needed was: - Map and enable SCU at .smp_prepare_cpus() - Write the start address for the secondary CPU(s) in their magic registers/addresses i.e what you do in nsp_write_lut() and then call arch_send_wakeup_ipi_mask(cpumask_of(cpu)); in .smp_boot_secondary() It seems you may not even need the IPI, I can't see that call in your patch so I guess your secondary CPUs aren't in WFI at boot. No pen hold/release magic! Works like a charm for us. So see of you really need this horror story with copied assembly code from realview etc. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 18/19] ARM: dts: ste: replace legacy *,wakeup property with wakeup-source
On Tue, Oct 27, 2015 at 1:46 PM, Sudeep Holla wrote: > On 27/10/15 12:34, Linus Walleij wrote: >> On Wed, Oct 21, 2015 at 12:10 PM, Sudeep Holla >> wrote: >> >>> Though the keyboard and other driver will continue to support the legacy >>> "gpio-key,wakeup", "linux,wakeup" boolean property to enable the wakeup >>> source, "wakeup-source" is the new standard binding. >>> >>> This patch replaces all the legacy wakeup properties with the unified >>> "wakeup-source" property in order to avoid any futher copy-paste >>> duplication. >>> >>> Cc: Linus Walleij >>> Signed-off-by: Sudeep Holla >> >> >> Acked-by: Linus Walleij >> >> Are you sending this to ARM SoC or do I need to handle the >> patch? >> > > Many platform maintainers preferred to pick up via their tree, so if you > want to pick up with other STE patches, I am fine as there's no > dependency on the driver changes. Patch applied to my ux500-devicetree branch, sorry for the delay. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 5/5] gpio: tps65912: Add GPIO driver for the TPS65912 PMIC
On Fri, Oct 30, 2015 at 12:38 AM, Andrew F. Davis wrote: > This patch adds support for the TPS65912 PMIC GPIOs. > > TPS65912 has five configurable GPIOs that can be used for several > purposes. > > Signed-off-by: Andrew F. Davis This looks like a fine driver, can't really see anything wrong with it so: Reviewed-by: Linus Walleij > +#define to_tps65912_gpio(gc) container_of(gc, struct tps65912_gpio, > gpio_chip) I would rewrite that to static inline however. Lee can take this into the MFD tree with my review-tag if he wants. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] mtd: create a partition type device tree binding
On Thu, Oct 29, 2015 at 5:29 PM, Brian Norris wrote: >> +Required properties: >> +- partition-type : the type of partition. Only one type can be specified. > > You're supporting this as a list property (for future expansion, > presumably), so I can only assume the "only one type" is referring to > the number of different parsers available currently, not the behavior of > the property itself? I was thinking that it would not be a list actually. The reason being that if you're anyways going to the trouble of specifying exactly what partition type is going to be used, you're not really interested in specifying a few different ones, you know exactly what type it is going to be. But if you think it needs to be a list, I'll specify that, no big deal. I'll also try to get the Linux code to handle a list then. > Also, this patch will conflict with [1]. I'll probably take [1] soon, so > one of us will have to rebase this. Sure I'll rebase on whatever you say. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 07/11] pinctrl: use ngpios propety from DT
On Thu, Oct 29, 2015 at 3:47 PM, Jonas Gorski wrote: > Using ngpios to restrict the amount of actually available GPIOs from > the possible amount of GPIOs seems a rather limited use, as rerouted > gpios are seldom at the end of the GPIO space. I need an example. > So maybe it makes more sense to use ngpio as the number of > possible gpios and then have an additional "reserved-gpios" > bitmask / list of unavailable gpios? This idea is good, but let's not make upfront design until we have a piece of hardware that requires exactly this. I sent a patch to the gpio.txt binding including a diplomatic statement on this... > Ideally those would be just consumed by a pinctrl instance, but I > guess that these are sometimes controlled through pinstrapping, > so there might be no driver to attach to them. Uhmm Not quite following but all right... With gpio ranges the GPIO to pins are mapped, and they can switch functions at runtime. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] gpio: dt-bindings: document the official use of "ngpios"
There are a bunch of drivers that utilize the "ngpios" DT property
without any vendor prefix. Try to start cleaning up the mess by
defining what we mean by this property.
Cc: devicetree@vger.kernel.org
Cc: Pramod Kumar
Cc: Jonas Gorski
Signed-off-by: Linus Walleij
---
Documentation/devicetree/bindings/gpio/gpio.txt | 24
1 file changed, 24 insertions(+)
diff --git a/Documentation/devicetree/bindings/gpio/gpio.txt
b/Documentation/devicetree/bindings/gpio/gpio.txt
index 63b1b9039ce8..9b081e6143a0 100644
--- a/Documentation/devicetree/bindings/gpio/gpio.txt
+++ b/Documentation/devicetree/bindings/gpio/gpio.txt
@@ -129,6 +129,30 @@ Every GPIO controller node must contain both an empty
"gpio-controller"
property, and a #gpio-cells integer property, which indicates the number of
cells in a gpio-specifier.
+Optionally, a GPIO controller may have a "ngpios" property. This property
+indicates the number of in-use slots of available slots for GPIOs. The
+typical example is something like this: the hardware register is 32 bits
+wide, but only 18 of the bits have a physical counterpart. The driver is
+generally written so that all 32 bits can be used, but the IP block is reused
+in a lot of designs, some using all 32 bits, some using 18 and some using
+12. In this case, setting "ngpios = <18>;" informs the driver that only the
+first 18 GPIOs, at local offset 0 .. 17, are in use.
+
+If these GPIOs do not happen to be the first N GPIOs at offset 0...N, an
+additional bitmask is needed to specify which GPIOs are actually in use,
+and which are dummies. The bindings for this case has not yet been
+specified, but should be specified if/when such hardware appears.
+
+Example:
+
+gpio-controller@ {
+ compatible = "foo";
+ reg = <0x 0x1000>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ ngpios = <18>;
+}
+
The GPIO chip may contain GPIO hog definitions. GPIO hogging is a mechanism
providing automatic GPIO request and configuration as part of the
gpio-controller's driver probe function.
--
2.4.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 07/11] pinctrl: use ngpios propety from DT
On Wed, Oct 28, 2015 at 12:52 PM, Pramod Kumar wrote: > I discussed with ASIC team regarding this iProc GPIO block. They use a > library to create the GPIOs block where "total number of GPIO pins( let say > N) in GPIO block" is used as an parameter. > Library uses a construct for *a* GPIO pin. This gets instantiated N times to > create a complete GPIO block with N pins. > > All iProc based SoCs uses this library. So I'm not sure whether attaching > "total number of GPIOs pins" to compatible-string make sense in this case. > I personally feel that passing this number from the DT makes more sense here. > Any iProc based future as well as current SoCs would be able to use this > driver without any change. > > Please advise us in this case. Hm! You make a good case. But this contradicts the traditional use of ngpios. But on the other hand: git grep ngpio Documentation/devicetree/bindings/gpio/ Gives at hand that the use of ngpio[s] is a complete mess. :( I will think about patching the standard bindings to fix this mess and include your case. Give me some time. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/3] gpio: arizona: Support Cirrus Logic CS47L24 and WM1831
On Wed, Oct 28, 2015 at 12:42 PM, Lee Jones wrote: > On Tue, 27 Oct 2015, Linus Walleij wrote: > >> On Mon, Oct 19, 2015 at 4:13 PM, Richard Fitzgerald >> wrote: >> >> > The CS47L24 and WM1831 codecs only have two GPIO lines, but are >> > otherwise similar to the WM8280. >> > >> > Signed-off-by: Richard Fitzgerald >> >> Acked-by: Linus Walleij >> >> Lee can merge this into the MFD tree with patch 1/3 if he likes, >> I guess that's simplest. > > I can do. Do you require a pull-request? Nah. I usually optimistically assume that these (small) things will not clash. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/3] gpio: xgene: add support to configure GPIO line as input, output or external IRQ pin
On Mon, Oct 26, 2015 at 7:49 AM, Y Vo wrote:
> Add support to configure GPIO line as input, output or external IRQ pin.
>
> Signed-off-by: Y Vo
As I will say again, this description is too terse, add lots of information
on how IRQs work on this controller please. I get confused.
(...)
> +#define XGENE_GPIO8_HWIRQ 0x48
> +#define XGENE_GPIO8_IDX8
(...)
> +#define XGENE_HWIRQ_TO_GPIO(hwirq) ((hwirq) + XGENE_GPIO8_IDX)
> +#define XGENE_GPIO_TO_HWIRQ(gpio) ((gpio) - XGENE_GPIO8_IDX)
> +#define GIC_IRQ_TO_GPIO_IRQ(hwirq) ((hwirq) - XGENE_GPIO8_HWIRQ)
> +#define GPIO_IRQ_TO_GIC_IRQ(hwirq) ((hwirq) + XGENE_GPIO8_HWIRQ)
I'm a bit uneasy about this, maybe I just don't get it.
What is this indexing into "GIC IRQ" that is starting to happen
here?
The GIC (if that is drivers/irqchip/irq-gic.c) has a totally dynamic IRQ
translation and the Linux IRQs it is using may change. I am worried
that there is some reliance here on Linux IRQ having certain numbers
because there is certainly no ABI like that.
Is this 0x48 really an index into the *hardware* offset in the GIC?
And if it is: why are we not getting this hardware information from the
device tree like all other interrupt numbers and offsets?
I'm worried about this.
> - u32 *irq;
> + void __iomem *regs;
> + struct irq_domain *gic_domain;
> + struct irq_domain *irq_domain;
And there is some secondary gic_domain here, which is confusing
since the GIC does have an IRQ domain too.
I think I want a clear explanation to how this GPIO controller interacts
with the GIC, and I want it to be part of the patch, as comments in the
code and in the commit message (which is way too small for a complex
patch like this).
Otherwise I have no chance to understand what is really going on here.
> +static int xgene_gpio_sb_irq_set_type(struct irq_data *d, unsigned int type)
> +{
> + int hwirq = d->hwirq;
> + int gpio = XGENE_HWIRQ_TO_GPIO(hwirq);
> + struct xgene_gpio_sb *priv = irq_data_get_irq_chip_data(d);
> + int lvl_type;
> + int ret;
> +
> + switch (type & IRQ_TYPE_SENSE_MASK) {
> + case IRQ_TYPE_EDGE_RISING:
> + case IRQ_TYPE_LEVEL_HIGH:
> + lvl_type = GPIO_INT_LVL_LEVEL_HIGH;
> + break;
> + case IRQ_TYPE_EDGE_FALLING:
> + case IRQ_TYPE_LEVEL_LOW:
> + lvl_type = GPIO_INT_LVL_LEVEL_LOW;
> + break;
> + default:
> + return -EINVAL;
> + }
> +
> + ret = gpiochip_lock_as_irq(&priv->bgc.gc, gpio);
> + if (ret) {
> + dev_err(priv->bgc.gc.dev,
> + "Unable to configure XGene GPIO standby pin %d as IRQ\n",
> + gpio);
> + return ret;
> + }
> +
> + if ((gpio >= XGENE_GPIO8_IDX) &&
> + (hwirq < XGENE_MAX_GPIO_DS_IRQ)) {
> + xgene_gpio_set_bit(&priv->bgc, priv->regs + MPA_GPIO_SEL_LO,
> + gpio * 2, 1);
> + xgene_gpio_set_bit(&priv->bgc, priv->regs + MPA_GPIO_INT_LVL,
> + hwirq, lvl_type);
> + }
> + if (type & (IRQ_TYPE_EDGE_RISING | IRQ_TYPE_EDGE_FALLING))
> + irq_set_handler_locked(d, handle_edge_irq);
> + else
> + irq_set_handler_locked(d, handle_level_irq);
> +
> + return 0;
> +}
If you are assigning hadle_edge_irq() your irqchip *must* have an
.irq_ack() callback that acknowledges the IRQs as they come in.
This makes me suspect that you haven't really tested edge
interrupts, because if you did, the kernel would crash as it
is unconditionally calling the .irq_ack() from handle_level_irq().
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] mtd: create a partition type device tree binding
The Linux code in drivers/mtd/maps/physmap_of.c will optionally
look for the linux,part-probe binding for hints on a partition type to
look for in the MTD. It was added in commit 9d5da3a9b849
"mtd: extend physmap_of to let the device tree specify the parition probe"
This solution is too Linux-specific and depend on some
Linux kernel-internal naming conventions. We need a proper
way of describing partition types that follow the pattern set by
other device tree bindings.
Create a "partition-type" binding for this, and add "my" bindings
for "arm,arm-flash-structure" as a starter for others to follow.
A follow-on patch adds support to the Linux kernel to handle this
binding, with some infrastructure for others to use it too.
Cc: devicetree@vger.kernel.org
Cc: Jason Gunthorpe
Cc: Liviu Dudau
Reported-by: Liviu Dudau
Signed-off-by: Linus Walleij
---
.../devicetree/bindings/mtd/mtd-physmap.txt| 2 ++
.../devicetree/bindings/mtd/partition.txt | 35 +++---
2 files changed, 33 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/mtd/mtd-physmap.txt
b/Documentation/devicetree/bindings/mtd/mtd-physmap.txt
index 4a0a48bf4ecb..863560bdbb19 100644
--- a/Documentation/devicetree/bindings/mtd/mtd-physmap.txt
+++ b/Documentation/devicetree/bindings/mtd/mtd-physmap.txt
@@ -23,6 +23,8 @@ file systems on embedded devices.
unaligned accesses as implemented in the JFFS2 code via memcpy().
By defining "no-unaligned-direct-access", the flash will not be
exposed directly to the MTD users (e.g. JFFS2) any more.
+ - partition-type : a flash partition type to expect and probe for
+ on this device. See "partition.txt" for available partition types.
- linux,mtd-name: allow to specify the mtd name for retro capability with
physmap-flash drivers as boot loader pass the mtd partition via the old
device name physmap-flash.
diff --git a/Documentation/devicetree/bindings/mtd/partition.txt
b/Documentation/devicetree/bindings/mtd/partition.txt
index 8e5557da1955..85d45764a4b3 100644
--- a/Documentation/devicetree/bindings/mtd/partition.txt
+++ b/Documentation/devicetree/bindings/mtd/partition.txt
@@ -1,9 +1,36 @@
Representing flash partitions in devicetree
-Partitions can be represented by sub-nodes of an mtd device. This can be used
-on platforms which have strong conventions about which portions of a flash are
-used for what purposes, but which don't use an on-flash partition table such
-as RedBoot.
+On-device partition types:
+
+It is possible for some drivers to indicate an on-device partition type, i.e.
+partition tables, footers or other binary pattern in the flash used to
+define how the flash is partitioned. This can be done in the device tree node
+of an MTD device by specifying partition-type = "foo"; This tells the operating
+system to look for the partition type indicated.
+
+Required properties:
+- partition-type : the type of partition. Only one type can be specified.
+ Valid types are:
+ "arm,arm-flash-structure" (also called AFS)
+
+Example:
+
+flash0@4000 {
+ /* 2 * 32MiB NOR Flash memory */
+ compatible = "arm,vexpress-flash", "cfi-flash";
+ partition-type = "arm,arm-flash-structure";
+ reg = <0x4000 0x0400>;
+ bank-width = <4>;
+};
+
+
+Device Tree specified partitions:
+
+If there is no specified on-device binary format, partitions can be
+represented by sub-nodes of an mtd device. This can be used on platforms which
+have strong conventions about which portions of a flash are used for what
+purposes.
+
NOTE: if the sub-node has a compatible string, then it is not a partition.
#address-cells & #size-cells must both be present in the mtd device. There are
--
2.4.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 8/9] ARM: dts: Add leds support to STM32F429 Discovery board
On Tue, Oct 27, 2015 at 10:37 PM, Andreas Färber wrote: > Am 27.10.2015 um 21:31 schrieb Maxime Coquelin: >> 2015-10-26 14:41 GMT+01:00 Linus Walleij : >>> Usually people also want to add a default linux,trigger to these, >>> like linux,default-trigger = "heartbeat"; but whatever you prefer. >> >> Makes sense, I will add default trigger in next version. > > Previously, consensus seemed to be not to use heartbeat as default, but > rather off or on. Which consensus, where, and for whom? Heartbeat is awesome. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 1/2] Documentation: ad5592r: Added devicetree bindings documentation
On Tue, Oct 27, 2015 at 5:13 PM, Linus Walleij wrote: > There are other problems though, but I comment on these > separately. Was wrong about that. I think this can go in like this. Later, this device may fork off a GPIO chip as well, but we will deal with that whenever we run into it. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 1/2] Documentation: ad5592r: Added devicetree bindings documentation
On Sun, Oct 25, 2015 at 2:31 PM, Jonathan Cameron wrote: > On 13/10/15 10:37, Paul Cercueil wrote: >> Signed-off-by: Paul Cercueil > Looks good to me, but as it is a little bit 'different' and we are > defining entirely new generic bindings (the channel modes stuff) > I would like some more input. It might be overkill but we do > of course have the pinctl framework which covers this sort of > thing... Might be worth considering if using that to get the unified > bindings might make sense here... > > cc'd Linus in case he wants to comment on this. > > It would obviously be a very heavy weight solution to the problem > so I'm far from convinced it makes sense - or even fits the usecase > terrible well. Just thought I'd mention the possibility. There is something of a grey area between "definately pin control" and "some extra pin hardware duct-taped to something else". I guess that is natural, life is full of grey areas... Basically if there are plenty of pins and functions, local solutions to the problem will not scale. Then it is necessary to go ahead and implement full pin control. Especially for say a big BGA package or so with lots and lots of pins. It is is a few pins or they just alter between similar functionality (like different graphic modes) I think local solutions are OK. There are other problems though, but I comment on these separately. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] ARM: zynq: DT: Add interrupt-controller property to GPIO
On Fri, Oct 23, 2015 at 6:25 PM, Soren Brinkmann wrote: > GPIO can be used as interrupt-controller. Add the missing properties to > the GPIO node. > > Signed-off-by: Soren Brinkmann Acked-by: Linus Walleij Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] DT binding: gpio-zynq: Document interrupt-controller
On Fri, Oct 23, 2015 at 6:25 PM, Soren Brinkmann wrote: > HW and driver support the GPIO as interrupt-controller. Document that in > the DT binding. > > Signed-off-by: Soren Brinkmann Patch subject augmented and applied. > +- interrupt-controller : Marks the device node as an interrupt controller. > +- #interrupt-cells : Should be 2. The first cell is the GPIO number. > + The second cell bits[3:0] is used to specify > trigger type and level flags: > + 1 = low-to-high edge triggered. > + 2 = high-to-low edge triggered. > + 4 = active high level-sensitive. > + 8 = active low level-sensitive. If these can be or:ed together, e.g 3 = both edges, that needs to be documented. If they can't the current patch is fine I guess. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 18/19] ARM: dts: ste: replace legacy *,wakeup property with wakeup-source
On Wed, Oct 21, 2015 at 12:10 PM, Sudeep Holla wrote: > Though the keyboard and other driver will continue to support the legacy > "gpio-key,wakeup", "linux,wakeup" boolean property to enable the wakeup > source, "wakeup-source" is the new standard binding. > > This patch replaces all the legacy wakeup properties with the unified > "wakeup-source" property in order to avoid any futher copy-paste > duplication. > > Cc: Linus Walleij > Signed-off-by: Sudeep Holla Acked-by: Linus Walleij Are you sending this to ARM SoC or do I need to handle the patch? Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
