* RE: [PATCH] mtd/nand:Fix wrong usage of is_blank() in fsl_ifc_run_command
From: Kushwaha Prabhakar-B32579 @ 2012-01-27 14:20 UTC (permalink / raw)
To: dedekind1@gmail.com
Cc: linux-mtd@lists.infradead.org, Aggrwal Poonam-B10812,
linuxppc-dev@lists.ozlabs.org, Wood Scott-B07421
In-Reply-To: <1327670133.26648.40.camel@sauron.fi.intel.com>
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQXJ0ZW0gQml0eXV0c2tp
eSBbbWFpbHRvOmRlZGVraW5kMUBnbWFpbC5jb21dDQo+IFNlbnQ6IEZyaWRheSwgSmFudWFyeSAy
NywgMjAxMiA2OjQ2IFBNDQo+IFRvOiBLdXNod2FoYSBQcmFiaGFrYXItQjMyNTc5DQo+IENjOiBs
aW51eHBwYy1kZXZAbGlzdHMub3psYWJzLm9yZzsgbGludXgtbXRkQGxpc3RzLmluZnJhZGVhZC5v
cmc7IFdvb2QNCj4gU2NvdHQtQjA3NDIxOyBBZ2dyd2FsIFBvb25hbS1CMTA4MTINCj4gU3ViamVj
dDogUmU6IFtQQVRDSF0gbXRkL25hbmQ6Rml4IHdyb25nIHVzYWdlIG9mIGlzX2JsYW5rKCkgaW4N
Cj4gZnNsX2lmY19ydW5fY29tbWFuZA0KPiANCj4gT24gV2VkLCAyMDEyLTAxLTE4IGF0IDA5OjQz
ICswNTMwLCBQcmFiaGFrYXIgS3VzaHdhaGEgd3JvdGU6DQo+ID4gRnJlZXNjYWxlIElGQyBOQU5E
IE1hY2hpbmUgY2FsY3VsYXRlcyBFQ0Mgb24gNTEyYnl0ZSBzZWN0b3IgYW5kIHNhbWUNCj4gPiBp
cyB1c2VkIGluDQo+ID4gZnNsX2lmY19ydW5fY29tbWFuZCgpIGR1cmluZyBFQ0Mgc3RhdHVzIHZl
cmlmaWNhdGlvbi4gQWxzbyB0aGlzIHNlY3Rvcg0KPiA+IGlzIHBhc3NlZCB0byBpc19ibGFuaygp
IGZvciBibGFuayBjaGVja2luZy4gSXQgaXMgd3JvbmcgYXQgZmlyc3QgcGxhY2UNCj4gPiBiZWNh
dXNlIGlzX2JsYW5rKCkncyBpbXBsZW1lbnRhdGlvbiBjaGVja3MgZm9yIFBhZ2Ugc2l6ZSBhbmQg
T09CIGFyZWENCj4gc2l6ZS4NCj4gPiBpc19ibGFuaygpIHNob3VsZCBiZSBjYWxsZWQgcGVyIHBh
Z2UgZm9yIG1haW4gYW5kIE9PQiBhcmVhDQo+IHZlcmlmaWNhdGlvbi4NCj4gPg0KPiA+IFZhcmlh
YmxlcyBuYW1lIGFyZSByZWRlZmluZWQgdG8gYXZvaWQgY29uZnVzaW9uIGJldHdlZW4gYnVmZmVy
IGFuZCBlY2MNCj4gc2VjdG9yLg0KPiA+DQo+ID4gU2lnbmVkLW9mZi1ieTogUG9vbmFtIEFnZ3J3
YWwgPHBvb25hbS5hZ2dyd2FsQGZyZWVzY2FsZS5jb20+DQo+ID4gU2lnbmVkLW9mZi1ieTogU2Nv
dHQgV29vZCA8c2NvdHR3b29kQGZyZWVzY2FsZS5jb20+DQo+ID4gU2lnbmVkLW9mZi1ieTogUHJh
Ymhha2FyIEt1c2h3YWhhIDxwcmFiaGFrYXJAZnJlZXNjYWxlLmNvbT4NCj4gDQo+IFRoZSBkcml2
ZXIgaXMgbm90IGluIDMuMy1yYzEsIHNvIEkgc2tpcCB0aGlzIHBhdGNoLg0KPiANCg0KDQpUaGlz
IHBhdGNoIGlzIHNxdWFzaGVkIGluIExpbnV4IE5BTkQgZHJpdmVyIHBhdGNoLiBJdCB3aWxsIGJl
IHByb3ZpZGVkIGJ5IGdhbGFrJ3MgdHJlZQ0KDQoiTkFORCBNYWNoaW5lIHN1cHBvcnQgZm9yIElu
dGVncmF0ZWQgRmxhc2ggQ29udHJvbGxlciINCmh0dHA6Ly9wYXRjaHdvcmsub3psYWJzLm9yZy9w
YXRjaC8xMzcwMjQvDQoNCi0tUHJhYmhha2FyDQoNCg==
^ permalink raw reply
* Re: [PATCH] mtd/nand:Fix wrong usage of is_blank() in fsl_ifc_run_command
From: Artem Bityutskiy @ 2012-01-27 13:15 UTC (permalink / raw)
To: Prabhakar Kushwaha; +Cc: Scott Wood, linux-mtd, linuxppc-dev, Poonam Aggrwal
In-Reply-To: <1326859991-7469-1-git-send-email-prabhakar@freescale.com>
[-- Attachment #1: Type: text/plain, Size: 816 bytes --]
On Wed, 2012-01-18 at 09:43 +0530, Prabhakar Kushwaha wrote:
> Freescale IFC NAND Machine calculates ECC on 512byte sector and same is used in
> fsl_ifc_run_command() during ECC status verification. Also this sector is passed
> to is_blank() for blank checking. It is wrong at first place because
> is_blank()'s implementation checks for Page size and OOB area size.
> is_blank() should be called per page for main and OOB area verification.
>
> Variables name are redefined to avoid confusion between buffer and ecc sector.
>
> Signed-off-by: Poonam Aggrwal <poonam.aggrwal@freescale.com>
> Signed-off-by: Scott Wood <scottwood@freescale.com>
> Signed-off-by: Prabhakar Kushwaha <prabhakar@freescale.com>
The driver is not in 3.3-rc1, so I skip this patch.
--
Best Regards,
Artem Bityutskiy
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* [PATCH] ALSA: aoa: Convert onyx and tas codec drivers to module_i2c_driver
From: Axel Lin @ 2012-01-27 7:23 UTC (permalink / raw)
To: alsa-devel; +Cc: Takashi Iwai, Johannes Berg, linuxppc-dev, Jaroslav Kysela
This patch converts onyx and tas codec drivers to use the module_i2c_driver()
macro which makes the code smaller and a bit simpler.
Signed-off-by: Axel Lin <axel.lin@gmail.com>
---
sound/aoa/codecs/onyx.c | 13 +------------
sound/aoa/codecs/tas.c | 13 +------------
2 files changed, 2 insertions(+), 24 deletions(-)
diff --git a/sound/aoa/codecs/onyx.c b/sound/aoa/codecs/onyx.c
index 762af68..270790d 100644
--- a/sound/aoa/codecs/onyx.c
+++ b/sound/aoa/codecs/onyx.c
@@ -1132,15 +1132,4 @@ static struct i2c_driver onyx_driver = {
.id_table = onyx_i2c_id,
};
-static int __init onyx_init(void)
-{
- return i2c_add_driver(&onyx_driver);
-}
-
-static void __exit onyx_exit(void)
-{
- i2c_del_driver(&onyx_driver);
-}
-
-module_init(onyx_init);
-module_exit(onyx_exit);
+module_i2c_driver(onyx_driver);
diff --git a/sound/aoa/codecs/tas.c b/sound/aoa/codecs/tas.c
index fd2188c..8e63d1f 100644
--- a/sound/aoa/codecs/tas.c
+++ b/sound/aoa/codecs/tas.c
@@ -1026,15 +1026,4 @@ static struct i2c_driver tas_driver = {
.id_table = tas_i2c_id,
};
-static int __init tas_init(void)
-{
- return i2c_add_driver(&tas_driver);
-}
-
-static void __exit tas_exit(void)
-{
- i2c_del_driver(&tas_driver);
-}
-
-module_init(tas_init);
-module_exit(tas_exit);
+module_i2c_driver(tas_driver);
--
1.7.5.4
^ permalink raw reply related
* Another FSL SPI driver question (warning long post)
From: Bruce_Leonard @ 2012-01-27 6:43 UTC (permalink / raw)
To: linuxppc-dev
Hi Kumar,
I'm using the 3.0.3 kernel on an MPC8308 and utilizing the spi_fsl_spi
driver to talk with an Cypress NvRAM device. I've gotten that working
now, but I've come across something I don't understand in the driver and
I'm not sure if it's just me or if there's a bug. My issue relates to
chip selects, their active state, and their specification in the device
tree (lots of moving parts here, so I hope I describe it well enough to be
understood). The chip select for the NvRAM is active low, but setting
everything up they way I _think_ it should be for an active low signal
gets me an active high signal.
The device tree entry is:
spi@7000 {
#address-cells = <1>;
#size-cells = <0>;
cell-index = <0>;
compatible = "fsl,spi";
reg = <0x7000 0x1000>;
interrupts = <16 0x8>;
interrupt-parent = <&ipic>;
mode = "cpu";
gpios = <&gpio1 16 1>;
nvram@0 {
compatible = "spidev";
spi-max-frequency = <40000000>;
reg = <0>;
};
};
And the relevant driver code is the fsl_spi_chipselect and the
fsl_spi_cs_control functions shown below (line numbers are for reference
only and don't match lines numbers in .../drivers/spi/spi_fsl_spi.c):
1 static void fsl_spi_chipselect(struct spi_device *spi, int value)
2 {
3 struct mpc8xxx_spi *mpc8xxx_spi =
spi_master_get_devdata(spi->master);
4 struct fsl_spi_platform_data *pdata =
spi->dev.parent->platform_data;
5 bool pol = spi->mode & SPI_CS_HIGH;
6 struct spi_mpc8xxx_cs *cs = spi->controller_state;
7
8 if (value == BITBANG_CS_INACTIVE) {
9 if (pdata->cs_control)
10 pdata->cs_control(spi, !pol);
11 }
12
13 if (value == BITBANG_CS_ACTIVE) {
14 mpc8xxx_spi->rx_shift = cs->rx_shift;
15 mpc8xxx_spi->tx_shift = cs->tx_shift;
16 mpc8xxx_spi->get_rx = cs->get_rx;
17 mpc8xxx_spi->get_tx = cs->get_tx;
18
19 fsl_spi_change_mode(spi);
20
21 if (pdata->cs_control)
22 pdata->cs_control(spi, pol);
23 }
24 }
25
26 static void fsl_spi_cs_control(struct spi_device *spi, bool on)
27 {
28 struct device *dev = spi->dev.parent;
29 struct mpc8xxx_spi_probe_info *pinfo =
to_of_pinfo(dev->platform_data);
30 u16 cs = spi->chip_select;
31 int gpio = pinfo->gpios[cs];
32 bool alow = pinfo->alow_flags[cs];
33
34 gpio_set_value(gpio, on ^ alow);
35 }
The variable "pol" comes from spi->mode & SPI_CS_HIGH (line 5) and
spi->mode gets it's value based on the spi-cs-high attribute in the device
tree via .../drivers/of/of_spi.c like this:
if (of_find_property(nc, "spi-cs-high", NULL))
spi->mode |= SPI_CS_HIGH;
In my case I want an active low CS so I don't include this attribute and
spi->mode doesn't get the bit set. "alow" (line 32) ultimately comes from
the flags part of the gpios specifier in the SPI node of my device tree
via the of_fsl_spi_probe function like this:
gpio = of_get_gpio_flags(np, i, &flags); <- flags gets a direct copy of
flags in the gpios specifier
pinfo->alow_flags[i] = flags & OF_GPIO_ACTIVE_LOW;
OF_GPIO_ACTIVE_LOW is an enum with a value of 0x1, implying that a value
of "1" in the flags in my gpios specifier is saying the GPIO signal is
active low. So if my understanding is right, I've got everything set up
in my device tree correctly to have an active low CS.
Now to the crux of the problem, line 34, the gpio_set_value call. When an
SPI transaction is started and the CS needs to be driven to it's active
state (low in my case) fsl_spi_chipselect is called with value =
BITBANG_CS_ACTIVE, which leads to line 22, calling fsl_spi_cs_control with
pol = 0 because spi->mode doesn't have the SPI_CS_HIGH bit set (line 5)
which becomes "on" in fsl_spi_cs_control. alow = 1(line 32) because flags
is 1 in the gpios specifier. "on" = 0 XORed with "alow" = 1 equals 1 when
gpio_set_value is called, setting my chipselect HIGH not low. Then when
the transaction is done fsl_spi_chipselect is called with value =
BITBANG_CS_INACTIVE which leads to line 10 calling fsl_spi_cs_control with
!pol = 1, alow is still a 1 and 1 XOR 1 = 0 when gpio_set_value is called,
setting my chipselect to LOW.
I did an experiment in which I added the spi-cs-high attribute to my
device tree (which should have made the signal active high) and the result
was the signal operated in the opposite way from what the name of the
attribute implies.
So (if my understanding of the device tree entries is correct) the logic
on line 34 appears to be flawed, but since I'm not 100% sure of my
understanding I wanted to ask people smarter than I am.
More over, I don't think I understand why a device tree entry is used to
indicate which state to change the chipselect to. Wouldn't it make more
sense if lines 10 and 22 pass in a "1" for "set the CS to the active
state" and a "0" for "set the CS to the inactive state"? You could even
use the already existing BITBANG_* macros. Something like this:
1 static void fsl_spi_chipselect(struct spi_device *spi, int value)
2 {
3 struct mpc8xxx_spi *mpc8xxx_spi =
spi_master_get_devdata(spi->master);
4 struct fsl_spi_platform_data *pdata =
spi->dev.parent->platform_data;
5 bool pol = spi->mode & SPI_CS_HIGH;
6 struct spi_mpc8xxx_cs *cs = spi->controller_state;
7
8 if (value == BITBANG_CS_INACTIVE) {
9 if (pdata->cs_control)
10 pdata->cs_control(spi, BITBANG_CS_INACTIVE); <--
change
11 }
12
13 if (value == BITBANG_CS_ACTIVE) {
14 mpc8xxx_spi->rx_shift = cs->rx_shift;
15 mpc8xxx_spi->tx_shift = cs->tx_shift;
16 mpc8xxx_spi->get_rx = cs->get_rx;
17 mpc8xxx_spi->get_tx = cs->get_tx;
18
19 fsl_spi_change_mode(spi);
20
21 if (pdata->cs_control)
22 pdata->cs_control(spi, BITBANG_CS_ACTIVE);
<--change
23 }
24 }
25
26 static void fsl_spi_cs_control(struct spi_device *spi, bool on)
27 {
28 struct device *dev = spi->dev.parent;
29 struct mpc8xxx_spi_probe_info *pinfo =
to_of_pinfo(dev->platform_data);
30 u16 cs = spi->chip_select;
31 int gpio = pinfo->gpios[cs];
32 bool alow = pinfo->alow_flags[cs];
33
34 gpio_set_value(gpio, on ^ alow);
35 }
Comments? Am I totally screwed up in my understanding?
Thanks.
Bruce
^ permalink raw reply
* Question about GPIO Lib
From: Bruce_Leonard @ 2012-01-27 4:31 UTC (permalink / raw)
To: linuxppc-dev
(This time with a subject line, sorry)
Hi,
I'm using the 3.0.3 kernel on an MPC8308 and have turned on GPIO support
(CONFIG_GPIOLIB = Y) because the SPI sub-system needed to use it for the
GPIO pin I'm using as a CS to a NvRAM part. I also have some jumpers on
the processor GPIO pins and I thought it would be really slick to use the
built in GPIO support in the kernel rather than roll my own driver to read
five pins. So I've got GPIO sysfs support turned on (CONFIG_GPIO_SYSFS =
Y) and everything shows up in /sys/class/gpio and works as advertised.
Really nice.
The problem is we've got a number of other things hooked up to the GPIO
pins that it would be very bad if someone from user space played with
them, like our FPGA configuration pin. Some one toggles that and our box
goes stupid. So what I'm wondering is if there's a way, preferably via
the device tree, to limit the GPIOs that GPIO Lib exposes to user space?
I tried the following in my device tree without success:
gpio1: gpio@c00 {
#gpio-cells = <2>;
device_type = "gpio";
compatible = "fsl,mpc8308-gpio", "fsl,mpc8349-gpio";
reg = <0xc00 0x18>;
interrupts = <74 0x8>;
interrupt-parent = <&ipic>;
gpio-controller;
gpios = <&gpio1 0 0
&gpio1 1 0
&gpio1 2 0
&gpio1 3 0
&gpio1 4 0
&gpio1 5 0
&gpio1 6 0>;
};
I also thought maybe a separate child node of the gpio1 node, but I think
it would require a "compatible" attribute which would mean a driver to
bind it to, and the whole point is to avoid writing a driver if someone
else has already got something that will work.
Thanks.
Bruce
^ permalink raw reply
* (no subject)
From: Bruce_Leonard @ 2012-01-27 4:29 UTC (permalink / raw)
To: linuxppc-dev
Hi,
I'm using the 3.0.3 kernel on an MPC8308 and have turned on GPIO support
(CONFIG_GPIOLIB = Y) because the SPI sub-system needed to use it for the
GPIO pin I'm using as a CS to a NvRAM part. I also have some jumpers on
the processor GPIO pins and I thought it would be really slick to use the
built in GPIO support in the kernel rather than roll my own driver to read
five pins. So I've got GPIO sysfs support turned on (CONFIG_GPIO_SYSFS =
Y) and everything shows up in /sys/class/gpio and works as advertised.
Really nice.
The problem is we've got a number of other things hooked up to the GPIO
pins that it would be very bad if someone from user space played with
them, like our FPGA configuration pin. Some one toggles that and our box
goes stupid. So what I'm wondering is if there's a way, preferably via
the device tree, to limit the GPIOs that GPIO Lib exposes to user space?
I tried the following in my device tree without success:
gpio1: gpio@c00 {
#gpio-cells = <2>;
device_type = "gpio";
compatible = "fsl,mpc8308-gpio", "fsl,mpc8349-gpio";
reg = <0xc00 0x18>;
interrupts = <74 0x8>;
interrupt-parent = <&ipic>;
gpio-controller;
gpios = <&gpio1 0 0
&gpio1 1 0
&gpio1 2 0
&gpio1 3 0
&gpio1 4 0
&gpio1 5 0
&gpio1 6 0>;
};
I also thought maybe a separate child node of the gpio1 node, but I think
it would require a "compatible" attribute which would mean a driver to
bind it to, and the whole point is to avoid writing a driver if someone
else has already got something that will work.
Thanks.
Bruce
^ permalink raw reply
* Re: tlb flushing on Power
From: Benjamin Herrenschmidt @ 2012-01-27 2:40 UTC (permalink / raw)
To: Dave Hansen; +Cc: Brian King, Seth Jennings, Robert Jennings, linuxppc-dev
In-Reply-To: <4F21D3F4.7020904@linux.vnet.ibm.com>
On Thu, 2012-01-26 at 14:30 -0800, Dave Hansen wrote:
> On 01/26/2012 01:39 PM, Benjamin Herrenschmidt wrote:
> > Can you explain to me a bit more the whole business in this patch set
> > about doing kmap_atomic() vs. manually trying to populate the PTEs ?
>
> They're compressing pages and the allocator is trying getting very poor
> packing of compressed pages in to PAGE_SIZE chunks. So, they're moving
> to 2-page allocations that they need to be mapped contiguously to make
> it easier on the users of the allocator.
>
> > Why not just use two kmap atomic entries ? If interrupts are disabled
> > kmap_atomic() should give you contiguous ones I suppose
>
> I think you and I are at least on the same page on this one:
>
> https://lkml.org/lkml/2012/1/26/355
Right. We probably want to document this somewhere if we start relying
on that behaviour or at the very least add a WARN_ON() and fail from the
compressed allocator if we end up with non-contiguous pages.
> > (unless NMIs are allowed to use kmap_atomic, are they ?)
>
> Surely they can't be. Even if they could use it, they'd have to return
> the __kmap_atomic_idx back to the place where it started before they
> returned, so the interrupted code wouldn't notice.
Ah indeed, that's for talking before I had breakfast :-)
Cheers,
Ben.
^ permalink raw reply
* Re: tlb flushing on Power
From: Dave Hansen @ 2012-01-26 22:30 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Brian King, Seth Jennings, Robert Jennings, linuxppc-dev
In-Reply-To: <1327613953.24487.9.camel@pasglop>
On 01/26/2012 01:39 PM, Benjamin Herrenschmidt wrote:
> Can you explain to me a bit more the whole business in this patch set
> about doing kmap_atomic() vs. manually trying to populate the PTEs ?
They're compressing pages and the allocator is trying getting very poor
packing of compressed pages in to PAGE_SIZE chunks. So, they're moving
to 2-page allocations that they need to be mapped contiguously to make
it easier on the users of the allocator.
> Why not just use two kmap atomic entries ? If interrupts are disabled
> kmap_atomic() should give you contiguous ones I suppose
I think you and I are at least on the same page on this one:
https://lkml.org/lkml/2012/1/26/355
> (unless NMIs are allowed to use kmap_atomic, are they ?)
Surely they can't be. Even if they could use it, they'd have to return
the __kmap_atomic_idx back to the place where it started before they
returned, so the interrupted code wouldn't notice.
^ permalink raw reply
* Re: tlb flushing on Power
From: Benjamin Herrenschmidt @ 2012-01-26 21:39 UTC (permalink / raw)
To: Brian King; +Cc: Seth Jennings, Robert Jennings, linuxppc-dev, Dave Hansen
In-Reply-To: <4F216620.2010509@linux.vnet.ibm.com>
On Thu, 2012-01-26 at 08:41 -0600, Brian King wrote:
> CC'ing linuxppc-dev...
>
>
> On 01/26/2012 08:18 AM, Seth Jennings wrote:
> > Hey Dave,
> >
> > So I submitted the zsmalloc patches to lkml at the beginning
> > of the year
> >
> > https://lkml.org/lkml/2012/1/9/389
> >
> > I found there are two functions Nitin used in the mapping
> > functions that are not supported in the powerpc arch:
> > set_pte() and __flush_tlb_one().
.../...
The arch management of page tables can be tricky indeed :-) I need to
have a better understanding of what you are doing to see how I can try
to adapt it to power.
set_pte() is long gone on all archs really (or if it's still there it's
not meant to be used as is), use set_pte_at().
__flush_tlb_one() doesn't mean anything as an arch independent
functionality. We have a local_flush_tlb_page() that -might- do what you
want but why in hell is that patch not using proper existing
interfaces ?
Can you explain to me a bit more the whole business in this patch set
about doing kmap_atomic() vs. manually trying to populate the PTEs ? Why
not just use two kmap atomic entries ? If interrupts are disabled
kmap_atomic() should give you contiguous ones I suppose (unless NMIs are
allowed to use kmap_atomic, are they ?)
Cheers,
Ben.
^ permalink raw reply
* [RFC] dmaengine/dma_slave: add context parameter to prep_slave_sg callback
From: Alexandre Bounine @ 2012-01-26 21:22 UTC (permalink / raw)
To: akpm, linux-kernel, linuxppc-dev, vinod.koul, dan.j.williams
Cc: Jassi Brar, Alexandre Bounine, Russell King
As we agreed during our discussion about adding DMA Engine support for RapidIO
subsystem, RapidIO and similar clients may benefit from adding an extra context
parameter to device_prep_slave_sg() callback.
See https://lkml.org/lkml/2011/10/24/275 for more details.
Adding the context parameter will allow to pass client/target specific
information associated with an individual data transfer request.
In the case of RapidIO support this additional information consists of target
destination ID and its buffer address (which is not mapped into the local CPU
memory space). Because a single RapidIO-capable DMA channel may queue data
transfer requests to different target devices, the per-request configuration
is required.
The proposed change eliminates need for new subsystem-specific API.
Existing DMA_SLAVE clients will ignore the new parameter.
This RFC only demonstrates the API change and does not include corresponding
changes to existing DMA_SLAVE clients. Complete set of patches will be provided
after (if) this API change is accepted.
Signed-off-by: Alexandre Bounine <alexandre.bounine@idt.com>
Cc: Jassi Brar <jaswinder.singh@linaro.org>
Cc: Russell King <rmk@arm.linux.org.uk>
Cc: Kumar Gala <galak@kernel.crashing.org>
Cc: Matt Porter <mporter@kernel.crashing.org>
Cc: Li Yang <leoli@freescale.com>
---
include/linux/dmaengine.h | 7 ++++---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
index 679b349..79d71bb 100644
--- a/include/linux/dmaengine.h
+++ b/include/linux/dmaengine.h
@@ -575,7 +575,7 @@ struct dma_device {
struct dma_async_tx_descriptor *(*device_prep_slave_sg)(
struct dma_chan *chan, struct scatterlist *sgl,
unsigned int sg_len, enum dma_transfer_direction direction,
- unsigned long flags);
+ unsigned long flags, void *context);
struct dma_async_tx_descriptor *(*device_prep_dma_cyclic)(
struct dma_chan *chan, dma_addr_t buf_addr, size_t buf_len,
size_t period_len, enum dma_transfer_direction direction);
@@ -607,12 +607,13 @@ static inline int dmaengine_slave_config(struct dma_chan *chan,
static inline struct dma_async_tx_descriptor *dmaengine_prep_slave_single(
struct dma_chan *chan, void *buf, size_t len,
- enum dma_transfer_direction dir, unsigned long flags)
+ enum dma_transfer_direction dir, unsigned long flags, void *context)
{
struct scatterlist sg;
sg_init_one(&sg, buf, len);
- return chan->device->device_prep_slave_sg(chan, &sg, 1, dir, flags);
+ return chan->device->device_prep_slave_sg(chan, &sg, 1, dir, flags,
+ context);
}
static inline int dmaengine_terminate_all(struct dma_chan *chan)
--
1.7.8.4
^ permalink raw reply related
* Re: [RFCv2 00/14]
From: Grant Likely @ 2012-01-26 21:33 UTC (permalink / raw)
To: Rob Herring
Cc: Cousson, Benoit, devicetree-discuss, linux-kernel, Milton Miller,
Shawn Guo, linuxppc-dev
In-Reply-To: <4F204F1C.70908@gmail.com>
On Wed, Jan 25, 2012 at 11:51 AM, Rob Herring <robherring2@gmail.com> wrote=
:
> On 01/25/2012 08:13 AM, Cousson, Benoit wrote:
>> On 1/23/2012 10:53 PM, Rob Herring wrote:
>>> On 01/23/2012 03:07 PM, Grant Likely wrote:
>>>>
>>>> Hey everyone,
>>>>
>>>> Here's the second RFC for the irq_domain patches. =A0I could use some
>>>> help testing now. =A0I still expect there will be a few bugs. =A0The
>>>> series is based on v3.3-rc1, and I've pushed it out to my git server:
>>>>
>>>> git://git.secretlab.ca/git/linux-2.6.git irqdomain/next
>>>
>>> Can you post to linux-arm-kernel too so people are aware of this work
>>> and stop posting dead-end irqdomain patches.
>>
>> Good point, I have two pending series that are using the
>> irq_domain_add() so far, so it will be good to have that branch pulled
>> in arm-soc.
>>
>>> I tested what you had as of this morning and it works fine for me. Look=
s
>>> like the only diff is the VExpress code. I'm working on rebasing my
>>> domain support for generic irqchip now.
>>
>> In fact your generic irqchip should even avoid us to use
>> irq_domain_add_legacy() since both GPIO and OMAP3 intc are already using
>> the irqchip.
>>
>> I guess you are not going to change the interface so the patches I did
>> on your previous branch to try them should be good already, isn't it?
>
> I've got it rebased on top of Grant's tree. I will send it out soon.
>
> One problem that still remains is it breaks x86 and any platform using
> generic irq chip, but not selecting IRQ_DOMAIN. Grant, do you plan to
> enable IRQ_DOMAIN for x86 in your series? MIPS may also need fixing.
I've got the x86 fix in my tree now. It will be part of the next
merge. MIPS, Microblaze and OpenRISC cannot turn on CONFIG_IRQ_DOMAIN
without rework. I just hacked together the microblaze version, but
Michal will have to verify that it is correct. I just posted it. It
will be similar for the other two.
The real problem is sparc which does something entirely different for
irqs. Rather than resolving irqs on-demand, it calculates the Linux
irq numbers at boot time for every node in the tree. The irq_domains
will need to be set up for all interrupt controllers before sparc
begins it's big walk of the tree to resolve interrupts. I haven't dug
into everything that needs to be done to support this.
I don't think you can count on turning on IRQ_DOMAIN on all
architectures just yet. Adding irq_domain support directly to
irq_generic_chip is going to be difficult for that reason. However,
it would be useful to have an irq_domain+irq_generic_chip wrapper that
can be enabled only when IRQ_DOMAIN is enabled.
g.
^ permalink raw reply
* Re: [PATCH 1/1] carma-fpga: fix race between data dumping and DMA callback
From: Benjamin Herrenschmidt @ 2012-01-26 21:25 UTC (permalink / raw)
To: Ira W. Snyder; +Cc: linuxppc-dev
In-Reply-To: <1327611614-18508-1-git-send-email-iws@ovro.caltech.edu>
On Thu, 2012-01-26 at 13:00 -0800, Ira W. Snyder wrote:
>
> @@ -970,7 +984,13 @@ static ssize_t data_en_show(struct device *dev, struct device_attribute *attr,
> char *buf)
> {
> struct fpga_device *priv = dev_get_drvdata(dev);
> - return snprintf(buf, PAGE_SIZE, "%u\n", priv->enabled);
> + int ret;
> +
> + spin_lock_irq(&priv->lock);
> + ret = snprintf(buf, PAGE_SIZE, "%u\n", priv->enabled);
> + spin_unlock_irq(&priv->lock);
> +
> + return ret;
> }
I don't think the lock buys you anything here.
Cheers,
Ben.
^ permalink raw reply
* [PATCH 1/1] carma-fpga: fix race between data dumping and DMA callback
From: Ira W. Snyder @ 2012-01-26 21:00 UTC (permalink / raw)
To: linuxppc-dev
When the system is under heavy load, we occasionally saw a problem where
the system would get a legitimate interrupt when they should be
disabled.
This was caused by the data_dma_cb() DMA callback unconditionally
re-enabling FPGA interrupts even when data dumping is disabled. When
data dumping was re-enabled, the irq handler would fire while a DMA was
in progress. The "BUG_ON(priv->inflight != NULL);" during the second
invocation of the DMA callback caused the system to crash.
To fix the issue, the priv->enabled boolean is moved under the
protection of the priv->lock spinlock. The DMA callback checks the
boolean to know whether to re-enable FPGA interrupts before it returns.
Now that it is fixed, the driver keeps FPGA interrupts disabled when it
expects that they are disabled, fixing the bug.
Signed-off-by: Ira W. Snyder <iws@ovro.caltech.edu>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
drivers/misc/carma/carma-fpga.c | 101 +++++++++++++++++++++++---------------
1 files changed, 61 insertions(+), 40 deletions(-)
diff --git a/drivers/misc/carma/carma-fpga.c b/drivers/misc/carma/carma-fpga.c
index 4fd896d..0cfc5bf 100644
--- a/drivers/misc/carma/carma-fpga.c
+++ b/drivers/misc/carma/carma-fpga.c
@@ -560,6 +560,9 @@ static void data_enable_interrupts(struct fpga_device *priv)
/* flush the writes */
fpga_read_reg(priv, 0, MMAP_REG_STATUS);
+ fpga_read_reg(priv, 1, MMAP_REG_STATUS);
+ fpga_read_reg(priv, 2, MMAP_REG_STATUS);
+ fpga_read_reg(priv, 3, MMAP_REG_STATUS);
/* switch back to the external interrupt source */
iowrite32be(0x3F, priv->regs + SYS_IRQ_SOURCE_CTL);
@@ -591,8 +594,12 @@ static void data_dma_cb(void *data)
list_move_tail(&priv->inflight->entry, &priv->used);
priv->inflight = NULL;
- /* clear the FPGA status and re-enable interrupts */
- data_enable_interrupts(priv);
+ /*
+ * If data dumping is still enabled, then clear the FPGA
+ * status registers and re-enable FPGA interrupts
+ */
+ if (priv->enabled)
+ data_enable_interrupts(priv);
spin_unlock_irqrestore(&priv->lock, flags);
@@ -708,6 +715,15 @@ static irqreturn_t data_irq(int irq, void *dev_id)
spin_lock(&priv->lock);
+ /*
+ * This is an error case that should never happen.
+ *
+ * If this driver has a bug and manages to re-enable interrupts while
+ * a DMA is in progress, then we will hit this statement and should
+ * start paying attention immediately.
+ */
+ BUG_ON(priv->inflight != NULL);
+
/* hide the interrupt by switching the IRQ driver to GPIO */
data_disable_interrupts(priv);
@@ -762,11 +778,15 @@ out:
*/
static int data_device_enable(struct fpga_device *priv)
{
+ bool enabled;
u32 val;
int ret;
/* multiple enables are safe: they do nothing */
- if (priv->enabled)
+ spin_lock_irq(&priv->lock);
+ enabled = priv->enabled;
+ spin_unlock_irq(&priv->lock);
+ if (enabled)
return 0;
/* check that the FPGAs are programmed */
@@ -797,6 +817,9 @@ static int data_device_enable(struct fpga_device *priv)
goto out_error;
}
+ /* prevent the FPGAs from generating interrupts */
+ data_disable_interrupts(priv);
+
/* hookup the irq handler */
ret = request_irq(priv->irq, data_irq, IRQF_SHARED, drv_name, priv);
if (ret) {
@@ -804,11 +827,13 @@ static int data_device_enable(struct fpga_device *priv)
goto out_error;
}
- /* switch to the external FPGA IRQ line */
- data_enable_interrupts(priv);
-
- /* success, we're enabled */
+ /* allow the DMA callback to re-enable FPGA interrupts */
+ spin_lock_irq(&priv->lock);
priv->enabled = true;
+ spin_unlock_irq(&priv->lock);
+
+ /* allow the FPGAs to generate interrupts */
+ data_enable_interrupts(priv);
return 0;
out_error:
@@ -834,41 +859,40 @@ out_error:
*/
static int data_device_disable(struct fpga_device *priv)
{
- int ret;
+ spin_lock_irq(&priv->lock);
/* allow multiple disable */
- if (!priv->enabled)
+ if (!priv->enabled) {
+ spin_unlock_irq(&priv->lock);
return 0;
+ }
+
+ /*
+ * Mark the device disabled
+ *
+ * This stops DMA callbacks from re-enabling interrupts
+ */
+ priv->enabled = false;
- /* switch to the internal GPIO IRQ line */
+ /* prevent the FPGAs from generating interrupts */
data_disable_interrupts(priv);
+ /* wait until all ongoing DMA has finished */
+ while (priv->inflight != NULL) {
+ spin_unlock_irq(&priv->lock);
+ wait_event(priv->wait, priv->inflight == NULL);
+ spin_lock_irq(&priv->lock);
+ }
+
+ spin_unlock_irq(&priv->lock);
+
/* unhook the irq handler */
free_irq(priv->irq, priv);
- /*
- * wait for all outstanding DMA to complete
- *
- * Device interrupts are disabled, therefore another buffer cannot
- * be marked inflight.
- */
- ret = wait_event_interruptible(priv->wait, priv->inflight == NULL);
- if (ret)
- return ret;
-
/* free the correlation table */
sg_free_table(&priv->corl_table);
priv->corl_nents = 0;
- /*
- * We are taking the spinlock not to protect priv->enabled, but instead
- * to make sure that there are no readers in the process of altering
- * the free or used lists while we are setting this flag.
- */
- spin_lock_irq(&priv->lock);
- priv->enabled = false;
- spin_unlock_irq(&priv->lock);
-
/* free all buffers: the free and used lists are not being changed */
data_free_buffers(priv);
return 0;
@@ -896,15 +920,6 @@ static unsigned int list_num_entries(struct list_head *list)
static int data_debug_show(struct seq_file *f, void *offset)
{
struct fpga_device *priv = f->private;
- int ret;
-
- /*
- * Lock the mutex first, so that we get an accurate value for enable
- * Lock the spinlock next, to get accurate list counts
- */
- ret = mutex_lock_interruptible(&priv->mutex);
- if (ret)
- return ret;
spin_lock_irq(&priv->lock);
@@ -917,7 +932,6 @@ static int data_debug_show(struct seq_file *f, void *offset)
seq_printf(f, "num_dropped: %d\n", priv->num_dropped);
spin_unlock_irq(&priv->lock);
- mutex_unlock(&priv->mutex);
return 0;
}
@@ -970,7 +984,13 @@ static ssize_t data_en_show(struct device *dev, struct device_attribute *attr,
char *buf)
{
struct fpga_device *priv = dev_get_drvdata(dev);
- return snprintf(buf, PAGE_SIZE, "%u\n", priv->enabled);
+ int ret;
+
+ spin_lock_irq(&priv->lock);
+ ret = snprintf(buf, PAGE_SIZE, "%u\n", priv->enabled);
+ spin_unlock_irq(&priv->lock);
+
+ return ret;
}
static ssize_t data_en_set(struct device *dev, struct device_attribute *attr,
@@ -986,6 +1006,7 @@ static ssize_t data_en_set(struct device *dev, struct device_attribute *attr,
return -EINVAL;
}
+ /* protect against concurrent enable/disable */
ret = mutex_lock_interruptible(&priv->mutex);
if (ret)
return ret;
--
1.7.3.4
^ permalink raw reply related
* [PATCH 1/1] carma-fpga: fix lockdep warning
From: Ira W. Snyder @ 2012-01-26 20:59 UTC (permalink / raw)
To: linuxppc-dev
Lockdep occasionally complains with the message:
INFO: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected
This is caused by calling videobuf_dma_unmap() under spin_lock_irq(). To
fix the warning, we drop the lock before unmapping and freeing the
buffer.
Signed-off-by: Ira W. Snyder <iws@ovro.caltech.edu>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
drivers/misc/carma/carma-fpga.c | 13 +++++++++++--
1 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/misc/carma/carma-fpga.c b/drivers/misc/carma/carma-fpga.c
index 14e974b2..4fd896d 100644
--- a/drivers/misc/carma/carma-fpga.c
+++ b/drivers/misc/carma/carma-fpga.c
@@ -1079,6 +1079,7 @@ static ssize_t data_read(struct file *filp, char __user *ubuf, size_t count,
struct fpga_reader *reader = filp->private_data;
struct fpga_device *priv = reader->priv;
struct list_head *used = &priv->used;
+ bool drop_buffer = false;
struct data_buf *dbuf;
size_t avail;
void *data;
@@ -1166,10 +1167,12 @@ have_buffer:
* One of two things has happened, the device is disabled, or the
* device has been reconfigured underneath us. In either case, we
* should just throw away the buffer.
+ *
+ * Lockdep complains if this is done under the spinlock, so we
+ * handle it during the unlock path.
*/
if (!priv->enabled || dbuf->size != priv->bufsize) {
- videobuf_dma_unmap(priv->dev, &dbuf->vb);
- data_free_buffer(dbuf);
+ drop_buffer = true;
goto out_unlock;
}
@@ -1178,6 +1181,12 @@ have_buffer:
out_unlock:
spin_unlock_irq(&priv->lock);
+
+ if (drop_buffer) {
+ videobuf_dma_unmap(priv->dev, &dbuf->vb);
+ data_free_buffer(dbuf);
+ }
+
return count;
}
--
1.7.3.4
^ permalink raw reply related
* [PATCH 1/1] fsldma: ignore end of segments interrupt
From: Ira W. Snyder @ 2012-01-26 20:58 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Dan Williams
The mpc8349ea has been observed to generate spurious end of segments
interrupts despite the fact that they are not enabled by this driver.
Check for them and ignore them to avoid a kernel error message.
Signed-off-by: Ira W. Snyder <iws@ovro.caltech.edu>
Cc: Dan Williams <dan.j.williams@intel.com>
---
drivers/dma/fsldma.c | 10 ++++++++++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
index 8a78154..7dc9689 100644
--- a/drivers/dma/fsldma.c
+++ b/drivers/dma/fsldma.c
@@ -1052,6 +1052,16 @@ static irqreturn_t fsldma_chan_irq(int irq, void *data)
stat &= ~FSL_DMA_SR_EOLNI;
}
+ /*
+ * This driver does not use this feature, therefore we shouldn't
+ * ever see this bit set in the status register. However, it has
+ * been observed on MPC8349EA parts.
+ */
+ if (stat & FSL_DMA_SR_EOSI) {
+ chan_dbg(chan, "irq: End-of-Segments INT\n");
+ stat &= ~FSL_DMA_SR_EOSI;
+ }
+
/* check that the DMA controller is really idle */
if (!dma_is_idle(chan))
chan_err(chan, "irq: controller not idle!\n");
--
1.7.3.4
^ permalink raw reply related
* Re: FSL SPI driver question
From: Bruce_Leonard @ 2012-01-26 19:49 UTC (permalink / raw)
To: Norbert van Bolhuis; +Cc: linuxppc-dev
In-Reply-To: <4F216C25.6000303@aimvalley.nl>
Norbert,
>
> ok, then I don't know.
>
> I doubt this is a spidev or FSP SPI driver problem though.
>
> Questions like:
>
> Could it be a HW problem ?
> Is the correct SPI mode used ?
> Does it work in u-boot ?
>
> Come to mind in a situation like this.
>
Thanks for the suggestions. I finally found it in the wee hours this
morning, and it was operator error. The CY14 by default powers up in the
write protect state and from the factory is erased to all zeros. So my
writes and subsequent reads appeared to fail by the "fact" that I could
never read what I wrote. Guess I need better reading glasses in my old
age :-/
Anyway, I'm happily up and talking using the Freescale SPI driver and
spidev. Thanks for the help and sorry for the noise on the list.
Bruce
^ permalink raw reply
* Re: [RFC 1/2] irq_domain: Create common xlate functions that device drivers can use
From: Grant Likely @ 2012-01-26 18:15 UTC (permalink / raw)
To: Rob Herring; +Cc: linuxppc-dev, linux-kernel, linux-arm-kernel
In-Reply-To: <4F216819.7030106@gmail.com>
On Thu, Jan 26, 2012 at 7:50 AM, Rob Herring <robherring2@gmail.com> wrote:
> On 01/25/2012 11:59 AM, Grant Likely wrote:
>> On Tue, Jan 24, 2012 at 10:35 PM, Grant Likely
>> <grant.likely@secretlab.ca> wrote:
>>> On Tue, Jan 24, 2012 at 6:50 PM, Rob Herring <robherring2@gmail.com> wr=
ote:
>>>>
>>>>
>>>> On 01/24/2012 06:18 PM, Grant Likely wrote:
>>>>> Rather than having each interrupt controller driver creating its own =
barely
>>>>> unique .xlate function for irq_domain, create a library of translator=
s which
>>>>> any driver can use directly.
>>>>>
>>>>> diff --git a/include/linux/irqdomain.h b/include/linux/irqdomain.h
>>>>> index e7379a3..5e497a0 100644
>>>>> --- a/include/linux/irqdomain.h
>>>>> +++ b/include/linux/irqdomain.h
>>>>> @@ -110,6 +110,9 @@ struct irq_domain {
>>>>> =A0 =A0 =A0 void *host_data;
>>>>> =A0 =A0 =A0 irq_hw_number_t inval_irq;
>>>>>
>>>>> + =A0 =A0 /* Data for common irq xlate functions */
>>>>> + =A0 =A0 unsigned int xlate_type;
>>>>> +
>>>>
>>>> How does this get set? Do we want interrupt controllers messing with t=
he
>>>> domain struct directly long term?
>>>
>>> It defaults to IRQ_TYPE_NONE in the alloc function and drivers can
>>> override it. =A0Alternately it could be made part of the
>>> irq_domain_add() arguments, but I'm not thrilled with adding a whole
>>> bunch of arguments to the function prototype.
>>
>> Do you like this better (built on top of this patch)?
>
> Yes, I think it's better.
I've changed my mind on this after looking at the generated code.
These functions are so simple that it actually is larger (both in
source and object size) to call out to a common function. I've gone
back to each _xlate_*() function open coding the two assignments.
g.
>
>> diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
>> index ef2b1fe..7856c04 100644
>> --- a/kernel/irq/irqdomain.c
>> +++ b/kernel/irq/irqdomain.c
>> @@ -701,12 +701,10 @@ int irq_domain_xlate_onecell(struct irq_domain
>> *d, struct device_node *ctrlr,
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0const u32 *intspe=
c, unsigned int intsize,
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0unsigned long *ou=
t_hwirq, unsigned int *out_type)
>> =A0{
>> - =A0 =A0 if (WARN(intsize < 1, "Bad intspec for %s: intsize=3D%i < 1\n"=
,
>> - =A0 =A0 =A0 =A0 =A0 =A0 =A0ctrlr->full_name, intsize))
>> + =A0 =A0 if (WARN_ON(intsize < 1))
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 return -EINVAL;
>> - =A0 =A0 *out_hwirq =3D intspec[0];
>> - =A0 =A0 *out_type =3D d->xlate_type;
>> - =A0 =A0 return 0;
>> + =A0 =A0 return irq_domain_xlate_onetwocell(d, ctrlr, intspec, 1,
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0out_hwirq, out_type);
>> =A0}
>> =A0EXPORT_SYMBOL_GPL(irq_domain_xlate_onecell);
>>
>> @@ -721,12 +719,10 @@ int irq_domain_xlate_twocell(struct irq_domain
>> *d, struct device_node *ctrlr,
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 const u32 *intspec, unsigned=
int intsize,
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 irq_hw_number_t *out_hwirq, =
unsigned int *out_type)
>> =A0{
>> - =A0 =A0 if (WARN(intsize < 2, "Bad intspec for %s: intsize=3D%i < 2\n"=
,
>> - =A0 =A0 =A0 =A0 =A0 =A0 =A0ctrlr->full_name, intsize))
>> + =A0 =A0 if (WARN_ON(intsize < 2))
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 return -EINVAL;
>> - =A0 =A0 *out_hwirq =3D intspec[0];
>> - =A0 =A0 *out_type =3D intspec[1] & IRQ_TYPE_SENSE_MASK;
>> - =A0 =A0 return 0;
>> + =A0 =A0 return irq_domain_xlate_onetwocell(d, ctrlr, intspec, intsize,
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0out_hwirq, out_type);
>> =A0}
>> =A0EXPORT_SYMBOL_GPL(irq_domain_xlate_twocell);
>>
>> @@ -746,8 +742,7 @@ int irq_domain_xlate_onetwocell(struct irq_domain *d=
,
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 const u32 *i=
ntspec, unsigned int intsize,
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 unsigned lon=
g *out_hwirq, unsigned int *out_type)
>> =A0{
>> - =A0 =A0 if (WARN(intsize < 1, "Bad intspec for %s: intsize=3D%i < 1\n"=
,
>> - =A0 =A0 =A0 =A0 =A0 =A0 =A0ctrlr->full_name, intsize))
>> + =A0 =A0 if (WARN_ON(intsize < 1))
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 return -EINVAL;
>> =A0 =A0 =A0 *out_hwirq =3D intspec[0];
>> =A0 =A0 =A0 *out_type =3D d->xlate_type;
>
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: FSL SPI driver question
From: Norbert van Bolhuis @ 2012-01-26 15:07 UTC (permalink / raw)
To: Bruce_Leonard; +Cc: linuxppc-dev
In-Reply-To: <OF248EC14B.3E5BA3A6-ON88257990.006C779B-88257990.006CE971@selinc.com>
Hi Bruce,
On 01/25/12 20:49, Bruce_Leonard@selinc.com wrote:
.
.
.
> Thanks for the reply. Yes I did find spidev_fdx.c and in fact copied it
> for my tests. I still see SPICLK active only during the time the 8308 is
> sending data (read cmd + address). Nothing happens with the clock after
> that when the NvRAM is ready to send data.
>
> Bruce
>
ok, then I don't know.
I doubt this is a spidev or FSP SPI driver problem though.
Questions like:
Could it be a HW problem ?
Is the correct SPI mode used ?
Does it work in u-boot ?
Come to mind in a situation like this.
Norbert.
^ permalink raw reply
* Re: [RFC 1/2] irq_domain: Create common xlate functions that device drivers can use
From: Rob Herring @ 2012-01-26 14:50 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, linux-kernel, linux-arm-kernel
In-Reply-To: <CACxGe6tgGqQSThzVVEzwOdtYkjKHT1uQhZBOkCTwkutyKXDCAg@mail.gmail.com>
On 01/25/2012 11:59 AM, Grant Likely wrote:
> On Tue, Jan 24, 2012 at 10:35 PM, Grant Likely
> <grant.likely@secretlab.ca> wrote:
>> On Tue, Jan 24, 2012 at 6:50 PM, Rob Herring <robherring2@gmail.com> wrote:
>>>
>>>
>>> On 01/24/2012 06:18 PM, Grant Likely wrote:
>>>> Rather than having each interrupt controller driver creating its own barely
>>>> unique .xlate function for irq_domain, create a library of translators which
>>>> any driver can use directly.
>>>>
>>>> diff --git a/include/linux/irqdomain.h b/include/linux/irqdomain.h
>>>> index e7379a3..5e497a0 100644
>>>> --- a/include/linux/irqdomain.h
>>>> +++ b/include/linux/irqdomain.h
>>>> @@ -110,6 +110,9 @@ struct irq_domain {
>>>> void *host_data;
>>>> irq_hw_number_t inval_irq;
>>>>
>>>> + /* Data for common irq xlate functions */
>>>> + unsigned int xlate_type;
>>>> +
>>>
>>> How does this get set? Do we want interrupt controllers messing with the
>>> domain struct directly long term?
>>
>> It defaults to IRQ_TYPE_NONE in the alloc function and drivers can
>> override it. Alternately it could be made part of the
>> irq_domain_add() arguments, but I'm not thrilled with adding a whole
>> bunch of arguments to the function prototype.
>
> Do you like this better (built on top of this patch)?
Yes, I think it's better.
> diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
> index ef2b1fe..7856c04 100644
> --- a/kernel/irq/irqdomain.c
> +++ b/kernel/irq/irqdomain.c
> @@ -701,12 +701,10 @@ int irq_domain_xlate_onecell(struct irq_domain
> *d, struct device_node *ctrlr,
> const u32 *intspec, unsigned int intsize,
> unsigned long *out_hwirq, unsigned int *out_type)
> {
> - if (WARN(intsize < 1, "Bad intspec for %s: intsize=%i < 1\n",
> - ctrlr->full_name, intsize))
> + if (WARN_ON(intsize < 1))
> return -EINVAL;
> - *out_hwirq = intspec[0];
> - *out_type = d->xlate_type;
> - return 0;
> + return irq_domain_xlate_onetwocell(d, ctrlr, intspec, 1,
> + out_hwirq, out_type);
> }
> EXPORT_SYMBOL_GPL(irq_domain_xlate_onecell);
>
> @@ -721,12 +719,10 @@ int irq_domain_xlate_twocell(struct irq_domain
> *d, struct device_node *ctrlr,
> const u32 *intspec, unsigned int intsize,
> irq_hw_number_t *out_hwirq, unsigned int *out_type)
> {
> - if (WARN(intsize < 2, "Bad intspec for %s: intsize=%i < 2\n",
> - ctrlr->full_name, intsize))
> + if (WARN_ON(intsize < 2))
> return -EINVAL;
> - *out_hwirq = intspec[0];
> - *out_type = intspec[1] & IRQ_TYPE_SENSE_MASK;
> - return 0;
> + return irq_domain_xlate_onetwocell(d, ctrlr, intspec, intsize,
> + out_hwirq, out_type);
> }
> EXPORT_SYMBOL_GPL(irq_domain_xlate_twocell);
>
> @@ -746,8 +742,7 @@ int irq_domain_xlate_onetwocell(struct irq_domain *d,
> const u32 *intspec, unsigned int intsize,
> unsigned long *out_hwirq, unsigned int *out_type)
> {
> - if (WARN(intsize < 1, "Bad intspec for %s: intsize=%i < 1\n",
> - ctrlr->full_name, intsize))
> + if (WARN_ON(intsize < 1))
> return -EINVAL;
> *out_hwirq = intspec[0];
> *out_type = d->xlate_type;
^ permalink raw reply
* Re: tlb flushing on Power
From: Brian King @ 2012-01-26 14:41 UTC (permalink / raw)
To: Seth Jennings; +Cc: Robert Jennings, linuxppc-dev, Dave Hansen
In-Reply-To: <4F2160B3.60708@linux.vnet.ibm.com>
CC'ing linuxppc-dev...
On 01/26/2012 08:18 AM, Seth Jennings wrote:
> Hey Dave,
>
> So I submitted the zsmalloc patches to lkml at the beginning
> of the year
>
> https://lkml.org/lkml/2012/1/9/389
>
> I found there are two functions Nitin used in the mapping
> functions that are not supported in the powerpc arch:
> set_pte() and __flush_tlb_one().
>
> set_pte() seems straightforward for the ppc64 case, although
> I think Power does some sort of pte hashing that might convolute
> it a little.
>
> My real question is how to achieve the function of __flush_tlb_one()
> on Power. I looked in Docuemntation/cachetlb.txt and it seems like
> the portable tlb flush functions are:
>
> void flush_tlb_all(void)
> void flush_tlb_mm(struct mm_struct *mm)
> void flush_tlb_range(struct vm_area_struct *vma,
> unsigned long start, unsigned long end)
> void flush_tlb_page(struct vm_area_struct *vma, unsigned long addr)
>
> Of those options, flush_tlb_page() seems the closest to what
> __flush_tlb_one() does. However, we don't have a vma argument in
> our context (akaik) to send to it.
>
> I was wondering if you have any ideas. Any help is greatly appreciated!
>
> --
> Seth
--
Brian King
Linux on Power Virtualization
IBM Linux Technology Center
^ permalink raw reply
* Re: [RFCv2 00/14]
From: Grant Likely @ 2012-01-26 13:38 UTC (permalink / raw)
To: Mark Salter
Cc: devicetree-discuss, linux-kernel, Milton Miller, Rob Herring,
linuxppc-dev
In-Reply-To: <1327532011.24169.6.camel@deneb.redhat.com>
On Wed, Jan 25, 2012 at 3:53 PM, Mark Salter <msalter@redhat.com> wrote:
> On Mon, 2012-01-23 at 14:07 -0700, Grant Likely wrote:
>> Hey everyone,
>>
>> Here's the second RFC for the irq_domain patches. =A0I could use some
>> help testing now. =A0I still expect there will be a few bugs. =A0The
>> series is based on v3.3-rc1, and I've pushed it out to my git server:
>
> Hi Grant,
>
> I converted arch/c6x over to the generic irq_domain support and have not
> had any problems in testing. The c6x virtual irq support was a nearly
> identical copy of the powerpc code, so the patch I ended up with mostly
> copied what you did in arch/powerpc. The c6x patch is on the tip of:
>
> =A0git@linux-c6x.org:/git/projects/linux-c6x-upstreaming irq-testing
>
> I think this probably belongs in your series, but I can push it
> separately if not.
Yes, it should be in my series. Please post the patches and cc me so
there is record of them in the mailing list archives and I'll pick
them up.
g.
^ permalink raw reply
* Re: [PATCH] dmaengine: async_xor, fix zero address issue when xor highmem page
From: Dan Williams @ 2012-01-26 9:12 UTC (permalink / raw)
To: Shi Xuelin-B29237
Cc: vinod.koul@intel.com, linuxppc-dev@lists.ozlabs.org,
linux-kernel@vger.kernel.org, Li Yang-R58472
In-Reply-To: <DBB740589CE8814680DECFE34BE197AB166593@039-SN1MPN1-006.039d.mgd.msft.net>
2012/1/10 Shi Xuelin-B29237 <B29237@freescale.com>:
> Hello Dan Williams,
>
> Do you have any comment about this patch?
Hi, sorrry for the delay.
>
> Thanks,
> Forrest
>
> -----Original Message-----
> From: Shi Xuelin-B29237
> Sent: 2011=E5=B9=B412=E6=9C=8827=E6=97=A5 14:31
> To: vinod.koul@intel.com; dan.j.williams@intel.com; linuxppc-dev@lists.oz=
labs.org; linux-kernel@vger.kernel.org; Li Yang-R58472
> Cc: Shi Xuelin-B29237
> Subject: [PATCH] dmaengine: async_xor, fix zero address issue when xor hi=
ghmem page
>
> From: Forrest shi <b29237@freescale.com>
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0we may do_sync_xor high mem pages, in this cas=
e, page_address will
> =C2=A0 =C2=A0 =C2=A0 =C2=A0return zero address which cause a failure.
In what scenarios do we xor highmem?
In the case of raid we currently always xor on kmalloc'd memory.
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0this patch uses kmap_atomic before xor the pag=
es and kunmap_atomic
> =C2=A0 =C2=A0 =C2=A0 =C2=A0after it.
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0Signed-off-by: b29237@freescale.com <xuelin.sh=
i@freescale.com>
> ---
> =C2=A0crypto/async_tx/async_xor.c | =C2=A0 16 ++++++++++++----
> =C2=A01 files changed, 12 insertions(+), 4 deletions(-)
>
> diff --git a/crypto/async_tx/async_xor.c b/crypto/async_tx/async_xor.c in=
dex bc28337..5b416d1 100644
> --- a/crypto/async_tx/async_xor.c
> +++ b/crypto/async_tx/async_xor.c
> @@ -26,6 +26,7 @@
> =C2=A0#include <linux/kernel.h>
> =C2=A0#include <linux/interrupt.h>
> =C2=A0#include <linux/mm.h>
> +#include <linux/highmem.h>
> =C2=A0#include <linux/dma-mapping.h>
> =C2=A0#include <linux/raid/xor.h>
> =C2=A0#include <linux/async_tx.h>
> @@ -126,7 +127,7 @@ do_sync_xor(struct page *dest, struct page **src_list=
, unsigned int offset,
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0int src_cnt, size_t len, struct =
async_submit_ctl *submit) =C2=A0{
> =C2=A0 =C2=A0 =C2=A0 =C2=A0int i;
> - =C2=A0 =C2=A0 =C2=A0 int xor_src_cnt =3D 0;
> + =C2=A0 =C2=A0 =C2=A0 int xor_src_cnt =3D 0, kmap_cnt=3D0;
> =C2=A0 =C2=A0 =C2=A0 =C2=A0int src_off =3D 0;
> =C2=A0 =C2=A0 =C2=A0 =C2=A0void *dest_buf;
> =C2=A0 =C2=A0 =C2=A0 =C2=A0void **srcs;
> @@ -138,11 +139,13 @@ do_sync_xor(struct page *dest, struct page **src_li=
st, unsigned int offset,
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0/* convert to buffer pointers */
> =C2=A0 =C2=A0 =C2=A0 =C2=A0for (i =3D 0; i < src_cnt; i++)
> - =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if (src_list[i])
> - =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 srcs[xor_src_cnt++] =3D page_address(src_list[i]) + offset;
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if (src_list[i]) {
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 srcs[xor_src_cnt++] =3D kmap_atomic(src_list[i], KM_USER1) + offset;
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
> + =C2=A0 =C2=A0 =C2=A0 kmap_cnt =3D xor_src_cnt;
I guess this works now that we have stack based kmap_atomic, but on
older kernels you could not simultaneously map that many buffers with
a single kmap slot. So if you resend, drop the second parameter to
kmap_atomic.
...but unless you have a non md/raid456 use case in mind, or have
patches to convert md/raid to xor straight out of the incoming biovecs
I don't think this patch is needed right?
^ permalink raw reply
* [PATCH] irq: make SPARSE_IRQ an optionally hidden option
From: Rob Herring @ 2012-01-26 2:58 UTC (permalink / raw)
To: linux-kernel
Cc: Russell King, linux-c6x-dev, Aurelien Jacquiot, linux-sh,
H. Peter Anvin, Rob Herring, Paul Mundt, Paul Mackerras,
Mark Salter, Thomas Gleixner, linuxppc-dev, Ingo Molnar,
linux-arm-kernel
From: Rob Herring <rob.herring@calxeda.com>
On ARM, we don't want SPARSE_IRQ to be a user visible option. Make
SPARSE_IRQ visible based on MAY_HAVE_SPARSE_IRQ instead of depending
on HAVE_SPARSE_IRQ.
With this, SPARSE_IRQ is not visible on C6X and ARM.
Signed-off-by: Rob Herring <rob.herring@calxeda.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Mark Salter <msalter@redhat.com>
Cc: Aurelien Jacquiot <a-jacquiot@ti.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Paul Mundt <lethal@linux-sh.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-c6x-dev@linux-c6x.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-sh@vger.kernel.org
---
This is part of an irq include consolidation series for ARM:
http://www.spinics.net/lists/arm-kernel/msg156492.html
Rob
arch/arm/Kconfig | 1 -
arch/c6x/Kconfig | 2 +-
arch/powerpc/Kconfig | 2 +-
arch/sh/Kconfig | 2 +-
arch/x86/Kconfig | 1 -
kernel/irq/Kconfig | 5 ++---
6 files changed, 5 insertions(+), 8 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 24626b0..30e7840 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -28,7 +28,6 @@ config ARM
select HAVE_HW_BREAKPOINT if (PERF_EVENTS && (CPU_V6 || CPU_V6K || CPU_V7))
select HAVE_C_RECORDMCOUNT
select HAVE_GENERIC_HARDIRQS
- select HAVE_SPARSE_IRQ
select GENERIC_IRQ_SHOW
select CPU_PM if (SUSPEND || CPU_IDLE)
select GENERIC_PCI_IOMAP
diff --git a/arch/c6x/Kconfig b/arch/c6x/Kconfig
index 26e67f0..2f58c61 100644
--- a/arch/c6x/Kconfig
+++ b/arch/c6x/Kconfig
@@ -11,7 +11,7 @@ config TMS320C6X
select HAVE_DMA_API_DEBUG
select HAVE_GENERIC_HARDIRQS
select HAVE_MEMBLOCK
- select HAVE_SPARSE_IRQ
+ select SPARSE_IRQ
select OF
select OF_EARLY_FLATTREE
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 1919634..06c1cf0 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -133,7 +133,7 @@ config PPC
select HAVE_REGS_AND_STACK_ACCESS_API
select HAVE_HW_BREAKPOINT if PERF_EVENTS && PPC_BOOK3S_64
select HAVE_GENERIC_HARDIRQS
- select HAVE_SPARSE_IRQ
+ select MAY_HAVE_SPARSE_IRQ
select IRQ_PER_CPU
select GENERIC_IRQ_SHOW
select GENERIC_IRQ_SHOW_LEVEL
diff --git a/arch/sh/Kconfig b/arch/sh/Kconfig
index 3c8db65..21b82a8 100644
--- a/arch/sh/Kconfig
+++ b/arch/sh/Kconfig
@@ -22,7 +22,7 @@ config SUPERH
select HAVE_SYSCALL_TRACEPOINTS
select HAVE_REGS_AND_STACK_ACCESS_API
select HAVE_GENERIC_HARDIRQS
- select HAVE_SPARSE_IRQ
+ select MAY_HAVE_SPARSE_IRQ
select IRQ_FORCED_THREADING
select RTC_LIB
select GENERIC_ATOMIC64
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 864cc6e..fb2da44 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -69,7 +69,6 @@ config X86
select HAVE_ARCH_JUMP_LABEL
select HAVE_TEXT_POKE_SMP
select HAVE_GENERIC_HARDIRQS
- select HAVE_SPARSE_IRQ
select SPARSE_IRQ
select GENERIC_FIND_FIRST_BIT
select GENERIC_IRQ_PROBE
diff --git a/kernel/irq/Kconfig b/kernel/irq/Kconfig
index 5a38bf4..1f2dece 100644
--- a/kernel/irq/Kconfig
+++ b/kernel/irq/Kconfig
@@ -13,7 +13,7 @@ config GENERIC_HARDIRQS
# Options selectable by the architecture code
# Make sparse irq Kconfig switch below available
-config HAVE_SPARSE_IRQ
+config MAY_HAVE_SPARSE_IRQ
bool
# Enable the generic irq autoprobe mechanism
@@ -61,8 +61,7 @@ config IRQ_FORCED_THREADING
bool
config SPARSE_IRQ
- bool "Support sparse irq numbering"
- depends on HAVE_SPARSE_IRQ
+ bool "Support sparse irq numbering" if MAY_HAVE_SPARSE_IRQ
---help---
Sparse irq numbering is useful for distro kernels that want
--
1.7.5.4
^ permalink raw reply related
* Re: [RFCv2 00/14]
From: Mark Salter @ 2012-01-25 22:53 UTC (permalink / raw)
To: Grant Likely
Cc: devicetree-discuss, linux-kernel, Milton Miller, Rob Herring,
linuxppc-dev
In-Reply-To: <1327352870-14687-1-git-send-email-grant.likely@secretlab.ca>
On Mon, 2012-01-23 at 14:07 -0700, Grant Likely wrote:
> Hey everyone,
>
> Here's the second RFC for the irq_domain patches. I could use some
> help testing now. I still expect there will be a few bugs. The
> series is based on v3.3-rc1, and I've pushed it out to my git server:
Hi Grant,
I converted arch/c6x over to the generic irq_domain support and have not
had any problems in testing. The c6x virtual irq support was a nearly
identical copy of the powerpc code, so the patch I ended up with mostly
copied what you did in arch/powerpc. The c6x patch is on the tip of:
git@linux-c6x.org:/git/projects/linux-c6x-upstreaming irq-testing
I think this probably belongs in your series, but I can push it
separately if not.
--Mark
^ permalink raw reply
* Re: [PATCH 2/2] powerpc: Abstract common define of signal multiplex control for qe
From: Tabi Timur-B04825 @ 2012-01-25 20:55 UTC (permalink / raw)
To: Fan Zhicheng-B32736; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1327035611-22794-2-git-send-email-B32736@freescale.com>
On Thu, Jan 19, 2012 at 11:00 PM, Zhicheng Fan <B32736@freescale.com> wrote=
:
> Signed-off-by: Fanzc <b32736@freeescale.com>
Please fix this. There are only two e's in freescale. In addition,
please use your full name.
--=20
Timur Tabi
Linux kernel developer at Freescale=
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox