Based on BenH's earlier work, this is a new version of the EMAC driver
for the built-in ethernet found on PowerPC 4xx embedded CPUs. The
same ASIC is also found in the Axon bridge chip. This new version is
designed to work in the arch/powerpc tree, using the device tree to
probe the device, rathe
The 440 family of processors don't have a tlbie instruction. So, we
implement TLB invalidates by explicitly searching the TLB with tlbsx.,
then clobbering the relevant entry, if any. Unfortunately the PID for
the search needs to be stored in the MMUCR register, which is also
used by the TLB miss
I'm almost sorry I spoke up...
Matt Sealey writes the following:
>
>Okay before you add to the nvramrc you also need to add probe-all to build the
>device tree first; I assumed this was common knowledge.
Maybe for experienced OpenFirmware developers; this is the first time I've
had to touch the s
On Mon, Aug 06, 2007 at 07:08:25PM -0500, Josh Boyer wrote:
> On Mon, Aug 06, 2007 at 06:10:29PM -0300, [EMAIL PROTECTED] wrote:
> > Hello guys,
> >
> > I'm just writting to know if someone have some opinion about the patch I
> > sent a week ago. I'm not sending it again cause I'm traveling and
On Mon, Aug 06, 2007 at 10:15:39PM +0200, Segher Boessenkool wrote:
> >>> + UIC0: interrupt-controller0 {
> >>> + compatible = "ibm,uic-440gp","ibm,uic";
> >>
> >> The first compatible entry should always be the precise model, so in
> >> this case "ibm,uic-440epx". If it is (supposed to be
On Mon, Aug 06, 2007 at 10:54:33PM +0200, Segher Boessenkool wrote:
> > Aha! Ok, now I understand the sorts of situations you're talking
> > about. By "not direct mapped", I thought you were talking about some
> > kind of access via address/data registers on some indirect bus
> > controller, rath
On Mon, Aug 06, 2007 at 10:35:57PM +0200, Segher Boessenkool wrote:
> >> To be honest, I'm not sure that describing the mapping is really the
> >> job of the compatible property. That the flash is mapped into the
> >> address space is kind of implicit in the way the reg interacts with
> >> the par
On Fri, Aug 03, 2007 at 11:09:10AM -0500, Josh Boyer wrote:
> Add a bootwrapper for the AMCC 440EP Bamboo Eval board. This also adds a
> common fixup_clock function for all 440EP(x) chips.
>
> Signed-off-by: Josh Boyer <[EMAIL PROTECTED]>
Acked-by: David Gibson <[EMAIL PROTECTED]>
--
David Gib
On Mon, Aug 06, 2007 at 07:31:44AM -0500, Josh Boyer wrote:
> On Sat, Aug 04, 2007 at 05:45:38PM +1000, David Gibson wrote:
> > On Fri, Aug 03, 2007 at 11:09:02AM -0500, Josh Boyer wrote:
> > > Remove some leftover cruft in the 40x Kconfig file. Also make sure we
> > > select WANT_DEVICE_TREE for
On Mon, Aug 06, 2007 at 07:36:03AM -0500, Josh Boyer wrote:
> On Mon, Aug 06, 2007 at 02:38:55PM +1000, David Gibson wrote:
> > On Fri, Aug 03, 2007 at 11:09:04AM -0500, Josh Boyer wrote:
> > > -#define SPRN_DBCR0 0x134
> > > -#define DBCR0_RST_SYSTEM 0x3000
> > > +#define
On Mon, Aug 06, 2007 at 07:39:02AM -0500, Josh Boyer wrote:
> On Mon, Aug 06, 2007 at 03:00:12PM +1000, David Gibson wrote:
> > On Fri, Aug 03, 2007 at 11:09:10AM -0500, Josh Boyer wrote:
> > > Add a bootwrapper for the AMCC 440EP Bamboo Eval board. This also adds a
> > > common fixup_clock functi
On Mon, Aug 06, 2007 at 09:59:24PM +0200, Segher Boessenkool wrote:
> >>> Yeah, better names please -- if possible, something that someone
> >>> without knowledge of this SoC will understand what it is.
> >>
> >> I think the names are probably ok - I'm assuming they're in keeping
> >> with the conv
On Mon, Aug 06, 2007 at 10:20:01PM +0200, Segher Boessenkool wrote:
> >>> + - compatible : should contain the specific model of flash
> >>> chip(s) used
> >>> + followed by either "cfi-flash" or "jedec-flash"
> >>
> >> This "compatible" prop (and the node in whole) doesn't say a
> >>
On Tue, Aug 07, 2007 at 08:15:23AM +1000, Benjamin Herrenschmidt wrote:
> On Mon, 2007-08-06 at 22:37 +0400, Sergei Shtylyov wrote:
> >
> > Actually, checking for the presence of all possible perverted
> > mapping
> > props doesn't seem a good idea -- it's simpler to check for the
> > presenc
On Mon, Aug 06, 2007 at 10:37:14PM +0400, Sergei Shtylyov wrote:
> Hello.
[snip]
> >>>Can you describe some of the options for *not* direct mapped flash
> >>>chips - I can't reasonably come up with a way of describing the
> >>>distinction when I've never seen NOR flash other than direct mapped.
>
Hi, Michael,
I get them. Thanks for your work! :)
Best Regards,
Zhang Wei
> -Original Message-
> From: Michael Ellerman [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, August 07, 2007 11:19 AM
> To: Zang Roy-r61911
> Cc: Kumar Gala; linuxppc-dev list; Paul Mackerras; Zhang Wei-r63237
> Subje
On Tue, 2007-08-07 at 10:57 +0800, Zang Roy-r61911 wrote:
> On Tue, 2007-08-07 at 09:06, Michael Ellerman wrote:
> > On Mon, 2007-08-06 at 08:57 -0500, Kumar Gala wrote:
> > > On Aug 6, 2007, at 12:57 AM, Zhang Wei-r63237 wrote:
> > >
> > > > Hi, Paul,
> > > >
> > > > How about following patches?
On Tue, 2007-08-07 at 09:06, Michael Ellerman wrote:
> On Mon, 2007-08-06 at 08:57 -0500, Kumar Gala wrote:
> > On Aug 6, 2007, at 12:57 AM, Zhang Wei-r63237 wrote:
> >
> > > Hi, Paul,
> > >
> > > How about following patches?
> > >
> > > [PATCH 1/2] Add sysdev/pci_quirks.c file into PowerPC
> arch
Stefan Richter <[EMAIL PROTECTED]> writes:
>
> 1.) The ieee1394 subsystem is known to work on x86_64 with more than 4
> GB RAM,
It's actually ~3+GB where memory above the 4GB barrier starts appearing.
In some extreme cases even for 2+GB.
> so I gather that architecture code already sets a pr
On Mon, 2007-08-06 at 08:57 -0500, Kumar Gala wrote:
> On Aug 6, 2007, at 12:57 AM, Zhang Wei-r63237 wrote:
>
> > Hi, Paul,
> >
> > How about following patches?
> >
> > [PATCH 1/2] Add sysdev/pci_quirks.c file into PowerPC architecture
> > with
> > ULI chip quirk functions.
> > URL: http://ozlab
On Mon, Aug 06, 2007 at 06:10:29PM -0300, [EMAIL PROTECTED] wrote:
> Hello guys,
>
> I'm just writting to know if someone have some opinion about the patch I
> sent a week ago. I'm not sending it again cause I'm traveling and don't
> have it here in this machine.
Sorry Rodrigo. I'll try to fi
Stefan Richter wrote:
> Benjamin Herrenschmidt wrote:
>> Oh and, don't do the set_dma_mask() in sbp2, it has nothing to do there.
>> It should be in the ohci1394 driver.
>
> That's not quite right. OHCI-1394 implementations can go beyond 4GB bus
> address space. (Although I don't know if there a
>> It seems like things go wrong when lparmap.s is generated with
>> (DWARF) debug info; could you try building it (manually) with -g0
>> added on the end of the compile line, and see if head_64.o compiles
>> okay for you then? If so, I'll prepare a proper patch for it, I
>> have a similar one (al
>> Actually, checking for the presence of all possible perverted
>> mapping
>> props doesn't seem a good idea -- it's simpler to check for the
>> presence of
>> one prop (like "direct-mapped" I was thinking about, or maybe
>> "simple-map").
>
> Or more simply... if it's not a direct mapping, it
Benjamin Herrenschmidt wrote:
> On Mon, 2007-08-06 at 16:25 -0600, Robert Hancock wrote:
>>> Anyway. For now I will simply go with what 2.6.23-rc has and what
>>> 2.6.21 had: No dma_set_mask anywhere in the 1394 subsystem. We can
>>> revisit this whenever an actual need arises.
>> Not sure this
Robert Hancock wrote:
> I would agree, though, that sbp2 isn't really the place for setting
> this, since the DMA mask is presently a property of the device, not of
> the user..
The mask that sbp2 set was because sbp2 has (in theory, not yet in
practice) a _narrower requirement on address ranges t
Robert Hancock wrote:
> Stefan Richter wrote:
>> So that's the story why that dma_set_mask went into sbp2: Sbp2 wants
>> mappings in a _subset_ of the OHCI-1394 controllers DMA range.
>>
>> Anyway. For now I will simply go with what 2.6.23-rc has and what
>> 2.6.21 had: No dma_set_mask anywhere
> >>> Second issue as reported earilier allmodconfig fails to build on imac
> >>> g3.
> >>>
> >>> CC arch/powerpc/kernel/lparmap.s
> >>> AS arch/powerpc/kernel/head_64.o
> >>> lparmap.c: Assembler messages:
> >>> lparmap.c:84: Error: file number 1 already allocated
> >>> make[1]: ***
On Mon, 2007-08-06 at 16:25 -0600, Robert Hancock wrote:
> > Anyway. For now I will simply go with what 2.6.23-rc has and what
> > 2.6.21 had: No dma_set_mask anywhere in the 1394 subsystem. We can
> > revisit this whenever an actual need arises.
>
> Not sure this is a very good idea. This seem
On Tue, Aug 07, Benjamin Herrenschmidt wrote:
> powerpc has a couple of bugs in the usage of dma_masks that tend to
> break when drivers explicitely try to set a 32 bits mask for example.
>
> First the code that generates the pci devices from the OF device-tree
> doesn't initialize the mask prope
On Tue, 2007-08-07 at 00:22 +0200, Stefan Richter wrote:
> Benjamin Herrenschmidt wrote:
> > Oh and, don't do the set_dma_mask() in sbp2, it has nothing to do there.
> > It should be in the ohci1394 driver.
>
> That's not quite right. OHCI-1394 implementations can go beyond 4GB bus
> address spac
Paul Mackerras wrote:
> diff --git a/arch/powerpc/mm/slb.c b/arch/powerpc/mm/slb.c
>
A couple of hunks fail in this file when applying to the current tree.
...
> diff --git a/include/asm-powerpc/mmu-hash64.h
> b/include/asm-powerpc/mmu-hash64.h
> index 695962f..053f86b 100644
> --- a/include/a
Benjamin Herrenschmidt wrote:
> Oh and, don't do the set_dma_mask() in sbp2, it has nothing to do there.
> It should be in the ohci1394 driver.
That's not quite right. OHCI-1394 implementations can go beyond 4GB bus
address space. (Although I don't know if there are such implementations
availabl
On Mon, 2007-08-06 at 22:37 +0400, Sergei Shtylyov wrote:
>
> Actually, checking for the presence of all possible perverted
> mapping
> props doesn't seem a good idea -- it's simpler to check for the
> presence of
> one prop (like "direct-mapped" I was thinking about, or maybe
> "simple-map"
On Mon, 2007-08-06 at 20:04 +0200, Segher Boessenkool wrote:
> That's of course the smarter choice, _if_ we have a choice at
> all -- on PowerPC, the PCI setup on certain platforms is done
> by the firmware (and we don't want to mess with it for various
> reasons), and some _do_ map PCI legacy I/O
>>> + max-speed-hz = ; /* 1250 Hz
>>> */
Just max-speed.
>>>
>>> Segher, how is this different from:
>>>
>>> http://ozlabs.org/pipermail/linuxppc-dev/2007-April/034557.html
>>
>> Not sure what you mean. I'm just saying that "speed-hz" is a
>> te
powerpc has a couple of bugs in the usage of dma_masks that tend to
break when drivers explicitely try to set a 32 bits mask for example.
First the code that generates the pci devices from the OF device-tree
doesn't initialize the mask properly, then our implementation of
set_dma_mask() was trying
> 2) The fix was in the wrong place anyway, if it was going to be done
> anywhere
> at all it needs to be in
> arch/powerpc/kernel/prom_init.c:fixup_device_tree_chrp()
> like the ISA ranges breakage (which is on Briq) and IDE IRQ
> misnumbering fix.
> Not the keyboard platform driver.
Yeah. In
On Mon, 2007-08-06 at 15:51 +0200, Olaf Hering wrote:
> On Mon, Aug 06, Benjamin Herrenschmidt wrote:
>
> > BTW. Any reason why you don't set the DMA mask in the ohci driver rather
> > than the sbp2 one ?
>
> I used this patch, and the attached CD was found.
> What dma mask should be used in ohci
On Mon, 2007-08-06 at 13:58 +0200, Olaf Hering wrote:
> On Sun, Aug 05, Stefan Richter wrote:
>
> > Benjamin Herrenschmidt wrote:
> > >>> If setting 32-bit DMA mask fails on ppc64, that sounds like a problem
> > >>> with the DMA implementation on that architecture. There are enough cards
> > >>> o
Okay before you add to the nvramrc you also need to add probe-all to build the
device tree first; I assumed this was common knowledge.
probe-all
" /pci/isa/8042" find-device
" 8042" encode-string device-type
install-console
banner
That should do it. Without probe-all/install-console/banner in the
On Mon, 6 Aug 2007 20:25:13 +0200
Segher Boessenkool <[EMAIL PROTECTED]> wrote:
> > + max-speed-hz = ; /* 1250 Hz
> > */
> >>
> >> Just max-speed.
> >
> > Segher, how is this different from:
> >
> > http://ozlabs.org/pipermail/linuxppc-dev/2007-April/0345
Arnd Bergmann wrote:
> On Saturday 04 August 2007, Geoff Levand wrote:
>>
>> From: Andre Detsch <[EMAIL PROTECTED]>
>>
>> This patch moves affinity initialization code from spu_base.c to a
>> new spu_management_of_ops function (init_affinity), which is empty
>> in the case of PS3. This fixes a li
>>> Second issue as reported earilier allmodconfig fails to build on imac
>>> g3.
>>>
>>> CC arch/powerpc/kernel/lparmap.s
>>> AS arch/powerpc/kernel/head_64.o
>>> lparmap.c: Assembler messages:
>>> lparmap.c:84: Error: file number 1 already allocated
>>> make[1]: *** [arch/powerpc/ke
Hello guys,
I'm just writting to know if someone have some opinion about the patch I
sent a week ago. I'm not sending it again cause I'm traveling and don't
have it here in this machine.
Tks,
Rodrigo (BSDaemon).___
Linuxppc-dev mailing list
Linuxpp
>> "bit-swizzling" or something which can be defined to describe some odd
>> connections. If absent we'd default to direct mapping. Segher, is
>> that idea going to cause you to scream?
>
> Actually, checking for the presence of all possible perverted
> mapping
> props doesn't seem a good id
>>> + - compatible : should contain the specific model of flash
>>> chip(s) used
>>> + followed by either "cfi-flash" or "jedec-flash"
>>
>> Duh, have nearly forgotten to complain about "-flash" suffix.
>> Isn't it
>> superfluous?
>
> For CFI, I guess so. But don't JEDEC standardi
> Aha! Ok, now I understand the sorts of situations you're talking
> about. By "not direct mapped", I thought you were talking about some
> kind of access via address/data registers on some indirect bus
> controller, rather than weird variations on endianness and
> bit-swizzling.
>
> Hrm.. this i
>> + - compatible : should contain the specific model of flash
>> chip(s) used
>> + followed by either "cfi-flash" or "jedec-flash"
>
>Duh, have nearly forgotten to complain about "-flash" suffix.
> Isn't it superfluous?
No, it describes what kind of thing this is. "cfi" and "jed
>> To be honest, I'm not sure that describing the mapping is really the
>> job of the compatible property. That the flash is mapped into the
>> address space is kind of implicit in the way the reg interacts with
>> the parents' ranges property.
>
> Ah, I keep forgetting about implied 1:1 paren
>>> + - compatible : should contain the specific model of flash
>>> chip(s) used
>>> + followed by either "cfi-flash" or "jedec-flash"
>>
>> This "compatible" prop (and the node in whole) doesn't say a
>> thing about how the flash is mapped into the CPU address space. I
>> strongly
>>> + UIC0: interrupt-controller0 {
>>> + compatible = "ibm,uic-440gp","ibm,uic";
>>
>> The first compatible entry should always be the precise model, so in
>> this case "ibm,uic-440epx". If it is (supposed to be) identical to
>> the UIC in the 440GP, it can also have an "ibm,uic-440gp
>> + - compatible : should contain the specific model of flash
>> chip(s) used
>> + followed by either "cfi-flash" or "jedec-flash"
>
>This "compatible" prop (and the node in whole) doesn't say a thing
> about how the flash is mapped into the CPU address space.
...and it shouldn't.
>>> Yeah, better names please -- if possible, something that someone
>>> without knowledge of this SoC will understand what it is.
>>
>> I think the names are probably ok - I'm assuming they're in keeping
>> with the convention I've used of using the same names / abbreviations
>> as in the CPU user
On Mon, 6 Aug 2007, Segher Boessenkool wrote:
> > Maybe the best solution would be for 824[15] to not claim compatibility
> > with 8250 at all then.
>
> Or at least it should have a more specific entry for this
> "special" 16x50 UART, and that one should be probed first.
>
> > If the device tree
O> That's of course the smarter choice, _if_ we have a choice at
> all -- on PowerPC, the PCI setup on certain platforms is done
> by the firmware (and we don't want to mess with it for various
> reasons), and some _do_ map PCI legacy I/O at 0.
>
> Not in this case though, so let's just ignore tha
>> However, the interrupt mapping spec says that all interrupt
>> controller (regardless of device_type) must have a
>> property named "interrupt-controller" to identify
>> the device node as an interrupt controller and root of
>> a interrupt tree.
>> See: http://playground.sun.com/1275/practice/im
>> It seems to me a flat device tree could leave out all those
>> properties that can be derived from the PVR (except for the
>> few that are really useful for bootloaders and such -- cache
>> line size, 64-bit-or-not, what kind of MMU). Linux doesn't
>> use it anyway. Existing DTSs already leave
+ MPIC: [EMAIL PROTECTED] {
+ device_type = "open-pic";
device_type = "interrupt-controller".
>>
>> Not according to the binding in booting-without-of.txt
>
> My understanding here, though possibly flawed, is that the current
> implementation has "open-
Removes the use of bitfields from the ibmveth driver. This results
in slightly smaller object code.
Signed-off-by: Brian King <[EMAIL PROTECTED]>
---
linux-2.6-bjking1/drivers/net/ibmveth.c | 90
linux-2.6-bjking1/drivers/net/ibmveth.h | 56 -
Removes dead frag processing code from ibmveth. Since NETIF_F_SG was
not set, this code was never executed. Also, since the ibmveth
interface can only handle 6 fragments, core networking code would need
to be modified in order to efficiently enable this support.
Signed-off-by: Brian King <[EMAIL
>>> + PIC8259: interrupt-controller {
>>> + device_type = "i8259";
>>>
>>> device_type = "interrupt-controller".
>
> Is that really right? The MPIC binding, at least, has device_type =
> "open-pic" rather than "interrupt-controller".
I got confused. "o
Add ethtool hooks to ibmveth to retrieve driver statistics.
Signed-off-by: Brian King <[EMAIL PROTECTED]>
---
drivers/net/ibmveth.c | 53 +-
1 file changed, 52 insertions(+), 1 deletion(-)
diff -puN drivers/net/ibmveth.c~ibmveth_ethtool_driver_
Add handlers for get_tso and get_ufo to prevent errors being printed
by ethtool.
Signed-off-by: Brian King <[EMAIL PROTECTED]>
---
drivers/net/ibmveth.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff -puN drivers/net/ibmveth.c~ibmveth_ethtool_get_tso drivers/net/ibmveth.c
---
This patch adds the appropriate ethtool hooks to allow for enabling/disabling
of hypervisor assisted checksum offload for TCP.
Signed-off-by: Brian King <[EMAIL PROTECTED]>
---
linux-2.6-bjking1/drivers/net/ibmveth.c | 118 +++-
linux-2.6-bjking1/drivers/net/ibmveth
This patchset enables TCP checksum offload support for IPV4
on ibmveth. This completely eliminates the generation and checking of
the checksum for packets that are completely virtual and never
touch a physical network. A simple TCP_STREAM netperf run on
a virtual network with maximum mtu set yield
>>> Ok, figured out why. When I push, then pop a quilt patch some of the
>>> files end up with their original contents, but changed timestamps.
>>> That altered stat information causes git-diff-index to give false
>>> indications of changed files, so setlocalversion adds the -dirty.
>>> Running gi
> Maybe the best solution would be for 824[15] to not claim compatibility
> with 8250 at all then.
Or at least it should have a more specific entry for this
"special" 16x50 UART, and that one should be probed first.
> If the device tree contains an entry that matches
> what the generic driver loo
On Sat, Aug 04, 2007 at 12:31:28PM +1000, Benjamin Herrenschmidt wrote:
>
> Paulus stuff is likely to be unrelated to your bug. Also, whatever blurb
> you pasted in this email is totally incomprehensible due to total lack
> of context.
Sorry. Mike Strosaker nailed it; its a nutty hypervisor bug.
> Another option altogether would be to allow the device node to
> specify the linux specific serial port flags in a separate property,
> like "linux,uart-port-flags" that contains the same flags that
> setserial can set from user space. That would also be useful
> if you want to specify UPF_MAGIC_
> Some how your defconfig is targeting a PPC64 box:
>
> CONFIG_PPC64=y
>
> shouldn't be set if you want to build a kernel for a G3 imac.
allyesconfig/allmodconfig select a 64-bit build always. Maybe
it shouldn't.
Segher
___
Linuxppc-dev mailing list
On 2 aug 2007, at 12:14, Mariusz Kozlowski wrote:
>>> Second issue as reported earilier allmodconfig fails to build on
>>> imac g3.
>>
>> Do you really mean g3? If so it's a 32-bit kernel and it shouldn't be
>> building lparmap.s.
It might be a bug nevertheless, there are more "issues" with
th
> Second issue as reported earilier allmodconfig fails to build on imac
> g3.
>
> CC arch/powerpc/kernel/lparmap.s
> AS arch/powerpc/kernel/head_64.o
> lparmap.c: Assembler messages:
> lparmap.c:84: Error: file number 1 already allocated
> make[1]: *** [arch/powerpc/kernel/head_64.o]
>> +[EMAIL PROTECTED] {
>> +reg = <0>;
>> +pio-handle = <&mmc0pio>;
>> +};
>> };
>
> I'm still against this. Why don't we just do this in
> 83xx/mpc832x_rdb.c
Seconded.
Segher
Segher Boessenkool wrote:
>>p.s. mpc8272ads.dts is broken wrt spaces/tabs, very.
>
>
> Care to do a cleanup patch? Good for your karma ;-)
I've got one in my 82xx patchset (a respin of which should be coming soon).
There's a lot more broken in there than just spaces/tabs, BTW. :-)
-Scott
>> You don't need to patch Linux at all. In fact for silly things like
>> this
>> I would recommend against it :)
>
> If the workaround doesn't go into the kernel, everybody with affected
> hardware has to individually find out about the bug (probably by
> experiencing
> an annoying keyboardless
>> The network address is passed to OF as (part of) the device
>> argument for the network device; and colons aren't legal
>> characters in a device argument,
>
> yeah, pretty thoughtless of the IETF for not consulting the 1275WG. :)
Heh. That's not an issue; it just means that OF implementations
Hello.
David Gibson wrote:
>Index: working-2.6/Documentation/powerpc/booting-without-of.txt
>===
>--- working-2.6.orig/Documentation/powerpc/booting-without-of.txt
>2007-07-30 17:07:14.0 +1000
>+++ worki
> + max-speed-hz = ; /* 1250 Hz */
>>
>> Just max-speed.
>
> Segher, how is this different from:
>
> http://ozlabs.org/pipermail/linuxppc-dev/2007-April/034557.html
Not sure what you mean. I'm just saying that "speed-hz" is a
terrible name, I'm not saying that "max
>> For some buses, there is a "slot-names" property; some (non-core)
>> bindings seem to define a "location" property.
>> For "random" human-readable labelling, i.e. not corresponding to
>> physical markings on the hardware, I recommend you look for a
>> matching entry in /aliases.
>
> Aliases coul
> [EMAIL PROTECTED] {
> device_type = "spi";
> + device-id = <1>;
Can we just use the reg value for bus_num in the kernel.
>>>
>>> Sure, technically nothing prevents this. But, QE specs names
>>> SPIs by these ids.
>>
>> As a minimum
>>> + spi1pio:[EMAIL PROTECTED] {
>>
>> There should be whitespace after the label. @01 should be
>> spelled @1. Except there is no "reg" property.
>
> Hm. I've just tried to keep original style in this particular dts.
> Want to ack patch below?
Not unless you get rid of the ex
On Aug 3, 2007, at 17:54, Morrison, Tom wrote:
> All,
>
> Connected to eth1 (etsec2) of my mpc8548 cpu is a 88E1145 and I
> am trying to get the core functionality running with the device tree
> paradigm - I know the sense of the 88E1145 is active-low for my
> mpc8548 board and have it working wi
On Mon, 06 Aug 2007 13:01:28 -0500
Jon Loeliger <[EMAIL PROTECTED]> wrote:
> On Sun, 2007-08-05 at 23:53, David Gibson wrote:
>
> > > + *
> > > + * To build:
> > > + * dtc -I dts -O asm -o bamboo.S -b 0 bamboo.dts
> > > + * dtc -I dts -O dtb -o bamboo.dtb -b 0 bamboo.dts
> >
> > Can we ditch
>>> But 0 _is_ a valid PCI I/O address. Do we now have to start
>>
>> I wasn't in PCI 2.1 (later the corresponding passage have
>> disppeared).
>
> SFF controllers often use 0 to indicate a channel isn't configured and
> present. Libata and old IDE both assume these semantics for an SFF
> IDE
On Sun, 2007-08-05 at 23:53, David Gibson wrote:
> > + *
> > + * To build:
> > + * dtc -I dts -O asm -o bamboo.S -b 0 bamboo.dts
> > + * dtc -I dts -O dtb -o bamboo.dtb -b 0 bamboo.dts
>
> Can we ditch this "to build" boilerplate. It's just another thing
> people frequently forget to update
>> The hardware is called (E)IDE, the protocol is called ATA.
>> Or that's what I was told -- I think there's some historic
>> revisionism involved, too.
>
> ATA is the interface and standards for the ANSI standards based disk
> attachment. IDE "Integrated Drive Electronics" is a marketing name use
>> More importantly, "reg-shift" doesn't say what part of
>> the bigger words to access. A common example is byte-wide
>> registers on a 32-bit-only bus; it's about 50%-50% between
>> connecting the registers to the low byte vs. connecting it
>> to the byte with the lowest address.
>
>We alrea
On Mon, Aug 06, 2007 at 08:44:40AM -0700, David Brownell wrote:
> On Monday 06 August 2007, Anton Vorontsov wrote:
> > +
> > + if (pm)
> > + pm--;
> > + else /* this floods dmesg if using mmc_spi, so dbg
> > */
> > +
On Monday 06 August 2007, Anton Vorontsov wrote:
> +
> + if (pm)
> + pm--;
> + else /* this floods dmesg if using mmc_spi, so dbg */
> + dev_dbg(&spi->dev, "Requested speed is too "
> +
On Aug 6, 2007, at 12:57 AM, Zhang Wei-r63237 wrote:
> Hi, Paul,
>
> How about following patches?
>
> [PATCH 1/2] Add sysdev/pci_quirks.c file into PowerPC architecture
> with
> ULI chip quirk functions.
> URL: http://ozlabs.org/pipermail/linuxppc-dev/2007-August/040363.html
> [PATCH 2/2] Remov
On Mon, Aug 06, Benjamin Herrenschmidt wrote:
> BTW. Any reason why you don't set the DMA mask in the ohci driver rather
> than the sbp2 one ?
I used this patch, and the attached CD was found.
What dma mask should be used in ohci_probe()?
---
drivers/ieee1394/ohci1394.c |2 ++
driver
On Fri, 27 Jul 2007 11:33:31 +1000
David Gibson <[EMAIL PROTECTED]> wrote:
> On Thu, Jul 26, 2007 at 10:21:33AM -0500, Jon Loeliger wrote:
> > So, like, the other day David Gibson mumbled:
> >
> > > > > Only thing I'm not really happy with in the current release is the
> > > > > versioning stuff.
Long ago I've noticed (but didn't pay much attention) that
spi_mpc83xx using PM calculations that differs from what
specs describe. I.e.
u8 pm = mpc83xx_spi->spibrg / (spi->max_speed_hz * 4);
While specs says: "The SPI baud rate generator clock source (either
system clock or system clock divided
On Mon, Aug 06, 2007 at 03:00:12PM +1000, David Gibson wrote:
> On Fri, Aug 03, 2007 at 11:09:10AM -0500, Josh Boyer wrote:
> > Add a bootwrapper for the AMCC 440EP Bamboo Eval board. This also adds a
> > common fixup_clock function for all 440EP(x) chips.
>
> Ok, you have a separate bamboo.c and
On Mon, Aug 06, 2007 at 02:38:55PM +1000, David Gibson wrote:
> On Fri, Aug 03, 2007 at 11:09:04AM -0500, Josh Boyer wrote:
> > -#define SPRN_DBCR0 0x134
> > -#define DBCR0_RST_SYSTEM 0x3000
> > +#define DBCR0_RST_SYSTEM 0x3000
>
> Rather than just removing these defines and usin
On Sat, Aug 04, 2007 at 05:45:38PM +1000, David Gibson wrote:
> On Fri, Aug 03, 2007 at 11:09:02AM -0500, Josh Boyer wrote:
> > Remove some leftover cruft in the 40x Kconfig file. Also make sure we
> > select WANT_DEVICE_TREE for 40x.
> >
> > Signed-off-by: Josh Boyer <[EMAIL PROTECTED]>
> >
> >
On Fri, Aug 03, 2007 at 04:29:48AM -0500, Kumar Gala wrote:
>
> On Aug 2, 2007, at 4:47 PM, David Brownell wrote:
>
> > On Thursday 02 August 2007, Anton Vorontsov wrote:
> >> Probably someday mpc83xx_spi->sysclk should be renamed to
> >> mpc83xx_spi->spiclk to be less confusing.
> >
> > Why not
On Sun, Aug 05, Stefan Richter wrote:
> Benjamin Herrenschmidt wrote:
> >>> If setting 32-bit DMA mask fails on ppc64, that sounds like a problem
> >>> with the DMA implementation on that architecture. There are enough cards
> >>> out there that only support 32-bit DMA that this really needs to wo
Fixed wrongly casted pointers
Signed-off-by: Thomas Klein <[EMAIL PROTECTED]>
---
drivers/net/ehea/ehea_main.c | 25 ++---
1 files changed, 10 insertions(+), 15 deletions(-)
diff --git a/drivers/net/ehea/ehea_main.c b/drivers/net/ehea/ehea_main.c
index 36ca322..9756211 100
1 - 100 of 104 matches
Mail list logo
