Re: Question about GPIO Lib

ns of gpiolib offer today make this work even better. b.g. -- Bill Gatliff b...@billgatliff.com ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: Question about GPIO Lib

Bruce: On Mon, Jan 30, 2012 at 6:06 PM, wrote: > Bill Gatliff wrote on 01/27/2012 10:42:57 AM: >> Sounds like you DON'T want to merely export that GPIO pin to userspace. >> > > Well, yes I do want to just export to userspace I misunderstood your message, then. I

Re: Question about GPIO Lib

on that pin, it won't be exportable to userspace anyway. Regardless, you are probably better off implement a DEVICE_ATTR that, in its store() method, treads lightly on said pin. And then do a gpio_request() in kernel space so that users can't ever see the pin directly. Just my $0.

Re: Question on supporting multiple HW versions with a single driver (warning: long post)

ort of dual bus binding" so can see an > example of what I'm trying to do? > > Bruce > ___ > Linuxppc-dev mailing list > Linuxppc-dev@lists.ozlabs.org > https://lists.ozlabs

Re: Xorg on Fujitsu "Lime" with MPC5200b?

27;t an "endianness bit" in the memory bus controller that can undo this damage for us. I know I've seen such a bit in other SoCs... Thanks! b.g. -- Bill Gatliff b...@billgatliff.com ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: Xorg on Fujitsu "Lime" with MPC5200b?

t the *Weak stuff is doing. Can I just hack shadowUpdatePacked() itself? b.g. -- Bill Gatliff b...@billgatliff.com ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: Xorg on Fujitsu "Lime" with MPC5200b?

