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
Bruce:
On Mon, Jan 30, 2012 at 6:06 PM, bruce_leon...@selinc.com wrote:
Bill Gatliff b...@billgatliff.com 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
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.02.
b.g.
--
Bill Gatliff
b
can see an
example of what I'm trying to do?
Bruce
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
--
Bill Gatliff
b...@billgatliff.com
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
diagonal line is very blocky--- not smooth at all
I would love it if you posted your code! Thanks!!
b.g.
On Apr 15, 2010 8:53 AM, Roman Fietze roman.fie...@telemotive.de 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
. 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
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
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
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
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
Linuxppc-dev
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 the problem of dependencies between devices in different
Grant Likely wrote:
On Fri, Apr 9, 2010 at 1:23 PM, Bill Gatliff b...@billgatliff.com 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 thinking
about the problem of dependencies between
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
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
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...@billgatliff.com
___
Linuxppc-dev
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
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.c
+++ b/init/main.c
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 the only place
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 with something.
I
!
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
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 calls gpio_set_value
, 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
Linuxppc-dev
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 I lack is a
clear idea
of how to set a GPIO.
Isn't
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 mean I'll be seeing
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 consulting
http://billgatliff.com
b...@billgatliff.com
Signed-off-by: Bill Gatliff b...@billgatliff.com
---
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
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
Signed-off-by: Bill Gatliff b...@billgatliff.com
---
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
*** 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
,
an ordinary struct gpio_chip is employed.
Signed-off-by: Bill Gatliff b...@billgatliff.com
---
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
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 b...@billgatliff.com
.
The 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
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 training
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
, 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 Gatliff
Embedded systems training
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://billgatliff.com
b
operations.
Signed-off-by: Bill Gatliff b...@billgatliff.com
---
arch/powerpc/platforms/52xx/mpc52xx_gpio.c | 328 ++-
1 files changed, 267 insertions(+), 61 deletions(-)
diff --git a/arch/powerpc/platforms/52xx/mpc52xx_gpio.c
b/arch/powerpc/platforms/52xx/mpc52xx_gpio.c
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 was not tested
Peter Korsgaard wrote:
Bill == Bill Gatliff b...@billgatliff.com writes:
Bill Guys:
Bill Is it possible to specify an individual GPIO pin as an interrupt source
Bill with the current MPC52xx code?
No (not yet). In Ben's latest pull request there's a patch from me to
add
. 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-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo
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 has been written for
52xx.
http://patchwork.ozlabs.org
.
--
Bill Gatliff
b...@billgatliff.com
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
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 encoder using the syntax I
want, I have
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
?
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
, 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
___
Linuxppc-dev mailing list
Linuxppc
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.
--
Bill Gatliff
b
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 with that call?
/dev/mem
b.g.
--
Bill Gatliff
b...@billgatliff.com
___
Linuxppc-dev mailing
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
Linuxppc-dev
it will 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
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]
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https
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/linuxppc
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
https://ozlabs.org/mailman/listinfo/linuxppc
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/listinfo
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 with git?
I'm using git-format-patch and git-send
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]
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo
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,
and to send notification messages
the ARM people.
Sounds like the ARM people need you to drop by and help them do a better job.
Sounds like you could directly benefit from their doing a better job, too.
Win-win.
b.g.
--
Bill Gatliff
[EMAIL PROTECTED]
___
Linuxppc-dev mailing list
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
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 objective is to consolidate the
existing PWM implementations
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.
--
Bill Gatliff
[EMAIL PROTECTED]
==
Bill
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/linux/pwm
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
new file mode
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/pwm.h
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/Kconfig
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 100644
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.c
new
67 matches
Mail list logo
