Re: [PATCH v3 01/12] misc: add driver for sequencer serial port
On Friday 22 October 2010 14:39:33 Cyril Chemparathy wrote:
> >> +/* Register Access Helpers */
> >> +static inline u32 ssp_read(struct ti_ssp *ssp, int reg)
> >> +{
> >> +return __raw_readl(ssp->regs + reg);
> >> +}
> >> +
> >> +static inline void ssp_write(struct ti_ssp *ssp, int reg, u32 val)
> >> +{
> >> +__raw_writel(val, ssp->regs + reg);
> >> +}
> >
> > Why are the __raw functions used here?
> >
>
> These registers are to be accessed native endian at all times, and
> therefore the le32 conversion done otherwise is inappropriate.
Won't that break on out-of-order CPUs that need the extra synchronization
done in readl/writel?
Arnd
--
Nokia and AT&T present the 2010 Calling All Innovators-North America contest
Create new apps & games for the Nokia N8 for consumers in U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store
http://p.sf.net/sfu/nokia-dev2dev
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH] spi: spidev: Add 32 bit compat ioctl()
On Wednesday 02 February 2011, Grant Likely wrote:
> On Tue, Feb 01, 2011 at 10:02:46AM +0100, Bernhard Walle wrote:
> > Add the compat_ioctl for operations on /dev/spi* so that 32 bit
> > userspace applications can access SPI. As far as I can see all data
> > structure are already prepared for that, so no additional conversion has
> > to be done.
> >
> > My use case is MIPS with N32 userspace ABI and toolchain, and that was
> > also the platform where I tested it successfully (Cavium Octeon).
> >
> > Signed-off-by: Bernhard Walle
>
> Arnd, can you please give your opinion on this one? I haven't fully
> got my head around the subtleties of 32/64 bit file_operations.
The patch is correct on everything except s390, which does not have SPI.
The only thing that is missing for s390 is a pointer conversion of the ioctl
argument, like:
static long
compat_spidev_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
{
return spidev_ioctl(filp, cmd, (unsigned long)compat_ptr(arg));
}
Some years ago, I proposed adding a common
#ifdef CONFIG_COMPAT
long generic_compat_ioctl(struct file *filp, unsigned int cmd, unsigned long
arg)
{
if (!file->unlocked_ioctl)
return -ENOTTY;
return filp->f_ops->unlocked_ioctl(filp, cmd, (unsigned
long)compat_ptr(arg));
}
#else
#define generic_compat_ioctl NULL
#endif
for this purpose, but it never made it in. Maybe I should try again.
Arnd
--
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires
February 28th, so secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsight-sfd2d
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH] spi: spidev: Add 32 bit compat ioctl()
On Wednesday 02 February 2011, Bernhard Walle wrote: > Add the compat_ioctl for operations on /dev/spi* so that 32 bit > userspace applications can access SPI. As far as I can see all data > structure are already prepared for that, so no additional conversion has > to be done. > > My use case is MIPS with N32 userspace ABI and toolchain, and that was > also the platform where I tested it successfully (Cavium Octeon). > > Signed-off-by: Bernhard Walle I think you now need to #include as well, to get the definition of compat_ptr(). Otherwise looks good. Arnd -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH] spi: spidev: Add 32 bit compat ioctl()
On Wednesday 02 February 2011, Bernhard Walle wrote: > Add the compat_ioctl for operations on /dev/spi* so that 32 bit > userspace applications can access SPI. As far as I can see all data > structure are already prepared for that, so no additional conversion has > to be done. > > My use case is MIPS with N32 userspace ABI and toolchain, and that was > also the platform where I tested it successfully (Cavium Octeon). > > Signed-off-by: Bernhard Walle Reviewed-by: Arnd Bergmann -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH] spi: reorganize drivers
On Sunday 05 June 2011, Grant Likely wrote:
> rename drivers/spi/{omap2_mcspi.c => spi_omap2_mcspi.c} (100%)
> rename drivers/spi/{omap_spi_100k.c => spi_omap_100k.c} (100%)
> rename drivers/spi/{omap_uwire.c => spi_omap_uwire.c} (100%)
> rename drivers/spi/{orion_spi.c => spi_orion.c} (100%)
> rename drivers/spi/{amba-pl022.c => spi_pl022.c} (100%)
> rename drivers/spi/{pxa2xx_spi.c => spi_pxa2xx.c} (100%)
> rename drivers/spi/{pxa2xx_spi_pci.c => spi_pxa2xx_pci.c} (100%)
> rename drivers/spi/{ti-ssp-spi.c => spi_ti_ssp.c} (100%)
> rename drivers/spi/{tle62x0.c => spi_tle62x0.c} (100%)
> rename drivers/spi/{xilinx_spi.c => spi_xilinx.c} (100%)
I recently looked at the directory structure in drivers/ and found a lot
of bus drivers with very few files, plus a few bus drivers with a lot
of files in them besides directories for non-bus specific subsystems.
I think it would be good to move them into a deeper directory drivers/bus/
if we have support from the maintainers, and it's probably better if we
only have to move the files once to reduce the amount of churn on the
MAINTAINERS file and any out of tree patches.
Specifically, I'd like to do these moves:
drivers/{ => bus}/amba
drivers/{ => bus}/dio
drivers/{ => bus}/eisa
drivers/{ => bus}/firewire
drivers/{ => bus}/i2c
drivers/{ => bus}/mca
drivers/{ => bus}/nubus
drivers/{ => bus}/pcmcia
drivers/{ => bus}/rapidio
drivers/{ => bus}/sbus
drivers/{ => bus}/spi
drivers/{ => bus}/ssb
drivers/{ => bus}/tc
drivers/{ => bus}/uwb
drivers/{ => bus}/virtio
drivers/{ => bus}/vlync
drivers/{ => bus}/w1
drivers/{ => bus}/zorro
This leaves out the two most common buses, USB and PCI, mostly because
the directories contain a lot of stuff that is not really bus code
but actual drivers. It does include i2c and spi, which stick out by
being a lot larger than most others.
Opinions? Move or don't move?
Arnd
--
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Discover what all the cheering's about.
Get your free trial download today.
http://p.sf.net/sfu/quest-dev2dev2
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH] spi: reorganize drivers
On Monday 06 June 2011, James Bottomley wrote: > I'd say it only makes sense if we do it for all busses ... so USB and > PCI would have to move too. Logically, the bus code should move and we > should be left with the drivers in both of those directories. I'd also > say that we don't have to deepen the tree: /bus would be fine. That > way, /drivers/ would be only for specific drivers, with non > bus specific drivers we just group them by function as now. A top-level /bus would work for me, and I guess would also address Russell's concern. Regarding bus-specific drivers, we're gradually moving those out of the bus specific directories anyway, basically the only bus directory that really has device driver in it is USB at this point. It makes some sense to have a bus-specific low-level user space interface driver like sg or uio in the bus directory, but everything else should really belong into some other subsystem. > What about the half busses (like SCSI)? I think SCSI is a really special case, not just because of its size of more than twice the code than everything else I would suggest to move, but also because it contains mostly host drivers but very few device drivers (sd, sr, osst, st, and sg). In that sense it's more a class of devices than a bus and fits in the same category as mmc and ata than a bus like pci or i2c that have a multitude of device drivers. > Finally, is there any real point (other than we can do it)? what is > actually helped by having the bus code obviously separated from the > driver code (assuming we sort out what is bus and what is driver)? Mostly I think the drivers/ subdirectory is getting a bit cluttered with stuff that doesn't really fit together, and bus drivers are typically directories with less than five files in them, apart from the few exceptions that already came up. This is about to get worse as we introduce new subsystems (e.g. iommu, irq, clocksource, eeprom, nvram, ...) into which we are moving code from arch/arm, drivers/char and drivers/misc. Having buses and drivers in a separate hierarchy would make the drivers directory and the respective menuconfig list more clearly structured IMHO. Arnd -- Simplify data backup and recovery for your virtual environment with vRanger. Installation's a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Discover what all the cheering's about. Get your free trial download today. http://p.sf.net/sfu/quest-dev2dev2 ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH] spi: reorganize drivers
On Monday 06 June 2011, Jean Delvare wrote:
> On Mon, 6 Jun 2011 13:21:07 +0200, Arnd Bergmann wrote:
> > A top-level /bus would work for me, and I guess would also address Russell's
> > concern. Regarding bus-specific drivers, we're gradually moving those out
> > of the bus specific directories anyway, basically the only bus directory
> > that really has device driver in it is USB at this point. It makes some
> > sense to have a bus-specific low-level user space interface driver like
> > sg or uio in the bus directory, but everything else should really belong
> > into some other subsystem.
>
> Err, what about I2C and SPI? Aren't drivers/i2c/busses and drivers/spi
> full of "device drivers"? Or are these what you call "bus-specific
> drivers"? Maybe we need to define all the terms before the discussion
> continues further.
drivers/i2c/busses and drivers/spi are full of what I would call "bus
drivers" or "host drivers". They bind to a device from another bus
(platform, pci, ...) and export devices of their own type (i2c, spi, ...).
This is what all bus drivers do.
An i2c or spi device driver would in turn bind to that device and
provide a functionality not specific to that bus (e.g. hwmon, input,
leds, rtc or media).
> > (...)
> > This is about to get worse as we introduce new subsystems (e.g. iommu,
> > irq, clocksource, eeprom, nvram, ...) into which we are moving
> > code from arch/arm, drivers/char and drivers/misc. Having buses and
> > drivers in a separate hierarchy would make the drivers directory and
> > the respective menuconfig list more clearly structured IMHO.
>
> This gets interesting. Would you suggest for example that i2c-core.c
> goes to bus/i2c, and drivers/i2c/busses becomes drivers/i2c? And that
> CONFIG_I2C is somewhere in menuconfig, and the hardware driver
> selection for drivers/i2c is in a totally different place?
No, all of drivers/i2c would go into bus/i2c or drivers/bus/i2c, there
is no point splitting that. The part that would no go there is the various
drivers that are already not under drivers/i2c but are for devices
connected to an i2c bus.
The confusion is probably that in case of drivers/scsi and drivers/usb,
both bus and device drivers are in the same subdirectories. If we move
drivers/usb to bus/usb, I would probably recommend to split
drivers/usb/{serial,storage,atm,misc} out of it and move it to
drivers/{tty/usb-serial,block/usb,net/usb/atm,misc/usb} though, to
make it look more like PCI or i2c that already have a clean split.
> While I am surprised, I am not necessarily objecting. But it seems that
> you should better define what your actual plan is, before asking us if
> we agree with it.
My original plan was to think this through a bit more, but Grant posted
the big spi reorganization, so I jumped in on that because it wouldn't
be nice to have to move all those drivers again.
Arnd
--
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Discover what all the cheering's about.
Get your free trial download today.
http://p.sf.net/sfu/quest-dev2dev2
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH] spi: reorganize drivers
On Monday 06 June 2011, Stefan Richter wrote: > On Jun 06 Arnd Bergmann wrote: > > On Monday 06 June 2011, Jean Delvare wrote: > On drivers/firewire/: > > FireWire drivers are currently spread over drivers/firewire (three > link-layer controller drivers + the IEEE 1394 core + two IEEE 1394 > application layer drivers), drivers/media/dvb/firewire/ (one 1394 > application layer driver), sound/firewire/ (two 1394 application layer > drivers, more are planned to be added there). > > From the Linux driver model POV, > 1. the IEEE 1394 core driver implements the firewire bus, > 2. the link-layer controller drivers implement pci bus based devices, > 3. the IEEE 1394 application layer drivers implement firewire bus based > devices. The two of them that are located in drivers/firewire/ > expose a SCSI LLD (a transport in SCSI Architecture Model terms, but > a host rather than a transport in Linux implementation terms) and a > networking interface driver. > > Number 2 is something one would expect to find in a hypothetical > drivers/bus/ directory. But where do the others belong? > > Would type 1 drivers be kept in drivers/bus/firewire/? I understand your > above response to Jean that this is what you have in mind. Correct. > firewire-sbp2 could be moved into drivers/scsi/, and firewire-net could be > moved into drivers/net/. But what about maintenance? They could still be > maintained via linux1394-2.6.git because this worked so far, but then the > directory structure might irritate people who don't use > scripts/get_maintainer.pl all the time. Well, I could actually picture > firewire-net to be maintained via the net development tree, but I do > wonder how well firewire-sbp2 maintenance through the scsi tree would work. I guess the real question is whether firewire should be considered a bus like USB or a device class like SCSI, and it's abit of a grey area (SCSI is too). If you declare it to be a bus, I'd suggest moving the sbp2 and network drivers to drivers/scsi and drivers/net. If you like to think of firewire as a closed subsystem instead, it's probably better to leave all of it in drivers/firewire. > PS, > these are the same questions like with USB, only on a smaller scale. (The > usb-storage driver is maintained through the usb tree as well, not the > scsi tree. drivers/net/usb/ has got T: git .../gregkh/usb-2.6.git > assigned in MAINTAINERS but most of the commits there are actually done by > DaveM.) The difference that I see with usb-storage is that this one is really a set of different drivers for all sorts of devices, while the firewire sbp2 driver feels more like a single driver that includes a few special cases. Also, USB is generally perceived as a generic interconnect, while firewire is seen primarily as a way to attach disk drives. The differences are of course gradual. Arnd -- Simplify data backup and recovery for your virtual environment with vRanger. Installation's a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Discover what all the cheering's about. Get your free trial download today. http://p.sf.net/sfu/quest-dev2dev2 ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH 0/6] spi/spi-pl022 fixes
On Wednesday 10 August 2011, Linus Walleij wrote: > The basic assumption is that patches are orthogonal and apply > without conflicts, i.e. patch different parts of the kernel tree or > different lines in the same file. > > Second assumption is that if patches do collide, the subsystem > maintainer can solve most conflicts, and is expected to do > so. Torvalds sets an example by requesting that subsystem > maintainers do not fixup conflicts between subsystems so he > can see them himself. > > Then there are special cases when you get a strong > coupling between patches. > > In these special cases, ask the subsystem maintainer what to > base the patches on. Usually it's some commit on the subsystem > tree rather than -next. > > This is my understanding of how we work, maybe I should > patch Documentation/development-process/*, Arnd do you have > anything to add? No, your explanations are pretty much what I would have said. Arnd -- uberSVN's rich system and user administration capabilities and model configuration take the hassle out of deploying and managing Subversion and the tools developers use with it. Learn more about uberSVN and get a free download at: http://p.sf.net/sfu/wandisco-dev2dev ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH 5/9] ARM: kirkwood: use devicetree for orion-spi
On Sunday 10 June 2012, Andrew Lunn wrote:
> @@ -26,6 +26,11 @@ static struct of_device_id kirkwood_dt_match_table[]
> __initdata = {
> { }
> };
>
> +struct of_dev_auxdata kirkwood_auxdata_lookup[] __initdata = {
> + OF_DEV_AUXDATA("marvell,orion-spi", 0xf1010600, "orion_spi.0", NULL),
> + {},
> +};
> +
> static void __init kirkwood_dt_init(void)
> {
How about instead adding the clkdev for "f1010600.spi" so you don't need the
auxdata?
Arnd
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH 1/9] ARM: Kirkwood: Add interrupt controller support for DT boards
On Sunday 10 June 2012, Andrew Lunn wrote:
> +static int __init kirkwood_add_irq_domain(struct device_node *np,
> + struct device_node
> *interrupt_parent)
> +{
> + kirkwood_init_irq();
> + irq_domain_add_legacy(np, 64, 0, 0, &irq_domain_simple_ops, NULL);
> + return 0;
> +}
> +
> +static const struct of_device_id kirkwood_irq_match[] = {
> + { .compatible = "marvell,orion-intc",
> + .data = kirkwood_add_irq_domain, },
> + {},
> +};
> +
> +static void __init kirkwood_dt_init_irq(void)
> +{
> + of_irq_init(kirkwood_irq_match);
> +}
> +
I think if you compute the number of interrupts in the domain from the number of
registers that are described in the device tree, call orion_irq_init()
based on those registers, and use irq domains for the gpio stuff as Rob
suggested,
this init_irq function can become completely generic to all orion platforms.
That is what I tried to do with an earlier patch, which was flawed for other
reasons.
Arnd
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH 5/9] ARM: kirkwood: use devicetree for orion-spi
On Thursday 14 June 2012, Andrew Lunn wrote: > We either have auxdata and clean clock code, or no auxdata and messy > clock code with lots of aliases. > > The auxdata is also not limited to the name of the clocks. It allows > me to diff the kernel log for a DT boot and a none DT boot of the same > box and see they are identical. I've found a few typo's that way, and > not been hindered by noise of the devices changing name is useful. > > Once we have the clock tree described in DT, then i think it makes > sense to remove these auxdata entries. > Ok, fair enough. Arnd -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH 1/9] ARM: Kirkwood: Add interrupt controller support for DT boards
On Thursday 14 June 2012, Andrew Lunn wrote: > > I think if you compute the number of interrupts in the domain from the > > number of > > registers that are described in the device tree, call orion_irq_init() > > based on those registers, and use irq domains for the gpio stuff as Rob > > suggested, > > this init_irq function can become completely generic to all orion platforms. > > I'm reworking the GPIO stuff at the moment, moving it to use IRQ > domains for its interrupts. That code will be generic to all Orion > platforms. I'm modeling the code on the AT91 GPIO handler, since that > has a similar structure, one hardware interrupt for a number of GPIO > lines, which is in software demultiplexed and triggers secondary level > interrupts. The major difference is that AT91 has one hardware > interrupt for a GPIO chip with 32 lines, where as Orion has 4 hardware > interrupt lines, so maybe four interrupt domains, for one GPIO chip > with 32 lines. My guess is that you're still better off with a single interrupt domain for 32 lines, or even for all the gpio lines, but I'm sure you can find a solution that works best for you. > Non-GPIO interrupts are more of a problem. Underneath it uses the > generic-chip interrupt code. The patchset to add _domain versions of > these calls is stalled. So i think for the moment, we need to stay > with the domain bolted on top, until generic-chip gets domain > support. I would also expect that generic-chip also gets a common DT > binding which any SoC can use. I suggested that before, and the comments I got back then were that we should treat the generic irq chip more like a library and keep the device tree binding at a higher level. If I understood things right, that means we would just have one plat-orion (or mach-mvebu later) irq chip abstraction that handles the DT binding and the irq domains itself but uses the generic irq chip code to implement the actual irq handling. > My aim at the moment is to get something which works well enough that > we can add DT support to other drivers. Without interrupts, we are not > going to get very far. We can later rip it out what i create now and > replace it once generic-chip becomes domain and DT aware, and there > should be no effect on other drivers. Right. I just want to ensure that we don't need to change the bindings in incompatible ways. Arnd -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH v2 01/12] ARM: Orion: DT support for IRQ and GPIO Controllers
On Tuesday 03 July 2012, Andrew Lunn wrote:
> Both IRQ and GPIO controllers can now be represented in DT. The IRQ
> controllers are setup first, and then the GPIO controllers. Interrupts
> for GPIO lines are placed directly after the main interrupts in the
> interrupt space.
Overall looks very good.
> diff --git a/Documentation/devicetree/bindings/arm/mrvl/intc.txt
> b/Documentation/devicetree/bindings/arm/mrvl/intc.txt
> index 80b9a94..8927e10 100644
> --- a/Documentation/devicetree/bindings/arm/mrvl/intc.txt
> +++ b/Documentation/devicetree/bindings/arm/mrvl/intc.txt
> @@ -38,3 +38,22 @@ Example:
> reg-names = "mux status", "mux mask";
> mrvl,intc-nr-irqs = <2>;
> };
> +
> +* Marvell Orion Interrupt controller
> +
> +Required properties
> +- compatible : Should be "marvell,orion-intc".
> +- #interrupt-cells: Specifies the number of cells needed to encode an
> + interrupt source. Supported value is <1>.
> +- interrupt-controller : Declare this node to be an interrupt controller.
> +- reg : Interrupt mask address.
I think you should clarify that the "reg" property can be multiple
4-byte ranges, because that is fairly unusual.
> +#ifdef CONFIG_OF
> +static int __init orion_add_irq_domain(struct device_node *np,
> +struct device_node *interrupt_parent)
> +{
> + int i = 0, irq_gpio;
> + void __iomem *base;
> +
> + do {
> + base = of_iomap(np, i);
> + if (base) {
> + orion_irq_init(i * 32, base);
> + i++;
> + }
> + } while (base);
> +
> + irq_domain_add_legacy(np, i * 32, 0, 0,
> + &irq_domain_simple_ops, NULL);
> +
> + irq_gpio = i * 32;
> + orion_gpio_of_init(irq_gpio);
> +
> + return 0;
> +}
> +
> +static const struct of_device_id orion_irq_match[] = {
> + { .compatible = "marvell,orion-intc",
> + .data = orion_add_irq_domain, },
> + {},
> +};
> +
> +void __init orion_dt_init_irq(void)
> +{
> + of_irq_init(orion_irq_match);
> +}
> +#endif
I'm wondering about this one. The other platforms usually put the secondary
interrupt controllers into the same match table, while you call
orion_gpio_of_init
from orion_add_irq_domain. Can you explain why you do this? Does it have
any disadvantages?
Arnd
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH v2 01/12] ARM: Orion: DT support for IRQ and GPIO Controllers
On Thursday 05 July 2012, Andrew Lunn wrote: > > > > I'm wondering about this one. The other platforms usually put the secondary > > interrupt controllers into the same match table, while you call > > orion_gpio_of_init > > from orion_add_irq_domain. Can you explain why you do this? Does it have > > any disadvantages? > > The issue is knowing what IRQ number to use for the secondary > interrupts. > > Orion use generic chip interrupts, both for the main interrupts and > the GPIO interrupts. This does not yet support irq domain, so i have > to layer a legacy domain on top. The legacy domain needs to know the > first IRQ and the number of IRQs. For the primary IRQs that is > easy. However, GPIO IRQ is not so easy, it depends on how many primary > IRQs there are. This is not fixed. Orion5x has 32, Dove 64, kirkwood, > 64, and mv78xx0 has 96. I need to know this number when adding the > GPIO secondary IRQ legacy domain. By calling orion_gpio_of_init() in > the orion_add_irq_domain() i have this number to hand. If i used to > entries in the match table, i would have to put this number into some > global variable, or somehow ask the IRQ subsystem what the next free > IRQ number is. But couldn't you store the number of interrupts for the primary controller in a local variable? I think the of_irq code already guarantees that the parent is probed first. > As for disadvantages, humm. Dove has yet more interrupts, from the > PMU. They are currently unsupported in DT. When we add support for the > PMU interrupt controller, we are going to have the same problem, what > IRQ base should it use. Either we extend the chaining, calling > dove_pmu_of_init from orion_gpio_of_init(), where we know the next > free IRQ. Or we find out how to ask the IRQ subsystem for the next > available. Better still, the work to make generic chip interrupts irq > domain aware would get completed, and we can swap all this code to irq > domain linear and this whole probable probably goes away. Yes, that makes sense. Using the linear domain should solve all these nicely. Arnd -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH v2 01/12] ARM: Orion: DT support for IRQ and GPIO Controllers
On Thursday 05 July 2012, Sebastian Hesselbarth wrote:
> Andrew,
>
> is it possible to group all gpio banks into one DT description?
> For mach-dove it could be something like:
>
> gpio: gpio-controller {
> compatible = "marvell, orion-gpio";
> ...
>
> bank0@d0400 {
> reg = <0xd0400 0x40>;
> ngpio = <8>;
> mask-offset = <0>;
> interrupts = <12>;
> };
>
> bank1@d0400 {
> reg = <0xd0400 0x40>;
> ngpio = <8>;
> mask-offset = <8>;
> interrupts = <13>;
> };
This way you have multiple nodes with the same register
and different names, which is not how it normally works.
>
> This would have the advantage that DT describes gpio-to-irq dependencies.
> Moreover, nodes that reference gpios can do gpios = <&gpio 71 0>; instead of
> gpios = <&gpio3 7 0>;
Is that desired?
The device tree representation should match what is in the data sheet
normally. If they are in a single continuous number range, then we should
probably have a single device node with multiple register ranges
rather than one device node for each 32-bit register. Looking at
arch/arm/plat-orion/gpio.c I think that is not actually the case though
and having separate banks is more logical.
Something completely different I just noticed in the original patch:
> @@ -90,6 +74,27 @@ static void pmu_irq_handler(unsigned int irq, struct
> irq_desc *desc)
> }
> }
>
> +static int __initdata gpio0_irqs[4] = {
> + IRQ_DOVE_GPIO_0_7,
> + IRQ_DOVE_GPIO_8_15,
> + IRQ_DOVE_GPIO_16_23,
> + IRQ_DOVE_GPIO_24_31,
> +};
> +
> +static int __initdata gpio1_irqs[4] = {
> + IRQ_DOVE_HIGH_GPIO,
> + 0,
> + 0,
> + 0,
> +};
I think the latter one needs to be
+static int __initdata gpio1_irqs[4] = {
+ IRQ_DOVE_HIGH_GPIO,
+ IRQ_DOVE_HIGH_GPIO,
+ IRQ_DOVE_HIGH_GPIO,
+ IRQ_DOVE_HIGH_GPIO,
+};
so we register all four parts to the same primary IRQ. The
same is true for the devicetree representation.
Arnd
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH v2 01/12] ARM: Orion: DT support for IRQ and GPIO Controllers
On Thursday 05 July 2012, Andrew Lunn wrote:
> > I think the latter one needs to be
> >
> > +static int __initdata gpio1_irqs[4] = {
> > + IRQ_DOVE_HIGH_GPIO,
> > + IRQ_DOVE_HIGH_GPIO,
> > + IRQ_DOVE_HIGH_GPIO,
> > + IRQ_DOVE_HIGH_GPIO,
> > +};
> >
> > so we register all four parts to the same primary IRQ. The
> > same is true for the devicetree representation.
>
> Nope, does not work like that.
>
> It does not matter which IRQ of a GPIO chip fires. It looks at the IRQ
> cause bits for all lines and fires off the secondary ISR as needed for
> the whole chip. So in effect, there is a mapping IRQ->GPIO chip, not
> IRQ->1/4 of GPIO chip. With what you suggest above, you would end up
> with four chained interrupt handlers, all being handled by the same
> interrupt handler for one chio, and the last three in the chain would
> never do anything since the first one does all the work.
Does it really?
The handler function I'm looking at is
static void gpio_irq_handler(unsigned int irq, struct irq_desc *desc)
{
int irqoff;
BUG_ON(irq < IRQ_DOVE_GPIO_0_7 || irq > IRQ_DOVE_HIGH_GPIO);
irqoff = irq <= IRQ_DOVE_GPIO_16_23 ? irq - IRQ_DOVE_GPIO_0_7 :
3 + irq - IRQ_DOVE_GPIO_24_31;
orion_gpio_irq_handler(irqoff << 3);
if (irq == IRQ_DOVE_HIGH_GPIO) {
orion_gpio_irq_handler(40);
orion_gpio_irq_handler(48);
orion_gpio_irq_handler(56);
}
}
My reading of this is a manual hardwired implementation of a
primary handler that triggers the secondary handler four times
when it's called with a specific argument.
If you want to keep that behavior, this handler cannot be
generic across all mvebu socs, whereas registering four
chained handlers for the same primary interrupt would have
the same effect at a very small runtime overhead without the
need for any special case.
Arnd
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
spi/omap2: mark omap2_mcspi_master_setup as __devinit
This warning recently appeared with omap2plus_defconfig:
WARNING: drivers/spi/built-in.o(.devinit.text+0x3c4): Section mismatch in
reference from the function omap2_mcspi_probe() to the function
.init.text:omap2_mcspi_master_setup()
The function __devinit omap2_mcspi_probe() references
a function __init omap2_mcspi_master_setup().
If omap2_mcspi_master_setup is only used by omap2_mcspi_probe then
annotate omap2_mcspi_master_setup with a matching annotation.
The fix is obviously to mark the omap2_mcspi_master_setup function as
__devinit, rather than __init.
Signed-off-by: Arnd Bergmann
diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c
index 0c73dd4..dc02f2f 100644
--- a/drivers/spi/spi-omap2-mcspi.c
+++ b/drivers/spi/spi-omap2-mcspi.c
@@ -1032,7 +1032,7 @@ static int omap2_mcspi_transfer_one_message(struct
spi_master *master,
return 0;
}
-static int __init omap2_mcspi_master_setup(struct omap2_mcspi *mcspi)
+static int __devinit omap2_mcspi_master_setup(struct omap2_mcspi *mcspi)
{
struct spi_master *master = mcspi->master;
struct omap2_mcspi_regs *ctx = &mcspi->ctx;
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH v2 00/25] make *struct of_device_id.data const
On Monday 23 July 2012, Uwe Kleine-König wrote: > this is the 2nd version of this series whose goal is to make struct > of_device_id.data const. Conceptually a driver must not modify the data > contained there so making it const is the right thing. > > v1 of this series was sent with Message-id: > 1342182734-321-1-git-send-email-y. Changes since then are: > - powerpc fixes > - several new consts that were found by Arnd that are possible after >patch 19. > > Arnd suggested to take this series via arm-soc late for 3.6 in one go > because patch 19 depends on the former patches but is a precondition to > the latter and it fixes a few warnings. So getting it in via the > respective maintainer trees would need a much bigger coordination > effort. That means I prefer getting Acks over you taking the patch. > > Vinod Koul already took > dmaengine: at_hdmac: add a few const qualifiers > that is in next-20120723 as 7fd63ccdad72 now. Vinod, I don't follow your > pull requests, but assuming you didn't let it already pull for 3.6 I > suggest you drop it from your queue and I just take your Ack. > > This series was build tested for arm (all defconfigs) and powerpc (all > defconfigs and an allyesconfig) and grep didn't find more issues. As > before it introduces a warning in drivers/regulator/twl-regulator.c. > This driver does modify its .of_match_table when a device is bound which > doesn't fits the concept of independant devices. Arnd noticed another > new warning in drivers/scsi/qlogicpti.c that isn't that easy to resolve, > because the pointer to (now) const data is passed as first argument to > scsi_host_alloc. To fix that properly struct Scsi_Host.hostt needs to > get a const, too. Alternatively I could introduce a cast removing the > const, but I don't like that. > > This series is also available at: > > git://git.pengutronix.de/git/ukl/linux.git ofdeviceiddata > > and I will modify it there for the Acks I'm getting. Pulled the entire series into arm-soc/late/warnings. Thanks everyone who provided Acks. I'll wait for a few more days to let this sit in linux-next and if nobody complains, Olof or I will forward it to Linus. Arnd -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [RFC PATCH 10/13] spi: omap2-mcspi: dma_request_slave_channel() support for DT platforms
On Thursday 20 September 2012, Tony Lindgren wrote:
> > /* use PIO for small transfers, avoiding DMA setup/teardown overhead and
> > @@ -798,14 +801,26 @@ static int omap2_mcspi_request_dma(struct spi_device
> > *spi)
> > dma_cap_zero(mask);
> > dma_cap_set(DMA_SLAVE, mask);
> > sig = mcspi_dma->dma_rx_sync_dev;
> > - mcspi_dma->dma_rx = dma_request_channel(mask, omap_dma_filter_fn,
> > &sig);
> > + if (spi->dev.of_node)
> > + mcspi_dma->dma_rx =
> > + dma_request_slave_channel(&master->dev,
> > + mcspi_dma->dma_rx_ch_name);
> > + else
> > + mcspi_dma->dma_rx =
> > + dma_request_channel(mask, omap_dma_filter_fn, &sig);
> > if (!mcspi_dma->dma_rx) {
> > dev_err(&spi->dev, "no RX DMA engine channel for McSPI\n");
> > return -EAGAIN;
> > }
> >
>
> Hmm this does not look nice.. We should be able to somehow not to care about
> the configuration at the mcspi driver level.
I agree, but as far as I understand Vinod's plans, we would actually move
all drivers over to dma_request_slave_channel() when we have an interface
to register the lookup tables from platform code.
I think the above is ok for a transitional phase and we can remove the
fallback path when we have converted all platforms using this driver
to either use DT or move to the new style way of passing the channel
configuration.
Arnd
--
Got visibility?
Most devs has no idea what their production app looks like.
Find out how fast your code is with AppDynamics Lite.
http://ad.doubleclick.net/clk;262219671;13503038;y?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
[PATCH 15/16] spi/s3c64xx: use correct dma_transfer_direction type
There is a subtle difference between dma_transfer_direction and
dma_data_direction: the former is used by the dmaengine framework,
while the latter is used by the dma-mapping API. Although the
purpose is comparable, the actual values are different and must
not be mixed. In this case, the driver just wants to use
dma_transfer_direction.
Without this patch, building s3c6400_defconfig results in:
drivers/spi/spi-s3c64xx.c: In function 's3c64xx_spi_dmacb':
drivers/spi/spi-s3c64xx.c:239:21: warning: comparison between
'enum dma_data_direction' and 'enum dma_transfer_direction'
[-Wenum-compare]
Signed-off-by: Arnd Bergmann
Cc: Ben Dooks
Cc: Kukjin Kim
Cc: Grant Likely
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: spi-devel-general@lists.sourceforge.net
---
drivers/spi/spi-s3c64xx.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
index d1c8441f..2e44dd6 100644
--- a/drivers/spi/spi-s3c64xx.c
+++ b/drivers/spi/spi-s3c64xx.c
@@ -132,7 +132,7 @@
struct s3c64xx_spi_dma_data {
unsignedch;
- enum dma_data_direction direction;
+ enum dma_transfer_direction direction;
enum dma_ch dmach;
struct property *dma_prop;
};
--
1.7.10
--
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
[PATCH v2 v2 v2 8/8] spi/s3c64xx: use correct dma_transfer_direction type
There is a subtle difference between dma_transfer_direction and
dma_data_direction: the former is used by the dmaengine framework,
while the latter is used by the dma-mapping API. Although the
purpose is comparable, the actual values are different and must
not be mixed. In this case, the driver just wants to use
dma_transfer_direction.
Without this patch, building s3c6400_defconfig results in:
drivers/spi/spi-s3c64xx.c: In function 's3c64xx_spi_dmacb':
drivers/spi/spi-s3c64xx.c:239:21: warning: comparison between
'enum dma_data_direction' and 'enum dma_transfer_direction'
[-Wenum-compare]
Signed-off-by: Arnd Bergmann
Cc: Ben Dooks
Cc: Kukjin Kim
Cc: Grant Likely
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: spi-devel-general@lists.sourceforge.net
---
drivers/spi/spi-s3c64xx.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
index d1c8441f..2e44dd6 100644
--- a/drivers/spi/spi-s3c64xx.c
+++ b/drivers/spi/spi-s3c64xx.c
@@ -132,7 +132,7 @@
struct s3c64xx_spi_dma_data {
unsignedch;
- enum dma_data_direction direction;
+ enum dma_transfer_direction direction;
enum dma_ch dmach;
struct property *dma_prop;
};
--
1.7.10
--
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
[PATCH v2 0/8] ARM: mostly harmless gcc warnings
Most patches from the first time this was posted have been adopted by a subsystem maintainer or were show to be obsolete. Here are the remaining ones again. I'm planning to submit those patches that are still necessary by the time we have an -rc1 through the arm-soc tree, but my preference is still to have them go through the subsystem maintainers. Olof: should we add it to for-next? Arnd Arnd Bergmann (8): SCSI: ARM: ncr5380/oak uses no interrupts SCSI: ARM: make fas216_dumpinfo function conditional mm/slob: use min_t() to compare ARCH_SLAB_MINALIGN USB: EHCI: mark ehci_orion_conf_mbus_windows __devinit clk: don't mark clkdev_add_table as init pcmcia: sharpsl: don't discard sharpsl_pcmcia_ops video: mark nuc900fb_map_video_memory as __devinit spi/s3c64xx: use correct dma_transfer_direction type drivers/clk/clkdev.c|2 +- drivers/pcmcia/pxa2xx_sharpsl.c |2 +- drivers/scsi/arm/fas216.c |2 +- drivers/scsi/arm/oak.c |1 + drivers/spi/spi-s3c64xx.c |2 +- drivers/usb/host/ehci-orion.c |2 +- drivers/video/nuc900fb.c|2 +- mm/slob.c |6 +++--- 8 files changed, 10 insertions(+), 9 deletions(-) -- 1.7.10 Cc: "James E.J. Bottomley" Cc: Ben Dooks Cc: Dominik Brodowski Cc: Florian Tobias Schandinat Cc: Grant Likely Cc: Greg Kroah-Hartman Cc: Jochen Friedrich Cc: Kukjin Kim Cc: Mike Turquette Cc: Pavel Machek Cc: Pekka Enberg Cc: Russell King Cc: Wan ZongShun Cc: linux-arm-ker...@lists.infradead.org Cc: linux-fb...@vger.kernel.org Cc: linux-pcm...@lists.infradead.org Cc: linux-samsung-...@vger.kernel.org Cc: linux-s...@vger.kernel.org Cc: linux-...@vger.kernel.org Cc: spi-devel-general@lists.sourceforge.net Cc: sta...@vger.kernel.org -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH v2 v2 v2 8/8] spi/s3c64xx: use correct dma_transfer_direction type
On Wednesday 17 October 2012, Kukjin Kim wrote:
> BTW, don't we need following accordingly?
>
> diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
> index 1a81c90..a0bb55e 100644
> --- a/drivers/spi/spi-s3c64xx.c
> +++ b/drivers/spi/spi-s3c64xx.c
> @@ -1067,11 +1067,11 @@ static int __devinit s3c64xx_spi_get_dmares(
>
> if (tx) {
> dma_data = &sdd->tx_dma;
> - dma_data->direction = DMA_TO_DEVICE;
> + dma_data->direction = DMA_MEM_TO_DEV;
> chan_str = "tx";
> } else {
> dma_data = &sdd->rx_dma;
> - dma_data->direction = DMA_FROM_DEVICE;
> + dma_data->direction = DMA_DEV_TO_MEM;
> chan_str = "rx";
> }
>
Yes, you are absolutely right, sorry for not seeing that earlier.
New version below.
Arnd
>From c10356b9846b13651a8a24c3a31e029ffe6eafd9 Mon Sep 17 00:00:00 2001
From: Arnd Bergmann
Date: Mon, 30 Apr 2012 16:31:27 +
Subject: [PATCH] spi/s3c64xx: use correct dma_transfer_direction type
There is a subtle difference between dma_transfer_direction and
dma_data_direction: the former is used by the dmaengine framework,
while the latter is used by the dma-mapping API. Although the
purpose is comparable, the actual values are different and must
not be mixed. In this case, the driver just wants to use
dma_transfer_direction.
Without this patch, building s3c6400_defconfig results in:
drivers/spi/spi-s3c64xx.c: In function 's3c64xx_spi_dmacb':
drivers/spi/spi-s3c64xx.c:239:21: warning: comparison between
'enum dma_data_direction' and 'enum dma_transfer_direction'
[-Wenum-compare]
As pointed out by Kukjin Kim, this also changes the use of constants
from DMA_FROM_DEVICE/DMA_TO_DEVICE to DMA_DEV_TO_MEM/DMA_MEM_TO_DEV.
Signed-off-by: Arnd Bergmann
Acked-by: Kukjin Kim
Cc: Ben Dooks
Cc: Grant Likely
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: spi-devel-general@lists.sourceforge.net
diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
index d1c8441f..cd43b4b 100644
--- a/drivers/spi/spi-s3c64xx.c
+++ b/drivers/spi/spi-s3c64xx.c
@@ -132,7 +132,7 @@
struct s3c64xx_spi_dma_data {
unsignedch;
- enum dma_data_direction direction;
+ enum dma_transfer_direction direction;
enum dma_ch dmach;
struct property *dma_prop;
};
@@ -1065,11 +1065,11 @@ static int __devinit s3c64xx_spi_get_dmares(
if (tx) {
dma_data = &sdd->tx_dma;
- dma_data->direction = DMA_TO_DEVICE;
+ dma_data->direction = DMA_MEM_TO_DEV;
chan_str = "tx";
} else {
dma_data = &sdd->rx_dma;
- dma_data->direction = DMA_FROM_DEVICE;
+ dma_data->direction = DMA_DEV_TO_MEM;
chan_str = "rx";
}
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH RESEND] ARM/SPI: New driver for SPI master controller for CLPS711X-target
On Wednesday 07 November 2012, Alexander Shiyan wrote: > This patch add new driver for CLPS711X SPI master controller. > Due to platform limitations driver supports only 8 bit transfer mode. > Chip select control is handled via GPIO. > > Signed-off-by: Alexander Shiyan Acked-by: Arnd Bergmann -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH v4 00/14] DMA Engine support for AM33XX
On Friday 11 January 2013, Matt Porter wrote: > The approach taken is similar to how OMAP DMA is being converted to > DMA Engine support. With the functional EDMA private API already > existing in mach-davinci/dma.c, we first move that to an ARM common > area so it can be shared. Adding DT and runtime PM support to the > private EDMA API implementation allows it to run on AM33xx. AM33xx > only boots using DT so we leverage Jon's generic DT DMA helpers to > register EDMA DMAC with the of_dma framework and then add support > for calling the dma_request_slave_channel() API to both the mmc > and spi drivers. I think this looks very good. What I wonder is whether we should make the non-DT parts of the dmaengine driver compile-time conditional on CONFIG_ATAGS though, so the slave drivers don't have a link-time dependency on the dmaengine driver's omap_dma_filter_fn symbol when building without ATAGS support. Arnd -- Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and much more. Get web development skills now with LearnDevNow - 350+ hours of step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122812 ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH v4 00/14] DMA Engine support for AM33XX
On Friday 11 January 2013, Matt Porter wrote: > We have tightly coupled the link-time dependency for > omap_dma_filter_fn by going down the path of using > dma_request_slave_channel_compat() as Tony suggested to avoid extra > ifdefry. > > That dependency will go away naturally if all the "legacy" OMAP platforms > were required to only boot from DT...just as a newly added SoCs are. > > Are you suggesting unwinding the _compat() approach? No, I was thinking we could define omap_dma_filter_fn to NULL for the DT-only case. Arnd -- Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and much more. Get web development skills now with LearnDevNow - 350+ hours of step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122812 ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH v5 07/14] dmaengine: add dma_request_slave_channel_compat()
On Tuesday 15 January 2013, Matt Porter wrote:
> Adds a dma_request_slave_channel_compat() wrapper which accepts
> both the arguments from dma_request_channel() and
> dma_request_slave_channel(). Based on whether the driver is
> instantiated via DT, the appropriate channel request call will be
> made.
>
> This allows for a much cleaner migration of drivers to the
> dmaengine DT API as platforms continue to be mixed between those
> that boot using DT and those that do not.
I noticed today some drivers in linux-next that rely on this patch,
but the patch itself still missing from -next.
> --- a/include/linux/dmaengine.h
> +++ b/include/linux/dmaengine.h
> @@ -1047,6 +1047,16 @@ void dma_run_dependencies(struct
> dma_async_tx_descriptor *tx);
> struct dma_chan *dma_find_channel(enum dma_transaction_type tx_type);
> struct dma_chan *net_dma_find_channel(void);
> #define dma_request_channel(mask, x, y) __dma_request_channel(&(mask), x, y)
> +static inline struct dma_chan
> +*dma_request_slave_channel_compat(dma_cap_mask_t mask, dma_filter_fn fn,
> + void *fn_param, struct device *dev,
> + char *name)
> +{
> + if (dev->of_node)
> + return dma_request_slave_channel(dev, name);
> + else
> + return dma_request_channel(mask, fn, fn_param);
> +}
Hmm, dma_request_channel is actually a macro that passes mask by reference,
presumably because it can get modified by the filter function. Also, there
may be cases where we do have an of_node but don't use the dma binding
yet, or where dma_request_slave_channel doesn't actually use DT information
but rather one of the other methods that Vinod was talking about adding.
I think what it should look like instead is the below.
Arnd
diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
index bfcdecb..b6ffd7d 100644
--- a/include/linux/dmaengine.h
+++ b/include/linux/dmaengine.h
@@ -993,6 +993,19 @@ static inline void dma_release_channel(struct dma_chan
*chan)
}
#endif
+static inline struct dma_chan
*__dma_request_slave_channel_compat(dma_cap_mask_t *mask,
+ dma_filter_fn fn, void *fn_param, struct device
*dev,
+char *name)
+{
+ struct dma_chan *chan;
+
+ chan = dma_request_slave_channel(dev, name);
+ if (chan)
+ return chan;
+
+ return __dma_request_channel(mask, fn, fn_param);
+}
+
/* --- DMA device --- */
int dma_async_device_register(struct dma_device *device);
@@ -1001,6 +1014,8 @@ void dma_run_dependencies(struct dma_async_tx_descriptor
*tx);
struct dma_chan *dma_find_channel(enum dma_transaction_type tx_type);
struct dma_chan *net_dma_find_channel(void);
#define dma_request_channel(mask, x, y) __dma_request_channel(&(mask), x, y)
+#define dma_request_slave_channel_compat(mask, x, y, dev, name) \
+__dma_request_slave_channel_compat(&(mask), x, y, dev, name)
/* --- Helper iov-locking functions --- */
--
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnnow-d2d
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
[PATCH 14/19] spi/atmel: remove incorrect __exit_p()
Since we no longer allow building without hotplug, the
atmel_spi_remove function is always present and we should
not use __exit_p() to refer to it.
Without this patch, building at91_dt_defconfig results in:
drivers/spi/spi-atmel.c:1006:12: warning: 'atmel_spi_remove' defined but not
used [-Wunused-function]
Signed-off-by: Arnd Bergmann
Cc: Nicolas Ferre
Cc: Grant Likely
Cc: spi-devel-general@lists.sourceforge.net
---
drivers/spi/spi-atmel.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/spi/spi-atmel.c b/drivers/spi/spi-atmel.c
index ab34497..656d137 100644
--- a/drivers/spi/spi-atmel.c
+++ b/drivers/spi/spi-atmel.c
@@ -1088,7 +1088,7 @@ static struct platform_driver atmel_spi_driver = {
.suspend= atmel_spi_suspend,
.resume = atmel_spi_resume,
.probe = atmel_spi_probe,
- .remove = __exit_p(atmel_spi_remove),
+ .remove = atmel_spi_remove,
};
module_platform_driver(atmel_spi_driver);
--
1.8.0
--
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnnow-d2d
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
[PATCH 14/19] spi/atmel: remove incorrect __exit_p()
Since we no longer allow building without hotplug, the
atmel_spi_remove function is always present and we should
not use __exit_p() to refer to it.
Without this patch, building at91_dt_defconfig results in:
drivers/spi/spi-atmel.c:1006:12: warning: 'atmel_spi_remove' defined but not
used [-Wunused-function]
Signed-off-by: Arnd Bergmann
Cc: Nicolas Ferre
Cc: Grant Likely
Cc: spi-devel-general@lists.sourceforge.net
---
drivers/spi/spi-atmel.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/spi/spi-atmel.c b/drivers/spi/spi-atmel.c
index ab34497..656d137 100644
--- a/drivers/spi/spi-atmel.c
+++ b/drivers/spi/spi-atmel.c
@@ -1088,7 +1088,7 @@ static struct platform_driver atmel_spi_driver = {
.suspend= atmel_spi_suspend,
.resume = atmel_spi_resume,
.probe = atmel_spi_probe,
- .remove = __exit_p(atmel_spi_remove),
+ .remove = atmel_spi_remove,
};
module_platform_driver(atmel_spi_driver);
--
1.8.0
--
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnnow-d2d
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
[PATCH 3/5] serial: pl011: use generic DMA slave configuration if possible
With the new OF DMA binding, it is possible to completely avoid the
need for platform_data for configuring a DMA channel. In cases where the
platform has already been converted, calling dma_request_slave_channel
should get all the necessary information from the device tree.
Like the patch that converts the dw_dma controller, this is completely
untested and is looking for someone to try it out.
Signed-off-by: Arnd Bergmann
Cc: Grant Likely
Cc: Jiri Slaby
Cc: Greg Kroah-Hartman
Cc: Linus Walleij
Cc: spi-devel-general@lists.sourceforge.net
Cc: Viresh Kumar
Cc: Andy Shevchenko
Cc: Vinod Koul
Cc: devicetree-disc...@lists.ozlabs.org
Cc: linux-arm-ker...@vger.kernel.org
---
drivers/tty/serial/amba-pl011.c | 62 -
1 file changed, 37 insertions(+), 25 deletions(-)
diff --git a/drivers/tty/serial/amba-pl011.c b/drivers/tty/serial/amba-pl011.c
index 3ea5408..c25b00e 100644
--- a/drivers/tty/serial/amba-pl011.c
+++ b/drivers/tty/serial/amba-pl011.c
@@ -245,7 +245,7 @@ static void pl011_sgbuf_free(struct dma_chan *chan, struct
pl011_sgbuf *sg,
}
}
-static void pl011_dma_probe_initcall(struct uart_amba_port *uap)
+static void pl011_dma_probe_initcall(struct device *dev, struct uart_amba_port
*uap)
{
/* DMA is the sole user of the platform data right now */
struct amba_pl011_data *plat = uap->port.dev->platform_data;
@@ -259,20 +259,25 @@ static void pl011_dma_probe_initcall(struct
uart_amba_port *uap)
struct dma_chan *chan;
dma_cap_mask_t mask;
- /* We need platform data */
- if (!plat || !plat->dma_filter) {
- dev_info(uap->port.dev, "no DMA platform data\n");
- return;
- }
+ chan = dma_request_slave_channel(dev, "tx");
- /* Try to acquire a generic DMA engine slave TX channel */
- dma_cap_zero(mask);
- dma_cap_set(DMA_SLAVE, mask);
-
- chan = dma_request_channel(mask, plat->dma_filter, plat->dma_tx_param);
if (!chan) {
- dev_err(uap->port.dev, "no TX DMA channel!\n");
- return;
+ /* We need platform data */
+ if (!plat || !plat->dma_filter) {
+ dev_info(uap->port.dev, "no DMA platform data\n");
+ return;
+ }
+
+ /* Try to acquire a generic DMA engine slave TX channel */
+ dma_cap_zero(mask);
+ dma_cap_set(DMA_SLAVE, mask);
+
+ chan = dma_request_channel(mask, plat->dma_filter,
+ plat->dma_tx_param);
+ if (!chan) {
+ dev_err(uap->port.dev, "no TX DMA channel!\n");
+ return;
+ }
}
dmaengine_slave_config(chan, &tx_conf);
@@ -282,7 +287,18 @@ static void pl011_dma_probe_initcall(struct uart_amba_port
*uap)
dma_chan_name(uap->dmatx.chan));
/* Optionally make use of an RX channel as well */
- if (plat->dma_rx_param) {
+ chan = dma_request_slave_channel(dev, "rx");
+
+ if (!chan && plat->dma_rx_param) {
+ chan = dma_request_channel(mask, plat->dma_filter,
plat->dma_rx_param);
+
+ if (!chan) {
+ dev_err(uap->port.dev, "no RX DMA channel!\n");
+ return;
+ }
+ }
+
+ if (chan) {
struct dma_slave_config rx_conf = {
.src_addr = uap->port.mapbase + UART01x_DR,
.src_addr_width = DMA_SLAVE_BUSWIDTH_1_BYTE,
@@ -291,12 +307,6 @@ static void pl011_dma_probe_initcall(struct uart_amba_port
*uap)
.device_fc = false,
};
- chan = dma_request_channel(mask, plat->dma_filter,
plat->dma_rx_param);
- if (!chan) {
- dev_err(uap->port.dev, "no RX DMA channel!\n");
- return;
- }
-
dmaengine_slave_config(chan, &rx_conf);
uap->dmarx.chan = chan;
@@ -315,6 +325,7 @@ static void pl011_dma_probe_initcall(struct uart_amba_port
*uap)
struct dma_uap {
struct list_head node;
struct uart_amba_port *uap;
+ struct device *dev;
};
static LIST_HEAD(pl011_dma_uarts);
@@ -325,7 +336,7 @@ static int __init pl011_dma_initcall(void)
list_for_each_safe(node, tmp, &pl011_dma_uarts) {
struct dma_uap *dmau = list_entry(node, struct dma_uap, node);
- pl011_dma_probe_initcall(dmau->uap);
+ pl011_dma_probe_initcall(dmau->dev, dmau->uap);
list_del(node);
kfree(dmau);
}
@@ -334,18 +345,19 @@ static int __init pl011_dma_initca
[PATCH 2/5] spi: pl022: use generic DMA slave configuration if possible
With the new OF DMA binding, it is possible to completely avoid the
need for platform_data for configuring a DMA channel. In cases where the
platform has already been converted, calling dma_request_slave_channel
should get all the necessary information from the device tree.
Like the patch that converts the dw_dma controller, this is completely
untested and is looking for someone to try it out.
Signed-off-by: Arnd Bergmann
Cc: Grant Likely
Cc: Mark Brown
Cc: spi-devel-general@lists.sourceforge.net
Cc: Viresh Kumar
Cc: Andy Shevchenko
Cc: Vinod Koul
Cc: devicetree-disc...@lists.ozlabs.org
Cc: linux-arm-ker...@vger.kernel.org
---
drivers/spi/spi-pl022.c | 43 +--
1 file changed, 41 insertions(+), 2 deletions(-)
diff --git a/drivers/spi/spi-pl022.c b/drivers/spi/spi-pl022.c
index b0fe393..371cc66f 100644
--- a/drivers/spi/spi-pl022.c
+++ b/drivers/spi/spi-pl022.c
@@ -1139,6 +1139,35 @@ err_no_rxchan:
return -ENODEV;
}
+static int pl022_dma_autoprobe(struct pl022 *pl022)
+{
+ struct device *dev = &pl022->adev->dev;
+
+ /* automatically configure DMA channels from platform, normally using
DT */
+ pl022->dma_rx_channel = dma_request_slave_channel(dev, "rx");
+ if (!pl022->dma_rx_channel)
+ goto err_no_rxchan;
+
+ pl022->dma_tx_channel = dma_request_slave_channel(dev, "tx");
+ if (!pl022->dma_tx_channel)
+ goto err_no_txchan;
+
+ pl022->dummypage = kmalloc(PAGE_SIZE, GFP_KERNEL);
+ if (!pl022->dummypage)
+ goto err_no_dummypage;
+
+ return 0;
+
+err_no_dummypage:
+ dma_release_channel(pl022->dma_tx_channel);
+ pl022->dma_tx_channel = NULL;
+err_no_txchan:
+ dma_release_channel(pl022->dma_rx_channel);
+ pl022->dma_rx_channel = NULL;
+err_no_rxchan:
+ return -ENODEV;
+}
+
static void terminate_dma(struct pl022 *pl022)
{
struct dma_chan *rxchan = pl022->dma_rx_channel;
@@ -1167,6 +1196,11 @@ static inline int configure_dma(struct pl022 *pl022)
return -ENODEV;
}
+static inline int pl022_dma_autoprobe(struct pl022 *pl022)
+{
+ return 0;
+}
+
static inline int pl022_dma_probe(struct pl022 *pl022)
{
return 0;
@@ -2226,8 +2260,13 @@ static int pl022_probe(struct amba_device *adev, const
struct amba_id *id)
goto err_no_irq;
}
- /* Get DMA channels */
- if (platform_info->enable_dma) {
+ /* Get DMA channels, try autoconfiguration first */
+ status = pl022_dma_autoprobe(pl022);
+
+ /* If that failed, use channels from platform_info */
+ if (status == 0)
+ platform_info->enable_dma = 1;
+ else if (platform_info->enable_dma) {
status = pl022_dma_probe(pl022);
if (status != 0)
platform_info->enable_dma = 0;
--
1.8.0
--
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnnow-d2d
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH v5 07/14] dmaengine: add dma_request_slave_channel_compat()
On Monday 28 January 2013, Andy Shevchenko wrote: > On Tue, Jan 15, 2013 at 10:32 PM, Matt Porter wrote: > > Adds a dma_request_slave_channel_compat() wrapper which accepts > > both the arguments from dma_request_channel() and > > dma_request_slave_channel(). Based on whether the driver is > > instantiated via DT, the appropriate channel request call will be > > made. > > > > This allows for a much cleaner migration of drivers to the > > dmaengine DT API as platforms continue to be mixed between those > > that boot using DT and those that do not. > > Does it mean the introduced function is kinda temporary? Some drivers can very likely get converted to use only dma_request_slave_channel() in the long run, when all the platforms using those drivers have been converted to provide the channels using device tree. However, for drivers that are used on legacy platforms without DT support, we may still need something like this function in the long run. Arnd -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnnow-d2d ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
[PATCH v2 0/5] dmaengine: convert dw_dmac/spear13xx to generic binding
Hi everyone,
I'm rather embarrassed to have sent yet another patch series
to the wrong mailing list address, this now goes to the
correct linux-arm-kernel list, so please comment here,
not on the first version. I have also made some smaller
changes and updated the DT bindings where I extended
the drivers. I also uploaded the git branch to the
spear/dma branch of
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git
This is my attempt to convert the spear platform and the dw_dmac to
the generic device tree binding for DMA, so that we don't get
a release with the broken version. I'm pretty sure that this
has bugs, but it's as good as I could do without access to
hardware or specs.
Please review and comment,
Arnd
Arnd Bergmann (5):
dmaengine: dw_dmac: move to generic DMA binding
spi: pl022: use generic DMA slave configuration if possible
serial: pl011: use generic DMA slave configuration if possible
ata: arasan: remove the need for platform_data
ARM: SPEAr13xx: Pass generic DW DMAC platform data from DT
.../devicetree/bindings/ata/pata-arasan.txt| 22
Documentation/devicetree/bindings/dma/snps-dma.txt | 70 +--
arch/arm/boot/dts/spear1340.dtsi | 2 +
arch/arm/boot/dts/spear13xx.dtsi | 25 +++-
arch/arm/mach-spear/generic.h | 6 -
arch/arm/mach-spear/include/mach/spear.h | 2 -
arch/arm/mach-spear/spear1310.c| 30 +
arch/arm/mach-spear/spear1340.c| 32 +
arch/arm/mach-spear/spear13xx-dma.h| 128
arch/arm/mach-spear/spear13xx.c| 58 -
drivers/ata/pata_arasan_cf.c | 31 +++--
drivers/dma/dw_dmac.c | 130 ++---
drivers/dma/dw_dmac_regs.h | 4 -
drivers/spi/spi-pl022.c| 43 ++-
drivers/tty/serial/amba-pl011.c| 62 ++
include/linux/dw_dmac.h| 5 -
include/linux/pata_arasan_cf_data.h| 2 -
17 files changed, 243 insertions(+), 409 deletions(-)
delete mode 100644 arch/arm/mach-spear/spear13xx-dma.h
--
1.8.0
Cc: Andy Shevchenko
Cc: Grant Likely
Cc: Greg Kroah-Hartman
Cc: Jeff Garzik
Cc: Jon Hunter
Cc: Jiri Slaby
Cc: Linus Walleij
Cc: Mark Brown
Cc: Vinod Koul
Cc: Viresh Kumar
Cc: devicetree-disc...@lists.ozlabs.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: spi-devel-general@lists.sourceforge.net
--
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnnow-d2d
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
[PATCH 2/5] spi: pl022: use generic DMA slave configuration if possible
With the new OF DMA binding, it is possible to completely avoid the
need for platform_data for configuring a DMA channel. In cases where the
platform has already been converted, calling dma_request_slave_channel
should get all the necessary information from the device tree.
Like the patch that converts the dw_dma controller, this is completely
untested and is looking for someone to try it out.
Signed-off-by: Arnd Bergmann
Cc: Grant Likely
Cc: Mark Brown
Cc: spi-devel-general@lists.sourceforge.net
Cc: Viresh Kumar
Cc: Andy Shevchenko
Cc: Vinod Koul
Cc: devicetree-disc...@lists.ozlabs.org
Cc: linux-arm-ker...@lists.infradead.org
---
.../devicetree/bindings/spi/spi_pl022.txt | 36 ++
drivers/spi/spi-pl022.c| 43 +-
2 files changed, 77 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/spi/spi_pl022.txt
b/Documentation/devicetree/bindings/spi/spi_pl022.txt
index f158fd3..22ed679 100644
--- a/Documentation/devicetree/bindings/spi/spi_pl022.txt
+++ b/Documentation/devicetree/bindings/spi/spi_pl022.txt
@@ -16,6 +16,11 @@ Optional properties:
device will be suspended immediately
- pl022,rt : indicates the controller should run the message pump with realtime
priority to minimise the transfer latency on the bus (boolean)
+- dmas : Two or more DMA channel specifiers following the convention outlined
+ in bindings/dma/dma.txt
+- dma-names: Names for the dma channels, if present. There must be at
+least one channel named "tx" for transmit and named "rx" for
+ receive.
SPI slave nodes must be children of the SPI master node and can
@@ -32,3 +37,34 @@ contain the following properties.
- pl022,wait-state : Microwire interface: Wait state
- pl022,duplex : Microwire interface: Full/Half duplex
+
+Example:
+
+ spi@e010 {
+ compatible = "arm,pl022", "arm,primecell";
+ reg = <0xe010 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interrupts = <0 31 0x4>;
+ dmas = <&dma-controller 23 1>,
+ <&dma-controller 24 0>;
+ dma-names = "rx", "tx";
+
+ m25p80@1 {
+ compatible = "st,m25p80";
+ reg = <1>;
+ spi-max-frequency = <1200>;
+ spi-cpol;
+ spi-cpha;
+ pl022,hierarchy = <0>;
+ pl022,interface = <0>;
+ pl022,slave-tx-disable;
+ pl022,com-mode = <0x2>;
+ pl022,rx-level-trig = <0>;
+ pl022,tx-level-trig = <0>;
+ pl022,ctrl-len = <0x11>;
+ pl022,wait-state = <0>;
+ pl022,duplex = <0>;
+ };
+ };
+
diff --git a/drivers/spi/spi-pl022.c b/drivers/spi/spi-pl022.c
index b0fe393..371cc66f 100644
--- a/drivers/spi/spi-pl022.c
+++ b/drivers/spi/spi-pl022.c
@@ -1139,6 +1139,35 @@ err_no_rxchan:
return -ENODEV;
}
+static int pl022_dma_autoprobe(struct pl022 *pl022)
+{
+ struct device *dev = &pl022->adev->dev;
+
+ /* automatically configure DMA channels from platform, normally using
DT */
+ pl022->dma_rx_channel = dma_request_slave_channel(dev, "rx");
+ if (!pl022->dma_rx_channel)
+ goto err_no_rxchan;
+
+ pl022->dma_tx_channel = dma_request_slave_channel(dev, "tx");
+ if (!pl022->dma_tx_channel)
+ goto err_no_txchan;
+
+ pl022->dummypage = kmalloc(PAGE_SIZE, GFP_KERNEL);
+ if (!pl022->dummypage)
+ goto err_no_dummypage;
+
+ return 0;
+
+err_no_dummypage:
+ dma_release_channel(pl022->dma_tx_channel);
+ pl022->dma_tx_channel = NULL;
+err_no_txchan:
+ dma_release_channel(pl022->dma_rx_channel);
+ pl022->dma_rx_channel = NULL;
+err_no_rxchan:
+ return -ENODEV;
+}
+
static void terminate_dma(struct pl022 *pl022)
{
struct dma_chan *rxchan = pl022->dma_rx_channel;
@@ -1167,6 +1196,11 @@ static inline int configure_dma(struct pl022 *pl022)
return -ENODEV;
}
+static inline int pl022_dma_autoprobe(struct pl022 *pl022)
+{
+ return 0;
+}
+
static inline int pl022_dma_probe(struct pl022 *pl022)
{
return 0;
@@ -2226,8 +2260,13 @@ static int pl022_probe(struct amba_device *adev, const
struct amba_id *id)
goto err_no_irq;
}
- /* Get DMA channels */
- if (platform_info->enable_dma) {
+ /* Get DMA channels, tr
[PATCH 3/5] serial: pl011: use generic DMA slave configuration if possible
With the new OF DMA binding, it is possible to completely avoid the
need for platform_data for configuring a DMA channel. In cases where the
platform has already been converted, calling dma_request_slave_channel
should get all the necessary information from the device tree.
This also adds a binding document specific to the pl011 controller,
and extends the generic primecell binding to mention "dmas" and other
common properties.
Like the patch that converts the dw_dma controller, this is completely
untested and is looking for someone to try it out.
Signed-off-by: Arnd Bergmann
Cc: Grant Likely
Cc: Jiri Slaby
Cc: Greg Kroah-Hartman
Cc: Linus Walleij
Cc: spi-devel-general@lists.sourceforge.net
Cc: Viresh Kumar
Cc: Andy Shevchenko
Cc: Vinod Koul
Cc: devicetree-disc...@lists.ozlabs.org
Cc: linux-arm-ker...@lists.infradead.org
---
.../devicetree/bindings/arm/primecell.txt | 19 ++-
Documentation/devicetree/bindings/serial/pl011.txt | 17 ++
drivers/tty/serial/amba-pl011.c| 62 +-
3 files changed, 72 insertions(+), 26 deletions(-)
create mode 100644 Documentation/devicetree/bindings/serial/pl011.txt
diff --git a/Documentation/devicetree/bindings/arm/primecell.txt
b/Documentation/devicetree/bindings/arm/primecell.txt
index 64fc82b..0df6aca 100644
--- a/Documentation/devicetree/bindings/arm/primecell.txt
+++ b/Documentation/devicetree/bindings/arm/primecell.txt
@@ -16,14 +16,31 @@ Optional properties:
- clocks : From common clock binding. First clock is phandle to clock for apb
pclk. Additional clocks are optional and specific to those peripherals.
- clock-names : From common clock binding. Shall be "apb_pclk" for first clock.
+- dmas : From common DMA binding. If present, refers to one or more dma
channels.
+- dma-names : From common DMA binding, needs to match the 'dmas' property.
+ Devices with exactly one receive and transmit channel shall name
+ these "rx" and "tx", respectively.
+- pinctrl- : Pinctrl states as described in
bindings/pinctrl/pinctrl-bindings.txt
+- pinctrl-names : Names corresponding to the numbered pinctrl states
+- interrupts : one or more interrupt specifiers
+- interrupt-names : names corresponding to the interrupts properties
Example:
serial@fff36000 {
compatible = "arm,pl011", "arm,primecell";
arm,primecell-periphid = <0x00341011>;
+
clocks = <&pclk>;
clock-names = "apb_pclk";
-
+
+ dmas = <&dma-controller 4>, <&dma-controller 5>;
+ dma-names = "rx", "tx";
+
+ pinctrl-0 = <&uart0_default_mux>, <&uart0_default_mode>;
+ pinctrl-1 = <&uart0_sleep_mode>;
+ pinctrl-names = "default","sleep";
+
+ interrupts = <0 11 0x4>;
};
diff --git a/Documentation/devicetree/bindings/serial/pl011.txt
b/Documentation/devicetree/bindings/serial/pl011.txt
new file mode 100644
index 000..5d2e840
--- /dev/null
+++ b/Documentation/devicetree/bindings/serial/pl011.txt
@@ -0,0 +1,17 @@
+* ARM AMBA Primecell PL011 serial UART
+
+Required properties:
+- compatible: must be "arm,primecell", "arm,pl011"
+- reg: exactly one register range with length 0x1000
+- interrupts: exactly one interrupt specifier
+
+Optional properties:
+- pinctrl: When present, must have one state named "sleep"
+ and one state named "default"
+- clocks: When present, must refer to exactly one clock named
+ "apb_pclk"
+- dmas: When present, may have one or two dma channels.
+ The first one must be named "rx", the second one
+ must be named "tx".
+
+See also bindings/arm/primecell.txt
diff --git a/drivers/tty/serial/amba-pl011.c b/drivers/tty/serial/amba-pl011.c
index 7fca402..f9af04d 100644
--- a/drivers/tty/serial/amba-pl011.c
+++ b/drivers/tty/serial/amba-pl011.c
@@ -245,7 +245,7 @@ static void pl011_sgbuf_free(struct dma_chan *chan, struct
pl011_sgbuf *sg,
}
}
-static void pl011_dma_probe_initcall(struct uart_amba_port *uap)
+static void pl011_dma_probe_initcall(struct device *dev, struct uart_amba_port
*uap)
{
/* DMA is the sole user of the platform data right now */
struct amba_pl011_data *plat = uap->port.dev->platform_data;
@@ -259,20 +259,25 @@ static void pl011_dma_probe_initcall(struct
uart_amba_port *uap)
struct dma_chan *chan;
dma_cap_mask_t mask;
- /* We need platform data */
- if (!plat || !plat->dma_filter) {
- dev_info(uap->port.dev, "no DMA platform data\n");
- return;
- }
+ chan = dma_request_slave_channel(dev, "tx");
- /* Try to acquire a generic DMA engine slave TX channel */
-
Re: [PATCH 2/5] spi: pl022: use generic DMA slave configuration if possible
On Tuesday 29 January 2013, Andy Shevchenko wrote:
> > +static int pl022_dma_autoprobe(struct pl022 *pl022)
> > +{
> > + struct device *dev = &pl022->adev->dev;
> > +
> > + /* automatically configure DMA channels from platform, normally using
> > DT */
> > + pl022->dma_rx_channel = dma_request_slave_channel(dev, "rx");
> > + if (!pl022->dma_rx_channel)
> > + goto err_no_rxchan;
> > +
> > + pl022->dma_tx_channel = dma_request_slave_channel(dev, "tx");
> > + if (!pl022->dma_tx_channel)
> > + goto err_no_txchan;
> > +
> > + pl022->dummypage = kmalloc(PAGE_SIZE, GFP_KERNEL);
>
> Where this memory will be freed?
> In dependence of the answer could you consider to use
> devm_kmalloc or __get_free_page?
There is another function like this called pl022_dma_probe()
that has the same allocation, and it gets freed in the same place.
It's probably worth changing this into something different, but
I felt that it didn't belong into this patch. I was also not
sure if the best option would be dmam_alloc_coherent, dev_kzalloc,
or __get_free_page.
Arnd
--
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnnow-d2d
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH v6 09/10] spi: omap2-mcspi: add generic DMA request support to the DT binding
On Wednesday 30 January 2013, Matt Porter wrote: > +Optional properties: > +- dmas: List of DMA controller phandle and DMA request ordered > + pairs. One tx and one rx pair is required for each chip > + select. The binding looks ok, but the wording is slightly incorrect here: strictly speaking, it's not a pair of controller phandle and request line number, but a DMA descriptor as specified in bindings/dma/dma.txt with a format specific to the dma engine being used. That can require more than just a single integer request number. Arnd -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH v6 07/10] dmaengine: add dma_request_slave_channel_compat()
On Wednesday 30 January 2013, Matt Porter wrote:
> Adds a dma_request_slave_channel_compat() wrapper which accepts
> both the arguments from dma_request_channel() and
> dma_request_slave_channel(). Based on whether the driver is
> instantiated via DT, the appropriate channel request call will be
> made.
>
> This allows for a much cleaner migration of drivers to the
> dmaengine DT API as platforms continue to be mixed between those
> that boot using DT and those that do not.
>
> Suggested-by: Tony Lindgren
> Signed-off-by: Matt Porter
> Acked-by: Tony Lindgren
Acked-by: Arnd Bergmann
> @@ -1001,6 +1001,22 @@ void dma_run_dependencies(struct
> dma_async_tx_descriptor *tx);
> struct dma_chan *dma_find_channel(enum dma_transaction_type tx_type);
> struct dma_chan *net_dma_find_channel(void);
> #define dma_request_channel(mask, x, y) __dma_request_channel(&(mask), x, y)
> +#define dma_request_slave_channel_compat(mask, x, y, dev, name) \
> + __dma_request_slave_channel_compat(&(mask), x, y, dev, name)
> +
> +static inline struct dma_chan
> +*__dma_request_slave_channel_compat(dma_cap_mask_t *mask, dma_filter_fn fn,
> + void *fn_param, struct device *dev,
> + char *name)
> +{
> + struct dma_chan *chan;
> +
> + chan = dma_request_slave_channel(dev, name);
> + if (chan)
> + return chan;
> +
> + return __dma_request_channel(mask, fn, fn_param);
> +}
After I have spent some more time with implementing the code for dw_dma,
I think the mask is actually unnecessary here, the helper could just
always set it to DMA_SLAVE before calling __dma_request_channel.
It's not a bug to do it this way though, and it may help convert drivers
a little easier if there is less to change.
Arnd
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_jan
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH v6 03/10] ARM: edma: add AM33XX support to the private EDMA API
On Wednesday 30 January 2013, Matt Porter wrote: > + dma_cap_set(DMA_SLAVE, edma_filter_info.dma_cap); > + of_dma_controller_register(dev->of_node, > + of_dma_simple_xlate, > + &edma_filter_info); > + } How do you actually deal with the problem mentioned by Padma, that the filter function does not know which edma instance it is looking at? If you assume that there can only be a single edma instance in the system, that is probably a limitation that should be documented somewhere, and ideally the probe() function should check for that. Arnd -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH v6 03/10] ARM: edma: add AM33XX support to the private EDMA API
On Thursday 31 January 2013, Matt Porter wrote: > On Wed, Jan 30, 2013 at 09:32:58AM +0000, Arnd Bergmann wrote: > > On Wednesday 30 January 2013, Matt Porter wrote: > > > + dma_cap_set(DMA_SLAVE, edma_filter_info.dma_cap); > > > + of_dma_controller_register(dev->of_node, > > > + of_dma_simple_xlate, > > > + &edma_filter_info); > > > + } > > > > How do you actually deal with the problem mentioned by Padma, that > > the filter function does not know which edma instance it is looking > > at? If you assume that there can only be a single edma instance in > > the system, that is probably a limitation that should be documented > > somewhere, and ideally the probe() function should check for that. > > I make an assumption of one edma instance in the system in the case of > DT being populated. This is always true right now as the only SoC with > two EDMA controllers in existence is Davinci DA850. Until recently, > Davinci had no DT support. Given the steady work being done today on DT > support for DA850, it'll probably be something needed in 3.10. > > I will add a comment and check in probe() to capture this assumption > and then plan to update separately to support DA850 booting from DT. Ok, sounds good. Hopefully by then we will already have a nicer way to write an xlate function that does not rely on a filter function. Arnd -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common
On Saturday 02 February 2013 04:07:59 Sergei Shtylyov wrote: > On 02-02-2013 1:30, Russell King - ARM Linux wrote: > >> because it doesn't make sense to support multiple DMA APIs. We can check > >> from MUSB's registers if it was configured with Inventra DMA support and > >> based on that we can register MUSB's own DMA Engine to dmaengine API. > > > Hang on. This is one of the DMA implementations which is closely > > coupled with the USB and only the USB? If it is... > > > I thought this had been discussed _extensively_ before. I thought the > > resolution on it was: > > 1. It would not use the DMA engine API. > > 2. It would not live in arch/arm. > > 3. It would be placed nearby the USB driver it's associated with. > > > (1) because we don't use APIs just for the hell of it - think. Do we > > use the DMA engine API for PCI bus mastering ethernet controllers? No. > > Do we use it for PCI bus mastering SCSI controllers? No. Because the > > DMA is integral to the rest of the device. > > > The DMA engine API only makes sense if the DMA engine is a shared > > system resource. > > Thanks for such extensive wording in the support of my point. Actually there is another problem with the musb driver, which is that you can only have one DMA controller configured at build time, and that currently prevents us from building a kernel that supports both the Inventra and TUSB variants together. With multiplatform coming up for both ux500 and omap2, we will also have to make a decision about ux500 vs omap being supported in DMA mode. I can see two ways out of this: either we extend the musb driver to have run-time registration of the DMA controller, which duplicates infrastructure that already exists in the dmaengine API, or we make the dmaengine back-end for musb the default and require all platforms to use that if they want to coexist with other platforms and also use DMA support in musb. Note that the ux500_dma code in musb already uses dmaengine. It could probably be extended to support any platform that has a dmaengine driver for the DMA controller used in MUSB. Arnd -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common
On Monday 04 February 2013, Linus Walleij wrote: > So I think the above concerns are moot. The callback we can > set on cookies is entirely optional, and it's even implemented by > each DMA engine, and some may not even support it but require > polling, and then it won't even be implemented by the driver. Just to ensure that everybody is talking about the same thing here: Is it just the callback that is optional, or also the interrupt coming from the hardware? With NAPI, you want to avoid both, since getting an interrupt for every packet adds noticeable overhead, but you still want to be able to tell the hardware that you are fed up with polling and would like to get an interrupt again when the next data arrives (ideally, after either a little time has passed after the next packet, or a specific number of packets has arrived). Arnd -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common
On Tuesday 05 February 2013, Tony Lindgren wrote: > * Felipe Balbi [130204 07:46]: > > > > Current DMA abstraction is quite poor, for example there's no way to > > compile support for multiple DMA engines. Code also makes certain, IMO > > unnecessary, assumptions about the underlying DMA engine (abstraction is > > poor, as said above but it we could follow MUSB's programming guide when > > it comes to programming DMA transfers). > > > > Considering all of the above, it's far better to use DMA engine and get > > rid of all the mess. > > How about just disable MUSB DMA support if ARCH_MULTIPLATFORM for now? > That way MUSB can be fixed up first to support ARCH_MULTIPLATFORM > using PIO while sorting out the DMA related issues. Sounds ok to me. Someone still needs to do the work to make the non-DMA variants of MUSB coexist in one kernel, but as we discussed erlier, that should be much simpler. Arnd -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH 2/5] spi: pl022: use generic DMA slave configuration if possible
On Thursday 07 February 2013, Linus Walleij wrote: > On Tue, Jan 29, 2013 at 2:13 PM, Arnd Bergmann wrote: > > On Tuesday 29 January 2013, Andy Shevchenko wrote: > > >> > + pl022->dummypage = kmalloc(PAGE_SIZE, GFP_KERNEL); > >> > >> Where this memory will be freed? > >> In dependence of the answer could you consider to use > >> devm_kmalloc or __get_free_page? > > > > There is another function like this called pl022_dma_probe() > > that has the same allocation, and it gets freed in the same place. > > > > It's probably worth changing this into something different, but > > I felt that it didn't belong into this patch. I was also not > > sure if the best option would be dmam_alloc_coherent, dev_kzalloc, > > or __get_free_page. > > Actually I once read about a feature where the kernel provides > a static page full of zeroes or something like this, that would be > ideal to use in cases like this, then all of this dummy page > allocation and freeing can be deleted. You mean empty_zero_page? That only works if this page is read-only from the perspective of the DMA controller, but then it would be a good fit, yes. Arnd -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH 2/5] spi: pl022: use generic DMA slave configuration if possible
On Thursday 07 February 2013 21:19:04 Linus Walleij wrote: > On Thu, Feb 7, 2013 at 8:42 PM, Arnd Bergmann wrote: > > On Thursday 07 February 2013, Linus Walleij wrote: > > >> Actually I once read about a feature where the kernel provides > >> a static page full of zeroes or something like this, that would be > >> ideal to use in cases like this, then all of this dummy page > >> allocation and freeing can be deleted. > > > > You mean empty_zero_page? That only works if this page is > > read-only from the perspective of the DMA controller, but > > then it would be a good fit, yes. > > That's actually how it's used. > > SPI is symmetric, and in the DMA case we're not poking > data into the buffers from the CPU so the controller need > something - anything - to stream to the block. > > If we can use that page we'll even save a few remaps. I'm slightly worried about the caching effects though. The idea of the empty-zero page is that all user processes get it when they read a page before they write to it, so the data in it can essentially always be cache-hot. If we do DMA from that page to a device what would be the overhead of flushing the (clean) cache lines? Arnd -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
[PATCH 3/4] spi: pl022: use generic DMA slave configuration if possible
With the new OF DMA binding, it is possible to completely avoid the
need for platform_data for configuring a DMA channel. In cases where the
platform has already been converted, calling dma_request_slave_channel
should get all the necessary information from the device tree.
Like the patch that converts the dw_dma controller, this is completely
untested and is looking for someone to try it out.
Signed-off-by: Arnd Bergmann
Acked-by: Grant Likely
Acked-by: Mark Brown
Acked-by: Linus Walleij
Cc: spi-devel-general@lists.sourceforge.net
Cc: Viresh Kumar
Cc: Andy Shevchenko
Cc: Vinod Koul
Cc: devicetree-disc...@lists.ozlabs.org
Cc: linux-arm-ker...@lists.infradead.org
---
.../devicetree/bindings/spi/spi_pl022.txt | 36 ++
drivers/spi/spi-pl022.c| 43 +-
2 files changed, 77 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/spi/spi_pl022.txt
b/Documentation/devicetree/bindings/spi/spi_pl022.txt
index f158fd3..22ed679 100644
--- a/Documentation/devicetree/bindings/spi/spi_pl022.txt
+++ b/Documentation/devicetree/bindings/spi/spi_pl022.txt
@@ -16,6 +16,11 @@ Optional properties:
device will be suspended immediately
- pl022,rt : indicates the controller should run the message pump with realtime
priority to minimise the transfer latency on the bus (boolean)
+- dmas : Two or more DMA channel specifiers following the convention outlined
+ in bindings/dma/dma.txt
+- dma-names: Names for the dma channels, if present. There must be at
+least one channel named "tx" for transmit and named "rx" for
+ receive.
SPI slave nodes must be children of the SPI master node and can
@@ -32,3 +37,34 @@ contain the following properties.
- pl022,wait-state : Microwire interface: Wait state
- pl022,duplex : Microwire interface: Full/Half duplex
+
+Example:
+
+ spi@e010 {
+ compatible = "arm,pl022", "arm,primecell";
+ reg = <0xe010 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interrupts = <0 31 0x4>;
+ dmas = <&dma-controller 23 1>,
+ <&dma-controller 24 0>;
+ dma-names = "rx", "tx";
+
+ m25p80@1 {
+ compatible = "st,m25p80";
+ reg = <1>;
+ spi-max-frequency = <1200>;
+ spi-cpol;
+ spi-cpha;
+ pl022,hierarchy = <0>;
+ pl022,interface = <0>;
+ pl022,slave-tx-disable;
+ pl022,com-mode = <0x2>;
+ pl022,rx-level-trig = <0>;
+ pl022,tx-level-trig = <0>;
+ pl022,ctrl-len = <0x11>;
+ pl022,wait-state = <0>;
+ pl022,duplex = <0>;
+ };
+ };
+
diff --git a/drivers/spi/spi-pl022.c b/drivers/spi/spi-pl022.c
index b0fe393..371cc66f 100644
--- a/drivers/spi/spi-pl022.c
+++ b/drivers/spi/spi-pl022.c
@@ -1139,6 +1139,35 @@ err_no_rxchan:
return -ENODEV;
}
+static int pl022_dma_autoprobe(struct pl022 *pl022)
+{
+ struct device *dev = &pl022->adev->dev;
+
+ /* automatically configure DMA channels from platform, normally using
DT */
+ pl022->dma_rx_channel = dma_request_slave_channel(dev, "rx");
+ if (!pl022->dma_rx_channel)
+ goto err_no_rxchan;
+
+ pl022->dma_tx_channel = dma_request_slave_channel(dev, "tx");
+ if (!pl022->dma_tx_channel)
+ goto err_no_txchan;
+
+ pl022->dummypage = kmalloc(PAGE_SIZE, GFP_KERNEL);
+ if (!pl022->dummypage)
+ goto err_no_dummypage;
+
+ return 0;
+
+err_no_dummypage:
+ dma_release_channel(pl022->dma_tx_channel);
+ pl022->dma_tx_channel = NULL;
+err_no_txchan:
+ dma_release_channel(pl022->dma_rx_channel);
+ pl022->dma_rx_channel = NULL;
+err_no_rxchan:
+ return -ENODEV;
+}
+
static void terminate_dma(struct pl022 *pl022)
{
struct dma_chan *rxchan = pl022->dma_rx_channel;
@@ -1167,6 +1196,11 @@ static inline int configure_dma(struct pl022 *pl022)
return -ENODEV;
}
+static inline int pl022_dma_autoprobe(struct pl022 *pl022)
+{
+ return 0;
+}
+
static inline int pl022_dma_probe(struct pl022 *pl022)
{
return 0;
@@ -2226,8 +2260,13 @@ static int pl022_probe(struct amba_device *adev, const
struct amba_id *id)
goto err_no_irq;
}
- /* Get DMA channels */
- if (platform_info->enable_dma) {
Re: [PATCH v2 1/4] spi/davinci: add DT binding documentation
On Monday 04 March 2013 18:29:12 Manjunathappa, Prakash wrote: > diff --git a/Documentation/devicetree/bindings/spi/spi-davinci.txt > b/Documentation/devicetree/bindings/spi/spi-davinci.txt > new file mode 100644 > index 000..a62d7a8 > --- /dev/null > +++ b/Documentation/devicetree/bindings/spi/spi-davinci.txt > @@ -0,0 +1,51 @@ > +Davinci SPI controller device bindings > + > +Required properties: > +- #address-cells: number of cells required to define a chip select > + address on the SPI bus. Should be set to 1. > +- #size-cells: should be zero. > +- compatible: > + - "ti,dm644x-spi" for SPI used similar to that on DM644x SoC family > + - "ti,da8xx-spi" for SPI used similar to that on DA8xx SoC family In general, you should avoid wildcards in "compatible" properties. Better use the number of the first chip that introduced the specific version of the device. > +- reg: Offset and length of SPI controller register space > +- num-cs: Number of chip selects > +- ti,davinci-spi-intr-line: interrupt line used to connect the SPI > + IP to the interrupt controller withn the SoC. Possible values > + are 0 and 1. Manual says one of the two possible interrupt > + lines can be tied to the interrupt controller. Set this > + based on a specifc SoC configuration. > +- interrupts: interrupt number offset at the irq parent I would not call this an "offset". It is an interrupt descriptor which may be something other than a simple number. Unfortunately, there is no way to provide an "invalid" interrupt, otherwise you could just list both interrupts, out of which at least one should be valid, and drop the ti,davinci-spi-intr-line property. One thing you could do instead though is to use the "interrupt-names" property to define "irq0" and "irq1" interrupts, and in the implementation use the first one you find. Arnd -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH v2 1/4] spi/davinci: add DT binding documentation
On Tuesday 05 March 2013, Manjunathappa, Prakash wrote: > On Mon, Mar 04, 2013 at 21:59:16, Arnd Bergmann wrote: > > On Monday 04 March 2013 18:29:12 Manjunathappa, Prakash wrote: > > > +- reg: Offset and length of SPI controller register space > > > +- num-cs: Number of chip selects > > > +- ti,davinci-spi-intr-line: interrupt line used to connect the SPI > > > + IP to the interrupt controller withn the SoC. Possible values > > > + are 0 and 1. Manual says one of the two possible interrupt > > > + lines can be tied to the interrupt controller. Set this > > > + based on a specifc SoC configuration. > > > +- interrupts: interrupt number offset at the irq parent > > > > I would not call this an "offset". It is an interrupt descriptor > > which may be something other than a simple number. > > > > I am planning to drop from this documentation as it is common property. I think it makese sense to document the fact that there should be exactly one interrupt listed in the interrupts property, especially since the hardware has two outputs. Arnd -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
[PATCH 29/30] spi: s3c64xx: move to generic dmaengine API
The spi-s3c64xx uses a Samsung proprietary interface for
talking to the DMA engine, which does not work with
multiplatform kernels.
This version of the patch leaves the old code in place,
behind an #ifdef. This can be removed in the future,
after the s3c64xx platform start supporting the regular
dmaengine interface. An earlier version of this patch was
tested successfully on exynos5250 by Padma Venkat.
The conversion was rather mechanical, since the samsung
interface is just a shallow wrapper around the dmaengine
interface.
Signed-off-by: Arnd Bergmann
Cc: spi-devel-general@lists.sourceforge.net
Cc: Mark Brown
Cc: Grant Likely
Cc: Padma Venkat
---
arch/arm/plat-samsung/devs.c | 10 ++
drivers/spi/spi-s3c64xx.c | 185 +++---
include/linux/platform_data/spi-s3c64xx.h | 3 +
3 files changed, 154 insertions(+), 44 deletions(-)
diff --git a/arch/arm/plat-samsung/devs.c b/arch/arm/plat-samsung/devs.c
index b441908..30c2fe2 100644
--- a/arch/arm/plat-samsung/devs.c
+++ b/arch/arm/plat-samsung/devs.c
@@ -10,6 +10,7 @@
* published by the Free Software Foundation.
*/
+#include
#include
#include
#include
@@ -1512,6 +1513,9 @@ void __init s3c64xx_spi0_set_platdata(int
(*cfg_gpio)(void), int src_clk_nr,
pd.num_cs = num_cs;
pd.src_clk_nr = src_clk_nr;
pd.cfg_gpio = (cfg_gpio) ? cfg_gpio : s3c64xx_spi0_cfg_gpio;
+#ifdef CONFIG_PL330_DMA
+ pd.filter = pl330_filter;
+#endif
s3c_set_platdata(&pd, sizeof(pd), &s3c64xx_device_spi0);
}
@@ -1550,6 +1554,9 @@ void __init s3c64xx_spi1_set_platdata(int
(*cfg_gpio)(void), int src_clk_nr,
pd.num_cs = num_cs;
pd.src_clk_nr = src_clk_nr;
pd.cfg_gpio = (cfg_gpio) ? cfg_gpio : s3c64xx_spi1_cfg_gpio;
+#ifdef CONFIG_PL330_DMA
+ pd.filter = pl330_filter;
+#endif
s3c_set_platdata(&pd, sizeof(pd), &s3c64xx_device_spi1);
}
@@ -1588,6 +1595,9 @@ void __init s3c64xx_spi2_set_platdata(int
(*cfg_gpio)(void), int src_clk_nr,
pd.num_cs = num_cs;
pd.src_clk_nr = src_clk_nr;
pd.cfg_gpio = (cfg_gpio) ? cfg_gpio : s3c64xx_spi2_cfg_gpio;
+#ifdef CONFIG_PL330_DMA
+ pd.filter = pl330_filter;
+#endif
s3c_set_platdata(&pd, sizeof(pd), &s3c64xx_device_spi2);
}
diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
index 4188b2f..74809af 100644
--- a/drivers/spi/spi-s3c64xx.c
+++ b/drivers/spi/spi-s3c64xx.c
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -31,9 +32,12 @@
#include
#include
-#include
#include
+#ifdef CONFIG_SAMSUNG_DMADEV
+#include
+#endif
+
#define MAX_SPI_PORTS 3
/* Registers and bit-fields */
@@ -131,9 +135,9 @@
#define TXBUSY(1<<3)
struct s3c64xx_spi_dma_data {
- unsignedch;
+ struct dma_chan *ch;
enum dma_transfer_direction direction;
- enum dma_ch dmach;
+ unsigned int dmach;
};
/**
@@ -195,16 +199,14 @@ struct s3c64xx_spi_driver_data {
unsignedcur_speed;
struct s3c64xx_spi_dma_data rx_dma;
struct s3c64xx_spi_dma_data tx_dma;
+#ifdef CONFIG_SAMSUNG_DMADEV
struct samsung_dma_ops *ops;
+#endif
struct s3c64xx_spi_port_config *port_conf;
unsigned intport_id;
unsigned long gpios[4];
};
-static struct s3c2410_dma_client s3c64xx_spi_dma_client = {
- .name = "samsung-spi-dma",
-};
-
static void flush_fifo(struct s3c64xx_spi_driver_data *sdd)
{
void __iomem *regs = sdd->regs;
@@ -281,6 +283,13 @@ static void s3c64xx_spi_dmacb(void *data)
spin_unlock_irqrestore(&sdd->lock, flags);
}
+#ifdef CONFIG_SAMSUNG_DMADEV
+/* FIXME: remove this section once arch/arm/mach-s3c64xx uses dmaengine */
+
+static struct s3c2410_dma_client s3c64xx_spi_dma_client = {
+ .name = "samsung-spi-dma",
+};
+
static void prepare_dma(struct s3c64xx_spi_dma_data *dma,
unsigned len, dma_addr_t buf)
{
@@ -294,14 +303,14 @@ static void prepare_dma(struct s3c64xx_spi_dma_data *dma,
config.direction = sdd->rx_dma.direction;
config.fifo = sdd->sfr_start + S3C64XX_SPI_RX_DATA;
config.width = sdd->cur_bpw / 8;
- sdd->ops->config(sdd->rx_dma.ch, &config);
+ sdd->ops->config((enum dma_ch)sdd->rx_dma.ch, &config);
} else {
sdd = container_of((void *)dma,
struct s3c64xx_spi_driver_data, tx_dma);
config.direction = sdd->tx_dma.direction;
config.fifo = sdd->sfr_start + S3C64XX_SPI_TX_DATA;
config.width = sdd->cur_bpw / 8;
- sdd->ops->config(sdd->tx_dma.ch, &config);
+
[PATCH v2] spi: s3c64xx: move to generic dmaengine API
The spi-s3c64xx uses a Samsung proprietary interface for
talking to the DMA engine, which does not work with
multiplatform kernels.
This version of the patch leaves the old code in place,
behind an #ifdef. This can be removed in the future,
after the s3c64xx platform start supporting the regular
dmaengine interface. An earlier version of this patch was
tested successfully on exynos5250 by Padma Venkat.
The conversion was rather mechanical, since the samsung
interface is just a shallow wrapper around the dmaengine
interface.
Signed-off-by: Arnd Bergmann
Cc: spi-devel-general@lists.sourceforge.net
Cc: Mark Brown
Cc: Grant Likely
Cc: Padma Venkat
v2: rebased to git://git.kernel.org/pub/scm/linux/kernel/git/broonie/misc.git
spi-next
diff --git a/arch/arm/plat-samsung/devs.c b/arch/arm/plat-samsung/devs.c
index 51afedd..03db14d 100644
--- a/arch/arm/plat-samsung/devs.c
+++ b/arch/arm/plat-samsung/devs.c
@@ -10,6 +10,7 @@
* published by the Free Software Foundation.
*/
+#include
#include
#include
#include
@@ -1552,6 +1553,9 @@ void __init s3c64xx_spi0_set_platdata(int
(*cfg_gpio)(void), int src_clk_nr,
pd.num_cs = num_cs;
pd.src_clk_nr = src_clk_nr;
pd.cfg_gpio = (cfg_gpio) ? cfg_gpio : s3c64xx_spi0_cfg_gpio;
+#ifdef CONFIG_PL330_DMA
+ pd.filter = pl330_filter;
+#endif
s3c_set_platdata(&pd, sizeof(pd), &s3c64xx_device_spi0);
}
@@ -1590,6 +1594,9 @@ void __init s3c64xx_spi1_set_platdata(int
(*cfg_gpio)(void), int src_clk_nr,
pd.num_cs = num_cs;
pd.src_clk_nr = src_clk_nr;
pd.cfg_gpio = (cfg_gpio) ? cfg_gpio : s3c64xx_spi1_cfg_gpio;
+#ifdef CONFIG_PL330_DMA
+ pd.filter = pl330_filter;
+#endif
s3c_set_platdata(&pd, sizeof(pd), &s3c64xx_device_spi1);
}
@@ -1628,6 +1635,9 @@ void __init s3c64xx_spi2_set_platdata(int
(*cfg_gpio)(void), int src_clk_nr,
pd.num_cs = num_cs;
pd.src_clk_nr = src_clk_nr;
pd.cfg_gpio = (cfg_gpio) ? cfg_gpio : s3c64xx_spi2_cfg_gpio;
+#ifdef CONFIG_PL330_DMA
+ pd.filter = pl330_filter;
+#endif
s3c_set_platdata(&pd, sizeof(pd), &s3c64xx_device_spi2);
}
diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
index 682b1e7..4989aeb 100644
--- a/drivers/spi/spi-s3c64xx.c
+++ b/drivers/spi/spi-s3c64xx.c
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -31,9 +32,12 @@
#include
#include
-#include
#include
+#ifdef CONFIG_SAMSUNG_DMADEV
+#include
+#endif
+
#define MAX_SPI_PORTS 3
/* Registers and bit-fields */
@@ -131,9 +135,9 @@
#define TXBUSY(1<<3)
struct s3c64xx_spi_dma_data {
- unsignedch;
+ struct dma_chan *ch;
enum dma_transfer_direction direction;
- enum dma_ch dmach;
+ unsigned int dmach;
};
/**
@@ -195,16 +199,14 @@ struct s3c64xx_spi_driver_data {
unsignedcur_speed;
struct s3c64xx_spi_dma_data rx_dma;
struct s3c64xx_spi_dma_data tx_dma;
+#ifdef CONFIG_SAMSUNG_DMADEV
struct samsung_dma_ops *ops;
+#endif
struct s3c64xx_spi_port_config *port_conf;
unsigned intport_id;
unsigned long gpios[4];
};
-static struct s3c2410_dma_client s3c64xx_spi_dma_client = {
- .name = "samsung-spi-dma",
-};
-
static void flush_fifo(struct s3c64xx_spi_driver_data *sdd)
{
void __iomem *regs = sdd->regs;
@@ -281,6 +283,13 @@ static void s3c64xx_spi_dmacb(void *data)
spin_unlock_irqrestore(&sdd->lock, flags);
}
+#ifdef CONFIG_SAMSUNG_DMADEV
+/* FIXME: remove this section once arch/arm/mach-s3c64xx uses dmaengine */
+
+static struct s3c2410_dma_client s3c64xx_spi_dma_client = {
+ .name = "samsung-spi-dma",
+};
+
static void prepare_dma(struct s3c64xx_spi_dma_data *dma,
unsigned len, dma_addr_t buf)
{
@@ -294,14 +303,14 @@ static void prepare_dma(struct s3c64xx_spi_dma_data *dma,
config.direction = sdd->rx_dma.direction;
config.fifo = sdd->sfr_start + S3C64XX_SPI_RX_DATA;
config.width = sdd->cur_bpw / 8;
- sdd->ops->config(sdd->rx_dma.ch, &config);
+ sdd->ops->config((enum dma_ch)sdd->rx_dma.ch, &config);
} else {
sdd = container_of((void *)dma,
struct s3c64xx_spi_driver_data, tx_dma);
config.direction = sdd->tx_dma.direction;
config.fifo = sdd->sfr_start + S3C64XX_SPI_TX_DATA;
config.width = sdd->cur_bpw / 8;
- sdd->ops->config(sdd->tx_dma.ch, &config);
+ sdd->ops->config((enum dma_ch)sdd->tx_dma.ch, &config);
}
info.cap = DMA_SLAVE;
@@ -311,8 +320,8 @@ static void
Re: [PATCH 29/30] spi: s3c64xx: move to generic dmaengine API
On Thursday 11 April 2013, Arnd Bergmann wrote: > @@ -713,9 +836,9 @@ static int s3c64xx_spi_transfer_one_message(struct > spi_master *master, > } > > /* Polling method for xfers not bigger than FIFO capacity */ > - if (xfer->len <= ((FIFO_LVL_MASK(sdd) >> 1) + 1)) > - use_dma = 0; > - else > + use_dma = 0; > + if (sdd->rx_dma.ch && sdd->tx_dma.ch && > + (xfer->len > ((FIFO_LVL_MASK(sdd) >> 1) + 1))) > use_dma = 1; > > spin_lock_irqsave(&sdd->lock, flags); Can you try just reverting this hunk? It's actually not required and comes from an earlier version of the patch. I assumed it was harmless, but it's the only think I see that should actually make a difference in my patch for the case of !CONFIG_SAMSUNG_DMADEV. Arnd -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH] spi/s3c64xx: Fix non-dmaengine usage
On Thursday 18 April 2013, Mark Brown wrote: > The multiplatform conversion in commit 788437 (spi: s3c64xx: move to > generic dmaengine API) tested for the use of the Samsung-specific DMA > API with SAMSUNG_DMADEV when in fact S3C_DMA should be used. This > renderd DMA based transfers non-functional on platforms not using > dmaengine. > > Signed-off-by: Mark Brown Acked-by: Arnd Bergmann Sorry for the confusion on my part. I thought that S3C_DMA was referring to just the S3C specific functionality while SAMSUNG_DMADEV was the wrapper around it, while in truth SAMSUNG_DMADEV is the wrapper around just the dmaengine API. Arnd -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
[PATCH 09/21] spi/sirf: fix MODULE_DEVICE_TABLE
This fixes building the spi-sirf driver as a loadable module, which uses
an incorrect MODULE_DEVICE_TABLE, by changing the reference to the
correct symbol.
Signed-off-by: Arnd Bergmann
Cc: Grant Likely
Cc: Mark Brown
Cc: spi-devel-general@lists.sourceforge.net
Cc: Barry Song
---
drivers/spi/spi-sirf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/spi/spi-sirf.c b/drivers/spi/spi-sirf.c
index f59d417..0808cd5 100644
--- a/drivers/spi/spi-sirf.c
+++ b/drivers/spi/spi-sirf.c
@@ -660,7 +660,7 @@ static const struct of_device_id spi_sirfsoc_of_match[] = {
{ .compatible = "sirf,marco-spi", },
{}
};
-MODULE_DEVICE_TABLE(of, sirfsoc_spi_of_match);
+MODULE_DEVICE_TABLE(of, spi_sirfsoc_of_match);
static struct platform_driver spi_sirfsoc_driver = {
.driver = {
--
1.8.1.2
--
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
[PATCH 00/21] ARM build fixes for 3.10
Hi everyone, This is a set of bug fixes for build errors and warnings I am seeing in the various defconfigs and/or allmodconfig builds on linux-next. The majority of these showed up because we now include a lot more platforms in allmodconfig than we used to. Please apply to appropriate maintainer trees or provide feedback, I can take care of the rest sending those through arm-soc that I get no feedback on. Arnd Arnd Bergmann (21): Turn off -Wmaybe-uninitialized when building with -Os ARM: compressed/head.S: work around new binutils warning ARM: use optimized do_div only for EABI ARM: kvm: define KVM_ARM_MAX_VCPUS unconditionally ARM: OMAP2+: add dependencies on ARCH_MULTI_V6/V7 ARM: tegra: call cpu_do_idle from C code ARM: tegra: unify tegra_idle_device definitions ASoC: ux500: forward declare msp_i2s_platform_data spi/sirf: fix MODULE_DEVICE_TABLE ssb: fix alignment of struct bcma_device_id drm/tilcdc: use only a single module device table mmc: sdhci-tegra: fix MODULE_DEVICE_TABLE misc: mark spear13xx-pcie-gadget as broken staging: nvec: allow modular build staging: comedi/dawboard2000: use mdelay for large delays staging/zsmalloc: don't use pgtable-mapping from modules tty/serial/sirf: fix MODULE_DEVICE_TABLE usb: phy: tegra: don't call into tegra-ehci directly usb: phy: don't mark usb_bind_phy as __init MFD: ab8500: export ab8500_gpadc_sw_hw_convert properly mtd: omap2: allow bulding as a module Makefile | 2 +- arch/arm/boot/compressed/Makefile | 2 +- arch/arm/boot/compressed/head.S | 12 arch/arm/include/asm/div64.h | 2 +- arch/arm/kvm/Kconfig | 6 +++--- arch/arm/mach-omap2/Kconfig | 5 + arch/arm/mach-tegra/cpuidle-tegra114.c| 5 ++--- arch/arm/mach-tegra/cpuidle-tegra20.c | 4 +--- arch/arm/mach-tegra/cpuidle-tegra30.c | 4 +--- arch/arm/mach-tegra/cpuidle.c | 2 ++ arch/arm/mach-tegra/cpuidle.h | 4 arch/arm/mach-tegra/pm.c | 5 + arch/arm/mach-tegra/sleep-tegra20.S | 2 +- drivers/gpu/drm/tilcdc/tilcdc_panel.c | 1 - drivers/gpu/drm/tilcdc/tilcdc_slave.c | 1 - drivers/gpu/drm/tilcdc/tilcdc_tfp410.c| 1 - drivers/mfd/ab8500-gpadc.c| 2 +- drivers/misc/Kconfig | 2 +- drivers/mmc/host/sdhci-tegra.c| 2 +- drivers/mtd/nand/Kconfig | 2 +- drivers/spi/spi-sirf.c| 2 +- drivers/staging/comedi/drivers/daqboard2000.c | 14 +++--- drivers/staging/nvec/Kconfig | 10 +- drivers/staging/zsmalloc/zsmalloc-main.c | 2 +- drivers/tty/serial/sirfsoc_uart.c | 2 +- drivers/usb/host/ehci-tegra.c | 10 +- drivers/usb/otg/otg.c | 2 +- drivers/usb/phy/tegra_usb_phy.c | 13 + include/linux/mod_devicetable.h | 5 +++-- include/linux/usb/tegra_usb_phy.h | 10 +- sound/soc/ux500/ux500_msp_i2s.h | 1 + 31 files changed, 82 insertions(+), 55 deletions(-) -- 1.8.1.2 Cc: Alan Stern Cc: Artem Bityutskiy Cc: Chris Ball Cc: Dave Airlie Cc: David Woodhouse Cc: Felipe Balbi Cc: Grant Likely Cc: Greg Kroah-Hartman Cc: Mark Brown Cc: Russell King Cc: Samuel Ortiz Cc: Stephen Warren Cc: Tony Lindgren Cc: Viresh Kumar Cc: alsa-de...@alsa-project.org Cc: dri-de...@lists.freedesktop.org Cc: linux-...@lists.infradead.org Cc: linux-...@vger.kernel.org Cc: spi-devel-general@lists.sourceforge.net -- Try New Relic Now & We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH 2/2] spi: convert drivers to use bits_per_word_mask
Can you check this part again:
On Tuesday 21 May 2013 20:36:35 Stephen Warren wrote:
> diff --git a/drivers/spi/spi-pxa2xx.c b/drivers/spi/spi-pxa2xx.c
> index f5d84d6..7de2ca1 100644
> --- a/drivers/spi/spi-pxa2xx.c
> +++ b/drivers/spi/spi-pxa2xx.c
> @@ -881,21 +881,6 @@ static int setup(struct spi_device *spi)
> rx_thres = RX_THRESH_DFLT;
> }
>
> - if (!pxa25x_ssp_comp(drv_data)
> - && (spi->bits_per_word < 4 || spi->bits_per_word > 32)) {
> - dev_err(&spi->dev, "failed setup: ssp_type=%d, bits/wrd=%d "
> - "b/w not 4-32 for type non-PXA25x_SSP\n",
> - drv_data->ssp_type, spi->bits_per_word);
> - return -EINVAL;
> - } else if (pxa25x_ssp_comp(drv_data)
> - && (spi->bits_per_word < 4
> - || spi->bits_per_word > 16)) {
> - dev_err(&spi->dev, "failed setup: ssp_type=%d, bits/wrd=%d "
> - "b/w not 4-16 for type PXA25x_SSP\n",
> - drv_data->ssp_type, spi->bits_per_word);
> - return -EINVAL;
> - }
> -
> /* Only alloc on first setup */
> chip = spi_get_ctldata(spi);
> if (!chip) {
> @@ -1011,9 +996,6 @@ static int setup(struct spi_device *spi)
> chip->n_bytes = 4;
> chip->read = u32_reader;
> chip->write = u32_writer;
> - } else {
> - dev_err(&spi->dev, "invalid wordsize\n");
> - return -ENODEV;
> }
> chip->bits_per_word = spi->bits_per_word;
>
> @@ -1190,11 +1172,13 @@ static int pxa2xx_spi_probe(struct platform_device
> *pdev)
> drv_data->ioaddr = ssp->mmio_base;
> drv_data->ssdr_physical = ssp->phys_base + SSDR;
> if (pxa25x_ssp_comp(drv_data)) {
> + master->bits_per_word_mask = SPI_BPW_RANGE_MASK(4, 16);
> drv_data->int_cr1 = SSCR1_TIE | SSCR1_RIE;
> drv_data->dma_cr1 = 0;
> drv_data->clear_sr = SSSR_ROR;
> drv_data->mask_sr = SSSR_RFS | SSSR_TFS | SSSR_ROR;
> } else {
> + master->bits_per_word_mask = SPI_BPW_RANGE_MASK(4, 32);
> drv_data->int_cr1 = SSCR1_TIE | SSCR1_RIE | SSCR1_TINTE;
> drv_data->dma_cr1 = DEFAULT_DMA_CR1;
> drv_data->clear_sr = SSSR_ROR | SSSR_TINT;
I get a new build warning
drivers/spi/spi-pxa2xx.c: In function 'pxa2xx_spi_probe':
drivers/spi/spi-pxa2xx.c:1152:3: warning: left shift count >= width of type
[enabled by default]
master->bits_per_word_mask = SPI_BPW_RANGE_MASK(4, 32);
^
Arnd
--
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH 2/2] spi: convert drivers to use bits_per_word_mask
On Friday 31 May 2013, Stephen Warren wrote: > > drivers/spi/spi-pxa2xx.c: In function 'pxa2xx_spi_probe': > > drivers/spi/spi-pxa2xx.c:1152:3: warning: left shift count >= width of type > > [enabled by default] > >master->bits_per_word_mask = SPI_BPW_RANGE_MASK(4, 32); > >^ > > That should be fixed by the patches I sent yesterday. Cool, thanks! Arnd -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH v10 5/8] dmaengine: edma: Add TI EDMA device tree binding
On Friday 14 June 2013 21:32:47 Joel A Fernandes wrote: > > diff --git a/Documentation/devicetree/bindings/dma/ti-edma.txt > b/Documentation/devicetree/bindings/dma/ti-edma.txt > new file mode 100644 > index 000..ada0018 > --- /dev/null > +++ b/Documentation/devicetree/bindings/dma/ti-edma.txt > @@ -0,0 +1,26 @@ > +TI EDMA > + > +Required properties: > +- compatible : "ti,edma3" > +- ti,hwmods: Name of the hwmods associated to the EDMA > +- ti,edma-regions: Number of regions > +- ti,edma-slots: Number of slots > + > +Optional properties: > +- ti,edma-xbar-event-map: Crossbar event to channel map You need to list #dma-cells as required here, and which values are accepted by the driver (I suppose only <1>). You should also explain the format of the dma-specifier for a slave here for each possible value of #dma-cells. For each of the standard properties (reg, interrupts, dma-channels), list whether they are optional or required. Since the example has three interrupts, you should probably list how many interrupts need to be specified (minimum and maximum if the number is variable) and in what order to expect them. Arnd -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH v10 5/8] dmaengine: edma: Add TI EDMA device tree binding
On Monday 17 June 2013, Fernandes, Joel A wrote: > [Joel] Thanks for the suggestion, I updated it and it looks like this now: > > > Required properties: > > - compatible : "ti,edma3" > > - ti,hwmods: Name of the hwmods associated to the EDMA > > - ti,edma-regions: Number of regions > > - ti,edma-slots: Number of slots > - #dma-cells: Should be set to <1> > Clients should use a single number per DMA channel request. That still does not say what that number refers to. Is it a channel number, or a request line number, or something completely different? Arnd -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH v11 0/8] ] DMA Engine support for AM33XX
On Tuesday 18 June 2013, Joel A Fernandes wrote: > > This series is a repost of Matt Porter's EDMA patches for AM33XX EDMA support > with changes for few pending review comments on v9 series. > > Currently this is required for AM33XX (Beaglebone or EVM) to access MMC > and be able mount to rootfs and boot till command prompt over MMC. > Unless there are other pending review comments, I hope this series can > make it into 3.11 merge window, the dependent series has been posted at [1] > and completed review. > > Tested EDMA on AM1808 EVM and AM33XX Beaglebone with MMC. > Acked-by: Arnd Bergmann The binding looks good now. My usual comment about the fact that we shouldn't use a filter function in .xlate() applies here, but that is more about the missing interface of the dmaengine layer than the particular driver. Arnd -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH v12 05/11] edma: config: Enable config options for EDMA
On Friday 21 June 2013, Joel A Fernandes wrote: > >> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > >> index b1c66a4..7d58cd9 100644 > >> --- a/arch/arm/Kconfig > >> +++ b/arch/arm/Kconfig > >> @@ -841,6 +841,7 @@ config ARCH_DAVINCI > >> select HAVE_IDE > >> select NEED_MACH_GPIO_H > >> select TI_PRIV_EDMA > >> + select DMADEVICES > > > > It is generally a bad idea to force select on something that can be > > enabled using menuconfig. Unless used carefully, select causes "unmet > > direct dependency" warnings which folks are already fighting hard to > > fix. This leads to what Russell referred in the past as "select madness" [1] > > Are you concerned with bloat issues? I know your point of view but the idea > was to build these options by default for these platforms even though > in some cases > it might not be used. I have seen folks including myself select the wrong > option. Having the build system automatically select the correct option for > the > most common cases can be very useful I feel and not require manual > configuration. For defaults, you should use the defconfig, not 'select' in Kconfig. A lot of the 'select' statements are actually wrong because they do not take dependencies into account where A selects B but not C, and B depends on C, which leads to broken builds when C is disabled by a user (or randconfig). You should only ever use 'select' from platforms on silent options that are not themselves user selectable like the above 'HAVE_IDE' and 'NEED_MACH_GPIO_H'. Arnd -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH v12 05/11] edma: config: Enable config options for EDMA
On Friday 21 June 2013, Joel A Fernandes wrote: > I haven't come across this problem but- are you saying there is a > shortcoming in Kbuild/Kconfig that selects an option even if its > dependency is not met? Well, the shortcoming is that it lets you specify impossible contraints. You get a warning from Kconfig when building such a configuration, but then it continues. > The problem with defconfig is also too many options I feel for a common case. > CONFIG_DMADEVICES=y > CONFIG_TI_EDMA=y > > Most if not all future OMAPs from will use EDMA. Why not we can be > explicit about it and just built it in anyway. If ARCH_OMAP and > DMADEVICES are selected, then we can just build EDMA in by default. It's just not how we do things. Kconfig is a mess because we are not consistent in the way this is done. > I agree maybe the option can be dropped from Davinci but I suggest > let's keep it for OMAP. Is that ok? No, I would still like you to not add it to either one. I'm spending a lot of my time tracking down incorrect 'select' statements and I'd rather spend it in a different way. I've had to a number of 'select' statements from OMAP in the past, please don't add any new ones unless there is a strict build dependency (which normally should not exist). Arnd -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH v12 05/11] edma: config: Enable config options for EDMA
On Friday 21 June 2013, Joel A Fernandes wrote: > I think we are talking about different things, I agree the 'select > DMADEVICES' can be dropped but lets please keep the default y option > (not adding new select statements, just saying that if someone select > DMADEVICES in menuconfig and if they're ARCH_OMAP=1 , then default to > EDMA). This will simply allow people to have a default. Thanks. Yes, that's ok. Also, if the driver doesn't strictly depend on these platforms but can build on anything, I would write it as config TI_EDMA tristate "TI EDMA support" default m if 'ARCH_DAVINCI || ARCH_OMAP1 || ARCH_OMAP2 select DMA_ENGINE select DMA_VIRTUAL_CHANNELS Arnd -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH v12 05/11] edma: config: Enable config options for EDMA
On Friday 21 June 2013, Joel A Fernandes wrote: > Hi Arnd, > > On Fri, Jun 21, 2013 at 1:44 PM, Arnd Bergmann wrote: > > On Friday 21 June 2013, Joel A Fernandes wrote: > >> I think we are talking about different things, I agree the 'select > >> DMADEVICES' can be dropped but lets please keep the default y option > >> (not adding new select statements, just saying that if someone select > >> DMADEVICES in menuconfig and if they're ARCH_OMAP=1 , then default to > >> EDMA). This will simply allow people to have a default. Thanks. > > > > Yes, that's ok. > > Ok, thanks. I will follow up with a patch in my next submissions that builds > it. > > Perhaps a: > default y if 'ARCH_OMAP2PLUS' > > and leave the existing as it is... > default n if 'ARCH_DAVINCI || ARCH_OMAP1 || ARCH_OMAP2' > > would make most sense to me. Basically EDMA is seen on current and all > new OMAP2PLUS. Ok > > config TI_EDMA > > tristate "TI EDMA support" > > default m if 'ARCH_DAVINCI || ARCH_OMAP1 || ARCH_OMAP2 > > select DMA_ENGINE > > select DMA_VIRTUAL_CHANNELS > > > MMC depends on EDMA specially on AM33xx there's no PIO mode AFAIK. The > 'm' option will require some initramfs to load the module when needing > to MMC boot, I suggest lets leave it as y. > Ah, right: you still export a filter function from the edma driver and use it in slave drivers: drivers/mmc/host/davinci_mmc.c: dma_request_slave_channel_compat(mask, edma_filter_fn, drivers/mmc/host/davinci_mmc.c: dma_request_slave_channel_compat(mask, edma_filter_fn, drivers/spi/spi-davinci.c: dspi->dma_rx = dma_request_channel(mask, edma_filter_fn, drivers/spi/spi-davinci.c: dspi->dma_tx = dma_request_channel(mask, edma_filter_fn, As long as this is the case, you have to be careful with the dependencies to make sure that davinci_mmc and spi-davinci either depend on TI_EDMA, or edma_filter_fn gets defined to NULL when you are building for a DT-only platform. Arnd -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH v12 05/11] edma: config: Enable config options for EDMA
On Saturday 22 June 2013, Joel A Fernandes wrote:
>
> >> > config TI_EDMA
> >> > tristate "TI EDMA support"
> >> > default m if 'ARCH_DAVINCI || ARCH_OMAP1 || ARCH_OMAP2
> >> > select DMA_ENGINE
> >> > select DMA_VIRTUAL_CHANNELS
> >>
> >>
> >> MMC depends on EDMA specially on AM33xx there's no PIO mode AFAIK. The
> >> 'm' option will require some initramfs to load the module when needing
> >> to MMC boot, I suggest lets leave it as y.
> >>
> >
> > Ah, right: you still export a filter function from the edma driver
> > and use it in slave drivers:
> >
> > drivers/mmc/host/davinci_mmc.c:
> > dma_request_slave_channel_compat(mask, edma_filter_fn,
> > drivers/mmc/host/davinci_mmc.c:
> > dma_request_slave_channel_compat(mask, edma_filter_fn,
> > drivers/spi/spi-davinci.c: dspi->dma_rx = dma_request_channel(mask,
> > edma_filter_fn,
> > drivers/spi/spi-davinci.c: dspi->dma_tx = dma_request_channel(mask,
> > edma_filter_fn,
> >
> > As long as this is the case, you have to be careful with the dependencies
> > to make sure that davinci_mmc and spi-davinci either depend on TI_EDMA, or
> > edma_filter_fn gets defined to NULL when you are building for a DT-only
> > platform.
>
> Yes sure, right now they are defined as follows in include/linux/edma.h:
>
> #if defined(CONFIG_TI_EDMA) || defined(CONFIG_TI_EDMA_MODULE)
> bool edma_filter_fn(struct dma_chan *, void *);
> #else
> static inline bool edma_filter_fn(struct dma_chan *chan, void *param)
> {
> return false;
> }
> #endif
It's best to just define the filter function in the platform
code and pass a pointer to it through platform data. The way you do
it above makes the slave drivers inherently nonportable.
Arnd
--
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH v12 05/11] edma: config: Enable config options for EDMA
On Monday 24 June 2013, Joel A Fernandes wrote:
> >> Yes sure, right now they are defined as follows in include/linux/edma.h:
> >>
> >> #if defined(CONFIG_TI_EDMA) || defined(CONFIG_TI_EDMA_MODULE)
> >> bool edma_filter_fn(struct dma_chan *, void *);
> >> #else
> >> static inline bool edma_filter_fn(struct dma_chan *chan, void *param)
> >> {
> >> return false;
> >> }
> >> #endif
> >
> > It's best to just define the filter function in the platform
> > code and pass a pointer to it through platform data. The way you do
> > it above makes the slave drivers inherently nonportable.
>
> But with DT-only platforms, can you really do that?
The nice thing about this is that with a DT-only platform, the
filter function will automatically go away: you have no
platform_data, which means that if you are using
dma_request_slave_channel_compat, you just pass NULL as the
filter and the filter-data, same as just calling
dma_request_slave_channel.
Arnd
--
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
