* Re: [patch 08/18] PS3: Kexec support
From: Geoff Levand @ 2007-06-07 1:33 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20070607112541.5a296cd1.sfr@canb.auug.org.au>
Stephen Rothwell wrote:
> Hi Geoff,
>
> On Wed, 06 Jun 2007 14:55:00 -0700 Geoff Levand <geoffrey.levand@am.sony.com> wrote:
>>
>> Michael Ellerman wrote:
>> > On Tue, 2007-06-05 at 20:00 -0700, Geoff Levand wrote:
>> >> Fixup the core platform parts needed for kexec to work on the PS3.
>> >> - Setup ps3_hpte_clear correctly.
>> >> - Mask interrupts on irq removal.
>> >> - Release all hypervisor resources.
>> >
>> > The irq changes might be kexec related, but it's a mess to review. You
>> > seem to moving a bunch of code around in the patch as well.
>>
>> Yes, I need to move the static chip_mask routines up so they would be
>> defined before the irq setup/destroy routines.
>
> I think Michael's point then is that if you submitted a separate
> preceding patch that just moves stuff around without any other changes
> (if at all possible) then reviewing the changes in this would be much
> easier (and our confidence would be higher).
Yes, sorry, I understood. I've already split it up for the next round.
-Geoff
^ permalink raw reply
* Re: [PATCH] fix stolen time for SMT without LPAR
From: Paul Mackerras @ 2007-06-07 1:33 UTC (permalink / raw)
To: Michael Neuling; +Cc: linuxppc-dev
In-Reply-To: <16370.1180069711@neuling.org>
Michael Neuling writes:
> - if (!cpu_has_feature(CPU_FTR_PURR))
> + if (!cpu_has_feature(CPU_FTR_PURR) &&
> + !firmware_has_feature(FW_FEATURE_SPLPAR))
> return;
> for_each_possible_cpu(cpu)
> spin_lock_init(&per_cpu(cpu_purr_data, cpu).lock);
This means that on a machine with SPLPAR but not a PURR, e.g. a JS21,
we'll try to read the PURR register and do the stolen time calculation
with whatever value was in the register before the mfspr from the
PURR. If we're going to make this change then we also need to add
code to do the H_PURR hcall instead of reading the PURR directly on
such machines.
Paul.
^ permalink raw reply
* Re: [PATCH] powerpc: add table of contents to booting-without-of-txt
From: David Gibson @ 2007-06-07 1:58 UTC (permalink / raw)
To: Stuart Yoder; +Cc: linuxppc-dev, paulus
In-Reply-To: <200706051829.l55ITEAR028492@ld0164-tx32.am.freescale.net>
On Tue, Jun 05, 2007 at 01:29:14PM -0500, Stuart Yoder wrote:
> Add table of contents.
>
> Signed-off-by: Stuart Yoder <stuart.yoder@freescale.com>
> ---
>
> I think this should help make the doc more easily navigated and will help
> make the structure visible so someone editing will know where to put
> stuff.
I like it in theory. Whether it will remain updated in sync with the
rest of the document remains to be seen...
Acked-by: David Gibson <david@gibson.dropbear.id.au>
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* dtc: Fix recognition of whitespace characters
From: David Gibson @ 2007-06-07 2:07 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev, Mark Lacas
At present, the lexer in dtc recognizes only space, tab and newline as
whitespace characters. This is broken; in particular this means that
dtc will get syntax errors on files with DOS-style (CR-LF) newlines.
This patch fixes the problem, using flex's built-int [:space:]
character class.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
---
Jon, please apply.
Index: dtc/dtc-lexer.l
===================================================================
--- dtc.orig/dtc-lexer.l 2007-06-07 12:00:31.000000000 +1000
+++ dtc/dtc-lexer.l 2007-06-07 12:03:31.000000000 +1000
@@ -27,7 +27,7 @@
PROPCHAR [a-zA-Z0-9,._+*#?-]
UNITCHAR [0-9a-f,]
-WS [ \t\n]
+WS [[:space:]]
REFCHAR ({PROPCHAR}|{UNITCHAR}|[/@])
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [patch 08/18] PS3: Kexec support
From: Michael Ellerman @ 2007-06-07 2:31 UTC (permalink / raw)
To: Geoff Levand; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <46672D34.8010808@am.sony.com>
[-- Attachment #1: Type: text/plain, Size: 2375 bytes --]
On Wed, 2007-06-06 at 14:55 -0700, Geoff Levand wrote:
> Michael Ellerman wrote:
> >> --- a/arch/powerpc/platforms/ps3/htab.c
> >> +++ b/arch/powerpc/platforms/ps3/htab.c
> >> @@ -234,10 +234,18 @@ static void ps3_hpte_invalidate(unsigned
> >>
> >> static void ps3_hpte_clear(void)
> >> {
> >> - /* Make sure to clean up the frame buffer device first */
> >> - ps3fb_cleanup();
> >> + int result;
> >>
> >> - lv1_unmap_htab(htab_addr);
> >> + DBG(" -> %s:%d\n", __func__, __LINE__);
> >> +
> >> + result = lv1_unmap_htab(htab_addr);
> >> + BUG_ON(result);
> >> +
> >> + ps3_mm_shutdown();
> >> +
> >> + ps3_mm_vas_destroy();
> >> +
> >> + DBG(" <- %s:%d\n", __func__, __LINE__);
> >> }
> >
> > Do you really want to be calling DBG() here? Hmm, it looks like it
> > doesn't actually do anything?
>
>
> Sure, it uses udbg_printf, and works OK.
Which is hooked up to what?
> >> +static void ps3_chip_mask(unsigned int virq)
> >> +{
> >> + struct ps3_private *pd = get_irq_chip_data(virq);
> >> + u64 bit = 0x8000000000000000UL >> virq;
> >> + u64 *p = &pd->bmp.mask;
> >> + u64 old;
> >> + unsigned long flags;
> >> +
> >> + pr_debug("%s:%d: cpu %u, virq %d\n", __func__, __LINE__, pd->cpu, virq);
> >> +
> >> + local_irq_save(flags);
> >> + asm volatile(
> >> + "1: ldarx %0,0,%3\n"
> >> + "andc %0,%0,%2\n"
> >> + "stdcx. %0,0,%3\n"
> >> + "bne- 1b"
> >> + : "=&r" (old), "+m" (*p)
> >> + : "r" (bit), "r" (p)
> >> + : "cc" );
> >> +
> >> + lv1_did_update_interrupt_mask(pd->node, pd->cpu);
> >> + local_irq_restore(flags);
> >
> > How is this different from set_bit() ? (asm-powerpc/bitops.h)
> >
> > ps. now that I see you're just moving this code around someone's
> > probably already asked that question.
>
>
> This was contributed by Ben H as the fastest way. I think the
> reason was that we could minimize the time between local_irq_save
> and local_irq_restore?
To save ~10 instructions? Followed by a HV call? I guess Ben has some
really good benchmark data to support it ;)
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [patch 08/18] PS3: Kexec support
From: Stephen Rothwell @ 2007-06-07 2:48 UTC (permalink / raw)
To: Geoff Levand; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <46676051.5010603@am.sony.com>
[-- Attachment #1: Type: text/plain, Size: 295 bytes --]
On Wed, 06 Jun 2007 18:33:05 -0700 Geoff Levand <geoffrey.levand@am.sony.com> wrote:
>
> Yes, sorry, I understood. I've already split it up for the next round.
Excellent, thanks.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [patch 08/18] PS3: Kexec support
From: Benjamin Herrenschmidt @ 2007-06-07 2:54 UTC (permalink / raw)
To: michael; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <1181183468.4166.5.camel@concordia.ozlabs.ibm.com>
On Thu, 2007-06-07 at 12:31 +1000, Michael Ellerman wrote:
> > >> + pr_debug("%s:%d: cpu %u, virq %d\n", __func__, __LINE__,
> pd->cpu, virq);
> > >> +
> > >> + local_irq_save(flags);
> > >> + asm volatile(
> > >> + "1: ldarx %0,0,%3\n"
> > >> + "andc %0,%0,%2\n"
> > >> + "stdcx. %0,0,%3\n"
> > >> + "bne- 1b"
> > >> + : "=&r" (old), "+m" (*p)
> > >> + : "r" (bit), "r" (p)
> > >> + : "cc" );
> > >> +
> > >> + lv1_did_update_interrupt_mask(pd->node, pd->cpu);
> > >> + local_irq_restore(flags);
> > >
> > > How is this different from set_bit() ? (asm-powerpc/bitops.h)
> > >
> > > ps. now that I see you're just moving this code around someone's
> > > probably already asked that question.
Actually the above is clear_bit :-)
That would thus be something around the lines of:
clear_bit(&pd->bmp.mask, 63 - virq);
Geoff, feel free to replace it with the clear_bit if you think it's
nicer that way :-) (and double check I didn't smoke crack when doing
the above conversion).
The other one in unmask would be set_bit() of course.
Ben.
^ permalink raw reply
* Re: MPC8349ea Random Device Generator driver
From: Kim Phillips @ 2007-06-07 2:55 UTC (permalink / raw)
To: Philippe Lachenal; +Cc: linuxppc-dev, sl
In-Reply-To: <BAY122-F18923A7AA6D3A4D96A360085200@phx.gbl>
On Tue, 05 Jun 2007 17:42:08 +0200
"Philippe Lachenal" <philippe.lachenal@hotmail.fr> wrote:
> Hello !
>
> I've made a driver for the MPC8349ea Random Device Generator, and I
> therefore submit it to your impartial judgment.. ;)
> thanks a lot !
>
> Lachenal Philippe
>
the Random Device Generator, eh? didn't know we had one of those. ;)
The RNG h/w block in question shares registers, initialization and
configuration with what's known as the Freescale SEC device (a.k.a.
talitos). Talitos does crypto and public key ops, and some
implementations don't have an RNG EU. There needs to be one driver for
the SEC, and it's not an rng driver.
Kim
^ permalink raw reply
* Re: dtc: Fix recognition of whitespace characters
From: Jon Loeliger @ 2007-06-07 2:56 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev, Mark Lacas
In-Reply-To: <20070607020735.GD24230@localhost.localdomain>
So, like, the other day David Gibson mumbled:
> At present, the lexer in dtc recognizes only space, tab and newline as
> whitespace characters. This is broken; in particular this means that
> dtc will get syntax errors on files with DOS-style (CR-LF) newlines.
Doctor, it hurts when I use DOS. :-)
> This patch fixes the problem, using flex's built-int [:space:]
> character class.
>
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
> ---
>
> Jon, please apply.
Applied.
Thanks,
jdl
^ permalink raw reply
* [PATCH]: Add 8548 pcie bus number workaround
From: Zang Roy-r61911 @ 2007-06-07 3:13 UTC (permalink / raw)
To: linuxppc-dev list; +Cc: Paul Mackerras
From: Zang Roy-r61911 <tie-fei.zang@freescale.com>
Remove legacy pcie support for 8641 chip.
General PCI code can fully support 8641 Rev2.0 chip.
For 8548 PEX controller, PCIE host controller configure
space can only be accessed as "bus->number = 0" in
the PCI architecture. So "bus->number == hose->bus_offset"
judgment is added.
Some minor space indentation clean up.
---
arch/powerpc/sysdev/fsl_pcie.c | 28 ++++++++++++++--------------
1 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_pcie.c b/arch/powerpc/sysdev/fsl_pcie.c
index 041c07e..79e9546 100644
--- a/arch/powerpc/sysdev/fsl_pcie.c
+++ b/arch/powerpc/sysdev/fsl_pcie.c
@@ -47,16 +47,16 @@ indirect_read_config_pcie(struct pci_bus *bus, unsigned int devfn, int offset,
return PCIBIOS_DEVICE_NOT_FOUND;
PCIE_FIX;
- if (bus->number == 0xff) {
+ if (bus->number == hose->bus_offset) {
PCI_CFG_OUT(hose->cfg_addr,
- (0x80000000 | ((offset & 0xf00) << 16) |
- ((bus->number - hose->bus_offset) << 16)
- | (devfn << 8) | ((offset & 0xfc) )));
+ (0x80000000 | ((offset & 0xf00) << 16) |
+ ((bus->number - hose->bus_offset) << 16)
+ | (devfn << 8) | ((offset & 0xfc) )));
} else {
PCI_CFG_OUT(hose->cfg_addr,
- (0x80000001 | ((offset & 0xf00) << 16) |
- ((bus->number - hose->bus_offset) << 16)
- | (devfn << 8) | ((offset & 0xfc) )));
+ (0x80000000 | ((offset & 0xf00) << 16) |
+ (bus->number << 16)
+ | (devfn << 8) | ((offset & 0xfc) )));
}
/*
@@ -98,16 +98,16 @@ indirect_write_config_pcie(struct pci_bus *bus, unsigned int devfn, int offset,
return PCIBIOS_DEVICE_NOT_FOUND;
PCIE_FIX;
- if (bus->number == 0xff) {
+ if (bus->number == hose->bus_offset) {
PCI_CFG_OUT(hose->cfg_addr,
- (0x80000000 | ((offset & 0xf00) << 16) |
- ((bus->number - hose->bus_offset) << 16)
- | (devfn << 8) | ((offset & 0xfc) )));
+ (0x80000000 | ((offset & 0xf00) << 16) |
+ ((bus->number - hose->bus_offset) << 16)
+ | (devfn << 8) | ((offset & 0xfc) )));
} else {
PCI_CFG_OUT(hose->cfg_addr,
- (0x80000001 | ((offset & 0xf00) << 16) |
- ((bus->number - hose->bus_offset) << 16)
- | (devfn << 8) | ((offset & 0xfc) )));
+ (0x80000000 | ((offset & 0xf00) << 16) |
+ (bus->number << 16)
+ | (devfn << 8) | ((offset & 0xfc) )));
}
/*
--
1.5.1
^ permalink raw reply related
* [PATCH]: Add 8548 pcie bus number workaround
From: Zang Roy-r61911 @ 2007-06-07 3:19 UTC (permalink / raw)
To: linuxppc-dev list; +Cc: Paul Mackerras
From: Zang Roy-r61911 <tie-fei.zang@freescale.com>
Remove legacy pcie support for 8641 chip.
General PCI code can fully support 8641 Rev2.0 chip.
For 8548 PEX controller, PCIE host controller configure
space can only be accessed as "bus->number = 0" in
the PCI architecture. So "bus->number == hose->bus_offset"
judgment is added.
Some minor space indentation clean up.
Signed-off-by: Roy Zang <tie-fei.zang@freescale.com>
---
Please ignore the previous and pick up this one.
Sorry for it!
arch/powerpc/sysdev/fsl_pcie.c | 28 ++++++++++++++--------------
1 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_pcie.c b/arch/powerpc/sysdev/fsl_pcie.c
index 041c07e..79e9546 100644
--- a/arch/powerpc/sysdev/fsl_pcie.c
+++ b/arch/powerpc/sysdev/fsl_pcie.c
@@ -47,16 +47,16 @@ indirect_read_config_pcie(struct pci_bus *bus, unsigned int devfn, int offset,
return PCIBIOS_DEVICE_NOT_FOUND;
PCIE_FIX;
- if (bus->number == 0xff) {
+ if (bus->number == hose->bus_offset) {
PCI_CFG_OUT(hose->cfg_addr,
- (0x80000000 | ((offset & 0xf00) << 16) |
- ((bus->number - hose->bus_offset) << 16)
- | (devfn << 8) | ((offset & 0xfc) )));
+ (0x80000000 | ((offset & 0xf00) << 16) |
+ ((bus->number - hose->bus_offset) << 16)
+ | (devfn << 8) | ((offset & 0xfc) )));
} else {
PCI_CFG_OUT(hose->cfg_addr,
- (0x80000001 | ((offset & 0xf00) << 16) |
- ((bus->number - hose->bus_offset) << 16)
- | (devfn << 8) | ((offset & 0xfc) )));
+ (0x80000000 | ((offset & 0xf00) << 16) |
+ (bus->number << 16)
+ | (devfn << 8) | ((offset & 0xfc) )));
}
/*
@@ -98,16 +98,16 @@ indirect_write_config_pcie(struct pci_bus *bus, unsigned int devfn, int offset,
return PCIBIOS_DEVICE_NOT_FOUND;
PCIE_FIX;
- if (bus->number == 0xff) {
+ if (bus->number == hose->bus_offset) {
PCI_CFG_OUT(hose->cfg_addr,
- (0x80000000 | ((offset & 0xf00) << 16) |
- ((bus->number - hose->bus_offset) << 16)
- | (devfn << 8) | ((offset & 0xfc) )));
+ (0x80000000 | ((offset & 0xf00) << 16) |
+ ((bus->number - hose->bus_offset) << 16)
+ | (devfn << 8) | ((offset & 0xfc) )));
} else {
PCI_CFG_OUT(hose->cfg_addr,
- (0x80000001 | ((offset & 0xf00) << 16) |
- ((bus->number - hose->bus_offset) << 16)
- | (devfn << 8) | ((offset & 0xfc) )));
+ (0x80000000 | ((offset & 0xf00) << 16) |
+ (bus->number << 16)
+ | (devfn << 8) | ((offset & 0xfc) )));
}
/*
--
1.5.1
^ permalink raw reply related
* Re: [spi-devel-general] [PATCH] Simple driver for Xilinx SPI controler.
From: David Brownell @ 2007-06-07 5:09 UTC (permalink / raw)
To: Andrei Konovalov; +Cc: spi-devel-general, linuxppc-embedded
In-Reply-To: <4666BF47.8080103@ru.mvista.com>
On Wednesday 06 June 2007, Andrei Konovalov wrote:
>
> Would be nice to get this driver into mainline.
> Reviews and comments are welcome.
I'll ignore the Kconfig flamage ... ;)
> --- /dev/null
> +++ b/drivers/spi/xilinx_spi.c
> @@ -0,0 +1,447 @@
> +/*
> + * xilinx_spi.c
> + *
> + * Xilinx SPI controler driver (master mode only)
> + *
> + * Author: MontaVista Software, Inc.
> + * source@mvista.com
> + *
> + * 2002-2007 (c) MontaVista Software, Inc. This file is licensed under the
> + * terms of the GNU General Public License version 2. This program is licensed
> + * "as is" without any warranty of any kind, whether express or implied.
> + */
> +
> +
> +/* Simple macros to get the code more readable */
> +#define xspi_in16(addr) in_be16((u16 __iomem *)(addr))
> +#define xspi_in32(addr) in_be32((u32 __iomem *)(addr))
> +#define xspi_out16(addr, value) out_be16((u16 __iomem *)(addr), (value))
> +#define xspi_out32(addr, value) out_be32((u32 __iomem *)(addr), (value))
I'm rather used to seeing I/O addressses passed around as "void __iomem *"
so those sorts of cast are not needed... :)
> +
> +static void xspi_abort_transfer(u8 __iomem *regs_base)
> +{
You should not need an abort primitive. This is called only
in the remove-controller path. By the time it's called,
every child spi_device on this bus segment should have been
removed ... which means any spi_driver attached to that
device has already returned from its remove() method, which
in turn means that there will be no spi_message objects in
flight from any of those drivers.
> +static void xilinx_spi_chipselect(struct spi_device *spi, int is_on)
> +{
> + struct xilinx_spi *xspi;
> + u8 __iomem *regs_base;
> +
> + xspi = spi_master_get_devdata(spi->master);
> + regs_base = xspi->regs;
> +
> + if (is_on == BITBANG_CS_INACTIVE) {
> + /* Deselect the slave on the SPI bus */
> + xspi_out32(regs_base + XSPI_SSR_OFFSET, 0xffff);
I take it you can't support SPI_CS_HIGH??
> +/* spi_bitbang requires custom setup_transfer() to be defined if there is a
> + * custom txrx_bufs(). We have nothing to setup here as the SPI IP block
> + * supports just 8 bits per word, and SPI clock can't be changed in software.
> + * Check for 8 bits per word; speed_hz checking could be added if the SPI
> + * clock information is available. Chip select delay calculations could be
> + * added here as soon as bitbang_work() can be made aware of the delay value.
> + */
> +static int xilinx_spi_setup_transfer(struct spi_device *spi,
> + struct spi_transfer *t)
> +{
> + u8 bits_per_word;
> +
> + bits_per_word = (t) ? t->bits_per_word : spi->bits_per_word;
> + if (bits_per_word != 8)
> + return -EINVAL;
Speed checking *SHOULD* be added; the clock info can be platform data.
It would make trouble if a driver needed to turn the clock down to,
say, 400 KHz for some operation, and the controller said "yes" but
kept it at 25 MHz or whatever. It's OK if the driver is told that
400 KHz can't happen though -- it's possible to recover from that.
(Although in practice it's best to have the transfer method do
the error checking, so that messages that will fail do so before
they are allowed to enter the I/O queue.)
ISTR you may need to delegate to the default method here too, but
it's been a while since I poked at that level and the issue might
not apply to this particular driver config.
> +
> + return 0;
> +}
> +
> +
> +static int xilinx_spi_setup(struct spi_device *spi)
> +{
> + struct spi_bitbang *bitbang;
> + struct xilinx_spi *xspi;
> + int retval;
> +
> + xspi = spi_master_get_devdata(spi->master);
> + bitbang = &xspi->bitbang;
You need to verify ALL the input parameters. In particular,
mask spi->mode against all the values this driver recognizes
and supports. If you don't support SPI_LSB_FIRST it's a bug
if setup() succeeds after setting that. Same thing with all
other bits defined today (SPI_3WIRE, SPI_CS_HIGH) and in the
future...
For an example, see the atmel_spi.c driver and MODEBITS.
There's a patch in MM that makes all the SPI controller
drivers have analagous tests ... and for bitbang there's
a patch adding spi_bitbang.mode flags to declare any
extra spi->mode flags that should be accepted.
> + ...
> +
> +static irqreturn_t xilinx_spi_irq(int irq, void *dev_id)
> +{
> + struct xilinx_spi *xspi;
> + u8 __iomem *regs_base;
> + u32 ipif_isr;
> +
> + xspi = (struct xilinx_spi *) dev_id;
> + regs_base = xspi->regs;
> +
> + /* Get the IPIF inetrrupts, and clear them immediately */
Spell checkers will tell you this is "interrupts" ... ;)
> + ipif_isr = xspi_in32(regs_base + XIPIF_V123B_IISR_OFFSET);
> + xspi_out32(regs_base + XIPIF_V123B_IISR_OFFSET, ipif_isr);
> +
> + if (ipif_isr & XSPI_INTR_TX_EMPTY) { /* Transmission completed */
> + u16 cr;
> + u8 sr;
> +
> + /* A transmit has just completed. Process received data and
> + * check for more data to transmit. Always inhibit the
> + * transmitter while the Isr refills the transmit register/FIFO,
> + * or make sure it is stopped if we're done.
> + */
> + cr = xspi_in16(regs_base + XSPI_CR_OFFSET);
> + xspi_out16(regs_base + XSPI_CR_OFFSET,
> + cr | XSPI_CR_TRANS_INHIBIT);
> +
> + /* Read out all the data from the Rx FIFO */
> + sr = in_8(regs_base + XSPI_SR_OFFSET);
> + while ((sr & XSPI_SR_RX_EMPTY_MASK) == 0) {
> + u8 data;
> +
> + data = in_8(regs_base + XSPI_RXD_OFFSET);
> + if (xspi->rx_ptr) {
> + *xspi->rx_ptr++ = data;
> + }
> + sr = in_8(regs_base + XSPI_SR_OFFSET);
> + }
> +
> + /* See if there is more data to send */
> + if (xspi->remaining_bytes > 0) {
> + /* sr content is valid here; no need for io_8() */
> + while ((sr & XSPI_SR_TX_FULL_MASK) == 0
> + && xspi->remaining_bytes > 0) {
> + if (xspi->tx_ptr) {
> + out_8(regs_base + XSPI_TXD_OFFSET,
> + *xspi->tx_ptr++);
> + } else {
> + out_8(regs_base + XSPI_TXD_OFFSET, 0);
> + }
This duplicates the loop in txrx_bufs(); that's bad style.
Have one routine holding the shared code.
> +static int __init xilinx_spi_probe(struct platform_device *dev)
> +{
> + int ret = 0;
> + struct spi_master *master;
> + struct xilinx_spi *xspi;
> + struct xspi_platform_data *pdata;
> + struct resource *r;
> +
> + /* Get resources(memory, IRQ) associated with the device */
> + master = spi_alloc_master(&dev->dev, sizeof(struct xilinx_spi));
> +
> + if (master == NULL) {
> + return -ENOMEM;
> + }
> +
> + platform_set_drvdata(dev, master);
> + pdata = dev->dev.platform_data;
> +
> + if (pdata == NULL) {
> + ret = -ENODEV;
> + goto put_master;
> + }
> +
> + r = platform_get_resource(dev, IORESOURCE_MEM, 0);
> + if (r == NULL) {
> + ret = -ENODEV;
> + goto put_master;
> + }
> +
> + xspi = spi_master_get_devdata(master);
> + xspi->bitbang.master = spi_master_get(master);
> + xspi->bitbang.chipselect = xilinx_spi_chipselect;
> + xspi->bitbang.setup_transfer = xilinx_spi_setup_transfer;
> + xspi->bitbang.txrx_bufs = xilinx_spi_txrx_bufs;
> + xspi->bitbang.master->setup = xilinx_spi_setup;
> + init_completion(&xspi->done);
> +
> + xspi->regs = ioremap(r->start, r->end - r->start + 1);
Strictly speaking a request_region() should precede the ioremap,
but a lot of folk don't bother. However, lacking that I'd put
the request_irq() earlier, since that will be the only resource
providing any guard against another driver sharing the hardware.
^ permalink raw reply
* Re: a question on "iowrite32()"
From: Domen Puncer @ 2007-06-07 6:20 UTC (permalink / raw)
To: Ming Liu; +Cc: linuxppc-embedded
In-Reply-To: <BAY138-F6B2DA6BEF021C7026E522B2270@phx.gbl>
On 06/06/07 19:30 +0000, Ming Liu wrote:
> Dear all,
> I am writing a device driver for my customized PLB hardware module on my
> PPC405 & Xilinx ML403 architecture. In the driver code, I use a
> "iowrite32()" function to initiate a DMA transfer. However, I found that if
> I program as "iowrite32(0x12345678, address);", actually I am writing
> 0x87654321 to that address. However if I write a standalone program without
> a Linux OS, the Xilinx function "XIo_Out32()" just write the correct value
> 0x12345678 into address. Can anyone explain my why this happens? I know
> that PPC405 is a big-endian system. But I don't think this is a endian
> problem. After all endian is only an issue of the CPU architecture, not the
> OS. Am I right?
out_be32?
I recall something about iowrite32 being PCI stuff and therefore little
endian, but don't count on this being right.
Domen
^ permalink raw reply
* Re: [PATCH]: Add 8548 pcie bus number workaround
From: Kumar Gala @ 2007-06-07 6:48 UTC (permalink / raw)
To: Zang Roy-r61911; +Cc: linuxppc-dev list, Paul Mackerras
In-Reply-To: <1181186378.10296.41.camel@localhost.localdomain>
On Jun 6, 2007, at 10:19 PM, Zang Roy-r61911 wrote:
>
> From: Zang Roy-r61911 <tie-fei.zang@freescale.com>
>
> Remove legacy pcie support for 8641 chip.
> General PCI code can fully support 8641 Rev2.0 chip.
> For 8548 PEX controller, PCIE host controller configure
> space can only be accessed as "bus->number = 0" in
> the PCI architecture. So "bus->number == hose->bus_offset"
> judgment is added.
Uugh, I'm completely confused. Does 8548 rev 2.x have some errata
(or 'feature') that 8641 doesn't have?
- k
^ permalink raw reply
* RE: MPC8272 LPT support
From: Kruit, Chris van der [FINT] @ 2007-06-07 7:06 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <4666DB52.2020807@ovro.caltech.edu>
Hi Dave,
Thanks for the reply. It's really usefull. I probally come back later
with some more questions :)
Chris.
-----Original Message-----
From: David Hawkins [mailto:dwh@ovro.caltech.edu]=20
Sent: Wednesday, June 06, 2007 6:06 PM
To: Kruit, Chris van der [FINT]
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: MPC8272 LPT support
Hi Chris,
> I'm new to Linux and PowerPC.
Ok.
> Last days I did some research to find out if we could use a specific=20
> board for our new project. I found a board with a MPC8272 processor;
it=20
> got all the IO we need, except for a LPT port that we use now for=20
> driving a HD44780 based display.
>=20
> Now the MPC8272 has a lot free GPIO pins which can be used for driving
> the HD44780 controller.
>=20
> Now my question is if there are drivers for these GPIO pins and if
there=20
> is a way too emulate a parallel port on GPIO pins.
Since you are using the parallel port as GPIO to drive
the HD44780 display, then you should really just use
the MPC8272 GPIO as ... GPIO :)
Depending on your application, you might even get away
without using a custom driver.
If the GPIO pin register you plan to use for controlling
the HD44780 display is not used by any other driver/process,
then user-space can read/write to the register without
needing any sort of locking. If the GPIO pins are
shared, then you'd need a kernel driver with locking, or
possibly user space app with mutex locking.
I've attached inline some /dev/mem code that I've used
on an EP9302 (ARM processor) development board. I see no
reason it won't work on a PPC.
Give it a shot; map your GPIO register, set up a GPIO
bank as output, and toggle the I/O. To interface to the
LCD controller, I think you'll only need an 8-bit bidirectional
bus, and two or three output control signals.
Cheers,
Dave
/*
* mem_debug.c
*
* 5/10/07 D. W. Hawkins (dwh@ovro.caltech.edu)
*
* A debug console for read/write access to /dev/mem mapped
* areas.
*/
#include <stdio.h>
#include <errno.h>
#include <string.h>
#include <fcntl.h>
#include <sys/ioctl.h>
#include <signal.h>
#include <sys/mman.h>
#include <stdlib.h>
#include <unistd.h>
void display_help();
void change_mem(char *cmd);
void display_mem(char *cmd);
void process_command(char *cmd);
/* Mapped address and size */
static char *mem_addr =3D NULL;
static unsigned int mem_phys =3D 0;
static unsigned int mem_pages =3D 0;
static unsigned int mem_size =3D 0;
static void show_usage()
{
printf("\nUsage: mem_debug -a <address> -n <pages>\n"\
" -h Help (this message)\n"\
" -a <address> Hex address to start the map\n"\
" -n <pages> Number of pages to map\n\n");
}
int main(int argc, char *argv[])
{
int opt; /* getopt processing */
int fd; /* /dev/mem file descriptor */
char buf[200]; /* command processing buffer */
int len =3D 200;
int page_size =3D getpagesize();
int status;
while ((opt =3D getopt(argc, argv, "a:hn:")) !=3D -1) {
switch (opt) {
case 'a':
status =3D sscanf(optarg, "%X",
&mem_phys);
if (status !=3D 1) {
printf("Parse error for -a
option\n");
show_usage();
return -1;
}
break;
case 'h':
show_usage();
return -1;
case 'n':
mem_pages =3D atoi(optarg);
break;
default:
show_usage();
return -1;
}
}
if (mem_phys !=3D (mem_phys/page_size)*page_size) {
printf("Error: the address must be page-aligned
(0x%X)\n",
page_size);
return -1;
}
if (mem_pages =3D=3D 0) {
mem_pages =3D 1;
}
mem_size =3D mem_pages*page_size;
/* Startup */
printf("\n------------------------\n");
printf("/dev/mem debug interface\n");
=
printf("=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D\n\n");
/* Open /dev/mem and map it */
printf(" * open /dev/mem\n");
fd =3D open("/dev/mem", O_RDWR | O_SYNC);
if (fd < 0) {
printf("Open /dev/mem failed - %s\n",
strerror(errno));
return -1;
}
printf(" * map %d page(s) (%d-bytes) at address 0x%.8X\n",
mem_pages, mem_size, mem_phys);
mem_addr =3D (char *)mmap(
0,
mem_size,
PROT_READ|PROT_WRITE,
MAP_SHARED,
fd,
mem_phys);
if (mem_addr =3D=3D (char *)MAP_FAILED) {
printf("Error: mmap failed\n");
close(fd);
return -1;
}
/* Display help */
display_help();
/* Process commands */
while (1) {
printf("CMD> ");
fflush(stdout);
fgets(buf,len,stdin);
process_command(buf);
}
/* Cleanup */
munmap((void *)mem_addr, mem_pages*page_size);
close(fd);
return 0;
}
/*--------------------------------------------------------------------
* User interface
*--------------------------------------------------------------------
*/
void display_help()
{
printf("\n ? Help\n");
printf(" dw addr len Display len words starting from
addr\n");
printf(" db addr len Display len bytes starting from
addr\n");
printf(" cw addr val Change word at addr to val\n");
printf(" cb addr val Change byte at addr to val\n");
printf(" q Quit\n");
printf("\n Notes:\n");
printf(" * addr, len, and val are interpreted as hex
values\n");
printf(" * addresses are always byte based\n");
printf(" * addresses are offsets relative to the base
address\n\n");
}
void process_command(char *cmd)
{
if (cmd[0] =3D=3D '\0') {
return;
}
switch (cmd[0]) {
case '?':
display_help();
break;
case 'd':
case 'D':
display_mem(cmd);
break;
case 'c':
case 'C':
change_mem(cmd);
break;
case 'q':
case 'Q':
exit(0);
default:
break;
}
return;
}
void display_mem(char *cmd)
{
char width =3D 0;
int addr =3D 0;
int len =3D 0;
int status;
int i, data;
/* d, db, dw */
status =3D sscanf(cmd, "%*c%c %x %x", &width, &addr, &len);
if (status !=3D 3) {
printf("syntax error (use ? for help)\n");
return;
}
if (len > mem_size) {
len =3D mem_size;
}
/* Convert to offset if required */
if (addr >=3D mem_phys) {
addr -=3D mem_phys;
}
if (addr >=3D mem_size) {
printf("Illegal address\n");
return;
}
switch (width) {
case 'b':
for (i =3D 0; i < len; i++) {
if ((i%16) =3D=3D 0) {
printf("\n%.8X: ", mem_phys +
addr + i);
}
data =3D (int)(mem_addr[addr+i]) & 0xFF;
printf("%.02X ", data);
}
printf("\n");
break;
default:
for (i =3D 0; i < len; i+=3D4) {
if ((i%16) =3D=3D 0) {
printf("\n%.8X: ", mem_phys +
addr + i);
}
data =3D *(int *)(mem_addr + addr + i);
printf("%.08X ", data);
}
printf("\n");
break;
}
printf("\n");
return;
}
void change_mem(char *cmd)
{
char width =3D 0;
int addr =3D 0;
int data =3D 0;
int status;
/* c, cb, cw */
status =3D sscanf(cmd, "%*c%c %x %x", &width, &addr, &data);
if (status !=3D 3) {
printf("syntax error (use ? for help)\n");
return;
}
/* Convert to offset if required */
if (addr >=3D mem_phys) {
addr -=3D mem_phys;
}
if (addr >=3D mem_size) {
printf("Illegal address\n");
return;
}
switch (width) {
case 'b':
mem_addr[addr] =3D data & 0xFF;
break;
default:
*(int *)(mem_addr + addr) =3D data;
break;
}
return;
}
^ permalink raw reply
* Re: [RFC/PATCH 4/4] Add support for MSI on Axon-based Cell systems
From: Michael Ellerman @ 2007-06-07 7:58 UTC (permalink / raw)
To: Jean-Christophe Dubois; +Cc: linuxppc-dev
In-Reply-To: <200706050900.54022.jdubois@mc.com>
[-- Attachment #1: Type: text/plain, Size: 1639 bytes --]
On Tue, 2007-06-05 at 09:00 +0200, Jean-Christophe Dubois wrote:
> On Monday 04 June 2007 15:00:05 Michael Ellerman wrote:
> > + pr_debug("axon_msi: initialising ...\n");
> > +
> > + for_each_compatible_node(node, NULL, "ibm,axon-msic") {
> > + if (axon_msi_setup_one(of_node_get(node)) == 0)
> > + found++;
> > + }
> > + of_node_put(node);
>
> 2 comments:
>
> 1) There is no "ibm,axon-msic" compatible property in the SLOF tree provided
> by IBM on the CAB (or other such platforms). Therefore this code will not
> work on these platforms.
It's not clear to me if MSIs will work on CAB, with Axon in end-point
mode. But it'd be good to try it at some point.
The compatible property is new, it's only just been added to SLOF
recently by Heiko, not sure when it will be in released firmware.
> 2) you should somehow check for the Axon version. Axon 1.1 (and prior) are
> know to be loosing MSI/MBX interrupts (but not the data part associated to
> them). Therefore this should be enabled only on Axon 2.1 (or later).
Yep. It works some of the time on 1.1, but not enough to enable it.
I guess I'd say firmware that runs on 1.1 should just not export the msi
nodes, or not put the compatible property on them - rather than having
the kernel explicitly checking for the version.
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* write u-boot.bin on mpc8349e-mITX-gp with bdi2000
From: Soohyung Cho @ 2007-06-07 8:05 UTC (permalink / raw)
To: linuxppc-embedded
Hello.
Now I'm trying to write u-boot.bin on mpc8349e-mITX-gp with bdi2000.
But I don't have correct bdi2000 configuration file for mpc8349e-mITX-gp.
How can I write u-boot.bin on that board?
Unfortunately I erased u-boot area on that board so there no u-boot anymore
on that board.
Is there anyone can show bdi2000 configuration file for mpc8349e-mITX-gp?
Or please let me know how to write u-boot on that board with bdi2000.
I'll appreciate any comments.
^ permalink raw reply
* Re: [RFC/PATCH 4/4] Add support for MSI on Axon-based Cell systems
From: Jean-Christophe Dubois @ 2007-06-07 8:10 UTC (permalink / raw)
To: michael; +Cc: linuxppc-dev
In-Reply-To: <1181203139.4166.26.camel@concordia.ozlabs.ibm.com>
On Thursday 07 June 2007 09:58:59 Michael Ellerman wrote:
> On Tue, 2007-06-05 at 09:00 +0200, Jean-Christophe Dubois wrote:
> > On Monday 04 June 2007 15:00:05 Michael Ellerman wrote:
> > > + pr_debug("axon_msi: initialising ...\n");
> > > +
> > > + for_each_compatible_node(node, NULL, "ibm,axon-msic") {
> > > + if (axon_msi_setup_one(of_node_get(node)) == 0)
> > > + found++;
> > > + }
> > > + of_node_put(node);
> >
> > 2 comments:
> >
> > 1) There is no "ibm,axon-msic" compatible property in the SLOF tree
> > provided by IBM on the CAB (or other such platforms). Therefore this code
> > will not work on these platforms.
>
> It's not clear to me if MSIs will work on CAB, with Axon in end-point
> mode. But it'd be good to try it at some point.
The CAB (or other derived products) can be set in RC mode (via a jumper). In
this case the MSI could be supported.
> The compatible property is new, it's only just been added to SLOF
> recently by Heiko, not sure when it will be in released firmware.
>
> > 2) you should somehow check for the Axon version. Axon 1.1 (and prior)
> > are know to be loosing MSI/MBX interrupts (but not the data part
> > associated to them). Therefore this should be enabled only on Axon 2.1
> > (or later).
>
> Yep. It works some of the time on 1.1, but not enough to enable it.
>
> I guess I'd say firmware that runs on 1.1 should just not export the msi
> nodes, or not put the compatible property on them - rather than having
> the kernel explicitly checking for the version.
>
> cheers
^ permalink raw reply
* Re: [PATCH 2.6.22-rc4] ehea: Fixed possible kernel panic on VLAN packet recv
From: Thomas Q Klein @ 2007-06-07 8:14 UTC (permalink / raw)
To: michael
Cc: Jeff Garzik, Jan-Bernd Themann, netdev, linux-kernel,
Stefan Roscher, linux-ppc, Christoph Raisch, Marcus Eder, tklein
In-Reply-To: <1181176500.4166.1.camel@concordia.ozlabs.ibm.com>
Michael Ellerman <michael@ellerman.id.au> wrote on 06/07/2007 02:35:00 AM:
> On Wed, 2007-06-06 at 20:53 +0200, Thomas Klein wrote:
> > This patch fixes a possible kernel panic due to not checking the vlan
group
> > when processing received VLAN packets and a malfunction in
VLAN/hypervisor
> > registration.
> >
> >
> > Signed-off-by: Thomas Klein <tklein@de.ibm.com>
> > ---
> >
> >
> > diff -Nurp -X dontdiff linux-2.6.22-rc4/drivers/net/ehea/ehea.h
> patched_kernel/drivers/net/ehea/ehea.h
> > --- linux-2.6.22-rc4/drivers/net/ehea/ehea.h 2007-06-05 02:57:
> 25.000000000 +0200
> > +++ patched_kernel/drivers/net/ehea/ehea.h 2007-06-06 12:53:58.
> 000000000 +0200
> > @@ -39,7 +39,7 @@
> > #include <asm/io.h>
> >
> > #define DRV_NAME "ehea"
> > -#define DRV_VERSION "EHEA_0061"
> > +#define DRV_VERSION "EHEA_0064"
> >
> > #define EHEA_MSG_DEFAULT (NETIF_MSG_LINK | NETIF_MSG_TIMER \
> > | NETIF_MSG_RX_ERR | NETIF_MSG_TX_ERR)
> > diff -Nurp -X dontdiff linux-2.6.22-
> rc4/drivers/net/ehea/ehea_main.c
patched_kernel/drivers/net/ehea/ehea_main.c
> > --- linux-2.6.22-rc4/drivers/net/ehea/ehea_main.c 2007-06-05 02:
> 57:25.000000000 +0200
> > +++ patched_kernel/drivers/net/ehea/ehea_main.c 2007-06-06 12:
> 53:58.000000000 +0200
> > @@ -1947,7 +1945,7 @@ static void ehea_vlan_rx_add_vid(struct
> > }
> >
> > index = (vid / 64);
> > - cb1->vlan_filter[index] |= ((u64)(1 << (vid & 0x3F)));
> > + cb1->vlan_filter[index] |= ((u64)(0x8000000000000000 >> (vid &
0x3F)));
> >
> > hret = ehea_h_modify_ehea_port(adapter->handle,
port->logical_port_id,
> > H_PORT_CB1, H_PORT_CB1_ALL, cb1);
> > @@ -1982,7 +1980,7 @@ static void ehea_vlan_rx_kill_vid(struct
> > }
> >
> > index = (vid / 64);
> > - cb1->vlan_filter[index] &= ~((u64)(1 << (vid & 0x3F)));
> > + cb1->vlan_filter[index] &= ~((u64)(0x8000000000000000 >> (vid &
0x3F)));
>
> These two seem ripe for splitting into some sort of helper routine.
> Which would leave only one place to get it right.
>
Basically agreed. But as we're already at rc4 I wanted to keep the
patch as least invasive as possible. The modification you suggest
can be implemented as a code improvement in 2.6.23.
^ permalink raw reply
* RE: [PATCH]: Add 8548 pcie bus number workaround
From: Zhang Wei-r63237 @ 2007-06-07 8:54 UTC (permalink / raw)
To: Kumar Gala, Zang Roy-r61911; +Cc: linuxppc-dev list, Paul Mackerras
In-Reply-To: <D373FFB6-49B6-414B-AEEB-65AB62EB5AD5@kernel.crashing.org>
MPC8641 v2.0 have fixed the errata. And v1.0 is not supported.
Wei.
> -----Original Message-----
> From: linuxppc-dev-bounces+wei.zhang=3Dfreescale.com@ozlabs.org=20
> [mailto:linuxppc-dev-bounces+wei.zhang=3Dfreescale.com@ozlabs.or
> g] On Behalf Of Kumar Gala
> Sent: Thursday, June 07, 2007 2:49 PM
> To: Zang Roy-r61911
> Cc: linuxppc-dev list; Paul Mackerras
> Subject: Re: [PATCH]: Add 8548 pcie bus number workaround
>=20
>=20
> On Jun 6, 2007, at 10:19 PM, Zang Roy-r61911 wrote:
>=20
> >
> > From: Zang Roy-r61911 <tie-fei.zang@freescale.com>
> >
> > Remove legacy pcie support for 8641 chip.
> > General PCI code can fully support 8641 Rev2.0 chip.
> > For 8548 PEX controller, PCIE host controller configure
> > space can only be accessed as "bus->number =3D 0" in
> > the PCI architecture. So "bus->number =3D=3D hose->bus_offset"
> > judgment is added.
>=20
> Uugh, I'm completely confused. Does 8548 rev 2.x have some errata =20
> (or 'feature') that 8641 doesn't have?
>=20
> - k
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>=20
^ permalink raw reply
* Re: [PATCH]: Add 8548 pcie bus number workaround
From: Zang Roy-r61911 @ 2007-06-07 9:04 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev list, Paul Mackerras
In-Reply-To: <D373FFB6-49B6-414B-AEEB-65AB62EB5AD5@kernel.crashing.org>
On Thu, 2007-06-07 at 14:48, Kumar Gala wrote:
> On Jun 6, 2007, at 10:19 PM, Zang Roy-r61911 wrote:
>
> >
> > From: Zang Roy-r61911 <tie-fei.zang@freescale.com>
> >
> > Remove legacy pcie support for 8641 chip.
> > General PCI code can fully support 8641 Rev2.0 chip.
> > For 8548 PEX controller, PCIE host controller configure
> > space can only be accessed as "bus->number = 0" in
> > the PCI architecture. So "bus->number == hose->bus_offset"
> > judgment is added.
>
> Uugh, I'm completely confused. Does 8548 rev 2.x have some errata
> (or 'feature') that 8641 doesn't have?
NO! I do not think so!
It is a story about the 85xx/86xx pcie road map.
Originally, fsl_pcie.c is based on the pcie support code for 86xx (1.x
or later).
Jdl and I separate this part of code for the purpose to support both
85xx/86xx pcie. So this part of code contains some garbage code for
legacy 86xx pcie support or debug information. I have discussed this
with the original developer.
So in this patch I remove the unused code. Is it wrong?
Now this file is target to support 8548 rev 1.x and 2.x pcie controller.
Now, I am working to put some common code to support 85xx/86xx pcie in
this file, such as atmu init and link status check.
Moer patches will be posted to provide a completely pcie support for
85xx/86xx.
Thanks.
Roy
^ permalink raw reply
* Re: a question on "iowrite32()"
From: Arnd Bergmann @ 2007-06-07 10:01 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: linuxppc, Domen Puncer
In-Reply-To: <20070607062054.GD23294@moe.telargo.com>
On Thursday 07 June 2007, Domen Puncer wrote:
> out_be32?
> I recall something about iowrite32 being PCI stuff and therefore little
> endian, but don't count on this being right.
You're completely right, out_be32 is the correct one. The primitives
we have for writing 32 bit I/O space are:
writel(): PCI memory space from ioremap
outl(): PCI I/O space from a struct resource
iowrite32(): PCI memory or I/O space from pci_iomap
iowrite32be(): defined but not useful anywhere currently
out_be32(): big-endian memory address from of_address_to_resource or of_iomap
out_le32(): like out_be32(), but little-endian
__raw_writel(): always broken, don't use
Since of_iomap() is rather new and hardly used by any drivers, we
could still redefine it so that you would use iowrite32{,be}() instead
of out_{be,le}32, but currently that doesn't work.
I also thought about changing of_iomap() to use the devres functions,
which basically attach information about the mapping to the device
structure, and automatically unmap those when the of_platform_driver
gets unregistered.
Arnd <><
^ permalink raw reply
* Re: a question on "iowrite32()"
From: Ming Liu @ 2007-06-07 11:20 UTC (permalink / raw)
To: arnd; +Cc: domen.puncer, linuxppc-embedded
In-Reply-To: <200706071201.46637.arnd@arndb.de>
Dear Arnd,
>Since of_iomap() is rather new and hardly used by any drivers, we
>could still redefine it so that you would use iowrite32{,be}() instead
>of out_{be,le}32, but currently that doesn't work.
So if I am correct, your suggestion is to use iowrite32be() in my device
driver, right? However, I cannot find such a function defined in my 2.6.10
kernel. Isn't iowrite32be() a standard IO function like iowrite32(), or
there is a patch to export this function?
Thanks for your information.
BR
Ming
_________________________________________________________________
与联机的朋友进行交流，请使用 MSN Messenger: http://messenger.msn.com/cn
^ permalink raw reply
* Re: MPC8349ea Random Number Generator driver
From: Philippe Lachenal @ 2007-06-07 11:29 UTC (permalink / raw)
To: arnd, linuxppc-dev; +Cc: sl
In-Reply-To: <200706061615.11380.arnd@arndb.de>
Hi !
Thank you for your answer :)
>Looks good from the point of integration into the driver framework.
>I can't judge the hwrng specific parts, but don't see anything
>fundamentally wrong there.
>
> > +static int __init mpc834x_itx_declare_of_platform_devices(void)
> > +{
> > + if (!machine_is(mpc834x_itx)){
> > + printk("__init mpc834x_itx_declare_of_platform_devices
>error\n");
> > + return 0;
> > + }
>
>I would think that it's not strictly an error to be running on some other
>hardware than yours ;-)
>
>Just remove the printk here.
I would think that you're right.. ;)
> > + err = of_address_to_resource(rng_np, 0, &res);
> > + if (err)
> > + return -ENODEV; > + rng_regs = ioremap(res.start,
>(res.end - res.start));
>
>This can be done in one step with the new 'of_iomap' function.
nice :)
... I've checked this function, (yours ? ;) ) and there's a very small
difference between it and what I've done :
+-static void __iomem *of_iomap(struct device_node *np)
+-{
+- struct resource res;
+-
+- if (of_address_to_resource(np, 0, &res))
+- return NULL;
+-
+- pr_debug("Resource start: 0x%lx\n", res.start);
+- pr_debug("Resource end: 0x%lx\n", res.end);
+-
+- return ioremap(res.start, 1 + res.end - res.start);
+-}
why is there a 1+ res.end-res.start ? Am I wrong in not adding one in my
code ?
> > + printk(KERN_INFO "Registering Talitos RNG\n");
> > +
> > + err = hwrng_register(&talitos_rng);
> > + if (err){
> > + printk(".............. failure\n");
> > + iounmap(rng_regs);
> > + }
>
>This printk should have a KERN_ERROR or similar level.
>Ideally, replace all instances of printk in your driver with 'dev_err',
>'dev_info' or similar calls from <linux/device.h>.
>
> Arnd <><
ok, I will remove those ugly printks ;)
Phil
_________________________________________________________________
Personnalisez votre Messenger avec Live.com
http://www.windowslive.fr/livecom/
^ permalink raw reply
* Re: [RFC/PATCH 4/4] Add support for MSI on Axon-based Cell systems
From: Benjamin Herrenschmidt @ 2007-06-07 11:55 UTC (permalink / raw)
To: Jean-Christophe Dubois; +Cc: linuxppc-dev
In-Reply-To: <200706071010.05172.jdubois@mc.com>
On Thu, 2007-06-07 at 10:10 +0200, Jean-Christophe Dubois wrote:
> The CAB (or other derived products) can be set in RC mode (via a jumper). In
> this case the MSI could be supported.
Is there any plan to have CABs based on AXON DD >= 2.0
I still think the right approach is to have the right properties set by
the firmware if the Axon version supports MSIs reliably. Do you see any
problem with this approach ?
Ben.
^ 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