* Re: [PATCH 0/8] 8xx: Misc fixes for buggy insn
From: Joakim Tjernlund @ 2009-11-10 21:47 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev@ozlabs.org, Rex Feany
In-Reply-To: <4AF9DCE0.4030805@freescale.com>
Scott Wood <scottwood@freescale.com> wrote on 10/11/2009 22:36:32:
>
> Joakim Tjernlund wrote:
> > Scott Wood <scottwood@freescale.com> wrote on 10/11/2009 21:27:05:
> >> Joakim Tjernlund wrote:
> >>> Scott Wood <scottwood@freescale.com> wrote on 10/11/2009 17:55:28:
> >>>> Except that the invalidation only happens when you take an ITLB miss on
> >>>> an adjacent page, which means we'd likely never get CPU15 protection for
> >>>> kernel code if pinning is enabled. :-(
> >>> So tlbie invalidates pinned TLBs too?
> >> Yes.
> >
> > OK, and this is in no way unique for 8xx?
>
> Not sure about others, but 8xx manual explicitly says that it
> invalidates reserved entries.
>
> >> But who knows when CPU15 will strike...
> > yes, maybe there is a way around that. Perhaps by using one of the
> > pinned entries for loaded modules, i.e avoid ITLB misses for kernel space?
>
> Not sure what you mean... loaded modules won't be pinned, and since
> they shouldn't contain rfi, don't need to be.
But CPU15 may invalidate a pinned TLB if you take a TLB Miss?
If not there should not be a problem, because the rest
of the kernel will never take a ITLB Miss.
>
> I don't see how to pin any part of the kernel without introducing some
> possibility of CPU15, unless we go scanning the last word of every
> instruction page, creating trampolines, and hoping there's no data
> embedded in the text segment. :-P
Yes, it is not going to be easy.
So aligning the srr0/srr1/rfi properly is needed.
BTW, you could probably cram the DARFix into the DTLBerror with some luck.
Especially if you allow it to spill over to the next trap. Then create a
branch insn at 0x1500 to 0x1600. Would that make everything aligned again?
Jocke
^ permalink raw reply
* Re: [PATCH 09/11] of: merge prom_{add,remove,modify}_property
From: Grant Likely @ 2009-11-10 21:41 UTC (permalink / raw)
To: Nathan Fontenot
Cc: sfr, monstr, devicetree-discuss, microblaze-uclinux, sparclinux,
linuxppc-dev, davem
In-Reply-To: <4AF9CE2F.7080502@austin.ibm.com>
On Tue, Nov 10, 2009 at 1:33 PM, Nathan Fontenot <nfont@austin.ibm.com> wro=
te:
> Grant Likely wrote:
>>
>> Merge common code between PowerPC and MicroBlaze
>>
>> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
>> ---
>>
>> =A0arch/microblaze/kernel/prom.c | =A0113
>> ----------------------------------------
>> =A0arch/powerpc/kernel/prom.c =A0 =A0| =A0114
>> ----------------------------------------
>> =A0drivers/of/base.c =A0 =A0 =A0 =A0 =A0 =A0 | =A0116
>> +++++++++++++++++++++++++++++++++++++++++
>> =A03 files changed, 116 insertions(+), 227 deletions(-)
>>
>
> Should the prom_{add,remove,update}_property routines belong in base.c or
> of_dynamic.c (patches coming soon for of_dynamic.c)?
> My original patch set put these routines in of_dynamic.c and renamed
> them to of_{add,remove,update}_property since they are part of the of
> code.
First stage for me is to go through the rather mechanical process of
merging common code. As much as possible I'm not changing any APIs,
and I don't have enough background on the of_dynamic stuff to make a
call about where it should ultimately live. The goal of the first
stage is simply to eliminate duplicated code. Rename of functions to
of_ is potentially risky, so I'm deferring those changes until after
all the code is merged.
Feel free to make changes on top of what I'm doing. Keep each one
small to reduce the risk of conflict. I'll pick up the ones that make
sense.
Cheers,
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 09/11] of: merge prom_{add,remove,modify}_property
From: Nathan Fontenot @ 2009-11-10 20:33 UTC (permalink / raw)
To: Grant Likely
Cc: sfr, monstr, devicetree-discuss, microblaze-uclinux, sparclinux,
linuxppc-dev, davem
In-Reply-To: <20091105074656.10460.29333.stgit@angua>
Grant Likely wrote:
> Merge common code between PowerPC and MicroBlaze
>
> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
> ---
>
> arch/microblaze/kernel/prom.c | 113 ----------------------------------------
> arch/powerpc/kernel/prom.c | 114 ----------------------------------------
> drivers/of/base.c | 116 +++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 116 insertions(+), 227 deletions(-)
>
Should the prom_{add,remove,update}_property routines belong in base.c or
of_dynamic.c (patches coming soon for of_dynamic.c)?
My original patch set put these routines in of_dynamic.c and renamed
them to of_{add,remove,update}_property since they are part of the of
code.
-Nathan Fontenot
^ permalink raw reply
* Re: [spi-devel-general] [PATCH v4] xilinx_spi: Splitted into generic, of and platform driver, added support for DS570
From: Grant Likely @ 2009-11-10 16:44 UTC (permalink / raw)
To: Richard Röjfors
Cc: spi-devel-general, Andrew Morton, dbrownell, John Linn,
linuxppc-dev
In-Reply-To: <4AF99298.9020207@mocean-labs.com>
On Tue, Nov 10, 2009 at 9:19 AM, Richard R=F6jfors
<richard.rojfors@mocean-labs.com> wrote:
> Grant Likely wrote:
>> Oops, I replied to the original version, but missed the subsequent
>> versions. =A0Looks like some of my comments still apply though.
>> Overall, the patch changes too many things all at once. =A0You should
>> look at splitting it up. =A0At the very least the io accessor changes
>> should be done in a separate patch.
Hi Richard. Please do another spin of this patch. I don't have any
particular problem with the changes, but it needs to be in a more
granular form so I can review it properly.
>>> +struct xilinx_spi {
>>> + =A0 =A0 =A0 /* bitbang has to be first */
>>> + =A0 =A0 =A0 struct spi_bitbang bitbang;
>>> + =A0 =A0 =A0 struct completion done;
>>> + =A0 =A0 =A0 struct resource mem; /* phys mem */
>>> + =A0 =A0 =A0 void __iomem =A0 =A0*regs; =A0/* virt. address of the con=
trol registers */
>>> + =A0 =A0 =A0 u32 irq;
>>> + =A0 =A0 =A0 u8 *rx_ptr; =A0 =A0 =A0 =A0 =A0 =A0 /* pointer in the Tx =
buffer */
>>> + =A0 =A0 =A0 const u8 *tx_ptr; =A0 =A0 =A0 /* pointer in the Rx buffer=
*/
>>> + =A0 =A0 =A0 int remaining_bytes; =A0 =A0/* the number of bytes left t=
o transfer */
>>> + =A0 =A0 =A0 /* offset to the XSPI regs, these might vary... */
>>> + =A0 =A0 =A0 u8 bits_per_word;
>>> + =A0 =A0 =A0 bool big_endian; =A0 =A0 =A0 =A0/* The device could be ac=
cessed big or little
>>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* endi=
an
>>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0*/
>>> +};
>>> +
>>
>> Why is the definition of xilinx_spi moved?
>
> I liked the idea of heaving the struct defined in the top of the file.
... which is completely unrelated to the patch purpose, and is not
mentioned in the patch header. If you really want to move it then put
it in a completely separate patch and describe the change properly.
As it is right now it is just noise that makes the stated purpose of
the patch hard to review.
>> Ah, you changed these to functions instead of macros. =A0I like.
>> However, as you suggested elsewhere in this thread, you could change
>> these to callbacks and then eliminate the if/else statements. =A0I think
>> that is the approach you should use. =A0I don't think you need to worry
>> about it being slower. =A0Any extra cycles for jumping to a callback
>> will be far dwarfed by the number of cycles it takes to complete an
>> SPI transfer.
>
> Sure that can be updated. I prefer to do that in an incremental patch, wo=
uld be great to get this
> big one merged first.
As already commented on, this patch is too big and does too many
unrelated things. Please split into discrete changes so it can be
reviewed properly.
Thanks,
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 0/8] 8xx: Misc fixes for buggy insn
From: Scott Wood @ 2009-11-10 16:36 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: linuxppc-dev@ozlabs.org, Rex Feany
In-Reply-To: <OF0C254AE9.CCCFDCCC-ONC125766A.002D331C-C125766A.002E7C69@transmode.se>
Joakim Tjernlund wrote:
> Scott Wood <scottwood@freescale.com> wrote on 10/11/2009 00:00:04:
>> syscall_exit_cont, SRR0/SRR1 were being loaded immediately prior to a page
>> boundary, with the rfi after the page boundary. On crossing the boundary,
>> we take an ITLB miss (which goes from possibility to certainty with the
>> CPU15 workaround), and SRR0/SRR1 get clobbered.
>
> I am not familiar with CPU15 since we never had that problem.
> The patch series is OK then, but one need to add some CPU15 love?
It's not CPU15 itself that is causing the problem, but rather the
workaround for CPU15 takes something that has a possibility of happening
and makes it certain to happen.
>> Either that, or require that the kernel text be pinned, though that does not
>> interact well with CPU15.
>
> Why does not pinning interact well with CPU15? If pinned, you never get
> a TLB miss for kernel text so that should mitigate the CPU15 problem.
The nature of the workaround for CPU15 is that we can't keep it pinned
-- we have to take an ITLB miss on every page boundary crossing. If you
try to pin, it'll just be invalidated by the workaround.
There is an alternate workaround, but it requires compiler changes.
-Scott
^ permalink raw reply
* Re: term_adt746x: Invert bit required on this Powerbook G4
From: Michel Dänzer @ 2009-11-10 14:41 UTC (permalink / raw)
To: Max Vozeler; +Cc: linuxppc-dev
In-Reply-To: <20091104122355.GA7269@quark.vpn.nusquama.org>
[ Resending with linuxppc-dev list domain fixed ]
On Wed, 2009-11-04 at 13:23 +0100, Max Vozeler wrote:=20
> I installed Ubuntu 8.10 on this Powerbook G4 ("alu" I think)=20
> for a friend of mine. As soon as therm_adt746x got loaded, the=20
> fan turned into a noise steam engine.=20
>=20
> This was on Ubuntu's 2.6.31 kernel (2.6.31-14-powerpc) which=20
> includes 0512a9a8e277a9de2. I could reproduce it with latest
> mainline as well.
>=20
> The effect was just as Michel described in the changelog; The
> fan was running while temps were well below any of the limits,
> and it stopped only when I set ridiculously low limits.
>=20
> [ 1087.141482] adt746x: version 1 (supported)
> [ 1087.141495] adt746x: Thermostat bus: 1, address: 0x2e, limit_adjust: 0=
, fan_speed: -1
> [ 1087.141503] sensor 0: HDD BOTTOMSIDE
> [ 1087.141507] sensor 1: CPU TOPSIDE
> [ 1087.141512] sensor 2: GPU ON DIE
> [ 1087.161365] adt746x: ADT7460 initializing
> [ 1087.165245] adt746x: Lowering max temperatures from 73, 80, 109 to 70,=
50, 70
> [ 1087.165261] adt746x: Setting speed to 0 for CPU TOPSIDE fan.
> [ 1087.166302] adt746x: Setting speed to 0 for GPU ON DIE fan.
>=20
> (What "worked" was limit_adjust=3D-30, fan did turn off, but so did
> the Powerbook shortly after, despite being cold.)
>=20
> After some poking around, in which everything seemed to be
> according to plan including write of 0 to both FAN_SPD_SET regs,
> I noticed that explicitly *setting* the invert bit as in=20
>=20
> - write_reg(th, MANUAL_MODE[fan],
> - (manual|MANUAL_MASK) & (~INVERT_MASK));
> + write_reg(th, MANUAL_MODE[fan],
> + (manual|MANUAL_MASK|INVERT_MASK));
>=20
> seems to cure it. The fan appears to behave normally now, it
> turns on slowly when the temp limits are reached, otherwise it
> stays off. The temperature is reasonable (ie, no too hot).
>=20
> So, puzzeled, I checked the spec, and it appears very clear on
> the question of invert: It should be off by default.
Right, that's what I based my patch on.
However, it sounds like your PowerBook model (mine is a PowerBook5,8) is
wired up such that the invert bit needs to be enabled. I can think of
two basic approaches for dealing with this offhand:
* Set or clear the invert bit depending on the machine model or
whatever is relevant.=20
* Save the bit value during initialization and preserve it
whenever writing to the register. Or maybe even add proper
suspend/resume hooks which save/restore all hardware state, it
seems like it may be luck that the current code works more or
less for suspend/resume.
I'm not too interested in working on this anymore and I definitely won't
have time this or next week, anyone feel free to take it on.
--=20
Earthling Michel D=C3=A4nzer | http://www.vmware.c=
om
Libre software enthusiast | Debian, X and DRI developer
^ permalink raw reply
* Re: [PATCH] ASoC/mpc5200: remove duplicate identical IRQ handler
From: Mark Brown @ 2009-11-10 13:03 UTC (permalink / raw)
To: Grant Likely; +Cc: alsa-devel, linuxppc-dev, lrg
In-Reply-To: <20091109163936.29231.482.stgit@angua>
On Mon, Nov 09, 2009 at 09:40:09AM -0700, Grant Likely wrote:
> The TX and RX irq handlers are identical. Merge them
Applied, thanks.
^ permalink raw reply
* MPC5200B FEC_IEVENT_RFIFO_ERROR leading to Link is Down
From: Roman Fietze @ 2009-11-10 12:47 UTC (permalink / raw)
To: linuxppc-dev
Hello,
When having high traffic on the MPC5200B ATA (MWDMA2), FEC (100MBit)
and LPC (MTD FLASH read) I will get the typical
=46EC_IEVENT_RFIFO_ERROR's.
Without the FLASH reads, that we use to stress the probably existing
LPC arbiter or MPC5200B silicon bug when running UDMA2+LPC, and which
should not happen using MWDMA2+LPC, I could not yet reproduce the
=46EC_IEVENT_RFIFO_ERROR.
Now comes the problem: since the PHY driver rework followed by John
Bonesio's fix (rev 37ccd92f55c6c6) to avoid accessing the DIO bus at
interrupt context, this now sometimes causes an irrecoverable link
down (PHY: f0003000:00 - Link is Down). This patch is of course
necessary to avoid a panic.
I can reproduce that on the current DENX/master using an own board
very close to the Lite5200B. This board runs fine under the old
2.4.25, of course also sometimes showing the FEC FIFO error.
Any ideas?
Roman
=2D-=20
Roman Fietze Telemotive AG B=FCro M=FChlhausen
Breitwiesen 73347 M=FChlhausen
Tel.: +49(0)7335/18493-45 http://www.telemotive.de
^ permalink raw reply
* OOPS on MPC8548 board when writing RAID5 array
From: hank peng @ 2009-11-10 11:44 UTC (permalink / raw)
To: linuxppc-dev, linux-raid
CPU is MPC8548, kernel version is 2.6.31.5,CONFIG_FSL_DMA and
CONFIG_ASYNC_TX_DMA options are all enabled.
#mdadm -C /dev/md0 --assume-clean -l5 -n3 /dev/sd{a,b,c}
#dd if=/dev/zero of=/dev/md0 bs=1M count=1000
Oops: Exception in kernel mode, sig: 5 [#1]
MPC85xx CDS
Modules linked in:
NIP: c01c45d8 LR: c01c4d48 CTR: 00000000
REGS: c2dd5c80 TRAP: 0700 Not tainted (2.6.31.5)
MSR: 00029000 <EE,ME,CE> CR: 22004028 XER: 00000000
TASK = e820a580[3804] 'md0_raid5' THREAD: c2dd4000
GPR00: 00000001 c2dd5d30 e820a580 c2fb1088 00000001 00000000 00000002 00001000
GPR08: 00000001 c0485a20 00000000 ef8092f8 22002024 55555555 c2d67870 c0282d2c
GPR16: 00001000 e8355c00 c2eff964 00000000 00000000 00000019 01000040 c2dd5e00
GPR24: c2dd5dfc 00000001 c2dd5dc0 c099c420 00000000 c2d67838 00000002 c2dd5d58
NIP [c01c45d8] async_tx_quiesce+0x28/0x74
LR [c01c4d48] async_xor+0x208/0x350
Call Trace:
[c2dd5d30] [c02a80f8] fsl_dma_alloc_descriptor+0x24/0x70 (unreliable)
[c2dd5d40] [c01c4d48] async_xor+0x208/0x350
[c2dd5db0] [c02839ec] ops_run_postxor+0xfc/0x1c0
[c2dd5df0] [c0284700] handle_stripe5+0xb24/0x15c0
[c2dd5e70] [c02864c8] handle_stripe+0x34/0x12d4
[c2dd5f10] [c02879ac] raid5d+0x244/0x458
[c2dd5f70] [c02938d4] md_thread+0x5c/0x124
[c2dd5fc0] [c004cc9c] kthread+0x78/0x7c
[c2dd5ff0] [c000f50c] kernel_thread+0x4c/0x68
Instruction dump:
7c0803a6 4e800020 9421fff0 7c0802a6 93e1000c 7c7f1b78 90010014 80630000
2f830000 419e0034 80030004 5400fffe <0f000000> 480e19b1 2f830002 419e0030
I checked the kernel source code, and find that this OOPS was caused
by the following BUG_ON code:
It is in crypto/async_tx/async_tx.c:
void async_tx_quiesce(struct dma_async_tx_descriptor **tx)
{
if (*tx) {
/* if ack is already set then we cannot be sure
* we are referring to the correct operation
*/
BUG_ON(async_tx_test_ack(*tx));
/* OOPS occured */
if (dma_wait_for_async_tx(*tx) == DMA_ERROR)
panic("DMA_ERROR waiting for transaction\n");
async_tx_ack(*tx);
*tx = NULL;
}
}
--
The simplest is not all best but the best is surely the simplest!
^ permalink raw reply
* SPI driver for linux 2.6.29
From: Dhinakaran K @ 2009-11-10 11:17 UTC (permalink / raw)
To: linuxppc-dev
Hi,
I've a PPC8313e based board running linux2.6.29 on it. Also I've a
FRAM interfaced to it via SPI. This FRAM almost similar to SPI based
EEPROM, so I'm trying to use EEPROM's driver AT25.
Kernel Configuration :
SPI support --> selected
Freescale MPC83xx/QUICC Engine SPI controller --> selected
(Actually I've replaced MPC83xx's controller driver with modified
MPC8XXX's(from 2.6.31) one for it was not getting probed,)
User mode SPI device driver support --> selected
DTS File;
spi@7000 {
cell-index = <0>;
compatible = "fsl,spi";
reg = <0x7000 0x1000>;
interrupts = <16 0x8>;
interrupt-parent = <&ipic>;
mode = "cpu";
fram@0{
compatible =
"ramtron,fm25"; -->(Modified at25 as fm25 )
spi-max-frequency =
<100000000>;
reg = <0>;
};
};
and we are forcing following values in AT25 driver
byte_len = 65536;
name = fram-spi
page_size = 65535;
flags = EE_ADDR2;
Problem:
Drivers are getting complied. But I'm not sure how to acces(i.e,
read/write) the actual SPI-FRAM device.
Should I use
1. /dev/spi/X nodes created by spidev driver
When I use this node, open fails with ERRNO 6
or
2. /sys/bus/spi/devices/spi32766.0/eeprom file.
When I use this sysfs file,Im not able to read / write
properly
Queries:
1. What will be device nodes for this custom at25(fm25) driver,
which registers to spi.c driver?
2. Is spidev.c involved in this picture?
Any help/directions in this regard will of great help.
Thanks n Regards
dhina
^ permalink raw reply
* [PATCH 3/3] mpc52xx_spi: add gpio chipselect
From: Luotao Fu @ 2009-11-10 9:12 UTC (permalink / raw)
To: Grant Likely
Cc: spi-devel-general, David Brownell, linux-kernel, l.fu,
linuxppc-dev
In-Reply-To: <1257844329-20687-3-git-send-email-l.fu@pengutronix.de>
This one enables the mpc52xx_spi driver for usage of user defined gpio lines
as chipselect. This way we can control some more spi devices than only one
Signed-off-by: Luotao Fu <l.fu@pengutronix.de>
---
drivers/spi/mpc52xx_spi.c | 57 +++++++++++++++++++++++++++++++++++++++++---
1 files changed, 53 insertions(+), 4 deletions(-)
diff --git a/drivers/spi/mpc52xx_spi.c b/drivers/spi/mpc52xx_spi.c
index 79ba678..58c2ce5 100644
--- a/drivers/spi/mpc52xx_spi.c
+++ b/drivers/spi/mpc52xx_spi.c
@@ -21,6 +21,7 @@
#include <linux/spi/mpc52xx_spi.h>
#include <linux/of_spi.h>
#include <linux/io.h>
+#include <linux/of_gpio.h>
#include <asm/time.h>
#include <asm/mpc52xx.h>
@@ -79,7 +80,6 @@ struct mpc52xx_spi {
spinlock_t lock;
struct work_struct work;
-
/* Details of current transfer (length, and buffer pointers) */
struct spi_message *message; /* current message */
struct spi_transfer *transfer; /* current transfer */
@@ -89,6 +89,8 @@ struct mpc52xx_spi {
u8 *rx_buf;
const u8 *tx_buf;
int cs_change;
+ int gpio_cs_count;
+ unsigned int *gpio_cs;
};
/*
@@ -96,7 +98,13 @@ struct mpc52xx_spi {
*/
static void mpc52xx_spi_chipsel(struct mpc52xx_spi *ms, int value)
{
- out_8(ms->regs + SPI_PORTDATA, value ? 0 : 0x08);
+ int cs;
+
+ if (ms->gpio_cs_count > 0) {
+ cs = ms->message->spi->chip_select;
+ gpio_direction_output(ms->gpio_cs[cs], value);
+ } else
+ out_8(ms->regs + SPI_PORTDATA, value ? 0 : 0x08);
}
/*
@@ -390,8 +398,9 @@ static int __devinit mpc52xx_spi_probe(struct of_device *op,
struct spi_master *master;
struct mpc52xx_spi *ms;
void __iomem *regs;
- int rc;
int ctrl1;
+ int rc, i = 0;
+ int gpio_cs;
/* MMIO registers */
dev_dbg(&op->dev, "probing mpc5200 SPI device\n");
@@ -426,8 +435,8 @@ static int __devinit mpc52xx_spi_probe(struct of_device *op,
rc = -ENOMEM;
goto err_alloc;
}
+
master->bus_num = -1;
- master->num_chipselect = 1;
master->setup = mpc52xx_spi_setup;
master->transfer = mpc52xx_spi_transfer;
master->mode_bits = SPI_CPOL | SPI_CPHA | SPI_CS_HIGH | SPI_LSB_FIRST;
@@ -441,6 +450,39 @@ static int __devinit mpc52xx_spi_probe(struct of_device *op,
ms->irq1 = irq_of_parse_and_map(op->node, 1);
ms->state = mpc52xx_spi_fsmstate_idle;
ms->ipb_freq = mpc5xxx_get_bus_frequency(op->node);
+ ms->gpio_cs_count = of_gpio_count(op->node);
+ if (ms->gpio_cs_count > 0) {
+ master->num_chipselect = ms->gpio_cs_count;
+ ms->gpio_cs = kmalloc(ms->gpio_cs_count * sizeof(unsigned int),
+ GFP_KERNEL);
+ if (!ms->gpio_cs) {
+ rc = -ENOMEM;
+ goto err_alloc;
+ }
+
+ for (i = 0; i < ms->gpio_cs_count; i++) {
+ gpio_cs = of_get_gpio(op->node, i);
+ if (gpio_cs < 0) {
+ dev_err(&op->dev,
+ "could not parse the gpio field "
+ "in oftree\n");
+ rc = -ENODEV;
+ goto err_alloc;
+ }
+
+ ms->gpio_cs[i] = gpio_cs;
+ rc = gpio_request(ms->gpio_cs[i], dev_name(&op->dev));
+ if (rc) {
+ dev_err(&op->dev,
+ "can't request spi cs gpio #%d "
+ "on gpio line %d\n",
+ i, gpio_cs);
+ goto err_gpio;
+ }
+ }
+ } else
+ master->num_chipselect = 1;
+
spin_lock_init(&ms->lock);
INIT_LIST_HEAD(&ms->queue);
INIT_WORK(&ms->work, mpc52xx_spi_wq);
@@ -477,6 +519,9 @@ static int __devinit mpc52xx_spi_probe(struct of_device *op,
err_register:
dev_err(&ms->master->dev, "initialization failed\n");
spi_master_put(master);
+ err_gpio:
+ while (i-- > 0)
+ gpio_free(ms->gpio_cs[i]);
err_alloc:
err_init:
iounmap(regs);
@@ -487,10 +532,14 @@ static int __devexit mpc52xx_spi_remove(struct of_device *op)
{
struct spi_master *master = dev_get_drvdata(&op->dev);
struct mpc52xx_spi *ms = spi_master_get_devdata(master);
+ int i;
free_irq(ms->irq0, ms);
free_irq(ms->irq1, ms);
+ for (i = 0; i < ms->gpio_cs_count; i++)
+ gpio_free(ms->gpio_cs[i]);
+
spi_unregister_master(master);
spi_master_put(master);
iounmap(ms->regs);
--
1.6.5.2
^ permalink raw reply related
* [PATCH 1/3] mpc52xx_spi: fix clearing status register
From: Luotao Fu @ 2009-11-10 9:12 UTC (permalink / raw)
To: Grant Likely
Cc: spi-devel-general, David Brownell, linux-kernel, l.fu,
linuxppc-dev
In-Reply-To: <1257844329-20687-1-git-send-email-l.fu@pengutronix.de>
Before reading status register to check MODF failure, we have to clear it
first since the MODF flag will be set after initializing the spi master,
if the hardware comes up with a low SS. The processor datasheet reads:
Mode Fault flag -- bit sets if SS input goes low while SPI is configured as a
master. Flag is cleared automatically by an SPI status register read (with MODF
set) followed by a SPI control register 1 write.
Hence simply rereading the register is not sufficient to clear the flag. We
redo the write also to make sure to clear the flag.
Signed-off-by: Luotao Fu <l.fu@pengutronix.de>
---
drivers/spi/mpc52xx_spi.c | 6 +++++-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/drivers/spi/mpc52xx_spi.c b/drivers/spi/mpc52xx_spi.c
index ef8379b..5b036f2 100644
--- a/drivers/spi/mpc52xx_spi.c
+++ b/drivers/spi/mpc52xx_spi.c
@@ -391,6 +391,7 @@ static int __devinit mpc52xx_spi_probe(struct of_device *op,
struct mpc52xx_spi *ms;
void __iomem *regs;
int rc;
+ int ctrl1;
/* MMIO registers */
dev_dbg(&op->dev, "probing mpc5200 SPI device\n");
@@ -399,7 +400,8 @@ static int __devinit mpc52xx_spi_probe(struct of_device *op,
return -ENODEV;
/* initialize the device */
- out_8(regs+SPI_CTRL1, SPI_CTRL1_SPIE | SPI_CTRL1_SPE | SPI_CTRL1_MSTR);
+ ctrl1 = SPI_CTRL1_SPIE | SPI_CTRL1_SPE | SPI_CTRL1_MSTR;
+ out_8(regs + SPI_CTRL1, ctrl1);
out_8(regs + SPI_CTRL2, 0x0);
out_8(regs + SPI_DATADIR, 0xe); /* Set output pins */
out_8(regs + SPI_PORTDATA, 0x8); /* Deassert /SS signal */
@@ -409,6 +411,8 @@ static int __devinit mpc52xx_spi_probe(struct of_device *op,
* on the SPI bus. This fault will also occur if the SPI signals
* are not connected to any pins (port_config setting) */
in_8(regs + SPI_STATUS);
+ out_8(regs + SPI_CTRL1, ctrl1);
+
in_8(regs + SPI_DATA);
if (in_8(regs + SPI_STATUS) & SPI_STATUS_MODF) {
dev_err(&op->dev, "mode fault; is port_config correct?\n");
--
1.6.5.2
^ permalink raw reply related
* Patches for mpc52xx_spi
From: Luotao Fu @ 2009-11-10 9:12 UTC (permalink / raw)
To: Grant Likely
Cc: spi-devel-general, David Brownell, linux-kernel, l.fu,
linuxppc-dev
Hi Grant,
here are several patches for the dedicated spi controller on mpc5200 SOC. The
patchset contains two fixes and an enhancement. I noticed that your original V4
Patch is still pending for mainline. So I made the patches against the latest
version in your -next tree. Tested on a mpc5200b machine with 7 spi devices,
(cs lines are conntected to gpios) on 2.6.31, should work with latest kernel
also. Please review.
cheers
Luotao Fu
^ permalink raw reply
* [PATCH 2/3] mpc52xx_spi: add missing mode_bits definition
From: Luotao Fu @ 2009-11-10 9:12 UTC (permalink / raw)
To: Grant Likely
Cc: spi-devel-general, David Brownell, linux-kernel, l.fu,
linuxppc-dev
In-Reply-To: <1257844329-20687-2-git-send-email-l.fu@pengutronix.de>
Signed-off-by: Luotao Fu <l.fu@pengutronix.de>
---
drivers/spi/mpc52xx_spi.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/spi/mpc52xx_spi.c b/drivers/spi/mpc52xx_spi.c
index 5b036f2..79ba678 100644
--- a/drivers/spi/mpc52xx_spi.c
+++ b/drivers/spi/mpc52xx_spi.c
@@ -430,6 +430,8 @@ static int __devinit mpc52xx_spi_probe(struct of_device *op,
master->num_chipselect = 1;
master->setup = mpc52xx_spi_setup;
master->transfer = mpc52xx_spi_transfer;
+ master->mode_bits = SPI_CPOL | SPI_CPHA | SPI_CS_HIGH | SPI_LSB_FIRST;
+
dev_set_drvdata(&op->dev, master);
ms = spi_master_get_devdata(master);
--
1.6.5.2
^ permalink raw reply related
* [PATCH] zlib: Optimize inffast when copying direct from output
From: Joakim Tjernlund @ 2009-11-10 9:00 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org
In-Reply-To: <Received>
JFFS2 uses lesser compression ratio and inflate always
ends up in "copy direct from output" case.
This patch tries to optimize the direct copy procedure.
Uses get_unaligned() but only in one place.
The copy loop just above this one can also use this
optimization, but I havn't done so as I have not tested if it
is a win there too.
On my MPC8321 this is about 17% faster on my JFFS2 root FS
than the original.
---
Would like some testing of the PowerPC boot wrapper and
a LE target before sending it upstream.
arch/powerpc/boot/Makefile | 4 ++-
lib/zlib_inflate/inffast.c | 48 +++++++++++++++++++++++++++++++++----------
2 files changed, 40 insertions(+), 12 deletions(-)
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index 9ae7b7e..98e4c4f 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -20,7 +20,7 @@
all: $(obj)/zImage
BOOTCFLAGS := -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs \
- -fno-strict-aliasing -Os -msoft-float -pipe \
+ -fno-strict-aliasing -Os -msoft-float -pipe -D__KERNEL__\
-fomit-frame-pointer -fno-builtin -fPIC -nostdinc \
-isystem $(shell $(CROSS32CC) -print-file-name=include)
BOOTAFLAGS := -D__ASSEMBLY__ $(BOOTCFLAGS) -traditional -nostdinc
@@ -34,6 +34,8 @@ BOOTCFLAGS += -fno-stack-protector
endif
BOOTCFLAGS += -I$(obj) -I$(srctree)/$(obj)
+BOOTCFLAGS += -include include/linux/autoconf.h -Iarch/powerpc/include
+BOOTCFLAGS += -Iinclude
DTS_FLAGS ?= -p 1024
diff --git a/lib/zlib_inflate/inffast.c b/lib/zlib_inflate/inffast.c
index 8550b0c..0c7fa3d 100644
--- a/lib/zlib_inflate/inffast.c
+++ b/lib/zlib_inflate/inffast.c
@@ -4,6 +4,7 @@
*/
#include <linux/zutil.h>
+#include <asm/unaligned.h>
#include "inftrees.h"
#include "inflate.h"
#include "inffast.h"
@@ -24,9 +25,11 @@
#ifdef POSTINC
# define OFF 0
# define PUP(a) *(a)++
+# define UP_UNALIGNED(a) get_unaligned((a)++)
#else
# define OFF 1
# define PUP(a) *++(a)
+# define UP_UNALIGNED(a) get_unaligned(++(a))
#endif
/*
@@ -239,18 +242,41 @@ void inflate_fast(z_streamp strm, unsigned start)
}
}
else {
+ unsigned short *sout;
+ unsigned long loops;
+
from = out - dist; /* copy direct from output */
- do { /* minimum length is three */
- PUP(out) = PUP(from);
- PUP(out) = PUP(from);
- PUP(out) = PUP(from);
- len -= 3;
- } while (len > 2);
- if (len) {
- PUP(out) = PUP(from);
- if (len > 1)
- PUP(out) = PUP(from);
- }
+ /* minimum length is three */
+ /* Align out addr */
+ if (!((long)(out - 1 + OFF)) & 1) {
+ PUP(out) = PUP(from);
+ len--;
+ }
+ sout = (unsigned short *)(out - OFF);
+ if (dist > 2 ) {
+ unsigned short *sfrom;
+
+ sfrom = (unsigned short *)(from - OFF);
+ loops = len >> 1;
+ do
+ PUP(sout) = UP_UNALIGNED(sfrom);
+ while (--loops);
+ out = (unsigned char *)sout + OFF;
+ from = (unsigned char *)sfrom + OFF;
+ } else { /* dist == 1 or dist == 2 */
+ unsigned short pat16;
+
+ pat16 = *(sout-2+2*OFF);
+ if (dist == 1)
+ pat16 = (pat16 & 0xff) | ((pat16 & 0xff ) << 8);
+ loops = len >> 1;
+ do
+ PUP(sout) = pat16;
+ while (--loops);
+ out = (unsigned char *)sout + OFF;
+ }
+ if (len & 1)
+ PUP(out) = PUP(from);
}
}
else if ((op & 64) == 0) { /* 2nd level distance code */
--
1.6.4.4
^ permalink raw reply related
* Re: [PATCH 3/8] hvc_console: make the ops pointer const.
From: Christian Borntraeger @ 2009-11-10 8:56 UTC (permalink / raw)
To: Rusty Russell; +Cc: Amit Shah, linuxppc-dev, virtualization
In-Reply-To: <1257834450..rusty@rustcorp.com.au>
Am Dienstag 10 November 2009 07:27:30 schrieb Rusty Russell:
> This is nicer for modern R/O protection. And noone needs it non-const, so
> constify the callers as well.
>
> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
> To: Christian Borntraeger <borntraeger@de.ibm.com>
> Cc: linuxppc-dev@ozlabs.org
> ---
> drivers/char/hvc_beat.c | 2 +-
> drivers/char/hvc_console.c | 7 ++++---
> drivers/char/hvc_console.h | 7 ++++---
> drivers/char/hvc_iseries.c | 2 +-
> drivers/char/hvc_iucv.c | 2 +-
> drivers/char/hvc_rtas.c | 2 +-
> drivers/char/hvc_udbg.c | 2 +-
> drivers/char/hvc_vio.c | 2 +-
> drivers/char/hvc_xen.c | 2 +-
> drivers/char/virtio_console.c | 2 +-
> 10 files changed, 16 insertions(+), 14 deletions(-)
Ok, I started with patches 1-3. I like the result.
So for the first 3 patches you can add
Tested-by: Christian Borntraeger <borntraeger@de.ibm.com> (on s390)
Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com>
I have not yet looked at the other ones, but I will try to find some time to
look at them.
Christian
^ permalink raw reply
* Re: [PATCH 0/8] 8xx: Misc fixes for buggy insn
From: Joakim Tjernlund @ 2009-11-10 8:27 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev@ozlabs.org, Rex Feany
In-Reply-To: <20091109230004.GA24671@loki.buserror.net>
Scott Wood <scottwood@freescale.com> wrote on 10/11/2009 00:00:04:
>
> On Mon, Nov 09, 2009 at 03:53:21PM -0600, Scott Wood wrote:
> > On Fri, Nov 06, 2009 at 10:29:44AM +0100, Joakim Tjernlund wrote:
> > > > > With this, the kernel hangs after "Mount-cache hash table entries: 512".
> > > >
> > > > Somewhat surprising result. I didn't expect you would even hit this
> > > > condition now as we haven't enabled the use of dcbX insn yet.
> > > > The only thing I can think of is the you hit the 0x00f0 due to other
> > > > dcbX insn use and the kernel managed to fixup this in the page fault handler
> > > > by pure luck before.
> >
> > It's bizarre -- it still happens even if I revert the branch to FixupDAR.
> > However, if I comment out the final "b 151b", it stops happening. It also
> > stops happening sometimes depending on where I stick printk()s to debug
> > this.
> >
> > So it may be an unrelated issue that just got perturbed somehow.
>
> OK, figured it out. The fixup code pushed things around so that in
Cool!
> syscall_exit_cont, SRR0/SRR1 were being loaded immediately prior to a page
> boundary, with the rfi after the page boundary. On crossing the boundary,
> we take an ITLB miss (which goes from possibility to certainty with the
> CPU15 workaround), and SRR0/SRR1 get clobbered.
I am not familiar with CPU15 since we never had that problem.
The patch series is OK then, but one need to add some CPU15 love?
>
> I suppose we'll need to find all places where we do rfi with the MMU
> enabled, and ensure acceptable alignment. :-(
Ouch, but it can't be that many places though.
>
> Either that, or require that the kernel text be pinned, though that does not
> interact well with CPU15.
Why does not pinning interact well with CPU15? If pinned, you never get
a TLB miss for kernel text so that should mitigate the CPU15 problem.
Jocke
^ permalink raw reply
* Re: [PATCH 0/8] 8xx: Misc fixes for buggy insn
From: Scott Wood @ 2009-11-09 23:00 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: linuxppc-dev@ozlabs.org, Rex Feany
In-Reply-To: <20091109215321.GA4351@loki.buserror.net>
On Mon, Nov 09, 2009 at 03:53:21PM -0600, Scott Wood wrote:
> On Fri, Nov 06, 2009 at 10:29:44AM +0100, Joakim Tjernlund wrote:
> > > > With this, the kernel hangs after "Mount-cache hash table entries: 512".
> > >
> > > Somewhat surprising result. I didn't expect you would even hit this
> > > condition now as we haven't enabled the use of dcbX insn yet.
> > > The only thing I can think of is the you hit the 0x00f0 due to other
> > > dcbX insn use and the kernel managed to fixup this in the page fault handler
> > > by pure luck before.
>
> It's bizarre -- it still happens even if I revert the branch to FixupDAR.
> However, if I comment out the final "b 151b", it stops happening. It also
> stops happening sometimes depending on where I stick printk()s to debug
> this.
>
> So it may be an unrelated issue that just got perturbed somehow.
OK, figured it out. The fixup code pushed things around so that in
syscall_exit_cont, SRR0/SRR1 were being loaded immediately prior to a page
boundary, with the rfi after the page boundary. On crossing the boundary,
we take an ITLB miss (which goes from possibility to certainty with the
CPU15 workaround), and SRR0/SRR1 get clobbered.
I suppose we'll need to find all places where we do rfi with the MMU
enabled, and ensure acceptable alignment. :-(
Either that, or require that the kernel text be pinned, though that does not
interact well with CPU15.
-Scott
^ permalink raw reply
* Fw: Help with SPI node
From: Ravi Shekhar @ 2009-11-10 3:36 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 529 bytes --]
I'm attempting to get SPI to work on my embedded design
that is based on the mpc8313erbd reference board wiht a
2.6.27 kernel. I cannot open the SPI device.
Tracing through the kernel code, it looks like the device is
not being found in the DTB file. However there is a
SPI node in there already described. Our boards is a
SPI master, and the device we will attach is a SPI
slave. Could someone elaborate on what is needed in
the DTS file to have our SPI driver work and respond to an
open() call?
Thanks
-Ravi
[-- Attachment #2: Type: text/html, Size: 748 bytes --]
^ permalink raw reply
* Re: Invalidate Data Cache from User Space
From: Josh Boyer @ 2009-11-10 1:15 UTC (permalink / raw)
To: Jonathan Haws; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <BB99A6BA28709744BF22A68E6D7EB51F03310AFEC3@midas.usurf.usu.edu>
On Mon, Nov 09, 2009 at 11:10:42AM -0700, Jonathan Haws wrote:
>All,
>What is happening is the dcbi instruction will fail. I get an Illegal Instruction message on the console and my program exits.
>
>Is there a reason I cannot call dbci from a user space application, or is there something wrong in my code? Even better, is there a working and tested function that I can call from user space to invalidate a portion of the data cache?
dcbi is a priviledged instruction on 4xx. You can only execute it from
supervisor mode (kernel).
josh
^ permalink raw reply
* RE: [spi-devel-general] [PATCH v4] xilinx_spi: Splitted into generic, of and platform driver, added support for DS570
From: Stephen Neuendorffer @ 2009-11-10 0:59 UTC (permalink / raw)
To: Grant Likely, Richard Röjfors
Cc: John Linn, spi-devel-general, Andrew Morton, dbrownell,
linuxppc-dev
In-Reply-To: <fa686aa40911091321w187fe85fl4e6d9f36f5966f34@mail.gmail.com>
> -----Original Message-----
> From: linuxppc-dev-bounces+stephen=3Dneuendorffer.name@lists.ozlabs.org [=
mailto:linuxppc-dev-
> bounces+stephen=3Dneuendorffer.name@lists.ozlabs.org] On Behalf Of Grant =
Likely
> Sent: Monday, November 09, 2009 1:22 PM
> To: Richard R=F6jfors
> Cc: spi-devel-general@lists.sourceforge.net; Andrew Morton; dbrownell@use=
rs.sourceforge.net; John
> Linn; linuxppc-dev@ozlabs.org
> Subject: Re: [spi-devel-general] [PATCH v4] xilinx_spi: Splitted into gen=
eric, of and platform
> driver, added support for DS570
> =
> Oops, I replied to the original version, but missed the subsequent
> versions. Looks like some of my comments still apply though.
> Overall, the patch changes too many things all at once. You should
> look at splitting it up. At the very least the io accessor changes
> should be done in a separate patch.
> =
> On Mon, Sep 28, 2009 at 7:22 AM, Richard R=F6jfors
> <richard.rojfors@mocean-labs.com> wrote:
> > @@ -227,6 +227,21 @@ config SPI_XILINX
> > =A0 =A0 =A0 =A0 =A0See the "OPB Serial Peripheral Interface (SPI) (v1.0=
0e)"
> > =A0 =A0 =A0 =A0 =A0Product Specification document (DS464) for hardware =
details.
> >
> > + =A0 =A0 =A0 =A0 Or for the DS570, see "XPS Serial Peripheral Interfac=
e (SPI) (v2.00b)"
> > +
> > +config SPI_XILINX_OF
> > + =A0 =A0 =A0 tristate "Xilinx SPI controller OF device"
> > + =A0 =A0 =A0 depends on SPI_XILINX && XILINX_VIRTEX
> > + =A0 =A0 =A0 help
> > + =A0 =A0 =A0 =A0 This is the OF driver for the SPI controller IP from =
the Xilinx EDK.
> > +
> > +config SPI_XILINX_PLTFM
> > + =A0 =A0 =A0 tristate "Xilinx SPI controller platform device"
> > + =A0 =A0 =A0 depends on SPI_XILINX
> > + =A0 =A0 =A0 help
> > + =A0 =A0 =A0 =A0 This is the platform driver for the SPI controller IP=
> > + =A0 =A0 =A0 =A0 from the Xilinx EDK.
> > +
> =
> Personally, I don't think it is necessary to present these options to
> the user. I think they can be auto-selected depending on CONFIG_OF
> and CONFIG_PLATFORM.
And in any event, OF should work for MICROBLAZE, too...
Steve
=
This email and any attachments are intended for the sole use of the named r=
ecipient(s) and contain(s) confidential information that may be proprietary=
, privileged or copyrighted under applicable law. If you are not the intend=
ed recipient, do not read, copy, or forward this email message or any attac=
hments. Delete this email message and any attachments immediately.
^ permalink raw reply
* Re: [PATCH] spi/mpc52xx: replace printk with dev_err
From: Grant Likely @ 2009-11-09 19:12 UTC (permalink / raw)
To: Wolfram Sang; +Cc: linuxppc-dev
In-Reply-To: <1257328160-24955-1-git-send-email-w.sang@pengutronix.de>
On Wed, Nov 4, 2009 at 2:49 AM, Wolfram Sang <w.sang@pengutronix.de> wrote:
> To easily identify which device has problems.
>
> Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
> Cc: Grant Likely <grant.likely@secretlab.ca>
> ---
> =A0drivers/spi/mpc52xx_psc_spi.c | =A0 =A05 ++---
> =A01 files changed, 2 insertions(+), 3 deletions(-)
picked up. Thanks
g.
^ permalink raw reply
* Re: [spi-devel-general] [PATCH v4] xilinx_spi: Splitted into generic, of and platform driver, added support for DS570
From: Grant Likely @ 2009-11-09 21:21 UTC (permalink / raw)
To: Richard Röjfors
Cc: spi-devel-general, Andrew Morton, dbrownell, John Linn,
linuxppc-dev
In-Reply-To: <4AC0C699.2070506@mocean-labs.com>
Oops, I replied to the original version, but missed the subsequent
versions. Looks like some of my comments still apply though.
Overall, the patch changes too many things all at once. You should
look at splitting it up. At the very least the io accessor changes
should be done in a separate patch.
On Mon, Sep 28, 2009 at 7:22 AM, Richard R=F6jfors
<richard.rojfors@mocean-labs.com> wrote:
> @@ -227,6 +227,21 @@ config SPI_XILINX
> =A0 =A0 =A0 =A0 =A0See the "OPB Serial Peripheral Interface (SPI) (v1.00e=
)"
> =A0 =A0 =A0 =A0 =A0Product Specification document (DS464) for hardware de=
tails.
>
> + =A0 =A0 =A0 =A0 Or for the DS570, see "XPS Serial Peripheral Interface =
(SPI) (v2.00b)"
> +
> +config SPI_XILINX_OF
> + =A0 =A0 =A0 tristate "Xilinx SPI controller OF device"
> + =A0 =A0 =A0 depends on SPI_XILINX && XILINX_VIRTEX
> + =A0 =A0 =A0 help
> + =A0 =A0 =A0 =A0 This is the OF driver for the SPI controller IP from th=
e Xilinx EDK.
> +
> +config SPI_XILINX_PLTFM
> + =A0 =A0 =A0 tristate "Xilinx SPI controller platform device"
> + =A0 =A0 =A0 depends on SPI_XILINX
> + =A0 =A0 =A0 help
> + =A0 =A0 =A0 =A0 This is the platform driver for the SPI controller IP
> + =A0 =A0 =A0 =A0 from the Xilinx EDK.
> +
Personally, I don't think it is necessary to present these options to
the user. I think they can be auto-selected depending on CONFIG_OF
and CONFIG_PLATFORM.
> +struct xilinx_spi {
> + =A0 =A0 =A0 /* bitbang has to be first */
> + =A0 =A0 =A0 struct spi_bitbang bitbang;
> + =A0 =A0 =A0 struct completion done;
> + =A0 =A0 =A0 struct resource mem; /* phys mem */
> + =A0 =A0 =A0 void __iomem =A0 =A0*regs; =A0/* virt. address of the contr=
ol registers */
> + =A0 =A0 =A0 u32 irq;
> + =A0 =A0 =A0 u8 *rx_ptr; =A0 =A0 =A0 =A0 =A0 =A0 /* pointer in the Tx bu=
ffer */
> + =A0 =A0 =A0 const u8 *tx_ptr; =A0 =A0 =A0 /* pointer in the Rx buffer *=
/
> + =A0 =A0 =A0 int remaining_bytes; =A0 =A0/* the number of bytes left to =
transfer */
> + =A0 =A0 =A0 /* offset to the XSPI regs, these might vary... */
> + =A0 =A0 =A0 u8 bits_per_word;
> + =A0 =A0 =A0 bool big_endian; =A0 =A0 =A0 =A0/* The device could be acce=
ssed big or little
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* endian
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0*/
> +};
> +
Why is the definition of xilinx_spi moved?
> =A0/* Register definitions as per "OPB Serial Peripheral Interface (SPI) =
(v1.00e)
> =A0* Product Specification", DS464
> =A0*/
> -#define XSPI_CR_OFFSET =A0 =A0 =A0 =A0 0x62 =A0 =A0/* 16-bit Control Reg=
ister */
> +#define XSPI_CR_OFFSET =A0 =A0 =A0 =A0 0x60 =A0 =A0/* Control Register *=
/
>
> =A0#define XSPI_CR_ENABLE =A0 =A0 =A0 =A0 0x02
> =A0#define XSPI_CR_MASTER_MODE =A0 =A00x04
> @@ -40,8 +53,9 @@
> =A0#define XSPI_CR_RXFIFO_RESET =A0 0x40
> =A0#define XSPI_CR_MANUAL_SSELECT 0x80
> =A0#define XSPI_CR_TRANS_INHIBIT =A00x100
> +#define XSPI_CR_LSB_FIRST =A0 =A0 =A00x200
>
> -#define XSPI_SR_OFFSET =A0 =A0 =A0 =A0 0x67 =A0 =A0/* 8-bit Status Regis=
ter */
> +#define XSPI_SR_OFFSET =A0 =A0 =A0 =A0 0x64 =A0 =A0/* Status Register */
>
> =A0#define XSPI_SR_RX_EMPTY_MASK =A00x01 =A0 =A0/* Receive FIFO is empty =
*/
> =A0#define XSPI_SR_RX_FULL_MASK =A0 0x02 =A0 =A0/* Receive FIFO is full *=
/
> @@ -49,8 +63,8 @@
> =A0#define XSPI_SR_TX_FULL_MASK =A0 0x08 =A0 =A0/* Transmit FIFO is full =
*/
> =A0#define XSPI_SR_MODE_FAULT_MASK =A0 =A0 =A0 =A00x10 =A0 =A0/* Mode fau=
lt error */
>
> -#define XSPI_TXD_OFFSET =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A00x6b =A0 =A0/* 8-=
bit Data Transmit Register */
> -#define XSPI_RXD_OFFSET =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A00x6f =A0 =A0/* 8-=
bit Data Receive Register */
> +#define XSPI_TXD_OFFSET =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A00x68 =A0 =A0/* Da=
ta Transmit Register */
> +#define XSPI_RXD_OFFSET =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A00x6C =A0 =A0/* Da=
ta Receive Register */
>
> =A0#define XSPI_SSR_OFFSET =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A00x70 =A0 =A0/* =
32-bit Slave Select Register */
>
> @@ -70,43 +84,72 @@
> =A0#define XSPI_INTR_TX_UNDERRUN =A0 =A0 =A0 =A0 =A00x08 =A0 =A0/* TxFIFO=
was underrun */
> =A0#define XSPI_INTR_RX_FULL =A0 =A0 =A0 =A0 =A0 =A0 =A00x10 =A0 =A0/* Rx=
FIFO is full */
> =A0#define XSPI_INTR_RX_OVERRUN =A0 =A0 =A0 =A0 =A0 0x20 =A0 =A0/* RxFIFO=
was overrun */
> +#define XSPI_INTR_TX_HALF_EMPTY =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A00x40 =A0 =
=A0/* TxFIFO is half empty */
>
> =A0#define XIPIF_V123B_RESETR_OFFSET =A0 =A0 =A00x40 =A0 =A0/* IPIF reset=
register */
> =A0#define XIPIF_V123B_RESET_MASK =A0 =A0 =A0 =A0 0x0a =A0 =A0/* the valu=
e to write */
>
> -struct xilinx_spi {
> - =A0 =A0 =A0 /* bitbang has to be first */
> - =A0 =A0 =A0 struct spi_bitbang bitbang;
> - =A0 =A0 =A0 struct completion done;
> +/* to follow are some functions that does little of big endian read and
> + * write depending on the config of the device.
> + */
> +static inline void xspi_write8(struct xilinx_spi *xspi, u32 offs, u8 val=
)
> +{
> + =A0 =A0 =A0 iowrite8(val, xspi->regs + offs + ((xspi->big_endian) ? 3 :=
0));
> +}
>
> - =A0 =A0 =A0 void __iomem =A0 =A0*regs; =A0/* virt. address of the contr=
ol registers */
> +static inline void xspi_write16(struct xilinx_spi *xspi, u32 offs, u16 v=
al)
> +{
> + =A0 =A0 =A0 if (xspi->big_endian)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 iowrite16be(val, xspi->regs + offs + 2);
> + =A0 =A0 =A0 else
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 iowrite16(val, xspi->regs + offs);
> +}
>
> - =A0 =A0 =A0 u32 =A0 =A0 =A0 =A0 =A0 =A0 irq;
> +static inline void xspi_write32(struct xilinx_spi *xspi, u32 offs, u32 v=
al)
> +{
> + =A0 =A0 =A0 if (xspi->big_endian)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 iowrite32be(val, xspi->regs + offs);
> + =A0 =A0 =A0 else
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 iowrite32(val, xspi->regs + offs);
> +}
>
> - =A0 =A0 =A0 u32 =A0 =A0 =A0 =A0 =A0 =A0 speed_hz; /* SCK has a fixed fr=
equency of speed_hz Hz */
> +static inline u8 xspi_read8(struct xilinx_spi *xspi, u32 offs)
> +{
> + =A0 =A0 =A0 return ioread8(xspi->regs + offs + ((xspi->big_endian) ? 3 =
: 0));
> +}
>
> - =A0 =A0 =A0 u8 *rx_ptr; =A0 =A0 =A0 =A0 =A0 =A0 /* pointer in the Tx bu=
ffer */
> - =A0 =A0 =A0 const u8 *tx_ptr; =A0 =A0 =A0 /* pointer in the Rx buffer *=
/
> - =A0 =A0 =A0 int remaining_bytes; =A0 =A0/* the number of bytes left to =
transfer */
> -};
> +static inline u16 xspi_read16(struct xilinx_spi *xspi, u32 offs)
> +{
> + =A0 =A0 =A0 if (xspi->big_endian)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 return ioread16be(xspi->regs + offs + 2);
> + =A0 =A0 =A0 else
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 return ioread16(xspi->regs + offs);
> +}
> +
> +static inline u32 xspi_read32(struct xilinx_spi *xspi, u32 offs)
> +{
> + =A0 =A0 =A0 if (xspi->big_endian)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 return ioread32be(xspi->regs + offs);
> + =A0 =A0 =A0 else
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 return ioread32(xspi->regs + offs);
> +}
Ah, you changed these to functions instead of macros. I like.
However, as you suggested elsewhere in this thread, you could change
these to callbacks and then eliminate the if/else statements. I think
that is the approach you should use. I don't think you need to worry
about it being slower. Any extra cycles for jumping to a callback
will be far dwarfed by the number of cycles it takes to complete an
SPI transfer.
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Invalidate Data Cache from User Space
From: Jonathan Haws @ 2009-11-09 18:10 UTC (permalink / raw)
To: linuxppc-dev@lists.ozlabs.org
All,
I have a routine to invalidate the data cache from user space (since I do n=
ot believe there is a standard routine I can use outside of kernel space??)=
.
Here is the code:
.text;
.globl cacheInvalidate405;
cacheInvalidate405:
/*
* r3 =3D Data cache
* r4 =3D address
* r5 =3D number of bytes
*/
cmpwi r5,0 /* make sure number of bytes is > 0 */
beq invalDone
add r6,r4,r5
addi r6,r6,31
rlwinm r6,r6,0,0,26 /* end addr to start of next cache line=
*/
rlwinm r7,r4,0,0,26 /* start address back to start of line =
*/
sub r6,r6,r7
srawi r6,r6,5 /* divide by 32 to get number of lines =
*/
mtctr r6
invalLoop:
dcbi r0,r4 /* THIS INSTRUCTION FAILS! */
addi r4,r4,32
bdnz invalLoop
sync
invalDone:
blr
.size cacheInvalidate405, . - cacheInvalidate405
What is happening is the dcbi instruction will fail. I get an Illegal Inst=
ruction message on the console and my program exits.
Is there a reason I cannot call dbci from a user space application, or is t=
here something wrong in my code? Even better, is there a working and teste=
d function that I can call from user space to invalidate a portion of the d=
ata cache?
Thanks!
Jonathan
^ permalink raw reply
* Disable Caching for mmap() address
From: Jonathan Haws @ 2009-11-09 23:21 UTC (permalink / raw)
To: linuxppc-dev@lists.ozlabs.org
All,
I would like to disable caching for an address that was returned from a cal=
l to mmap(). I am using this address for DMA operations in user space and =
want to make sure that the data cache is turned off for that buffer.
The way this works is the driver simply takes an address I provide and begi=
ns a DMA operation to that location in RAM (I have ensured that this is a p=
hysical address I am passing already). When the DMA is complete, an interr=
upt fires and the ISR gives a semaphore that the user space application is =
pending on (RT_SEM from Xenomai). I have tried simply calling a cache inva=
lidate routine in the ISR before I give the semaphore, but the kernel crash=
es when I try to call that routine - my guess it because the kernel does no=
t have direct access to that location in memory (only my application does, =
according to the MMU).
Anyway, all I want to do is make sure that the buffer is never stored in th=
e cache and that I always fetch it from RAM. How can I specify that using =
mmap() on the /dev/mem device, or is there a better way to accomplish this?
Thanks,
Jonathan
^ 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