--- On Thu, 9/30/10, Mingkai Hu wrote:
> From: Mingkai Hu
> Subject: [PATCH v3 6/7] mtd: m25p80: add a read function to read page by page
NAK.
We went over this before.
The bug is in your SPI master controller driver,
and the fix there involves mapping large reads
into multiple smaller re
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 I2C_CL
hes; but the second four
depend on them.
So I'll just say
Acked-by: David Brownell
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
> >> Signed-off-by: John Linn
> >
> > Looks good.
> >
> > Acked-by: Grant Likely
Acked-by: David Brownell
> > I'll pick this up into my -next branch and ask Ben to pull it in the
> > next week or so.
>
> > ---
> > This is an increme
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
t
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
>
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
---
d
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.
> >
> >
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 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 interfa
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
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 th
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 th
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 comme
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.
__
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
https://lists.ozlabs.org/listinfo/linuxppc
> > 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) ...
___
L
> - 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
Linuxppc-dev@list
--- On Mon, 8/9/10, Grant Likely 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 infrastructure that starts gene
--- On Tue, 8/10/10, Grant Likely 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
responsible for returning all b
Since I don't do OpenFirmware, let's hear from
Grant on this one.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
ann
Resent-by: Subrata Modak
Signed-off-by: David Brownell
---
drivers/usb/host/Kconfig | 29 +++--
1 file changed, 15 insertions(+), 14 deletions(-)
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -180,26 +180,27 @@ config USB_OHCI_HCD_PPC_SOC
E
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.
>
>
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
The "-1" is for the init
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 wa
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 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
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").
<[EMAIL PROTECTED]>
> ---
> arch/powerpc/sysdev/fsl_soc.c | 37 -
> drivers/spi/spi_mpc83xx.c | 6 +-
> 2 files changed, 25 insertions(+), 18 deletions(-)
For the SPI parts:
Acked-by: David Brownell <[EMAIL PROTECTED]>
Though it all lo
On Monday 21 January 2008, Peter Korsgaard wrote:
> The Cypress c67x00 (EZ-Host/EZ-OTG) controllers are multi-role low/fullspeed
> USB controllers. This patch series implements a HCD driver and shows the
> work-in-progress status of a gadget driver.
>
> I believe patch 1..3 are ready, and I would
On Monday 21 January 2008, Peter Korsgaard wrote:
> Sure, http://peter.korsgaard.com/c67x00-v3-v4.patch (not posting as
> it's more than 100k)
I like this bit:
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -3832,6 +3832,12 @@ L: [EMAIL PROTECTED]
> S: Maintained
> W: http://www.kroa
On Wednesday 23 January 2008, Grant Likely wrote:
> The question is about the device structure which used to be provided
> by the platform device instances and now there just uses the c67x00's
> device struct. I was under the impression that each USB HCD needs to
> have it's own struct device. I
General comment: if you're going to index arrays by enum
values, it's best to initialize them that way too. Else
you're expecting a particular optional policy for how the
enums get grown...
- Dave
On Monday 21 January 2008, Jean Delvare wrote:
> --- linux-2.6.24-rc8.orig/drivers/rtc/rtc-ds1307
rocontroller inside 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]>
> +/*
on the chip.
>
> This driver does not directly implement the HCD or gadget behaviours; it
> just controls access to the chip.
>
> Signed-off-by: Peter Korsgaard <[EMAIL PROTECTED]>
Acked-by: David Brownell <[EMAIL PROTECTED]>
> ---
> MAINTAINERS
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,
>
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]
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 "nonpor
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 wa
On Wednesday 20 February 2008, Peter Korsgaard wrote:
> +ifeq ($(CONFIG_USB_DEBUG),y)
> + EXTRA_CFLAGS+= -DDEBUG
> +endif
The canonical Sam Ravnborg comment is to replace that with:
+ccflags-$(CONFIG_USB_DEBUG)+= -DDEBUG
It's a newish idiom, most easily applied to new cod
; make[3]: *** [drivers/usb/host/ehci-hcd.o] Error 1
>
> ehci-hcd.c actually contains 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/
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 "
On Wednesday 24 October 2007, Matt Sealey wrote:
> Can we just make sure real quickly that the changing of compatibles
> doesn't break existing, not-easily-flashable firmwares?
Yeah, I'm not keen on such breakage either...
___
Linuxppc-dev mailing list
L
On Saturday 24 November 2007, Alan Cox wrote:
> >
> > What about for platforms where irq 0 is a valid irq?
>
> There are no such platforms. Linus made that absolutely clear every time
> this came up before
>
> 0 - No IRQ
>
> A platform with a physical or bus IRQ of 0 needs t
On Friday 23 November 2007, Grant Likely wrote:
>
> This patch series is based on the c67x00 work done by Peter Korsgaard and
> posted back in April this year.
What's changed since that version? Were the comments sent
at that time addressed?
___
Li
On Friday 23 November 2007, Grant Likely wrote:
> Some multi-role (host/peripheral) USB controllers use a shared interrupt
> line for all parts of the chip.
Like the musb_hdrc code ... soonish to go upstream (it needs some
updates to catch up to usbcore urb->status changes), this is used
by the No
On Friday 23 November 2007, Grant Likely wrote:
> +/* These functions could also be implemented with SPI of HSS.
> + * This is currently not supported */
Give that this "HPI" interface seems to use a parallel bus
with irq-safe synchronous accesses, and SPI is a serial bus
where synchronous accesse
On Friday 23 November 2007, Grant Likely wrote:
> +config USB_C67X00_DRV
> + tristate "Cypress C67x00 support"
> + # only allowed to be =y if both USB!=m and USB_GADGET!=m
This is wrong. Remember that since this is a dual-role driver,
there are exactly three possible driver modes ...
On Saturday 24 November 2007, Grant Likely wrote:
> On 11/24/07, David Brownell <[EMAIL PROTECTED]> wrote:
> > On Friday 23 November 2007, Grant Likely wrote:
> > > +config USB_C67X00_DRV
> > > +tristate "Cypress C67x00 support"
> > > +# on
On Friday 30 November 2007, Arnd Bergmann wrote:
> 6100 lines means it's still the second-largest hcd driver in the kernel,
> only drivers/usb/host/u132-hcd.c has even more.
~/kernel/g26/drivers/usb/host$ wc -l ohci*[hc] |grep total
9485 total
~/kernel/g26/drivers/usb/host$ wc -l ehci*[hc] |grep
On Sunday 25 November 2007, Benjamin Herrenschmidt wrote:
> While there, any reason why we do the read of the interenable register
> and mask ? Is that actually useful in practice ? I haven't removed it
> but it might be a good candidate if we want to save on MMIO reads.
The code uses that registe
.
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
---
Suitable IMO for 2.6.24 final.
drivers/usb/host/ohci-hcd.c | 23 +--
1 file changed, 13 insertions(+), 10 deletions(-)
--- g26.orig/drivers/usb/host/ohci-hcd.
during the donelist processing it's trying to safeguard) and
useless as this IRQ may not be reissued until it's acked (unless this
legacy code is an uncommented workaround for some chip erratum).
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
Signed-off-by: David Brownell <[E
> I'm interested in your opinion about that patch. You're also Cc'ed
> to patch that using that feature.
>
> I know, currently that patch will conflict with GPIOLIB patches in -mm,
> so this is only RFC.
The point of CONFIG_GENERIC_GPIO is to be *the* conditional used to
tell whether that programm
On Monday 06 August 2007, Anton Vorontsov wrote:
> +
> + if (pm)
> + pm--;
> + else /* this floods dmesg if using mmc_spi, so dbg */
> + dev_dbg(&spi->dev, "Requested speed is too "
> +
> >> - depends on SPI_MASTER && PPC_83xx && EXPERIMENTAL
> >> + depends on SPI_MASTER && (PPC_83xx || PPC_85xx) && EXPERIMENTAL
> >
> > Should that really be just PPC_83xx || QUICC_ENGINE?
>
> Well, I thought about that. By now I'm unsure if every QE
> implementation will be compatible with furth
> @@ -612,7 +612,7 @@ static inline u32 hc32_to_cpup (const st
> * to arch/powerpc
> */
>
> -#ifdef CONFIG_STB03xxx
> +#if defined(CONFIG_STB03xxx) || defined(CONFIG_440EP) ||
> defined(CONFIG_440EPX)
> #define OHCI_BE_FRAME_NO_SHIFT 16
> #else
> #define OHCI_BE_FRAME_NO_SHIFT
> > Near as I can tell, the original code is wrong ... the hcca->frame_no
> > byte offset is fully specified, so that shift should always be 16.
>
> Are you saying that it should always be #define OHCI_BE_FRAME_NO_SHIFT
> 16 for big endian platforms?
More than that, I'm saying that shouldn't even
> >> However, based on one other post, I suspect at least one Freescale
> >> part will need to declare a chip quirk for this case.
> >
> > Which Freescale part do you think needs this?
>
> I've looked at drivers/usb/host/Kconfig
> It seems to be MPC52xx.
> David, is that the one you mentioned?
I
On Monday 24 September 2007, Valentine Barshak wrote:
> Some PowerPC systems have a built-in EHCI controller.
> This is a device tree aware version of the EHCI controller driver.
> Currently it's been tested on the PowerPC 440EPx Sequoia board.
> Other platforms can be added later.
> The code is ba
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 bi
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, rat
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 la
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 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.
___
Linuxp
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
> > [
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
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 Friday 23 May 2008, Anton Vorontsov wrote:
>
> This is second attempt to write the OpenFirmware bindings for the
> MMC-over-SPI (and SPI bindings in general).
Summary: an OF-specific wrapper around the mmc_spi platform code.
I think a wrapper to encapsulate all the OF-specific knowledge make
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 ad
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
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 som
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 pul
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_i
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.
>
&g
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?
stops using the "bitbang" framework (except for a few
constants).
Signed-off-by: Joakim Tjernlund <[EMAIL PROTECTED]>
[ Roel Kluin <[EMAIL PROTECTED]>: "irq" needs to be signed ]
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
---
drivers/spi/Kconfi
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.
inuxppc-dev/2008-July/060109.html
If you like ... but this is an OF-specific change, making
it conform with the interface spec, so I wouldn't expect
this to need more approvals than it's already got.
Acked-by: David Brownell <[EMAIL PROTECTED]>
>
> --
> Anton Voronts
device tree.
>
> Signed-off-by: Grant Likely <[EMAIL PROTECTED]>
Given the comment fixes noted above and below:
Acked-by: David Brownell <[EMAIL PROTECTED]>
Thanks.
> ---
>
> drivers/spi/spi.c | 139
> ---
>
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 app
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:
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 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_MAS
nto
his tree for 2.6.28-rc0 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
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
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
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
On Thursday 28 August 2008, Arnd Bergmann wrote:
> > +/*-
> > + Gadget driver register and unregister.
> > +
> > --*/
> > +int usb_gadget_register_dri
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 driver
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
On Wednesday 24 September 2008, Anton Vorontsov wrote:
> We'll need this function to write platform-specific hooks to deal
> with pin's dedicated functions. Quite obviously this will work only
> for the platforms with 1-to-1 GPIO to PIN mapping.
>
> This is stopgap solution till we think out and i
1 - 100 of 140 matches
Mail list logo
