* Re: [PATCH] 86xx: Enable the AC97 interface on 8641D board.
From: Olof Johansson @ 2007-05-03 17:26 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <1178209046.17201.55.camel@ld0161-tx32>
On Thu, May 03, 2007 at 11:17:26AM -0500, Jon Loeliger wrote:
> On Thu, 2007-05-03 at 11:10, Olof Johansson wrote:
>
> >
> > This sounds like something that firmware should take care of, not
> > hardcoded in the board code. Seems like the device is just a PCI device
> > that doesn't have a device tree entry.
>
> Well, it's not a PCI device at all.
Really? You use a PCI quirk to manipulate it.
> > Why not do this in u-boot instead?
>
> Why do it there? We'd have to do it _again_ in Linux
> if we didn't come in from U-Boot anyway.
The same argument could be used to motivate not doing any kind of board
inits in any firmware and do it all from the board code in linux.
Don't you guys use M1575 on other eval boards too, so you'll need the
same board quirk duplicated?
-Olof
^ permalink raw reply
* Re: powerpc_flash_init(), wtf!?
From: Segher Boessenkool @ 2007-05-03 17:25 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linuxppc-dev, David Gibson
In-Reply-To: <463A14E6.5010608@ru.mvista.com>
>>> BTW, is it legal/appropriate to specify device (not bus) types
>>> for
>>> of_platform_bus_probe()?
>
>> In almost all cases you should probe on "name"/"compatible",
>
> Probing on name is not a good idea, since those are mostly generic.
The OF standard tells you to probe on "name" before
probing on "compatible". If the "name" in a certain
node is generic, that doesn't harm at all, since you
probe for the more specific names only.
>> and not use "device_type" at all.
>
> Heh, SPARC device trees I saw seem to not have this "useless" prop
> at all. :-)
Well they have it in the nodes for which they _should_
have it, but not anywhere else no.
Segher
^ permalink raw reply
* Re: [PATCH] 86xx: Enable the AC97 interface on 8641D board.
From: Olof Johansson @ 2007-05-03 17:28 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <3C4D879A-E756-45EA-AB67-70902797ED35@kernel.crashing.org>
On Thu, May 03, 2007 at 11:19:21AM -0500, Kumar Gala wrote:
>
> On May 3, 2007, at 11:17 AM, Jon Loeliger wrote:
> >>Why not do this in u-boot instead?
> >
> >Why do it there? We'd have to do it _again_ in Linux
> >if we didn't come in from U-Boot anyway.
>
> I agree with Jon here. This is in board specific code so I don't see
> any issue with it.
Good to know. I'll keep that in mind myself for future reference, no
need to waste effort trying to get clean board ports.
-Olof
^ permalink raw reply
* Re: [PATCH] 86xx: Enable the AC97 interface on 8641D board.
From: Scott Wood @ 2007-05-03 17:38 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <20070503172657.GA32312@lixom.net>
Olof Johansson wrote:
> On Thu, May 03, 2007 at 11:17:26AM -0500, Jon Loeliger wrote:
>>Why do it there? We'd have to do it _again_ in Linux
>>if we didn't come in from U-Boot anyway.
>
> The same argument could be used to motivate not doing any kind of board
> inits in any firmware and do it all from the board code in linux.
Not to mention that it's more likely that someone will use a different
OS than different firmware, and then they'd have to duplicate the board
code *there*.
-Scott
^ permalink raw reply
* Re: [PATCH] Remove CPU_FTR_NEED_COHERENT for 7448.
From: Jon Loeliger @ 2007-05-03 17:38 UTC (permalink / raw)
To: Adrian Cox; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <1178212026.5586.17.camel@localhost.localdomain>
On Thu, 2007-05-03 at 12:07, Adrian Cox wrote:
> On Thu, 2007-05-03 at 11:13 -0500, Jon Loeliger wrote:
> > > The problem is that many 32-bit PowerPC machines needed
> > > CPU_FTR_NEED_COHERENT set for a second reason: compatibility with the
> > > cache in the MPC107. This was handled by CPU_FTR_COMMON in cputable.h
> > > before the L2 prefetch bug was known. There may be other host bridges
> > > that cache, but nobody will have noticed because all the CPUs had
> > > CPU_FTR_NEED_COHERENT set already.
>
> > Yes, you are correct and your concern is valid. However,
> > this case is still being handled by CONFIG_MPC10X_BRIDGE
> > to deal with the MPC106/MPC107/etc north bridges.
>
> My only concern here is that some other Northbridges may have a similar
> cache issue to the MPC107, but that we haven't noticed because the
> cputable entry has been a crutch for them. If we remove the entry, will
> some other 7448 designs quietly stop working? I think the Tsi108/109
> are probably safe, but I don't know about other bridges.
>
> > The CPU doesn't impose this requirement, the north bridge does.
> > It might even better be named something like
> > CPU_FTR_NORTHBRDIGE_NEEDS_COHERENT.
>
> Yes - we end up turning on coherency for multiple reasons - SMP, the L2
> prefetch bug, or the cache in the MPC107. I quite like Ben H's idea of
> doing this in machine_probe().
Hmmmm... I see... Would you prefer something like this instead:
static int __init mpc86xx_hpcn_probe(void)
{
unsigned long root = of_get_flat_dt_root();
if (of_flat_dt_is_compatible(root, "mpc86xx")) {
/*
* get number_of_cpus() from somewhere
* perhaps the device tree?
*/
if (number_of_cpus() == 1)
cur_cpu_spec->cpu_features &= ~CPU_FTR_NEED_COHERENT;
return 1; /* Looks good */
}
return 0;
}
Though, rather than a dynamic test for number_of_cpus() == 1, perhaps
just another #ifndef CONFIG_SMP around that feature removal?
Thanks,
jdl
^ permalink raw reply
* Re: powerpc_flash_init(), wtf!?
From: Sergei Shtylyov @ 2007-05-03 17:53 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, David Gibson
In-Reply-To: <463A1941.3090608@ru.mvista.com>
Hello, I wrote:
>>Now for ROM/flash/NVRAM, nodes _can_ appear directly
>>under the root, but only if that is where they belong
>>on your platform (i.e., they sit directly on the "system
>>bus" (whatever that means on your platform); on most
>>platforms though, such devices are connected via some
>>I/O busses, so the nodes should appear under their
>>respective controllers.
> Yeah, you're right here, and I've probably misunderstood what "memory"
> node was. In fact, the flash in my system resides on the same local bus as
> RAM, so the proper place would be behind the "lbc" (or whatever -- it doesn't
> exist as yet) node on the "soc" bus. Do you think I need to go and document
> it as well for such cause? :-]
No, that probably won't do. MPC85xx SoC bus has ranges = <e0000000
00100000> and the NOR flash is mapped at 0xff000000, so it seems that it can't
be located under the "soc" bus (unless that latter has "ranges" prop extended?).
>>Segher
WBR, Sergei
^ permalink raw reply
* Re: qla_wxyz pci_set_mwi question
From: Andrew Vasquez @ 2007-05-03 17:44 UTC (permalink / raw)
To: Matthew Wilcox
Cc: Randy Dunlap, scsi, gregkh, David Somayajulu, linuxppc-dev,
linux-driver, PCI
In-Reply-To: <20070412200438.GM26692@parisc-linux.org>
On Thu, 12 Apr 2007, Matthew Wilcox wrote:
> On Thu, Apr 12, 2007 at 12:37:13PM -0700, Andrew Vasquez wrote:
> > On Thu, 12 Apr 2007, Matthew Wilcox wrote:
> > > Why should it fail? If there's a platform which can't support a
> > > cacheline size that the qla2xyz card can handle, it should be able to
> > > happily fall back to doing plain writes instead of MWIs. IMO, it should
> > > just call pci_set_mwi() and ignore the result.
> >
> > I believe there were some erratas on some ISP2xxx chips where MWI
> > needed to be set for proper operation. I'll go back, verify and
> > update the patch accordingly.
>
> Hmm. The thing is that pci_set_mwi() returns success on machines where
> MWI is disabled (currently only PPC64). Perhaps it needs to fail
> instead.
Sorry for the latency on getting this one resolved... So is Randy's
proposal for pci_try_set_mwi():
http://article.gmane.org/gmane.linux.kernel/516349
going to be added in 2.6.22? If so, I'd like to propose the following
to qla2xxx which handles the 2300 errata.
--
diff --git a/drivers/scsi/qla2xxx/qla_init.c b/drivers/scsi/qla2xxx/qla_init.c
index 6ad1588..8b83e1c 100644
--- a/drivers/scsi/qla2xxx/qla_init.c
+++ b/drivers/scsi/qla2xxx/qla_init.c
@@ -130,18 +130,16 @@ qla2x00_initialize_adapter(scsi_qla_host_t *ha)
int
qla2100_pci_config(scsi_qla_host_t *ha)
{
- uint16_t w, mwi;
+ uint16_t w;
uint32_t d;
unsigned long flags;
struct device_reg_2xxx __iomem *reg = &ha->iobase->isp;
pci_set_master(ha->pdev);
- mwi = 0;
- if (pci_set_mwi(ha->pdev))
- mwi = PCI_COMMAND_INVALIDATE;
+ pci_try_set_mwi(ha->pdev);
pci_read_config_word(ha->pdev, PCI_COMMAND, &w);
- w |= mwi | (PCI_COMMAND_PARITY | PCI_COMMAND_SERR);
+ w |= (PCI_COMMAND_PARITY | PCI_COMMAND_SERR);
pci_write_config_word(ha->pdev, PCI_COMMAND, w);
/* Reset expansion ROM address decode enable */
@@ -166,22 +164,21 @@ qla2100_pci_config(scsi_qla_host_t *ha)
int
qla2300_pci_config(scsi_qla_host_t *ha)
{
- uint16_t w, mwi;
+ uint16_t w;
uint32_t d;
unsigned long flags = 0;
uint32_t cnt;
struct device_reg_2xxx __iomem *reg = &ha->iobase->isp;
pci_set_master(ha->pdev);
- mwi = 0;
- if (pci_set_mwi(ha->pdev))
- mwi = PCI_COMMAND_INVALIDATE;
+ pci_try_set_mwi(ha->pdev);
pci_read_config_word(ha->pdev, PCI_COMMAND, &w);
- w |= mwi | (PCI_COMMAND_PARITY | PCI_COMMAND_SERR);
+ w |= (PCI_COMMAND_PARITY | PCI_COMMAND_SERR);
if (IS_QLA2322(ha) || IS_QLA6322(ha))
w &= ~PCI_COMMAND_INTX_DISABLE;
+ pci_write_config_word(ha->pdev, PCI_COMMAND, w);
/*
* If this is a 2300 card and not 2312, reset the
@@ -210,7 +207,7 @@ qla2300_pci_config(scsi_qla_host_t *ha)
ha->fb_rev = RD_FB_CMD_REG(ha, reg);
if (ha->fb_rev == FPM_2300)
- w &= ~PCI_COMMAND_INVALIDATE;
+ pci_clear_mwi(ha->pdev);
/* Deselect FPM registers. */
WRT_REG_WORD(®->ctrl_status, 0x0);
@@ -227,7 +224,6 @@ qla2300_pci_config(scsi_qla_host_t *ha)
spin_unlock_irqrestore(&ha->hardware_lock, flags);
}
- pci_write_config_word(ha->pdev, PCI_COMMAND, w);
pci_write_config_byte(ha->pdev, PCI_LATENCY_TIMER, 0x80);
@@ -253,19 +249,17 @@ qla2300_pci_config(scsi_qla_host_t *ha)
int
qla24xx_pci_config(scsi_qla_host_t *ha)
{
- uint16_t w, mwi;
+ uint16_t w;
uint32_t d;
unsigned long flags = 0;
struct device_reg_24xx __iomem *reg = &ha->iobase->isp24;
int pcix_cmd_reg, pcie_dctl_reg;
pci_set_master(ha->pdev);
- mwi = 0;
- if (pci_set_mwi(ha->pdev))
- mwi = PCI_COMMAND_INVALIDATE;
+ pci_try_set_mwi(ha->pdev);
pci_read_config_word(ha->pdev, PCI_COMMAND, &w);
- w |= mwi | (PCI_COMMAND_PARITY | PCI_COMMAND_SERR);
+ w |= (PCI_COMMAND_PARITY | PCI_COMMAND_SERR);
w &= ~PCI_COMMAND_INTX_DISABLE;
pci_write_config_word(ha->pdev, PCI_COMMAND, w);
^ permalink raw reply related
* Re: powerpc_flash_init(), wtf!?
From: Segher Boessenkool @ 2007-05-03 18:07 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linuxppc-dev, David Gibson
In-Reply-To: <463A2192.6020308@ru.mvista.com>
>> Yeah, you're right here, and I've probably misunderstood what
>> "memory" node was. In fact, the flash in my system resides on the
>> same local bus as RAM, so the proper place would be behind the "lbc"
>> (or whatever -- it doesn't exist as yet) node on the "soc" bus. Do
>> you think I need to go and document it as well for such cause? :-]
>
> No, that probably won't do. MPC85xx SoC bus has ranges = <e0000000
> 00100000> and the NOR flash is mapped at 0xff000000, so it seems that
> it can't be located under the "soc" bus (unless that latter has
> "ranges" prop extended?).
If the RAM and/or ROM sit on the SoC bus, the "ranges"
property in the SoC node should be able to translate
their addresses, yes. You could opt for having the
memory controller a separate device node, as a sibling
of the "soc" node, if that agrees better with your
SoC architecture. "It all depends".
Segher
^ permalink raw reply
* Re: powerpc_flash_init(), wtf!?
From: Segher Boessenkool @ 2007-05-03 17:35 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linuxppc-dev, David Gibson
In-Reply-To: <463A1941.3090608@ru.mvista.com>
>>> NOR flashes are at the same level as the "memory" node (where
>>> else you
>>> expect them to appear I wonder?).
>
>> The "memory" node doesn't describe the RAM devices;
>> it describes the RAM address space, instead. You can
>> have separate nodes for the actual devices.
>
> If you can remember our prior discussion, the "rom" nodes don't
> describe "the actual devices" as well, only their mapping into the
> address space. ;-)
I don't remember that no. And having a node for the
"ROM address space" isn't useful in the same way as
having one for the "RAM address space" is -- flash
memory is not a resource you randomly hand out to
anyone who wants a piece. You also need to know some
_specifics_ about a certain ROM device before you can
map it into CPU address space properly.
>> Now for ROM/flash/NVRAM, nodes _can_ appear directly
>> under the root, but only if that is where they belong
>> on your platform (i.e., they sit directly on the "system
>> bus" (whatever that means on your platform); on most
>> platforms though, such devices are connected via some
>> I/O busses, so the nodes should appear under their
>> respective controllers.
>
> Yeah, you're right here, and I've probably misunderstood what
> "memory" node was. In fact, the flash in my system resides on the same
> local bus as RAM, so the proper place would be behind the "lbc" (or
> whatever -- it doesn't exist as yet) node on the "soc" bus. Do you
> think I need to go and document it as well for such cause? :-]
If the "lbc" isn't software visible, you can/should put
the RAM/ROM nodes directly under the SoC node.
This is all just standard considerations, so I don't think
you need to document it separately no. An example device
tree will help other implementors using your SoC create a
proper device tree, of course.
>> Most "north bridges" have some bits that enable
>> translation of accesses in the "low bios" area to
>> the 4GB-minus-a-bit area. There are many variations
>> and it all is a big mess :-)
>
> Human perversion knows no limits. O:-)
Well it's note like there aren't any groovy things on
some PowerPC systems, but x86 definitely wins :-)
>> Now, back to the case at hand -- it would be nice to
>> have a platform-independent way to probe the simple
>> case -- a single direct-mapped device -- but it isn't
>> obvious how to make that not clash with the not-so-simple
>> cases. A helper function that does the work but is
>> only called by the platforms that want it would do, I
>> suppose?
>
> It probably doesn't even worth a helper (since out of those 15
> lines, 6 were pretty useless anyway)
Sure -- but since it is such a common device to have (a
simple NOR boot flash), it would be nice to avoid any
code duplication. Compare to the serial port and RTC
situation.
Segher
^ permalink raw reply
* Re: powerpc_flash_init(), wtf!?
From: Sergei Shtylyov @ 2007-05-03 18:19 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, David Gibson
In-Reply-To: <4e36fd0fc67f14fc4ff2178468c053f0@kernel.crashing.org>
Hello.
Segher Boessenkool wrote:
>>>> NOR flashes are at the same level as the "memory" node (where
>>>> else you
>>>> expect them to appear I wonder?).
>>> The "memory" node doesn't describe the RAM devices;
>>> it describes the RAM address space, instead. You can
>>> have separate nodes for the actual devices.
>> If you can remember our prior discussion, the "rom" nodes don't
>> describe "the actual devices" as well, only their mapping into the
>> address space. ;-)
> I don't remember that no. And having a node for the
That's a pity. :-)
> "ROM address space" isn't useful in the same way as
> having one for the "RAM address space" is -- flash
> memory is not a resource you randomly hand out to
> anyone who wants a piece. You also need to know some
> _specifics_ about a certain ROM device before you can
> map it into CPU address space properly.
Almost all of that is handled by MTD subsys transparently by probing.
What one *must* supply are the bank width and the address mapping (may
optionally supply a probe type).
>>> Now for ROM/flash/NVRAM, nodes _can_ appear directly
>>> under the root, but only if that is where they belong
>>> on your platform (i.e., they sit directly on the "system
>>> bus" (whatever that means on your platform); on most
>>> platforms though, such devices are connected via some
>>> I/O busses, so the nodes should appear under their
>>> respective controllers.
>> Yeah, you're right here, and I've probably misunderstood what
>> "memory" node was. In fact, the flash in my system resides on the same
>> local bus as RAM, so the proper place would be behind the "lbc" (or
>> whatever -- it doesn't exist as yet) node on the "soc" bus. Do you
>> think I need to go and document it as well for such cause? :-]
> If the "lbc" isn't software visible, you can/should put
> the RAM/ROM nodes directly under the SoC node.
It has a register set of its own.
>>> Now, back to the case at hand -- it would be nice to
>>> have a platform-independent way to probe the simple
>>> case -- a single direct-mapped device -- but it isn't
>>> obvious how to make that not clash with the not-so-simple
>>> cases. A helper function that does the work but is
>>> only called by the platforms that want it would do, I
>>> suppose?
>> It probably doesn't even worth a helper (since out of those 15
>> lines, 6 were pretty useless anyway)
> Sure -- but since it is such a common device to have (a
> simple NOR boot flash), it would be nice to avoid any
> code duplication. Compare to the serial port and RTC
> situation.
UARTs should be registered as of_device by the same bus probing mechanism
(and there was an attempt at OF based driver, IIRC).
arch/powerpc/kernel/legacy_serial.c only facilitates the old, platform device
based approach.
> Segher
WBR, Sergei
^ permalink raw reply
* Re: [PATCH 3/13] powerpc: Add bootwrapper support for Marvell/mv64x60 hostbridge
From: Mark A. Greer @ 2007-05-03 18:44 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <17977.29234.367271.820951@cargo.ozlabs.ibm.com>
On Thu, May 03, 2007 at 03:25:06PM +1000, Paul Mackerras wrote:
> Mark A. Greer writes:
>
> > Well, the firmware just doesn't do all the init that's required. And,
> > some of the init that it does do is wrong. For example, the window for
> > the MPSC (serial ctlr) to access main memory isn't set up so the kernel
> > mpsc driver can't dma. There are several other examles.
> >
> > All of this init should be in the firmware but its Motorola/ECC's
> > firmware and I/we have no control over it. Given that, I/we have to do
> > the init somewhere. Either in the kernel or the bootwrapper.
> > I vote for the bootwrapper but then your vote is the only one that actually
> > counts. :)
>
> How much of the setup is actually necessary for the bootwrapper to
> run, and how much could be deferred to setup_arch() time in the
> kernel?
Actually, none of the config code should be needed by the bootwrapper
itself because the bootwrapper mpsc and i2c drivers use PIO (so accessing
memory isn't an issue). The "get info" type routines are still needed.
> If nothing else, doing it in the kernel means that the code
> and data for it exist in compressed form in the zImage rather than
> uncompressed form. :)
mv64x60.o is 4804 bytes, .text is 2188 bytes, .data 64 bytes, .bss 0
bytes. So we're probably only saving ~1-2KB by compressing.
> Also, how many lines of code (including definitions) would we avoid
> having in the kernel by having this stuff in the bootwrapper?
Its pretty much 1:1. Whatever is in the bootwrapper (including
#define's) isn't needed in the kernel.
> Another question - is this setup something that will need to be done
> differently for different boards using the mv64x60, or is the same
> setup needed for all applications of the mv64x60?
I expect that the setup will be done the same for all of the boards
that need it. Not all of the boards will need it, though. It depends
on their firmware. The config code is filling the gap between what the
firmware should have done and what the kernel drivers require (i.e.,
allowing the ctlrs to access system memory and pci mem/io space).
Paul, I'm a little perplexed by you wanting this code pushed back into
the kernel. A while back there was a definite desire to push stuff like
this out of the kernel (mainly by Ben). I tend to agree with Ben on
this. Either way, it would good to have everyone pushing in the same
direction. :)
Mark
^ permalink raw reply
* Re: [PATCH 3/13] powerpc: Add bootwrapper support for Marvell/mv64x60 hostbridge
From: Mark A. Greer @ 2007-05-03 19:00 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20070503184402.GA5600@mag.az.mvista.com>
On Thu, May 03, 2007 at 11:44:02AM -0700, Mark A. Greer wrote:
> On Thu, May 03, 2007 at 03:25:06PM +1000, Paul Mackerras wrote:
> > Mark A. Greer writes:
> > Another question - is this setup something that will need to be done
> > differently for different boards using the mv64x60, or is the same
> > setup needed for all applications of the mv64x60?
>
> I expect that the setup will be done the same for all of the boards
> that need it. Not all of the boards will need it, though. It depends
> on their firmware. The config code is filling the gap between what the
> firmware should have done and what the kernel drivers require (i.e.,
> allowing the ctlrs to access system memory and pci mem/io space).
I'll clarify the last line: "allowing ctlrs on the bridge to access
system memory, allowing the cpu to access pci mem/io space, and allowing
pci devices to access system memory via pci mem reference."
Mark
^ permalink raw reply
* Re: [PATCH] [POWERPC] 8xx: mpc885ads pcmcia support
From: Arnd Bergmann @ 2007-05-03 19:03 UTC (permalink / raw)
To: linuxppc-dev; +Cc: linux-pcmcia, linux-kernel
In-Reply-To: <5a7e02f6d1520d8ad02e28ace218981c@kernel.crashing.org>
On Thursday 03 May 2007, Segher Boessenkool wrote:
> > For example, you could make this
> >
> > =A0=A0=A0=A0=A0=A0compatible =3D "8xx\0mpc885ads";
>=20
> "mpc885ads-pcmcia\0mpc8xx-pcmcia" or something like that.
Right. I can never remember what goes first...
Arnd <><
^ permalink raw reply
* [PATCH] fix pci_setup_phb_io_dynamic for pci_iomap
From: Arnd Bergmann @ 2007-05-03 19:42 UTC (permalink / raw)
To: linuxppc-dev; +Cc: paulus
We had a problem on a system with only dynamically allocated
PCI buses (using of_pci_phb_driver) in combination with libata.
It turns out that pci_setup_phb_io_dynamic does a simple ioremap
instead of an __ioremap_explicit into the reserved I/O space
region, which causes pcim_iomap->pci_iomap->ioport_map to fail
a sanity check for the virtual address of the I/O port.
Also, our setup ended up having no "primary" phb, which means
that pci_io_base never got initialized. This caused the same
bug independently.
This patch fixes both problems.
Signed-off-by: Arnd Bergmann <arnd.bergmann@de.ibm.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
arch/powerpc/kernel/of_platform.c | 4 ++--
arch/powerpc/kernel/pci_64.c | 6 ++++--
2 files changed, 6 insertions(+), 4 deletions(-)
Index: linux-2.6.21.ppc64/arch/powerpc/kernel/of_platform.c
===================================================================
--- linux-2.6.21.ppc64.orig/arch/powerpc/kernel/of_platform.c
+++ linux-2.6.21.ppc64/arch/powerpc/kernel/of_platform.c
@@ -426,13 +426,13 @@ static int __devinit of_pci_phb_probe(st
}
/* Process "ranges" property */
- pci_process_bridge_OF_ranges(phb, dev->node, 0);
+ pci_process_bridge_OF_ranges(phb, dev->node, pci_io_base == 0);
/* Setup IO space.
* This will not work properly for ISA IOs, something needs to be done
* about it if we ever generalize that way of probing PCI brigdes
*/
- pci_setup_phb_io_dynamic(phb, 0);
+ pci_setup_phb_io_dynamic(phb, pci_io_base == 0);
/* Init pci_dn data structures */
pci_devs_phb_init_dynamic(phb);
Index: linux-2.6.21.ppc64/arch/powerpc/kernel/pci_64.c
===================================================================
--- linux-2.6.21.ppc64.orig/arch/powerpc/kernel/pci_64.c
+++ linux-2.6.21.ppc64/arch/powerpc/kernel/pci_64.c
@@ -1077,8 +1077,7 @@ void __devinit pci_setup_phb_io_dynamic(
unsigned long io_virt_offset;
struct resource *res;
- hose->io_base_virt = __ioremap(hose->io_base_phys, size,
- _PAGE_NO_CACHE | _PAGE_GUARDED);
+ hose->io_base_virt = reserve_phb_iospace(size);
DBG("phb%d io_base_phys 0x%lx io_base_virt 0x%lx\n",
hose->global_number, hose->io_base_phys,
(unsigned long) hose->io_base_virt);
@@ -1090,6 +1089,9 @@ void __devinit pci_setup_phb_io_dynamic(
res = &hose->io_resource;
res->start += io_virt_offset;
res->end += io_virt_offset;
+
+ __ioremap_explicit(hose->io_base_phys, (unsigned long)hose->io_base_virt, size,
+ _PAGE_NO_CACHE | _PAGE_GUARDED);
}
^ permalink raw reply
* Re: [Linux-fbdev-devel] [PATCH] Xilinx framebuffer device driver - 3d version
From: Antonino A. Daplas @ 2007-05-03 19:57 UTC (permalink / raw)
To: linux-fbdev-devel; +Cc: linuxppc-embedded
In-Reply-To: <463A1B58.8000804@ru.mvista.com>
On Thu, 2007-05-03 at 21:26 +0400, Andrei Konovalov wrote:
> Add support for the video controller IP block included into Xilinx ML300
> and ML403 reference designs.
>
> Signed-off-by: Andrei Konovalov <akonovalov@ru.mvista.com>
>
> -----
> The driver has been tested with Xilinx ML300 and ML403 reference designs.
>
> The two first version has been posted to linuxppc-embedded, and this
> version tries to address all the comments and criticism received.
>
> The platform device registration for Xilinx ML300 and ML403
> moved into separate patch (will be posted to linuxppc-embedded
> in couple minutes).
>
> Would be nice to get this driver into mainline for the 2.6.22.
> Reviews and comments are welcome.
It's hard to make comments when you submit patches as attachment, but
here goes.
+static int
+xilinx_fb_blank(int blank_mode, struct fb_info *fbi)
+{
+ struct xilinxfb_drvdata *drvdata = to_xilinxfb_drvdata(fbi);
+
+ switch (blank_mode) {
+ case VESA_NO_BLANKING:
+ /* turn on panel */
+ xilinx_fb_out_be32(drvdata, REG_CTRL, drvdata->reg_ctrl_default);
+ break;
+
+ case VESA_VSYNC_SUSPEND:
+ case VESA_HSYNC_SUSPEND:
+ case VESA_POWERDOWN:
+ /* turn off panel */
+ xilinx_fb_out_be32(drvdata, REG_CTRL, 0);
+ default:
+ break;
+
+ }
+ return 0; /* success */
+}
+
Use the FB_BLANK_* constants defined in include/linux/fb.h instead of
the VESA_* constants.
+static int
+xilinx_fb_pan_display(struct fb_var_screeninfo *var, struct fb_info
*fbi)
+{
+ if (var->xoffset != 0 || var->yoffset != 0)
+ return -EINVAL;
+
+ return 0;
+}
+
This silently succeeds. If you don't have a pan_display() hook, might
as well remove it.
+static int
+xilinxfb_drv_probe(struct device *dev)
+{
+ struct platform_device *pdev;
+ struct xilinxfb_platform_data *pdata;
+ struct xilinxfb_drvdata *drvdata;
+ struct resource *regs_res;
+ int retval;
+
+ if (!dev)
+ return -EINVAL;
+
+ pdev = to_platform_device(dev);
+ pdata = (struct xilinxfb_platform_data *)pdev->dev.platform_data;
Is the cast really needed?
+
+ if (pdata == NULL) {
+ printk(KERN_ERR "Couldn't find platform data.\n");
+ return -EFAULT;
+ }
+
+ drvdata = kzalloc(sizeof(*drvdata), GFP_KERNEL);
+ if (!drvdata) {
+ printk(KERN_ERR "Couldn't allocate device private record\n");
+ return -ENOMEM;
+ }
+ dev_set_drvdata(dev, (void *)drvdata);
Here also.
+
+ /* Map the control registers in */
+ regs_res = platform_get_resource(pdev, IORESOURCE_IO, 0);
+ if (!regs_res || (regs_res->end - regs_res->start + 1 < 8)) {
+ printk(KERN_ERR "Couldn't get registers resource\n");
+ retval = -EFAULT;
+ goto failed1;
+ }
+
+ if (!request_mem_region(regs_res->start, 8, DRIVER_NAME)) {
+ printk(KERN_ERR
+ "Couldn't lock memory region at 0x%08X\n",
+ regs_res->start);
+ retval = -EBUSY;
+ goto failed1;
+ }
+ drvdata->regs = (u32 __iomem*) ioremap(regs_res->start, 8);
+ drvdata->regs_phys = regs_res->start;
+
+ /* Allocate the framebuffer memory */
+ drvdata->fb_virt = dma_alloc_coherent(dev, PAGE_ALIGN(FB_SIZE),
+ &drvdata->fb_phys, GFP_KERNEL);
+ if (!drvdata->fb_virt) {
+ printk(KERN_ERR "Could not allocate frame buffer memory\n");
+ retval = -ENOMEM;
+ goto failed2;
+ }
+
+ /* Clear (turn to black) the framebuffer */
+ memset((void *) drvdata->fb_virt, 0, FB_SIZE);
memset() or memset_io()?
+
+ /* Tell the hardware where the frame buffer is */
+ xilinx_fb_out_be32(drvdata, REG_FB_ADDR, drvdata->fb_phys);
+
+ /* Turn on the display */
+ if (pdata->rotate_screen) {
+ drvdata->reg_ctrl_default = REG_CTRL_ENABLE | REG_CTRL_ROTATE;
+ } else {
+ drvdata->reg_ctrl_default = REG_CTRL_ENABLE;
+ }
+ xilinx_fb_out_be32(drvdata, REG_CTRL, drvdata->reg_ctrl_default);
+
+ /* Fill struct fb_info */
+ drvdata->info.screen_base = drvdata->fb_virt;
+ drvdata->info.fbops = &xilinxfb_ops;
+ drvdata->info.fix = xilinx_fb_fix;
+ drvdata->info.fix.smem_start = drvdata->fb_phys;
+ drvdata->info.pseudo_palette = drvdata->pseudo_palette;
If you cannot use framebuffer_alloc()/release(), set
drvdata->info.device so your driver shows up in /sys/class/graphics.
Tony
^ permalink raw reply
* RE: How do external irq's get mapped?
From: Charles Krinke @ 2007-05-03 20:19 UTC (permalink / raw)
To: Andy Fleming; +Cc: Randy Brown, Chris Carlson, Kevin Smith, linuxppc-embedded
In-Reply-To: <305AA45A-EF86-4661-80F6-AA1996893A3D@freescale.com>
Dear Andy:
I want to thank you and your group for getting us off the externalIRQ
block. Using irq =3D 128 allows the external device to interrupt on IRQ0
to the 8541.
I know it was a long, drawn-out explanation, but the help in
understanding is much appreciated.
Charles Krinke
^ permalink raw reply
* Re: [PATCH] fix pci_setup_phb_io_dynamic for pci_iomap
From: Benjamin Herrenschmidt @ 2007-05-03 21:31 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev, paulus
In-Reply-To: <200705032142.39031.arnd@arndb.de>
On Thu, 2007-05-03 at 21:42 +0200, Arnd Bergmann wrote:
> We had a problem on a system with only dynamically allocated
> PCI buses (using of_pci_phb_driver) in combination with libata.
>
> It turns out that pci_setup_phb_io_dynamic does a simple ioremap
> instead of an __ioremap_explicit into the reserved I/O space
> region, which causes pcim_iomap->pci_iomap->ioport_map to fail
> a sanity check for the virtual address of the I/O port.
>
> Also, our setup ended up having no "primary" phb, which means
> that pci_io_base never got initialized. This caused the same
> bug independently.
>
> This patch fixes both problems.
Hrm... dynamically added PHBs shouldn't use the reserved region.
We need to fix ioport_map instead I think. I'll have a look.
Ben.
^ permalink raw reply
* Re: [PATCH] Remove CPU_FTR_NEED_COHERENT for 7448.
From: Benjamin Herrenschmidt @ 2007-05-03 21:36 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <1178208838.17201.52.camel@ld0161-tx32>
On Thu, 2007-05-03 at 11:13 -0500, Jon Loeliger wrote:
> On Thu, 2007-05-03 at 05:17, Adrian Cox wrote:
> > On Wed, 2007-05-02 at 16:34 -0500, Jon Loeliger wrote:
> > > From: James.Yang <James.Yang@freescale.com>
> > >
> > > Remove CPU_FTR_NEED_COHERENT for MPC7448 (and single-core MPC86xx).
> > > This prevents needlessly setting M=1 when not SMP.
> >
> > There may be side effects to removing this. Most of the 74xx processors
> > had this flag added because of the L2 prefetch bug (erratum #16 on the
> > 7447A). I see that bug is missing from the 7448 errata.
> >
> > The problem is that many 32-bit PowerPC machines needed
> > CPU_FTR_NEED_COHERENT set for a second reason: compatibility with the
> > cache in the MPC107. This was handled by CPU_FTR_COMMON in cputable.h
> > before the L2 prefetch bug was known. There may be other host bridges
> > that cache, but nobody will have noticed because all the CPUs had
> > CPU_FTR_NEED_COHERENT set already.
>
> Adrian,
>
> Yes, you are correct and your concern is valid. However,
> this case is still being handled by CONFIG_MPC10X_BRIDGE
> to deal with the MPC106/MPC107/etc north bridges.
I still maintain it should be a runtime thing tho :-)
Ben.
^ permalink raw reply
* Re: powerpc_flash_init(), wtf!?
From: Benjamin Herrenschmidt @ 2007-05-03 21:37 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, David Gibson
In-Reply-To: <a8625bde363025ce23393d5b2bb6ec07@kernel.crashing.org>
On Thu, 2007-05-03 at 18:21 +0200, Segher Boessenkool wrote:
> > BTW, is it legal/appropriate to specify device (not bus) types for
> > of_platform_bus_probe()?
>
> In almost all cases you should probe on "name"/"compatible",
> and not use "device_type" at all.
of_platform_bus_probe() is for busses anyway.
Ben.
^ permalink raw reply
* Re: powerpc_flash_init(), wtf!?
From: Benjamin Herrenschmidt @ 2007-05-03 21:44 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linuxppc-dev, David Gibson
In-Reply-To: <463A27A6.5050601@ru.mvista.com>
> UARTs should be registered as of_device by the same bus probing mechanism
> (and there was an attempt at OF based driver, IIRC).
There is more than an "attempt". There is one and it works :-)
> arch/powerpc/kernel/legacy_serial.c only facilitates the old, platform device
> based approach.
This is a compromise for legacy port (ok, it did grow a bit beyond
legacy stuff but still...) mostly to allow for very early initialisation
of serial ports.
Ultimately, if we generalize of_platform_devices for serial ports,
however, we will not need to create platform devices there anymore.
Ben.
^ permalink raw reply
* [PATCH 2/1] comment fixup for smp_call_function
From: Will Schmidt @ 2007-05-03 21:47 UTC (permalink / raw)
To: michael; +Cc: linuxppc-dev, paulus, anton, Kevin Corry
In-Reply-To: <1178153638.5338.2.camel@concordia.ozlabs.ibm.com>
Fix up the comment blob for smp_call_function and friends. Also just a
touch of whitespace cleanup.
Signed-off-by: Will Schmidt <will_schmidt@vnet.ibm.com>
---
diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
index 4878588..1b82228 100644
--- a/arch/powerpc/kernel/smp.c
+++ b/arch/powerpc/kernel/smp.c
@@ -176,15 +176,13 @@ static struct call_data_struct {
#define SMP_CALL_TIMEOUT 8
/*
- * These functions send a 'generic call function' IPI to other online
- * CPUS in the system.
+ * smp_call_function(): Run a function on other CPUs.
+ * @func: The function to run. This must be fast and non-blocking.
+ * @info: An arbitrary pointer to pass to the function.
+ * @nonatomic: currently unused.
+ * @wait: If true, wait (atomically) until function has completed on other CPUs.
*
- * [SUMMARY] Run a function on other CPUs.
- * <func> The function to run. This must be fast and non-blocking.
- * <info> An arbitrary pointer to pass to the function.
- * <nonatomic> currently unused.
- * <wait> If true, wait (atomically) until function has completed on other CPUs.
- * [RETURNS] 0 on success, else a negative status code. Does not return until
+ * Returns 0 on success, else a negative status code. Does not return until
* remote CPUs are nearly ready to execute <<func>> or are or have executed.
*
* You must not call this function with disabled interrupts or from a
@@ -361,7 +359,7 @@ void __init smp_prepare_cpus(unsigned int max_cpus)
DBG("smp_prepare_cpus\n");
- /*
+ /*
* setup_cpu may need to be called on the boot cpu. We havent
* spun any cpus up but lets be paranoid.
*/
@@ -375,7 +373,7 @@ void __init smp_prepare_cpus(unsigned int max_cpus)
max_cpus = smp_ops->probe();
else
max_cpus = 1;
-
+
smp_space_timers(max_cpus);
for_each_possible_cpu(cpu)
@@ -585,7 +583,7 @@ void __init smp_cpus_done(unsigned int max_cpus)
*/
old_mask = current->cpus_allowed;
set_cpus_allowed(current, cpumask_of_cpu(boot_cpuid));
-
+
if (smp_ops)
smp_ops->setup_cpu(boot_cpuid);
^ permalink raw reply related
* Re: [PATCH] [POWERPC] 8xx: mpc885ads pcmcia support
From: Segher Boessenkool @ 2007-05-03 22:17 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev, linux-pcmcia, linux-kernel
In-Reply-To: <200705032103.33809.arnd@arndb.de>
>>> For example, you could make this
>>>
>>> =A0=A0=A0=A0=A0=A0compatible =3D "8xx\0mpc885ads";
>>
>> "mpc885ads-pcmcia\0mpc8xx-pcmcia" or something like that.
>
> Right. I can never remember what goes first...
It doesn't really matter all that much; "correct"
drivers probe for the most specific thing first,
then the next most specific thing they support,
etc. It is mostly a convention.
The important thing is that you can't just call
yourself "8xx", that is way to generic a name.
Segher
^ permalink raw reply
* Re: [PATCH] Remove CPU_FTR_NEED_COHERENT for 7448.
From: Paul Mackerras @ 2007-05-03 23:34 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <1178208290.17201.43.camel@ld0161-tx32>
Jon Loeliger writes:
> Yes. We have the data to back this claim up.
Care to share it with us? :)
Paul.
^ permalink raw reply
* Re: powerpc_flash_init(), wtf!?
From: David Gibson @ 2007-05-03 23:49 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <a8625bde363025ce23393d5b2bb6ec07@kernel.crashing.org>
On Thu, May 03, 2007 at 06:21:35PM +0200, Segher Boessenkool wrote:
> > BTW, is it legal/appropriate to specify device (not bus) types for
> > of_platform_bus_probe()?
>
> In almost all cases you should probe on "name"/"compatible",
> and not use "device_type" at all.
I don't think that's what he's getting at. "compatible" is what we
should use for the device <-> driver matching, but
of_platform_bus_probe() is earlier than that, creating the devices in
the first place.
And no, I don't think it is appropriate to specify device types rather
than bus types there. Probing devices independent of the bus type
they sit on will always run the risk of conflicting with the bus
type's specific probe logic.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: powerpc_flash_init(), wtf!?
From: David Gibson @ 2007-05-03 23:56 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <e21cca984c076474a6e89018a198d93a@kernel.crashing.org>
On Thu, May 03, 2007 at 08:07:27PM +0200, Segher Boessenkool wrote:
> >> Yeah, you're right here, and I've probably misunderstood what
> >> "memory" node was. In fact, the flash in my system resides on the
> >> same local bus as RAM, so the proper place would be behind the "lbc"
> >> (or whatever -- it doesn't exist as yet) node on the "soc" bus. Do
> >> you think I need to go and document it as well for such cause? :-]
> >
> > No, that probably won't do. MPC85xx SoC bus has ranges = <e0000000
> > 00100000> and the NOR flash is mapped at 0xff000000, so it seems that
> > it can't be located under the "soc" bus (unless that latter has
> > "ranges" prop extended?).
>
> If the RAM and/or ROM sit on the SoC bus, the "ranges"
> property in the SoC node should be able to translate
> their addresses, yes. You could opt for having the
> memory controller a separate device node, as a sibling
> of the "soc" node, if that agrees better with your
> SoC architecture. "It all depends".
But if the flash really is on an external bus controlled by a bus
controller on the SoC, it sounds like it should go under that bus
bridge. In which case the SoC would need another range in its ranges
property.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ 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