* 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
* MPC5121ADS PowerVR MBX driver on 2.6.31 kernel?
From: Cristian Axenie @ 2009-12-02 18:04 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 267 bytes --]
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: 300 bytes --]
^ permalink raw reply
* Re: [v10 PATCH 9/9]: POWER: Enable default_idle when power_save=off
From: Daniel Walker @ 2009-12-02 17:41 UTC (permalink / raw)
To: arun
Cc: linux-arch, Peter Zijlstra, Venkatesh Pallipadi, linux-kernel,
linux-acpi, Ingo Molnar, linuxppc-dev
In-Reply-To: <20091202100346.GJ27251@linux.vnet.ibm.com>
On Wed, 2009-12-02 at 15:33 +0530, Arun R Bharadwaj wrote:
> +int boot_option_idle_override = 0;
> +
Doesn't need to be set to zero AFAIK, since we do a mass initialization
to zero during boot up. Did you notice some type of failure when you
didn't initialize that to zero?
(checkpatch output below..)
--
ERROR: do not initialise externals to 0 or NULL
#97: FILE: arch/powerpc/kernel/idle.c:43:
+int boot_option_idle_override = 0;
total: 1 errors, 0 warnings, 0 checks, 31 lines checked
Your patch has style problems, please review. If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
^ permalink raw reply
* Re: [PATCH v2] ppc440spe-adma: adds updated ppc440spe adma driver
From: Anatolij Gustschin @ 2009-12-02 14:16 UTC (permalink / raw)
To: Dan Williams
Cc: linux-raid@vger.kernel.org, linuxppc-dev@ozlabs.org,
Yuri Tikhonov, wd@denx.de, dzu@denx.de
In-Reply-To: <4B1465C1.90606@intel.com>
Dan Williams <dan.j.williams@intel.com> wrote:
> Anatolij Gustschin wrote:
> > This patch adds new version of the PPC440SPe ADMA driver.
> >
> > Signed-off-by: Anatolij Gustschin <agust@denx.de>
> > Signed-off-by: Yuri Tikhonov <yur@emcraft.com>
>
> [minor] Sign-offs are typically in delivery path order, so yours would
> appear last.
Ok, I'll fix this in the next patch version.
> [..]
> > drivers/dma/ppc440spe/ppc440spe-adma.c | 5015 ++++++++++++++++++++
> > drivers/dma/ppc440spe/ppc440spe_adma.h | 195 +
> > drivers/dma/ppc440spe/ppc440spe_dma.h | 223 +
> > drivers/dma/ppc440spe/ppc440spe_xor.h | 110 +
>
> I belong to the school of thought that says something along the lines of
> "don't duplicate the directory path in the filename". You seem to have
> copied the iop-adma driver's inconsistent use of '-' and '_' let's not
> carry that forward, i.e. looking for a changelog like:
>
> drivers/dma/ppc440spe/adma.c | 5015 ++++++++++++++++++++
> drivers/dma/ppc440spe/adma.h | 195 +
> drivers/dma/ppc440spe/dma.h | 223 +
> drivers/dma/ppc440spe/xor.h | 110 +
Ok, it indeed looks much better. I think I should use 'ppc4xx' as driver
directory name now as we need to extend the driver to also support 460EX
later.
> > +/**
> > + * ppc440spe_adma_prep_dma_pqzero_sum - prepare CDB group for
> > + * a PQ_ZERO_SUM operation
> > + */
> > +static struct dma_async_tx_descriptor *ppc440spe_adma_prep_dma_pqzero_sum(
> > + struct dma_chan *chan, dma_addr_t *pq, dma_addr_t *src,
> > + unsigned int src_cnt, const unsigned char *scf, size_t len,
> > + enum sum_check_flags *pqres, unsigned long flags)
> > +{
> > + struct ppc440spe_adma_chan *ppc440spe_chan;
> > + struct ppc440spe_adma_desc_slot *sw_desc, *iter;
> > + dma_addr_t pdest, qdest;
> > + int slot_cnt, slots_per_op, idst, dst_cnt;
> > +
> > + if (unlikely(!len))
> > + return NULL;
> > + if (len > PAGE_SIZE)
> > + return NULL;
>
> This won't work, as currently we'll end up in an infinite loop in
> async_syndrome_val() because all descriptor allocation failures are
> assumed to be time-limited. The code just issues any pending operations
> and waits for descriptor resources to become available.
Yes, in the case 'len > PAGE_SIZE' this is true. I didn't look at
async_syndrome_val() code again before making this change and while
raid6 testing after this change I didn't notice any issues as passed
'len' was always equal to PAGE_SIZE. I must do this 'len' check while
looking for a suitable channel for pq_val operation so that there
will be a fallback to synchronous path in the case passed 'len' is
greater than PAGE_SIZE. I'll fix this.
> What this comes down to is that ppc440spe_adma is essentially fibbing
> about its support for the pq_val operation. I think a more generic
> solution would be to advertise to the async_tx api that the driver has
> per channel temporary buffers that can be used to store intermediate pq
> results and let the async_tx api handle the emulation using its
> knowledge of ->max_pq. We would also need a mechanism for the async_tx
> api to lock out other requesters of the temporary buffer until a
> coherent set of descriptors referencing those temporary buffers has been
> submitted to the driver. This would help other drivers like mv_xor
> which has no val support and ioatdma which currently can only validate
> up to 8 sources asynchronously.
>
> Can you clarify what ppc440spe-adma supports in this area? It looks
> like it has some hardware support for result checking but always needs
> to write p and/or q somewhere? Some devices may be able to do the final
> comparison against the original parity values asynchronously while
> others may need to do it synchronously in software. These details can
> be handled at the async_tx api level.
ppc440spe-adma supports checking against the original parity values
asynchronously using following approach:
original parity values (as passed to async_syndrome_val()) are copied to
channels temporary p and/or q buffer(s). Then the generation of the
syndrome is performed using this temporary buffer(s) as destination(s).
When DMA engine generates p and/or q parity, it always performs XOR
operation with the destination p and/or q buffer(s) content while
writing to this buffer(s). In the case that the syndrome is valid,
the destination p and/or q buffer(s) will be cleared (set to zero)
after syndrome validation. This is checked by the subsequent DMA
DATACHECK operation which compares a buffer with a data pattern and
stores the comparison result in the Completion Status FIFO. We queue
a subsequent DMA DATACHECK descriptor for this check operation. The
temporary buffers can be immediately re-used, they do not store a
result a subsequent async_tx operation depends on. I think this is
still much better than doing the validation synchronously in software.
Best regards,
Anatolij
^ permalink raw reply
* MPC8640D second core initialization
From: Thirumalai @ 2009-12-02 12:39 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, linux-kernel, u-boot
Hi Kumar,
I am using 2009-06 u-boot for MPC8640D based custom board. I just
want to know whether the second core of MPC8640D is kicked off automatically
or will it required by the user to kick[like mpc85xx/mp.c]. Also if am
enabling the CONFIG_MP macro and CONFIG_NUM_CPUS as 2, then the reset
command of the target is not working(means board is getting hanged). I have
mentioned the value of CONFIG_SYS_SCRATCH_VA as 0xf5000000.
Also when i try to boot linux using this configuration i was getting into
kernel panic.
## Current stack ends at 0x3fa91a08
## Booting kernel from Legacy Image at 00400000 ...
Image Name: Linux-2.6.30-dpvpx0689
Created: 2009-12-01 4:45:09 UTC
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 2307361 Bytes = 2.2 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
## Flattened Device Tree blob at 04000000
Booting using the fdt blob at 0x4000000
Uncompressing Kernel Image ... OK
Loading Device Tree to 007fa000, end 007ff150 ... OK
## Transferring control to Linux (at address 00000000) ...
Booting using OF flat tree...
Using DPVPX0689 machine description
Total memory = 1024MB; using 2048kB for hash table (at afe00000)
Linux version 2.6.30-dpvpx0689 (root@localhost.localdomain) (gcc version
4.0.0 (DENX ELDK 4.0 4.0.0)) #70 SMP Tue Dec 1 10:14:07 IST 2009
Found legacy serial port 0 for /soc@f6000000/serial@4500
mem=f6004500, taddr=f6004500, irq=0, clk=400000000, speed=0
Found legacy serial port 1 for /soc@f6000000/serial@4600
mem=f6004600, taddr=f6004600, irq=0, clk=400000000, speed=0
CPU maps initialized for 1 thread per core
(thread shift is 0)
console [udbg0] enabled
setup_arch: bootmem
dpvpx0689_setup_arch()
Found FSL PCI host bridge at 0x00000000f6008000. Firmware bus number: 0->15
PCI host bridge /pcie@f6008000 ranges:
MEM 0x0000000080000000..0x000000009fffffff -> 0x0000000080000000
IO 0x00000000f8000000..0x00000000fbffffff -> 0x0000000000000000
Single Board Computers from Data Patterns
Ported & Developed By COTS DIVISION
arch: exit
Top of RAM: 0x40000000, Total RAM: 0x40000000
Memory hole size: 0MB
Zone PFN ranges:
DMA 0x00000000 -> 0x00030000
Normal 0x00030000 -> 0x00030000
HighMem 0x00030000 -> 0x00040000
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
0: 0x00000000 -> 0x00040000
On node 0 totalpages: 262144
free_area_init_node: node 0, pgdat a047d1c0, node_mem_map a07fd000
DMA zone: 1536 pages used for memmap
DMA zone: 0 pages reserved
DMA zone: 195072 pages, LIFO batch:31
HighMem zone: 512 pages used for memmap
HighMem zone: 65024 pages, LIFO batch:15
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 260096
Kernel command line: root=/dev/nfs rw nfsroot=10.5.18.3:/ppc/netfs/fc5fs/
ip=10.5.18.230:10.5.18.3:10.5.18.3:255.0.0.0:DPVPX0689:eth0:off
console=ttyS0,115200
NR_IRQS:512
mpic: Setting up MPIC " MPIC " version 1.2 at f6040000, max 2 CPUs
mpic: ISU size: 256, shift: 8, mask: ff
mpic: Initializing for 256 sources
PID hash table entries: 4096 (order: 12, 16384 bytes)
time_init: decrementer frequency = 100.000000 MHz
time_init: processor frequency = 800.000000 MHz
clocksource: timebase mult[2800000] shift[22] registered
clockevent: decrementer mult[1999] shift[16] cpu[0]
Console: colour dummy device 80x25
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
High memory: 262140k
Memory: 1031504k/1048576k available (4444k kernel code, 16252k reserved,
160k data, 169k bss, 200k init)
Kernel virtual memory layout:
* 0xfffe0000..0xfffff000 : fixmap
* 0xff800000..0xffc00000 : highmem PTEs
* 0xfe7ed000..0xff800000 : early ioremap
* 0xd1000000..0xfe7ed000 : vmalloc & ioremap
Calibrating delay loop... 199.68 BogoMIPS (lpj=99840)
Mount-cache hash table entries: 512
mpic: requesting IPIs ...
Processor 1 found.
clockevent: decrementer mult[1999] shift[16] cpu[1]
Brought up 2 CPUs
Unable to handle kernel paging request for data at address 0x00000004
Faulting instruction address: 0xa0023e10
Oops: Kernel access of bad area, sig: 11 [#1]
SMP NR_CPUS=2 DPVPX0689
Modules linked in:
NIP: a0023e10 LR: a0023dd0 CTR: 00000000
REGS: cf841e90 TRAP: 0300 Not tainted (2.6.30-dpvpx0689)
MSR: 00009032 <EE,ME,IR,DR> CR: 24004028 XER: 20000000
DAR: 00000004, DSISR: 40000000
TASK = cf83f930[1] 'swapper' THREAD: cf840000 CPU: 0
GPR00: 00000000 cf841f40 cf83f930 00000000 00000000 00000000 cf841f50
00000000
GPR08: 00000000 00000000 00000002 a10018f4 22004082 ffffffff 3fee6c00
3ff94000
GPR16: ffffffbf ffbf7bff 00000000 00000000 00000000 cf83a800 a10018e8
a0491224
GPR24: a0490000 a04558f8 00000000 cf801f20 a1006070 a10018e8 a10018f8
00000000
NIP [a0023e10] __build_sched_domains+0x354/0x464
LR [a0023dd0] __build_sched_domains+0x314/0x464
Call Trace:
[cf841f40] [a0023b98] __build_sched_domains+0xdc/0x464 (unreliable)
[cf841f90] [a04326ec] sched_init_smp+0x88/0x1e8
[cf841fc0] [a0425a40] kernel_init+0x148/0x1f0
[cf841ff0] [a00131f8] kernel_thread+0x4c/0x68
Instruction dump:
813e0008 2f9c0000 90090004 419e00d4 801e0034 70090100 40820010 801c0034
70090280 408200bc 83fc0008 83be0008 <807f0004> 801d0004 7c630214 907d0004
---[ end trace 31fd0ba7d8756001 ]---
Kernel panic - not syncing: Attempted to kill init!
Rebooting in 180 seconds..
Kindly suggest me what might be the error.
Thank you,
T.
^ permalink raw reply
* Re: [PATCH 3/5] powerpc/macio: Rework hotplug media bay support
From: Sergei Shtylyov @ 2009-12-02 12:08 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: tj, linux-ide, linuxppc-dev, jeff
In-Reply-To: <20091202003628.CF4321007E0@ozlabs.org>
Hello.
Benjamin Herrenschmidt wrote:
> The hotplug mediabay has tendrils deep into drivers/ide code
> which makes a libata port reather difficult. In addition it's
> ugly and could be done better.
>
> This reworks the interface between the mediabay and the rest
> of the world so that:
>
> - Any macio_driver can now have a mediabay_event callback
> which will be called when that driver sits on a mediabay and
> it's been either plugged or unplugged. The device type is
> passed as an argument. We can now move all the IDE cruft
> into the IDE driver itself
>
> - A check_media_bay() function can be used to take a peek
> at the type of device currently in the bay if any, a cleaner
> variant of the previous function with the same name.
>
> - A pair of lock/unlock functions are exposed to allow the
> IDE driver to block the hotplug callbacks during the initial
> setup and probing of the bay in order to avoid nasty race
> conditions.
>
> - The mediabay code no longer needs to spin on the status
> register of the IDE interface when it detects an IDE device,
> this is done just fine by the IDE code itself
>
> Overall, less code, simpler, and allows for another driver
> than our old drivers/ide based one.
>
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>
Some grammar/style nitpicking...
> Index: linux-work/arch/powerpc/include/asm/mediabay.h
> ===================================================================
> --- linux-work.orig/arch/powerpc/include/asm/mediabay.h 2009-12-01 17:57:00.000000000 +1100
> +++ linux-work/arch/powerpc/include/asm/mediabay.h 2009-12-01 18:00:28.000000000 +1100
> @@ -17,26 +17,31 @@
> #define MB_POWER 6 /* media bay contains a Power device (???) */
> #define MB_NO 7 /* media bay contains nothing */
>
> -/* Number of bays in the machine or 0 */
> -extern int media_bay_count;
> +struct macio_dev;
>
> -#ifdef CONFIG_BLK_DEV_IDE_PMAC
> -#include <linux/ide.h>
> +#ifdef CONFIG_PMAC_MEDIABAY
>
> -int check_media_bay_by_base(unsigned long base, int what);
> -/* called by IDE PMAC host driver to register IDE controller for media bay */
> -int media_bay_set_ide_infos(struct device_node *which_bay, unsigned long base,
> - int irq, ide_hwif_t *hwif);
> -
> -int check_media_bay(struct device_node *which_bay, int what);
> +/* Check the content type of the bay, returns MB_NO if the bay is still
> + * transitionning
> + */
>
Only "transitioning".
>
> -int check_media_bay_by_base(unsigned long base, int what)
> +int check_media_bay(struct macio_dev *baydev)
> {
> - int i;
> + struct media_bay_info* bay;
> + int id;
>
> - for (i=0; i<media_bay_count; i++)
> - if (media_bays[i].mdev && base == (unsigned long) media_bays[i].cd_base) {
> - if ((what == media_bays[i].content_id) && media_bays[i].state == mb_up)
> - return 0;
> - media_bays[i].cd_index = -1;
> - return -EINVAL;
> - }
> + if (baydev == NULL)
> + return MB_NO;
>
> - return -ENODEV;
> + /* This returns an instant snapshot, not locking, sine
>
Only "since".
> Index: linux-work/drivers/block/swim3.c
> ===================================================================
> --- linux-work.orig/drivers/block/swim3.c 2009-12-01 17:57:00.000000000 +1100
> +++ linux-work/drivers/block/swim3.c 2009-12-01 18:00:28.000000000 +1100
>
[...]
> @@ -303,14 +303,13 @@ static int swim3_readbit(struct floppy_s
> static void do_fd_request(struct request_queue * q)
> {
> int i;
> - for(i=0;i<floppy_count;i++)
> - {
> -#ifdef CONFIG_PMAC_MEDIABAY
> - if (floppy_states[i].media_bay &&
> - check_media_bay(floppy_states[i].media_bay, MB_FD))
> +
> + for(i=0; i<floppy_count; i++) {
>
You could insert spaces around operators here, while at it...
MBR, Sergei
^ permalink raw reply
* Re: [PATCH 5/5] libata/drivers: Add pata_macio, driver Apple PowerMac/PowerBook IDE controller
From: Andreas Schwab @ 2009-12-02 11:44 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: tj, linux-ide, linuxppc-dev, jeff
In-Reply-To: <20091202003630.29919100851@ozlabs.org>
Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:
> 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.
Thanks, this works fine now, including suspend *and* resume. :-)
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ 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