--- 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
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
--- 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
--- 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
> - 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
> > 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
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
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:
>
> > 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
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 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 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 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.
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
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
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").
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 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 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 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 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 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 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.
>
>
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 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 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 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.
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 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 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
> >> 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
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 = spi_ppc4xx_of_ma
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 q
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
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__ ...
_
On Friday 31 October 2008, Stefan Roese wrote:
> +static int spi_ppc4xx_setupxfer(struct spi_device *spi, struct spi_transfer
> *t)
> +{
> ...
>
> + if (in_8(&hw->regs->cdm) != cdm)
> + out_8(&hw->regs->cdm, cdm);
... writes to hardware, updating SPI the clock ra
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 r
->lock again
>
> It seems unsafe to temporarily drop 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 &l
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
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
the driver accesses nonexistent 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 <
talled, since 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 Voron
gt;
> The qe_ep_reset() effectively 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 |
nt the disconnection events, 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 <[
b2_udc]
> [df145ed0] [e10c4c40] usb_composite_unregister+0x3c/0x4c [g_ether]
> [df145ee0] [c006bcc0] sys_delete_module+0x130/0x19c
> [df145f40] [c00142d8] ret_from_syscall+0x0/0x38
> [...]
> unregistered gadget driver 'g_ether'
>
> Signed-off-by: Anton Vorontsov <
0/0x19c
> [cfb93f40] [c00142d8] ret_from_syscall+0x0/0x38
> [...]
> fsl_qe_udc e01006c0.usb: unregistered gadget driver 'g_ether'
>
> Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
Acked-by: David Brownell <[EMAIL PROTECTED]>
> ---
>
&g
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 "
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, 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
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
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
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 thin
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
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 :-)
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
> >
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
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(
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
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
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... someth
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
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
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 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 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 Thursday 28 August 2008, Arnd Bergmann wrote:
> > +/*-
> > + Gadget driver register and unregister.
> > +
> > --*/
> > +int usb_gadget_register_dri
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 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 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, 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
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 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
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 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:
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
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
> ---
>
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
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 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 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, 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 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 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 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 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 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, 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 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 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 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 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 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.
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 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?
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 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 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 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 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 "
1 - 100 of 140 matches
Mail list logo