* Re: [PATCH 5/5] libata/drivers: Add pata_macio, driver Apple PowerMac/PowerBook IDE controller
From: Mikael Pettersson @ 2009-12-03 15:10 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: tj, linux-ide, linuxppc-dev, jeff
In-Reply-To: <20091202003630.29919100851@ozlabs.org>
Benjamin Herrenschmidt writes:
> This is a libata driver for the "macio" IDE controller used on most Apple
> PowerMac and PowerBooks. It's a libata equivalent of drivers/ide/ppc/pmac.c
>
> It supports all the features of its predecessor, including mediabay hotplug
> and suspend/resume. It should also support module load/unload.
>
> The timing calculations have been simplified to use pre-calculated tables
> compared to drivers/ide/pmac.c and it uses the new mediabay interface
> provided by a previous patch.
>
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
>
> v2. Better tested now, seems to be reasonably solid.
>
> Addressed Tejun comments and made remove more robust vs. media-bay,
> should also fix Andreas problem.
Tested in 2.6.32-rc8 and 2.6.32 final on a G4 eMac.
Works fine, except for the yaboot problem:
> /sbin/installkernel 2.6.32 vmlinux System.map
ofpath: Driver: is not supported
ybin: Unable to find OpenFirmware path for boot=/dev/sda2
ybin: Please add ofboot=<path> where <path> is the OpenFirmware path to /dev/sda2 to /etc/yaboot.conf
ofpath: Driver: is not supported
ybin: Unable to determine OpenFirmware path for macosx=/dev/sda4
ybin: Try specifying the real OpenFirmware path for macosx=/dev/sda4 in /etc/yaboot.conf
(userspace is YDL 6.2)
/Mikael
^ permalink raw reply
* Re: [PATCH v2] i2c-mpc: generate START condition after STOP caused by read i2c_msg
From: Michael Lawnick @ 2009-12-03 15:09 UTC (permalink / raw)
To: Ben Dooks; +Cc: linuxppc-dev, Esben Haabendal, Esben Haabendal, linux-i2c
In-Reply-To: <20090526213351.GG23114@fluff.org.uk>
Ben Dooks said the following:
> On Tue, May 26, 2009 at 01:30:21PM +0200, Esben Haabendal wrote:
>> On Tue, May 19, 2009 at 7:22 AM, Esben Haabendal <eha@doredevelopment.dk> wrote:
>> > This fixes MAL (arbitration lost) bug caused by illegal use of
>> > RSTA (repeated START) after STOP condition generated after last byte
>> > of reads. With this patch, it is possible to do an i2c_transfer() with
>> > additional i2c_msg's following the I2C_M_RD messages.
>> >
>> > It still needs to be resolved if it is possible to fix this issue
>> > by removing the STOP condition after reads in a robust way.
>> >
>> > Signed-off-by: Esben Haabendal <eha@doredevelopment.dk>
>> > ---
>> > ?drivers/i2c/busses/i2c-mpc.c | ? ?9 +++++++--
>> > ?1 files changed, 7 insertions(+), 2 deletions(-)
>>
>> Any blockers to get this accepted?
>
> It would be nice to get an ack from someone who can actually test
> the driver before getting this merged.
>
What is the state of this patch?
Shouldn't we attack the problem on a more general way by inventing a
Flag I2C_M_RESTART (or better I2C_M_NO_RESTART for backward compatibility)?
This way the client driver is able to decide what it needs. If we do the
choice within adapter, chance is about 50% to be wrong.
Just my 2 Cents.
--
Michael
^ permalink raw reply
* Re: [PATCH] ppc64: re-enable kexec to allow module loads with CONFIG_MODVERSIONS and CONFIG_RELOCATABLE turned on
From: Neil Horman @ 2009-12-03 15:04 UTC (permalink / raw)
To: linuxppc-dev; +Cc: rusty, paulus
In-Reply-To: <20091119195216.GC11414@hmsreliant.think-freely.org>
>>> Paul, Ben, given that Rusty hasn't come back with any opinion on this patch,
>>do you
>>> feel comfortable merging it via the ppc tree? Currently the earlyinit
>routine
>>> is only compiled in and used for your arch, so I think its fairly benign.
>>
>>Sorry, I *did* track down the archives for linuxppc-dev, then find your post,
>>then read your patch. But I didn't actually reply.
>>
>>Other than minor issues, there's one significant one: you shouldn't be trying
>>to change rodata. It might work on PPC today, but it's poor form at least.
>>
>>How's this? Untested on ppc.
>>
>I'll try grab a ppc64 system and test this soon.
>
>>Other changes:
>>1) I also changed reloc_start to an array; this is a good idea for any
>> linker-defined symbols so the compiler can't make assumptions about size.
>Ok, I'll certainly trust your linker skill over mine :)
>
>>2) local.h? How about module.h?
>Seems good to me
>>3) I don't think the extra ". = 0" is necessary.
>Its not, I was just trying to be clear about where reloc_start was to be placed.
>
>>4) ARCH_USES_RELOC_ENTRIES isn't clear enough for me; I prefer
>> ARCH_RELOCATE_KCRCTAB.
>Sounds good to me.
>
>
>I'll test this as soon as I'm able
>Thanks!
>Neil
>
Just finished testing your patch Rusty, it all works quite well, Thanks!
Will this be going in via your tree, or the ppc tree?
Acked-by: Neil Horman <nhorman@tuxdriver.com>
Neil
^ permalink raw reply
* Re: Recommended functions for accessing internal registers
From: Fortini Matteo @ 2009-12-03 11:16 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1259787475.2076.1160.camel@pasglop>
I'm on an embedded system, so every resource counts.
One of the biggest impacts is when writing to a communication/memory
access FIFO or reading/writing configurations.
In these cases, I'd just need to make sure that there's no I/O
reordering and/or subsequent r/w are not optimized away, I believe.
Should I switch to the deprecated "volatile" attribute?
Thank you.
Cheers,
Matteo
Il 02/12/2009 21.57, Benjamin Herrenschmidt ha scritto:
> On Tue, 2009-12-01 at 17:44 +0100, Fortini Matteo wrote:
>
>> I see that throughout the kernel source, internal PPC registers are
>> accessed through [in|out]_be[32|16|8]() functions. However, they are
>> translated into 3 inline assembly instructions, one of which is an
>> isync, which has a huge performance hit.
>> I tried using readl_be() which seems to be the right function according
>> to the Documentation/ dir, but it is translated directly to in_be32(),
>> so no luck.
>>
>> Is it really necessary to use all those instructions? I know I could use
>> a (volatile u32 *) variable to avoid subsequent read/writes to be
>> optimized out, but it seems to be a deprecated use.
>>
> There are good reasons why the accessors contain those barriers. What
> are you doing that would be performance critical enough for those to be
> a problem ?
>
> Cheers,
> Ben.
>
>
>
^ permalink raw reply
* Re: [PATCH] [SCSI] mpt fusion: Fix 32 bit platforms with 64 bit resources.
From: Wolfgang Denk @ 2009-12-03 8:56 UTC (permalink / raw)
To: Pravin Bathija, Benjamin Herrenschmidt, Desai, Kashyap
Cc: linuxppc-dev, Eric.Moore, linux-scsi
In-Reply-To: <1259805106-23636-1-git-send-email-pbathija@amcc.com>
Dear Pravin Bathija,
In message <1259805106-23636-1-git-send-email-pbathija@amcc.com> you wrote:
> Powerpc 44x uses 36 bit real address while the real address defined
> in MPT Fusion driver is of type 32 bit. This causes ioremap to fail and driver
> fails to initialize. This fix changes the data types representing the real
> address from unsigned long 32-bit types to resource_size_t which is 64-bit. The
> driver has been tested, the disks get discovered correctly and can do IO.
...
> --- a/drivers/message/fusion/mptbase.c
> +++ b/drivers/message/fusion/mptbase.c
> @@ -1511,7 +1511,7 @@ mpt_mapresources(MPT_ADAPTER *ioc)
> {
> u8 __iomem *mem;
> int ii;
> - unsigned long mem_phys;
> + resource_size_t mem_phys;
> unsigned long port;
> u32 msize;
> u32 psize;
I'm not sure if this one-liner really covers all the related issues.
We submitted a similar (but apparently more complete) patch more than
a year ago. Dunno why it has never been picked up. See
http://thread.gmane.org/gmane.linux.scsi/46082 for reference.
> From: Yuri Tikhonov <yur@emcraft.com>
To: linux-scsi@vger.kernel.org
Subject: [PATCH] mptbase: use resource_size_t instead of unsigned long and u32
Date: Thu, 13 Nov 2008 11:33:16 +0300
Hello,
The following patch adds using resource_size_t for the
pci_resource_start()/pci_resource_len() return values. This
makes mptbase driver work correctly on 32 bit systems with
64 bit resources (e.g. PPC440SPe).
Do some minor cleanups in mpt_mapresources() as well.
Signed-off-by: Yuri Tikhonov <yur@emcraft.com>
Signed-off-by: Ilya Yanok <yanok@emcraft.com>
---
drivers/message/fusion/mptbase.c | 38 ++++++++++++++++++++++++++------------
drivers/message/fusion/mptbase.h | 5 +++--
2 files changed, 29 insertions(+), 14 deletions(-)
diff --git a/drivers/message/fusion/mptbase.c b/drivers/message/fusion/mptbase.c
index d6a0074..9daf844 100644
--- a/drivers/message/fusion/mptbase.c
+++ b/drivers/message/fusion/mptbase.c
@@ -1488,11 +1488,12 @@ static int
mpt_mapresources(MPT_ADAPTER *ioc)
{
u8 __iomem *mem;
+ u8 __iomem *port;
int ii;
- unsigned long mem_phys;
- unsigned long port;
- u32 msize;
- u32 psize;
+ resource_size_t mem_phys;
+ resource_size_t port_phys;
+ resource_size_t msize;
+ resource_size_t psize;
u8 revision;
int r = -ENODEV;
struct pci_dev *pdev;
@@ -1530,13 +1531,13 @@ mpt_mapresources(MPT_ADAPTER *ioc)
}
mem_phys = msize = 0;
- port = psize = 0;
+ port_phys = psize = 0;
for (ii = 0; ii < DEVICE_COUNT_RESOURCE; ii++) {
if (pci_resource_flags(pdev, ii) & PCI_BASE_ADDRESS_SPACE_IO) {
if (psize)
continue;
/* Get I/O space! */
- port = pci_resource_start(pdev, ii);
+ port_phys = pci_resource_start(pdev, ii);
psize = pci_resource_len(pdev, ii);
} else {
if (msize)
@@ -1546,11 +1547,8 @@ mpt_mapresources(MPT_ADAPTER *ioc)
msize = pci_resource_len(pdev, ii);
}
}
- ioc->mem_size = msize;
- mem = NULL;
/* Get logical ptr for PciMem0 space */
- /*mem = ioremap(mem_phys, msize);*/
mem = ioremap(mem_phys, msize);
if (mem == NULL) {
printk(MYIOC_s_ERR_FMT ": ERROR - Unable to map adapter"
@@ -1558,14 +1556,24 @@ mpt_mapresources(MPT_ADAPTER *ioc)
return -EINVAL;
}
ioc->memmap = mem;
- dinitprintk(ioc, printk(MYIOC_s_INFO_FMT "mem = %p, mem_phys = %lx\n",
- ioc->name, mem, mem_phys));
+ dinitprintk(ioc, printk(MYIOC_s_INFO_FMT "mem=%p, mem_phys=%llx\n",
+ ioc->name, mem, (u64)mem_phys));
ioc->mem_phys = mem_phys;
ioc->chip = (SYSIF_REGS __iomem *)mem;
/* Save Port IO values in case we need to do downloadboot */
- ioc->pio_mem_phys = port;
+ port = ioremap(port_phys, psize);
+ if (port == NULL) {
+ printk(MYIOC_s_ERR_FMT ": ERROR - Unable to map adapter"
+ " port!\n", ioc->name);
+ return -EINVAL;
+ }
+ ioc->portmap = port;
+ dinitprintk(ioc, printk(MYIOC_s_INFO_FMT "port=%p, port_phys=%llx\n",
+ ioc->name, port, (u64)port_phys));
+
+ ioc->pio_mem_phys = port_phys;
ioc->pio_chip = (SYSIF_REGS __iomem *)port;
return 0;
@@ -1790,6 +1798,7 @@ mpt_attach(struct pci_dev *pdev, const struct pci_device_id *id)
list_del(&ioc->list);
if (ioc->alt_ioc)
ioc->alt_ioc->alt_ioc = NULL;
+ iounmap(ioc->portmap);
iounmap(ioc->memmap);
if (r != -5)
pci_release_selected_regions(pdev, ioc->bars);
@@ -2547,6 +2556,11 @@ mpt_adapter_dispose(MPT_ADAPTER *ioc)
ioc->pci_irq = -1;
}
+ if (ioc->portmap != NULL) {
+ iounmap(ioc->portmap);
+ ioc->portmap = NULL;
+ }
+
if (ioc->memmap != NULL) {
iounmap(ioc->memmap);
ioc->memmap = NULL;
diff --git a/drivers/message/fusion/mptbase.h b/drivers/message/fusion/mptbase.h
index dff048c..17826b3 100644
--- a/drivers/message/fusion/mptbase.h
+++ b/drivers/message/fusion/mptbase.h
@@ -584,8 +584,8 @@ typedef struct _MPT_ADAPTER
SYSIF_REGS __iomem *chip; /* == c8817000 (mmap) */
SYSIF_REGS __iomem *pio_chip; /* Programmed IO (downloadboot) */
u8 bus_type;
- u32 mem_phys; /* == f4020000 (mmap) */
- u32 pio_mem_phys; /* Programmed IO (downloadboot) */
+ resource_size_t mem_phys; /* == f4020000 (mmap) */
+ resource_size_t pio_mem_phys; /* Programmed IO (downloadboot) */
int mem_size; /* mmap memory size */
int number_of_buses;
int devices_per_bus;
@@ -635,6 +635,7 @@ typedef struct _MPT_ADAPTER
int bars; /* bitmask of BAR's that must be configured */
int msi_enable;
u8 __iomem *memmap; /* mmap address */
+ u8 __iomem *portmap; /* mmap address */
struct Scsi_Host *sh; /* Scsi Host pointer */
SpiCfgData spi_data; /* Scsi config. data */
RaidCfgData raid_data; /* Raid config. data */
--
1.5.6.1
--
Yuri Tikhonov, Senior Software Engineer
Emcraft Systems, www.emcraft.com
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
"I haven't lost my mind - it's backed up on tape somewhere."
^ permalink raw reply related
* Re: [PATCH 5/5] libata/drivers: Add pata_macio, driver Apple PowerMac/PowerBook IDE controller
From: Jeff Garzik @ 2009-12-03 8:12 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: tj, linux-ide, linuxppc-dev
In-Reply-To: <20091202003630.29919100851@ozlabs.org>
On 12/01/2009 07:36 PM, Benjamin Herrenschmidt wrote:
> This is a libata driver for the "macio" IDE controller used on most Apple
> PowerMac and PowerBooks. It's a libata equivalent of drivers/ide/ppc/pmac.c
>
> It supports all the features of its predecessor, including mediabay hotplug
> and suspend/resume. It should also support module load/unload.
>
> The timing calculations have been simplified to use pre-calculated tables
> compared to drivers/ide/pmac.c and it uses the new mediabay interface
> provided by a previous patch.
>
> Signed-off-by: Benjamin Herrenschmidt<benh@kernel.crashing.org>
> ---
>
> v2. Better tested now, seems to be reasonably solid.
>
> Addressed Tejun comments and made remove more robust vs. media-bay,
> should also fix Andreas problem.
>
>
> drivers/ata/Kconfig | 10
> drivers/ata/Makefile | 1
> drivers/ata/pata_macio.c | 1427 +++++++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 1438 insertions(+)
Looks fine to me. Two minor comments, which might perhaps be ignored if
that is your taste:
* prefer enums to #define's, for constants
* prefer direct function call to "ap->ops->foo_bar()", because
ap->ops->foo_bar() is guaranteed to be a constant value known to the
driver. The driver is the entity responsible for the function pointer.
Maybe saves a cycle or two. Not terribly important, but hey, calling
ap->ops->sff_exec_command() from pata_macio_bmdma_setup() is a hot path.
Jeff
^ permalink raw reply
* Re: [PATCH 4/5] libata/sff: Use ops->bmdma_stop instead of ata_bmdma_stop()
From: Jeff Garzik @ 2009-12-03 7:35 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: tj, linux-ide, linuxppc-dev
In-Reply-To: <20091202003629.4342710080C@ozlabs.org>
On 12/01/2009 07:36 PM, Benjamin Herrenschmidt wrote:
> In libata-sff, ata_sff_post_internal_cmd() directly calls ata_bmdma_stop()
> instead of ap->ops->bmdma_stop(). This can be a problem for controllers
> that use their own bmdma_stop for which the generic sff one isn't suitable
>
> Signed-off-by: Benjamin Herrenschmidt<benh@kernel.crashing.org>
> ---
>
> drivers/ata/libata-sff.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> --- linux-work.orig/drivers/ata/libata-sff.c 2009-12-01 17:48:27.000000000 +1100
> +++ linux-work/drivers/ata/libata-sff.c 2009-12-01 17:48:48.000000000 +1100
> @@ -2384,7 +2384,7 @@ void ata_sff_post_internal_cmd(struct at
> ap->hsm_task_state = HSM_ST_IDLE;
>
> if (ap->ioaddr.bmdma_addr)
> - ata_bmdma_stop(qc);
> + ap->ops->bmdma_stop(qc);
>
> spin_unlock_irqrestore(ap->lock, flags);
applied
As we discussed, feel free to carry this in your tree as well. git
should be able to sort it out.
Acked-by: Jeff Garzik <jgarzik@redhat.com>
^ permalink raw reply
* Re: PCI interrupt question
From: Stefan Roese @ 2009-12-03 7:31 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Jeff Hane
In-Reply-To: <1259821316.12651.26.camel@qu102.quarc.com>
Hi Jeff,
On Thursday 03 December 2009 07:21:56 Jeff Hane wrote:
> I'm trying to get interrupts working for my PCI device on a 460ex and
> am having problem. My ISR never triggers.
Which 460EX board is this? Canyonlands or some custom board?
> I'm new to PCI(and ppc) and LDD said that I could read the config reg
> INTURRUPT_LINE to get the interrupt assigned to my PCI device. Well,
> this always reads zero.
>
> After reading through the code it appears that the interrupt is being
> assigned after reading some information out of the device tree and then
> filling in the irg in the pci_dev structure.
Yes. The device tree has to describe the PCI interrupt layout.
> I'm just looking for confirmation that I should be calling request_irq
> with the irq that I found in the pci_dev struct.
Yes.
Canyonlands dts correctly describes the PCI interrupts assignments. If you
have a custom 460EX board, then you probably have a different interrupt routed
to the PCI slot. This needs to be described in your device tree file.
Cheers,
Stefan
^ permalink raw reply
* PCI interrupt question
From: Jeff Hane @ 2009-12-03 6:21 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org
Hello,
I'm trying to get interrupts working for my PCI device on a 460ex and
am having problem. My ISR never triggers.
I'm new to PCI(and ppc) and LDD said that I could read the config reg
INTURRUPT_LINE to get the interrupt assigned to my PCI device. Well,
this always reads zero.
After reading through the code it appears that the interrupt is being
assigned after reading some information out of the device tree and then
filling in the irg in the pci_dev structure.
I'm just looking for confirmation that I should be calling request_irq
with the irq that I found in the pci_dev struct.
thanks,
jeff
^ permalink raw reply
* Re: [v10 PATCH 9/9]: POWER: Enable default_idle when power_save=off
From: Arun R Bharadwaj @ 2009-12-03 6:33 UTC (permalink / raw)
To: Daniel Walker
Cc: linux-arch, linux-acpi, linuxppc-dev, linux-kernel,
Arun Bharadwaj
In-Reply-To: <20091202100346.GJ27251@linux.vnet.ibm.com>
* Arun R Bharadwaj <arun@linux.vnet.ibm.com> [2009-12-02 15:33:46]:
Thanks for running checkpatch on the patch Daniel. Will fix this.
arun
^ permalink raw reply
* Re: MPC5121ADS PowerVR MBX driver on 2.6.31 kernel?
From: Wolfgang Denk @ 2009-12-03 6:23 UTC (permalink / raw)
To: Chen Hongjun-R66092; +Cc: linuxppc-dev, Cristian Axenie
In-Reply-To: <3A45394FD742FA419B760BB8D398F9EDE65FFF@zch01exm26.fsl.freescale.net>
Dear "Chen Hongjun-R66092",
In message <3A45394FD742FA419B760BB8D398F9EDE65FFF@zch01exm26.fsl.freescale.net> you wrote:
>
> The released binary MBX driver is based on kernel 2.6.24, not on 2.6.31.
It is a GPL violation that there is no source code available for it.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Save energy: Drive a smaller shell.
^ permalink raw reply
* Re: [PATCH] powerpc/mm: setting mmaped page cache property through device tree
From: Li Yang @ 2009-12-03 6:15 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: paulus, linux-kernel, linuxppc-dev
In-Reply-To: <0CED0757-67E3-4EAD-A2F7-AB8553559E94@kernel.crashing.org>
On Thu, Dec 3, 2009 at 12:15 PM, Segher Boessenkool
<segher@kernel.crashing.org> wrote:
>>>> The scenario for the first case is that in a multicore system running
>>>> ASMP which means different OS runs on different cores. =C2=A0They migh=
t
>>>> communicate through a shared memory region. =C2=A0The region on every =
OS
>>>> need to be mapped with the same cache perperty to avoid cache paradox.
>>>
>>> This isn't true. =C2=A0In ASMP, you cannot usually do coherency between
>>> the different CPUs at all. =C2=A0Also, in most PowerPC implementations,
>>
>> Coherency can't be achieved with proper configuration and management? =
=C2=A0Why
>> so?
>
> Because different CPUs do not usually speak the same coherency protocol.
>
> However, it occurred to me that what you call ASMP is actually SMP where
> you run different OSes on the various cores?
>
Yup. There might be some confusion on the ASMP definition. But with
multi-core common in the market, new ASMP system may run on SMP-like
hardware.
>>> it is fine if one CPU maps a memory range as coherent while another
>>> maps it as non-coherent; sure, you have to be careful or you will
>>
>> But we do want the shared region to be coherent. =C2=A0So mappings shoul=
d
>> have the same cacheability property.
>
> No, they only need WIMG=3Dxx1x on both sides. =C2=A0Of course, IM=3D11 mi=
ght not
> be a valid combination on your particular CPU, and it probably is better
> for performance to have the RAM cacheable anyway.
Agreed. This patch also makes M bit configurable.
>
>>> So make the memory known to the kernel, just tell the kernel not to
>>> use it. =C2=A0If it's normal system RAM, just put it in the "memory" no=
de
>>> and do a memreserve on it (or do something in your platform code); if
>>> it's some other memory, do a device driver for it, map it there.
>>
>> Your solution is feasible. =C2=A0But the memory allocation is a software
>> configuration. =C2=A0IMHO, it should be better and easier addressed by
>> changing configurations(like mem parameter) rather than the kernel
>> platform code which should address hardware configuration.
>
> Either platform code or some other boot-time code, sure.
>
> The point is, you put the RAM in the device tree, so the kernel can
> know that particular range of physical address space is RAM, even
> if it doesn't use it itself.
If device tree always pass all the memory available, we need to
implement memmap=3D kernel cmdline parameter for powerpc in case the
memory used isn't start at address 0. Maybe it's better that all
these information be passed with kernel parameter rather than device
tree for cross architecture portability. What do you think?
- Leo
^ permalink raw reply
* RE: [PATCH] [SCSI] mpt fusion: Fix 32 bit platforms with 64 bit resources.
From: Desai, Kashyap @ 2009-12-03 5:26 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Pravin Bathija
Cc: linuxppc-dev@ozlabs.org, Moore, Eric, linux-scsi@vger.kernel.org
In-Reply-To: <1259809190.2076.1194.camel@pasglop>
This patch looks OK. Please consider it as ACKed by me on behalf of LSI.
- Kashyap
> -----Original Message-----
> From: linux-scsi-owner@vger.kernel.org [mailto:linux-scsi-
> owner@vger.kernel.org] On Behalf Of Benjamin Herrenschmidt
> Sent: Thursday, December 03, 2009 8:30 AM
> To: Pravin Bathija
> Cc: linux-scsi@vger.kernel.org; linuxppc-dev@ozlabs.org;
> jwboyer@linux.vnet.ibm.com; Moore, Eric
> Subject: Re: [PATCH] [SCSI] mpt fusion: Fix 32 bit platforms with 64 bit
> resources.
>=20
> On Wed, 2009-12-02 at 17:51 -0800, Pravin Bathija wrote:
> > Powerpc 44x uses 36 bit real address while the real address defined
> > in MPT Fusion driver is of type 32 bit. This causes ioremap to fail
> and driver
> > fails to initialize. This fix changes the data types representing
> the real
> > address from unsigned long 32-bit types to resource_size_t which is
> 64-bit. The
> > driver has been tested, the disks get discovered correctly and can
> do IO.
> >
> > Signed-off-by: Pravin Bathija <pbathija@amcc.com>
>=20
> Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
>=20
> James, this one should be good ;-)
>=20
> > Acked-by: Feng Kan <fkan@amcc.com>
> > Acked-by: Fushen Chen <fchen@amcc.com>
> > Acked-by: Loc Ho <lho@amcc.com>
> > Acked-by: Tirumala Reddy Marri <tmarri@amcc.com>
> > Acked-by: Victor Gallardo <vgallardo@amcc.com>
> > ---
> > drivers/message/fusion/mptbase.c | 2 +-
> > 1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/drivers/message/fusion/mptbase.c
> b/drivers/message/fusion/mptbase.c
> > index 5d496a9..9f14a60 100644
> > --- a/drivers/message/fusion/mptbase.c
> > +++ b/drivers/message/fusion/mptbase.c
> > @@ -1511,7 +1511,7 @@ mpt_mapresources(MPT_ADAPTER *ioc)
> > {
> > u8 __iomem *mem;
> > int ii;
> > - unsigned long mem_phys;
> > + resource_size_t mem_phys;
> > unsigned long port;
> > u32 msize;
> > u32 psize;
>=20
>=20
> --
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] powerpc/pseries: Track previous CPPR values to correctly EOI interrupts
From: Mark Nelson @ 2009-12-03 5:07 UTC (permalink / raw)
To: linuxppc-dev
At the moment when we EOI an interrupt we set the CPPR back to 0xFF
regardless of its previous value. This could lead to problems if we
take an interrupt with a priority of 5, but before EOIing it we get
an IPI which has a priority of 4. The problem is that at the moment
when we EOI the IPI we will set the CPPR to 0xFF, but it should
really be set back to 5 (the previous priority).
To keep track of the previous CPPR values we create the xics_cppr
structure that has an array for CPPR values and an index pointing
to the current priority. This can easily grow if new priorities get
added in the future.
This will also be useful because the partition adjunct option of
upcoming machines will update the H_XIRR hcall to accept the CPPR
as a parameter.
Signed-off-by: Mark Nelson <markn@au1.ibm.com>
---
arch/powerpc/platforms/pseries/xics.c | 48 ++++++++++++++++++++++++++++++----
1 file changed, 43 insertions(+), 5 deletions(-)
Index: upstream/arch/powerpc/platforms/pseries/xics.c
===================================================================
--- upstream.orig/arch/powerpc/platforms/pseries/xics.c
+++ upstream/arch/powerpc/platforms/pseries/xics.c
@@ -20,6 +20,7 @@
#include <linux/cpu.h>
#include <linux/msi.h>
#include <linux/of.h>
+#include <linux/percpu.h>
#include <asm/firmware.h>
#include <asm/io.h>
@@ -46,6 +47,12 @@ static struct irq_host *xics_host;
*/
#define IPI_PRIORITY 4
+/* The least favored priority */
+#define LOWEST_PRIORITY 0xFF
+
+/* The number of priorities defined above */
+#define MAX_NUM_PRIORITIES 3
+
static unsigned int default_server = 0xFF;
static unsigned int default_distrib_server = 0;
static unsigned int interrupt_server_size = 8;
@@ -56,6 +63,12 @@ static int ibm_set_xive;
static int ibm_int_on;
static int ibm_int_off;
+struct xics_cppr {
+ unsigned char stack[MAX_NUM_PRIORITIES];
+ int index;
+};
+
+static DEFINE_PER_CPU(struct xics_cppr, xics_cppr);
/* Direct hardware low level accessors */
@@ -284,6 +297,16 @@ static inline unsigned int xics_xirr_vec
return xirr & 0x00ffffff;
}
+static void get_irq_update_cppr(unsigned int vec)
+{
+ struct xics_cppr *os_cppr = &__get_cpu_var(xics_cppr);
+
+ if (vec == XICS_IPI)
+ os_cppr->stack[++os_cppr->index] = IPI_PRIORITY;
+ else
+ os_cppr->stack[++os_cppr->index] = DEFAULT_PRIORITY;
+}
+
static unsigned int xics_get_irq_direct(void)
{
unsigned int xirr = direct_xirr_info_get();
@@ -294,8 +317,10 @@ static unsigned int xics_get_irq_direct(
return NO_IRQ;
irq = irq_radix_revmap_lookup(xics_host, vec);
- if (likely(irq != NO_IRQ))
+ if (likely(irq != NO_IRQ)) {
+ get_irq_update_cppr(vec);
return irq;
+ }
/* We don't have a linux mapping, so have rtas mask it. */
xics_mask_unknown_vec(vec);
@@ -315,8 +340,10 @@ static unsigned int xics_get_irq_lpar(vo
return NO_IRQ;
irq = irq_radix_revmap_lookup(xics_host, vec);
- if (likely(irq != NO_IRQ))
+ if (likely(irq != NO_IRQ)) {
+ get_irq_update_cppr(vec);
return irq;
+ }
/* We don't have a linux mapping, so have RTAS mask it. */
xics_mask_unknown_vec(vec);
@@ -326,12 +353,19 @@ static unsigned int xics_get_irq_lpar(vo
return NO_IRQ;
}
+static unsigned char eoi_update_and_get_cppr(void)
+{
+ struct xics_cppr *os_cppr = &__get_cpu_var(xics_cppr);
+
+ return os_cppr->stack[--os_cppr->index];
+}
+
static void xics_eoi_direct(unsigned int virq)
{
unsigned int irq = (unsigned int)irq_map[virq].hwirq;
iosync();
- direct_xirr_info_set((0xff << 24) | irq);
+ direct_xirr_info_set((eoi_update_and_get_cppr() << 24) | irq);
}
static void xics_eoi_lpar(unsigned int virq)
@@ -339,7 +373,7 @@ static void xics_eoi_lpar(unsigned int v
unsigned int irq = (unsigned int)irq_map[virq].hwirq;
iosync();
- lpar_xirr_info_set((0xff << 24) | irq);
+ lpar_xirr_info_set((eoi_update_and_get_cppr() << 24) | irq);
}
static int xics_set_affinity(unsigned int virq, const struct cpumask *cpumask)
@@ -746,6 +780,10 @@ void __init xics_init_IRQ(void)
static void xics_set_cpu_priority(unsigned char cppr)
{
+ struct xics_cppr *os_cppr = &__get_cpu_var(xics_cppr);
+ os_cppr->index = 0;
+ os_cppr->stack[os_cppr->index] = cppr;
+
if (firmware_has_feature(FW_FEATURE_LPAR))
lpar_cppr_info(cppr);
else
@@ -772,7 +810,7 @@ static void xics_set_cpu_giq(unsigned in
void xics_setup_cpu(void)
{
- xics_set_cpu_priority(0xff);
+ xics_set_cpu_priority(LOWEST_PRIORITY);
xics_set_cpu_giq(default_distrib_server, 1);
}
^ permalink raw reply
* Re: Ethernet issues with lite5200 board from linux-2.6.31
From: Yogesh Chaudhari @ 2009-12-03 4:14 UTC (permalink / raw)
To: LKML
Cc: Robin Gareus, rt-users, Fernando Lopez-Lezcano, Peter Zijlstra,
Frank Rowand, Philippe Reynes, Mark Knecht, Steven Rostedt,
Sven-Thorsten Dietrich, Clark Williams, Darren Hart, Will Schmidt,
Jon Masters, John Kacur, Ingo Molnar, Jan Blunck, Gregory Haskins,
linuxppc-dev
In-Reply-To: <fa686aa40911300759h153b3300uc54b5d1871bfc839@mail.gmail.com>
2009/11/30 Grant Likely <grant.likely@secretlab.ca>:
> On Mon, Nov 30, 2009 at 2:50 AM, Yogesh Chaudhari <mr.yogesh@gmail.com> w=
rote:
>> Hello,
>> =A0 =A0 =A0 =A0 I am running linux kernel with rt patch on embedded boar=
d
>> based on lite5200 eval board. From linux-2.6.31 release, in which the
>> mdio patch has gone inside, =A0the fec ethernet does not come up on this
>> board. I get the following message at startup:
>> mpc52xx MII bus: probed
>> mdio_bus f0003000: error probing PHY at address 1
>>
>>
>> After the bootup if I try to do a ifconfig I get the message:
>> net eth2: of_phy_connect failed
>>
>>
>> If I change the value of reg in dts file (lite5200.dts) to 0 then this
>> ethernet comes up. However upto this kernel version, this was not
>> required.
>>
>> Ethernet does not come up on board with original lite5200.dts file
>
> Is your board based on the Lite5200 or the Lite5200B? =A0The phys are at
> different addresses on those two revisions of the board. =A0There is a
> different .dts file for each board.
>
>> phy0: ethernet-phy@1 {
>> =A0=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0reg =
=3D <1>;
>> =A0=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0};
>>
>> Ethernet comes up on board with this change
>> phy0: ethernet-phy@1 {
>> =A0=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0reg =
=3D <0>;
>> =A0=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0};
>
> Some PHYs treat address 0 as the 'broadcast' address. =A0You need to
> fill in this field (and modify the ethernet-phy@<address> node name)
> to reflect the address that your phy is actually at.
>
> g.
>
I have tried the same with the latest kernel both with and without
rt, but with the same end result. I have checked that the mpc52xx fec
driver was changed from 2.6.31 version but I am not able to point
where this error is coming up from and how changing the reg value in
dts (which is not required till previous versions) is solving this.
^ permalink raw reply
* Re: [PATCH] powerpc/mm: setting mmaped page cache property through device tree
From: Segher Boessenkool @ 2009-12-03 4:15 UTC (permalink / raw)
To: Li Yang; +Cc: paulus, linux-kernel, linuxppc-dev
In-Reply-To: <2a27d3730912012225h3deab5dao2211bc404d247192@mail.gmail.com>
>>> The scenario for the first case is that in a multicore system
>>> running
>>> ASMP which means different OS runs on different cores. They might
>>> communicate through a shared memory region. The region on every OS
>>> need to be mapped with the same cache perperty to avoid cache
>>> paradox.
>>
>> This isn't true. In ASMP, you cannot usually do coherency between
>> the different CPUs at all. Also, in most PowerPC implementations,
>
> Coherency can't be achieved with proper configuration and
> management? Why so?
Because different CPUs do not usually speak the same coherency protocol.
However, it occurred to me that what you call ASMP is actually SMP where
you run different OSes on the various cores?
>> it is fine if one CPU maps a memory range as coherent while another
>> maps it as non-coherent; sure, you have to be careful or you will
>
> But we do want the shared region to be coherent. So mappings should
> have the same cacheability property.
No, they only need WIMG=xx1x on both sides. Of course, IM=11 might not
be a valid combination on your particular CPU, and it probably is better
for performance to have the RAM cacheable anyway.
>> So make the memory known to the kernel, just tell the kernel not to
>> use it. If it's normal system RAM, just put it in the "memory" node
>> and do a memreserve on it (or do something in your platform code); if
>> it's some other memory, do a device driver for it, map it there.
>
> Your solution is feasible. But the memory allocation is a software
> configuration. IMHO, it should be better and easier addressed by
> changing configurations(like mem parameter) rather than the kernel
> platform code which should address hardware configuration.
Either platform code or some other boot-time code, sure.
The point is, you put the RAM in the device tree, so the kernel can
know that particular range of physical address space is RAM, even
if it doesn't use it itself.
Segher
^ permalink raw reply
* Re: [RFC PATCH v3 3/3] powerpc: gamecube/wii: early debugging using usbgecko
From: Segher Boessenkool @ 2009-12-03 4:06 UTC (permalink / raw)
To: Richard Holden; +Cc: Albert Herranz, linuxppc-dev
In-Reply-To: <40854686-7CD0-432D-B31C-0D5DF2DADBF9@gmail.com>
>>> you may want to rename the ug_ prefix, it took me a while looking
>>> back
>>> and forth through the patch to convince myself it wasn't a typo.
>>
>> What's wrong with ug_ ? (ug = (u)sb(g)ecko)
>
> At first look I thought it was a typo of udbg_early_remap. I prefer
> the longer names although we could use gecko_early_remap unless the
> gecko prefix conflicts with anything else.
All these names are local to this file. Shorter names are nicer than
longer names :-)
> If there is not going to be a non usb gecko then there is no need
> to have usb in the prefix.
There already is a Gecko device that plugs into the memory card slot
as well. It is older than the USB Gecko, and much more widespread.
It doesn't give you a serial connection, it's memory only.
Segher
^ permalink raw reply
* Re: [PATCH] [SCSI] mpt fusion: Fix 32 bit platforms with 64 bit resources.
From: Benjamin Herrenschmidt @ 2009-12-03 2:59 UTC (permalink / raw)
To: Pravin Bathija; +Cc: linuxppc-dev, Eric.Moore, linux-scsi
In-Reply-To: <1259805106-23636-1-git-send-email-pbathija@amcc.com>
On Wed, 2009-12-02 at 17:51 -0800, Pravin Bathija wrote:
> Powerpc 44x uses 36 bit real address while the real address defined
> in MPT Fusion driver is of type 32 bit. This causes ioremap to fail and driver
> fails to initialize. This fix changes the data types representing the real
> address from unsigned long 32-bit types to resource_size_t which is 64-bit. The
> driver has been tested, the disks get discovered correctly and can do IO.
>
> Signed-off-by: Pravin Bathija <pbathija@amcc.com>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
James, this one should be good ;-)
> Acked-by: Feng Kan <fkan@amcc.com>
> Acked-by: Fushen Chen <fchen@amcc.com>
> Acked-by: Loc Ho <lho@amcc.com>
> Acked-by: Tirumala Reddy Marri <tmarri@amcc.com>
> Acked-by: Victor Gallardo <vgallardo@amcc.com>
> ---
> drivers/message/fusion/mptbase.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/message/fusion/mptbase.c b/drivers/message/fusion/mptbase.c
> index 5d496a9..9f14a60 100644
> --- a/drivers/message/fusion/mptbase.c
> +++ b/drivers/message/fusion/mptbase.c
> @@ -1511,7 +1511,7 @@ mpt_mapresources(MPT_ADAPTER *ioc)
> {
> u8 __iomem *mem;
> int ii;
> - unsigned long mem_phys;
> + resource_size_t mem_phys;
> unsigned long port;
> u32 msize;
> u32 psize;
^ permalink raw reply
* [PATCH] [SCSI] mpt fusion: Fix 32 bit platforms with 64 bit resources.
From: Pravin Bathija @ 2009-12-03 1:51 UTC (permalink / raw)
To: linux-scsi; +Cc: linuxppc-dev, Eric.Moore, Pravin Bathija
Powerpc 44x uses 36 bit real address while the real address defined
in MPT Fusion driver is of type 32 bit. This causes ioremap to fail and driver
fails to initialize. This fix changes the data types representing the real
address from unsigned long 32-bit types to resource_size_t which is 64-bit. The
driver has been tested, the disks get discovered correctly and can do IO.
Signed-off-by: Pravin Bathija <pbathija@amcc.com>
Acked-by: Feng Kan <fkan@amcc.com>
Acked-by: Fushen Chen <fchen@amcc.com>
Acked-by: Loc Ho <lho@amcc.com>
Acked-by: Tirumala Reddy Marri <tmarri@amcc.com>
Acked-by: Victor Gallardo <vgallardo@amcc.com>
---
drivers/message/fusion/mptbase.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/message/fusion/mptbase.c b/drivers/message/fusion/mptbase.c
index 5d496a9..9f14a60 100644
--- a/drivers/message/fusion/mptbase.c
+++ b/drivers/message/fusion/mptbase.c
@@ -1511,7 +1511,7 @@ mpt_mapresources(MPT_ADAPTER *ioc)
{
u8 __iomem *mem;
int ii;
- unsigned long mem_phys;
+ resource_size_t mem_phys;
unsigned long port;
u32 msize;
u32 psize;
--
1.5.5
^ permalink raw reply related
* RE: MPC5121ADS PowerVR MBX driver on 2.6.31 kernel?
From: Chen Hongjun-R66092 @ 2009-12-03 0:27 UTC (permalink / raw)
To: Cristian Axenie, linuxppc-dev
In-Reply-To: <9c789a000912021004l5dda0ee8r77a21764e035ff35@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 749 bytes --]
The released binary MBX driver is based on kernel 2.6.24, not on 2.6.31.
Regards,
Hongjun
________________________________
From:
linuxppc-dev-bounces+hong-jun.chen=freescale.com@lists.ozlabs.org
[mailto:linuxppc-dev-bounces+hong-jun.chen=freescale.com@lists.ozlabs.or
g] On Behalf Of Cristian Axenie
Sent: Thursday, December 03, 2009 2:05 AM
To: linuxppc-dev@ozlabs.org
Subject: MPC5121ADS PowerVR MBX driver on 2.6.31 kernel?
Hi all!
I would like to know if there is someone that tested the MBX
driver for the PowerVR graphic chip in MPC5121 ?
It seems that on kernel 2.6.21 works fine but it fails on 2.6.31
!
I'm using wrlinux as the build environment !
Any opinions are welcome !
Best !
[-- Attachment #2: Type: text/html, Size: 1768 bytes --]
^ permalink raw reply
* Re: [RFC PATCH v2 09/11] powerpc: gamecube/wii: flipper interrupt controller support
From: Albert Herranz @ 2009-12-02 23:29 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1259787401.2076.1159.camel@pasglop>
Benjamin Herrenschmidt wrote:
> On Tue, 2009-12-01 at 20:48 +0100, Albert Herranz wrote:
>> This -1 should be NO_IRQ too.
>> I'll fix this in the next version.
>
> No. The number you pass here is not a linux virq number, but a number in
> your HW numbering space that never represents a valid IRQ. In your case
> 0 (NO_IRQ is deprecated anyways) is a valid HW interrupt number. However
> -1 sounds good.
>
> So your existing code is fine.
>
Oh. Good to know.
Then I need to fix the other PIC driver :)
> Cheers,
> Ben.
>
Thanks,
Albert
^ permalink raw reply
* Re: Recommended functions for accessing internal registers
From: Benjamin Herrenschmidt @ 2009-12-02 20:57 UTC (permalink / raw)
To: Fortini Matteo; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <4B1547E5.6050301@mta.it>
On Tue, 2009-12-01 at 17:44 +0100, Fortini Matteo wrote:
> I see that throughout the kernel source, internal PPC registers are
> accessed through [in|out]_be[32|16|8]() functions. However, they are
> translated into 3 inline assembly instructions, one of which is an
> isync, which has a huge performance hit.
> I tried using readl_be() which seems to be the right function according
> to the Documentation/ dir, but it is translated directly to in_be32(),
> so no luck.
>
> Is it really necessary to use all those instructions? I know I could use
> a (volatile u32 *) variable to avoid subsequent read/writes to be
> optimized out, but it seems to be a deprecated use.
There are good reasons why the accessors contain those barriers. What
are you doing that would be performance critical enough for those to be
a problem ?
Cheers,
Ben.
^ permalink raw reply
* Re: [RFC PATCH v2 09/11] powerpc: gamecube/wii: flipper interrupt controller support
From: Benjamin Herrenschmidt @ 2009-12-02 20:56 UTC (permalink / raw)
To: Albert Herranz; +Cc: linuxppc-dev
In-Reply-To: <4B15731E.3000109@yahoo.es>
On Tue, 2009-12-01 at 20:48 +0100, Albert Herranz wrote:
>
> This -1 should be NO_IRQ too.
> I'll fix this in the next version.
No. The number you pass here is not a linux virq number, but a number in
your HW numbering space that never represents a valid IRQ. In your case
0 (NO_IRQ is deprecated anyways) is a valid HW interrupt number. However
-1 sounds good.
So your existing code is fine.
Cheers,
Ben.
^ permalink raw reply
* Re: EP440XS board boot problem(Note:similart to Sequoia)
From: Wolfgang Denk @ 2009-12-02 20:09 UTC (permalink / raw)
To: Allan Wang; +Cc: linuxppc-dev
In-Reply-To: <880531.39933.qm@web52905.mail.re2.yahoo.com>
Dear Allan Wang,
In message <880531.39933.qm@web52905.mail.re2.yahoo.com> you wrote:
>
> Thank you for your help. My answer to your questions are between the lines.
> Attached is the dts file I use.
No, there is no attachment.
> Which exact version of U-Boot are you running on this board?
>
> => version
>
> U-Boot 1.1.6 (Oct 25 2009 - 13:26:41)
Um... why don't you update? This is really historic stuff...
> What is your exact boot command?
>
> I tftp the cuImage to address 0x200000 and bootm to boot.
>
> Which boot arguments do you pass to the kernel?
>
> bootargs=$(bootargs) console=ttyS0,$(baudrate)
Please provide complete answers, and not only the snippets that seem
important to you. For example, what is the "$(bootargs)" above?
Maybe you provide a full boot log right from reset/power on, including
the output of the "printenv" command on your system.
> The u-boot sets it to 115.2k. the dts file is set to 115.2k. Here is the bo
> ot parameter:
> baudrate=115200
Arghhh.. Please provide the actual output fdrom your system, not just
some parts you copy.
> What does your device tree look like?
>
> I attached my dts file.
No, it's missing.
> > 2. It pakics when mounting the root file system(NFS):
> > (gdb) bt
> > #0 panic (fmt=0xc0290e94 "VFS: Unable to mount root fs on %s")
>
> So what is the "%s" argument here? Which sort of root file system are
> you trying to mount - NFS, ramdisk, UBIFS, ... ?
>
> I try to use NFS for the root file system.
Then you can also run a packet sniffer (like wireshark) to see if any
NFS requests actually get sent to the targte, resp. where it stops).
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Romulan women are not like Vulcan females. We are not dedicated to
pure logic and the sterility of non-emotion.
-- Romulan Commander, "The Enterprise Incident",
stardate 5027.3
^ permalink raw reply
* Re: MPC5121ADS PowerVR MBX driver on 2.6.31 kernel?
From: Wolfgang Denk @ 2009-12-02 20:05 UTC (permalink / raw)
To: Cristian Axenie; +Cc: linuxppc-dev
In-Reply-To: <9c789a000912021004l5dda0ee8r77a21764e035ff35@mail.gmail.com>
Dear Cristian Axenie,
In message <9c789a000912021004l5dda0ee8r77a21764e035ff35@mail.gmail.com> you wrote:
>
> I would like to know if there is someone that tested the MBX driver for the
> PowerVR graphic chip in MPC5121 ?
> It seems that on kernel 2.6.21 works fine but it fails on 2.6.31 !
You probably have to rebuild it from the source code for this new
kernel version.
> I'm using wrlinux as the build environment !
Maybe you ask WRS to provide matching binaries, then? [Note that
woever provides the binaries also has to provide the sources; the
kernel is GPL after all...]
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
If the car industry behaved like the computer industry over the last
30 years, a Rolls-Royce would cost $5, get 300 miles per gallon, and
blow up once a year killing all passengers inside.
^ 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