* Re: pmppc7448/mv64x60 DMA from PCI to memory
From: Phil Nitschke @ 2006-05-24 2:23 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20060523235449.GB1536@mag.az.mvista.com>
On Tue, 2006-05-23 at 16:54 -0700, Mark A. Greer wrote:
> You say that you don't see any PCI traffic. Does that mean you
> have a PCI analyzer and that you are sure that its set up correctly?
I don't have a PCI analyzer, however the JTAG used to program the PCI
device has been configured to display 4 K samples of PCI bus signals
(about 20 microsecs?) around the time of an interrupt which results in
the DMA being requested. Since my last post, I have managed to see some
traffic, but the PCI STOP# line is asserted, so I'm not seeing any data
being read. I'll investigate further...
> If so, then you have something botched in your IDMA->PCI window setup
Quite possibly. The patch below shows how I've set this window up. It
is not intended as a 'final' piece of code, so please forgive the magic
numbers. Could you review this for me?
> or in the pgming of the DMA itself (e.g., in your descriptor(s)).
Well the memory to memory DMA is working OK. I just didn't know what
the correct procedure was for determining the bus address of the FIFO.
For example, this mapping returns a dma handle which does not work:
fifo_dma_handle = pci_map_single(dev, my_card.bar1+fifo_address[0],
FIFO_SIZE, PCI_DMA_FROMDEVICE);
Whereas without DMA I would just use this:
ioread32_rep(my_card.bar1 + fifo_address[0], buf, 6);
Was I misguided in trying to use pci_map_single in this way?
> Also, set the SrcHold bit [3] of the channel control reg (low).
> If its really a FIFO, you are--or will be once you get your windows
> and descriptors set up correctly--reading the FIFO once then
> incrementing past it.
I can either address it as a FIFO, or as a memory range. I can read
from any address in the range and it returns the "next FIFO value".
Anyway, I've tried both src address hold settings...
> > For this scenario, can anyone tell me:
> > * Should I be using the same src address as that reported via
> > the 'lspci' command - this _is_ the PCI bus address, isn't it?
>
> "man lspci" (read up on the '-b' option)
I cannot see any difference with the '-b' flag. Maybe that is the way
of things on my architecture?
> > * Looking through mv64x60.c in the 2.6.16 kernel, I note that 4
> > of the 8 possible IDMA address windows are configured (for each
> > of the 512 MB DRAM on our processor card).
>
> No they aren't. They're configured (or not) according to the setup info
> that you pass in.
OK. I also note there are several cases where this is used in
mv64x60.c:
for (i=0; i<3; i++)
Why is 3 used in these loops, and not some other constant like
MV64360_xxxxx_WINDOWS (which are usually 4, not 3)?
> > Do I need to add
> > tests to my source and destination regions, to determine if they
> > cross one of the 512 MB regions, and hence will require a
> > different CSx line (and thus the DMA will need to be broken into
> > two transactions), or does kernel already take care to ensure
> > allocated regions will not cross these boundaries?
>
> No. You need to do what's appropriate for the hardware that you are
> essentially writing a driver for. YOU are supposed to know what the
> limitations of your hardware are.
OK, I know how my hardware is configured, but when trying to write a
generic driver, perhaps I need to have the mv64x60.c code remember the
CSx barriers, e.g. in the mv64x60_chip_info, so the IDMA engine can
access it. Do you think this would be possible/beneficial?
Thanks again,
--
Phil
Here is the patch to configure IDMA to PCI window(s):
--- linux-2.6.16/arch/ppc/syslib/mv64x60.c 2006-03-20
16:23:29.000000000 +1030
+++ linux-2.6.16-patched/arch/ppc/syslib/mv64x60.c 2006-05-23
16:33:52.000000000 +0930
@@ -535,6 +581,7 @@
mv64x60_config_pci_params(bh->hose_a, &si->pci_0);
mv64x60_config_cpu2pci_windows(bh, &si->pci_0, 0);
+ mv64x60_config_idma2pci_windows(bh, &si->pci_0, 0);
mv64x60_config_pci2mem_windows(bh, bh->hose_a,
&si->pci_0, 0,
mem_windows);
bh->ci->set_pci2regs_window(bh, bh->hose_a, 0,
@@ -548,6 +595,7 @@
mv64x60_config_pci_params(bh->hose_b, &si->pci_1);
mv64x60_config_cpu2pci_windows(bh, &si->pci_1, 1);
+ mv64x60_config_idma2pci_windows(bh, &si->pci_1, 1);
mv64x60_config_pci2mem_windows(bh, bh->hose_b,
&si->pci_1, 1,
mem_windows);
bh->ci->set_pci2regs_window(bh, bh->hose_b, 1,
@@ -1136,6 +1188,42 @@
bh->ci->disable_window_32bit(bh, win_tab[bus][i
+1]);
}
+static u32 idma_tab_xtra[MV64x60_CPU2MEM_WINDOWS] __initdata = {
+ MV64x60_IDMA2MEM_0_WIN, MV64x60_IDMA2MEM_1_WIN,
+ MV64x60_IDMA2MEM_2_WIN, MV64x60_IDMA2MEM_3_WIN,
+};
+
+void __init
+mv64x60_config_idma2pci_windows(struct mv64x60_handle *bh,
+ struct mv64x60_pci_info *pi, u32 bus)
+{
+ u32 attributes, unit_id;
+ int i;
+
+ /* Target Unit IDs: PCI0 = 3, PCI1 = 4. */
+ unit_id = bus ? 0x4 : 0x3;
+ /* 0x1d == No swap data, PCI-X NS attribute asserted, PCI memory
+ * space, PCIx_REQ64n asserted according to requested data size.
*/
+ attributes = (0x1d << 8) | unit_id;
+
+ for (i=0; i<3; i++)
+ if (pi->pci_mem[i].size > 0) {
+ mv64x60_set_32bit_window(bh, idma_tab_xtra[i],
+ pi->pci_mem[i].cpu_base,
pi->pci_mem[i].size,
+ attributes);
+ bh->ci->enable_window_32bit(bh,
idma_tab_xtra[i]);
+ /* Give idma r/w access to PCI memory region */
+ mv64x60_set_bits(bh,
MV64360_IDMA2MEM_ACC_PROT_0,
+ (0x3 << (i << 1)));
+ mv64x60_set_bits(bh,
MV64360_IDMA2MEM_ACC_PROT_1,
+ (0x3 << (i << 1)));
+ mv64x60_set_bits(bh,
MV64360_IDMA2MEM_ACC_PROT_2,
+ (0x3 << (i << 1)));
+ mv64x60_set_bits(bh,
MV64360_IDMA2MEM_ACC_PROT_3,
+ (0x3 << (i << 1)));
+ }
+}
+
/*
*****************************************************************************
*
@@ -2220,8 +2311,8 @@
};
static u32 idma_tab[MV64x60_CPU2MEM_WINDOWS] __initdata = {
- MV64x60_IDMA2MEM_0_WIN, MV64x60_IDMA2MEM_1_WIN,
- MV64x60_IDMA2MEM_2_WIN, MV64x60_IDMA2MEM_3_WIN,
+ MV64x60_IDMA2MEM_4_WIN, MV64x60_IDMA2MEM_5_WIN,
+ MV64x60_IDMA2MEM_6_WIN, MV64x60_IDMA2MEM_7_WIN,
};
static u32 dram_selects[MV64x60_CPU2MEM_WINDOWS] __initdata =
@@ -2285,13 +2376,13 @@
/* Give idma r/w access to memory region */
mv64x60_set_bits(bh,
MV64360_IDMA2MEM_ACC_PROT_0,
- (0x3 << (i << 1)));
+ (0x3 << ((i+4) << 1)));
mv64x60_set_bits(bh,
MV64360_IDMA2MEM_ACC_PROT_1,
- (0x3 << (i << 1)));
+ (0x3 << ((i+4) << 1)));
mv64x60_set_bits(bh,
MV64360_IDMA2MEM_ACC_PROT_2,
- (0x3 << (i << 1)));
+ (0x3 << ((i+4) << 1)));
mv64x60_set_bits(bh,
MV64360_IDMA2MEM_ACC_PROT_3,
- (0x3 << (i << 1)));
+ (0x3 << ((i+4) << 1)));
}
}
^ permalink raw reply
* RE: question about linux with Xilinx ML-403
From: Rick Moleres @ 2006-05-23 21:21 UTC (permalink / raw)
To: Ming Liu, rick.moleres; +Cc: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 2275 bytes --]
Ming,
-----Original Message-----
From: Ming Liu [mailto:eemingliu@hotmail.com]
Sent: Tuesday, May 23, 2006 3:42 AM
To: rick.moleres
Cc: linuxppc-embedded@ozlabs.org
Subject: question about linux with Xilinx ML-403
Hi Rick,
> Yes, we have a driver for the PLB TEMAC (different than the GSRD LL
> TEMAC) for Linux 2.4 (MontaVista Linux 2.4.20) that's shipped in EDK
> 8.1.1, and MontaVista is on the verge of publishing a driver for PLB
> TEMAC for Linux 2.6. (I believe it came across this mailing list a few
> weeks ago)
I have generated the BSP by EDK 8.1.1 for my project in ML403(hardcore
Temac and PLB Temac included). I noticed that there is a directory
called
Xilinx_gige in the directory of /drivers/net. Is this the driver for
MontaVista Linux2.4.20?
Yes, this is the PLB TEMAC driver for Linux 2.4.20. In EDK 8.1.x, the
temac driver and Makefile are copied to drivers/net/xilinx_gige. This
xilinx_gige directory is not available in the MVL 3.1 Preview Kit, only
in the full Professional kit. We put the temac driver here mostly to
take advantage of the JUMBO_FRAME_SUPPORT in kernel configuration.
I copied the BSP and overwrote the original one in
the linux kernel directory (in the kernel directory, there is only a
directory called Xilinx_enet, no Xilinx_gige. So I just copied
Xilinx_gige.). However, my problem is in the menuconfig item of Network
Device Support->1000Mbit ethernet, there is not any option to choose and
enable the Xilinx on-chip ethernet. Is this a problem of MontaVista
Linux
3.1 Preview Kit, or my problem? And What shall I do to enable the
tri-mode
Temac in my platform? Thanks for your answer.
Our best recommendation is to use the drivers/net/xilinx_enet directory
for the temac driver and just enable the Xilinx 10/100 Ethernet in
menuconfig. If you want jumbo frame support, modify adapter.c in the
driver to define the CONFIG_XILINX_GIGE_JUMBO constant.
Note that Linux 2.6 support for the temac should be available from
MontaVista soon and a driver was pushed to this mailing list in March.
There will be support for MV Linux 2.6 in EDK 8.2.1 (around August).
Thanks,
Rick
[-- Attachment #2: Type: text/html, Size: 8154 bytes --]
^ permalink raw reply
* Re: pmppc7448/mv64x60 DMA from PCI to memory
From: Mark A. Greer @ 2006-05-23 23:54 UTC (permalink / raw)
To: Phil Nitschke; +Cc: linuxppc-embedded
In-Reply-To: <1148395804.21475.53.camel@toby.int.avalon.com.au>
Hi Phil,
On Wed, May 24, 2006 at 12:20:04AM +0930, Phil Nitschke wrote:
> I've written a collection of simple routines to program the Marvell IDMA
> controller, for example:
> mv64x6x_init_dma_channel();
> mv64x6x_set_dma_mode();
> mv64x6x_set_src_addr();
> mv64x6x_set_dst_addr();
> mv64x6x_set_dma_count();
> mv64x6x_enable_dma();
> or rather more simply:
> mv64x6x_memcpy_dma(dst_handle, src_handle, size);
Listing routine names but no code doesn't really help.
> This works OK for copying from a memory to memory, where the buffers are
> allocated using:
> src = dma_alloc_noncoherent(NULL, BUF_SZ, &src_handle, GFP_KERNEL);
> The src_handle is passed directly to mv64x6x_set_src_addr();
>
> But when the src address is the FIFO on the PCI bus, I don't know how to
Do you really mean a FIFO? If so, that would explain a lot...
> get the IDMA controller to play nicely. The FIFO sits in the middle of
> the PCI device's I/O mem range 0x9fe00000 - 0x9fffffff. I've programmed
> and enabled a 5th address window in the IDMA controller which
> encompasses the 0x200000 bytes of the PCI memory range, and I'm not
> seeing any address violation or address miss errors. The PCI->memory
> DMA "completes" without any traffic every touching the PCI bus, so
> obviously I need to do something else/differently.
You say that you don't see any PCI traffic. Does that mean you
have a PCI analyzer and that you are sure that its set up correctly?
If so, then you have something botched in your IDMA->PCI window setup
or in the pgming of the DMA itself (e.g., in your descriptor(s)).
Also, set the SrcHold bit [3] of the channel control reg (low).
If its really a FIFO, you are--or will be once you get your windows
and descriptors set up correctly--reading the FIFO once then
incrementing past it.
> For this scenario, can anyone tell me:
> * Should I be using the same src address as that reported via
> the 'lspci' command - this _is_ the PCI bus address, isn't it?
"man lspci" (read up on the '-b' option)
> * Do I have to do anything special to tell the IDMA controller
> to source data from the PCI bus and shift it into memory?
You're talking to a *FIFO* which means you read all the data from one
address and write all the data to one, probably different, address.
Its not normal PCI memory, you don't increment through it. Its a
register of a FIFO that's in PCI memory space. That's why you need
to tell the IDMA ctlr to "hold" and read/write to the same address
each time.
> * Looking through mv64x60.c in the 2.6.16 kernel, I note that 4
> of the 8 possible IDMA address windows are configured (for each
> of the 512 MB DRAM on our processor card).
No they aren't. They're configured (or not) according to the setup info
that you pass in.
> Do I need to add
> tests to my source and destination regions, to determine if they
> cross one of the 512 MB regions, and hence will require a
> different CSx line (and thus the DMA will need to be broken into
> two transactions), or does kernel already take care to ensure
> allocated regions will not cross these boundaries?
No. You need to do what's appropriate for the hardware that you are
essentially writing a driver for. YOU are supposed to know what the
limitations of your hardware are. Even if you don't have a manual... ;)
Mark
^ permalink raw reply
* Re: CPU 1 refused to die!
From: Nathan Lynch @ 2006-05-23 22:51 UTC (permalink / raw)
To: Giuliano Pochini; +Cc: LinuxPPC-dev
In-Reply-To: <20060523235819.473e4149.pochini@shiny.it>
Giuliano Pochini wrote:
>
> I booted with maxcpus=1, then I enabled the 2nd cpu
> with echo 1 > /sys/devices/system/cpu/cpu1/online
So onlining at runtime seems to work. Did you verify that tasks get
run on the 2nd cpu after you online it? Any other strange messages in
dmesg?
> I can't disable it anymore. dmesg says "CPU 1 refused to die!".
But offlining doesn't.
Can you online and offline cpus if you boot without maxcpus=1?
^ permalink raw reply
* Re: Setting I&D cache enable in the same mtspr instruction
From: Mark A. Greer @ 2006-05-23 22:34 UTC (permalink / raw)
To: Assaf Hoffman; +Cc: Ronen Shitrit, Rita Shtern, linuxppc-embedded
In-Reply-To: <B9FFC3F97441D04093A504CEA31B7C41A39491@msilexch01.marvell.com>
On Tue, May 23, 2006 at 12:55:46PM +0300, Assaf Hoffman wrote:
> Attached.
> Thanks.
Er, how about a *patch* place inline (as in, not as an attachment).
Thanks,
Mark
^ permalink raw reply
* Re: snd-aoa status update / automatic driver loading
From: Benjamin Herrenschmidt @ 2006-05-23 22:15 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev list, Benjamin Berg, debian-powerpc
In-Reply-To: <1148280172.6228.79.camel@johannes.berg>
> Right, that's how snd-powermac does it. It has the nasty side-effect of
> polluting the cache a lot though, since dbdma commands are 16 bytes
> long. Am I wrong?
You don't have that much DBDMA commands that it would pollute the cache
_a lot_ :)
> > Since we can only update the framecounter on a per-period basis,
>
> Alsa calls this thing the 'pointer' :) The frame counter we currently
> use is the frame counter register of the i2s bus controller, and I don't
> see why we shouldn't do that instead of reading back all the dbdma
> command status fields.
If you manage to have it properly in sync, that may work too.
> Since the i2s bus is not shut down it also counts when we are not
> transferring data. We currently calibrate on the first interrupt. That's
> fine, since having multiple periods means that we don't need to be
> absolutely precise here. If we miss one, that's fine, we can make it up
> the next time by saying that 2 have elapsed.
Ok.
Ben.
^ permalink raw reply
* CPU 1 refused to die!
From: Giuliano Pochini @ 2006-05-23 21:58 UTC (permalink / raw)
To: LinuxPPC-dev
I booted with maxcpus=1, then I enabled the 2nd cpu
with echo 1 > /sys/devices/system/cpu/cpu1/online
I can't disable it anymore. dmesg says "CPU 1 refused to die!".
/proc/cpuinfo and /proc/interrupts show one cpu only and the tasks run on
one cpu after the echo 0 > /sys/... , but since the command takes a couple
of seconds to complete I think it's not simply a bogus error message.
Dual G4 MDD
Linux Jay 2.6.16.16 #8 SMP Sat May 13 19:15:05 CEST 2006 ppc 7455,
altivec supported PowerMac3,6 GNU/Linux
--
Giuliano.
^ permalink raw reply
* Re: [Cbe-oss-dev] Cell and new CPU feature bits
From: Benjamin Herrenschmidt @ 2006-05-23 21:52 UTC (permalink / raw)
To: Alex Rosenberg; +Cc: linuxppc-dev list, cbe-oss-dev, Arnd Bergmann
In-Reply-To: <995508C0-6D30-479A-8ED5-C28CC0143DB7@playstation.sony.com>
> > Is this bug really going to be exposed in the wild or is it
> > an early silicon bug that will only bite early-testers?
>
> Is this or any other errata published somewhere? I didn't think they
> were.
I don't know, but I got approval to publically talk about that one (that
is to get a fix in the kernel, the vDSO, and see with Steve Munroe about
getting one in glibc hptiming as well)
> Our solution back at Apple was to put OF properties on the CPU node
> for each optional feature. e.g. for fres and frsqrte we put
> "graphics" since that's the official term for that group of optional
> instructions. We also put in "data-streams" instead of presuming that
> dss, etc. were always part of "altivec". These properties nicely fit
> into our Gestalt() API where "ppcf" had 32 bits to describe these to
> userland software.
Our firmwares do something similar, at least on pSeries (the cell blade
firmware may need a bit of kicking there). But that's only useful for
the kernel. I'm more interested about what is best to expose those to
userland and we have no such thing as good ol' Gestalt there :) We have
AT_HWCAP which we already use for a combination of things, and I was
wondering about the risk of running out of bits in there. Maybe we'll
have to extend the thing a bit.
I suppose the datastream instructions will mandate their own bits,
though nobody on the field seem to use them on linux at least on open
source code I've seen, and I'll probably add a separate bit for the new
altivec instructions. I was wondering if I should define a bit for those
"graphics" instruction and dcbf X form (at least the later could be just
derived from the uArchitecture bits in there)
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 4/6] Have x86_64 use add_active_range() and free_area_init_nodes
From: Mel Gorman @ 2006-05-23 18:01 UTC (permalink / raw)
To: Andrew Morton
Cc: davej, tony.luck, linux-mm, ak, bob.picco, linux-kernel,
linuxppc-dev
In-Reply-To: <20060520135922.129a481d.akpm@osdl.org>
On Sat, 20 May 2006, Andrew Morton wrote:
> Mel Gorman <mel@csn.ul.ie> wrote:
>>
>>
>> Size zones and holes in an architecture independent manner for x86_64.
>>
>>
>
> I found a .config which triggers the cant-map-acpitables problem.
>
>
> With that .config, and without this patch:
>
> Linux version 2.6.17-rc4-mm2 (akpm@box) (gcc version 4.1.0 20060304 (Red Hat 4.6
> BIOS-provided physical RAM map:
> BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
> BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
> BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
> BIOS-e820: 0000000000100000 - 00000000ca605000 (usable)
> BIOS-e820: 00000000ca605000 - 00000000ca680000 (ACPI NVS)
> BIOS-e820: 00000000ca680000 - 00000000cb5ef000 (usable)
> BIOS-e820: 00000000cb5ef000 - 00000000cb5fc000 (reserved)
> BIOS-e820: 00000000cb5fc000 - 00000000cb6a2000 (usable)
> BIOS-e820: 00000000cb6a2000 - 00000000cb6eb000 (ACPI NVS)
> BIOS-e820: 00000000cb6eb000 - 00000000cb6ef000 (usable)
> BIOS-e820: 00000000cb6ef000 - 00000000cb6ff000 (ACPI data)
> BIOS-e820: 00000000cb6ff000 - 00000000cb700000 (usable)
> BIOS-e820: 00000000cb700000 - 00000000cc000000 (reserved)
> BIOS-e820: 00000000ffe00000 - 0000000100000000 (reserved)
> BIOS-e820: 0000000100000000 - 0000000130000000 (usable)
> DMI 2.4 present.
> ACPI: PM-Timer IO Port: 0x408
> ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
> Processor #0 6:15 APIC version 20
> ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)
> Processor #1 6:15 APIC version 20
> ACPI: LAPIC (acpi_id[0x03] lapic_id[0x82] disabled)
> ACPI: LAPIC (acpi_id[0x04] lapic_id[0x83] disabled)
> ACPI: LAPIC_NMI (acpi_id[0x01] dfl dfl lint[0x1])
> ACPI: LAPIC_NMI (acpi_id[0x02] dfl dfl lint[0x1])
> ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0])
> IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI 0-23
> ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
>
>
> With that .config, and with this patch:
>
> Bootdata ok (command line is ro root=LABEL=/ earlyprintk=serial,ttyS0,9600,keep netconsole=4444@192.168.2.4/eth0,5147@192.168.2.33/00:0D:56:C6:C6:CC)
> Linux version 2.6.17-rc4-mm2 (akpm@box) (gcc version 4.1.0 20060304 (Red Hat 4.1.0-3)) #33 SMP Sat May 20 12:08:03 PDT 2006
> BIOS-provided physical RAM map:
> BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
> BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
> BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
> BIOS-e820: 0000000000100000 - 00000000ca605000 (usable)
> BIOS-e820: 00000000ca605000 - 00000000ca680000 (ACPI NVS)
> BIOS-e820: 00000000ca680000 - 00000000cb5ef000 (usable)
> BIOS-e820: 00000000cb5ef000 - 00000000cb5fc000 (reserved)
> BIOS-e820: 00000000cb5fc000 - 00000000cb6a2000 (usable)
> BIOS-e820: 00000000cb6a2000 - 00000000cb6eb000 (ACPI NVS)
> BIOS-e820: 00000000cb6eb000 - 00000000cb6ef000 (usable)
> BIOS-e820: 00000000cb6ef000 - 00000000cb6ff000 (ACPI data)
> BIOS-e820: 00000000cb6ff000 - 00000000cb700000 (usable)
> BIOS-e820: 00000000cb700000 - 00000000cc000000 (reserved)
> BIOS-e820: 00000000ffe00000 - 0000000100000000 (reserved)
> BIOS-e820: 0000000100000000 - 0000000130000000 (usable)
> Too many memory regions, truncating
> Too many memory regions, truncating
> Too many memory regions, truncating
> DMI 2.4 present.
> ACPI: Unable to map RSDT header
> Intel MultiProcessor Specification v1.4
> Virtual Wire compatibility mode.
> OEM ID: Product ID: APIC at: 0xFEE00000
>
I think I have figured out what went wrong here.
arch/i386/kernel/acpi/boot.c has a __acpi_map_table() function which uses
a variable end_pfn_map variable defined in arch/x86_64/kernel/e820.c .
Part of the arch-independent-zone-sizing patch calculates end_pfn_map from
early_node_map[] which only contains information on real RAM regions.
On Christian's machine, there is no usable region after the ACPI table
data so early_node_map[] finishes just before the ACPI tables. This
results in the wrong value for end_pfn_map and the table fails to be
mapped. In Andrew's machines case, the regions got truncated and nothing
after ACPI NVS was recorded, including ACPI data which is why it fails to
boot.
Am not ready to release another set of patches, but I think this was the
cause of magic failures on x86_64.
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
^ permalink raw reply
* Re: Maple: killing a process that causes a machine check exception
From: Linas Vepstas @ 2006-05-23 16:48 UTC (permalink / raw)
To: Anton Blanchard; +Cc: linuxppc64-dev
In-Reply-To: <20060523162348.GC5938@krispykreme>
On Wed, May 24, 2006 at 02:23:48AM +1000, Anton Blanchard wrote:
> jfaslist <jfaslist@yahoo.fr> wrote:
> > What do you mean by synchronous? Do you mean that the current process
> > may no be not the one that caused the ME?
>
> Yeah, a device doing DMA might cause a machine check independent to your
> current task. In that case we really need to take the machine down.
>
> > In my case I _need_ the process to be killed, as it is making a VME bus
> > error. / PCI target-abort.
>
> Sounds like you need a Maple specific machine check handler. My point is
> we cant merge a fix like that because it affects every powerpc arch out
> there, all with different machine check handling requirements.
Here's an utterly crazy idea that might take a lot of work to implement,
but might help with the problem. *If* it can be determined which pci device
caused the error, then it might be possible to reset the PCI device and
restart the device driver.
There is an existing infrastructure for "PCI Error Recovery" (known as
EEH on the pSeries) for detecting and clearing PCI bus errors. On the
pSeries, it depends on a combination of custom hardware PCI bridges and
firmware to isolate the failing device; but maybe on other systems, one
might be able to do "almost" as well.
(See kernel source, Documentation/pci-error-recovery.txt)
--linas
^ permalink raw reply
* Re: Maple: killing a process that causes a machine check exception
From: jfaslist @ 2006-05-23 16:30 UTC (permalink / raw)
To: Anton Blanchard; +Cc: linuxppc64-dev
In-Reply-To: <20060523162348.GC5938@krispykreme>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=us-ascii; format=flowed, Size: 961 bytes --]
>>In my case I _need_ the process to be killed, as it is making a VME bus
>>error. / PCI target-abort.
>>I am starting to get desperate. I have been working for several month
>>with IBM to get a solution on machine check related issues on the Maple.
>>First, the Maple was hanging hard. Now that this is fixed, I need the
>>Linux ME to kill the offending process!
>>My feeling now, is that I am really starting to have it w/ the ppc64!
>>
>>
>
>Sounds like you need a Maple specific machine check handler. My point is
>we cant merge a fix like that because it affects every powerpc arch out
>there, all with different machine check handling requirements.
>
>
>
understood. thanks. sorry for letting out a little steam
-jean-francois simon
___________________________________________________________________________
Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire.
http://fr.mail.yahoo.com
^ permalink raw reply
* Re: Maple: killing a process that causes a machine check exception
From: Anton Blanchard @ 2006-05-23 16:23 UTC (permalink / raw)
To: jfaslist; +Cc: linuxppc64-dev
In-Reply-To: <447333BF.6060306@yahoo.fr>
Hi,
> What do you mean by synchronous? Do you mean that the current process
> may no be not the one that caused the ME?
Yeah, a device doing DMA might cause a machine check independent to your
current task. In that case we really need to take the machine down.
> In my case I _need_ the process to be killed, as it is making a VME bus
> error. / PCI target-abort.
> I am starting to get desperate. I have been working for several month
> with IBM to get a solution on machine check related issues on the Maple.
> First, the Maple was hanging hard. Now that this is fixed, I need the
> Linux ME to kill the offending process!
> My feeling now, is that I am really starting to have it w/ the ppc64!
Sounds like you need a Maple specific machine check handler. My point is
we cant merge a fix like that because it affects every powerpc arch out
there, all with different machine check handling requirements.
Anton
^ permalink raw reply
* Re: Maple: killing a process that causes a machine check exception
From: jfaslist @ 2006-05-23 16:09 UTC (permalink / raw)
To: Anton Blanchard; +Cc: linuxppc64-dev
In-Reply-To: <20060523151541.GB10468@krispykreme>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=us-ascii; format=flowed, Size: 1259 bytes --]
Hi,
What do you mean by synchronous? Do you mean that the current process
may no be not the one that caused the ME?
In my case I _need_ the process to be killed, as it is making a VME bus
error. / PCI target-abort.
I am starting to get desperate. I have been working for several month
with IBM to get a solution on machine check related issues on the Maple.
First, the Maple was hanging hard. Now that this is fixed, I need the
Linux ME to kill the offending process!
My feeling now, is that I am really starting to have it w/ the ppc64!
-jfs
Anton Blanchard wrote:
>>By applying the following mods (plse see below), i was able to have a
>>user process that caused a machine check exception to be terminated (on
>>a Maple platform), as expected. I was wondering why the PPC64 had a
>>different ME handling than PPC which does send the SIGBUS to the process?
>>
>>
>
>Not all machine checks are synchronous so we cant always do this. From
>memory the ppc64 version will panic if the machine check wasnt
>synchronous.
>
>Anton
>
>
>
___________________________________________________________________________
Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire.
http://fr.mail.yahoo.com
^ permalink raw reply
* Re: snd-aoa status update / automatic driver loading
From: Sjoerd Simons @ 2006-05-23 15:41 UTC (permalink / raw)
To: Johannes Berg, linuxppc-dev list, debian-powerpc
In-Reply-To: <87wtcirw0y.fsf@briny.internal.ondioline.org>
On Fri, May 19, 2006 at 11:20:29PM +1000, Paul Collins wrote:
> Johannes Berg <johannes@sipsolutions.net> writes:
>
> > On Thu, 2006-05-18 at 10:25 +0300, Eddy Petri??or wrote:
> >
> >> Any chance for 5,2 ? What is needed for it? Codec only?
> >
> > I don't know. If you try loading the modules, the kernel will tell you
> > something about an unhandled layout id. Alternatively, you can find the
> > layout-id file in your /proc/device-tree/ and tell me the number in it.
> > The rest I can figure out.
>
> I have a PowerBook5,4 here and I'd be happy to test support for it.
> The hardware is identified by snd-powermac as "PowerMac Snapper" and
> the layout ID appears to be "3".
I wanted to test on my PowerBook5,2. Uhfortunately i can't find no layout-id
file for the sound device or any other layout-id file for that matter:
$ find /proc/device-tree | grep -i layout
/proc/device-tree/memory@0/ram-layout-architecture
Futhermore one loading the i2sbus module it only gives some information in
dmesg once every two tries ? No errors are shown when there is no output.
Probably not very usefull, but when i get output it shows the following:
i2sbus: mapped i2s control registers
i2sbus: control register contents:
i2sbus: fcr0 = 0x0
i2sbus: cell_control = 0x0
i2sbus: fcr2 = 0xa2caec
i2sbus: fcr3 = 0x0
i2sbus: clock_control = 0x0
i2sbus control destroyed
Sjoerd
--
Life exists for no known purpose.
^ permalink raw reply
* MPC8xx Debugging: function call vs. no function call
From: Josef Angermeier @ 2006-05-23 15:40 UTC (permalink / raw)
To: linuxppc-embedded
Hello,
I am not yet pretty familiar with 8xx system programming, so maybe you
could give me some debugging hint. My C code which programs the the CPM
(USB) has to execute the following commands:
eieio();
usbregs->usb_uscom = 0x80 | 0;
mb();
If i put those instructions in an new function, the CPM behaves as
wished, elsewise it depends on the remaining code. E.g. the number of
NOP machine code instructions before make a difference:
1.)
...< remaining C function code>
__asm__("nop\n\t");
eieio();
usbregs->usb_uscom = 0x80 | 0;
mb();
... <other code>
2.)
...< remaining C function code>
__asm__("nop\n\t");
__asm__("nop\n\t");
eieio();
usbregs->usb_uscom = 0x80 | 0;
mb();
... <other code>
Every hint howto find my mistake is appreciated! Thanks
Josef
^ permalink raw reply
* Re: snd-aoa status update / automatic driver loading
From: Hollis Blanchard @ 2006-05-23 15:25 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev list, debian-powerpc
In-Reply-To: <1148395617.3434.0.camel@diesel>
On Tue, 2006-05-23 at 09:46 -0500, Hollis Blanchard wrote:
>
> Could you also add a sample modules.conf? For example, users should be
> told to remove snd-powermac. Here's what I have ATM, on an FC5 system:
> alias snd-card-0 i2sbus
> remove snd-card-0 { /usr/sbin/alsactl store 0 >/dev/null 2>&1
> || : ; }; /sbin/modprobe -r --ignore-remove snd-powermac
Oops, obviously that last "snd-powermac" shouldn't be there; I just
edited what FC5 had put there and I missed a spot. Maybe this will be
better:
alias snd-card-0 i2sbus
remove i2sbus { /usr/sbin/alsactl store 0 >/dev/null 2>&1 || : ; }; /sbin/modprobe -r --ignore-remove i2sbus
Also, the file is called modprobe.conf... :)
-Hollis
^ permalink raw reply
* Re: Maple: killing a process that causes a machine check exception
From: Anton Blanchard @ 2006-05-23 15:15 UTC (permalink / raw)
To: jfaslist; +Cc: linuxppc64-dev
In-Reply-To: <44732357.4000506@yahoo.fr>
> By applying the following mods (plse see below), i was able to have a
> user process that caused a machine check exception to be terminated (on
> a Maple platform), as expected. I was wondering why the PPC64 had a
> different ME handling than PPC which does send the SIGBUS to the process?
Not all machine checks are synchronous so we cant always do this. From
memory the ppc64 version will panic if the machine check wasnt
synchronous.
Anton
^ permalink raw reply
* Re: UART DRIVER on 2.6.15
From: Vitaly Bordug @ 2006-05-23 15:11 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <3348e5d9925e49e2badcd00d615156b4@pobox.sk>
On Tue, 23 May 2006 14:02:49 +0200
"Ladislav Klenovič" <lk99336@pobox.sk> wrote:
> Hi,
> just a simple question, is uart driver for kernel 2.6.15 complete.
> There are some parts like:
> void scc1_lineif(struct uart_cpm_port *pinfo)
> {
> /* XXX SCC1: insert port configuration here */
> pinfo->brg = 1;
> }
> ....
> that seems to incomplete. Am I able to do something with SCC1 with the current cpm_uart code?
>
> Maybe stupid question, is there any way (is it possible) to import old uart driver from kernel 2.4.x to kernel 2.6.x
>
It is clear, that per-board tune-up is too specific to be kept within drivers/ and now it is accomplished in the board setup code.
Just have a look at arch/ppc/platforms/mps866ads_setup.c The thing you'll have to do is implement the pin tune-up for your board in a function, and set the callback pointer to it - it will be executed at the time UART initializes its resources.
--
Sincerely,
Vitaly
^ permalink raw reply
* Re: [PATCH] powerpc: Auto reserve of device tree blob
From: Jon Loeliger @ 2006-05-23 15:04 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org
In-Reply-To: <1148315146.17549.8.camel@cashmere.sps.mot.com>
On Mon, 2006-05-22 at 11:25, Jon Loeliger wrote:
> While I've not seen
> it applied yet, I am assuming that Jimi's patch from 14 April
> is what is needed here and will be applied.
And that patch appears to be in Paul's tree now!
jdl
^ permalink raw reply
* Maple: killing a process that causes a machine check exception
From: jfaslist @ 2006-05-23 14:59 UTC (permalink / raw)
To: linuxppc64-dev
Hi,
By applying the following mods (plse see below), i was able to have a
user process that caused a machine check exception to be terminated (on
a Maple platform), as expected. I was wondering why the PPC64 had a
different ME handling than PPC which does send the SIGBUS to the process?
Thanks
Regards,
-jean-francois simon
diff -urN -X linux-2.6.16.14/Documentation/dontdiff
linux-2.6.16.14/arch/powerpc/kernel/traps.c
linux-2.6.16.14.vmeberr_fix/arch/powerpc/kernel/traps.c
--- linux-2.6.16.14/arch/powerpc/kernel/traps.c 2006-05-04
17:03:45.000000000 -0700
+++ linux-2.6.16.14.vmeberr_fix/arch/powerpc/kernel/traps.c 2006-05-09
02:46:59.000000000 -0700
@@ -340,12 +340,19 @@
#ifdef CONFIG_PPC64
int recover = 0;
+
/* See if any machine dependent calls */
if (ppc_md.machine_check_exception)
recover = ppc_md.machine_check_exception(regs);
if (recover)
return;
+
+ if (user_mode(regs)) {
+ regs->msr |= MSR_RI;
+ _exception(SIGBUS, regs, BUS_ADRERR, regs->nip);
+ return;
+ }
#else
unsigned long reason = get_mc_reason(regs);
___________________________________________________________________________
Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire.
http://fr.mail.yahoo.com
^ permalink raw reply
* pmppc7448/mv64x60 DMA from PCI to memory
From: Phil Nitschke @ 2006-05-23 14:50 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
I'm working on a project using this processor:
http://www.artesyncp.com/products/PmPPC7448.html
on a custom VME carrier, as shown below. We're wanting to suck
large amounts of data from a PCI device which _cannot_ perform
bus-mastered DMA (it is a PCI Target only).
The Marvell Chip used by the PmPPC7448 is this one:
http://www.marvell.com/products/communication/Discovery%20MV64460%
20FINAL.pdf
I've written a collection of simple routines to program the Marvell IDMA
controller, for example:
mv64x6x_init_dma_channel();
mv64x6x_set_dma_mode();
mv64x6x_set_src_addr();
mv64x6x_set_dst_addr();
mv64x6x_set_dma_count();
mv64x6x_enable_dma();
or rather more simply:
mv64x6x_memcpy_dma(dst_handle, src_handle, size);
This works OK for copying from a memory to memory, where the buffers are
allocated using:
src = dma_alloc_noncoherent(NULL, BUF_SZ, &src_handle, GFP_KERNEL);
The src_handle is passed directly to mv64x6x_set_src_addr();
But when the src address is the FIFO on the PCI bus, I don't know how to
get the IDMA controller to play nicely. The FIFO sits in the middle of
the PCI device's I/O mem range 0x9fe00000 - 0x9fffffff. I've programmed
and enabled a 5th address window in the IDMA controller which
encompasses the 0x200000 bytes of the PCI memory range, and I'm not
seeing any address violation or address miss errors. The PCI->memory
DMA "completes" without any traffic every touching the PCI bus, so
obviously I need to do something else/differently.
For this scenario, can anyone tell me:
* Should I be using the same src address as that reported via
the 'lspci' command - this _is_ the PCI bus address, isn't it?
* Do I have to do anything special to tell the IDMA controller
to source data from the PCI bus and shift it into memory?
* Looking through mv64x60.c in the 2.6.16 kernel, I note that 4
of the 8 possible IDMA address windows are configured (for each
of the 512 MB DRAM on our processor card). Do I need to add
tests to my source and destination regions, to determine if they
cross one of the 512 MB regions, and hence will require a
different CSx line (and thus the DMA will need to be broken into
two transactions), or does kernel already take care to ensure
allocated regions will not cross these boundaries?
TIA for any help that anyone can offer.
--
Phil
+--------------------------------------------------+
| Custom VME64x Carrier Card |
| +-------------------+ +-------------------+ |
| | Artesyn PmPPC7448 | | Altera FPGA | |
| | | | | |
| |+-----------------+| |+-----------------+| |
| ||Marvell MV64460 || || Altera PCI I/F || |
| ||(NOT coherent || ||(non-prefetchable)| |
| || cache) (+IDMA) || || FIFO || |
| |+--------#--------+| |+---------#-------+| |
| +---------#---------+ +----------#--------+ |
| # PCI Bus # |
| ########################################### |
+--------------------------------------------------+
p.s. Since my driver was developed using documentation obtained from
Marvell under a very restrictive NDA, I cannot release it as open source
just yet. Marvell's Vice President and General Counsel is currently
reviewing the matter, and I expect to hear from them in the next couple
weeks.
^ permalink raw reply
* Re: snd-aoa status update / automatic driver loading
From: Hollis Blanchard @ 2006-05-23 14:46 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev list, debian-powerpc
In-Reply-To: <1148387282.25971.8.camel@johannes>
On Tue, 23 May 2006 14:27:52 +0200
Johannes Berg <johannes@sipsolutions.net> wrote:
> --44731b52_16deb9ec_c30
>
> gpg: Signature made Tue 23 May 2006 07:27:49 AM CDT using RSA key ID
> 227A1158 gpg: Can't check signature: public key not found
>
> --44731b52_16deb9ec_c30
>
> On Mon, 2006-05-22 at 22:11 -0500, Hollis Blanchard wrote:
>
> > The "auto-loading" stuff doesn't seem to be working for me on my
> > PowerMac11,2, with a fresh git clone as of right now. What is the
> > base module that should load all the others? After a "make
> > install", I still had to modprobe almost everything by hand
> > (`find ./snd-aoa -name \*.ko` in the source directory to get a
> > list).
>
> Odd. i2sbus should pull in all other required modules, and should
> itself load automatically at boot due to having a modalias that
> matches the of:... modalias the mac-io bus device for the i2s stuff
> has.
Yeah, I'm not sure how I was supposed to know that i2sbus was the magic
module. That seems to be working now. Again, from PowerMac11,2:
i2sbus: mapped i2s control registers
i2sbus: control register contents:
i2sbus: fcr0 = 0x8000056
i2sbus: cell_control = 0x5b43b71a
i2sbus: fcr2 = 0xe7008000
i2sbus: fcr3 = 0x7200d607
i2sbus: clock_control = 0x0
i2sbus: found i2s controller
serial format: 0x41190000
dws: 0x2000200
i2sbus: found i2s controller
serial format: 0x41100000
dws: 0x0
...
snd-aoa-fabric-layout: found bus with layout 68 (using)
snd-aoa-codec-onyx: found pcm3052
snd-aoa-fabric-layout: platform-onyx-codec-ref doesn't match!
snd-aoa: fabric didn't like codec onyx
snd-aoa-codec-onyx: created and attached onyx instance
snd-aoa-codec-onyx: found pcm3052
snd-aoa-fabric-layout: can use this codec
snd-aoa-codec-onyx: attached to onyx codec via i2c
snd-aoa-codec-onyx: created and attached onyx instance
snd-aoa-fabric-layout: found bus with layout 69 (using)
snd-aoa-fabric-layout: platform-onyx-codec-ref doesn't match!
snd-aoa: fabric didn't like codec onyx
> > snd-aoa-codec-tas: found keywest-i2c-bus, checking if tas chip is
> > on it snd-aoa-codec-tas: created and attached tas instance
> > snd-aoa-codec-tas: found keywest-i2c-bus, checking if tas chip is
> > on it snd-aoa-codec-tas: created and attached tas instance
>
> Uh. That one I need to check, there is no tas codec on your machine.
This is probably just because I loaded all the modules I could find.
> > snd: Unknown layout ID 0x44
>
> That looks like you have snd-powermac loaded too. Or not? I don't
> think I have anything that prints "snd:" as the prefix but I might be
> wrong.
Yes, it looks like snd-powermac was loading as well, thanks to
modules.conf. I've removed that now.
> > For the record, there are two "layout-id" properties in my device
> > tree, as discussed in this patch:
> > http://patchwork.ozlabs.org/linuxppc/patch?id=3D4867
>
> Note that the patch is mine :)
I noted that. Since most of the archived mails aren't overly helpful, I
was trying to be complete.
> > Ultimately, snd_aoa_codec_onyx seems to be the happy module. Only
> > the headphone jack was enabled; I had to use GNOME's "Volume
> > Control" panel applet to enable speakers or line out (both of which
> > work).
> >=20
> > However, volume control doesn't work at all, for both line-out and
> > headphone jacks. Should it?
>
> Yes, it should. I think the bug is that the tas module thinks it can
> attach a codec here. Can you try *not* loading that module and see if
> it works better then? I'll try to see if I can make the tas module not
> attach on those machines, but as long as you don't load it manually
> all should be fine.
Volume control does indeed work when the tas module isn't loaded.
> > Also, it would be helpful if the git tree were better publicized
> > somewhere (e.g. http://johannes.sipsolutions.net/). I had to dig
> > through =
> a LOT of mails to find the source.
>
> Sorry. I linked it up on http://johannes.sipsolutions.net/Projects/
> and will add a few more details later.
Could you also add a sample modules.conf? For example, users should be
told to remove snd-powermac. Here's what I have ATM, on an FC5 system:
alias snd-card-0 i2sbus
remove snd-card-0 { /usr/sbin/alsactl store 0 >/dev/null 2>&1
|| : ; }; /sbin/modprobe -r --ignore-remove snd-powermac
Thanks again!
-Hollis
^ permalink raw reply
* Re: Problem mapping GPIO regs on ppc440gx
From: Travis B. Sawyer @ 2006-05-23 13:50 UTC (permalink / raw)
To: Travis B. Sawyer; +Cc: linuxppc-embedded
In-Reply-To: <44730484.4090208@broadcom.com>
Answering my own question here...
Travis B. Sawyer wrote:
>Greetings:
>
>We've been using a 2.4.30 kernel (with numerous patches) on a AMCC 440gx
>custom built board for quite some time now.
>
>We're building some new hardware that forces us to go to a 2.6 kernel.
>So, I've downloaded 2.6.16.16 from kernel.org and am porting everything
>forward from our 2.4.30 kernel.
>
>The problem lies in mapping the GPIO regs of the 440 to user space using
>/dev/mem:
>
> gpio_fd = open("/dev/mem", O_RDWR | O_SYNC);
>
> if (0 > gpio_fd) {
> perror("mbGpioGet(): Unable to open gpio");
> return(-1);
> }
>
> addr = (ppc440_gpio_regs_t *)mmap(0, getpagesize() * 2,
> PROT_READ | PROT_WRITE,
> MAP_SHARED, gpio_fd,
> (off_t)(0x40000000));
>
>
>
The above mmap call worked for 2.4.30, but for 2.6.16 I needed to change
the offset
to be a multiple of page size, so:
(off_t)(0x40000000/getpagesize());
-travis
^ permalink raw reply
* [PATCH, 2.6.17-rc4-git10] ieee80211softmac_io.c: fix warning "defined but not used"
From: Toralf Förster @ 2006-05-23 13:49 UTC (permalink / raw)
To: linville; +Cc: netdev, linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 1451 bytes --]
Got this compiler warning today and Johannes Berg <johannes@sipsolutions.net> wrote:
Yeah, known 'bug', we have that code there but never use it. Feel free
to submit a patch (to John Linville, CC netdev and softmac-dev) to
remove it.
Signed-off-by: Toralf Foerster <toralf.foerster@gmx.de>
--- linux-2.6.17-rc4-git10-pcie-rme9652/net/ieee80211/softmac/ieee80211softmac_io.c.old 2006-05-12 09:44:47.000000000 +0200
+++ linux-2.6.17-rc4-git10-pcie-rme9652/net/ieee80211/softmac/ieee80211softmac_io.c 2006-05-23 15:16:38.000000000 +0200
@@ -456,31 +456,3 @@
return IEEE80211_2ADDR_LEN;
}
-
-/* Sends a control packet */
-static int
-ieee80211softmac_send_ctl_frame(struct ieee80211softmac_device *mac,
- struct ieee80211softmac_network *net, u32 type, u32 arg)
-{
- void *pkt = NULL;
- u32 pkt_size = 0;
-
- switch(type) {
- case IEEE80211_STYPE_RTS:
- case IEEE80211_STYPE_CTS:
- pkt_size = ieee80211softmac_rts_cts((struct ieee80211_hdr_2addr **)(&pkt), mac, net, type);
- break;
- default:
- printkl(KERN_DEBUG PFX "Unsupported Control Frame type: %i\n", type);
- return -EINVAL;
- }
-
- if(pkt_size == 0)
- return -ENOMEM;
-
- /* Send the packet to the ieee80211 layer for tx */
- ieee80211_tx_frame(mac->ieee, (struct ieee80211_hdr *) pkt, pkt_size);
-
- kfree(pkt);
- return 0;
-}
[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Re: Tri-mode or gigebit ethernet support problem in ML403
From: Grant Likely @ 2006-05-23 13:32 UTC (permalink / raw)
To: Ming Liu; +Cc: linuxppc-embedded
In-Reply-To: <BAY110-F36C1C973DE890A4541FF9EB29B0@phx.gbl>
On 5/23/06, Ming Liu <eemingliu@hotmail.com> wrote:
> Dear Grant,
Hey Ming, I just saw your repy to Rick from Xilinx. His advice is
better than mine. Listen to him. :)
> First, thanks for your help on my problem.
>
> So you mean, because there is no specific driver for TEMAC included in al=
l
> versions of linux, I must port the driver from the BSP generated by EDK
> into the linux kernel by myself, right? I am sorry that I am a novice in
> linux field and I cannot understand you very well. Could you please give =
me
> more guidance on what shall I do to port the driver, in detail? Do you ha=
ve
> some reference documents for me to do this?
You need some background on writing Linux device drivers:
http://lwn.net/Kernel/LDD3/
Cheers,
g.
--=20
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ 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