--- On Mon, 8/9/10, Grant Likely grant.lik...@secretlab.ca wrote:
+ nr_parts =
of_mtd_parse_partitions(spi-dev, np, parts);
Let's keep OF-specific logic out of drivers like
this one ... intended to work without OF.
NAK on adding dependencies like OF to drivers
and other
--- On Tue, 8/10/10, Grant Likely grant.lik...@secretlab.ca wrote:
This one bothers me, but I can't put my
finger on it. The flag feels
like a controller specific hack.
That's because it *IS* ...
Not clear what a good fix would look like.
But in general, SPI master controllers are
- The bind functions are only called at init time, so there
is no need
to save a pointer to it.
Right. Let's retain the space-saving behaviors
by keeping init-only code in init sections.
- Dave
___
Linuxppc-dev mailing list
and make the OTG functionality
key on the generic OTG symbol, not a DW-specific one.
Use drivers/usb/otg/otg.c and include/linux/usb/otg.h?
Maybe; CONFIG_USB_OTG specifically, though
(or whatever that generic symbol is) ...
___
Please remove all the changes not related to
this Synopsis IP ... and make the OTG functionality
key on the generic OTG symbol, not a DW-specific one.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
Good -- MUSB won't be the only one. ;)
Could you mention a few Linux-enabled chips which
include this controller?
arch/powerpc/boot/dts/kilauea.dts | 15 +
Also, please provide a clean patch that only
includes the driver, and split PPC hooks into
a separate patch.
On Tuesday 26 January 2010, Anton Vorontsov wrote:
Just
inline the little two blocking_notifier_call_chain() calls directly,
making this a *LOT* simpler.
I'd rather stay with gpio_call_chain() helper, it makes the code
a little bit prettier, IMO. Compare this:
The one without the
On Tuesday 26 January 2010, Anton Vorontsov wrote:
Why have two options, instead of just the first/simpler one??
Because I2C/SPI drivers allocate (and register) gpio_chip structures
by themselves, so the first option is a no-go.
You should be mentioning such issues in the patch comments.
On Monday 25 January 2010, Anton Vorontsov wrote:
With this patch there are two ways to register OF GPIO controllers:
1. Allocating the of_gpio_chip structure and passing the
of_gc-gc pointer to the gpiochip_add. (Can use container_of
to convert the gpio_chip to the of_gpio_chip.)
On Monday 25 January 2010, Anton Vorontsov wrote:
+config GPIOLIB_NOTIFIER
+ bool
+ help
+ This symbol is selected by subsystems that need to handle GPIO
+ chips addition and removal. E.g., this is used for the
+ OpenFirmware bindings.
+
I'm no huge
On Monday 25 January 2010, Anton Vorontsov wrote:
With the new OF GPIO infrastructure it's much easier to handle I2C
GPIO controllers, i.e. now drivers don't have to deal with the
OF-specific bits.
Good, that's how it should have been done in the first place. :)
Of course, there's still the
NAK; see details below
On Thursday 27 August 2009, Anton Vorontsov wrote:
RTC core won't allow wakeup alarms to be set if RTC devices' parent
(i.e. i2c_client or spi_device) isn't wakeup capable.
Quite rightly so ... being wakeup-capable is config-specific.
For I2C devices there is
depend on them.
So I'll just say
Acked-by: David Brownell dbrown...@users.sourceforge.net
and ask you to merge via the PPC tree. (And hope that you
verified these are bisectable...)
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https
On Wednesday 29 July 2009, Anton Vorontsov wrote:
platform_data is overkill for m25p80 chips, the
driver only needs to know exact chip model, and that's what device
tables are for.
To be fair, the platform_data also supports partitioning
and labeling e.g. for cmdlinepart ... though I'd
On Wednesday 29 July 2009, Ben Dooks wrote:
struct spi_driver {
+ const struct spi_device_id *id_table;
+ int (*probe_id)(struct spi_device *spi,
+ const struct spi_device_id *id);
how about leaving it at just probe
On Thursday 30 July 2009, Anton Vorontsov wrote:
This patch converts the m25p80 driver so that now it uses .id_table
for device matching, making it properly detect devices on OpenFirmware
platforms (prior to this patch the driver misdetected non-JEDEC chips,
seeing all chips as m25p80).
I
On Friday 26 June 2009, Steven A. Falco wrote:
+
+ /*
+ * If there are no chip selects at all, or if this is the special
+ * case of a non-existent (dummy) chip select, do nothing.
+ */
+
+ if (!hw-master-num_chipselect || hw-gpios[cs] == -EEXIST)
+
On Friday 19 June 2009, Rini van Zetten wrote:
This patch adds the possibility to have a spi device without a cs.
Note that there's now the SPI_NO_CS bit in spi_device.mode
to describe this situation ... so no -EEXIST hackery should
ever tempt anyone again.
On Thursday 25 June 2009, Steven A. Falco wrote:
+ if (spi-mode ~MODEBITS) {
+ dev_dbg(spi-dev, setup: unsupported mode bits %x\n,
+ spi-mode ~MODEBITS);
+ return -EINVAL;
+ }
This wasn't tested against 2.6.30-rc1 was it?
See
On Wednesday 24 June 2009, Steven A. Falco wrote:
Your changes to bitbang_work look good.
You tested?
I'm not clear on why you first set do_setup = -1 but later
use do_setup = 1. Perhaps they should both be 1. Other than that,
Acked-by: Steven A. Falco sfa...@harris.com
The -1 is for
On Tuesday 23 June 2009, Steven A. Falco wrote:
m25p80 spi0.0: invalid bits-per-word (0)
This message comes from spi_ppc4xx_setupxfer. I believe your patch
is doing what you intended (i.e. forcing an initial call to
spi_ppc4xx_setupxfer), but it exposes an OF / SPI linkage problem.
a...@arndb.de
Resent-by: Subrata Modak subr...@linux.vnet.ibm.com
Signed-off-by: David Brownell dbrown...@users.sourceforge.net
---
drivers/usb/host/Kconfig | 29 +++--
1 file changed, 15 insertions(+), 14 deletions(-)
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host
On Thursday 23 April 2009, Arnav Das wrote:
i am a newbie
Lesson #1: make sure your Subject: lines match the message
topic (I did a partial repair) and don't post to the wrong
list (e.g. PPC lists for OMAP questions).
and am doing a project on beagle board(running
omap3530). i am
On Thursday 08 January 2009, Stefan Roese wrote:
This adds a SPI driver for the SPI controller found in the IBM/AMCC
4xx PowerPC's.
Note that given some patches now in the mm tree, this needs
something like the appended fixup. Some common code has now
moved into the spi core.
- Dave
---
On Wednesday 22 April 2009, Stefan Roese wrote:
On Wednesday 22 April 2009, David Brownell wrote:
On Thursday 08 January 2009, Stefan Roese wrote:
This adds a SPI driver for the SPI controller found in the IBM/AMCC
4xx PowerPC's.
Note that given some patches now in the mm tree
On Thursday 08 January 2009, Stefan Roese wrote:
This adds a SPI driver for the SPI controller found in the IBM/AMCC
4xx PowerPC's.
+/*
+ * The PPC4xx SPI controller has no FIFO so each sent/received byte will
+ * generate an interrupt to the CPU. This can cause high CPU utilization.
+ *
On Tuesday 21 April 2009, Subrata Modak wrote:
Observing this for the first time:
CC drivers/usb/host/ohci-hcd.o
In file included from drivers/usb/host/ohci-hcd.c:1060:
drivers/usb/host/ohci-ppc-of.c:242:2: error: #error No endianess
Hmm, scripts/get_maintainer.pl doesn't report
the
On Tuesday 21 April 2009, Randy Dunlap wrote:
Since its feasible to say 'n' to both we get the compile error. How do
we enforce having at least one set?
Looks like using choice without optional would do it.
See Documentation/kbuild/kconfig-language.txt and various examples
in Kconfig*
Looks good.
Acked-by: Grant Likely grant.lik...@secretlab.ca
Acked-by: David Brownell dbrown...@users.sourceforge.net
I'll pick this up into my -next branch and ask Ben to pull it in the
next week or so.
---
This is an incremental patch to the patch (updated driver
for device
On Tuesday 25 November 2008, Stefan Roese wrote:
Changes in v5:
- Don't call setupxfer() from setup() so that the baudrate etc
won't get changed while another transfer is active, as suggested
by David Brownell.
Better, but this still doesn't seem quite right:
+static int
Also:
+static struct of_platform_driver spi_ppc4xx_of_driver = {
+ .owner = THIS_MODULE,
+ .name = DRIVER_NAME,
I'd hope the PPC folk eliminate this duplication soonish.
Those fields are obvious duplicates of the driver model
fields...
+ .match_table =
No comment from me on $SUBJECT beyond it seems plausible, but ...
On Tuesday 25 November 2008, David VomLehn wrote:
The important point, though, is that device tree is the only
thing approaching a standard on any non-x86-based platform for passing
structured information from the bootloader to
On Thursday 30 October 2008, Jason Hanna wrote:
Also, any pointers to sample/test code incorporating a spi protocol
driver would be incredibly helpful.
Look at Documentation/spi/*.c ... for user mode code
hooking up through spidev.
I'm very new to device driver
programming and don't really
On Friday 31 October 2008, Stefan Roese wrote:
+ dev_dbg(spi-dev, %s: mode %d, %u bpw, %d hz\n,
+ __FUNCTION__, spi-mode, spi-bits_per_word,
+ spi-max_speed_hz);
Oh, and checkpatch.pl would warn about __FUNCTION__ vs __func__ ...
the lock in the ch9getstatus(),
so to fix that bug the lock-less __qe_ep_queue() function
implemented and used by the ch9getstatus().
Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
Acked-by: David Brownell [EMAIL PROTECTED]
... noting that this *also* fixes a locking bug in qe_ep_queue
On Tuesday 18 November 2008, Anton Vorontsov wrote:
+ spin_lock_irqsave(udc-lock, flags);
+ ret = __qe_ep_queue(_ep, _req, gfp_flags);
+ spin_unlock_irqrestore(udc-lock, flags);
Why are you passing gfp_flags? Especially without
checking ... GFP_KERNEL will be illegal, for
'g_ether'
Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
Acked-by: David Brownell [EMAIL PROTECTED]
---
v2:
- Comment update per Alan Stern review.
replaces
usb.current/usb-fsl_qe_udc-report-disconnect-before-unbinding-fixing-oopses.patch
drivers/usb/gadget/fsl_qe_udc.c |3
] sys_delete_module+0x130/0x19c
[df145f40] [c00142d8] ret_from_syscall+0x0/0x38
[...]
unregistered gadget driver 'g_ether'
Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
Acked-by: David Brownell [EMAIL PROTECTED]
---
v2:
- Comment update per Alan Stern review.
drivers/usb/gadget
, and this causes few
repetitive messages in the kernel log.
This patch fixes the issue by using the usb_state machine, if the
usb controller has been already reset, just quit the reset irq
early.
Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
Acked-by: David Brownell [EMAIL PROTECTED]
Note
flushes the hardware fifos, finishes all
late transaction and thus prevents the corruption.
Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
Acked-by: David Brownell [EMAIL PROTECTED]
---
drivers/usb/gadget/fsl_qe_udc.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff
the driver won't queue the new
reqests.
This fixes a bug I'm observing with ethernet gadget while playing
with ifconfig usb0 up/down (the up/down sequence disables and
enables `in' and `out' endpoints).
Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
Acked-by: David Brownell [EMAIL PROTECTED
memory.
Fix this by setting udc_controller to NULL in case of errors.
While at it, also implement irq_of_parse_and_map()'s failure and cleanup
cases.
Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
Acked-by: David Brownell [EMAIL PROTECTED]
I seem to detect a lot of bugfix activity here
On Tuesday 11 November 2008, Anton Vorontsov wrote:
- spin_lock_irqsave(udc-lock, flags);
+ if (lock)
+ spin_lock_irqsave(lock, flags);
Ugly ugly ugly. Conditional locking is error prone ... don't.
Couldn't you just have the usb_ep_queue() method wrap lock calls
On Tuesday 11 November 2008, David Woodhouse wrote:
I believe you were also concerned that some device wouldn't want the
behaviour given by the existing sync_cmos_clock() function and workqueue
stuff in kernel/ntp.c, where we update the clock precisely half-way
through the second?
That's a
Yeah, we should have one of these. :)
On Monday 10 November 2008, Alessandro Zummo wrote:
@@ -30,7 +30,7 @@ config RTC_HCTOSYS
unnecessary fsck runs at boot time, and to network better.
config RTC_HCTOSYS_DEVICE
- string RTC used to set the system time
+ string RTC used
On Wednesday 22 October 2008, Benjamin Herrenschmidt wrote:
On Wed, 2008-10-22 at 14:04 -0700, David Brownell wrote:
So if we register the board infos after
the controller registered, then nobody will probe the board infos.
See above. If you're doing it right, there's no problem
On Wednesday 22 October 2008, Anton Vorontsov wrote:
--- a/drivers/gpio/pcf857x.c
+++ b/drivers/gpio/pcf857x.c
@@ -187,7 +187,7 @@ static int pcf857x_probe(struct i2c_client *client,
struct pcf857x *gpio;
int status;
-
On Wednesday 22 October 2008, Anton Vorontsov wrote:
The board info has another problem though. We can't remove it, thus
we can't implement module_exit() for the 'OF glue'.
That's not a problem. Why would you want to remove it?
And try to solve this problem... maybe then things will
On Wednesday 22 October 2008, Anton Vorontsov wrote:
So if we register the board infos after
the controller registered, then nobody will probe the board infos.
See above. If you're doing it right, there's no problem.
That is, scan the OF tables early. Just like PNP tables
get
On Wednesday 22 October 2008, Anton Vorontsov wrote:
So have it live in the __init text section...
Won't work, unfortunately. I2C devices are created by the
i2c controllers, via drivers/of_i2c.c of_register_i2c_devices().
And I'm pointing out a way to have the normal I2C core code
flow
On Monday 20 October 2008, Benjamin Herrenschmidt wrote:
This one is obviously broken and breaks booting on a whole bunch of
machines (including powermac's and thus my G5, it's never good when my
own machine breaks !).
Nice to see 3 SOB's and one Ack and nobody caught the obvious bug :-)
As
On Tuesday 21 October 2008, Benjamin Herrenschmidt wrote:
The notifier can be registered before the devices, though it's a little
bit fishy and fragile.
Easier I suppose to just have OF specific hooks in the bus code.
Like what I suggested: chip-aware OF glue drivers. The relevant
bus code
On Friday 17 October 2008, Anton Vorontsov wrote:
On Fri, Oct 17, 2008 at 01:24:42PM -0700, David Brownell wrote:
On Thursday 16 October 2008, Anton Vorontsov wrote:
+/*
+ * Platforms can define their own __dev_ versions to glue gpio_chips
with the
+ * architecture-specific code
On Thursday 16 October 2008, Anton Vorontsov wrote:
+/*
+ * Platforms can define their own __dev_ versions to glue gpio_chips with the
+ * architecture-specific code.
+ */
+#ifndef __dev_gpiochip_add
+#define __dev_gpiochip_add __dev_gpiochip_add
+static inline int __dev_gpiochip_add(struct
On Thursday 16 October 2008, Anton Vorontsov wrote:
+ if (of_gc-chip)
+ return of_gc-chip;
+ return of_gc-gc;
presumably there's a reason not to
of_gc-chip = of_gc-gc;
when this gets set up, so this can always be a simple
return of_gc-chip;
(and
On Friday 10 October 2008, Steven A. Falco wrote:
gpiolib can export GPIOs to userspace via sysfs. This patch modifies
the gpio_value_show() so that any non-zero value is explicitly printed
as 1, rather than whatever numerical value the lower-level driver returns.
Signed-off-by: Steve Falco
On Thursday 09 October 2008, Anton Vorontsov wrote:
I've incorporated the other changes, with one exception. I want
ppc4xx_gpio_get() to return 0 or 1 (rather than Anton's comment that any
non-zero value is ok), because when you use the new export feature in
sysfs, you see the raw value
On Wednesday 24 September 2008, Anton Vorontsov wrote:
what do you mean by dedicated function.. be a bit clearer in the commit
log.
This term is from the QE spec, I didn't invent anything. ;-)
Each pin in the I/O ports can be configured as a general-purpose
I/O signal or as a dedicated
On Tuesday 23 September 2008, Anton Vorontsov wrote:
qe_gpio_set_dedicated() is a platform specific function, which is used
to revert a pin to a dedicated function. Caller should have already
obtained the gpio via gpio_request().
Note the missing sibling function: putting the pin back into
On Wednesday 24 September 2008, Sergei Shtylyov wrote:
... then the root hub emulation is completely pointless.
It isn't. We always should emulate the root hub. The root hub
is part and parcel of any USB Host. Even the one-port one.
Hm, maybe that's what USB core thinks
On Thursday 14 August 2008, Laurent Pinchart wrote:
David, could you bear with gpio_to_chip() exported function, just as
a stopgap for a proper api?
I need gpio_to_chip() (or another 'proper API') as well for RTS/CTS
based flow control in the CPM/CPM2 UART driver.
I'l still say proper.
On Thursday 28 August 2008, Arnd Bergmann wrote:
+/*-
+ Gadget driver register and unregister.
+
--*/
+int
On Thursday 28 August 2008, Arnd Bergmann wrote:
If the gadget hardware drivers were registering the device with a
gadget_bus_type, you could still enforce the only one protocol
rule by binding every protocol to every device in that bus type.
And you'd have to rewrite all the gadget drivers
On Tuesday 02 September 2008, Li Yang-R58472 wrote:
Does RNDIS work too? If not, is it possible to add or doesn't
the HW support it?
RNDIS is a gadget(protocol) level thing. I believe it can work with
this driver although not tested myself.
It should, so long as the QE hardware
On Tuesday 02 September 2008, Joakim Tjernlund wrote:
Noted: AFAIK, RNDIS gadget in Linux doesn't interoperate with windows
well enough to be production level. Use at your own risk.
I see. If one wants to connect with CDC to Windows, what drivers are
there for Windows that works well
On Wednesday 24 September 2008, Joakim Tjernlund wrote:
I see. If one wants to connect with CDC to Windows, what drivers are
there for Windows that works well with Linux?
I believe MCCI has some. It also has drivers for a CDC subset,
pretty much the same one Linux has used forever
On Wednesday 24 September 2008, Anton Vorontsov wrote:
Anyway, just want to thank you for your time and persistence on this
matter, you're forcing others' people brains to *work*. And since you
rejected this approach too, I have no other option but to implement
something else... something
merge ...
Acked-by: David Brownell [EMAIL PROTECTED]
---
drivers/usb/core/hcd.h |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/core/hcd.h b/drivers/usb/core/hcd.h
index e710ce0..66b64d7 100644
--- a/drivers/usb/core/hcd.h
+++ b/drivers/usb/core/hcd.h
Applying patch mpc52xx-spi-fix0.patch
patching file drivers/spi/mpc52xx_spi.c
Hunk #1 FAILED at 149.
Hunk #2 succeeded at 154 (offset -7 lines).
Hunk #3 succeeded at 311 (offset -7 lines).
1 out of 3 hunks FAILED -- rejects in file drivers/spi/mpc52xx_spi.c
Patch mpc52xx-spi-fix0.patch does not
On Friday 25 July 2008, Grant Likely wrote:
From: Grant Likely [EMAIL PROTECTED]
Adds support for the dedicated SPI device on the Freescale MPC5200(b)
SoC.
It'd be a bit more clear if you said dedicated SPI controller;
device sounds like it's a struct spi_device.
Capsule summary: fault
On Friday 25 July 2008, Grant Likely wrote:
I don't know what to do with these patches. I'd really like to see them
in .27, and now that akpm has cleared his queue, the prerequisite patch
has been merged so they are ready to go in. However, even though there
has been favourable reception on
On Friday 16 May 2008, Scott Wood wrote:
On Fri, May 16, 2008 at 08:50:52PM +0400, Anton Vorontsov wrote:
config SPI_MPC83xx
tristate Freescale MPC83xx/QUICC Engine SPI controller
- depends on SPI_MASTER (PPC_83xx || QUICC_ENGINE) EXPERIMENTAL
+ depends on SPI_MASTER (PPC_83xx
and below:
Acked-by: David Brownell [EMAIL PROTECTED]
Thanks.
---
drivers/spi/spi.c | 139
---
include/linux/spi/spi.h | 10 +++
2 files changed, 105 insertions(+), 44 deletions(-)
diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
, so I wouldn't expect
this to need more approvals than it's already got.
Acked-by: David Brownell [EMAIL PROTECTED]
--
Anton Vorontsov
email: [EMAIL PROTECTED]
irc://irc.freenode.net/bd2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
On Sunday 29 June 2008, Jean Delvare wrote:
After the i2c adapter registers itself, of_register_i2c_devices() is called
which walks through the child nodes of the i2c adapter node in the device
tree. Each child node is an i2c device, and it immediately get
registered with the adapter.
On Friday 23 May 2008, Grant Likely wrote:
Question: spi_alloc_device() (and the original code) does a
spi_master_get() on the spi_master device. Doesn't spi_master_put()
need to be called when the device is discarded? spi_dev_put() doesn't
do that explicitly; is it an implicit operation
On Tuesday 17 June 2008, Grant Likely wrote:
This patch splits the allocation and registration portions of code out
of spi_new_device() and creates three new functions; spi_alloc_device(),
spi_register_device(), and spi_device_release().
I have no problem with the first two, but why the
On Friday 23 May 2008, Grant Likely wrote:
Very good point. Okay, so we cannot assume any correlation between
the number of CS lines and the number of child nodes to the SPI bus.
That wasn't what I was implying ... all the devices hooked
up to a given chipselect should be viewed as a single
On Saturday 24 May 2008, Grant Likely wrote:
+++ b/drivers/spi/spi_of.c
I think better placement for this is drivers/of, no?
Yes please.
Okay, I wasn't sure. Will do.
I'm having second thoughts about this. I think this code is more SPI
centric than it is OF centric. ie. it is
On Saturday 24 May 2008, Grant Likely wrote:
Isn't the same true for drivers/of/gpio.c or drivers/of/of_i2c.c, as well?
I would argue 'yes!'
... all the more reason to have the SPI glue go there too,
matching the ACPI/PCI precedent as well as those others!
On Wednesday 21 May 2008, Anton Vorontsov wrote:
+++ b/drivers/spi/spi_of.c
I think better placement for this is drivers/of, no?
Yes please.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
On Thursday 22 May 2008, Fabio Tosetto wrote:
* MMC host test driver
Unwise unless you really want to trash every MMC or SD card
you insert ...
You might consider not crossposting to such a large proportion
of the free world, by the way.
___
On Wednesday 21 May 2008, Grant Likely wrote:
spi-controller {
#address-cells = 2;
#size-cells = 0;
[EMAIL PROTECTED],f000 { reg = 0 f000 ; } // CS 0, SPI address f000
[EMAIL PROTECTED],f000 { reg = 1 f000 ; } // CS 1, SPI address f000
[EMAIL
On Friday 16 May 2008, Grant Likely wrote:
This patch splits the allocation and registration portions of code out
of spi_new_device() and creates three new functions; spi_alloc_device(),
spi_register_device(), and spi_device_release().
I have no problem with the first two, but why the last?
On Friday 16 May 2008, Grant Likely wrote:
In my mind; platform_data and the device tree are all about the same
thing: representation. In other words, how to describe the
configuration of the hardware independent of the driver itself.
Platform_data isn't what I'd call independent of drivers.
On Tuesday 15 April 2008, Laurent Pinchart wrote:
I'm implementing flow control and modem control lines support in the
cpm_uart driver.
The implementation is based on the GPIO lib. Modem control lines are
described in the device tree as GPIO resources and accessed through the OF
GPIO
On Tuesday 15 April 2008, Laurent Pinchart wrote:
Or maybe some kind of gpio_set_option() with flags specific to the
controller ? This could be used to enable open-drain outputs or internal
pull-ups for instance.
That presumes that the pin config is associated with the GPIO
controller,
On Wednesday 23 April 2008, Kumar Gala wrote:
On Apr 23, 2008, at 3:19 PM, Roel Kluin wrote:
mpc83xx_spi-irq is unsigned, so the test fails
Signed-off-by: Roel Kluin [EMAIL PROTECTED]
Any reason to not just make mpc83xx_spi-irq be int,
following normal practice everywhere? If not, I'll
On Wednesday 30 April 2008, Andrew Morton wrote:
+ spin_lock_irq(mpc83xx_spi-lock);
irq-safe.
...
+ spin_lock(mpc83xx_spi-lock);
not irq-safe.
Deliberate?
That latter one is inside an #if 0/#endif block, so it won't matter.
The #if 0 block bothered me. Maybe Joakim can
On Monday 21 April 2008, Anton Vorontsov wrote:
From: J. Random Hacker
Subject: [POWERPC] cleanup board initialization code
This patch removes vast amount of machine_arch_initcall()s that were
used to solely initialize some hardware, like this:
qe_add_gpio_chips();
fsl_gtm_init();
On Monday 21 April 2008, Anton Vorontsov wrote:
On Mon, Apr 21, 2008 at 01:01:12PM -0700, David Brownell wrote:
The way other platforms do this is to hav SOC-specific
init code, and have board-specific initcalls call the
relevant SOC-specific setup.
I don't know about other platforms
On Friday 18 April 2008, Anton Vorontsov wrote:
On Thu, Apr 17, 2008 at 09:21:40PM -0500, Kumar Gala wrote:
On Apr 17, 2008, at 5:41 PM, Anton Vorontsov wrote:
No problem. Would you prefer this to go under drivers/gpio/ ?
Yes that would be better. We actively worked on pull drivers
On Thursday 03 April 2008, Timur Tabi wrote:
Well, there is Linux CLK API (somewhat similar to GPIO API), but PowerPC
doesn't use it yet.
Yeah, I noticed that too. I'll add it to my to-do list, but I suspect that
someone else will get around to it before I do.
Note that there's some work
On Monday 10 December 2007, Anton Vorontsov wrote:
On Mon, Dec 10, 2007 at 02:55:24PM -0800, David Brownell wrote:
The point of CONFIG_GENERIC_GPIO is to be *the* conditional used to
tell whether that programming interface is available ... starting
from #include asm/gpio.h, and including
OF_PLATFORM_DRIVER glue, so error is bogus.
Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
Acked-by: David Brownell [EMAIL PROTECTED]
... for 2.6.25 ...
---
drivers/usb/host/ehci-hcd.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb
On Wednesday 20 February 2008, Greg KH wrote:
Greg Can you move the files under the hcd/ subdir
Oops, I ment host/ not, hcd/.
Sorry, I don't think that's a good idea as the hardware can do
peripheral as well, and as you can see in patch 4, a gadget driver is
on it's way.
Ok,
On Sunday 03 February 2008, Anton Vorontsov wrote:
On Sun, Feb 03, 2008 at 01:22:08PM -0800, David Brownell wrote:
[...]
So when you assume that a GPIO number can uniquely specify a pin for
use in function multiplexing ... you're stressing a nonportable
aspect of this issue.
Ditto
On Sunday 03 February 2008, Anton Vorontsov wrote:
This routine sets dedicated functions of the GPIO pin.
---
Hello David,
Yes, I did read Documentation/gpio.txt's last chapter. :-)
...that says:
One of the biggest things these conventions omit is pin multiplexing,
since this
On Sunday 03 February 2008, Anton Vorontsov wrote:
This patch implements support for the GPIO LIB API. Two calls
unimplemented though: irq_to_gpio and gpio_to_irq.
Also gpio_cansleep().
+Example of two SOC GPIO banks defined as gpio-controller nodes:
+
+ qe_pio_a: [EMAIL PROTECTED] {
the c67x00 device.
Communication is done over the HPI interface (16bit SRAM-like parallel bus).
Signed-off-by: Peter Korsgaard [EMAIL PROTECTED]
If you fix the issues I note below:
Acked-by: David Brownell [EMAIL PROTECTED]
+/**
+ * struct c67x00_sie - Common data associated
1 - 100 of 121 matches
Mail list logo
