Re: How about a gpio_get(device *, char *) function?

2012-11-26 Thread Grant Likely
On Mon, 5 Nov 2012 13:09:20 +0100, Linus Walleij wrote: > On Mon, Nov 5, 2012 at 8:31 AM, Alex Courbot wrote: > > > Interesting. I see you already gave the whole thing a thought. What I don't > > understand however is what is so wrong with the current GPIO numberspace > > that > > you want to

Re: [PATCH] of: When constructing the bus id consider assigned-addresses as well

2012-11-26 Thread Grant Likely
de, "assigned-addresses", NULL); > if (reg) { > if (of_can_translate_address(node)) { > addr = of_translate_address(node, reg); > -- > 1.7.5.4 > -- Grant Likely, B.Sc, P.Eng. Secret Lab Technologies, Ltd. -- To unsubscribe from this

Re: [PATCH] of/i2c: support more interrupt specifiers

2012-11-26 Thread Grant Likely
On Mon, 26 Nov 2012 14:11:27 +0900, Bongkyu Kim wrote: > On 11/21/2012 10:41 PM, Rob Herring wrote: > > On 11/21/2012 02:58 AM, Bongkyu Kim wrote: > >> This patch supports more interrupt specifiers for i2c client. > > > > Why? > > > > If we are registering a device has 2 interrupts like the bel

Re: [PATCHv9 1/3] Runtime Interpreted Power Sequences

2012-11-26 Thread Grant Likely
On Thu, 22 Nov 2012 22:40:21 +0100, Thierry Reding wrote: > On Thu, Nov 22, 2012 at 01:39:41PM +0000, Grant Likely wrote: > [...] > > I do think that each sequence should be contained within a single > > property, but I'm open to other suggestions. > > IIRC a very

Re: [PATCH] of: Have of_device_add call platform_device_add rather than device_add

2012-11-26 Thread Grant Likely
On Thu, 22 Nov 2012 10:30:20 -0700, Jason Gunthorpe wrote: > On Thu, Nov 22, 2012 at 03:36:21PM +0000, Grant Likely wrote: > > > Hmm... I've not tried it with assigned-address. I tried with two sibling > > platform devices using just the 'reg' property. That t

Re: How about a gpio_get(device *, char *) function?

2012-11-26 Thread Grant Likely
y the same way, or if implemented after the rework, it > > would return whatever handle type was in use at the time. > > Yes, I just think we should return an opaque struct from day 1, so > just a little, little bit more to shield us. > > Yours, > Linus Walleij -- Grant

Re: [PATCH] gpio: New driver for GPO emulation using PWM generators

2012-11-26 Thread Grant Likely
On Fri, 23 Nov 2012 10:44:36 +0100, Peter Ujfalusi wrote: > Hi Grant, > > On 11/23/2012 10:13 AM, Peter Ujfalusi wrote: > > Hi Grant, > > > > On 11/23/2012 08:55 AM, Grant Likely wrote: > >> Ugh. and this is why I wanted the PWM and GPIO subsystems to use

Re: [PATCH] of: Have of_device_add call platform_device_add rather than device_add

2012-11-26 Thread Grant Likely
On Thu, 22 Nov 2012 10:30:20 -0700, Jason Gunthorpe wrote: > On Thu, Nov 22, 2012 at 03:36:21PM +0000, Grant Likely wrote: > > > Hmm... I've not tried it with assigned-address. I tried with two sibling > > platform devices using just the 'reg' property. That t

Re: How about a gpio_get(device *, char *) function?

2012-11-26 Thread Grant Likely
ce that may use it. It if was possible to reference > GPIOs > by names that resolve to different GPIO numbers according to the device, then > the problem would be solved. > > There are probably other use-cases that would benefit from this, if you know > of > one please f

Re: [PATCH 2/4 v2] irqdomain: augment add_simple() to allocate descs

2012-11-26 Thread Grant Likely
t be allocated, e.g. if a > platform has the bad habit of hogging descriptors at boot > time. > > Cc: Rob Herring > Cc: Thomas Gleixner > Cc: Grant Likely > Cc: Paul Mundt > Cc: Russell King > Cc: Lee Jones > Signed-off-by: Linus Walleij > --- > ChangeLog

Re: [PATCH V3 3/3] mfd: stmpe: Update DT support in stmpe driver

2012-11-26 Thread Grant Likely
On Fri, 23 Nov 2012 23:03:47 +0530, Viresh Kumar wrote: > On 23 November 2012 15:11, Grant Likely wrote: > > On Fri, 23 Nov 2012 00:26:20 +0530, Viresh Kumar > > wrote: > > >> + - irq-trigger : IRQ trigger to use for the > >> inter

Re: [PATCH 2/4] irqdomain: augment add_simple() to allocate descs

2012-11-26 Thread Grant Likely
On Thu, 27 Sep 2012 08:41:53 -0500, Rob Herring wrote: > On 09/27/2012 08:13 AM, Linus Walleij wrote: > > --- > > kernel/irq/irqdomain.c | 21 - > > 1 file changed, 16 insertions(+), 5 deletions(-) > > > > diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c > > index

Re: [PATCH] wm831x: Add and use a wm831x_irq_byname convenience function

2012-11-26 Thread Grant Likely
On Wed, 17 Oct 2012 11:00:55 -0700, Joe Perches wrote: > Add and use a convenience inline to get an irq by name. > > Signed-off-by: Joe Perches > --- > Perhaps this is a better alternative to code reflowing. > > include/linux/mfd/wm831x/core.h | 8 > drivers/input/touchscreen/w

Re: [PATCH] No need to call irq_domain_legacy_revmap() for twice

2012-11-26 Thread Grant Likely
On Mon, 24 Sep 2012 17:37:55 +0800, Mike Qiu wrote: > Function irq_create_mapping() calls irq_find_mapping(). The later > function has checked if the indicated IRQ domain has hw IRQ mapped to > virtual IRQ through legacy mode or not and return the value of the > legacy irq number by call irq_domai

Re: [PATCH] clk: Make the generic clock API available by default

2012-11-26 Thread Grant Likely
> for the clock API at platform level. > > Signed-off-by: Mark Brown > Acked-by: Hans-Christian Egtvedt > Acked-by: Benjamin Herrenschmidt Looks reasonable to me. Acked-by: Grant Likely g. > --- > arch/arm/Kconfig | 12 > arch/avr32/Kconf

Re: [PATCH] gpio: New driver for GPO emulation using PWM generators

2012-11-29 Thread Grant Likely
On Wed, 28 Nov 2012 09:54:57 +0100, Peter Ujfalusi wrote: > Hi Grant, Lars, Thierry, > > On 11/26/2012 04:46 PM, Grant Likely wrote: > > You're effectively asking the pwm layer to behave like a gpio (which > > is completely reasonable). Having a completely separate t

Re: [PATCH] of: When constructing the bus id consider assigned-addresses as well

2012-11-29 Thread Grant Likely
On Mon, 26 Nov 2012 11:20:54 -0700, Jason Gunthorpe wrote: > On Mon, Nov 26, 2012 at 02:03:16PM +0000, Grant Likely wrote: > > On Wed, 21 Nov 2012 14:02:40 -0700, Jason Gunthorpe > > wrote: > > > 'assigned-addresses' is used for certain PCI device type nodes i

Re: [linux-keystone] [PATCH] watchdog: davinci_wdt: add OF support

2012-11-29 Thread Grant Likely
On Mon, 26 Nov 2012 16:41:35 -0500, Murali Karicheri wrote: > This adds OF support for davinci_wdt driver. > > Signed-off-by: Murali Karicheri Acked-by: Grant Likely > --- > .../devicetree/bindings/watchdog/davinci-wdt.txt | 12 > drivers/watc

Re: [PATCH v2] drivers/of: Constify device_node->name and ->path_component_name

2012-11-29 Thread Grant Likely
On Wed, 28 Nov 2012 10:46:04 +1100, Michael Neuling wrote: > > Neither of these should ever be changed once set. Make them const and > > fix up the users that try to modify it in-place. In one case > > kmalloc+memcpy is replaced with kstrdup() to avoid modifying the string. > > > > Build tested w

Re: How about a gpio_get(device *, char *) function?

2012-11-29 Thread Grant Likely
On Wed, 28 Nov 2012 12:38:38 +0900, Alex Courbot wrote: > On Monday 26 November 2012 19:14:31 Grant Likely wrote: > > I don't have any problem with a gpio_get function, but I do agree that > > making it return an opaque handle is how it should be written with a new >

Re: IRQ subsystem menu

2012-11-29 Thread Grant Likely
On Mon, 29 Oct 2012 15:03:08 +0100, Michal Marek wrote: > (Adding lkml and Thomas as IRQ subsystem maintainer to CC) > > On Sun, Oct 21, 2012 at 03:40:16AM -0400, Paul Thompson wrote: > > Hi; > > > > In menuconfig, General setup -> IRQ subsystem, there are two > > possible menu-items. On

Re: linux-next: manual merge of the gpio tree with the driver-core tree

2012-11-29 Thread Grant Likely
return 0; > - } > - > - static void em_gio_irq_domain_cleanup(struct em_gio_priv *p) > - { > - struct gpio_em_config *pdata = p->pdev->dev.platform_data; > - > - irq_free_descs(p->irq_base, pdata->number_of_pins); > - /* FIXME: irq domain wants

Re: [PATCH] irqdomain: stop screaming about preallocated irqdescs

2012-11-30 Thread Grant Likely
On Tue, 27 Nov 2012 01:20:32 +0100, Linus Walleij wrote: > From: Linus Walleij > > In the simple irqdomain: don't shout warnings to the user, > there is no point. An informational print is sufficient. > > Cc: Rob Herring > Cc: Grant Likely > Cc: Thomas Gle

Re: SPARC and OF_GPIO

2012-11-30 Thread Grant Likely
controller, then the irq number won't be known until after the gpio driver .probe occurs. For addresses, this situation is unlikely, but for all the other kinds of resources (gpios, regs, clocks, irqs, etc) it is a problem that we're actually seeing. g. -- Grant Likely, B.Sc, P.Eng. Sec

Re: [PATCH] of: When constructing the bus id consider assigned-addresses as well

2012-11-30 Thread Grant Likely
On Thu, 29 Nov 2012 12:38:29 -0700, Jason Gunthorpe wrote: > On Thu, Nov 29, 2012 at 04:26:48PM +0000, Grant Likely wrote: > > > Hmmm. okay that makes sense, but something still isn't quite right. So > > of_translate_address should take care of drilling down through the b

Re: [PATCH -next] of: export "allnodes" to fixx w1-gpio.c modular build

2012-11-30 Thread Grant Likely
On Thu, 29 Nov 2012 15:43:08 -0800, Randy Dunlap wrote: > From: Randy Dunlap > > Fix build when CONFIG_W1_MASTER_GPIO=m by exporting "allnodes". > > ERROR: "allnodes" [drivers/w1/masters/w1-gpio.ko] undefined! > > Signed-off-by: Randy Dunlap > Cc: Ville Syrjala > --- > drivers/of/base.c |

Re: SPARC and OF_GPIO

2012-11-30 Thread Grant Likely
On Fri, Nov 30, 2012 at 9:40 AM, Thierry Reding wrote: > On Fri, Nov 30, 2012 at 09:35:20AM +0000, Grant Likely wrote: >> On Wed, 07 Nov 2012 02:34:19 -0500 (EST), David Miller >> wrote: >> > From: Thierry Reding >> > Date: Wed, 7 Nov 2012 07:52:58 +0100 >

[PATCH] Fix build when CONFIG_W1_MASTER_GPIO=m b exporting "allnodes"

2012-11-30 Thread Grant Likely
From: Randy Dunlap ERROR: "allnodes" [drivers/w1/masters/w1-gpio.ko] undefined! Signed-off-by: Randy Dunlap [grant.likely: allnodes is too generic; rename to of_allnodes] Signed-off-by: Grant Likely Cc: Ville Syrjala --- arch/arm/mach-vexpress/v2m.c |2 +- drivers

Re: [PATCH] gpio: New driver for GPO emulation using PWM generators

2012-11-30 Thread Grant Likely
On Fri, 30 Nov 2012 07:47:52 +0100, Thierry Reding wrote: > On Thu, Nov 29, 2012 at 04:10:24PM +0000, Grant Likely wrote: > > On Wed, 28 Nov 2012 09:54:57 +0100, Peter Ujfalusi > > wrote: > > > Hi Grant, Lars, Thierry, > > > > > > On 11/26/2012 04

Re: [PATCH 3/6] OF: Export all DT proc update functions

2013-03-19 Thread Grant Likely
On Tue, 19 Mar 2013 13:42:32 +0200, Pantelis Antoniou wrote: > Hi Grant, > > The 3rd patch is in preparation for some patches I have in WIP that would > allow > drivers to set notifications for properties that are changed in runtime. Okay, submit it with that series then please. g. -- To uns

Re: [PATCH 5/6] OF: Introduce Device Tree resolve support.

2013-03-19 Thread Grant Likely
On Tue, 19 Mar 2013 13:51:01 +0200, Pantelis Antoniou wrote: > Hi Grant, > > On Mar 16, 2013, at 11:24 AM, Grant Likely wrote: > > > On Wed, 23 Jan 2013 12:58:02 +0200, Pantelis Antoniou > > wrote: > >> Hi David, > >> > >> On Jan

[PATCH 0/2] of: Create sysfs view of device tree nodes

2013-03-20 Thread Grant Likely
Hi all, This series reworks the device tree userspace view to be exposed via sysfs. I've been wanting to move to using kobjects to manage the device tree for a while now. It results in less code overall, and it gives us the userspace view "for free". The first patch converts the device_nodes into

[PATCH 1/2] of: Make device nodes kobjects so they show up in sysfs

2013-03-20 Thread Grant Likely
rhead, but at the cost of more complexity in the sysfs support code. However, I'm hopeful that these problems are just imaginary and we can stick with normal sysfs attributes. Signed-off-by: Grant Likely Cc: Rob Herring Cc: Greg Kroah-Hartman Cc: Benjamin Herrenschmidt Cc:

[PATCH 2/2] of: remove /proc/device-tree

2013-03-20 Thread Grant Likely
The same data is now available in sysfs, so we can remove the code that exports it in /proc and replace it with a symlink to the sysfs version. Tested on versatile qemu model and mpc5200 eval board. More testing would be appreciated. Signed-off-by: Grant Likely Cc: Rob Herring Cc: Greg Kroah

Re: linux-next: build failure after merge of the final tree (gpio tree relatred)

2013-03-20 Thread Grant Likely
On Wed, Mar 20, 2013 at 3:25 PM, Stephen Rothwell wrote: > Hi Grant, > > On Wed, 6 Mar 2013 09:10:42 +0800 Grant Likely > wrote: >> >> On Wed, Mar 6, 2013 at 8:44 AM, Stephen Rothwell >> wrote: >> > Caused by commit 82d4d6637fdf ("gpio/palmas: add i

Re: [PATCH 2/2] of: remove /proc/device-tree

2013-03-20 Thread Grant Likely
On Wed, Mar 20, 2013 at 4:24 PM, Daniel Mack wrote: > On Wed, Mar 20, 2013 at 4:19 PM, Rob Herring wrote: >> On 03/20/2013 09:51 AM, Grant Likely wrote: >>> The same data is now available in sysfs, so we can remove the code >>> that exports it in /proc and replace it

Re: [PATCH 1/2] of: Make device nodes kobjects so they show up in sysfs

2013-03-20 Thread Grant Likely
On Wed, Mar 20, 2013 at 2:57 PM, Benjamin Herrenschmidt wrote: > On Wed, 2013-03-20 at 14:51 +0000, Grant Likely wrote: >> Both of the above problems can be worked around by using >> sysfs_create_bin_file() instead of sysfs_create_file(), but doing so >> adds an additio

Re: [PATCH 2/2] of: remove /proc/device-tree

2013-03-20 Thread Grant Likely
On Wed, Mar 20, 2013 at 2:57 PM, Benjamin Herrenschmidt wrote: > On Wed, 2013-03-20 at 14:51 +0000, Grant Likely wrote: >> The same data is now available in sysfs, so we can remove the code >> that exports it in /proc and replace it with a symlink to the sysfs >> ver

Re: New tree for linux-next

2013-03-20 Thread Grant Likely
On Wed, Mar 20, 2013 at 11:47 PM, Stephen Rothwell wrote: > Hi Alexandre, > > On Wed, 20 Mar 2013 23:02:14 +0900 Alexandre Courbot wrote: >> >> I am currently trying to get rid of the GENERIC_GPIO config option in >> order to center GPIO support around gpiolib. The patch series has been >> rathe

Re: [PATCH 2/2] of: remove /proc/device-tree

2013-03-21 Thread Grant Likely
On Thu, Mar 21, 2013 at 4:19 AM, Benjamin Herrenschmidt wrote: > On Wed, 2013-03-20 at 21:38 +0000, Grant Likely wrote: >> > NAK. It should at the very least be a CONFIG option for a while >> before >> > completely switching over. >> >> I

Re: [PATCH 2/2] of: remove /proc/device-tree

2013-03-21 Thread Grant Likely
On Thu, Mar 21, 2013 at 7:43 AM, Benjamin Herrenschmidt wrote: > On Thu, 2013-03-21 at 07:35 +0000, Grant Likely wrote: >> > Shouldn't we have the symlink just be a config option itself ? >> > Eventually distros might want get rid of it completely .. >> >>

[PATCH V2 1/2] of: Make device nodes kobjects so they show up in sysfs

2013-03-21 Thread Grant Likely
e the problem of reporting incorrect property size. Signed-off-by: Grant Likely Cc: Rob Herring Cc: Greg Kroah-Hartman Cc: Benjamin Herrenschmidt Cc: David S. Miller --- Documentation/ABI/testing/sysfs-firmware-ofw | 28 ++ arch/arm/boot/dts/testcases/tests-phandle.dtsi |1 + dr

[PATCH V2 2/2] of: remove /proc/device-tree

2013-03-21 Thread Grant Likely
The same data is now available in sysfs, so we can remove the code that exports it in /proc and replace it with a symlink to the sysfs version. Tested on versatile qemu model and mpc5200 eval board. More testing would be appreciated. Signed-off-by: Grant Likely Cc: Rob Herring Cc: Greg Kroah

Kobjectify device tree structures

2013-03-21 Thread Grant Likely
Hi all, I've reworked the series to use sysfs bin files which has eliminated the problems with filesize from the first version and results in simpler code overall. Even though I'm posting both patches now, there can be a delay between applying the first and the second. After the first one is appli

Re: Kobjectify device tree structures

2013-03-21 Thread Grant Likely
On Thu, Mar 21, 2013 at 12:39 PM, Benjamin Herrenschmidt wrote: > On Thu, 2013-03-21 at 11:24 +0000, Grant Likely wrote: >> 11 files changed, 147 insertions(+), 342 deletions(-) > > Nice :-) :-) Thanks! ...and about 20% of the additions are ABI documentation. g. -- To unsubs

Re: [PATCH 2/2] of: remove /proc/device-tree

2013-03-21 Thread Grant Likely
On Thu, Mar 21, 2013 at 12:36 PM, Benjamin Herrenschmidt wrote: > On Thu, 2013-03-21 at 08:16 +0000, Grant Likely wrote: >> On Thu, Mar 21, 2013 at 7:43 AM, Benjamin Herrenschmidt >> wrote: >> > On Thu, 2013-03-21 at 07:35 +, Grant Likely wrote: >> >> >

Re: [PATCH 1/2] spi: make sure all transfer has proper speed set

2013-02-05 Thread Grant Likely
xfer->bits_per_word = spi->bits_per_word; > + if (!xfer->speed_hz) > + xfer->speed_hz = spi->max_speed_hz; > } > > message->spi = spi; > -- > 1.7.1.1 > -- Grant Likely, B.Sc, P.Eng.

Re: [PATCH 2/2] spi: tegra: remove checks for valid speed

2013-02-05 Thread Grant Likely
speed) { > clk_set_rate(tspi->clk, speed * 4); > tspi->cur_speed = speed; > @@ -841,6 +839,8 @@ static int tegra_slink_setup(struct spi_device *spi) > > BUG_ON(spi->chip_select >= MAX_CHIP_SELECT); > > + /* Set speed to

Re: [PATCH 14/19] spi/atmel: remove incorrect __exit_p()

2013-02-05 Thread Grant Likely
On Fri, 25 Jan 2013 14:14:31 +, Arnd Bergmann wrote: > Since we no longer allow building without hotplug, the > atmel_spi_remove function is always present and we should > not use __exit_p() to refer to it. > > Without this patch, building at91_dt_defconfig results in: > > drivers/spi/spi-at

[PATCH] spi: Remove erroneous __exit and __exit_p() references in drivers

2013-02-05 Thread Grant Likely
match the pattern. Remove then now to be rid of it. Reported-by: Arnd Bergmann [Arnd set a patch cleaning up one, and then I found more] Signed-off-by: Grant Likely --- drivers/spi/spi-atmel.c |2 +- drivers/spi/spi-au1550.c |4 ++-- drivers/spi/spi-omap-100k.c |4 ++-- dr

Re: [PATCH 1/3] spi: Add helper functions for setting up transfers

2013-02-05 Thread Grant Likely
On Sun, 27 Jan 2013 03:33:59 +, Mark Brown wrote: > On Wed, Jan 09, 2013 at 06:31:09PM +0100, Lars-Peter Clausen wrote: > > > The second function spi_sync_transfer() takes a SPI device and an array of > > spi_transfers. It will allocate a new spi_message (on the stack) and add all > > transf

Re: [v4 PATCH 00/12] atmel spi controller with dmaengine and device tree support

2013-02-05 Thread Grant Likely
2 + > arch/arm/mach-at91/at91sam9n12.c|2 + > arch/arm/mach-at91/at91sam9x5.c |2 + > drivers/spi/spi-atmel.c | 809 > ++++++++--- > 15 files changed, 908 insertions(+), 69 deletions(-) > > -- > 1.7.9.5 > > >

Re: [PATCH 25/33] spi: Convert to devm_ioremap_resource()

2013-02-05 Thread Grant Likely
icit > error messages can be removed from the failure code paths. > > Signed-off-by: Thierry Reding > Cc: Grant Likely > Cc: spi-devel-gene...@lists.sourceforge.net Looks fine by me. Go ahead and merge with the rest of the series. Acked-by: Grant Likely > --- > dri

Re: [PATCH] spi: Ensure memory used for spi_write_then_read() is DMA safe

2013-02-05 Thread Grant Likely
local_buf = kmalloc(max((unsigned)SPI_BUFSIZ, n_tx + n_rx), > + GFP_KERNEL | GFP_DMA); > if (!local_buf) > return -ENOMEM; > } else { > -- > 1.7.10.4 > -- Grant Likely, B.Sc, P.Eng. Secret Lab Tech

Re: [PATCH RFC 1/1] gpio: mcp23s08: convert driver to DT

2013-02-05 Thread Grant Likely
On Thu, 31 Jan 2013 21:51:36 +0100, Linus Walleij wrote: > On Thu, Jan 31, 2013 at 4:58 PM, Lars Poeschel > wrote: > > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/gpio/gpio-mcp23s08.txt > > @@ -0,0 +1,27 @@ > > +Microchip MCP2308/MCP23S08/MCP23017/MCP23S17 driver for > > +8-/16

[PATCH V2] spi: Remove erroneous __init, __exit and __exit_p() references in drivers

2013-02-05 Thread Grant Likely
/__devexit purge since they didn't match the pattern. Remove then now to be rid of it. v2: purge __init also Reported-by: Arnd Bergmann [Arnd set a patch cleaning up one, and then I found more] Signed-off-by: Grant Likely --- drivers/spi/spi-atmel.c |2 +- drivers/spi/spi-au1550.c |

Re: [PATCH] spi: davinci: use request_threaded_irq() to fix deadlock

2013-02-05 Thread Grant Likely
On Wed, 2 Jan 2013 10:19:08 -0500, Murali Karicheri wrote: > On 12/22/2012 05:08 AM, Grant Likely wrote: > > On Fri, 21 Dec 2012 15:13:26 -0500, Murali Karicheri > > wrote: > >> With RT pre-empt patch applied to Linux kernel, the irq handler will be > >> forc

Re: [PATCH RESEND] spi: spi-fsl-spi: Make spi-fsl-spi usable in cpu mode outside of FSL SOC environments and add a grlib variant normally running on sparc

2013-02-05 Thread Grant Likely
On Wed, 30 Jan 2013 13:15:24 +0100, Andreas Larsson wrote: > This makes the cpu mode of the driver available outside of an FSL SOC > and even powerpc environment. This is accomplished by putting things > regarding fsl specific code and to cpm specific code within ifdefs. > > Furthermore, this add

Re: [PATCH] drivers/block/xsysace - replace in(out)_8/in(out)_be16/in(out)_le16 with generic iowrite(read)8/16(be)

2013-02-06 Thread Grant Likely
On Tue, Feb 5, 2013 at 3:12 PM, Arnd Bergmann wrote: > On Tuesday 05 February 2013 18:03:31 Alexey Brodkin wrote: >> The Xilinx System ACE Compact Flash chip is a true little-endian device >> and the PLB is a big-endian bus. Therefore the XPS System ACE Interface >> Controller will do a bit-swap i

Re: [PATCH] drivers/block/xsysace - replace in(out)_8/in(out)_be16/in(out)_le16 with generic iowrite(read)8/16(be)

2013-02-06 Thread Grant Likely
ve the SystemACE directly wired to the SoC external bus (no adapter IP). The only problem that I see is that the ARM and Microblaze ioread16be/iowrite16be helpers are missing barriers which smells like a bug and should be fixed. Michal, have you tested Alexey's patch? If it works fo

Re: [PATCH 1/4] spi: s3c64xx: modified error interrupt handling and init

2013-02-06 Thread Grant Likely
On Tue, 5 Feb 2013 15:09:41 -0800, Girish K S wrote: > The status of the interrupt is available in the status register, > so reading the clear pending register and writing back the same > value will not actually clear the pending interrupts. This patch > modifies the interrupt handler to read the

Re: [PATCH 2/4] spi: s3c64xx: added support for polling mode

2013-02-06 Thread Grant Likely
On Tue, 5 Feb 2013 15:09:42 -0800, Girish K S wrote: > The 64xx spi driver supports partial polling mode. > Only the last chunk of the transfer length is transferred > or recieved in polling mode. > > Some SoC's that adopt this controller might not have have dma > interface. This patch adds supp

Re: [PATCH 3/4] spi: s3c64xx: add gpio quirk for controller

2013-02-06 Thread Grant Likely
es internal dedicated pins > + */ > + if (sdd->port_conf->quirks & S3C64XX_SPI_QUIRK_GPIO) > + return 0; > + > /* find gpios for mosi, miso and clock lines */ > for (idx = 0; idx < 3; idx++) { > gpio = of_get_gpio(dev

Re: Heads up on a device tree change

2013-02-06 Thread Grant Likely
On Wed, Feb 6, 2013 at 1:32 PM, James Hogan wrote: > On 06/02/13 13:11, Grant Likely wrote: >> Hi Stephen, >> >> I've just pushed out a change which cleans up platform device >> registration to use the same path whether or not the device tree is >> used. It

Re: [PATCH 1/4] spi: s3c64xx: modified error interrupt handling and init

2013-02-06 Thread Grant Likely
On Wed, Feb 6, 2013 at 8:12 PM, Girish KS wrote: > On Wed, Feb 6, 2013 at 2:26 AM, Grant Likely > wrote: >> On Tue, 5 Feb 2013 15:09:41 -0800, Girish K S >> wrote: >>> The status of the interrupt is available in the status register, >>> so reading the cle

[PATCH] devicetree: Move NS2 LEDs binding into LEDs directory

2013-02-07 Thread Grant Likely
leds-ns2.txt is a binding for LEDs, not GPIOs. Move the documentation in with the rest of the LEDs bindings. Cc: Andrew Lunn Cc: Simon Guinot Cc: Jason Cooper Signed-off-by: Grant Likely --- .../devicetree/bindings/gpio/leds-ns2.txt | 26 .../devicetree

Re: [PATCH] drivers/block/xsysace - replace in(out)_8/in(out)_be16/in(out)_le16 with generic iowrite(read)8/16(be)

2013-02-07 Thread Grant Likely
On Wed, Feb 6, 2013 at 9:35 PM, Benjamin Herrenschmidt wrote: > On Wed, 2013-02-06 at 10:14 +0000, Grant Likely wrote: >> >> Huh? That makes no sense. This device out in the wild with both big >> and little endian bus attachments. You can argue all day that one of >> th

Re: [PATCH] drivers/block/xsysace - replace in(out)_8/in(out)_be16/in(out)_le16 with generic iowrite(read)8/16(be)

2013-02-07 Thread Grant Likely
On Thu, Feb 7, 2013 at 2:39 PM, Grant Likely wrote: > On Wed, Feb 6, 2013 at 9:35 PM, Benjamin Herrenschmidt > wrote: >>> In fact, the driver already knows about this and figures >>> out at runtime how the device is wired up to the bus. This is not the >>> p

Re: [PATCH] drivers/block/xsysace - replace in(out)_8/in(out)_be16/in(out)_le16 with generic iowrite(read)8/16(be)

2013-02-07 Thread Grant Likely
On Thu, Feb 7, 2013 at 3:12 PM, Alexey Brodkin wrote: > On 02/07/2013 06:51 PM, Grant Likely wrote: >> >> On Thu, Feb 7, 2013 at 2:39 PM, Grant Likely >> wrote: >>> >>> On Wed, Feb 6, 2013 at 9:35 PM, Benjamin Herrenschmidt >>> wrote: >>&g

Re: [PATCH] drivers/block/xsysace - replace in(out)_8/in(out)_be16/in(out)_le16 with generic iowrite(read)8/16(be)

2013-02-07 Thread Grant Likely
On Thu, Feb 7, 2013 at 3:28 PM, Alexey Brodkin wrote: > On 02/07/2013 07:23 PM, Grant Likely wrote: >> >> On Thu, Feb 7, 2013 at 3:12 PM, Alexey Brodkin >> wrote: >>> >>> On 02/07/2013 06:51 PM, Grant Likely wrote: >>>> >>>>

Re: [PATCH] drivers/block/xsysace - replace in(out)_8/in(out)_be16/in(out)_le16 with generic iowrite(read)8/16(be)

2013-02-07 Thread Grant Likely
On Thu, Feb 7, 2013 at 4:56 PM, Alexey Brodkin wrote: > On 02/07/2013 08:44 PM, Grant Likely wrote: >> So, if I'm correct that means that for the data port (specifically >> copying between RAM and the data port) using ioread16/iowrite16 on the >> data port results in

Re: [PATCH] drivers/block/xsysace - replace in(out)_8/in(out)_be16/in(out)_le16 with generic iowrite(read)8/16(be)

2013-02-07 Thread Grant Likely
On Thu, Feb 7, 2013 at 11:05 PM, Arnd Bergmann wrote: > On Thursday 07 February 2013, Grant Likely wrote: >> On Thu, Feb 7, 2013 at 3:28 PM, Alexey Brodkin > Of course, as long as the driver is only ever used to access > the same non-removable block device and you don't cha

Re: [PATCH] drivers/block/xsysace - replace in(out)_8/in(out)_be16/in(out)_le16 with generic iowrite(read)8/16(be)

2013-02-07 Thread Grant Likely
On Thu, Feb 7, 2013 at 5:22 PM, Alexey Brodkin wrote: > On 02/07/2013 09:16 PM, Grant Likely wrote: >> >> On Thu, Feb 7, 2013 at 4:56 PM, Alexey Brodkin >> wrote: >>> >>> On 02/07/2013 08:44 PM, Grant Likely wrote: >>>> >>>> So,

[PATCH 1/2] powerpc/5200: Add Lite5200 on-board LEDs as devices

2013-02-08 Thread Grant Likely
is required for that, but it means less work needs to be done by board ports. Cc: Anatolij Gustschin Signed-off-by: Grant Likely --- arch/powerpc/boot/dts/lite5200b.dts | 23 +++ arch/powerpc/boot/dts/mpc5200b.dtsi | 25 + 2 files changed, 36 in

[PATCH 2/2] powerpc/5200: Use the gpt* labels to simplify mpc5200 dts files

2013-02-08 Thread Grant Likely
The DTC labels feature allows a dts file to reference a node without having to reproduce the entire node hierarchy above it. We can use this to simplify the MPC5200 board dts files by referencing the gpt nodes by label. Cc: Anatolij Gustschin Signed-off-by: Grant Likely --- arch/powerpc/boot

Re: [PATCH v2] input: Extend matrix-keypad device tree binding

2013-02-08 Thread Grant Likely
On Fri, 11 Jan 2013 10:09:19 -0700, Stephen Warren wrote: > On 01/10/2013 06:41 PM, Simon Glass wrote: > > Some matrix keypad drivers can support different numbers of rows and > > columns. Add a generic binding for these. > > > > Implementation note: > > > > In order to implement this binding i

Re: [PATCH v4] i2c: exynos5: add High Speed I2C controller driver

2013-02-08 Thread Grant Likely
On Fri, 01 Feb 2013 21:24:44 +0530, Naveen Krishna Chatradhi wrote: > Adds support for High Speed I2C driver found in Exynos5 and later > SoCs from Samsung. This driver currently supports Auto mode. > > Driver only supports Device Tree method. > Note: Added debugfs support for registers view, no

Re: [PATCH V8] kbuild: create a rule to run the pre-processor on *.dts files

2013-02-08 Thread Grant Likely
On Tue, 5 Feb 2013 12:06:28 -0700, Stephen Warren wrote: > From: Stephen Warren > > Create cmd_dtc_cpp to run the C pre-processor on *.dts file before > passing them to dtc for final compilation. This allows the use of #define > and #include within the .dts file. > > Acked-by: Simon Glass >

Re: [PATCH v8 2/4] misc: Generic on-chip SRAM allocation driver

2013-02-08 Thread Grant Likely
'm a little concerned that 'sram' is just too generic for a compatible value and we may end up needing a blacklist of systems where the sram device should not be driven with this driver. If you can think of a more descriptive name here then I would use it. However, I'

Re: [PATCH V8] kbuild: create a rule to run the pre-processor on *.dts files

2013-02-08 Thread Grant Likely
On Fri, Feb 8, 2013 at 5:18 PM, Stephen Warren wrote: > On 02/08/2013 07:45 AM, Grant Likely wrote: >> On Tue, 5 Feb 2013 12:06:28 -0700, Stephen Warren >> wrote: >>> From: Stephen Warren >>> >>> Create cmd_dtc_cpp to run the C pre-processor on *.d

Re: [PATCH v3 1/2] ARM: Exynos5250: Enabling ehci-s5p driver

2013-02-08 Thread Grant Likely
"samsung-i2s.2", NULL), > >>>> + OF_DEV_AUXDATA("samsung,exynos4210-ehci", EXYNOS5_PA_EHCI, > >>>> + "s5p-ehci", NULL), > >>> > >>> I'm assuming the above change is temporary. What is l

Re: [PATCH] platform: Fix platform device resource linking

2013-02-08 Thread Grant Likely
On Fri, 18 Jan 2013 11:05:14 +0200, Pantelis Antoniou wrote: > Hi Greg, > > On Jan 18, 2013, at 5:00 AM, Greg Kroah-Hartman wrote: > > > On Thu, Jan 17, 2013 at 07:27:21PM +0200, Pantelis Antoniou wrote: > In a nutshell, we have to exercise the platform device subsystem, in ways > tha

Re: [PATCH] Link platform device resources properly.

2013-02-08 Thread Grant Likely
On Thu, 17 Jan 2013 19:26:36 +0200, Pantelis Antoniou wrote: > The resources of the platform devices created by the OF core were > not properly linked. Make sure that they are, so that we don't get > any crashes when trying to remove the device. > > Signed-off-by: Pantelis Antoniou > --- > dri

Re: [PATCH V8] kbuild: create a rule to run the pre-processor on *.dts files

2013-02-08 Thread Grant Likely
On Fri, 08 Feb 2013 15:24:25 -0600, Rob Herring wrote: > On 02/08/2013 08:45 AM, Grant Likely wrote: > > On Tue, 5 Feb 2013 12:06:28 -0700, Stephen Warren > > wrote: > >> From: Stephen Warren > >> > >> Create cmd_dtc_cpp to run the C pre-processor on

Re: [PATCH] devicetree: Move NS2 LEDs binding into LEDs directory

2013-02-08 Thread Grant Likely
On Thu, 7 Feb 2013 08:21:18 -0500, Jason Cooper wrote: > On Thu, Feb 07, 2013 at 12:22:56PM +0000, Grant Likely wrote: > > leds-ns2.txt is a binding for LEDs, not GPIOs. Move the documentation in > > with the rest of the LEDs bindings. > > > > Cc: Andrew Lunn > >

Re: [PATCH 4/4] serial/arc-uart: switch to devicetree based probing

2013-02-08 Thread Grant Likely
to get resoures/plat_data. > This requires some infrastructre changes to of_flat_ framework > > Signed-off-by: Vineet Gupta > Cc: Grant Likely > Cc: Arnd Bergmann > Cc: linux-ser...@vger.kernel.org > Cc: Alan Cox > Cc: Greg Kroah-Hartman > Cc: devicetree-disc...@lists.o

Re: [PATCH 5/9] gpiolib: use gpio_chips list in gpiochip_find_base

2013-02-09 Thread Grant Likely
On Wed, 6 Feb 2013 13:48:19 +0900, Alex Courbot wrote: > On 02/06/2013 02:21 AM, Linus Walleij wrote: > > This looks like it is preserving this userspace-sensitive semantic > > so that dynamically added chips will still get the same assigned > > numbers. > > It does (it should, at least), the ass

Re: [PATCH 1/9] gpiolib: link all gpio_chips using a list

2013-02-09 Thread Grant Likely
On Tue, 5 Feb 2013 18:00:56 +0100, Linus Walleij wrote: > On Sat, Feb 2, 2013 at 5:29 PM, Alexandre Courbot wrote: > > > Add a list member to gpio_chip that allows all chips to be parsed > > quickly. The current method requires parsing the entire GPIO integer > > space, which is painfully slow.

Re: [PATCH v2 2/4] input: keyboard: tegra: use devm_* for resource allocation

2013-02-09 Thread Grant Likely
On Wed, 9 Jan 2013 01:19:39 -0800, Dmitry Torokhov wrote: > On Wed, Jan 09, 2013 at 08:07:45AM +0100, Thierry Reding wrote: > > On Sun, Jan 06, 2013 at 11:57:48AM -0800, Dmitry Torokhov wrote: > > > On Sun, Jan 06, 2013 at 08:27:39PM +0100, Thierry Reding wrote: > > > > On Sat, Jan 05, 2013 at 12

Re: [PATCH 4/9] gpiolib: use gpio_chips list in sysfs ops

2013-02-09 Thread Grant Likely
On Tue, 5 Feb 2013 18:15:54 +0100, Linus Walleij wrote: > On Sat, Feb 2, 2013 at 5:29 PM, Alexandre Courbot wrote: > > > This makes the code both simpler and faster compared to parsing the GPIO > > number space. > > > > Signed-off-by: Alexandre Courbot > > Reviewed-by: Linus Walleij Applied

Re: [PATCH 2/9] gpiolib: use gpio_chips list in gpiolib_sysfs_init

2013-02-09 Thread Grant Likely
iewed-by: Linus Walleij > Applied, thanks. g. -- Grant Likely, B.Sc, P.Eng. Secret Lab Technologies, Ltd. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org

Re: [PATCH 8/9] gpiolib: use gpio_chips list in gpio_to_desc

2013-02-09 Thread Grant Likely
rive here... */ > + break; > + } > + > + pr_warn("%s: no registered chip to handle GPIO %d\n", __func__, gpio); > + return NULL; > } > > /** > -- > 1.8.1.1 > -- Grant Likely, B.Sc, P.Eng. Secret Lab Technolo

Re: [PATCH 6/9] gpiolib: use descriptors internally

2013-02-09 Thread Grant Likely
On Thu, 7 Feb 2013 15:57:32 +0900, Alexandre Courbot wrote: > On Wed, Feb 6, 2013 at 2:53 AM, Linus Walleij > wrote: > > On Sat, Feb 2, 2013 at 5:29 PM, Alexandre Courbot > > wrote: > >> +/** > >> + * Convert a GPIO number to its descriptor > >> + */ > >> +static struct gpio_desc *gpio_to_des

Re: [PATCH 3/9] gpiolib: use gpio_chips list in gpiochip_find

2013-02-09 Thread Grant Likely
On Tue, 5 Feb 2013 18:05:32 +0100, Linus Walleij wrote: > On Sat, Feb 2, 2013 at 5:29 PM, Alexandre Courbot wrote: > > > Using the GPIO chips list is much faster than parsing the entire GPIO > > number space. > > > > Signed-off-by: Alexandre Courbot > > You don't say :-) > Reviewed-by: Linus

[PATCH] gpiolib: Fix locking on gpio debugfs files

2013-02-09 Thread Grant Likely
The debugfs files really need to hold the gpiolib spinlock before accessing the list. Otherwise chip addition/removal will cause an oops. Cc: Alexandre Courbot Cc: Linus Walleij Signed-off-by: Grant Likely --- drivers/gpio/gpiolib.c | 12 +--- 1 file changed, 9 insertions(+), 3

Re: [PATCH 6/9] gpiolib: use descriptors internally

2013-02-09 Thread Grant Likely
On Sun, 3 Feb 2013 01:29:29 +0900, Alexandre Courbot wrote: > Make sure gpiolib works internally with descriptors and (chip, offset) > pairs instead of using the global integer namespace. This prepares the > ground for the removal of the global gpio_desc[] array and the > introduction of the des

Re: [PATCH 6/9] gpiolib: use descriptors internally

2013-02-09 Thread Grant Likely
On Sun, 3 Feb 2013 01:29:29 +0900, Alexandre Courbot wrote: > Make sure gpiolib works internally with descriptors and (chip, offset) > pairs instead of using the global integer namespace. This prepares the > ground for the removal of the global gpio_desc[] array and the > introduction of the des

Re: [PATCH 7/9] gpiolib: let gpio_chip reference its descriptors

2013-02-09 Thread Grant Likely
On Tue, 5 Feb 2013 19:00:09 +0100, Linus Walleij wrote: > On Sat, Feb 2, 2013 at 5:29 PM, Alexandre Courbot wrote: > > > Add a pointer to the gpio_chip structure that references the array of > > GPIO descriptors belonging to the chip, and update gpiolib code to use > > this pointer instead of t

Re: [PATCH v3] gpio: vt8500: memory cleanup missing

2013-02-09 Thread Grant Likely
On Fri, 18 Jan 2013 17:58:22 +1300, Tony Prisk wrote: > This driver is missing a .remove callback, and the fail path on > probe is incomplete. > > If an error occurs in vt8500_add_chips, gpio_base is not unmapped. > The driver is also ignoring the return value from this function so > if a chip fa

Re: [PATCH 08/33] gpio: Convert to devm_ioremap_resource()

2013-02-09 Thread Grant Likely
On Mon, 21 Jan 2013 16:22:21 +0530, Viresh Kumar wrote: > On Mon, Jan 21, 2013 at 3:39 PM, Thierry Reding > wrote: > > diff --git a/drivers/gpio/gpio-spear-spics.c > > b/drivers/gpio/gpio-spear-spics.c > > index 5f45fc4..7a4bf7c 100644 > > --- a/drivers/gpio/gpio-spear-spics.c > > +++ b/drivers

  1   2   3   4   5   6   7   8   9   10   >