* 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: [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
* 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: 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
* [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: [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
* 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: [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 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: 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: 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: [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: 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: 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: 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: [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
* 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
* [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
* Missing patch for MPC5200B register definitions?
From: Matt Sealey @ 2008-03-26 16:15 UTC (permalink / raw)
To: ppc-dev
I've just been looking into the MPC5200B AC97 driver breakage with the
latest Git kernel, and found the following patch;
http://ozlabs.org/pipermail/linuxppc-dev/2007-May/035952.html
Is not in the latest tree. As such anything which uses the new MPC5200B
registers (especially important on AC97 and probably not used otherwise)
has not or was not applied.
Since the latest kernel source from git actually includes the MPC5121E
differences, I assume this is a regression?
How do we go about fixing this?
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
^ permalink raw reply
* Re: ppc platform for AMCC-440EPx - ELDK to the rescue
From: Scott Wood @ 2008-03-26 16:26 UTC (permalink / raw)
To: Steve Heflin; +Cc: linuxppc-embedded
In-Reply-To: <20080326130837.762DBDE2FB@ozlabs.org>
Steve Heflin wrote:
> 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.
And how do you propose to talk to said PCI devices without configuring
the host bridge?
> Also, I fail to see what the DTS virtualization layer of the hardware
> buys us.
Maintainability. Ease of porting to new hardware.
> 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,
Are you volunteering to maintain it, including the rest of us not having
to care when we change something in common code that breaks it?
> especially given the
> fact that DENX's ELDK is still using it with Linux 2.6.24.2 !!
Take that up with Denx.
-Scott
^ permalink raw reply
* Re: Missing patch for MPC5200B register definitions?
From: Matt Sealey @ 2008-03-26 16:48 UTC (permalink / raw)
To: ppc-dev
In-Reply-To: <47EA7687.5000102@genesi-usa.com>
Oh yes, I forgot.. also, the new MPC5121E stuff includes a lot of unions and
defines to make using both PSC formats easier.
Since the MPC5200 and MPC5200B PSC structures are different (CCR size), can the
original suggestion (in that thread) to support both with a union and some
defines to make supporting both CCR sizes, be implemented, or do we still think
that MPC5200 (not B) is not worth supporting?
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
Matt Sealey wrote:
> I've just been looking into the MPC5200B AC97 driver breakage with the
> latest Git kernel, and found the following patch;
>
> http://ozlabs.org/pipermail/linuxppc-dev/2007-May/035952.html
>
> Is not in the latest tree. As such anything which uses the new MPC5200B
> registers (especially important on AC97 and probably not used otherwise)
> has not or was not applied.
>
> Since the latest kernel source from git actually includes the MPC5121E
> differences, I assume this is a regression?
>
> How do we go about fixing this?
>
^ permalink raw reply
* Re: [PATCHv2 2/3] ep8248e: Reference SMC parameter RAM base in the device tree.
From: Scott Wood @ 2008-03-26 16:59 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: linuxppc-dev
In-Reply-To: <200803261220.43039.laurentp@cse-semaphore.com>
Laurent Pinchart wrote:
> @@ -138,7 +137,7 @@
> device_type = "serial";
> compatible = "fsl,mpc8248-smc-uart",
> "fsl,cpm2-smc-uart";
> - reg = <0x11a80 0x20 0x1100 0x40>;
> + reg = <0x11a80 0x20 0x87fc 2>;
> interrupts = <4 8>;
> interrupt-parent = <&PIC>;
> fsl,cpm-brg = <7>;
This breaks the bootwrapper console.
-Scott
^ permalink raw reply
* Xilin Temac Timer ?
From: khollan @ 2008-03-26 17:02 UTC (permalink / raw)
To: linuxppc-embedded
Hi
What is the purpose of stopping the timer in the ioctl call to read a PHY
register? This is the code:
case SIOCGMIIREG: /* Read GMII PHY register. */
case SIOCDEVPRIVATE + 1: /* for binary compat, remove in 2.5 */
if (data->phy_id > 31 || data->reg_num > 31)
return -ENXIO;
/* Stop the PHY timer to prevent reentrancy. */
spin_lock_irqsave(&XTE_spinlock, flags);
del_timer_sync(&lp->phy_timer);
ret = XTemac_PhyRead(&lp->Emac, data->phy_id,
data->reg_num, &data->val_out);
/* Start the PHY timer up again. */
lp->phy_timer.expires = jiffies + 2 * HZ;
add_timer(&lp->phy_timer);
spin_unlock_irqrestore(&XTE_spinlock, flags);
if (ret != XST_SUCCESS) {
printk(KERN_ERR
"%s: XTemac: could not read from PHY, error=%d.\n",
dev->name, ret);
return -EBUSY;
}
return 0;
I ask because I have an application that needs to read a Phy register before
the timer has started to see if a link is present. This causes a kernel bug
when trying to run the del_timer_sync function because there is not a
running timer. I would like to know if it is safe to remove the timer del
and add but keep the spin lock.
Thanks for your help
Kevin
--
View this message in context: http://www.nabble.com/Xilin-Temac-Timer---tp16306218p16306218.html
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Hell
From: Stefan Eletzhofer @ 2008-03-26 17:22 UTC (permalink / raw)
To: Linuxppc-embedded@ozlabs.org
--
Stefan Eletzhofer
www.eletztrick.de
^ permalink raw reply
* Re: [PATCH] [POWERPC] CPM1: implement GPIO LIB API
From: Jochen Friedrich @ 2008-03-26 17:47 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev list, linux-kernel
In-Reply-To: <47E93350.6090806@freescale.com>
Hi Scott,
>> diff --git a/arch/powerpc/platforms/8xx/Kconfig b/arch/powerpc/platforms/8xx/Kconfig
>> index 7fd224c..e12cbf0 100644
>> --- a/arch/powerpc/platforms/8xx/Kconfig
>> +++ b/arch/powerpc/platforms/8xx/Kconfig
>> @@ -4,6 +4,8 @@ config FADS
>> config CPM1
>> bool
>> select CPM
>> + select GENERIC_GPIO
>> + select GPIO_LIB
>
> Shouldn't this depend on the user enabling GPIO support? Some 8xx
> boards are very memory-constrained, so we don't want to be making the
> kernel even bigger than it already is unless it's actually needed.
Are you more comfortable with this?
Implement GPIO LIB API on CPM1 Freescale SoC.
Signed-off-by: Jochen Friedrich <jochen@scram.de>
---
arch/powerpc/platforms/8xx/Kconfig | 10 ++
arch/powerpc/sysdev/cpm1.c | 246 +++++++++++++++++++++++++++++++++++-
2 files changed, 255 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/platforms/8xx/Kconfig b/arch/powerpc/platforms/8xx/Kconfig
index 7fd224c..9d17425 100644
--- a/arch/powerpc/platforms/8xx/Kconfig
+++ b/arch/powerpc/platforms/8xx/Kconfig
@@ -109,6 +109,16 @@ config 8xx_COPYBACK
If in doubt, say Y here.
+config 8xx_GPIO
+ bool "GPIO API Support"
+ select GENERIC_GPIO
+ select HAVE_GPIO_LIB
+ help
+ Saying Y here will cause the ports on an MPC8xx processor to be used
+ with the GPIO API. If you say N here, the kernel needs less memory.
+
+ If in doubt, say Y here.
+
config 8xx_CPU6
bool "CPU6 Silicon Errata (860 Pre Rev. C)"
help
diff --git a/arch/powerpc/sysdev/cpm1.c b/arch/powerpc/sysdev/cpm1.c
index df8bd2b..6c97f3f 100644
--- a/arch/powerpc/sysdev/cpm1.c
+++ b/arch/powerpc/sysdev/cpm1.c
@@ -30,6 +30,7 @@
#include <linux/interrupt.h>
#include <linux/irq.h>
#include <linux/module.h>
+#include <linux/spinlock.h>
#include <asm/page.h>
#include <asm/pgtable.h>
#include <asm/8xx_immap.h>
@@ -42,6 +43,11 @@
#include <asm/fs_pd.h>
+#ifdef CONFIG_8xx_GPIO
+#include <linux/of_gpio.h>
+#include <asm/gpio.h>
+#endif
+
#define CPM_MAP_SIZE (0x4000)
#ifndef CONFIG_PPC_CPM_NEW_BINDING
@@ -403,7 +409,7 @@ struct cpm_ioport16 {
};
struct cpm_ioport32 {
- __be32 dir, par, sor;
+ __be32 dir, par, sor, dat;
};
static void cpm1_set_pin32(int port, int pin, int flags)
@@ -610,3 +616,241 @@ int cpm1_clk_setup(enum cpm_clk_target target, int clock, int mode)
return 0;
}
+
+/*
+ * GPIO LIB API implementation
+ */
+#ifdef CONFIG_8xx_GPIO
+
+struct cpm1_gpio16_chip {
+ struct of_mm_gpio_chip mm_gc;
+ spinlock_t lock;
+
+ /* shadowed data register to clear/set bits safely */
+ u16 cpdata;
+};
+
+static inline struct cpm1_gpio16_chip *
+to_cpm1_gpio16_chip(struct of_mm_gpio_chip *mm_gc)
+{
+ return container_of(mm_gc, struct cpm1_gpio16_chip, mm_gc);
+}
+
+static void cpm1_gpio16_save_regs(struct of_mm_gpio_chip *mm_gc)
+{
+ struct cpm1_gpio16_chip *cpm1_gc = to_cpm1_gpio16_chip(mm_gc);
+ struct cpm_ioport16 __iomem *iop = mm_gc->regs;
+
+ cpm1_gc->cpdata = in_be16(&iop->dat);
+}
+
+static int cpm1_gpio16_get(struct gpio_chip *gc, unsigned int gpio)
+{
+ struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
+ struct cpm_ioport16 __iomem *iop = mm_gc->regs;
+ u16 pin_mask;
+
+ pin_mask = 1 << (15 - gpio);
+
+ return !!(in_be16(&iop->dat) & pin_mask);
+}
+
+static void cpm1_gpio16_set(struct gpio_chip *gc, unsigned int gpio, int value)
+{
+ struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
+ struct cpm1_gpio16_chip *cpm1_gc = to_cpm1_gpio16_chip(mm_gc);
+ struct cpm_ioport16 __iomem *iop = mm_gc->regs;
+ unsigned long flags;
+ u16 pin_mask = 1 << (15 - gpio);
+
+ spin_lock_irqsave(&cpm1_gc->lock, flags);
+
+ if (value)
+ cpm1_gc->cpdata |= pin_mask;
+ else
+ cpm1_gc->cpdata &= ~pin_mask;
+
+ out_be16(&iop->dat, cpm1_gc->cpdata);
+
+ spin_unlock_irqrestore(&cpm1_gc->lock, flags);
+}
+
+static int cpm1_gpio16_dir_out(struct gpio_chip *gc, unsigned int gpio, int val)
+{
+ struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
+ struct cpm_ioport16 __iomem *iop = mm_gc->regs;
+ u16 pin_mask;
+
+ pin_mask = 1 << (15 - gpio);
+
+ setbits16(&iop->dir, pin_mask);
+
+ cpm1_gpio16_set(gc, gpio, val);
+
+ return 0;
+}
+
+static int cpm1_gpio16_dir_in(struct gpio_chip *gc, unsigned int gpio)
+{
+ struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
+ struct cpm_ioport16 __iomem *iop = mm_gc->regs;
+ u16 pin_mask;
+
+ pin_mask = 1 << (15 - gpio);
+
+ clrbits16(&iop->dir, pin_mask);
+
+ return 0;
+}
+
+int cpm1_gpiochip_add16(struct device_node *np)
+{
+ struct cpm1_gpio16_chip *cpm1_gc;
+ struct of_mm_gpio_chip *mm_gc;
+ struct of_gpio_chip *of_gc;
+ struct gpio_chip *gc;
+
+ cpm1_gc = kzalloc(sizeof(*cpm1_gc), GFP_KERNEL);
+ if (!cpm1_gc)
+ return -ENOMEM;
+
+ spin_lock_init(&cpm1_gc->lock);
+
+ mm_gc = &cpm1_gc->mm_gc;
+ of_gc = &mm_gc->of_gc;
+ gc = &of_gc->gc;
+
+ mm_gc->save_regs = cpm1_gpio16_save_regs;
+ of_gc->gpio_cells = 1;
+ gc->ngpio = 16;
+ gc->direction_input = cpm1_gpio16_dir_in;
+ gc->direction_output = cpm1_gpio16_dir_out;
+ gc->get = cpm1_gpio16_get;
+ gc->set = cpm1_gpio16_set;
+
+ return of_mm_gpiochip_add(np, mm_gc);
+}
+
+struct cpm1_gpio32_chip {
+ struct of_mm_gpio_chip mm_gc;
+ spinlock_t lock;
+
+ /* shadowed data register to clear/set bits safely */
+ u32 cpdata;
+};
+
+static inline struct cpm1_gpio32_chip *
+to_cpm1_gpio32_chip(struct of_mm_gpio_chip *mm_gc)
+{
+ return container_of(mm_gc, struct cpm1_gpio32_chip, mm_gc);
+}
+
+static void cpm1_gpio32_save_regs(struct of_mm_gpio_chip *mm_gc)
+{
+ struct cpm1_gpio32_chip *cpm1_gc = to_cpm1_gpio32_chip(mm_gc);
+ struct cpm_ioport32 __iomem *iop = mm_gc->regs;
+
+ cpm1_gc->cpdata = in_be32(&iop->dat);
+}
+
+static int cpm1_gpio32_get(struct gpio_chip *gc, unsigned int gpio)
+{
+ struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
+ struct cpm_ioport32 __iomem *iop = mm_gc->regs;
+ u32 pin_mask;
+
+ pin_mask = 1 << (31 - gpio);
+
+ return !!(in_be32(&iop->dat) & pin_mask);
+}
+
+static void cpm1_gpio32_set(struct gpio_chip *gc, unsigned int gpio, int value)
+{
+ struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
+ struct cpm1_gpio32_chip *cpm1_gc = to_cpm1_gpio32_chip(mm_gc);
+ struct cpm_ioport32 __iomem *iop = mm_gc->regs;
+ unsigned long flags;
+ u32 pin_mask = 1 << (31 - gpio);
+
+ spin_lock_irqsave(&cpm1_gc->lock, flags);
+
+ if (value)
+ cpm1_gc->cpdata |= pin_mask;
+ else
+ cpm1_gc->cpdata &= ~pin_mask;
+
+ out_be32(&iop->dat, cpm1_gc->cpdata);
+
+ spin_unlock_irqrestore(&cpm1_gc->lock, flags);
+}
+
+static int cpm1_gpio32_dir_out(struct gpio_chip *gc, unsigned int gpio, int val)
+{
+ struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
+ struct cpm_ioport32 __iomem *iop = mm_gc->regs;
+ u32 pin_mask;
+
+ pin_mask = 1 << (31 - gpio);
+
+ setbits32(&iop->dir, pin_mask);
+
+ cpm1_gpio32_set(gc, gpio, val);
+
+ return 0;
+}
+
+static int cpm1_gpio32_dir_in(struct gpio_chip *gc, unsigned int gpio)
+{
+ struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
+ struct cpm_ioport32 __iomem *iop = mm_gc->regs;
+ u32 pin_mask;
+
+ pin_mask = 1 << (31 - gpio);
+
+ clrbits32(&iop->dir, pin_mask);
+
+ return 0;
+}
+
+int cpm1_gpiochip_add32(struct device_node *np)
+{
+ struct cpm1_gpio32_chip *cpm1_gc;
+ struct of_mm_gpio_chip *mm_gc;
+ struct of_gpio_chip *of_gc;
+ struct gpio_chip *gc;
+
+ cpm1_gc = kzalloc(sizeof(*cpm1_gc), GFP_KERNEL);
+ if (!cpm1_gc)
+ return -ENOMEM;
+
+ spin_lock_init(&cpm1_gc->lock);
+
+ mm_gc = &cpm1_gc->mm_gc;
+ of_gc = &mm_gc->of_gc;
+ gc = &of_gc->gc;
+
+ mm_gc->save_regs = cpm1_gpio32_save_regs;
+ of_gc->gpio_cells = 1;
+ gc->ngpio = 32;
+ gc->direction_input = cpm1_gpio32_dir_in;
+ gc->direction_output = cpm1_gpio32_dir_out;
+ gc->get = cpm1_gpio32_get;
+ gc->set = cpm1_gpio32_set;
+
+ return of_mm_gpiochip_add(np, mm_gc);
+}
+
+static int cpm_init_par_io(void)
+{
+ struct device_node *np;
+
+ for_each_compatible_node(np, NULL, "fsl,cpm1-pario-bank16")
+ cpm1_gpiochip_add16(np);
+
+ for_each_compatible_node(np, NULL, "fsl,cpm1-pario-bank32")
+ cpm1_gpiochip_add32(np);
+ return 0;
+}
+arch_initcall(cpm_init_par_io);
+
+#endif /* CONFIG_8xx_GPIO */
--
1.5.4.4
^ permalink raw reply related
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