I would love it if you posted your code! Thanks!! b.g. On Apr 15, 2010 8:53 AM, "Roman Fietze" wrote: Hello Bill, On Thursday 15 April 2010 15:01:59 Bill Gatliff wrote: > Are you talking about this code here? > ... Yes. I added a routine like /* Swap frame buffer bytes

Re: Xorg on Fujitsu "Lime" with MPC5200b?

Roman Fietze wrote: > Hallo Bill, > > On Thursday 15 April 2010 05:07:08 Bill Gatliff wrote: > > >> Actually, I *have* Debian squeeze's xorg running on the platform just >> fine, with a 2.6.34-rc1 kernel (kernel.org). Problem is, every single >> diagona

Xorg on Fujitsu "Lime" with MPC5200b?

t the problem. Anyone have any suggestions on where to start with this one? Anyone else running a similar configuration with any success? I'm completely lost, and running out of hair *fast*... Thanks! b.g. -- Bill Gatliff b...@billgatliff.com __

kernel BUG at kernel/timer.c:643!

Is anyone seeing this message on an MPC5200 platform with the current HEAD from Linus Torvalds' git repo? I just did a rebase, and started seeing it... b.g. -- Bill Gatliff b...@billgatliff.com ___ Linuxppc-dev mailing list Linuxpp

Re: A better way to sequence driver initialization?

d make probing parallel from the beginning. But I think I'm going to have to settle for now with kthreading my probes that might want to sleep, and adding a wait queue to gpio_request() and a few others. It ain't perfect, but it is achieveable. *sigh* b.g. -- Bill Gatliff b...@billgat

Re: A better way to sequence driver initialization?

dent-driver") isn't the way to do the dependency tracking? I can't even implement that without a context that can sleep... b.g. -- Bill Gatliff b...@billgatliff.com ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: A better way to sequence driver initialization?

;t going to work. But I don't think that having every driver do its own kthread_run() is a solution, either. I'll keep tinkering. :) b.g. -- Bill Gatliff b...@billgatliff.com ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: A better way to sequence driver initialization?

Grant Likely wrote: > On Fri, Apr 9, 2010 at 1:23 PM, Bill Gatliff wrote: > >> Guys: >> >> >> My recent post, "Requesting a GPIO that hasn't been registered yet", and >> Anton's reply thereto (thanks, Anton!) on linuxppc-dev got me think

Re: A better way to sequence driver initialization?

Benjamin Herrenschmidt wrote: > On Fri, 2010-04-09 at 14:23 -0500, Bill Gatliff wrote: > >> My recent post, "Requesting a GPIO that hasn't been registered yet", and >> Anton's reply thereto (thanks, Anton!) on linuxppc-dev got me thinking >> about th

Re: A better way to sequence driver initialization?

Bill Gatliff wrote: > > ... and kset_register() might be the only place that calls > wake_up_interruptible(). Wow. > Wow, indeed. With just the attached patch, I get exactly one OOPS now--- in ssc_free(), which I think is getting called because atmel_ssc_modinit() is racing wi

Re: A better way to sequence driver initialization?

Bill Gatliff wrote: > Maybe there are fewer places that would need wait queues than I > originally thought! At least for drivers that use the device API, > kset_find_obj() might be the only place that needs to wait until a > device or bus appears. ... and kset_register() might be th

Re: A better way to sequence driver initialization?

Bill Gatliff wrote: > If someone doesn't tell me this is a stupid idea, I might post it to > lkml. Now's your chance! :) > So I went ahead and tried it anyway: $ git diff init/main.c diff --git a/init/main.c b/init/main.c index dac44a9..1461d09 100644 --- a/init/main.

A better way to sequence driver initialization?

flush_scheduled_work(); } If someone doesn't tell me this is a stupid idea, I might post it to lkml. Now's your chance! :) b.g. -- Bill Gatliff b...@billgatliff.com ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev

Requesting a GPIO that hasn't been registered yet

pio_leds and they are working fine--- although the GPIO pin is on a pca953x at address 20, instead of 60. I'm at a loss to explain why one works, but the other doesn't. And I don't know how to really fix this problem for good! Any suggestions? Thanks!! b.g. -- Bill Gatliff b...@billgatliff.com ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: Sleep-capable GPIO slave-selects on MPC52xx?

Bill Gatliff wrote: > > It looks like the current version of the MPC52xx SPI driver won't work > with sleep-capable GPIOs for slave-selects. In particular, it looks > like mpc52xx_spi_fsmstate_transfer() is an interrupt handler that calls > mpc52xx_spi_chipsel(), which itself

Sleep-capable GPIO slave-selects on MPC52xx?

ing, or is this a known (or at least now-identified) limitation of the current mpc52xx_spi.c? Thanks! b.g. -- Bill Gatliff Embedded systems training and consulting http://billgatliff.com b...@billgatliff.com ___ Linuxppc-dev mailing list Li

Re: [PATCH 0/2] Create an of_i2c_gpiochip_add()

garding GPIO sometimes need a bit of time. Also, of_platform was in the > discussion of being removed, this might complicate things, too. > Is this the right mailing list for such patches, though? b.g. -- Bill Gatliff Embedded systems training and c

Re: [PATCH 0/2] Create an of_i2c_gpiochip_add()

Bill Gatliff wrote: > This patch series creates an of_i2c_gpiochip_add() function, to allow > i2c-based GPIO expanders to work with device tree gpio specifications. > So nobody has any yays or nays on this? I was expecting at least _something_! :) Does the lack of response mea

Re: How to set GPIO state in the dts or in platform

Ayman El-Khashab wrote: > On 1/5/2010 10:38 PM, Bill Gatliff wrote: >> Ayman El-Khashab wrote: >> >>> I've got a custom board akin to the walnut. I've successfully got >>> u-boot, >>> the kernel, and a working filesystem. The only thing

Re: How to set GPIO state in the dts or in platform

os = ? If you are passing a 0 for the flags, try a 1. I know of at least one driver that interprets that to mean a polarity inversion. Maybe you'll get lucky. :) b.g. -- Bill Gatliff Embedded systems training and consulting http://billgatliff.com b...@billgatliff.com ___

Re: [PATCH 0/2] *** SUBJECT HERE ***

Bill Gatliff wrote: > *** BLURB HERE *** > Dangit, sometimes I really hate it when emacs leaves its backup files around... :( Like now, for example. Please disregard the noise generated by my careless use of filename wildcards... b.g. -- Bill Gatliff Embedded systems traini

[RFC/PATCH 0/2] Updates to improve device tree support

of_i2c_gpiochip_add() function has been posted for review on the linuxppc-dev mailing list. Bill Gatliff (2): Use struct of_i2c_gpio_chip instead of raw struct gpio_chip Reorder initialization to better support device tree data drivers/gpio/pca953x.c | 168

[PATCH 2/2] Reorder initialization to better support device tree data

This patch changes the initialization sequence implemented in pca953x_probe(), so as to simplify the retrieval of device tree data when device trees are used. Incorporates the new of_i2c_gpiochip_add() function to register the newly-added GPIOs. Signed-off-by: Bill Gatliff --- drivers/gpio

[PATCH 1/2] Use struct of_i2c_gpio_chip instead of raw struct gpio_chip

t used, an ordinary struct gpio_chip is employed. Signed-off-by: Bill Gatliff --- drivers/gpio/pca953x.c | 50 ++- 1 files changed, 36 insertions(+), 14 deletions(-) diff --git a/drivers/gpio/pca953x.c b/drivers/gpio/pca953x.c index b097043..9c70963 10

[PATCH 0/2] *** SUBJECT HERE ***

*** BLURB HERE *** Bill Gatliff (2): Use struct of_i2c_gpio_chip instead of raw struct gpio_chip Reorder initialization to better support device tree data drivers/gpio/pca953x.c | 168 +--- 1 files changed, 88 insertions(+), 80 deletions

[PATCH 1/2] Create a struct of_i2c_gpio_chip, for i2c-based GPIO devices

Signed-off-by: Bill Gatliff --- include/linux/of_gpio.h | 23 +++ 1 files changed, 23 insertions(+), 0 deletions(-) diff --git a/include/linux/of_gpio.h b/include/linux/of_gpio.h index fc2472c..0c39242 100644 --- a/include/linux/of_gpio.h +++ b/include/linux/of_gpio.h

[PATCH 0/2] Create an of_i2c_gpiochip_add()

This patch series creates an of_i2c_gpiochip_add() function, to allow i2c-based GPIO expanders to work with device tree gpio specifications. Bill Gatliff (2): Create a struct of_i2c_gpio_chip, for i2c-based GPIO devices Create an of_i2c_gpiochip_add() drivers/of/gpio.c | 55

[PATCH 2/2] Create an of_i2c_gpiochip_add()

Signed-off-by: Bill Gatliff --- drivers/of/gpio.c | 55 + 1 files changed, 55 insertions(+), 0 deletions(-) diff --git a/drivers/of/gpio.c b/drivers/of/gpio.c index 6eea601..56b438a 100644 --- a/drivers/of/gpio.c +++ b/drivers/of/gpio.c

Re: Trouble specifying dts gpio-leds with GPIO expander chip

Anton Vorontsov wrote: > Though, soon there will be an easier way to register I2C/SPI chips > with the OF GPIO infrastructure. > Should this make me hesitate to update the pca953x driver, or clone it? b.g. -- Bill Gatliff Embedded systems training and consulting http://billgatl

Re: Question on MPC52xx IRQ[123] pins

terrupt handler does fire, you switch the irq type to the opposite setting. I think that approach rates pretty high on the "ugly scale" too, but perhaps tolerably so. In fact, were I to actually need to interface one of the IRQ lines to gpiolib, I might attempt this... b.g. -- Bill Gat

Re: [PATCH 1/1] Adds gpio_to_irq() and related support to the mpc52xx_gpio WKUP peripheral driver

Bill Gatliff wrote: > Second, the previously-unimplemented gpio_to_irq() function was added, > using __gpio_to_irq(). The author does not know why this code was previously > left out of arch/powerpc/include/asm/gpio.h. It seems to work. The generic > irq_to_gpio() function wa

[PATCH 1/1] Adds gpio_to_irq() and related support to the mpc52xx_gpio WKUP peripheral driver

This driver does not currently support Deep Sleep wakeups, only non-Deep Sleep ones. The Deep Sleep wakeups appear to be most suited for support under power management functionality, and not gpio-related operations. Signed-off-by: Bill Gatliff --- arch/powerpc/platforms/52xx/mpc52xx_gpio.c |

Re: Does gpio_to_irq() work for MPC52xx gpios?

Peter Korsgaard wrote: >>>>>> "Bill" == Bill Gatliff writes: >>>>>> > > Bill> Guys: > Bill> Is it possible to specify an individual GPIO pin as an interrupt source > Bill> with the current MPC52xx code? > &

Re: Does gpio_to_irq() work for MPC52xx gpios?

Bill Gatliff wrote: > Guys: > > > Ok, I have gpio_to_irq() more-or-less showing signs of life for the > MPC5200. But I'm having some trouble using it the way I want to. > I think I've got the idea all of a sudden. In order to describe the inputs to my rotary enc

Re: Does gpio_to_irq() work for MPC52xx gpios?

I think the answer is no, because what I'm trying to do doesn't seem that much different from how one specifies GPIO pins coming from different controllers. Any suggestions? b.g. -- Bill Gatliff b...@billgatliff.com ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: Does gpio_to_irq() work for MPC52xx gpios?

Bill Gatliff wrote: > Peter Korsgaard wrote: > >> No (not yet). In Ben's latest pull request there's a patch from me to >> add basic infrastructure for gpio_to_irq(). I've recently added irq >> support to the mpc8xxx driver, but so far nothing h

Re: Does gpio_to_irq() work for MPC52xx gpios?

p://patchwork.ozlabs.org/patch/41550/ > Ok. I'm taking a look at that code now, planning to adapt it for the MPC52xx unless someone raises any objections. b.g. -- Bill Gatliff b...@billgatliff.com ___ Linuxppc-dev mailing list Linuxppc-d

Does gpio_to_irq() work for MPC52xx gpios?

nking that code to allow me to register an interrupt handler for a specific GPIO pin just isn't there... b.g. -- Bill Gatliff b...@billgatliff.com ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev

Question on MPC52xx IRQ[123] pins

evices is kind of like mixing policy with implementation, it turns out. Almost like trying to reuse a PCI driver as a platform driver. I didn't spot how important that was until I started hacking on the code itself... Thanks! b.g. -- Bill Gatliff b...@billgatliff.com _

Trouble specifying dts gpio-leds with GPIO expander chip

howing up on of_platform: # ls /sys/bus/of_platform/devices/ ... gpio-leds.2 ... I'm stumped. Could it be that the startup code is trying to register the heartbeat device before it has registered the MAX7314, so it doesn't know yet that the GPIO line exists? Anyone have any suggestions? b.g. -- Bill Gatliff b...@billgatliff.com ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: Accessing flash directly from User Space

mmap >> >> You want MAP_SHARED and O_SYNC. >> > > > To use that I need to have a file descriptor to a device, do I not? However, > I do not have a base flash driver to give me that file descriptor. Am I > missing something w

Re: Accessing flash directly from User Space

Jonathan Haws wrote: > > How can I get that pointer? Unfortunately I cannot simply use the address of > the flash. Is there some magical function call that gives me access to that > portion of the memory space? > $ man 2 mmap You want MAP_SHARED and O_SYNC. b.g. --

Re: [PATCH/RFC] Add Alternative Log Buffer Support for printk Messages

e concept of Open Firmware for a while, but haven't really looked into it before now--- mostly because my impression until now was that the available implementations were both closed-source, and not supporting embedded, non-PPC targets like ARM. b.g. -- Bill Gatliff [EMAIL PROTECTED] _

Re: [PATCH/RFC] Add Alternative Log Buffer Support for printk Messages

Matt Sealey wrote: > I can think of a bunch of reasons why it's a good idea.. Can you point to a GPL/LGPL/BSD/etc. source code for an OpenFirmware implementation? b.g. -- Bill Gatliff [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linu

Proposal for a Generic PWM Device API posted on linux-embedded

ll be useful for many others as well. Kindest regards, b.g. -- Bill Gatliff [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: Floating inputs on unused GPIO pins

answer might not be the best political one, at least not without Freescale-branded docs to back you up. I say, write the code and make everyone else happy. :) At least until someone plugs in that expansion module! b.g. -- Bill Gatliff [EMAIL PROTECTED] __

Re: [RFC 0/6] Proposal for a Generic PWM Device API

ding the mailing list submissions right, and I resolve to do a better job effective immediately. But I think that's the last that I need to say on the subject. If it makes you feel any better, I'll stop responding to your replies unless they come to me via linu

Re: [RFC 0/6] Proposal for a Generic PWM Device API

Paul Mundt wrote: > On Fri, Oct 10, 2008 at 09:03:34AM -0500, Bill Gatliff wrote: >> Paul Mundt wrote: >>> This is likely because some of those lists are subscribers only, so cross >>> posting is poor form. It makes sense to keep the discussion in one place, >>&g

Re: [RFC 1/6] [PWM] Generic PWM API implementation

Benjamin Herrenschmidt wrote: > On Wed, 2008-10-08 at 11:43 -0500, Bill Gatliff wrote: >> Signed-off-by: Bill Gatliff <[EMAIL PROTECTED]> >> --- > > And you haven't provided -any- changeset comment. That isn't good :-) What's the easiest way to do that

Re: [RFC 0/6] Proposal for a Generic PWM Device API

Jon Smirl wrote: > What do the device tree deities have to say about PWM support? Dunno. What lists are they on? :) b.g. -- Bill Gatliff [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listi

Re: [RFC 0/6] Proposal for a Generic PWM Device API

linux-embedded, and then post one short note on l-a-k, linuxppc-dev and elsewhere that refers those interested to the actual content. I can live with that. b.g. -- Bill Gatliff [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org ht

Re: [RFC 0/6] Proposal for a Generic PWM Device API

David Woodhouse wrote: > Subscriber-only lists are broken. Just don't use them. You owe me a new keyboard! :) b.g. -- Bill Gatliff [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/

Re: [RFC 0/6] Proposal for a Generic PWM Device API

nd in ARM and PPC, for example. I haven't run anything by the MIPS or AVR guys, but I'm guessing they would have something to add, too. I'm beginning to appreciate what everyone must have had to deal with for GPIO. :) b.g. -- Bill Gatliff [EMAIL PROTECTED] _

Re: [RFC 1/6] [PWM] Generic PWM API implementation

Benjamin Herrenschmidt wrote: > On Wed, 2008-10-08 at 11:43 -0500, Bill Gatliff wrote: >> Signed-off-by: Bill Gatliff <[EMAIL PROTECTED]> >> --- > > And you haven't provided -any- changeset comment. That isn't good :-) Apparently not. :) b

Re: [RFC 0/6] Proposal for a Generic PWM Device API

Benjamin Herrenschmidt wrote: > On Wed, 2008-10-08 at 11:43 -0500, Bill Gatliff wrote: >> This series proposes a "generic PWM" driver API. >> >> This proposed API is motivated by the author's need to support >> pluggable devices; a secondary objec

Re: [RFC 0/6] Proposal for a Generic PWM Device API

t control, drive motors, audio output, and the billion > other things.. /me blushes Aw, shucks. I'm just glad I could help. :) b.g. -- Bill Gatliff [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev

[RFC 4/6] [PWM] Driver for Atmel PWMC peripheral

Signed-off-by: Bill Gatliff <[EMAIL PROTECTED]> --- drivers/pwm/atmel-pwm.c | 631 +++ 1 files changed, 631 insertions(+), 0 deletions(-) create mode 100644 drivers/pwm/atmel-pwm.c diff --git a/drivers/pwm/atmel-pwm.c b/drivers/pwm/atmel-pwm

[RFC 1/6] [PWM] Generic PWM API implementation

Signed-off-by: Bill Gatliff <[EMAIL PROTECTED]> --- drivers/pwm/pwm.c | 667 + 1 files changed, 667 insertions(+), 0 deletions(-) create mode 100644 drivers/pwm/pwm.c diff --git a/drivers/pwm/pwm.c b/drivers/pwm/pwm.c new file mode

[RFC 5/6] [PWM] Install new Atmel PWMC driver in Kconfig, expunge old one

Signed-off-by: Bill Gatliff <[EMAIL PROTECTED]> --- arch/arm/Kconfig |2 + drivers/Makefile |2 + drivers/misc/Kconfig |9 - drivers/misc/Makefile|1 - drivers/misc/atmel_pwm.c | 409 -- drivers/pwm/K

[RFC 2/6] [PWM] Changes to existing include/linux/pwm.h to adapt to generic PWM API

Signed-off-by: Bill Gatliff <[EMAIL PROTECTED]> --- include/linux/pwm.h | 168 -- 1 files changed, 147 insertions(+), 21 deletions(-) diff --git a/include/linux/pwm.h b/include/linux/pwm.h index 3945f80..d3d18f7 100644 --- a/include/linux

[RFC 3/6] [PWM] Documentation

Signed-off-by: Bill Gatliff <[EMAIL PROTECTED]> --- Documentation/pwm.txt | 258 + 1 files changed, 258 insertions(+), 0 deletions(-) create mode 100644 Documentation/pwm.txt diff --git a/Documentation/pwm.txt b/Documentation/pwm.txt ne

[RFC 6/6] [PWM] New LED driver and trigger that use PWM API

Signed-off-by: Bill Gatliff <[EMAIL PROTECTED]> --- drivers/leds/Kconfig | 21 -- drivers/leds/Makefile |2 + drivers/leds/leds-pwm.c| 141 drivers/leds/ledtrig-dim.c | 95 + include/lin

[RFC 0/6] Proposal for a Generic PWM Device API

me of these needs have already been identified. The proposed code has been run-tested on a Cogent CSB737 (AT91SAM9263), mated to a custom circuit that drives multiple DC motors and sensors. Feedback is welcome! b.g