* [PATCH] [POWERPC] 85xx: Cleanup TLB initialization
From: Kumar Gala @ 2008-03-26 16:07 UTC (permalink / raw)
To: linuxppc-dev
* Determine the RPN we are running the kernel at runtime rather
than using compile time constant for initial TLB
* Cleanup adjust_total_lowmem() to respect memstart_addr and
be a bit more clear on variables that are sizes vs addresses.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
arch/powerpc/kernel/head_fsl_booke.S | 34 ++++++++++++++++++++++++------
arch/powerpc/mm/fsl_booke_mmu.c | 37 ++++++++++++++-------------------
2 files changed, 43 insertions(+), 28 deletions(-)
diff --git a/arch/powerpc/kernel/head_fsl_booke.S b/arch/powerpc/kernel/head_fsl_booke.S
index d9cc2c2..3b69b54 100644
--- a/arch/powerpc/kernel/head_fsl_booke.S
+++ b/arch/powerpc/kernel/head_fsl_booke.S
@@ -68,7 +68,9 @@ _ENTRY(_start);
mr r29,r5
mr r28,r6
mr r27,r7
+ li r25,0 /* phys kernel start (low) */
li r24,0 /* CPU number */
+ li r23,0 /* phys kernel start (high) */
/* We try to not make any assumptions about how the boot loader
* setup or used the TLBs. We invalidate all mappings from the
@@ -167,7 +169,28 @@ skpinv: addi r6,r6,1 /* Increment */
mtspr SPRN_MAS0,r7
tlbre
- /* Just modify the entry ID, EPN and RPN for the temp mapping */
+ /* grab and fixup the RPN */
+ mfspr r6,SPRN_MAS1 /* extract MAS1[SIZE] */
+ rlwinm r6,r6,25,27,30
+ li r8,-1
+ addi r6,r6,10
+ slw r6,r8,r6 /* convert to mask */
+
+ bl 1f /* Find our address */
+1: mflr r7
+
+ mfspr r8,SPRN_MAS3
+#ifdef CONFIG_PHYS_64BIT
+ mfspr r23,SPRN_MAS7
+#endif
+ and r8,r6,r8
+ subfic r9,r6,-4096
+ and r9,r9,r7
+
+ or r25,r8,r9
+ ori r8,r25,(MAS3_SX|MAS3_SW|MAS3_SR)
+
+ /* Just modify the entry ID and EPN for the temp mapping */
lis r7,0x1000 /* Set MAS0(TLBSEL) = 1 */
rlwimi r7,r5,16,4,15 /* Setup MAS0 = TLBSEL | ESEL(r5) */
mtspr SPRN_MAS0,r7
@@ -177,12 +200,10 @@ skpinv: addi r6,r6,1 /* Increment */
ori r6,r6,(MAS1_TSIZE(BOOKE_PAGESZ_4K))@l
mtspr SPRN_MAS1,r6
mfspr r6,SPRN_MAS2
- lis r7,PHYSICAL_START@h
+ li r7,0 /* temp EPN = 0 */
rlwimi r7,r6,0,20,31
mtspr SPRN_MAS2,r7
- mfspr r6,SPRN_MAS3
- rlwimi r7,r6,0,20,31
- mtspr SPRN_MAS3,r7
+ mtspr SPRN_MAS3,r8
tlbwe
xori r6,r4,1
@@ -232,8 +253,7 @@ skpinv: addi r6,r6,1 /* Increment */
ori r6,r6,PAGE_OFFSET@l
rlwimi r6,r7,0,20,31
mtspr SPRN_MAS2,r6
- li r7,(MAS3_SX|MAS3_SW|MAS3_SR)
- mtspr SPRN_MAS3,r7
+ mtspr SPRN_MAS3,r8
tlbwe
/* 7. Jump to KERNELBASE mapping */
diff --git a/arch/powerpc/mm/fsl_booke_mmu.c b/arch/powerpc/mm/fsl_booke_mmu.c
index 3dd0c81..59f6649 100644
--- a/arch/powerpc/mm/fsl_booke_mmu.c
+++ b/arch/powerpc/mm/fsl_booke_mmu.c
@@ -49,7 +49,6 @@
#include <asm/mmu.h>
#include <asm/uaccess.h>
#include <asm/smp.h>
-#include <asm/bootx.h>
#include <asm/machdep.h>
#include <asm/setup.h>
@@ -59,7 +58,6 @@ extern void loadcam_entry(unsigned int index);
unsigned int tlbcam_index;
unsigned int num_tlbcam_entries;
static unsigned long __cam0, __cam1, __cam2;
-#define MAX_LOW_MEM CONFIG_LOWMEM_SIZE
#define NUM_TLBCAMS (16)
@@ -195,35 +193,32 @@ unsigned long __init mmu_mapin_ram(void)
void __init
adjust_total_lowmem(void)
{
- unsigned long max_low_mem = MAX_LOW_MEM;
- unsigned long cam_max = 0x10000000;
- unsigned long ram;
+ phys_addr_t max_lowmem_size = __max_low_memory;
+ phys_addr_t cam_max_size = 0x10000000;
+ phys_addr_t ram;
- /* adjust CAM size to max_low_mem */
- if (max_low_mem < cam_max)
- cam_max = max_low_mem;
+ /* adjust CAM size to max_lowmem_size */
+ if (max_lowmem_size < cam_max_size)
+ cam_max_size = max_lowmem_size;
- /* adjust lowmem size to max_low_mem */
- if (max_low_mem < total_lowmem)
- ram = max_low_mem;
- else
- ram = total_lowmem;
+ /* adjust lowmem size to max_lowmem_size */
+ ram = min(max_lowmem_size, total_lowmem);
/* Calculate CAM values */
__cam0 = 1UL << 2 * (__ilog2(ram) / 2);
- if (__cam0 > cam_max)
- __cam0 = cam_max;
+ if (__cam0 > cam_max_size)
+ __cam0 = cam_max_size;
ram -= __cam0;
if (ram) {
__cam1 = 1UL << 2 * (__ilog2(ram) / 2);
- if (__cam1 > cam_max)
- __cam1 = cam_max;
+ if (__cam1 > cam_max_size)
+ __cam1 = cam_max_size;
ram -= __cam1;
}
if (ram) {
__cam2 = 1UL << 2 * (__ilog2(ram) / 2);
- if (__cam2 > cam_max)
- __cam2 = cam_max;
+ if (__cam2 > cam_max_size)
+ __cam2 = cam_max_size;
ram -= __cam2;
}
@@ -231,6 +226,6 @@ adjust_total_lowmem(void)
" CAM2=%ldMb residual: %ldMb\n",
__cam0 >> 20, __cam1 >> 20, __cam2 >> 20,
(total_lowmem - __cam0 - __cam1 - __cam2) >> 20);
- __max_low_memory = max_low_mem = __cam0 + __cam1 + __cam2;
- __initial_memory_limit = __max_low_memory;
+ __max_low_memory = __cam0 + __cam1 + __cam2;
+ __initial_memory_limit = memstart_addr + __max_low_memory;
}
--
1.5.4.1
^ permalink raw reply related
* Help on MPC82XX USB Host controller Development using m82xx-hcd.
From: Amarendra_Reddy @ 2008-03-26 16:11 UTC (permalink / raw)
To: linuxppc-embedded
Hi all,
We are working on implementation of the USB host controller driver for the
MPC8272ADS (eval board).
The USB Host controller on MPC8272 chip is neither UHCI nor OHCI compliant.
We downloaded the project cpm2usb and the patches created by Mr.Mike
Rapoport from http://cpm2usb.sourceforge.net
We integrated the 'm82xx-hcd' into the 2.6.10 source with few changes to usb
data structures (usb_hcd,usb_device,usb_host_endpoint) and to struct
hc_driver. Also updated the function ''tx_err' present in m82xx-hcd.c.
The output from console:
---------------------------------------------------------------------------
NET: Registered protocol family 16
mpc8272ads: Init
PCI: Probing PCI hardware
PCI: Cannot allocate resource region 0 of device 0000:00:00.0
PCI: Cannot allocate resource region 1 of device 0000:00:00.0
usbcore: registered new driver usbfs
usbcore: registered new driver hub
Serial: CPM driver $Revision: 0.01 $
ttyCPM0 at MMIO 0xf0011a00 (irq = 40) is a CPM UART
ttyCPM1 at MMIO 0xf0011a60 (irq = 43) is a CPM UART
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered
loop: loaded (max 8 devices)
fs_enet.c:v1.0 (Aug 8, 2005)
fs_enet: eth0 Phy @ 0x0, type DM9161 (0x0181b881)
fs_enet: eth1 Phy @ 0x3, type DM9161 (0x0181b881)
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
USB Universal Host Controller Interface driver v2.2
sl811: driver sl811-hcd, 06 Dec 2004
=> driver mpc82xx-hcd, 2005
mpc82xx-hcd mpc82xx-hcd3: PQ2 intergrated USB controller v0.1
mpc82xx-hcd mpc82xx-hcd3: new USB bus registered, assigned bus number 1
Oops: kernel access of bad area, sig: 11 [#1]
PREEMPT
--------------------------------------------------------------------------
I have a little knowledge of USB support by Linux.
If anyone has any clues or faced such a problem,
it would be of great help if you could reply or give any suggestion.
Thanks in advance
Amarendra Reddy
--
View this message in context: http://www.nabble.com/Help-on-MPC82XX-USB-Host-controller-Development-using-m82xx-hcd.-tp16304553p16304553.html
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCHv2 2/3] ep8248e: Reference SMC parameter RAM base in the device tree.
From: Scott Wood @ 2008-03-26 15:57 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: linuxppc-dev
In-Reply-To: <200803261220.43039.laurentp@cse-semaphore.com>
On Wed, Mar 26, 2008 at 12:20:42PM +0100, Laurent Pinchart wrote:
> diff --git a/arch/powerpc/boot/dts/ep8248e.dts b/arch/powerpc/boot/dts/ep8248e.dts
> index 5d2fb76..756758f 100644
> --- a/arch/powerpc/boot/dts/ep8248e.dts
> +++ b/arch/powerpc/boot/dts/ep8248e.dts
> @@ -121,8 +121,7 @@
>
> data@0 {
> compatible = "fsl,cpm-muram-data";
> - reg = <0 0x1100 0x1140
> - 0xec0 0x9800 0x800>;
> + reg = <0 0x2000 0x9800 0x800>;
> };
Can we leave this as reserved, so that udbg still works?
-Scott
^ permalink raw reply
* Re: OF compatible MTD platform RAM driver ?
From: Sergei Shtylyov @ 2008-03-26 15:40 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: ben, David Gibson, linux-mtd, linuxppc-dev
In-Reply-To: <b06db7bb4932d14f8af9547abdfc9d0d@kernel.crashing.org>
Segher Boessenkool wrote:
>> - Using another device node with a compatible value set to
>> "linear-ram" (or
>> something similar). This would support both volatile and non-volatile
>> devices, and a property could be added to specify if the device is
>> volatile
>> or not.
> "memory-mapped-memory" perhaps :-)
> Or, just "memory". Although that one might play havoc with some
I'd suggest "ram" and "rom" then. Luckily the device trees don't contain
binding for the real RAM chips yet. :-)
> not-quite-correct main memory probing code.
You mean the there's parsers that search the "compatible" prop for
"memory" as well as "device_type" prop?
> Segher
WBR, Sergei
^ permalink raw reply
* Re: [PATCH 1/2] [MTD] Add support for RAM & ROM mappings in the physmap_of MTD driver.
From: Segher Boessenkool @ 2008-03-26 15:34 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: ben, linuxppc-dev, linux-mtd, David Gibson
In-Reply-To: <47EA6B11.7050804@ru.mvista.com>
>>> {
>>> + .compatible = "physmap-ram",
>>> + .data = (void *)"map_ram",
>>> + },
>>> + {
>>> + .compatible = "physmap-rom",
>>> + .data = (void *)"map_rom",
>>> + },
>
>> Why the cast? It's redundant afaics.
>
> To be in line with the surrounding code...
I see _that_, but it's not a great argument IMNSHO. Could I trick
you into preceding this patch with a cleanup patch for the existing
casts?
Segher
^ permalink raw reply
* Re: DTS question
From: Segher Boessenkool @ 2008-03-26 15:32 UTC (permalink / raw)
To: David Gibson; +Cc: Scott Wood, linuxppc-dev, Sean MacLennan
In-Reply-To: <20080325221209.GB8281@localhost.localdomain>
>>> Well.. stock ticker is the new convention. IEEE1275 used IEEE
>>> assigned OUI strings (Organization Unique Identifiers). Often those
>>> are the same as the stock ticker, but not always.
>>
>> Erm, an OUI is a 24-bit number. I think you're confusing something
>> here.
>
> Yes, I think I am. I somehow had the impression that in addition to
> the 24-bit OUIs used in MAC addresses, there were also string-form
> OUIs assigned.
Perhaps, I'm not an expert on this organisational stuff (wow, big
understatement). OF uses only the six-hex-digit form though (with
a prepended 0, to make it unique).
>> Note that a stock symbol needs to be written in uppercase; in
>> lowercase,
>> it is just a random name that has no collision protection.
>
> Um.. bit too late for that. AFAIK, uppercase has been used by
> *no-one* for stock ticker derived vendor IDs.
No, it's used quite a lot actually. Not in DTS files though ;-)
It doesn't matter a lot, lowercase names are perfectly valid, you just
don't get the nice non-collision reassurance you would get if you used
a name in one of the namespaces reserved for that purpose.
It's probably best to not use an uppercase stock symbol if you don't
have approval from the company in question anyway -- we use a
lowercase name (i.e. in the "free-for-all" space) for our messed up
bindings, the companies use an uppercase name (in the stock-ticker
namespace) for their own, incompatible, messed-up bindings, and
everyone is happy. Or something like that.
Segher
^ permalink raw reply
* Re: [PATCH 1/2] [MTD] Add support for RAM & ROM mappings in the physmap_of MTD driver.
From: Sergei Shtylyov @ 2008-03-26 15:26 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: ben, David Gibson, linux-mtd, linuxppc-dev
In-Reply-To: <346860fa1e8a75a4a89e260011690659@kernel.crashing.org>
Segher Boessenkool wrote:
>> {
>> + .compatible = "physmap-ram",
>> + .data = (void *)"map_ram",
>> + },
>> + {
>> + .compatible = "physmap-rom",
>> + .data = (void *)"map_rom",
>> + },
> Why the cast? It's redundant afaics.
To be in line with the surrounding code...
> Segher
WBR, Sergei
^ permalink raw reply
* Re: OF compatible MTD platform RAM driver ?
From: Segher Boessenkool @ 2008-03-26 15:09 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: ben, David Gibson, linux-mtd, linuxppc-dev
In-Reply-To: <200803251744.46001.laurentp@cse-semaphore.com>
> The nvram device descrived in the Device Support Extensions is
> probably meant
> to describe the kind of nvram found in RTC chips.
It describes a generic interface _within OF_ for _all kinds_ of NVRAM,
both physical and virtual.
Segher
^ permalink raw reply
* Re: OF compatible MTD platform RAM driver ?
From: Segher Boessenkool @ 2008-03-26 15:06 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: ben, linuxppc-dev, linux-mtd, David Gibson
In-Reply-To: <200803251914.24021.laurentp@cse-semaphore.com>
> So we're left with two main options.
>
> - Reusing the nvram device type from the Device Support Extensions.
This wouldn't bring you anything. A device_type is only used internally
by OF, to decide what device nodes support which OF programming model.
If you only have a flat device tree, "device_type" should be used only
as a workaround for older kernels that require it.
> - Using another device node with a compatible value set to
> "linear-ram" (or
> something similar). This would support both volatile and non-volatile
> devices, and a property could be added to specify if the device is
> volatile
> or not.
"memory-mapped-memory" perhaps :-)
Or, just "memory". Although that one might play havoc with some
not-quite-correct main memory probing code.
Segher
^ permalink raw reply
* Re: [PATCH 2/2] pasemi_mac: Netpoll support
From: Olof Johansson @ 2008-03-26 15:08 UTC (permalink / raw)
To: Valentine Barshak; +Cc: linuxppc-dev, pasemi-linux, jgarzik, netdev
In-Reply-To: <47EA445D.9090509@ru.mvista.com>
On Wed, Mar 26, 2008 at 03:41:01PM +0300, Valentine Barshak wrote:
>> + pasemi_mac_tx_intr(mac->tx->chan.irq, mac->tx);
>> + enable_irq(mac->tx->chan.irq);
>> +
>> + disable_irq(mac->rx->chan.irq);
>> + pasemi_mac_rx_intr(mac->rx->chan.irq, dev);
>
> Shouldn't this actually be pasemi_mac_rx_intr(mac->rx->chan.irq, mac->rx)?
Yeah, it should. It used to take the netdev pointer instead. And the
void * argument means I never got a compiler warning from it.
Thanks!
-Olof
^ permalink raw reply
* Re: [PATCH 2/2] [POWERPC] Describe memory-mapped RAM&ROM chips of bindings
From: Segher Boessenkool @ 2008-03-26 14:52 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: ben, linuxppc-dev, linux-mtd, David Gibson
In-Reply-To: <200803261344.26555.laurentp@cse-semaphore.com>
> + Dedicated RAM and ROM chips are often used as storage for
> temporary or
> + permanent data in embedded devices. Possible usage include
> non-volatile
> + storage in battery-backed SRAM, semi-permanent storage in
> dedicated SRAM
> + to preserve data accross reboots and firmware storage in
> dedicated ROM.
> +
> + - compatible : should contain the specific model of RAM/ROM
> chip(s)
> + used, if known, followed by either "physmap-ram" or
> "physmap-rom"
> + - reg : Address range of the RAM/ROM chip
> + - bank-width : Width (in bytes) of the RAM/ROM bank. Equal to the
> + device width times the number of interleaved chips.
> + - device-width : (optional) Width of a single RAM/ROM chip. If
> + omitted, assumed to be equal to 'bank-width'.
Maybe I'm rehashing some old discussion here, if so, sorry; but why
do you have bank-width and device-width here? What useful information
does it provide? If this is about saying what the preferred (or only
possible) access width is, better names are in order.
Segher
^ permalink raw reply
* Re: [PATCH 1/2] [MTD] Add support for RAM & ROM mappings in the physmap_of MTD driver.
From: Segher Boessenkool @ 2008-03-26 14:45 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: ben, linuxppc-dev, linux-mtd, David Gibson
In-Reply-To: <200803261344.03438.laurentp@cse-semaphore.com>
> {
> + .compatible = "physmap-ram",
> + .data = (void *)"map_ram",
> + },
> + {
> + .compatible = "physmap-rom",
> + .data = (void *)"map_rom",
> + },
Why the cast? It's redundant afaics.
Segher
^ permalink raw reply
* Re: [RESEND] [PATCH 1/2 v2] [OF] Add of_device_is_available function
From: Segher Boessenkool @ 2008-03-26 14:25 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, Sean MacLennan
In-Reply-To: <20080325065158.6c299e05@zod.rchland.ibm.com>
> We really want just "okay" and "ok". Look for a version 3 of the patch
> that fixes it later today.
You might want to put in a comment that says "ok" is only a
workaround for some broken systems, too.
Segher
^ permalink raw reply
* [PATCH v3][OF] Add of_device_is_available function
From: Josh Boyer @ 2008-03-26 13:33 UTC (permalink / raw)
To: paulus, linuxppc-dev
IEEE 1275 defined a standard "status" property to indicate the operational
status of a device. The property has four possible values: okay, disabled,
fail, fail-xxx. The absence of this property means the operational status
of the device is unknown or okay.
This adds a function called of_device_is_available that checks the state
of the status property of a device. If the property is absent or set to
either "okay" or "ok", it returns 1. Otherwise it returns 0.
Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
---
drivers/of/base.c | 26 ++++++++++++++++++++++++++
include/linux/of.h | 1 +
2 files changed, 27 insertions(+)
--- linux-2.6.orig/drivers/of/base.c
+++ linux-2.6/drivers/of/base.c
@@ -117,6 +117,32 @@ int of_device_is_compatible(const struct
EXPORT_SYMBOL(of_device_is_compatible);
/**
+ * of_device_is_available - check if a device is available for use
+ *
+ * @device: Node to check for availability
+ *
+ * Returns 1 if the status property is absent or set to "okay" or "ok",
+ * 0 otherwise
+ */
+int of_device_is_available(const struct device_node *device)
+{
+ const char *status;
+ int statlen;
+
+ status = of_get_property(device, "status", &statlen);
+ if (status == NULL)
+ return 1;
+
+ if (statlen > 0) {
+ if (!strcmp(status, "okay") || !strcmp(status, "ok"))
+ return 1;
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL(of_device_is_available);
+
+/**
* of_get_parent - Get a node's parent if any
* @node: Node to get parent
*
--- linux-2.6.orig/include/linux/of.h
+++ linux-2.6/include/linux/of.h
@@ -62,6 +62,7 @@ extern struct property *of_find_property
int *lenp);
extern int of_device_is_compatible(const struct device_node *device,
const char *);
+extern int of_device_is_available(const struct device_node *device);
extern const void *of_get_property(const struct device_node *node,
const char *name,
int *lenp);
^ permalink raw reply
* Re: dtc: Trivial formatting fixes
From: Jon Loeliger @ 2008-03-26 13:15 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20080326052103.GB2090@localhost.localdomain>
> This patch fixes some trivial indentation and brace/bracket style
> problems.
> @@ -179,9 +179,8 @@
> arg = argv[optind];
>
> /* minsize and padsize are mutually exclusive */
> - if ((minsize) && (padsize)) {
> + if (minsize && padsize)
> die("Can't set both -p and -S\n");
> - }
I do not consider extra braces a "problem", and will
not be applying those changes. The other indentation
fixes will be applied, of course.
jdl
^ permalink raw reply
* ppc platform for AMCC-440EPx - ELDK to the rescue
From: Steve Heflin @ 2008-03-26 13:08 UTC (permalink / raw)
To: linuxppc-embedded
I finally resolved my nightmare of getting linux-2.6.24/5... to work
on my AMCC-440Epx - Sequoia spinoff board. Following a clue I derived
from a reply from Wolfgang Denx, I went to the DENX Engineering site
where I discoved and downloaded the ELDK for the ppc_4xxFP. the ELDK
uses the ppc platform instead of the powerpc platform. FINALLY the
early debugging console output worked, which doesn't work at all
using the powerpc platform (and yes, I had the correct port address
configured). After that, I was able to see that it was the
"setup_hose" function called from /arch/ppc/platforms/4xx/sequoia.c
that caused my board to hang. This Sequoia spinoff board has the PCI
Host Bridge disabled which I didn't realize until that point.
Looking back at the powerpc platform, I don't see how to disable the
Host Bridge initialization without disabling the entire PCI
bus. This board does have 2 devices hooked on the PCI bus, just no
need for a Host Bridge.
Also, I fail to see what the DTS virtualization layer of the hardware
buys us. When debugging, it's so much harder to use than the ppc
platform's straight forward and standard methodologies. I can't
understand to goal to eliminate the ppc platform, especially given
the fact that DENX's ELDK is still using it with Linux 2.6.24.2 !!
Best Regards to all,
Special Thanks to Wolfgang Denx,
Steve Heflin
^ permalink raw reply
* RE: [PATCH 0/2] Add support for RAM & ROM mappings to the physmap_of driver
From: Rune Torgersen @ 2008-03-26 13:04 UTC (permalink / raw)
To: Laurent Pinchart, linux-mtd; +Cc: ben, linuxppc-dev, David Gibson
In-Reply-To: <200803261341.31238.laurentp@cse-semaphore.com>
Laurent Pinchart wrote:
> Hi everybody,
>=20
> these two patches add support for memory-mapped RAM & ROM chips to the
> physmap_of MTD driver.
Whole series
acked-by: Rune Torgersen <runet@innovsys.com>
^ permalink raw reply
* Re: Patch: FW:Xilinx: BSP: Updated ML405 to match hardware used for testing
From: Grant Likely @ 2008-03-26 13:01 UTC (permalink / raw)
To: Guillaume Dargaud; +Cc: linuxppc-dev
In-Reply-To: <052801c88f37$3b51f7e0$ad289e86@LPSC0173W>
On Wed, Mar 26, 2008 at 5:47 AM, Guillaume Dargaud
<dargaud@lpsc.in2p3.fr> wrote:
> Hello all,
>
> I'm trying to get things up and running on a Xilinx Virtex-4 ml405 board,
> and as such I've been trying to figure out the following recent message to
> the list:
> http://patchwork.ozlabs.org/linuxppc/patch?person=1226&id=17037
>
> I don't understand what this patch applies to: it references files such as
> ml405_defconfig which are not part of the normal kernel tree and which I
> cannot find anywhere. Is there some other kind of patch that needs to apply
> first in order to get for instance CONFIG_XILINX_DRIVERS,
> CONFIG_XILINX_EMAC, etc...
>
> Thanks
It applies to Xilinx's git tree of the Linux kernel.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: OF compatible MTD platform RAM driver ?
From: Sergei Shtylyov @ 2008-03-26 12:53 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: ben, linuxppc-dev, linux-mtd, David Gibson
In-Reply-To: <200803251914.24021.laurentp@cse-semaphore.com>
Laurent Pinchart wrote:
>>>Regarding non-volatility nothing prevents a user from using a
>>>volatile RAM as an MTD device, but there's little point in doing so.
>>>Would it be acceptable for the "linear-nvram" specification
>>>not to include > volatile RAM ? ROM chips would be excluded too. Is
>>that an issue ?
>>We actually use a volatile ram (SRAM) as an MTD device. We use it to
>>store info from bootloader and system specific values between resets.
> So we're left with two main options.
> - Reusing the nvram device type from the Device Support Extensions. Volatile
> devices wouldn't be supported, and we'd need a separate device specification
> for linear-mapped volatile RAMs. I'm not very happy with that.
> - Using another device node with a compatible value set to "linear-ram" (or
> something similar). This would support both volatile and non-volatile
> devices, and a property could be added to specify if the device is volatile
> or not.
> I'd go for the second option, and I'd specify a "linear-rom" compatible value
> as well while we're at it.
> Both volatile and non-volatile RAMs can be handled by the physmap_of MTD
> driver. They both use the same map probe type ("map_ram"). Volatility isn't
> handled there.
> ROMs should be handled by the same driver and should use the "mtd_rom" map
> probe type.
OK, let's go with it.
> As all those devices use the physmap_of MTD driver, what about
> using "physmap-ram" and "physmap-rom" as compatibility names ?
Heh, we've gone thru "physmap" before -- it was labelled Linux-specific
name (well, I'd agree with that).
> Best regards,
WBR, Sergei
^ permalink raw reply
* [PATCH 2/2] [POWERPC] Describe memory-mapped RAM&ROM chips of bindings
From: Laurent Pinchart @ 2008-03-26 12:44 UTC (permalink / raw)
To: linux-mtd; +Cc: ben, linuxppc-dev, David Gibson
Signed-off-by: Laurent Pinchart <laurentp@cse-semaphore.com>
=2D--
Documentation/powerpc/booting-without-of.txt | 31 ++++++++++++++++++++++=
+++-
1 files changed, 30 insertions(+), 1 deletions(-)
diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/p=
owerpc/booting-without-of.txt
index 7b4e8a7..53d1cf8 100644
=2D-- a/Documentation/powerpc/booting-without-of.txt
+++ b/Documentation/powerpc/booting-without-of.txt
@@ -57,7 +57,8 @@ Table of Contents
n) 4xx/Axon EMAC ethernet nodes
o) Xilinx IP cores
p) Freescale Synchronous Serial Interface
=2D q) USB EHCI controllers
+ q) USB EHCI controllers
+ r) Memory-mapped RAM & ROM
=20
VII - Specifying interrupt information for devices
1) interrupts property
@@ -2816,6 +2817,34 @@ platforms are moved over to use the flattened-device=
=2Dtree model.
big-endian;
};
=20
+ r) Memory-mapped RAM & ROM
+
+ Dedicated RAM and ROM chips are often used as storage for temporary or
+ permanent data in embedded devices. Possible usage include non-volatile
+ storage in battery-backed SRAM, semi-permanent storage in dedicated SR=
AM
+ to preserve data accross reboots and firmware storage in dedicated ROM.
+
+ - compatible : should contain the specific model of RAM/ROM chip(s)
+ used, if known, followed by either "physmap-ram" or "physmap-rom"
+ - reg : Address range of the RAM/ROM chip
+ - bank-width : Width (in bytes) of the RAM/ROM bank. Equal to the
+ device width times the number of interleaved chips.
+ - device-width : (optional) Width of a single RAM/ROM chip. If
+ omitted, assumed to be equal to 'bank-width'.
+
+ Similarly to memory-mapped NOR flash, memory-mapped RAM & ROM chips
+ can be partionned. See the "j) CFI and JEDEC memory-mapped NOR flash"
+ section for information about how to represent partitions in the
+ device tree.
+
+ Example:
+
+ mmram@f2000000 {
+ compatible =3D "renesas,m5m5w816", "physmap-ram";
+ reg =3D <f2000000 00100000>;
+ bank-width =3D <2>;
+ };
+
=20
More devices will be defined as this spec matures.
=20
=2D-=20
1.5.0
=2D-=20
Laurent Pinchart
CSE Semaphore Belgium
Chauss=E9e de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
=46 +32 (2) 387 42 75
^ permalink raw reply
* Re: Patch: FW:Xilinx: BSP: Updated ML405 to match hardware used for testing
From: Guillaume Dargaud @ 2008-03-26 11:47 UTC (permalink / raw)
To: linuxppc-dev
Hello all,
I'm trying to get things up and running on a Xilinx Virtex-4 ml405 board,
and as such I've been trying to figure out the following recent message to
the list:
http://patchwork.ozlabs.org/linuxppc/patch?person=1226&id=17037
I don't understand what this patch applies to: it references files such as
ml405_defconfig which are not part of the normal kernel tree and which I
cannot find anywhere. Is there some other kind of patch that needs to apply
first in order to get for instance CONFIG_XILINX_DRIVERS,
CONFIG_XILINX_EMAC, etc...
Thanks
--
Guillaume Dargaud
http://www.gdargaud.net/
^ permalink raw reply
* [PATCH 1/2] [MTD] Add support for RAM & ROM mappings in the physmap_of MTD driver.
From: Laurent Pinchart @ 2008-03-26 12:44 UTC (permalink / raw)
To: linux-mtd; +Cc: ben, linuxppc-dev, David Gibson
Signed-off-by: Laurent Pinchart <laurentp@cse-semaphore.com>
=2D--
drivers/mtd/maps/physmap_of.c | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/drivers/mtd/maps/physmap_of.c b/drivers/mtd/maps/physmap_of.c
index 49acd41..65c30b5 100644
=2D-- a/drivers/mtd/maps/physmap_of.c
+++ b/drivers/mtd/maps/physmap_of.c
@@ -273,6 +273,14 @@ static struct of_device_id of_flash_match[] =3D {
.data =3D (void *)"jedec_probe",
},
{
+ .compatible =3D "physmap-ram",
+ .data =3D (void *)"map_ram",
+ },
+ {
+ .compatible =3D "physmap-rom",
+ .data =3D (void *)"map_rom",
+ },
+ {
.type =3D "rom",
.compatible =3D "direct-mapped"
},
=2D-=20
1.5.0
=2D-=20
Laurent Pinchart
CSE Semaphore Belgium
Chauss=E9e de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
=46 +32 (2) 387 42 75
^ permalink raw reply
* RE: [PATCH] ucc_geth: Add 8 bytes to max TX frame for VLANs
From: Li Yang @ 2008-03-26 12:43 UTC (permalink / raw)
To: joakim.tjernlund; +Cc: Netdev, Linuxppc-Embedded@Ozlabs.Org
In-Reply-To: <1206436671.7589.208.camel@gentoo-jocke.transmode.se>
> -----Original Message-----
> From: Joakim Tjernlund [mailto:joakim.tjernlund@transmode.se]=20
> Sent: Tuesday, March 25, 2008 5:18 PM
> To: Li Yang
> Cc: Netdev; Linuxppc-Embedded@Ozlabs.Org
> Subject: Re: [PATCH] ucc_geth: Add 8 bytes to max TX frame for VLANs
>=20
>=20
> On Sat, 2008-03-22 at 12:51 +0100, Joakim Tjernlund wrote:
> > >> -----Original Message-----
> > >> From: netdev-owner@vger.kernel.org
> > >> [mailto:netdev-owner@vger.kernel.org] On Behalf Of=20
> Joakim Tjernlund
> > > Sent: Tuesday, March 18, 2008 11:11 PM
> > >> To: Netdev; Li Yang
> > >> Cc: Joakim Tjernlund
> > >>Subject: [PATCH] ucc_geth: Add 8 bytes to max TX frame for VLANs
> > >>
> > >> Creating a VLAN interface on top of ucc_geth adds 4 bytes to the=20
> > >> frame and the HW controller is not prepared to TX a frame bigger=20
> > >> than 1518 bytes which is 4 bytes too small for a full=20
> VLAN frame.=20
> > >> Also add 4 extra bytes for future expansion.
> > >=20
> > > IMO, VLAN and Jumbo packet support is not general case of=20
> Ethernet.
> > > Could you make this change optional? Thanks.
> > >=20
> > > - Leo
> >=20
> > hmm, I do not agree. VLAN is common today.
> >=20
> > If you were to enable HW support for VLAN then the ethernet=20
> controller=20
> > would inject an extra 4 bytes into the frame.
> > This change does not change the visible MTU for the user.=20
> As is now,=20
> > soft VLAN is silently broken. Do you really want the user=20
> to find and=20
> > turn on a controller specific feature to use VLAN?
> >=20
> > What does netdev people think?=20
> >=20
> > Jocke
>=20
> hmm, I misread the HW specs. The change has nothing to do=20
> with TX, it is the MAX RX frame size that was too small for=20
> VLAN and that is what the patch addresses. I see that tg3.c=20
> adds 4 bytes to MAX RX pkgs:
> /* MTU + ethernet header + FCS + optional VLAN tag */
> tw32(MAC_RX_MTU_SIZE, tp->dev->mtu + ETH_HLEN + 8); So=20
> I don't think this change should be hidden behind a new=20
> CONFIG option. Updated patch below with changed description.
Hi Jocke,
QUICC engine supports dynamic maximum frame length. If you are not
expecting to receive only tagged frames, I recommend to use this feature
by setting dynamicMaxFrameLength and dynamicMinFrameLength in ug_info
instead of increasing the MaxLength for both tagged and untagged frames.
See the following part from the reference manual.
The MFLR entry in the Global Parameter RAM defines the length of the
largest frame, excluding Q TAG
but including FCS, that is still valid. When REMODER[DXE]=3D1, a tagged
frame that has length equals
MaxLength+4 considered valid, and a non tagged frame that has length
equals MaxLength is the longest
that is still considered valid. When REMODER[DXE]=3D0, any frame longer
than MaxLength consider
erroneous frame.
For systems with only tagged frames, set REMODER[DXE]=3D0 and set
MaxLength =3D Max LLC size+4.
- Leo
^ permalink raw reply
* [PATCH 0/2] Add support for RAM & ROM mappings to the physmap_of driver
From: Laurent Pinchart @ 2008-03-26 12:41 UTC (permalink / raw)
To: linux-mtd; +Cc: ben, linuxppc-dev, David Gibson
Hi everybody,
these two patches add support for memory-mapped RAM & ROM chips to the=20
physmap_of MTD driver.
Best regards,
=2D-=20
Laurent Pinchart
CSE Semaphore Belgium
Chauss=E9e de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
=46 +32 (2) 387 42 75
^ permalink raw reply
* Re: [PATCH 2/2] pasemi_mac: Netpoll support
From: Valentine Barshak @ 2008-03-26 12:41 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev, pasemi-linux, jgarzik, netdev
In-Reply-To: <20080326015801.GC23103@lixom.net>
Olof Johansson wrote:
> Add netpoll support to allow use of netconsole.
>
> Signed-off-by: Nate Case <ncase@xes-inc.com>
> Signed-off-by: Olof Johansson <olof@lixom.net>
>
> diff --git a/drivers/net/pasemi_mac.c b/drivers/net/pasemi_mac.c
> index abb1dc4..6030ffe 100644
> --- a/drivers/net/pasemi_mac.c
> +++ b/drivers/net/pasemi_mac.c
> @@ -1648,6 +1648,26 @@ static int pasemi_mac_poll(struct napi_struct *napi, int budget)
> return pkts;
> }
>
> +#ifdef CONFIG_NET_POLL_CONTROLLER
> +/*
> + * Polling 'interrupt' - used by things like netconsole to send skbs
> + * without having to re-enable interrupts. It's not called while
> + * the interrupt routine is executing.
> + */
> +static void pasemi_mac_netpoll(struct net_device *dev)
> +{
> + const struct pasemi_mac *mac = netdev_priv(dev);
> +
> + disable_irq(mac->tx->chan.irq);
> + pasemi_mac_tx_intr(mac->tx->chan.irq, mac->tx);
> + enable_irq(mac->tx->chan.irq);
> +
> + disable_irq(mac->rx->chan.irq);
> + pasemi_mac_rx_intr(mac->rx->chan.irq, dev);
Shouldn't this actually be pasemi_mac_rx_intr(mac->rx->chan.irq, mac->rx)?
Thanks,
Valentine.
> _______________________________________________
> 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