On Thu, Jan 22, 2009 at 4:52 AM, Scott Wood wrote:
>> 3) In the PIC: interrupt-control...@10c00 node-
>> reg = <0x10c00 0x80>;
>
> Offset and length of PIC registers.
Thanks Scott. What is the meaning of the Ethernet reg field?:
reg = <0x11300 0x20 0x8400 0x100 0x11390 0x1>;
Is it-
0x11300-> G
From: Paul Mackerras
Date: Thu, 22 Jan 2009 18:06:13 +1100
> Out of curiosity, what ppc hardware are you using perf_counters on?
> A G5?
An UltraSPARC-IIIi :-)
I just wanted to make sure you realized the conflict, and you
obviously do.
___
Linuxppc-de
David Miller writes:
> Paul, I just noticed that right now if perf counter is enabled, the
> oprofile module load will always fail because the powerpc perf counter
> support unconditionally grabs the PMC hardware using
> reserve_pmc_hardware() in an arch_initcall()
>
> There really needs to be a
Paul, I just noticed that right now if perf counter is enabled, the
oprofile module load will always fail because the powerpc perf counter
support unconditionally grabs the PMC hardware using
reserve_pmc_hardware() in an arch_initcall()
There really needs to be a way to segregate these multiple u
> That's as far as I took it: I can see there's code to set up
> "Legacy VGA memory" but it looks like that's not coming into play.
> dmesg and .config attached: I think you'll get to the point much
> quicker than I would.
>
> Though I bet you're busy at the moment: no hurry, I can comment
> out
On Wed, Jan 21, 2009 at 2:13 PM, Juergen Beisert wrote:
> Am Mittwoch, 21. Januar 2009 21:55 schrieb Grant Likely:
>> [...]
>> The whole 'port-number' scheme for assigning numbers to PSC uarts was
>> always rather half baked and just adds complexity. Remove it from the
>> driver. After this patc
On Tue, 20 Jan 2009, Roel Kluin wrote:
> >> make id signed so a negative id will get noticed
> >
> > Thanks for noticing! It looks OK, except...
>
> > 1. You forgot to update the forward declaration of ps3av_set_video_mode() in
> >arch/powerpc/include/asm/ps3av.h (did you compile this succesf
I am using my own 8272-based board (it is similar to the 8272 ADS) with Linux
2.6.27 and u-boot-2009-Jan-rc1.
Scott Wood-2 wrote:
>
> On Tue, Jan 20, 2009 at 11:56:58AM +0100, Jean-Michel Hautbois wrote:
> That looks like something is failing when the real (as opposed to early
> debug) serial d
I am using my own 8272-based board (it is similar to the 8272 ADS) with Linux
2.6.27 and u-boot-2009-Jan-rc1.
Scott Wood-2 wrote:
>
> On Tue, Jan 20, 2009 at 11:56:58AM +0100, Jean-Michel Hautbois wrote:
> That looks like something is failing when the real (as opposed to early
> debug) serial d
This patch adds a new driver: sdhci-of. The driver is similar to
the sdhci-pci, it contains common probe code, and controller-specific
ops and quirks.
So far there are only Freescale eSDHC ops and quirks.
Signed-off-by: Anton Vorontsov
---
drivers/mmc/host/Kconfig| 10 ++
drivers/mmc/host
This patch adds SDHCI_QUIRK_FSL quirk. The quirk is used to instruct
the sdhci driver about various FSL eSDHC host incompatibilities:
1) FSL eSDHC controllers can support maximum block size up to 4096
bytes. The MBL (Maximum Block Length) field in the capabilities
register extended by one bi
FSL eSDHC hosts have incompatible register map to manage the SDCLK.
This patch adds set_clock callback so that drivers could overwrite
set_clock behaviour.
Similar patch[1] was posted by Ben Dooks, though in Ben's version the
callback is named change_clock, plus the patch has some unrelated bits
t
FSL eSDHC hosts don't provide clocks bits in the capabilities register,
instead we're getting clocks values from the device tree.
There is somewhat similar change[1] from Ben Dooks, the change adds
callbacks for getting the clocks. But for eSDHC the callbacks are
superfluous, since the clocks are
Some hosts (that is, FSL eSDHC) throw PIO interrupts during DMA
transfers, this causes tons of unneeded interrupts, and thus highly
degraded speed.
This patch adds SDHCI_QUIRK_PIO_IRQS_DURING_DMA quirk. When specified,
the sdhci driver will disable PIO interrupts during DMA transfers.
Signed-off-
SDHCI driver must take special care when working with "triggering"
registers on hosts with strict 32 bit addressing.
In FSL eSDHC hosts all registers are 32 bit width, writing to the
first half of any register will cause [undefined?] write the second
half of the register. That is, 16 bit write to
This patch adds SDHCI_QUIRK_INVERTED_WRITE_PROTECT quirk. When
specified, the sdhci driver will invert WP state.
p.s. Actually, the quirk is more board-specific than
controller-specific.
Signed-off-by: Anton Vorontsov
---
drivers/mmc/host/sdhci.c |2 ++
drivers/mmc/host/sdhci.h |2
This patch adds SDHCI_QUIRK_BROKEN_CARD_DETECTION quirk. When specified,
sdhci driver will set MMC_CAP_NEEDS_POLL MMC host capability, and won't
enable card insert/remove interrupts.
This is needed for hosts with unreliable card detection, such as FSL
eSDHC. The original eSDHC driver was tring to
Currently the SDHCI driver works with PCI accessors (write{l,b,w} and
read{l,b,w}).
With this patch drivers may change memory accessors, so that we can
support hosts with "weird" IO memory access requirments.
For example, in "FSL eSDHC" SDHCI hardware all registers are 32 bit
width, with big-endi
From: Ben Dooks
The Samsung SDHCI (and FSL eSDHC) controller block seems to fail
to generate an INT_DATA_END after the transfer has completed and
the bus busy state finished.
Changes in e809517f6fa5803a5a1cd56026f0e2190fc13d5c to use the
new busy method are the cause of the behaviour change.
Si
On Thu, Jan 15, 2009 at 07:37:00AM +0800, Liu Dave wrote:
> > This patch adds support for the Freescale Enhanced Secure Digital
> > Host Controller Interface as found in some Freescale PowerPC
> > microprocessors (e.g. MPC837x SOCs).
>
> The Freescale ESDHC controller is basically compatible with
On Wed, Jan 14, 2009 at 09:43:50PM -0600, Kumar Gala wrote:
>
> On Jan 14, 2009, at 1:46 PM, Anton Vorontsov wrote:
>
>> From: Xie Xiaobo
>>
>> This patch adds support for the Freescale Enhanced Secure Digital
>> Host Controller Interface as found in some Freescale PowerPC
>> microprocessors (e.g.
On Mon, 2009-01-19 at 17:00 +0530, Chandru wrote:
> --- linux-2.6.29-rc2/arch/powerpc/mm/numa.c.orig 2009-01-19
> 16:14:49.0 +0530
> +++ linux-2.6.29-rc2/arch/powerpc/mm/numa.c 2009-01-19 16:36:38.0
> +0530
> @@ -901,7 +901,8 @@ static void mark_reserved_regions_for_ni
>
On Jan 21, 2009, at 12:00 PM, Aaron Pace wrote:
Its possible in that Linux supports this. However the PPC32 code
does not
exist and would need to be added to support non-contiguous memory
ranges.
What exact PCI-E needs do you have? Is PCI-E performance
critical? Is
(are) your pci d
These are all powerpc specific drivers.
res.start in fsl_elbc_nand.c needs to be cast since it may be either 32
or 64 bit. Thanks to Scott Wood for noticing.
Signed-off-by: Stephen Rothwell
Acked-by: Arnd Bergmann call_edac bits in particular
Acked-by: Olof Johansson pasemi_nand peices
Acked-
From: Thomas Klein
Date: Wed, 21 Jan 2009 15:49:41 +0100
> Reworked receive queue fill policies to make the driver more tolerant
> in low memory conditions.
>
> Signed-off-by: Thomas Klein
Applied, but there is an even better way to handle this.
You should be allocating replacement RX skbs at
From: Thomas Klein
Date: Wed, 21 Jan 2009 15:49:20 +0100
> PAGE_SIZE allocations via slab are not guaranteed to be page-aligned. Fixed
> all memory allocations where page alignment is required by firmware.
>
> Signed-off-by: Thomas Klein
Applied.
___
From: Thomas Klein
Date: Wed, 21 Jan 2009 15:49:00 +0100
> Adapt to lately introduced net_device_ops structure.
>
> Signed-off-by: Thomas Klein
Applied.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxpp
On Wed, 21 Jan 2009 12:13:24 -0600 Scott Wood wrote:
>
> On Wed, Jan 21, 2009 at 11:16:51AM +1100, Stephen Rothwell wrote:
> > - printk(KERN_INFO "eLBC NAND device at 0x%zx, bank %d\n",
> > + printk(KERN_INFO "eLBC NAND device at 0x%llx, bank %d\n",
> >res.start, priv->bank);
>
>
Am Mittwoch, 21. Januar 2009 21:55 schrieb Grant Likely:
> [...]
> The whole 'port-number' scheme for assigning numbers to PSC uarts was
> always rather half baked and just adds complexity. Remove it from the
> driver. After this patch is applied, PSC UART numbers are simply
> assigned from the o
From: Grant Likely
This patch adds IRQ controller support to the MPC5200 General
Purpose Timer (GPT) device driver. With this patch the mpc5200-gpt
driver supports both GPIO and IRQ functions.
The GPT driver was contained within the mpc52xx_gpio.c file, but this
patch moves it out into a new fi
From: Grant Likely
Rework the mpc5200-pic driver to simplify it and fix up the setting
of desc->status when set_type is called for internal IRQs (so they
are reported as level, not edge). The simplification is due to
splitting off the handling of external IRQs into a separate block
so they don't
From: Grant Likely
pr_debug() calls in the 'hot' *_mask(), *_unmask(), *_ack() and
get_irq() makes adding #define DEBUG pretty much useless. Remove
these calls because they completely swamp the output.
Signed-off-by: Grant Likely
---
arch/powerpc/platforms/52xx/mpc52xx_pic.c | 23 -
From: Grant Likely
The MPC5200 PSC device is wired up to a dedicated interrupt line
which is never shared. This patch removes the IRQF_SHARED flag
from the request_irq() call which eliminates the "IRQF_DISABLED
is not guaranteed on shared IRQs" warning message from the console
output.
Signed-of
From: Grant Likely
This patch adds board support for the Media5200 platform. Changes are:
- add the media5200 device tree
- add the media5200 platform support code and cascaded interrupt controller
- add media5200 to the build targets.
Note: this patch also includes a minor tweak to the lite520
From: Grant Likely
Trim out obsolete/extraneous properties and tighten up some usage
conventions. Changes include:
- removal of device_type properties
- removal of cell-index properties
- Addition of gpio-controller and #gpio-cells properties to gpio
nodes
- Move common interrupt-parent proper
From: Grant Likely
There is no reason for the PSC UART driver or the Ethernet driver
to require a device_type property. The compatible value is sufficient
to uniquely identify the device. Remove it from the driver.
The whole 'port-number' scheme for assigning numbers to PSC uarts was
always ra
From: Grant Likely
This patch updates the mpc5200 binding documentation to match
actual usage conventions, to remove incorrect information, and
to remove topics which are more thoroughly described elsewhere.
Signed-off-by: Grant Likely
CC: devtree-disc...@ozlabs.org
CC: Wolfram Sang
---
Docu
Hi All,
i have a board with MPC8555 processor
uboot version 1.1.6
linux kernel 2.6.19-rc5
ltib version: 6.2.2-sv
gcc 3.4.3
it boots successfully
i want to upgrade my linux kernel to 2.6.27
i upgraded the following:
ltib version 8.1.2-sv
gcc 4.1
linux kernel 2.6.27
& i kept the uboot with the same
On Wed, Jan 21, 2009 at 11:16:51AM +1100, Stephen Rothwell wrote:
> - printk(KERN_INFO "eLBC NAND device at 0x%zx, bank %d\n",
> + printk(KERN_INFO "eLBC NAND device at 0x%llx, bank %d\n",
> res.start, priv->bank);
This won't work if resource_size_t is 32-bit; it needs a cast.
>
> Its possible in that Linux supports this. However the PPC32 code does not
> exist and would need to be added to support non-contiguous memory ranges.
>
> What exact PCI-E needs do you have? Is PCI-E performance critical? Is
> (are) your pci device(s) 64-bit address capable?
>
> I ask because
On Wed, Jan 21, 2009 at 06:37:32PM +1100, Daniel Ng wrote:
> I think the of_get_gpio() error messages are a result of the following
> code in cpm_uart_init_port()-
>
> for (i = 0; i < NUM_GPIOS; i++)
> pinfo->gpios[i] = of_get_gpio(np, i);
>
> -why is this code here? Is it for processing mo
Create an of-aware driver using the now exported generic functions from
plat-ram.c. A typical oftree snipplet for it looks like this:
s...@04e0 {
compatible = "mtd-ram";
reg = <0x04e0 0x0020>;
bank-width = <2>;
};
Partitions on this device are not yet supported
Refactor the probe and remove routines of the mtd-ram driver to export
a generic part which can later be accessed by an of-counterpart of this
driver. Tested with a phyCORE-MPC5200B-IO.
Signed-off-by: Wolfram Sang
---
drivers/mtd/maps/plat-ram.c | 123 +-
Hello,
as we needed an of-mtd-ram driver to support SRAM on the
phyCORE-MPC5200B-IO, I did the following:
Patch 1:
refactor plat-ram.c to have generic probe and remove
routines
Patch 2:
use the new routines for an of-driver
Looking forward to comments. (Sidenote: Converting all these plat
On Jan 21, 2009, at 9:18 AM, Aaron Pace wrote:
Hello,
I'm working on a design using a Freescale MPC8572 processor.
We are using 4 gigs of memory, and also need a window of 512 megs for
PCI-E devices.
What I have done is set up the first 2G of memory from 0x0 - 0x7f, the
PCI windows from 0x8 -
Hello,
I'm working on a design using a Freescale MPC8572 processor.
We are using 4 gigs of memory, and also need a window of 512 megs for
PCI-E devices.
What I have done is set up the first 2G of memory from 0x0 - 0x7f, the
PCI windows from 0x8 - 0x9f, localbus devices + CCSRBAR from 0xf -
0xf
Eric Sesterhenn wrote:
Some callers of zlib_inflate() might accidentally pass a NULL
pointer in strm->next_out which zlib_inflate() should catch.
Others like the powerpc gunzip_partial expect to be able
to extract a zImage to memory location 0. This introduces
zlib_inflate_usafe() for those and
I am now trying to use an initial RAM filesystem.
I have this:
"checking if image is initramfs... it is"
And then, after some hardware detections:
"List of all partitions:
1f008192 mtdblock0 (driver?)
No filesystem could mount root, tried: ext3 ext2 cramfs
Kernel panic - not syncing:
On Wednesday 21 January 2009, Paul Collins wrote:
> Got a couple of these on a PowerBook running 2.6.29-rc2 either during
> suspend or resume -- it's hard to tell. (The suspend message is
> timestamped in syslog with the time I resumed, so I guess it was
> buffered along with the subsequent "Badne
On Tue, 2009-01-20 at 10:31 -0600, Scott Wood wrote:
> On Tue, Jan 20, 2009 at 11:56:58AM +0100, Jean-Michel Hautbois wrote:
> > Built 1 zonelists in Zone order, mobility grouping on. Total pages: 16256
> > Kernel command line: root=/dev/ram rw
> > PID hash table entries: 256 (order: 8, 1024 bytes
Hello,
> Pengutronix makes the kernels for the phytec pcm030 boards. Their
> 2.6.23 kernel has probably been patched for real time support. If you
> don't need real time there's no real downside to using current git.
> Sascha may have some other patches that I'm unaware of.
We are currently worki
On Wed, Jan 21, 2009 at 7:57 AM, Dave Best wrote:
> Thanks for the driver.
> I am looking into this.
>
> I still have some trouble to compile and use the driver:
> - I currently use the 2.6.23.1 kernel source which was provide along with
> the pcm030 board by Phytec. And i guess your driver was
Reworked receive queue fill policies to make the driver more tolerant
in low memory conditions.
Signed-off-by: Thomas Klein
---
diff -Nurp -X dontdiff linux-2.6.29-rc2/drivers/net/ehea/ehea_main.c
patched_kernel/drivers/net/ehea/ehea_main.c
--- linux-2.6.29-rc2/drivers/net/ehea/ehea_main.c
PAGE_SIZE allocations via slab are not guaranteed to be page-aligned. Fixed
all memory allocations where page alignment is required by firmware.
Signed-off-by: Thomas Klein
---
Thanks to Nathan Lynch for this hint!
diff -Nurp -X dontdiff linux-2.6.29-rc2/drivers/net/ehea/ehea_main.c
patched_ke
Adapt to lately introduced net_device_ops structure.
Signed-off-by: Thomas Klein
---
diff -Nurp -X dontdiff linux-2.6.29/drivers/net/ehea/ehea.h
patched_kernel/drivers/net/ehea/ehea.h
--- linux-2.6.29/drivers/net/ehea/ehea.h2009-01-16 12:03:27.0
+0100
+++ patched_kernel/drivers
Thanks for the driver.
I am looking into this.
I still have some trouble to compile and use the driver:
- I currently use the 2.6.23.1 kernel source which was provide along with the
pcm030 board by Phytec. And i guess your driver was compile along with a newer
driver as i can't find the "stric
Probe the new mdio node added by b31a1d8b. Fix kernel panic problem when
gianfar driver wants to get the of_platform_device of that mdio.
Signed-off-by: Li Yang
---
Supersede the patch to add "simple-bus" to gianfar node to fix this problem.
arch/powerpc/boot/dts/mpc8313erdb.dts |2 +-
* Tom Rini (tr...@kernel.crashing.org) wrote:
> On Tue, Jan 20, 2009 at 05:47:14PM +0100, Eric Sesterhenn wrote:
> > * Jörn Engel (jo...@logfs.org) wrote:
> > > On Fri, 16 January 2009 16:07:00 -0700, Tom Rini wrote:
> > > >
> > > > Sounds like a plan to me, except maybe zlib_inflate_unsafe() and
58 matches
Mail list logo
