Hai,
We have designed a MPC8641D based AMC card. We are using the
kernel (2.6.23-rc4) and uboot (1.2.0). When we disable the core1 Low Memory
offset mode the kernel was up and when we enable this core1 Low Memory
offset mode kernel was not up, It was hang after MPIC initialization.
Since commit c80d9133e99de1af607314107910a2a1645efb17 (Make direct DMA use
node local allocations) went in this comment makes no sense.
Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/dma_64.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/arc
We no longer need the global dma_direct_offset, update the comment to
reflect the new reality.
Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/dma_64.c |7 ---
include/asm-powerpc/dma-mapping.h |2 --
2 files changed, 4 insertions(+), 5 deletions(-)
d
Rather than using the global variable, have celleb use its own variable to
store the direct DMA offset.
Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/celleb/iommu.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platform
Rather than using the global variable, have cell use its own variable to
store the direct DMA offset.
Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/cell/iommu.c | 10 ++
1 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/platform
Now that all platforms using dma_direct_offset setup the archdata.dma_data
correctly, we can change the dma_direct_ops to retrieve the offset from
the dma_data, rather than directly from the global.
Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/dma_64.c | 18 ++
Celleb always uses dma_direct_ops, and sets dma_direct_offset, so it too
should set dma_data to dma_direct_offset.
Currently there's no pci_dma_dev_setup() routine for Celleb so add one.
Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/celleb/iommu.c | 14
Store a pointer to the direct_dma_offset in each device's dma_data
in the case where we're using the direct DMA ops.
Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/cell/iommu.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/powerp
Update ps3_defconfig.
Signed-off-by: Geoff Levand <[EMAIL PROTECTED]>
---
arch/powerpc/configs/ps3_defconfig | 177 ++---
1 file changed, 89 insertions(+), 88 deletions(-)
--- a/arch/powerpc/configs/ps3_defconfig
+++ b/arch/powerpc/configs/ps3_defconfig
@@ -1,7 +
The current pci_assign_unassigned_resources() code doesn't work properly
on 32 bits platforms with 64 bits resources. The main reason is the use
of unsigned long in various places instead of resource_size_t.
This fixes it, along with some tricks to avoid casting to 64 bits on
platforms that don't
On Wed, 2007-12-05 at 15:21 +1100, David Gibson wrote:
> On Wed, Dec 05, 2007 at 03:18:49PM +1100, Benjamin Herrenschmidt wrote:
> >
> > On Wed, 2007-12-05 at 14:53 +1100, David Gibson wrote:
> > > It occurred to me the other day. Instead of using a new "unused"
> > > property for this, should w
On Tue, Dec 04, 2007 at 10:00:12PM -0600, Josh Boyer wrote:
> So if mkimage is going to be put in-kernel, I'd rather it be in a more
> generic place. Arguably, dtc should go there as well seeing as how
> microblaze could probably use it too.
Well, kconfig is in scripts/ in spite of not being a s
On Wed, Dec 05, 2007 at 03:18:49PM +1100, Benjamin Herrenschmidt wrote:
>
> On Wed, 2007-12-05 at 14:53 +1100, David Gibson wrote:
> > It occurred to me the other day. Instead of using a new "unused"
> > property for this, should we be using the OF standard "status"
> > property.
>
> Dunno... it
On Wed, 2007-12-05 at 14:53 +1100, David Gibson wrote:
> It occurred to me the other day. Instead of using a new "unused"
> property for this, should we be using the OF standard "status"
> property.
Dunno... it's really not wired. Probably not even clocked.
Ben.
__
On Wed, Dec 05, 2007 at 11:14:30AM +1100, Benjamin Herrenschmidt wrote:
> From: Hugh Blemings <[EMAIL PROTECTED]>
>
> Depending on how the 44x processors are wired, some EMAC cells
> might not be useable (and not connected to a PHY). However, some
> device-trees may choose to still expose them (si
On Tue, 4 Dec 2007 20:26:25 -0600
Josh Boyer <[EMAIL PROTECTED]> wrote:
> On Wed, 5 Dec 2007 13:22:46 +1100
> Paul Mackerras <[EMAIL PROTECTED]> wrote:
>
> > Josh Boyer writes:
> >
> > > Using that same reasoning, should we merge a mkimage patch for the
> > > boards that use U-Boot?
> >
> > I t
On Wed, Dec 05, 2007 at 09:48:41AM +0900, Paul Mundt wrote:
> On Tue, Dec 04, 2007 at 02:01:21PM -0600, Olof Johansson wrote:
> > On Tue, Dec 04, 2007 at 10:49:21PM +0300, Anton Vorontsov wrote:
> > > tristate "Generic platform device PATA support"
> > > - depends on EMBEDDED || ARCH_RPC
> > > +
On Tue, 2007-12-04 at 17:08 +1100, Benjamin Herrenschmidt wrote:
> The current pci_assign_unassigned_resources() code doesn't work properly
> on 32 bits platforms with 64 bits resources. The main reason is the use
> of unsigned long in various places instead of resource_size_t.
>
> This fixes it,
On Wed, 5 Dec 2007 13:22:46 +1100
Paul Mackerras <[EMAIL PROTECTED]> wrote:
> Josh Boyer writes:
>
> > Using that same reasoning, should we merge a mkimage patch for the
> > boards that use U-Boot?
>
> I think so. It's fairly small and it would mean that people could
> cross-compile all the def
Josh Boyer writes:
> Using that same reasoning, should we merge a mkimage patch for the
> boards that use U-Boot?
I think so. It's fairly small and it would mean that people could
cross-compile all the defconfigs easily.
Paul.
___
Linuxppc-dev mailing
On Wed, Dec 05, 2007 at 11:41:50AM +1100, Paul Mackerras wrote:
> Olof Johansson writes:
>
> > Yep, I realized that after (re)asking Paul to pull though, and didn't
> > want to do a third request before he's done it. :)
> >
> > If he doesn't pull in the next few days I might just keep adding new
On Wed, 05 Dec 2007 00:54:38 +
David Woodhouse <[EMAIL PROTECTED]> wrote:
>
> On Tue, 2007-12-04 at 22:33 +, David Woodhouse wrote:
> > Make vmlinux the default target instead of zImage would seem like a
> > better answer. I'm surprised that it isn't like that already, in fact --
> > and
Scott Wood wrote:
> The physical address certainly is useful when you have more than one
> device of the same name.
What I meant was that the physical address isn't helpful by itself.
> So then you'd get "firmware-ucc.e01024". What if there's another ucc at
> e0102480? For devices with long
On Tue, 04 Dec 2007 15:07:49 -0500
Jeff Garzik wrote:
> Vitaly Bordug wrote:
> > With that patch fixed.c now fully emulates MDIO bus, thus no need
> > to duplicate PHY layer functionality. That, in turn, drastically
> > simplifies the code, and drops down line count.
> >
> > As an additional bonu
On Mon, 3 Dec 2007 13:05:00 -0800
John Tyner wrote:
> The following patch makes the QSpan PCI code compile and work on my
> hardware. The patch is against 2.4, but I'm hoping it will still be
> viewed as useful since the code currently does not even compile (2.6
> is the same). I had to make a ch
Olof Johansson writes:
> Yep, I realized that after (re)asking Paul to pull though, and didn't
> want to do a third request before he's done it. :)
>
> If he doesn't pull in the next few days I might just keep adding new
> patches as they come in though, and add it back.
I haven't pulled yet; so
David Woodhouse writes:
> Make vmlinux the default target instead of zImage would seem like a
> better answer. I'm surprised that it isn't like that already, in fact --
> and I'm only inferring that it isn't from your message. I always thought
> that if I typed 'make' I got the vmlinux and not a z
On Mon, 3 Dec 2007 12:58:38 -0800
John Tyner wrote:
> Building for 8xx fails to compile due to errors in a couple of
> places. The first is due to the casting of an lvalue (if I remember
> correctly), and the second was due to the cpmp variable being
> declared static even though the headers previ
On Wed, 5 Dec 2007 00:56:39 +0100
Arnd Bergmann wrote:
> On Wednesday 05 December 2007, Timur Tabi wrote:
> > Arnd Bergmann wrote:
> >
> > > You can argue that the QS is really a DMA device, but in that
> > > case you should convert the driver to use the DMA mapping
> > > interfaces correctly, wh
On Tue, Dec 04, 2007 at 08:07:45PM +0300, Anton Vorontsov wrote:
> This patch renames ioport_shift member of pata_platform_info
> structure to reg_shift. Users of pata_platform are followed
> appropriately.
>
> Rationale of that change is: shifting applies to the whole memory
> mapped region, not
On Tue, 2007-12-04 at 22:33 +, David Woodhouse wrote:
> Make vmlinux the default target instead of zImage would seem like a
> better answer. I'm surprised that it isn't like that already, in fact --
> and I'm only inferring that it isn't from your message. I always thought
> that if I typed 'm
This makes 4xx embedded platforms re-assign all PCI resources as we
pretty much never care about what the various firmwares have done on
these, it's generally not compatible with the way the kernel will map
the bridges.
We still need to also enable bus renumbering on some of them, but I
will do th
The 32 bits PCI code carries an old hack that was only useful for G5
machines. Nowdays, the 32 bits kernel doesn't support any of those
machines anymore so the hack is basically never used, remove it.
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/pci_32.c |
This adds to the 32 bits PCI code some flags, replacing the old
pci_assign_all_busses global, that allow to control various
aspects of the PCI probing, such as whether to re-assign all
resources or not, or to not try to assign anything at all.
This also adds the flag x86 already has to avoid ISA a
The 32 bits PowerPC PCI code has a hack for use by some PowerMacs
to try to re-open PCI<->PCI bridge IO resources that were closed
by the firmware. This is no longer necessary as the generic code
will now do that for us.
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
arch/powerpc/
This makes the 32 bits PowerPC PCI code use the generic code to assign
resources to devices that had unassigned or conflicting resources.
This allow to remove the local implementation that was incomplete and
could not assign for example a PCI<->PCI bridge from scratch, which is
needed on various e
There's a stale & bogus piece of code in 32 bits PCI code that
complains about ISA related alignment issues. Just remove it.
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/pci_32.c |6 --
1 file changed, 6 deletions(-)
Index: linux-work/arch/powerpc/ke
This serie of patches converts the 32 bits PCI code to use the generic
pci_assign_unassigned_resources() instead of its own assignment code
which was unable to deal with unassigned PCI<->PCI bridges among
other issues.
We also add flags to control the behaviour of the PCI code, such as
letting som
On Tue, Dec 04, 2007 at 02:01:21PM -0600, Olof Johansson wrote:
> On Tue, Dec 04, 2007 at 10:49:21PM +0300, Anton Vorontsov wrote:
> > tristate "Generic platform device PATA support"
> > - depends on EMBEDDED || ARCH_RPC
> > + depends on EMBEDDED || ARCH_PPC
>
> It needs to be || PPC, not
This updates the copyright notices of the new EMAC driver to
avoid confusion as who is to be blamed for new bugs.
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
drivers/net/ibm_newemac/core.c |5 +
drivers/net/ibm_newemac/core.h |5 +
drivers/net/ibm_newemac/deb
From: Valentine Barshak <[EMAIL PROTECTED]>
The patch moves dev_set_drvdata(&ofdev->dev, dev) up before tah_reset(ofdev)
is called to avoid a NULL pointer dereference, since tah_reset uses drvdata.
Signed-off-by: Valentine Barshak <[EMAIL PROTECTED]>
Signed-off-by: Benjamin Herrenschmidt <[EMAIL
From: Valentine Barshak <[EMAIL PROTECTED]>
This patch fixes a typo in ibm_newemac/core.c
(tah_port should be used instead of tah_ph)
Signed-off-by: Valentine Barshak <[EMAIL PROTECTED]>
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
drivers/net/ibm_newemac/core.c |2 +-
1 fi
From: Valentine Barshak <[EMAIL PROTECTED]>
The EMAC4_MR1_OBCI(freq) macro expects freg in MHz,
while opb_bus_freq is kept in Hz. Correct this.
Signed-off-by: Valentine Barshak <[EMAIL PROTECTED]>
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
diff -pruN linux-2.6.orig/drivers/net
From: Hugh Blemings <[EMAIL PROTECTED]>
Depending on how the 44x processors are wired, some EMAC cells
might not be useable (and not connected to a PHY). However, some
device-trees may choose to still expose them (since their registers
are present in the MMIO space) but with an "unused" property i
There are a few variants of the STACR register that affect more than
just the "AXON" version of EMAC. Replace the current test of various
chip models with tests for generic properties in the device-tree.
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
Acked-by: Stefan Roese <[EMAIL PROTE
More than just "AXON" version of EMAC RGMII supports MDIO, so replace
the current test with a generic property in the device-tree that
indicates such support.
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
Acked-by: Stefan Roese <[EMAIL PROTECTED]>
---
arch/powerpc/boot/dts/sequoia.dt
With some PHYs, when the link goes away, the EMAC reset fails due
to the loss of the RX clock I believe.
The old EMAC driver worked around that using some internal chip-specific
clock force bits that are different on various 44x implementations.
This is an attempt at doing it differently, by avoi
When using ZMII for MDIO only (such as 440GX with RGMII for data and ZMII for
MDIO), the ZMII code would fail to properly refcount, thus triggering a
BUG_ON().
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
Acked-by: Stefan Roese <[EMAIL PROTECTED]>
---
drivers/net/ibm_newemac/zmii.c
From: Stefan Roese <[EMAIL PROTECTED]>
This adds support for the Agere ET1011c PHY as found on the AMCC Taishan
board.
Signed-off-by: Stefan Roese <[EMAIL PROTECTED]>
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
drivers/net/ibm_newemac/phy.c | 37 +
From: Stefan Roese <[EMAIL PROTECTED]>
This patch adds BCM5248 and Marvell 88E PHY support to NEW EMAC driver.
These PHY chips are used on PowerPC 440EPx boards.
The PHY code is based on the previous work by Stefan Roese <[EMAIL PROTECTED]>
Signed-off-by: Stefan Roese <[EMAIL PROTECTED]>
Sign
On Tue, Dec 04, 2007 at 01:05:46PM -0700, Grant Likely wrote:
> On 12/4/07, Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote:
> >
> > On Tue, 2007-12-04 at 11:01 -0700, Mark A. Greer wrote:
> > > On Tue, Dec 04, 2007 at 06:23:09PM +1100, Benjamin Herrenschmidt wrote:
> > > >
> > > > On Mon, 2007-12
On 12/4/07, Stephen Neuendorffer <[EMAIL PROTECTED]> wrote:
> Supports static platform_device and static device tree configuration.
> This is a standalone driver that does not depend on EDK generated
> files. However, it is also somewhat different in functionality from
> the standard EDK driver.
>
Supports static platform_device and static device tree configuration.
This is a standalone driver that does not depend on EDK generated
files. However, it is also somewhat different in functionality from
the standard EDK driver.
1) The EDK driver doesn't support readback, which this driver does.
On Wednesday 05 December 2007, Timur Tabi wrote:
> Arnd Bergmann wrote:
>
> > You can argue that the QS is really a DMA device, but in that case you
> > should convert the driver to use the DMA mapping interfaces correctly,
> > which I would consider overkill.
>
> I'm confused. I'm already calli
Timur Tabi wrote:
>
> In other words, the only thing you get is the first letter of the device
> name.
> You used to get the whole name. The physical address obviously isn't very
> helpful.
The physical address certainly is useful when you have more than one
device of the same name.
> Now,
Arnd Bergmann wrote:
> You can argue that the QS is really a DMA device, but in that case you
> should convert the driver to use the DMA mapping interfaces correctly,
> which I would consider overkill.
I'm confused. I'm already calling dma_alloc_coherent() and getting a
dma_addr_t
back. Why d
Markus and Greg,
I've found a problem with this patch that probably affects a number of embedded
PowerPC systems:
http://marc.info/?l=linux-kernel&m=119222892713518&w=2
The problem is that the device name for many PowerPC SoC devices is based on
the
physical address. So we have stuff like th
Arnd Bergmann wrote:
> On Wednesday 05 December 2007, Scott Wood wrote:
>>> You can argue that the QS is really a DMA device, but in that
>>> case you should convert the driver to use the DMA mapping
>>> interfaces correctly, which I would consider overkill.
>> Why is it overkill?
>>
>
> Well, if
This patch extends dtc syntax to allow references (&label, or
&{/full/path}) directly within property definitions, rather than
inside a cell list. Such references are expanded to the full path of
the referenced node, as a string, instead of to a phandle as
references within cell lists are evaluate
On Wednesday 05 December 2007, Scott Wood wrote:
>
> > You can argue that the QS is really a DMA device, but in that case you
> > should convert the driver to use the DMA mapping interfaces correctly,
> > which I would consider overkill.
>
> Why is it overkill?
>
Well, if the QE can never be us
On Dec 4, 2007, at 4:20 PM, David Gibson wrote:
> On Tue, Dec 04, 2007 at 10:33:20AM -0600, Kumar Gala wrote:
>> Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
>
> You know, the whole batch of fprintf()s of header information in
> dt_from_blob() are really just a debugging hack that uglifies dtc's
"Add an option to pad the blob that is generated" broke the padding
support. We were updating the fdt header after writing it.
Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
---
Better commit message for this, since my commit ID is different.
flattree.c | 12 +++-
1 files changed, 7 i
Arnd Bergmann wrote:
> From a code clarity perspective, the interesting point is that dma_addr_t is
> what comes back from the functions in dma-mapping.h. If you don't use them,
> a physical address is phys_addr_t.
>
> You can argue that the QS is really a DMA device, but in that case you
> should
On several occasions, I've accidentally put properties after subnodes
in a dts file. I've then spent ages thinking that the resulting
syntax error was because of something else.
This patch arranges for this specific syntax error to generate a more
specific and useful error message.
Signed-off-by
On Tuesday 04 December 2007, Timur Tabi wrote:
> When I program the DMA controller, I give it a dma_addr_t. And yet, the DMA
> controller and the QE are both devices on the SoC. So if the DMA controller
> takes a dma_addr_t, then shouldn't the QE also take one?
>
>From a code clarity perspect
Hallo Tony,
Tony Breeds <[EMAIL PROTECTED]> wrote:
> The commit fa13a5a1f25f671d084d8884be96fc48d9b68275 (sched: restore
> deterministic CPU accounting on powerpc), unconditionally calls
> update_process_tick() in system context. In the deterministic accounting case
> this is the correct thing to
This patch applies a couple of tiny cleanups to the lexer. The
not-very-useful 'WS' named pattern is removed, and the debugging
printf() for single character tokens is moved to the top of the
action, which results in less confusing output when LEXDEBUG is
switched on (because it goes before the pr
This patch removes the old-style checking code for the "name" property
- i.e. verifying that the "name" property, if present, matches the
node name. It replaces it with a pair of more-or-less equivalent
checks in the new checking framework.
This also promotes this check to a "structural" check, o
The way the checking subsystem FAIL() macro is currently implemented
it must take at least one paramater after the format string. This
patch corrects the problem.
Signed-off-by: David Gibson <[EMAIL PROTECTED]>
Index: dtc/checks.c
=
Arnd Bergmann wrote:
> I'm guessing that you don't really mean dma_addr_t here, but rather
> phys_addr_t, which is something different.
Now that I think about it, I don't know which is correct. The value is plugged
into the pointer register of a buffer descriptor, and the QE performs a
DMA-lik
On Wed, 5 Dec 2007 09:21:21 +1100
Paul Mackerras <[EMAIL PROTECTED]> wrote:
> David Woodhouse writes:
>
> > I think this is a bad idea -- it's hardly a difficult for those people
> > who _do_ need dts to obtain it separately.
>
> The trouble is that it's not just people who are making a kernel f
On Wed, 2007-12-05 at 09:21 +1100, Paul Mackerras wrote:
> David Woodhouse writes:
>
> > I think this is a bad idea -- it's hardly a difficult for those people
> > who _do_ need dts to obtain it separately.
>
> The trouble is that it's not just people who are making a kernel for a
> specific embe
Arnd Bergmann wrote:
> Can you use the driver on CPUs without this particular bug when it's built
> in Soft-UART mode?
No, you have to build with Soft-UART mode turned off. Soft-UART mode actually
uses the HMC mode of the QE and hacks it up to act like a UART.
The only way to know at runtime w
David Woodhouse writes:
> I think this is a bad idea -- it's hardly a difficult for those people
> who _do_ need dts to obtain it separately.
The trouble is that it's not just people who are making a kernel for a
specific embedded board that need dtc. These days anyone who wants to
try cross-com
On Tue, Dec 04, 2007 at 10:33:20AM -0600, Kumar Gala wrote:
> Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
You know, the whole batch of fprintf()s of header information in
dt_from_blob() are really just a debugging hack that uglifies dtc's
output. The whole lot could be moved over to ftdump inst
I guess it was really git commit
2b7dc8dce549ad72ad437b254bf756d7ba4c2a5a
Add an option to pad the blob that is generated
- k
On Dec 4, 2007, at 4:04 PM, David Gibson wrote:
> On Tue, Dec 04, 2007 at 10:27:52AM -0600, Kumar Gala wrote:
>> commit 22e787ca2b1e49a9a0f3c43262564ab1038c5c3c broke
On Tue, Dec 04, 2007 at 10:04:53AM -0600, Kumar Gala wrote:
>
> On Dec 4, 2007, at 9:26 AM, Josh Boyer wrote:
>
> > On Tue, 04 Dec 2007 07:25:57 -0600
> > Jon Loeliger <[EMAIL PROTECTED]> wrote:
> >
> >> So, like, the other day David Woodhouse mumbled:
> >>>
> >>> I think this is a bad idea -- it
On Tuesday 04 December 2007, Timur Tabi wrote:
> Add support for UART serial ports using a Freescale QUICC Engine
> (found on some MPC83xx and MPC85xx SOCs).
>
> Because of a silicon bug in some QE-enabled SOCs (e.g. 8323 and 8360), a new
> microcode is required. This microcode implements UART via
On Tuesday 04 December 2007, Benjamin Herrenschmidt wrote:
> > 2. The call to firmware_has_feature() turns into a compile-time check
> > in
> > many cases, so if the kernel does not contain support for any firmware
> > with the given feature, all the code referenced it can get optimized
> > away by
On Tue, Dec 04, 2007 at 10:27:52AM -0600, Kumar Gala wrote:
> commit 22e787ca2b1e49a9a0f3c43262564ab1038c5c3c broke the padding
> support. We were updating the fdt header after writing it.
Uh.. I can't find a commit with that SHA1. Which one are you
referring to?
--
David Gibson
On Tuesday 04 December 2007, Benjamin Herrenschmidt wrote:
> On Tue, 2007-12-04 at 20:35 +0100, Arnd Bergmann wrote:
> >
> > 1. If another platform gets added that uses the same firmware feature,
> > it
> > will automatically do the right thing.
>
> Yes but is it something that we want to happen
Geert Uytterhoeven wrote:
> On Tue, 4 Dec 2007, Grant Likely wrote:
>> On 12/4/07, Geert Uytterhoeven <[EMAIL PROTECTED]> wrote:
>> > On Sat, 1 Dec 2007, Grant Likely wrote:
>> > > From: Grant Likely <[EMAIL PROTECTED]>
>> > >
>> > > This patch makes the platform code use the new machine-specific i
On Tue, Dec 04, 2007 at 03:50:03PM -0500, Jeff Garzik wrote:
> Olof Johansson wrote:
>> [POWERPC] Move electra-ide support over to new pata_of_platform framework
>> Move electra-ide glue over to the new pata_of_platform framework, and
>> add the quirks needed to that driver.
>> Signed-off-by: Olof
On 12/4/07, Stephen Neuendorffer <[EMAIL PROTECTED]> wrote:
> This code is needed to boot without a boot loader.
>
> Grant: I'm not sure where the right place to put this is. I'm assuming
> we'll actually need some boot code that is not generic? Also, note that
> there is a V4FX errata workaro
* Kamalesh Babulal <[EMAIL PROTECTED]> wrote:
> Hi Ingo,
>
> This softlockup is seen in the 2.6.24-rc4 either and looks like a
> message because this is seen while running tbench and machine
> continues running other test's after the softlockup messages and some
> times seen with the bootup,
Olof Johansson wrote:
> [POWERPC] Move electra-ide support over to new pata_of_platform framework
>
> Move electra-ide glue over to the new pata_of_platform framework, and
> add the quirks needed to that driver.
>
>
> Signed-off-by: Olof Johansson <[EMAIL PROTECTED]>
>
> ---
>
> I'll remove th
This code is needed to boot without a boot loader.
Grant: I'm not sure where the right place to put this is. I'm assuming we'll
actually need some boot code that is not generic? Also, note that there is a
V4FX errata workaround in arch/ppc/boot/head.S, which probably also needs to
get pulled
[POWERPC] Move electra-ide support over to new pata_of_platform framework
Move electra-ide glue over to the new pata_of_platform framework, and
add the quirks needed to that driver.
Signed-off-by: Olof Johansson <[EMAIL PROTECTED]>
---
I'll remove the electra-ide stuff from arch/powerpc/platfo
On Tue, Dec 04, 2007 at 08:06:25PM +0300, Anton Vorontsov wrote:
> Split pata_platform_{probe,remove} into two pieces:
> 1. pata_platform_{probe,remove} -- platform_device-dependant bits;
> 2. __ptata_platform_{probe,remove} -- device type neutral bits.
>
> This is done to not duplicate code for t
On Tue, Dec 04, 2007 at 10:45:31PM +0300, Anton Vorontsov wrote:
> This patch adds localbus and pata nodes to use CF IDE interface
> on MPC8349E-mITX boards.
>
> Patch also adds code to probe localbus.
>
> Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
Acked-by: Olof Johansson <[EMAIL PROTEC
On Tue, Dec 04, 2007 at 11:37:51PM +0300, Anton Vorontsov wrote:
> On Tue, Dec 04, 2007 at 02:01:21PM -0600, Olof Johansson wrote:
> > On Tue, Dec 04, 2007 at 10:49:21PM +0300, Anton Vorontsov wrote:
> > > tristate "Generic platform device PATA support"
> > > - depends on EMBEDDED || ARCH_RPC
> >
On Tue, Dec 04, 2007 at 02:01:21PM -0600, Olof Johansson wrote:
> On Tue, Dec 04, 2007 at 10:49:21PM +0300, Anton Vorontsov wrote:
> > tristate "Generic platform device PATA support"
> > - depends on EMBEDDED || ARCH_RPC
> > + depends on EMBEDDED || ARCH_PPC
>
> It needs to be || PPC, not
On Tue, 2007-12-04 at 20:35 +0100, Arnd Bergmann wrote:
>
> 1. If another platform gets added that uses the same firmware feature,
> it
> will automatically do the right thing.
Yes but is it something that we want to happen ? That is, do we want
code somewhere in a platform/foo dir to run when u
On Tue, 2007-12-04 at 13:05 -0700, Grant Likely wrote:
> We could simply have the setup code copy the ppc_md.power_off pointer
> into pm_power_off; that we retain the nice assignment in
> define_machine(), but eliminate the duplicated calls.
Good idea.
Ben.
Grant Likely wrote:
> From: Grant Likely <[EMAIL PROTECTED]>
>
> This patch eliminates the warning of unused return values when the driver
> registers it sysfs files. Now the driver will print an error if it is
> unable to register the sysfs files.
>
> It also eliminates the macros used to wrap
Vitaly Bordug wrote:
> With that patch fixed.c now fully emulates MDIO bus, thus no need
> to duplicate PHY layer functionality. That, in turn, drastically
> simplifies the code, and drops down line count.
>
> As an additional bonus, now there is no need to register MDIO bus
> for each PHY, all em
Grant Likely wrote:
> From: Grant Likely <[EMAIL PROTECTED]>
>
> Eliminate an uninitialized variable warning. The code is correct, but
> a pointer to the automatic variable 'addr' is passed to dma_alloc_coherent.
> Since addr has never been initialized, and the compiler doesn't know
> what dma_al
On 12/4/07, Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote:
>
> On Tue, 2007-12-04 at 11:01 -0700, Mark A. Greer wrote:
> > On Tue, Dec 04, 2007 at 06:23:09PM +1100, Benjamin Herrenschmidt wrote:
> > >
> > > On Mon, 2007-12-03 at 22:48 -0700, Mark A. Greer wrote:
> > > > From: Mark A. Greer <[EMA
On Nov 28, 2007, at 13:56, David Woodhouse wrote:
> This kind of sucks, and prevents the Fedora installer from using the
> device for network installs...
>
> [EMAIL PROTECTED] phy]# iwconfig eth0
> Warning: Driver for device eth0 has been compiled with an ancient
> version
> of Wireless Extensi
On Tue, 2007-12-04 at 13:39 +0100, Geert Uytterhoeven wrote:
>
> Can we please have them in ? They look very useful to
> me
> elsewhere (other bus drivers, device drivers), too.
>
> What about naming the printf format specifier macros more like in C99,
> e.g.
> PRI*?
That's a can of worms I jus
1 - 100 of 158 matches
Mail list logo
