* Re: MPC8349ea Random Device Generator driver
From: Olof Johansson @ 2007-06-06 22:09 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, sl, Philippe Lachenal
In-Reply-To: <46672DB4.80504@freescale.com>
On Wed, Jun 06, 2007 at 04:57:08PM -0500, Timur Tabi wrote:
> > +#include <asm/of_platform.h>
> > +#include <asm/io.h>
> > +
> > +#define TALITOS_RNGSR 0x028 /* RNG status register */
> > +#define TALITOS_RNGSR_HI 0x02c /* RNG status register */
> > +#define TALITOS_RNGSR_HI_RD 0x1 /* RNG Reset done */
> > +#define TALITOS_RNGSR_HI_OFL 0xff0000/* number of dwords in RNG output FIFO*/
> > +#define TALITOS_RNGDSR 0x010 /* RNG data size register */
> > +#define TALITOS_RNGDSR_HI 0x014 /* RNG data size register */
> > +#define TALITOS_RNG_FIFO 0x800 /* RNG FIFO - pool of random numbers */
> > +#define TALITOS_RNGISR 0x030 /* RNG Interrupt status register */
> > +#define TALITOS_RNGISR_HI 0x034 /* RNG Interrupt status register */
> > +#define TALITOS_RNGRCR 0x018 /* RNG Reset control register */
> > +#define TALITOS_RNGRCR_HI 0x01c /* RNG Reset control register */
>
> Please create a structure instead of using macros like this. Example:
>
> struct sec_rng {
> __be64 rngmr;
> u8 res1[8];
> __be64 rngdsr;
> __be64 rngrcr;
> ...
> };
>
> and then ...
There's nothing wrong with the way he coded that up. Lots of drivers
are written that way (all of mine are). It's at least as clear as any
structure, and it doesn't cause temptation to do...
> > +static int talitos_hwrng_data_present(struct hwrng *rng)
> > +{
> > + void __iomem *rng_regs = (void __iomem *)rng->priv;
>
> struct sec_rng __iomem *rng = (struct sec_rng __iomem *) rng->priv;
>
> > +
> > +
> > + /* check for things like FIFO underflow */
> > +
> > + u32 v;
> > +
> > + v = in_be32(rng_regs + TALITOS_RNGISR_HI);
>
> u64 v;
> v = rng->rngisr;
>
> or something like that. Try to use the built-in support for 64-bit data types when possible.
...this. NO! Don't reference ioremapped memory from regular code like
that. The way he's doing it is the preferred way.
-Olof
^ permalink raw reply
* Re: MPC8349ea Random Device Generator driver
From: Timur Tabi @ 2007-06-06 21:57 UTC (permalink / raw)
To: Philippe Lachenal; +Cc: linuxppc-dev, sl
In-Reply-To: <BAY122-F18923A7AA6D3A4D96A360085200@phx.gbl>
Philippe Lachenal 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 !
First, please don't post your patch as an attachment. I recommend you use git-send-email.
> diff --git a/arch/powerpc/platforms/83xx/mpc834x_itx.c b/arch/powerpc/platforms/83xx/mpc834x_itx.c
> old mode 100644
> new mode 100755
> index 40a0194..b05980b
> --- a/arch/powerpc/platforms/83xx/mpc834x_itx.c
> +++ b/arch/powerpc/platforms/83xx/mpc834x_itx.c
> @@ -48,6 +48,24 @@ unsigned long isa_mem_base = 0;
> * Setup the architecture
> *
> */
> +
> +static struct of_device_id mpc834x_itx[] = {
> + { .type = "soc", },
> + { .type ="crypto", },
You have a lot of minor spacing problems, like this one. There should be a blank space
before '"crypto"'.
> +
> +#include <asm/of_platform.h>
> +#include <asm/io.h>
> +
> +#define TALITOS_RNGSR 0x028 /* RNG status register */
> +#define TALITOS_RNGSR_HI 0x02c /* RNG status register */
> +#define TALITOS_RNGSR_HI_RD 0x1 /* RNG Reset done */
> +#define TALITOS_RNGSR_HI_OFL 0xff0000/* number of dwords in RNG output FIFO*/
> +#define TALITOS_RNGDSR 0x010 /* RNG data size register */
> +#define TALITOS_RNGDSR_HI 0x014 /* RNG data size register */
> +#define TALITOS_RNG_FIFO 0x800 /* RNG FIFO - pool of random numbers */
> +#define TALITOS_RNGISR 0x030 /* RNG Interrupt status register */
> +#define TALITOS_RNGISR_HI 0x034 /* RNG Interrupt status register */
> +#define TALITOS_RNGRCR 0x018 /* RNG Reset control register */
> +#define TALITOS_RNGRCR_HI 0x01c /* RNG Reset control register */
Please create a structure instead of using macros like this. Example:
struct sec_rng {
__be64 rngmr;
u8 res1[8];
__be64 rngdsr;
__be64 rngrcr;
...
};
and then ...
> +static int talitos_hwrng_data_present(struct hwrng *rng)
> +{
> + void __iomem *rng_regs = (void __iomem *)rng->priv;
struct sec_rng __iomem *rng = (struct sec_rng __iomem *) rng->priv;
> +
> +
> + /* check for things like FIFO underflow */
> +
> + u32 v;
> +
> + v = in_be32(rng_regs + TALITOS_RNGISR_HI);
u64 v;
v = rng->rngisr;
or something like that. Try to use the built-in support for 64-bit data types when possible.
I get this confused easily, but I don't think you should be using the in/out_be macros
either. Just do regular reads and writes.
--
Timur Tabi
Linux Kernel Developer @ Freescale
^ permalink raw reply
* Re: [patch 08/18] PS3: Kexec support
From: Geoff Levand @ 2007-06-06 21:55 UTC (permalink / raw)
To: michael; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <1181102510.5536.15.camel@concordia.ozlabs.ibm.com>
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.
>> Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
>> ---
>> arch/powerpc/platforms/ps3/htab.c | 14 +-
>> arch/powerpc/platforms/ps3/interrupt.c | 199 ++++++++++++++++++++-------------
>> arch/powerpc/platforms/ps3/setup.c | 29 ++--
>> 3 files changed, 147 insertions(+), 95 deletions(-)
>>
>> --- 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.
>> +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?
>> static void ps3_machine_kexec(struct kimage *image)
>> {
>> - unsigned long ppe_id;
>> -
>> DBG(" -> %s:%d\n", __func__, __LINE__);
>>
>> - lv1_get_logical_ppe_id(&ppe_id);
>> - lv1_configure_irq_state_bitmap(ppe_id, 0, 0);
>> - ps3_mm_shutdown();
>> - ps3_mm_vas_destroy();
>> -
>> - default_machine_kexec(image);
>> + default_machine_kexec(image); // needs ipi, never returns.
>
> Just get rid of ps3_machine_kexec() and hook default_machine_kexec()
> directly into your ppc_md.
Right, just a debugging leftover...
-Geoff
^ permalink raw reply
* Re: [patch 02/18] PS3: Rename IPI symbols
From: Geoff Levand @ 2007-06-06 20:49 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20070606131157.133ce9bb.sfr@canb.auug.org.au>
Stephen Rothwell wrote:
> On Tue, 05 Jun 2007 19:59:25 -0700 Geoff Levand <geoffrey.levand@am.sony.com> wrote:
>>
>> Rename the PS3 static symbol virqs to ps3_ipi_virqs to aid in
>> debugging.
>>
>> Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
>>
>> for (i = 0; i < MSG_COUNT; i++) {
>> - free_irq(virqs[i], (void*)(long)i);
>> + /* Can't call free_irq from interrupt context. */
>
> This change is probably worth a mention in the change log - it looks like
> a bug fix.
That leaked into this patch from my kexec cleanups. I'll move it out
to where it belongs.
-Geoff
^ permalink raw reply
* Re: [PATCH] Simple driver for Xilinx SPI controler.
From: Grant Likely @ 2007-06-06 20:55 UTC (permalink / raw)
To: Wolfgang Reissnegger
Cc: spi-devel-general, Stephen Neuendorffer, linuxppc-embedded,
Andrei Konovalov, Wolfgang Reissnegger
In-Reply-To: <20070606204741.D4AEB468054@mail82-cpk.bigfish.com>
On 6/6/07, Wolfgang Reissnegger <wolfgang.reissnegger@xilinx.com> wrote:
> Grant,
>
> I'm in the process of merging your virtex-dev tree into our
> linux-2.6-xlnx tree. I'll be taking care of the necessary changes. They
> will show up on the Xilinx git repository soon.
Don't forget to send patches to the list for review so we can get this
stuff into mainline.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [patch 02/18] PS3: Rename IPI symbols
From: Geoff Levand @ 2007-06-06 20:47 UTC (permalink / raw)
To: will_schmidt; +Cc: Stephen Rothwell, Paul Mackerras, linuxppc-dev
In-Reply-To: <1181141312.18837.6.camel@farscape.rchland.ibm.com>
Will Schmidt wrote:
> On Wed, 2007-06-06 at 13:11 +1000, Stephen Rothwell wrote:
>> On Tue, 05 Jun 2007 19:59:25 -0700 Geoff Levand <geoffrey.levand@am.sony.com> wrote:
>> >
>> > Rename the PS3 static symbol virqs to ps3_ipi_virqs to aid in
>> > debugging.
>> >
>> > Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
>> >
>> > for (i = 0; i < MSG_COUNT; i++) {
>> > - free_irq(virqs[i], (void*)(long)i);
>> > + /* Can't call free_irq from interrupt context. */
>>
>> This change is probably worth a mention in the change log - it looks like
>> a bug fix.
>
>
> Does the free_irq call (being removed here) need to be added back in
> somewhere else?
No, the kernel is kexecing, so it is not needed.
-Geoff
^ permalink raw reply
* Re: [PATCH] Simple driver for Xilinx SPI controler.
From: Wolfgang Reissnegger @ 2007-06-06 20:49 UTC (permalink / raw)
To: Grant Likely
Cc: spi-devel-general, Stephen Neuendorffer, linuxppc-embedded,
Andrei Konovalov, Wolfgang Reissnegger
In-Reply-To: <fa686aa40706061200u1141fcc9k73b7cc80c07240d1@mail.gmail.com>
Grant,
I'm in the process of merging your virtex-dev tree into our
linux-2.6-xlnx tree. I'll be taking care of the necessary changes. They
will show up on the Xilinx git repository soon.
Thanks,
Wolfgang
Grant Likely wrote:
> On 6/6/07, Stephen Neuendorffer <stephen.neuendorffer@xilinx.com> wrote:
>>
>> Yes, except that microblazes systems run in non-virtex FPGAs...
>>
>> It may be that XILINX_EDK is not the right thing either, but it
>> seemed like the easiest way to have a superset of powerpc and microblaze
>> systems
>>
>> What I'm trying to do is (in concert with Grant's recent configuration
>> changes)
>> having an easy way for a new board configuration to select the Kconfig
>> options for
>> all of the Xilinx drivers. Namely:
>>
>> config XILINX_ML300
>> bool "Xilinx-ML300"
>> select XILINX_VIRTEX_II_PRO
>> select EMBEDDEDBOOT
>> help
>> This option enables support for the Xilinx ML300 evaluation
>> board.
>>
>> config XILINX_VIRTEX_II_PRO
>> bool
>> select XILINX_VIRTEX
>>
>> config XILINX_EDK
>> bool
>> depends on XILINX_VIRTEX || XILINX_MICROBLAZE
>> default y
>
> I don't have any problem with adding XILINX_EDK (or whatever), but
> think particular layout is back-assward. Rather than XILINX_EDK
> depending on XILINX_VIRTEX/MICROBLAZE, XILINX_VIRTEX/MICROBLAZE should
> 'select' XILINX_EDK and you need to drop the 'default y' line.
> Otherwise the XILINX_EDK option shows up in non-edk config files.
>
>>
>> config XILINX_GPIO
>> tristate "Xilinx OPB GPIO Support"
>> depends on XILINX_EDK
>> help
>> This option enables support for Xilinx GPIO.
>>
>>
>> It seems like I'm using XILINX_EDK to mean something different than you
>> are.
>> Perhaps it sould be instead:
>>
>> config XILINX_DRIVERS
>> bool
>> depends on XILINX_VIRTEX || XILINX_MICROBLAZE
>> default y
>
> Hmmm, yes. XILINX_DRIVERS is probably better.
>
>>
>> config XILINX_GPIO_EDK
>> tristate "Xilinx EDK-based OPB GPIO Support"
>> depends on XILINX_DRIVERS
>> select XILINX_EDK
>> help
>> This option enables support for Xilinx GPIO using EDK OS
>> independent driver.
>
> Why still have XILINX_EDK? I thought you meant replace XILINX_EDK
> with XILINX_DRIVERS.
>
> Cheers,
> g.
>
^ permalink raw reply
* Re: [PATCH] Simple driver for Xilinx SPI controler.
From: Grant Likely @ 2007-06-06 19:55 UTC (permalink / raw)
To: Stephen Neuendorffer
Cc: spi-devel-general, Andrei Konovalov, Wolfgang Reissnegger,
linuxppc-embedded
In-Reply-To: <20070606190640.B7028900053@mail104-cpk.bigfish.com>
On 6/6/07, Stephen Neuendorffer <stephen.neuendorffer@xilinx.com> wrote:
> > Why still have XILINX_EDK? I thought you meant replace
> > XILINX_EDK with XILINX_DRIVERS.
>
> Yes, that's what I was suggesting.
> But I think that Andrei still wants to use XILINX_EDK to pull in the
> stuff in drivers/xilinx_common.
>
> # The Xilinx OS common code
> obj-$(CONFIG_XILINX_EDK) += xbasic_types.o xpacket_fifo_l_v2_00_a.o \
> xpacket_fifo_v2_00_a.o xversion.o \
> xdma_channel.o xdma_channel_sg.o
>
> Which you wouldn't want if you were able to build a kernel completely
> from 'non-edk' drivers.
Fair enough, but that's only an issue for vendor trees. None of this
code will be going into mainline. Any of it that does get into good
shape should probably go under drivers/misc, and have the drivers
select only the pieces that are needed (with finer-grain CONFIG_
items). A blanked CONFIG_XILINX_EDK for random stuff is not a good
idea.
Cheers,
g.
>
> Steve
>
>
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* a question on "iowrite32()"
From: Ming Liu @ 2007-06-06 19:30 UTC (permalink / raw)
To: linuxppc-embedded
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?
Thanks for your hints.
BR
Ming
_________________________________________________________________
享用世界上最大的电子邮件系统― MSN Hotmail。 http://www.hotmail.com
^ permalink raw reply
* RE: [PATCH] Simple driver for Xilinx SPI controler.
From: Stephen Neuendorffer @ 2007-06-06 19:06 UTC (permalink / raw)
To: Grant Likely
Cc: spi-devel-general, Andrei Konovalov, Wolfgang Reissnegger,
linuxppc-embedded
In-Reply-To: <fa686aa40706061200u1141fcc9k73b7cc80c07240d1@mail.gmail.com>
> > config XILINX_EDK
> > bool
> > depends on XILINX_VIRTEX || XILINX_MICROBLAZE
> > default y
>=20
> I don't have any problem with adding XILINX_EDK (or=20
> whatever), but think particular layout is back-assward. =20
> Rather than XILINX_EDK depending on XILINX_VIRTEX/MICROBLAZE,=20
> XILINX_VIRTEX/MICROBLAZE should 'select' XILINX_EDK and you=20
> need to drop the 'default y' line.
> Otherwise the XILINX_EDK option shows up in non-edk config files.
Good point...
=20
> Why still have XILINX_EDK? I thought you meant replace=20
> XILINX_EDK with XILINX_DRIVERS.
Yes, that's what I was suggesting.
But I think that Andrei still wants to use XILINX_EDK to pull in the
stuff in drivers/xilinx_common.
# The Xilinx OS common code=20
obj-$(CONFIG_XILINX_EDK) +=3D xbasic_types.o xpacket_fifo_l_v2_00_a.o \
xpacket_fifo_v2_00_a.o xversion.o \
xdma_channel.o xdma_channel_sg.o
Which you wouldn't want if you were able to build a kernel completely
from 'non-edk' drivers.
Steve
^ permalink raw reply
* Re: [PATCH] Simple driver for Xilinx SPI controler.
From: Grant Likely @ 2007-06-06 19:00 UTC (permalink / raw)
To: Stephen Neuendorffer
Cc: spi-devel-general, Andrei Konovalov, Wolfgang Reissnegger,
linuxppc-embedded
In-Reply-To: <20070606180618.C4D861268059@mail88-blu.bigfish.com>
On 6/6/07, Stephen Neuendorffer <stephen.neuendorffer@xilinx.com> wrote:
>
> Yes, except that microblazes systems run in non-virtex FPGAs...
>
> It may be that XILINX_EDK is not the right thing either, but it
> seemed like the easiest way to have a superset of powerpc and microblaze
> systems
>
> What I'm trying to do is (in concert with Grant's recent configuration
> changes)
> having an easy way for a new board configuration to select the Kconfig
> options for
> all of the Xilinx drivers. Namely:
>
> config XILINX_ML300
> bool "Xilinx-ML300"
> select XILINX_VIRTEX_II_PRO
> select EMBEDDEDBOOT
> help
> This option enables support for the Xilinx ML300 evaluation
> board.
>
> config XILINX_VIRTEX_II_PRO
> bool
> select XILINX_VIRTEX
>
> config XILINX_EDK
> bool
> depends on XILINX_VIRTEX || XILINX_MICROBLAZE
> default y
I don't have any problem with adding XILINX_EDK (or whatever), but
think particular layout is back-assward. Rather than XILINX_EDK
depending on XILINX_VIRTEX/MICROBLAZE, XILINX_VIRTEX/MICROBLAZE should
'select' XILINX_EDK and you need to drop the 'default y' line.
Otherwise the XILINX_EDK option shows up in non-edk config files.
>
> config XILINX_GPIO
> tristate "Xilinx OPB GPIO Support"
> depends on XILINX_EDK
> help
> This option enables support for Xilinx GPIO.
>
>
> It seems like I'm using XILINX_EDK to mean something different than you
> are.
> Perhaps it sould be instead:
>
> config XILINX_DRIVERS
> bool
> depends on XILINX_VIRTEX || XILINX_MICROBLAZE
> default y
Hmmm, yes. XILINX_DRIVERS is probably better.
>
> config XILINX_GPIO_EDK
> tristate "Xilinx EDK-based OPB GPIO Support"
> depends on XILINX_DRIVERS
> select XILINX_EDK
> help
> This option enables support for Xilinx GPIO using EDK OS
> independent driver.
Why still have XILINX_EDK? I thought you meant replace XILINX_EDK
with XILINX_DRIVERS.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* [PATCH 2.6.22-rc4] ehea: Fixed possible kernel panic on VLAN packet recv
From: Thomas Klein @ 2007-06-06 18:53 UTC (permalink / raw)
To: Jeff Garzik
Cc: Thomas Klein, Jan-Bernd Themann, netdev, linux-kernel,
Christoph Raisch, Stefan Roscher, linux-ppc, Marcus Eder
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
@@ -451,7 +451,8 @@ static struct ehea_cqe *ehea_proc_rwqes(
processed_rq3++;
}
- if (cqe->status & EHEA_CQE_VLAN_TAG_XTRACT)
+ if ((cqe->status & EHEA_CQE_VLAN_TAG_XTRACT)
+ && port->vgrp)
vlan_hwaccel_receive_skb(skb, port->vgrp,
cqe->vlan_tag);
else
@@ -1910,10 +1911,7 @@ static void ehea_vlan_rx_register(struct
goto out;
}
- if (grp)
- memset(cb1->vlan_filter, 0, sizeof(cb1->vlan_filter));
- else
- memset(cb1->vlan_filter, 0xFF, sizeof(cb1->vlan_filter));
+ memset(cb1->vlan_filter, 0, sizeof(cb1->vlan_filter));
hret = ehea_h_modify_ehea_port(adapter->handle, port->logical_port_id,
H_PORT_CB1, H_PORT_CB1_ALL, cb1);
@@ -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)));
hret = ehea_h_modify_ehea_port(adapter->handle, port->logical_port_id,
H_PORT_CB1, H_PORT_CB1_ALL, cb1);
^ permalink raw reply
* RE: [PATCH] Simple driver for Xilinx SPI controler.
From: Stephen Neuendorffer @ 2007-06-06 18:06 UTC (permalink / raw)
To: Andrei Konovalov
Cc: spi-devel-general, Wolfgang Reissnegger, linuxppc-embedded
In-Reply-To: <4666F598.2000004@ru.mvista.com>
Yes, except that microblazes systems run in non-virtex FPGAs...
It may be that XILINX_EDK is not the right thing either, but it
seemed like the easiest way to have a superset of powerpc and microblaze
systems
What I'm trying to do is (in concert with Grant's recent configuration
changes)
having an easy way for a new board configuration to select the Kconfig
options for
all of the Xilinx drivers. Namely:
config XILINX_ML300
bool "Xilinx-ML300"
select XILINX_VIRTEX_II_PRO
select EMBEDDEDBOOT
help
This option enables support for the Xilinx ML300 evaluation
board.
config XILINX_VIRTEX_II_PRO
bool
select XILINX_VIRTEX
config XILINX_EDK
bool
depends on XILINX_VIRTEX || XILINX_MICROBLAZE
default y
config XILINX_GPIO
tristate "Xilinx OPB GPIO Support"
depends on XILINX_EDK
help
This option enables support for Xilinx GPIO.
It seems like I'm using XILINX_EDK to mean something different than you
are.
Perhaps it sould be instead:
config XILINX_DRIVERS
bool
depends on XILINX_VIRTEX || XILINX_MICROBLAZE
default y
config XILINX_GPIO_EDK
tristate "Xilinx EDK-based OPB GPIO Support"
depends on XILINX_DRIVERS
select XILINX_EDK
help
This option enables support for Xilinx GPIO using EDK OS
independent driver.
config XILINX_GPIO
tristate "Xilinx OPB GPIO Support"
depends on XILINX_DRIVERS
help
This option enables support for Xilinx GPIO.
Would this work for you?
Steve
> -----Original Message-----
> From: Andrei Konovalov [mailto:akonovalov@ru.mvista.com]=20
> Sent: Wednesday, June 06, 2007 10:58 AM
> To: Stephen Neuendorffer
> Cc: spi-devel-general@lists.sourceforge.net;=20
> linuxppc-embedded@ozlabs.org; Wolfgang Reissnegger
> Subject: Re: [PATCH] Simple driver for Xilinx SPI controler.
>=20
> Hi Steve,
>=20
> Stephen Neuendorffer wrote:
> > In order to anticipate future Microblaze support with most of these=20
> > drivers, we've been moving towards having all of the Kconfig=20
> > dependencies on XILINX_EDK,
>=20
> There is no XILINX_EDK in the ko tree.
>=20
> > rather than XILINX_VIRTEX...
>=20
> Using XILINX_VIRTEX seems to be a common thing:
>=20
> > -------- Original Message --------
> > Subject: [RFC] Xilinx SystemACE device driver
> > Date: Sat, 14 Apr 2007 19:23:14 -0600
> > From: Grant Likely <grant.likely@secretlab.ca>
> > To: linuxppc-embedded@ozlabs.org, Andrei Konovalov=20
> <akonovalov@ru.mvista.com>, Peter Korsgaard=20
> <jacmet@sunsite.dk>, Rick Moleres <Rick.Moleres@xilinx.com>,=20
> Stefan Roese <sr@denx.de>
> >=20
> > Add support for block device access to the Xilinx SystemACE Compact=20
> > flash interface
> <snip>
> > diff --git a/drivers/block/Kconfig b/drivers/block/Kconfig index=20
> > 17ee97f..08ad23c 100644
> > --- a/drivers/block/Kconfig
> > +++ b/drivers/block/Kconfig
> > @@ -453,6 +453,12 @@ config ATA_OVER_ETH
> > This driver provides Support for ATA over Ethernet block
> > devices like the Coraid EtherDrive (R) Storage Blade.
> > =20
> > +config XILINX_SYSACE
> > + tristate "Xilinx SystemACE support"
> > + depends on XILINX_VIRTEX
> > + help
> > + Include support for the Xilinx SystemACE CompactFlash=20
> interface
> > +
>=20
> BTW the SystemACE has been successfully tested with ppc440=20
> based board. So XILINX_VIRTEX doesn't imply ppc405.
>=20
> On the other side,
> UART Lite driver (in the ko tree) doesn't depend on both=20
> XILINX_EDK and XILINX_VIRTEX
>=20
> Couldn't Microblaze port use XILINX_VIRTEX too?
> IMHO XILINX_VIRTEX is more general name for something inside=20
> the Virtex chip (ppc405 core, Microblaze softcore, IP blocks=20
> from EDK or elsewhere).
>=20
> I've recently added XILINX_EDK to linux-xilinx-26.git=20
> repository at source.mvista.com, but to include the level 1=20
> drivers (aka OS independent drivers) from EDK. Haven't=20
> planned to use XILINX_EDK for drivers not using EDK code.
> Here is the relevant snippet from=20
> arch/ppc/platforms/4xx/Kconfig (from linux-xilinx-26.git @=20
> source.mvista.com, ko doesn't have XILINX_EDK and the rest below):
>=20
> =
=3D=3D=3D8<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> config XILINX_VIRTEX_II_PRO
> bool
> select XILINX_VIRTEX
>=20
> config XILINX_VIRTEX_4_FX
> bool
> select XILINX_VIRTEX
>=20
> config XILINX_VIRTEX
> bool
>=20
> # The options selected by EDK based drivers. Not visible from=20
> [menu]config.
> config XILINX_EDK
> bool
> config XILINX_IPIF_V123B
> bool
> config XILINX_FIFO_V200A
> bool
> config XILINX_DMA_V300A
> bool
> =
=3D=3D=3D8<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>=20
> If we do something like
> config XILINX_MICROBLAZE
> bool
> select XILINX_VIRTEX
> in arch/microblaze/Kconfig
> would it work?
>=20
>=20
> Thanks,
> Andrei
>=20
>=20
>=20
^ permalink raw reply
* Re: [PATCH] Simple driver for Xilinx SPI controler.
From: Andrei Konovalov @ 2007-06-06 17:57 UTC (permalink / raw)
To: Stephen Neuendorffer; +Cc: spi-devel-general, linuxppc-embedded
In-Reply-To: <20070606160329.A8A719E0060@mail81-sin.bigfish.com>
Hi Steve,
Stephen Neuendorffer wrote:
> In order to anticipate future Microblaze support with most of these
> drivers,
> we've been moving towards having all of the Kconfig dependencies on
> XILINX_EDK,
There is no XILINX_EDK in the ko tree.
> rather than XILINX_VIRTEX...
Using XILINX_VIRTEX seems to be a common thing:
> -------- Original Message --------
> Subject: [RFC] Xilinx SystemACE device driver
> Date: Sat, 14 Apr 2007 19:23:14 -0600
> From: Grant Likely <grant.likely@secretlab.ca>
> To: linuxppc-embedded@ozlabs.org, Andrei Konovalov <akonovalov@ru.mvista.com>, Peter Korsgaard <jacmet@sunsite.dk>, Rick Moleres <Rick.Moleres@xilinx.com>, Stefan Roese <sr@denx.de>
>
> Add support for block device access to the Xilinx SystemACE Compact
> flash interface
<snip>
> diff --git a/drivers/block/Kconfig b/drivers/block/Kconfig
> index 17ee97f..08ad23c 100644
> --- a/drivers/block/Kconfig
> +++ b/drivers/block/Kconfig
> @@ -453,6 +453,12 @@ config ATA_OVER_ETH
> This driver provides Support for ATA over Ethernet block
> devices like the Coraid EtherDrive (R) Storage Blade.
>
> +config XILINX_SYSACE
> + tristate "Xilinx SystemACE support"
> + depends on XILINX_VIRTEX
> + help
> + Include support for the Xilinx SystemACE CompactFlash interface
> +
BTW the SystemACE has been successfully tested with ppc440 based
board. So XILINX_VIRTEX doesn't imply ppc405.
On the other side,
UART Lite driver (in the ko tree) doesn't depend on both XILINX_EDK and XILINX_VIRTEX
Couldn't Microblaze port use XILINX_VIRTEX too?
IMHO XILINX_VIRTEX is more general name for something inside the Virtex chip (ppc405
core, Microblaze softcore, IP blocks from EDK or elsewhere).
I've recently added XILINX_EDK to linux-xilinx-26.git repository at source.mvista.com,
but to include the level 1 drivers (aka OS independent drivers) from EDK. Haven't
planned to use XILINX_EDK for drivers not using EDK code.
Here is the relevant snippet from arch/ppc/platforms/4xx/Kconfig
(from linux-xilinx-26.git @ source.mvista.com, ko doesn't have XILINX_EDK and the
rest below):
===8<=====================================
config XILINX_VIRTEX_II_PRO
bool
select XILINX_VIRTEX
config XILINX_VIRTEX_4_FX
bool
select XILINX_VIRTEX
config XILINX_VIRTEX
bool
# The options selected by EDK based drivers. Not visible from [menu]config.
config XILINX_EDK
bool
config XILINX_IPIF_V123B
bool
config XILINX_FIFO_V200A
bool
config XILINX_DMA_V300A
bool
===8<=====================================
If we do something like
config XILINX_MICROBLAZE
bool
select XILINX_VIRTEX
in arch/microblaze/Kconfig
would it work?
Thanks,
Andrei
^ permalink raw reply
* Re: [PATCH] powerpc: Add Marvell mv64x60 udbg putc/getc functions
From: Dale Farnsworth @ 2007-06-06 17:29 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18022.20173.857845.49576@cargo.ozlabs.ibm.com>
On Wed, Jun 06, 2007 at 04:06:05PM +1000, Paul Mackerras wrote:
> Dale Farnsworth writes:
>
> > Paul, this patch is unchanged from the one I posted 10 days ago.
> > At that time, I saw no discussion, other than Mark's ACK. I'd
> > argue that this is a bugfix, and hope that it could go into 2.6.22.
>
> Um, it seems rather large, and in particular adds a fair bit of
> completely new code. Is there a simpler way of getting to an
> acceptable point - e.g. just not use the udbg console on these boards?
Yeah, that was the first approach I took. Unfortunately, currently the
udbg console is included unconditionally on arch/powerpc. I created the
patch below to conditionalize the use of udbg console. I thought it a
bit risky for 2.6.22, but I think it's the right approach long term.
> If we don't have udbg support for them then the udbg console would
> seem a bit pointless, no?
There is value in that with the udbg console we do see console output
much earlier. While there's some new code (I didn't think it was all
that much), the impact is limited to the single platform now using the
mv64x60 console port, the prpmc2800.
-Dale
---------------- begin patch ------------------------
[POWERPC] Make the use of the udbg console conditional
Create a new config variable: PPC_UDBG and make the inclusion
of the udbg console dependent on it.
Signed-off-by: Dale Farnsworth <dale@farnsworth.org>
---
arch/powerpc/Kconfig | 4 ++++
arch/powerpc/Kconfig.debug | 1 +
arch/powerpc/kernel/Makefile | 3 ++-
arch/powerpc/platforms/Kconfig | 2 ++
arch/powerpc/platforms/iseries/Kconfig | 1 +
arch/powerpc/platforms/powermac/Kconfig | 1 +
include/asm-powerpc/udbg.h | 9 +++++++++
7 files changed, 20 insertions(+), 1 deletion(-)
Index: linux-2.6-powerpc-df/arch/powerpc/Kconfig
===================================================================
--- linux-2.6-powerpc-df.orig/arch/powerpc/Kconfig
+++ linux-2.6-powerpc-df/arch/powerpc/Kconfig
@@ -99,9 +99,13 @@ config ARCH_MAY_HAVE_PC_FDC
config PPC_OF
def_bool y
+config PPC_UDBG
+ bool
+
config PPC_UDBG_16550
bool
+ select PPC_UDBG
default n
config GENERIC_TBSYNC
bool
Index: linux-2.6-powerpc-df/arch/powerpc/Kconfig.debug
===================================================================
--- linux-2.6-powerpc-df.orig/arch/powerpc/Kconfig.debug
+++ linux-2.6-powerpc-df/arch/powerpc/Kconfig.debug
@@ -135,6 +135,7 @@ config BDI_SWITCH
config BOOTX_TEXT
bool "Support for early boot text console (BootX or OpenFirmware only)"
depends PPC_OF
+ select PPC_UDBG
help
Say Y here to see progress messages from the boot firmware in text
mode. Requires either BootX or Open Firmware.
Index: linux-2.6-powerpc-df/arch/powerpc/kernel/Makefile
===================================================================
--- linux-2.6-powerpc-df.orig/arch/powerpc/kernel/Makefile
+++ linux-2.6-powerpc-df/arch/powerpc/kernel/Makefile
@@ -52,7 +52,8 @@ extra-$(CONFIG_8xx) := head_8xx.o
extra-y += vmlinux.lds
obj-y += time.o prom.o traps.o setup-common.o \
- udbg.o misc.o io.o
+ misc.o io.o
+obj-$(CONFIG_PPC_UDBG) += udbg.o
obj-$(CONFIG_PPC32) += entry_32.o setup_32.o misc_32.o
obj-$(CONFIG_PPC64) += misc_64.o dma_64.o iommu.o
obj-$(CONFIG_PPC_MULTIPLATFORM) += prom_init.o
Index: linux-2.6-powerpc-df/arch/powerpc/platforms/Kconfig
===================================================================
--- linux-2.6-powerpc-df.orig/arch/powerpc/platforms/Kconfig
+++ linux-2.6-powerpc-df/arch/powerpc/platforms/Kconfig
@@ -61,6 +61,7 @@ config UDBG_RTAS_CONSOLE
config PPC_UDBG_BEAT
bool "BEAT based debug console"
depends on PPC_CELLEB
+ select PPC_UDBG
default n
config XICS
@@ -87,6 +88,7 @@ config U3_DART
config PPC_RTAS
bool
+ select PPC_UDBG
default n
config RTAS_ERROR_LOGGING
Index: linux-2.6-powerpc-df/include/asm-powerpc/udbg.h
===================================================================
--- linux-2.6-powerpc-df.orig/include/asm-powerpc/udbg.h
+++ linux-2.6-powerpc-df/include/asm-powerpc/udbg.h
@@ -11,6 +11,8 @@
#define _ASM_POWERPC_UDBG_H
#ifdef __KERNEL__
+#ifdef CONFIG_PPC_UDBG
+
#include <linux/compiler.h>
#include <linux/init.h>
@@ -49,5 +51,12 @@ extern void __init udbg_init_debug_beat(
extern void __init udbg_init_btext(void);
extern void __init udbg_init_44x_as1(void);
+#else
+
+#define udbg_early_init()
+#define register_early_udbg_console()
+
+#endif /* CONFIG_PPC_UDBG */
+
#endif /* __KERNEL__ */
#endif /* _ASM_POWERPC_UDBG_H */
Index: linux-2.6-powerpc-df/arch/powerpc/platforms/iseries/Kconfig
===================================================================
--- linux-2.6-powerpc-df.orig/arch/powerpc/platforms/iseries/Kconfig
+++ linux-2.6-powerpc-df/arch/powerpc/platforms/iseries/Kconfig
@@ -2,6 +2,7 @@ config PPC_ISERIES
bool "IBM Legacy iSeries"
depends on PPC_MULTIPLATFORM && PPC64
select PPC_INDIRECT_IO
+ select PPC_UDBG
menu "iSeries device drivers"
depends on PPC_ISERIES
Index: linux-2.6-powerpc-df/arch/powerpc/platforms/powermac/Kconfig
===================================================================
--- linux-2.6-powerpc-df.orig/arch/powerpc/platforms/powermac/Kconfig
+++ linux-2.6-powerpc-df/arch/powerpc/platforms/powermac/Kconfig
@@ -5,6 +5,7 @@ config PPC_PMAC
select PPC_INDIRECT_PCI if PPC32
select PPC_MPC106 if PPC32
select PPC_NATIVE
+ select PPC_UDBG
default y
config PPC_PMAC64
^ permalink raw reply
* Re: [PATCH] Fix drivers/rtc/Kconfig for powerpc
From: Wade Farnsworth @ 2007-06-06 17:17 UTC (permalink / raw)
To: Jon Loeliger; +Cc: a.zummo, rtc-linux, linuxppc-dev
In-Reply-To: <1181149622.12740.32.camel@ld0161-tx32>
On Wed, 2007-06-06 at 12:07 -0500, Jon Loeliger wrote:
> On Wed, 2007-06-06 at 11:57, Wade Farnsworth wrote:
> > The powerpc arch uses CONFIG_PPC instead of CONFIG_POWERPC. This fixes
> > drivers/rtc/Kconfig to use the correct config option.
> >
> > Signed-off-by: Wade Farnsworth <wfarnsworth@mvista.com>
> >
> > ---
> > This is a resubmission of a patch I sent a few weeks ago. I'm
> > resubmitting this as I haven't seen any activity regarding this patch
> > since I submitted it.
>
> Did you miss where I ACK'ed it 16-May-2007? :-)
Ah okay, maybe I don't understand what that means. When you say
"Acked-by" does that mean you'll push it upstream?
What I meant was I haven't seen anybody pick up this patch yet, and
would like to know it if will be, or if there is something else I need
to do.
--Wade
>
>
> From: Jon Loeliger <jdl@freescale.com>
> To: Wade Farnsworth <wfarnsworth@mvista.com>
> Cc: linuxppc-dev <linuxppc-dev@ozlabs.org>, rtc-linux@googlegroups.com
> Subject: Re: [PATCH] Fix drivers/rtc/Kconfig for powerpc
> Date: Wed, 16 May 2007 11:31:26 -0500
>
> On Tue, 2007-05-15 at 11:53, Wade Farnsworth wrote:
> > The powerpc arch uses CONFIG_PPC instead of CONFIG_POWERPC. This makes
> > drivers/rtc/Kconfig to use the correct config option.
> >
> > Signed-off-by: Wade Farnsworth <wfarnsworth@mvista.com>
>
> Acked-by: Jon Loeliger <jdl@freescale.com>
>
> jdl
>
>
^ permalink raw reply
* Re: [PATCH] Fix drivers/rtc/Kconfig for powerpc
From: Jon Loeliger @ 2007-06-06 17:07 UTC (permalink / raw)
To: Wade Farnsworth; +Cc: a.zummo, rtc-linux, linuxppc-dev
In-Reply-To: <1181149064.5674.134.camel@rhino>
On Wed, 2007-06-06 at 11:57, Wade Farnsworth wrote:
> The powerpc arch uses CONFIG_PPC instead of CONFIG_POWERPC. This fixes
> drivers/rtc/Kconfig to use the correct config option.
>
> Signed-off-by: Wade Farnsworth <wfarnsworth@mvista.com>
>
> ---
> This is a resubmission of a patch I sent a few weeks ago. I'm
> resubmitting this as I haven't seen any activity regarding this patch
> since I submitted it.
Did you miss where I ACK'ed it 16-May-2007? :-)
From: Jon Loeliger <jdl@freescale.com>
To: Wade Farnsworth <wfarnsworth@mvista.com>
Cc: linuxppc-dev <linuxppc-dev@ozlabs.org>, rtc-linux@googlegroups.com
Subject: Re: [PATCH] Fix drivers/rtc/Kconfig for powerpc
Date: Wed, 16 May 2007 11:31:26 -0500
On Tue, 2007-05-15 at 11:53, Wade Farnsworth wrote:
> The powerpc arch uses CONFIG_PPC instead of CONFIG_POWERPC. This makes
> drivers/rtc/Kconfig to use the correct config option.
>
> Signed-off-by: Wade Farnsworth <wfarnsworth@mvista.com>
Acked-by: Jon Loeliger <jdl@freescale.com>
jdl
^ permalink raw reply
* [PATCH] Fix drivers/rtc/Kconfig for powerpc
From: Wade Farnsworth @ 2007-06-06 16:57 UTC (permalink / raw)
To: a.zummo; +Cc: linuxppc-dev, rtc-linux
The powerpc arch uses CONFIG_PPC instead of CONFIG_POWERPC. This fixes
drivers/rtc/Kconfig to use the correct config option.
Signed-off-by: Wade Farnsworth <wfarnsworth@mvista.com>
---
This is a resubmission of a patch I sent a few weeks ago. I'm
resubmitting this as I haven't seen any activity regarding this patch
since I submitted it.
drivers/rtc/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-2.6-powerpc-8641/drivers/rtc/Kconfig
===================================================================
--- linux-2.6-powerpc-8641.orig/drivers/rtc/Kconfig
+++ linux-2.6-powerpc-8641/drivers/rtc/Kconfig
@@ -246,7 +246,7 @@ comment "Platform RTC drivers"
config RTC_DRV_CMOS
tristate "PC-style 'CMOS'"
depends on RTC_CLASS && (X86 || ALPHA || ARM26 || ARM \
- || M32R || ATARI || POWERPC || MIPS)
+ || M32R || ATARI || PPC || MIPS)
help
Say "yes" here to get direct support for the real time clock
found in every PC or ACPI-based system, and some other boards.
^ permalink raw reply
* Re: [patch 07/18] PS3: Make ps3av.h usable from user space
From: Geoff Levand @ 2007-06-06 16:44 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Geert Uytterhoeven, linuxppc-dev, Paul Mackerras, Masashi Kimoto
In-Reply-To: <20070606074609.GA31975@lst.de>
Christoph Hellwig wrote:
> On Tue, Jun 05, 2007 at 08:00:07PM -0700, Geoff Levand wrote:
>> The user applications to manage the PS3 AV modes can use values
>> defined in this header.
>
> NACK. First please don't introduce new unifdef-y headers but always
> separated them. Second I don't see any of the values actually used
> in a user<->kerne interface. If the application only happens to use
> the same values it should ship a copy of the header intead.
Yes, they are currently used with ioctl for video mode selection
by the ps3videomode utility.
OK, you recommend having two headers one for the kernel and one for
the application or library, then keeping them in sync. I think
in some ways that is easier for the package user also, since there
is no dependency on kernel headers. It does mean that the package
definitions need to be kept up to date.
-Geoff
^ permalink raw reply
* [PATCH] When checking I8042 io port, use of_find_compatible_node() instead of of_find_node_by_type()
From: Wade Farnsworth @ 2007-06-06 16:42 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
In check_legacy_ioport(), instead of using of_find_node_by_type() to
find the 8042 node, use of_find_compatible_node() to find either the
keyboard or mouse node.
Signed-off-by: Wade Farnsworth <wfarnsworth@mvista.com>
---
arch/powerpc/kernel/setup-common.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
Index: linux-2.6-powerpc-8641/arch/powerpc/kernel/setup-common.c
===================================================================
--- linux-2.6-powerpc-8641.orig/arch/powerpc/kernel/setup-common.c
+++ linux-2.6-powerpc-8641/arch/powerpc/kernel/setup-common.c
@@ -517,7 +517,14 @@ int check_legacy_ioport(unsigned long ba
switch(base_port) {
case I8042_DATA_REG:
- np = of_find_node_by_type(NULL, "8042");
+ np = of_find_compatible_node(NULL, NULL, "pnpPNP,303");
+ if (!np)
+ np = of_find_compatible_node(NULL, NULL, "pnpPNP,f03");
+ if (np) {
+ parent = of_get_parent(np);
+ of_node_put(np);
+ np = parent;
+ }
break;
case FDC_BASE: /* FDC1 */
np = of_find_node_by_type(NULL, "fdc");
^ permalink raw reply
* [PATCH] Create add_rtc() function to enable the RTC CMOS driver
From: Wade Farnsworth @ 2007-06-06 16:37 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
Signed-off-by: Wade Farnsworth <wfarnsworth@mvista.com>
---
arch/powerpc/kernel/setup-common.c | 31 +++++++++++++++++++++++++++
1 file changed, 31 insertions(+)
Index: linux-2.6-powerpc-8641/arch/powerpc/kernel/setup-common.c
===================================================================
--- linux-2.6-powerpc-8641.orig/arch/powerpc/kernel/setup-common.c
+++ linux-2.6-powerpc-8641/arch/powerpc/kernel/setup-common.c
@@ -32,6 +32,7 @@
#include <linux/unistd.h>
#include <linux/serial.h>
#include <linux/serial_8250.h>
+#include <linux/mc146818rtc.h>
#include <asm/io.h>
#include <asm/prom.h>
#include <asm/processor.h>
@@ -447,6 +448,36 @@ static __init int add_pcspkr(void)
}
device_initcall(add_pcspkr);
+#ifdef CONFIG_RTC_DRV_CMOS
+static int __init add_rtc(void)
+{
+ struct device_node *np;
+ struct platform_device *pd;
+ struct resource res;
+
+ np = of_find_compatible_node(NULL, NULL, "pnpPNP,b00");
+ if (!np)
+ return -ENODEV;
+
+ if (of_address_to_resource(np, 0, &res)) {
+ of_node_put(np);
+ return -ENODEV;
+ }
+
+ pd = platform_device_register_simple("rtc_cmos", -1,
+ &res, 1);
+ of_node_put(np);
+ if (IS_ERR(pd))
+ return PTR_ERR(pd);
+
+ /* rtc-cmos only supports 24-hr mode */
+ CMOS_WRITE(CMOS_READ(RTC_CONTROL) | RTC_24H, RTC_CONTROL);
+
+ return 0;
+}
+device_initcall(add_rtc);
+#endif /* CONFIG_RTC_DRV_CMOS */
+
void probe_machine(void)
{
extern struct machdep_calls __machine_desc_start;
^ permalink raw reply
* [PATCH] Fix the LPC47M192 SuperIO on the MPC8641 HPCN
From: Wade Farnsworth @ 2007-06-06 16:30 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
This is a fix for the LPC47M192 SuperIO on the MPC8641 HPCN.
Specifically this fixes support for the I8042 Keyboard/Mouse and the
GPIO on the chip.
Also, the mouse needs to use IRQ 12, which is currently in use by some
PCI devices. Move those devices to IRQ 11, and reserve IRQ 12 for the
mouse.
Signed-off-by: Wade Farnsworth <wfarnsworth@mvista.com>
---
Note that I submitted this previously as part of a larger patchset.
Most of the other patches in the set have been obsoleted, so I'm now
submitting this as a standalone patch.
arch/powerpc/boot/dts/mpc8641_hpcn.dts | 4 -
arch/powerpc/platforms/86xx/mpc86xx_hpcn.c | 43 +++++++++++++++----
2 files changed, 38 insertions(+), 9 deletions(-)
Index: linux-2.6-powerpc-8641/arch/powerpc/boot/dts/mpc8641_hpcn.dts
===================================================================
--- linux-2.6-powerpc-8641.orig/arch/powerpc/boot/dts/mpc8641_hpcn.dts
+++ linux-2.6-powerpc-8641/arch/powerpc/boot/dts/mpc8641_hpcn.dts
@@ -268,7 +268,7 @@
/* IDSEL 0x1c */
e000 0 0 1 &i8259 9 2
e000 0 0 2 &i8259 a 2
- e000 0 0 3 &i8259 c 2
+ e000 0 0 3 &i8259 b 2
e000 0 0 4 &i8259 7 2
/* IDSEL 0x1d */
@@ -278,7 +278,7 @@
e800 0 0 4 &i8259 0 0
/* IDSEL 0x1e */
- f000 0 0 1 &i8259 c 2
+ f000 0 0 1 &i8259 b 2
f000 0 0 2 &i8259 0 0
f000 0 0 3 &i8259 0 0
f000 0 0 4 &i8259 0 0
Index: linux-2.6-powerpc-8641/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c
===================================================================
--- linux-2.6-powerpc-8641.orig/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c
+++ linux-2.6-powerpc-8641/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c
@@ -141,7 +141,7 @@ const unsigned char uli1575_irq_route_ta
0x1, /* 9: 0b0001 */
0x3, /* 10: 0b0011 */
0x9, /* 11: 0b1001 */
- 0xb, /* 12: 0b1011 */
+ 0, /* 12: Reserved */
0, /* 13: Reserved */
0xd, /* 14, 0b1101 */
0xf, /* 15, 0b1111 */
@@ -211,7 +211,7 @@ static void __devinit quirk_uli1575(stru
pirq_map_word |= (uli1575_irq_route_table[i] & 0xf)
<< ((irq2pin[i] - PIRQA) * 4);
- /* ULI1575 IRQ mapping conf register default value is 0xb9317542 */
+ /* ULI1575 IRQ mapping conf register default value is 0x09317542 */
DBG("Setup ULI1575 IRQ mapping configuration register value = 0x%x\n",
pirq_map_word);
pci_write_config_dword(dev, 0x48, pirq_map_word);
@@ -266,9 +266,9 @@ static void __devinit quirk_uli1575(stru
pci_write_config_byte(dev, 0x44, 0x30 | uli1575_irq_route_table[14]);
pci_write_config_byte(dev, 0x75, uli1575_irq_route_table[15]);
- /* Set IRQ14 and IRQ15 to legacy IRQs */
+ /* Set IRQ1, IRQ12, IRQ14 and IRQ15 to legacy IRQs */
pci_read_config_word(dev, 0x46, &temp);
- temp |= 0xc000;
+ temp |= 0xd002;
pci_write_config_word(dev, 0x46, temp);
/* Set i8259 interrupt trigger
@@ -280,12 +280,12 @@ static void __devinit quirk_uli1575(stru
* IRQ 9: Level
* IRQ 10: Level
* IRQ 11: Level
- * IRQ 12: Level
+ * IRQ 12: Edge
* IRQ 14: Edge
* IRQ 15: Edge
*/
- outb(0xfa, 0x4d0);
- outb(0x1e, 0x4d1);
+ outb(0xf8, 0x4d0);
+ outb(0x0e, 0x4d1);
#undef ULI1575_SET_DEV_IRQ
@@ -293,6 +293,35 @@ static void __devinit quirk_uli1575(stru
pci_read_config_byte(dev, 0xb8, &c);
c &= 0x7f;
pci_write_config_byte(dev, 0xb8, c);
+
+ /* enable superio @ 0x4e and keyboard/mouse address decoding */
+ pci_write_config_byte(dev, 0x63, 0x90);
+
+ /* LPC47M192 Super I/O configuration */
+ outb(0x55, 0x4e); /* enter superio config mode */
+
+ /* Enable keyboard and mouse */
+ outb(0x07, 0x4e); /* device selector register */
+ outb(0x07, 0x4f); /* select keyboard registers (device 7) */
+ outb(0x30, 0x4e); /* keyboard activation register */
+ outb(0x01, 0x4f); /* activate keyboard */
+ outb(0x70, 0x4e); /* keyboard IRQ register */
+ outb(0x01, 0x4f); /* IRQ1 for keyboard */
+ outb(0x72, 0x4e); /* mouse IRQ register */
+ outb(0x0c, 0x4f); /* IRQ12 for mouse */
+
+ /* Enable superio runtime registers for gpio in pci i/o space */
+ outb(0x20, 0x4e); /* device id register */
+ outb(0x07, 0x4e); /* device selector register */
+ outb(0x0a, 0x4f); /* select runtime registers (device A) */
+ outb(0x60, 0x4e); /* select runtime register address high byte */
+ outb(0x04, 0x4f); /* runtime register address high byte */
+ outb(0x61, 0x4e); /* select runtime register address low byte */
+ outb(0x01, 0x4f); /* runtime register address low byte */
+ outb(0x30, 0x4e); /* runtime registers activation register */
+ outb(0x01, 0x4f); /* activate runtime registers */
+
+ outb(0xaa, 0x4e); /* exit superio config mode */
}
static void __devinit quirk_uli5288(struct pci_dev *dev)
^ permalink raw reply
* Re: MPC8272 LPT support
From: David Hawkins @ 2007-06-06 16:05 UTC (permalink / raw)
To: Kruit, Chris van der [FINT]; +Cc: linuxppc-embedded
In-Reply-To: <C89EFD3CD56F64468D3D206D683A8D22351B7A@ldam-msx2.fugro-nl.local>
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
> board for our new project. I found a board with a MPC8272 processor; it
> got all the IO we need, except for a LPT port that we use now for
> driving a HD44780 based display.
>
> Now the MPC8272 has a lot free GPIO pins which can be used for driving
> the HD44780 controller.
>
> Now my question is if there are drivers for these GPIO pins and if there
> 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 = NULL;
static unsigned int mem_phys = 0;
static unsigned int mem_pages = 0;
static unsigned int mem_size = 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 = 200;
int page_size = getpagesize();
int status;
while ((opt = getopt(argc, argv, "a:hn:")) != -1) {
switch (opt) {
case 'a':
status = sscanf(optarg, "%X", &mem_phys);
if (status != 1) {
printf("Parse error for -a option\n");
show_usage();
return -1;
}
break;
case 'h':
show_usage();
return -1;
case 'n':
mem_pages = atoi(optarg);
break;
default:
show_usage();
return -1;
}
}
if (mem_phys != (mem_phys/page_size)*page_size) {
printf("Error: the address must be page-aligned (0x%X)\n",
page_size);
return -1;
}
if (mem_pages == 0) {
mem_pages = 1;
}
mem_size = mem_pages*page_size;
/* Startup */
printf("\n------------------------\n");
printf("/dev/mem debug interface\n");
printf("========================\n\n");
/* Open /dev/mem and map it */
printf(" * open /dev/mem\n");
fd = 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 = (char *)mmap(
0,
mem_size,
PROT_READ|PROT_WRITE,
MAP_SHARED,
fd,
mem_phys);
if (mem_addr == (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] == '\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 = 0;
int addr = 0;
int len = 0;
int status;
int i, data;
/* d, db, dw */
status = sscanf(cmd, "%*c%c %x %x", &width, &addr, &len);
if (status != 3) {
printf("syntax error (use ? for help)\n");
return;
}
if (len > mem_size) {
len = mem_size;
}
/* Convert to offset if required */
if (addr >= mem_phys) {
addr -= mem_phys;
}
if (addr >= mem_size) {
printf("Illegal address\n");
return;
}
switch (width) {
case 'b':
for (i = 0; i < len; i++) {
if ((i%16) == 0) {
printf("\n%.8X: ", mem_phys + addr + i);
}
data = (int)(mem_addr[addr+i]) & 0xFF;
printf("%.02X ", data);
}
printf("\n");
break;
default:
for (i = 0; i < len; i+=4) {
if ((i%16) == 0) {
printf("\n%.8X: ", mem_phys + addr + i);
}
data = *(int *)(mem_addr + addr + i);
printf("%.08X ", data);
}
printf("\n");
break;
}
printf("\n");
return;
}
void change_mem(char *cmd)
{
char width = 0;
int addr = 0;
int data = 0;
int status;
/* c, cb, cw */
status = sscanf(cmd, "%*c%c %x %x", &width, &addr, &data);
if (status != 3) {
printf("syntax error (use ? for help)\n");
return;
}
/* Convert to offset if required */
if (addr >= mem_phys) {
addr -= mem_phys;
}
if (addr >= mem_size) {
printf("Illegal address\n");
return;
}
switch (width) {
case 'b':
mem_addr[addr] = data & 0xFF;
break;
default:
*(int *)(mem_addr + addr) = data;
break;
}
return;
}
^ permalink raw reply
* RE: [PATCH] Simple driver for Xilinx SPI controler.
From: Stephen Neuendorffer @ 2007-06-06 16:03 UTC (permalink / raw)
To: Andrei Konovalov, spi-devel-general; +Cc: linuxppc-embedded
In-Reply-To: <4666BF47.8080103@ru.mvista.com>
In order to anticipate future Microblaze support with most of these
drivers,
we've been moving towards having all of the Kconfig dependencies on
XILINX_EDK,
rather than XILINX_VIRTEX...
Steve Neuendorffer
> -----Original Message-----
> From:=20
> linuxppc-embedded-bounces+stephen=3Dneuendorffer.name@ozlabs.org
> =20
> [mailto:linuxppc-embedded-bounces+stephen=3Dneuendorffer.name@oz
labs.org] On Behalf Of Andrei Konovalov
> Sent: Wednesday, June 06, 2007 7:06 AM
> To: spi-devel-general@lists.sourceforge.net
> Cc: linuxppc-embedded@ozlabs.org
> Subject: [PATCH] Simple driver for Xilinx SPI controler.
>=20
> +config SPI_XILINX
> + tristate "Xilinx SPI controller"
> + depends on SPI_MASTER && XILINX_VIRTEX && EXPERIMENTAL
> + select SPI_BITBANG
> + help
> + This enables using the SPI controller IP from Xilinx=20
> EDK in master
> + mode. See the DS464, "OPB Serial Peripheral Interface=20
> (SPI) (v1.00e)"
> + Product Specification document for the hardware details.
> #
> # Add new SPI master controllers in alphabetical order=20
> above this line
> #
> diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile=20
> index 5788d86..a2412bd 100644
> --- a/drivers/spi/Makefile
> +++ b/drivers/spi/Makefile
> @@ -23,6 +23,7 @@ obj-$(CONFIG_SPI_MPC52xx_PSC) =09
> +=3D mpc52xx_psc_spi.o
> obj-$(CONFIG_SPI_MPC83xx) +=3D spi_mpc83xx.o
> obj-$(CONFIG_SPI_S3C24XX_GPIO) +=3D spi_s3c24xx_gpio.o
> obj-$(CONFIG_SPI_S3C24XX) +=3D spi_s3c24xx.o
> +obj-$(CONFIG_SPI_XILINX) +=3D xilinx_spi.o
> # ... add above this line ...
>=20
> # SPI protocol drivers (device/link on bus) diff --git=20
> a/drivers/spi/xilinx_spi.c b/drivers/spi/xilinx_spi.c new=20
> file mode 100644 index 0000000..e5f149f
> --- /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=20
> licensed under=20
> +the
> + * terms of the GNU General Public License version 2. This=20
> program is=20
> +licensed
> + * "as is" without any warranty of any kind, whether express=20
> or implied.
> + */
> +
> +#include <linux/module.h>
> +#include <linux/init.h>
> +#include <linux/interrupt.h>
> +#include <linux/platform_device.h>
> +#include <linux/spi/spi.h>
> +#include <linux/spi/spi_bitbang.h>
> +
> +#include <asm/io.h>
> +#include <syslib/virtex_devices.h>
> +
> +#define XILINX_SPI_NAME "xspi"
> +
> +/* Register definitions as per "OPB Serial Peripheral=20
> Interface (SPI)=20
> +(v1.00e)
> + * Product Specification", DS464
> + */
> +#define XSPI_CR_OFFSET 0x62 /* 16-bit=20
> Control Register */
> +
> +#define XSPI_CR_ENABLE 0x02
> +#define XSPI_CR_MASTER_MODE 0x04
> +#define XSPI_CR_CPOL 0x08
> +#define XSPI_CR_CPHA 0x10
> +#define XSPI_CR_MODE_MASK (XSPI_CR_CPHA | XSPI_CR_CPOL)
> +#define XSPI_CR_TXFIFO_RESET 0x20
> +#define XSPI_CR_RXFIFO_RESET 0x40
> +#define XSPI_CR_MANUAL_SSELECT 0x80
> +#define XSPI_CR_TRANS_INHIBIT 0x100
> +
> +#define XSPI_SR_OFFSET 0x67 /* 8-bit Status=20
> Register */
> +
> +#define XSPI_SR_RX_EMPTY_MASK 0x01 /* Receive FIFO=20
> is empty */
> +#define XSPI_SR_RX_FULL_MASK 0x02 /* Receive FIFO is full */
> +#define XSPI_SR_TX_EMPTY_MASK 0x04 /* Transmit=20
> FIFO is empty */
> +#define XSPI_SR_TX_FULL_MASK 0x08 /* Transmit FIFO is full */
> +#define XSPI_SR_MODE_FAULT_MASK 0x10 /* Mode fault error */
> +
> +#define XSPI_TXD_OFFSET 0x6b /* 8-bit Data=20
> Transmit Register */
> +#define XSPI_RXD_OFFSET 0x6f /* 8-bit Data=20
> Receive Register */
> +
> +#define XSPI_SSR_OFFSET 0x70 /* 32-bit Slave=20
> Select Register */
> +
> +/* Register definitions as per "OPB IPIF (v3.01c) Product=20
> +Specification", DS414
> + * IPIF registers are 32 bit
> + */
> +#define XIPIF_V123B_DGIER_OFFSET 0x1c /* IPIF global=20
> int enable reg */
> +#define XIPIF_V123B_GINTR_ENABLE 0x80000000
> +
> +#define XIPIF_V123B_IISR_OFFSET 0x20 /* IPIF=20
> interrupt status reg */
> +#define XIPIF_V123B_IIER_OFFSET 0x28 /* IPIF=20
> interrupt enable reg */
> +
> +#define XSPI_INTR_MODE_FAULT 0x01 /* Mode fault error */
> +#define XSPI_INTR_SLAVE_MODE_FAULT 0x02 /* Selected as=20
> slave while
> + * disabled */
> +#define XSPI_INTR_TX_EMPTY 0x04 /* TxFIFO is empty */
> +#define XSPI_INTR_TX_UNDERRUN 0x08 /*=20
> TxFIFO was underrun */
> +#define XSPI_INTR_RX_FULL 0x10 /* RxFIFO is full */
> +#define XSPI_INTR_RX_OVERRUN 0x20 /* RxFIFO was overrun */
> +
> +#define XIPIF_V123B_RESETR_OFFSET 0x40 /* IPIF reset=20
> register */
> +#define XIPIF_V123B_RESET_MASK 0x0a /* the=20
> value to write */
> +
> +/* 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=20
> *)(addr), (value))
> +#define xspi_out32(addr, value) out_be32((u32 __iomem=20
> *)(addr), (value))
> +
> +struct xilinx_spi {
> + /* bitbang has to be first */
> + struct spi_bitbang bitbang;
> + struct completion done;
> +
> + u32 regs_phys; /* phys. address of the=20
> control registers */
> + void __iomem *regs; /* virt. address of the=20
> control registers */
> +
> + u32 irq;
> +
> + u8 *rx_ptr; /* pointer in the Tx buffer */
> + const u8 *tx_ptr; /* pointer in the Rx buffer */
> + int remaining_bytes; /* the number of bytes left to=20
> transfer */
> +};
> +
> +static void xspi_abort_transfer(u8 __iomem *regs_base) {
> + /* Deselect the slave on the SPI bus */
> + xspi_out32(regs_base + XSPI_SSR_OFFSET, 0xffff);
> +
> + /* Terminate transmit in progress (if any) and Reset=20
> the FIFOs */
> + xspi_out16(regs_base + XSPI_CR_OFFSET,
> + xspi_in16(regs_base + XSPI_CR_OFFSET)
> + | XSPI_CR_TRANS_INHIBIT | XSPI_CR_TXFIFO_RESET
> + | XSPI_CR_RXFIFO_RESET);
> +}
> +
> +static void xspi_init_hw(u8 __iomem *regs_base) {
> + /* Reset the SPI device */
> + xspi_out32(regs_base + XIPIF_V123B_RESETR_OFFSET,
> + XIPIF_V123B_RESET_MASK);
> + /* Disable all the interrupts just in case */
> + xspi_out32(regs_base + XIPIF_V123B_IIER_OFFSET, 0);
> + /* Enable the global IPIF interrupt */
> + xspi_out32(regs_base + XIPIF_V123B_DGIER_OFFSET,
> + XIPIF_V123B_GINTR_ENABLE);
> + /* Deselect the slave on the SPI bus */
> + xspi_out32(regs_base + XSPI_SSR_OFFSET, 0xffff);
> + /* Disable the transmitter, enable Manual Slave Select=20
> Assertion,
> + * put SPI controller into master mode, and enable it */
> + xspi_out16(regs_base + XSPI_CR_OFFSET,
> + XSPI_CR_TRANS_INHIBIT | XSPI_CR_MANUAL_SSELECT
> + | XSPI_CR_MASTER_MODE | XSPI_CR_ENABLE); }
> +
> +static void xilinx_spi_chipselect(struct spi_device *spi,=20
> int is_on) {
> + struct xilinx_spi *xspi;
> + u8 __iomem *regs_base;
> +
> + xspi =3D spi_master_get_devdata(spi->master);
> + regs_base =3D xspi->regs;
> +
> + if (is_on =3D=3D BITBANG_CS_INACTIVE) {
> + /* Deselect the slave on the SPI bus */
> + xspi_out32(regs_base + XSPI_SSR_OFFSET, 0xffff);
> + } else if (is_on =3D=3D BITBANG_CS_ACTIVE) {
> + /* Set the SPI clock phase and polarity */
> + u16 cr =3D xspi_in16(regs_base + XSPI_CR_OFFSET)
> + & ~XSPI_CR_MODE_MASK;
> + if (spi->mode & SPI_CPHA)
> + cr |=3D XSPI_CR_CPHA;
> + if (spi->mode & SPI_CPOL)
> + cr |=3D XSPI_CR_CPOL;
> + xspi_out16(regs_base + XSPI_CR_OFFSET, cr);
> +
> + /* We do not check spi->max_speed_hz here as=20
> the SPI clock
> + * frequency is not software programmable (the=20
> IP block design
> + * parameter)
> + */
> +
> + /* Activate the chip select */
> + xspi_out32(regs_base + XSPI_SSR_OFFSET,
> + ~(0x0001 << spi->chip_select));
> + }
> +}
> +
> +/* spi_bitbang requires custom setup_transfer() to be=20
> defined if there=20
> +is a
> + * custom txrx_bufs(). We have nothing to setup here as the SPI IP=20
> +block
> + * supports just 8 bits per word, and SPI clock can't be=20
> changed in software.
> + * Check for 8 bits per word; speed_hz checking could be=20
> added if the=20
> +SPI
> + * clock information is available. Chip select delay=20
> calculations could=20
> +be
> + * added here as soon as bitbang_work() can be made aware of=20
> the delay value.
> + */
> +static int xilinx_spi_setup_transfer(struct spi_device *spi,
> + struct spi_transfer *t)
> +{
> + u8 bits_per_word;
> +
> + bits_per_word =3D (t) ? t->bits_per_word : spi->bits_per_word;
> + if (bits_per_word !=3D 8)
> + return -EINVAL;
> +
> + return 0;
> +}
> +
> +
> +static int xilinx_spi_setup(struct spi_device *spi) {
> + struct spi_bitbang *bitbang;
> + struct xilinx_spi *xspi;
> + int retval;
> +
> + xspi =3D spi_master_get_devdata(spi->master);
> + bitbang =3D &xspi->bitbang;
> +
> + if (!spi->bits_per_word)
> + spi->bits_per_word =3D 8;
> +
> + retval =3D xilinx_spi_setup_transfer(spi, NULL);
> + if (retval < 0)
> + return retval;
> +
> + dev_dbg(&spi->dev, "%s, mode %d, %u bits/w, %u nsec/bit\n",
> + __FUNCTION__, spi->mode & (SPI_CPOL | SPI_CPHA),
> + spi->bits_per_word, 0);
> +
> + return 0;
> +}
> +
> +static int xilinx_spi_txrx_bufs(struct spi_device *spi, struct=20
> +spi_transfer *t) {
> + struct xilinx_spi *xspi;
> + u8 __iomem *regs_base;
> + u32 ipif_ier;
> + u16 cr;
> + u8 sr;
> +
> + /* We get here with transmitter inhibited */
> +
> + xspi =3D spi_master_get_devdata(spi->master);
> + regs_base =3D xspi->regs;
> +
> + xspi->tx_ptr =3D t->tx_buf;
> + xspi->rx_ptr =3D t->rx_buf;
> + xspi->remaining_bytes =3D t->len;
> + INIT_COMPLETION(xspi->done);
> +
> + /* Fill the Tx FIFO with as many bytes as possible */
> + sr =3D in_8(regs_base + XSPI_SR_OFFSET);
> + while ((sr & XSPI_SR_TX_FULL_MASK) =3D=3D 0 &&=20
> xspi->remaining_bytes > 0) {
> + if (xspi->tx_ptr) {
> + out_8(regs_base + XSPI_TXD_OFFSET,=20
> *xspi->tx_ptr++);
> + } else {
> + out_8(regs_base + XSPI_TXD_OFFSET, 0);
> + }
> + xspi->remaining_bytes--;
> + sr =3D in_8(regs_base + XSPI_SR_OFFSET);
> + }
> +
> + /* Enable the transmit empty interrupt, which we use to=20
> determine
> + * progress on the transmission.
> + */
> + ipif_ier =3D xspi_in32(regs_base + XIPIF_V123B_IIER_OFFSET);
> + xspi_out32(regs_base + XIPIF_V123B_IIER_OFFSET,
> + ipif_ier | XSPI_INTR_TX_EMPTY);
> +
> + /* Start the transfer by not inhibiting the transmitter=20
> any longer */
> + cr =3D xspi_in16(regs_base + XSPI_CR_OFFSET) &=20
> ~XSPI_CR_TRANS_INHIBIT;
> + xspi_out16(regs_base + XSPI_CR_OFFSET, cr);
> +
> + wait_for_completion(&xspi->done);
> +
> + /* Disable the transmit empty interrupt */
> + xspi_out32(regs_base + XIPIF_V123B_IIER_OFFSET, ipif_ier);
> +
> + return t->len - xspi->remaining_bytes; }
> +
> +
> +/* This driver supports single master mode only. Hence Tx FIFO Empty
> + * is the only interrupt we care about.
> + * Receive FIFO Overrun, Transmit FIFO Underrun, Mode Fault,=20
> and Slave=20
> +Mode
> + * Fault are not to happen.
> + */
> +static irqreturn_t xilinx_spi_irq(int irq, void *dev_id) {
> + struct xilinx_spi *xspi;
> + u8 __iomem *regs_base;
> + u32 ipif_isr;
> +
> + xspi =3D (struct xilinx_spi *) dev_id;
> + regs_base =3D xspi->regs;
> +
> + /* Get the IPIF inetrrupts, and clear them=20
> immediately */
> + ipif_isr =3D 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=20
> completed */
> + u16 cr;
> + u8 sr;
> +
> + /* A transmit has just completed. Process=20
> received data and
> + * check for more data to transmit. Always inhibit the
> + * transmitter while the Isr refills the=20
> transmit register/FIFO,
> + * or make sure it is stopped if we're done.
> + */
> + cr =3D 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 =3D in_8(regs_base + XSPI_SR_OFFSET);
> + while ((sr & XSPI_SR_RX_EMPTY_MASK) =3D=3D 0) {
> + u8 data;
> +
> + data =3D in_8(regs_base + XSPI_RXD_OFFSET);
> + if (xspi->rx_ptr) {
> + *xspi->rx_ptr++ =3D data;
> + }
> + sr =3D 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=20
> for io_8() */
> + while ((sr & XSPI_SR_TX_FULL_MASK) =3D=3D 0
> + && xspi->remaining_bytes > 0) {
> + if (xspi->tx_ptr) {
> + out_8(regs_base +=20
> XSPI_TXD_OFFSET,
> + *xspi->tx_ptr++);
> + } else {
> + out_8(regs_base +=20
> XSPI_TXD_OFFSET, 0);
> + }
> + xspi->remaining_bytes--;
> + sr =3D in_8(regs_base + XSPI_SR_OFFSET);
> + }
> + /* Start the transfer by not inhibiting the
> + * transmitter any longer
> + */
> + xspi_out16(regs_base + XSPI_CR_OFFSET, cr);
> + } else {
> + /* No more data to send.
> + * Indicate the transfer is completed.
> + */
> + complete(&xspi->done);
> + }
> + } else {
> + /* spurious interrupt */
> + }
> +
> + return IRQ_HANDLED;
> +}
> +
> +static int __init xilinx_spi_probe(struct platform_device *dev) {
> + int ret =3D 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 =3D spi_alloc_master(&dev->dev, sizeof(struct xilinx_spi));
> +
> + if (master =3D=3D NULL) {
> + return -ENOMEM;
> + }
> +
> + platform_set_drvdata(dev, master);
> + pdata =3D dev->dev.platform_data;
> +
> + if (pdata =3D=3D NULL) {
> + ret =3D -ENODEV;
> + goto put_master;
> + }
> +
> + r =3D platform_get_resource(dev, IORESOURCE_MEM, 0);
> + if (r =3D=3D NULL) {
> + ret =3D -ENODEV;
> + goto put_master;
> + }
> +
> + xspi =3D spi_master_get_devdata(master);
> + xspi->bitbang.master =3D spi_master_get(master);
> + xspi->bitbang.chipselect =3D xilinx_spi_chipselect;
> + xspi->bitbang.setup_transfer =3D xilinx_spi_setup_transfer;
> + xspi->bitbang.txrx_bufs =3D xilinx_spi_txrx_bufs;
> + xspi->bitbang.master->setup =3D xilinx_spi_setup;
> + init_completion(&xspi->done);
> +
> + xspi->regs =3D ioremap(r->start, r->end - r->start + 1);
> + if (xspi->regs =3D=3D NULL) {
> + ret =3D -ENOMEM;
> + goto put_master;
> + }
> +
> + xspi->irq =3D platform_get_irq(dev, 0);
> + if (xspi->irq < 0) {
> + ret =3D -ENXIO;
> + goto unmap_io;
> + }
> +
> + master->bus_num =3D pdata->bus_num;
> + master->num_chipselect =3D pdata->num_chipselect;
> +
> + /* SPI controller initializations */
> + xspi_init_hw(xspi->regs);
> +
> + /* Register for SPI Interrupt */
> + ret =3D request_irq(xspi->irq, xilinx_spi_irq, 0,=20
> XILINX_SPI_NAME, xspi);
> + if (ret !=3D 0)
> + goto unmap_io;
> +
> + ret =3D spi_bitbang_start(&xspi->bitbang);
> + if (ret !=3D 0) {
> + printk(KERN_ALERT "spi_btbang_start FAILED\n");
> + goto free_irq;
> + }
> +
> + printk(KERN_INFO "%s: at 0x%08X mapped to 0x%08X, irq=3D%d\n",
> + dev->dev.bus_id, r->start, (u32)xspi->regs, xspi->irq);
> +
> + return ret;
> +
> +free_irq:
> + free_irq(xspi->irq, xspi);
> +unmap_io:
> + iounmap(xspi->regs);
> +put_master:
> + spi_master_put(master);
> + return ret;
> +}
> +
> +static int __devexit xilinx_spi_remove(struct platform_device *dev) {
> + struct xilinx_spi *xspi;
> + struct spi_master *master;
> +
> + master =3D platform_get_drvdata(dev);
> + xspi =3D spi_master_get_devdata(master);
> +
> + spi_bitbang_stop(&xspi->bitbang);
> + xspi_abort_transfer(xspi->regs);
> + free_irq(xspi->irq, xspi);
> + iounmap(xspi->regs);
> + platform_set_drvdata(dev, 0);
> + spi_master_put(xspi->bitbang.master);
> +
> + return 0;
> +}
> +
> +static struct platform_driver xilinx_spi_driver =3D {
> + .probe =3D xilinx_spi_probe,
> + .remove =3D __devexit_p(xilinx_spi_remove),
> + .driver =3D {
> + .name =3D XILINX_SPI_NAME,
> + .owner =3D THIS_MODULE,
> + },
> +};
> +
> +static int __init xilinx_spi_init(void) {
> + return platform_driver_register(&xilinx_spi_driver);
> +}
> +
> +static void __exit xilinx_spi_exit(void) {
> + platform_driver_unregister(&xilinx_spi_driver);
> +}
> +
> +module_init(xilinx_spi_init);
> +module_exit(xilinx_spi_exit);
> +
> +MODULE_AUTHOR("MontaVista Software, Inc. <source@mvista.com>");=20
> +MODULE_DESCRIPTION("Xilinx SPI driver"); MODULE_LICENSE("GPL");
> --
> 1.5.1.1
>=20
>=20
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>=20
>=20
^ permalink raw reply
* Re: [patch 02/18] PS3: Rename IPI symbols
From: Will Schmidt @ 2007-06-06 14:48 UTC (permalink / raw)
To: Geoff Levand; +Cc: Stephen Rothwell, Paul Mackerras, linuxppc-dev
In-Reply-To: <20070606131157.133ce9bb.sfr@canb.auug.org.au>
On Wed, 2007-06-06 at 13:11 +1000, Stephen Rothwell wrote:
> On Tue, 05 Jun 2007 19:59:25 -0700 Geoff Levand <geoffrey.levand@am.sony.com> wrote:
> >
> > Rename the PS3 static symbol virqs to ps3_ipi_virqs to aid in
> > debugging.
> >
> > Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
> >
> > for (i = 0; i < MSG_COUNT; i++) {
> > - free_irq(virqs[i], (void*)(long)i);
> > + /* Can't call free_irq from interrupt context. */
>
> This change is probably worth a mention in the change log - it looks like
> a bug fix.
Does the free_irq call (being removed here) need to be added back in
somewhere else?
-Will
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ 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