On Tue, May 27, 2008 at 02:55:56PM -0700, Linus Torvalds wrote:
>
>
> On Wed, 28 May 2008, Benjamin Herrenschmidt wrote:
> >
> > A problem with __raw_ though is that they -also- don't do byteswap,
>
> Well, that's why there is __readl() and __raw_readl(), no?
>
> Neither does ordering, and __r
Geert Uytterhoeven <[EMAIL PROTECTED]> wrote:
> On Fri, 30 May 2008, Haavard Skinnemoen wrote:
> > Maybe we need another interface that does not do byteswapping but
> > provides stronger ordering guarantees?
>
> The byte swapping depends on the device/bus.
Of course. But isn't it reasonable to as
All,
has anybody made some investigations about performance of a SD/MMC card
on SPI ?
Actually I'm using various cards (different speed classes) on an SPI bus
of a MPC8343 cpu.
Everything is working fine basically, i.e. card is detected properly and
block device can be mounted and used.
SPI cloc
Signed-off-by: Al Viro <[EMAIL PROTECTED]>
---
diff --git a/arch/powerpc/platforms/cell/celleb_scc_pciex.c
b/arch/powerpc/platforms/cell/celleb_scc_pciex.c
index 31da84c..0e04f8f 100644
--- a/arch/powerpc/platforms/cell/celleb_scc_pciex.c
+++ b/arch/powerpc/platforms/cell/celleb_scc_pciex.c
@@ -2
Signed-off-by: Al Viro <[EMAIL PROTECTED]>
---
diff --git a/arch/powerpc/platforms/52xx/mpc52xx_gpio.c
b/arch/powerpc/platforms/52xx/mpc52xx_gpio.c
index 48da5df..8a455eb 100644
--- a/arch/powerpc/platforms/52xx/mpc52xx_gpio.c
+++ b/arch/powerpc/platforms/52xx/mpc52xx_gpio.c
@@ -100,7 +100,7 @@ s
Jeremy Higdon wrote:
We don't actually have that problem on the Altix. All writes issued
by CPU X will be ordered with respect to each other. But writes by
CPU X and CPU Y will not be, unless an mmiowb() is done by the
original CPU before the second CPU writes. I.e.
CPU X writel
* Linus Torvalds <[EMAIL PROTECTED]> wrote:
> > Here's a UNTESTED patch for x86 that may or may not compile and
> > work, and which serializes (on a compiler level) the IO accesses
> > against regular memory accesses.
>
> Ok, so it at least boots on x86-32. Thus probably on x86-64 too (since
Pavel Machek wrote:
Still better than changing semantics of writel for _all_ drivers.
If you are really sure driver does not depend on writel order, it is
just a sed/// command, so I don't see any big code maintenance
issues...
This isn't changing the semantics for all drivers, it means it lea
On Sun, Jun 01, 2008 at 12:18:41PM +0200, Pierre Ossman wrote:
> On Mon, 26 May 2008 17:10:09 +0400
> Anton Vorontsov <[EMAIL PROTECTED]> wrote:
>
> >
> > Btw, this isn't actually drivers encapsulating. This is about making
> > mmc_spi export some "library" function which could be used by other
>
On Sat, 31 May 2008 13:59:02 +0400
Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
> Hi.
>
> On Fri, May 30, 2008 at 05:19:30PM -0500, Kim Phillips ([EMAIL PROTECTED])
> wrote:
> > ok, I see what you are saying now; if a channel gets done during
> > talitos_done processing, it'll trigger an interrup
Kumar Gala wrote:
The core portions of the phylib aren't capable of being used as
a module. This isn't really any different than something like i2c
in that the bus driver and core need to be built into the kernel.
Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
---
Jeff, please consider this for
I'm going to be spending most of this week bringing myself up to speed
on how to use these mhs tools (as part of a larger project on partial
reconfiguration on Xilinx PPC Virtex boards). For now, can someone help
me understand how to run the fdt part of the program? I'd like to
generate an FDT from
On Mon, Jun 02, 2008 at 09:27:01AM -0500, Kim Phillips ([EMAIL PROTECTED])
wrote:
> > I meant descriptor hdr value accessed via it - can it be checked in
> > tasklet under the lock and in submit path without? Can they correlate
> > somehow?
>
> I believe the check for a non-null request->desc (un
The core portions of the phylib aren't capable of being used as
a module. This isn't really any different than something like i2c
in that the bus driver and core need to be built into the kernel.
Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
---
Jeff, please consider this for 2.6.26 as w/o it we
On Mon, Jun 02, 2008 at 10:11:02AM +0200, Haavard Skinnemoen wrote:
> Geert Uytterhoeven <[EMAIL PROTECTED]> wrote:
> > On Fri, 30 May 2008, Haavard Skinnemoen wrote:
> > > Maybe we need another interface that does not do byteswapping but
> > > provides stronger ordering guarantees?
> >
> > The by
On Mon, 2 Jun 2008 20:00:12 +0400
Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
> On Mon, Jun 02, 2008 at 09:27:01AM -0500, Kim Phillips ([EMAIL PROTECTED])
> wrote:
> > > I meant descriptor hdr value accessed via it - can it be checked in
> > > tasklet under the lock and in submit path without? Ca
On May 30, 2008, at 4:42 PM, Segher Boessenkool wrote:
Removed clock-frequency and big-endian props as they aren't specified
anywhere.
If you remove "big-endian", you'll have to provide some other way
to get that information (like, some new "compatible" value).
I'm all for "big-endian" but
git.xilinx.com has a gen-mhs-devtree.git repository. This contains an
EDK BSP called 'fdt' which generates the device tree for an EDK design.
The easiest way to use this is to check it out, and then point the EDK
user repository at the edk_lib directory (under project->project
options->project pe
On Mon, Jun 02, 2008 at 11:25:14AM -0500, Kumar Gala wrote:
> The core provides functions like phy_read/phy_write. Andy has recently
> introduced board level workaround/fixups. The problem is these
> workarounds tend to use phy_read/phy_write and the board/platform code is
> not built as modul
Kumar Gala wrote:
On Jun 2, 2008, at 11:03 AM, Jeff Garzik wrote:
Kumar Gala wrote:
The core portions of the phylib aren't capable of being used as
a module. This isn't really any different than something like i2c
in that the bus driver and core need to be built into the kernel.
Signed-off-b
On May 30, 2008, at 4:49 PM, Segher Boessenkool wrote:
Added next-level-cache to the L1 and a reference to the new L2 label.
Where is this property defined? I can't find it.
its in ePAPR.
The PowerPC binding defines an "l2-cache" property for this (it
points from CPU node to L2 cache nod
On Jun 2, 2008, at 11:03 AM, Jeff Garzik wrote:
Kumar Gala wrote:
The core portions of the phylib aren't capable of being used as
a module. This isn't really any different than something like i2c
in that the bus driver and core need to be built into the kernel.
Signed-off-by: Kumar Gala <[EMA
On MPC86xx the watchdog could be enabled only at power-on-reset, and
could not be disabled afterwards. We must ping the watchdog from the
kernel until the userspace handles it.
MPC83xx CPUs are only differ in a way that watchdog could be disabled
once, but after it was enabled via software it beco
Hi all,
No comments on the previous version for two weeks... resending once
again.
Changes since v3:
- None. Simply resending, plus adding Andrew Morton and linux-kernel
to Cc, since I'm constantly getting bounces from Wim Van Sebroeck's
email:
- - - -
<[EMAIL PROTECTED]>:
213.249.96.
This patch simply converts mpc83xx_wdt to the OF platform driver so we
can directly work with the device tree without passing various stuff
through platform data.
Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
Acked-by: Stephen Rothwell <[EMAIL PROTECTED]>
---
drivers/watchdog/mpc83xx_wdt.c |
On Mon, Jun 02, 2008 at 11:25:14AM -0500, Kumar Gala wrote:
>
> On Jun 2, 2008, at 11:03 AM, Jeff Garzik wrote:
>
>> Kumar Gala wrote:
>>> The core portions of the phylib aren't capable of being used as
>>> a module. This isn't really any different than something like i2c
>>> in that the bus drive
Quite tired of these warnings ;-), checkpatch spitting them when
seeing the rename patch.
WARNING: Use #include instead of
#25: FILE: watchdog/mpc83xx_wdt.c:25:
+#include
WARNING: Use #include instead of
#26: FILE: watchdog/mpc83xx_wdt.c:26:
+#include
WARNING: line over 80 characters
#45:
On Mon, Jun 02, 2008 at 11:50:21AM -0500, Kim Phillips ([EMAIL PROTECTED])
wrote:
> > But can it be changed? You write to it without lock, but read under the
> > one (different for each channel though), so it attracted attention.
>
> can you point where in the code your concern is?
talitos_submi
Rename the driver because now we support some MPC86xx processors.
There are no changes to the mpc83xx_wdt.c file, yet. When possible, we do
file renames and changes separately (because Linus once asked so, because
it helps git to track the renamed files).
Signed-off-by: Anton Vorontsov <[EMAIL PR
Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
---
arch/powerpc/boot/dts/mpc8610_hpcd.dts |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8610_hpcd.dts
b/arch/powerpc/boot/dts/mpc8610_hpcd.dts
index fa9c297..bb0395b 100644
--- a/arch/powe
The mpc8xxx_wdt driver is using two registers: SWSRR to push magic
numbers, and SWCRR to control the watchdog. Both registers are available
on the MPC8xx, and seem to have the same offsets and semantics as in
MPC83xx/MPC86xx watchdogs. The only difference is prescale value. So this
driver simply wo
mpc83xx_wdt is the OF driver now, so we don't need fsl_soc constructor.
Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
---
arch/powerpc/sysdev/fsl_soc.c | 46 -
1 files changed, 0 insertions(+), 46 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_so
mpc83xx_wdt.c renamed to mpc8xxx_wdt.c, now we can do various renames
in the file itself.
Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
---
drivers/watchdog/mpc8xxx_wdt.c | 104
1 files changed, 52 insertions(+), 52 deletions(-)
diff --git a/drivers
Hi all,
Here are the notorious bindings. I believe I addressed Segher's comments.
Major changes are in the LEDs bindings, I removed all the cruft and now
using "aliases" mechanism to determine LEDs' trigger.
Comments, suggestions?
Thanks,
Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
---
On Jun 2, 2008, at 11:39 AM, Jeff Garzik wrote:
Kumar Gala wrote:
On Jun 2, 2008, at 11:03 AM, Jeff Garzik wrote:
Kumar Gala wrote:
The core portions of the phylib aren't capable of being used as
a module. This isn't really any different than something like i2c
in that the bus driver and co
On Mon, 2 Jun 2008, Adrian Bunk wrote:
> On Mon, Jun 02, 2008 at 11:25:14AM -0500, Kumar Gala wrote:
> >
> > On Jun 2, 2008, at 11:03 AM, Jeff Garzik wrote:
> >
> >> Kumar Gala wrote:
> >>> The core portions of the phylib aren't capable of being used as
> >>> a module. This isn't really any diffe
On Mon, 2 Jun 2008 21:57:51 +0400
Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
> On Mon, Jun 02, 2008 at 11:50:21AM -0500, Kim Phillips ([EMAIL PROTECTED])
> wrote:
> > > But can it be changed? You write to it without lock, but read under the
> > > one (different for each channel though), so it at
On Jun 2, 2008, at 11:39 AM, Jeff Garzik wrote:
Kumar Gala wrote:
On Jun 2, 2008, at 11:03 AM, Jeff Garzik wrote:
Kumar Gala wrote:
The core portions of the phylib aren't capable of being used as
a module. This isn't really any different than something like i2c
in that the bus driver and co
Removed clock-frequency, big-endian, and built-in props as they aren't
specified anywhere. Also added compatible = "chrp,open-pic" in the
places it was missing.
---
Updated the commit message to be more explicit.
(in my powerpc.git powerpc-next branch)
- k
Documentation/powerpc/booting-witho
Added next-level-cache to the L1 and a reference to the new L2 label.
This is per the ePAPR 0.94 spec. Since we are't really dependent on this
today we aren't supporting the "legacy" l2-cache phandle that is specified
in the PPC v2.1 OF Binding spec.
---
Updated the commit message to be more exp
On May 30, 2008, at 4:49 PM, Segher Boessenkool wrote:
Added next-level-cache to the L1 and a reference to the new L2 label.
Where is this property defined? I can't find it.
The PowerPC binding defines an "l2-cache" property for this (it
points from CPU node to L2 cache node, from L2 cache
On Jun 2, 2008, at 14:30, Kumar Gala wrote:
On Jun 2, 2008, at 11:39 AM, Jeff Garzik wrote:
If you really think the core of the phylib should be able to be
built as a module than we could possibly add function pointers to
phy_dev to do the real phy_read()/phy_write() and change phy_read/
On Mon, 2 Jun 2008 21:38:36 +0400
Anton Vorontsov <[EMAIL PROTECTED]> wrote:
> Quite tired of these warnings ;-), checkpatch spitting them when
> seeing the rename patch.
I've already sent the maintainer a complete overhaul of watchdog via
checkpatch.
Alan
___
Currently, fsl_i2c_of_init() uses the order of the I2C adapter nodes in the
device tree to enumerate the I2C adapters. Instead, let's check for the
cell-index property and use it if it exists.
This is handy for device drivers that need to identify the I2C adapters by
specific numbers. The Freesc
> On Thu, May 29, 2008 at 09:04:29AM -0500, Jon Loeliger wrote:
> >
> > I believe I am fully caught up at this point.
>
> Not quite, this one slipped through the cracks:
Rats.
> dtc: Fix some printf() format warnings when compiling 64-bit
>
> Currently, dtc generates a few gcc build warnings if
> This patch adds an extra testcase to dtc to ensure that the
> "reg_format" and "ranges_format" checks trigger as they should if a
> 'reg' or 'ranges' property appears in the root node.
>
> Signed-off-by: David Gibson <[EMAIL PROTECTED]>
Applied.
Thanks,
jdl
__
Kumar Gala wrote:
On Jun 2, 2008, at 11:39 AM, Jeff Garzik wrote:
Kumar Gala wrote:
On Jun 2, 2008, at 11:03 AM, Jeff Garzik wrote:
Kumar Gala wrote:
The core portions of the phylib aren't capable of being used as
a module. This isn't really any different than something like i2c
in that th
Andy Fleming wrote:
I'm partial to the select-it-if-you-need-it paradigm.
AFAICS this can all be solved by the platform Kconfig ensuring that phylib=y
Jeff
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/li
Removed clock-frequency and big-endian props as they aren't specified
anywhere.
If you remove "big-endian", you'll have to provide some other way
to get that information (like, some new "compatible" value).
I'm all for "big-endian" but we don't spec this anywhere and aren't
using it right now
On Mon, Jun 02, 2008 at 11:56:39AM +0200, Jes Sorensen wrote:
> Jeremy Higdon wrote:
> >We don't actually have that problem on the Altix. All writes issued
> >by CPU X will be ordered with respect to each other. But writes by
> >CPU X and CPU Y will not be, unless an mmiowb() is done by the
> >or
Added next-level-cache to the L1 and a reference to the new L2 label.
Where is this property defined? I can't find it.
The PowerPC binding defines an "l2-cache" property for this (it
points from CPU node to L2 cache node, from L2 cache node to L3
cache node, from L3 cache node to L4 cache node
On Mon, Jun 02, 2008 at 08:43:18PM +0100, Alan Cox wrote:
> On Mon, 2 Jun 2008 21:38:36 +0400
> Anton Vorontsov <[EMAIL PROTECTED]> wrote:
>
> > Quite tired of these warnings ;-), checkpatch spitting them when
> > seeing the rename patch.
>
> I've already sent the maintainer a complete overhaul o
Segher Boessenkool wrote:
>>>
>>> The PowerPC binding defines an "l2-cache" property for this (it
>>> points from CPU node to L2 cache node, from L2 cache node to L3
>>> cache node, from L3 cache node to L4 cache node, etc.)
>>
>> So looking at the PPC binding its not terrible clear about "l3-cache
On Mon, 2008-06-02 at 12:36 +0200, Ingo Molnar wrote:
> The patch passed initial light testing in -tip (~30 successful random
> self-builds and bootups on various mixed 32-bit/64-bit boxes) but
> it's
> still v2.6.27 material IMO.
I think adding the "memory" clobber should be .26 and even -stabl
Geoff Levand wrote:
> Alessandro Zummo wrote:
>> On Wed, 20 Feb 2008 10:11:23 -0600
>> Kumar Gala <[EMAIL PROTECTED]> wrote:
>>
>>>
>>> Is the functionality provided by drivers/char/gen_rtc.c completely
>>> handled by the rtc subsystem in drivers/rtc?
>>>
>>> I ask for two reasons:
>>> 1. shou
On Jun 2, 2008, at 4:26 PM, Nathan Lynch wrote:
Segher Boessenkool wrote:
The PowerPC binding defines an "l2-cache" property for this (it
points from CPU node to L2 cache node, from L2 cache node to L3
cache node, from L3 cache node to L4 cache node, etc.)
So looking at the PPC binding its
The whole world isn't embedded ppc, we use this stuff elsewhere too.
You guys need to figure out something that doesn't require phylib
be built-in on ALL platforms, but only the platforms that require
it.
I wasn't suggesting we build it always, just not let it be built as
a module.
I was
On Jun 2, 2008, at 11:32 AM, Segher Boessenkool wrote:
Removed clock-frequency and big-endian props as they aren't
specified
anywhere.
If you remove "big-endian", you'll have to provide some other way
to get that information (like, some new "compatible" value).
I'm all for "big-endian" bu
On Jun 2, 2008, at 3:30 PM, Jeff Garzik wrote:
Andy Fleming wrote:
I'm partial to the select-it-if-you-need-it paradigm.
AFAICS this can all be solved by the platform Kconfig ensuring that
phylib=y
I don't care for this as it means making sure each platform/board port
gets it right.
On Jun 1, 2008, at 9:03 PM, David Gibson wrote:
On Fri, May 30, 2008 at 08:49:45AM +0200, Wolfgang Grandegger wrote:
This patch adds support for the TQM8548 modules from TQ-Components
GmbH (http://www.tqc.de).
[snip]
index 000..d09250a
--- /dev/null
+++ b/arch/powerpc/boot/dts/tqm8548.d
Kumar Gala wrote:
On Jun 2, 2008, at 3:30 PM, Jeff Garzik wrote:
Andy Fleming wrote:
I'm partial to the select-it-if-you-need-it paradigm.
AFAICS this can all be solved by the platform Kconfig ensuring that
phylib=y
I don't care for this as it means making sure each platform/board port
Hi.
On Mon, Jun 02, 2008 at 02:06:03PM -0500, Kim Phillips ([EMAIL PROTECTED])
wrote:
> it would be an issue if flush_cannel didn't save off the data required
> to call the callback with in saved_req. flush_channel does this on
> purpose to be able to call the callback outside of lock (as is
> c
During the next merge window, pci_name()'s return value will become
const, so use the new dev_set_name() instead to avoid the warning (from
linux-next):
arch/powerpc/kernel/pci_64.c: In function 'of_create_pci_dev':
arch/powerpc/kernel/pci_64.c:193: warning: passing argument 1 of 'sprintf'
discar
On Monday 02 June 2008 19:56, Jes Sorensen wrote:
> Jeremy Higdon wrote:
> > We don't actually have that problem on the Altix. All writes issued
> > by CPU X will be ordered with respect to each other. But writes by
> > CPU X and CPU Y will not be, unless an mmiowb() is done by the
> > original C
On Monday 02 June 2008 17:24, Russell King wrote:
> On Tue, May 27, 2008 at 02:55:56PM -0700, Linus Torvalds wrote:
> > On Wed, 28 May 2008, Benjamin Herrenschmidt wrote:
> > > A problem with __raw_ though is that they -also- don't do byteswap,
> >
> > Well, that's why there is __readl() and __raw_
> This whole thread also ties in with my posts about mmiowb (which IMO
> should go away).
>
> readl/writel: strongly ordered wrt one another and other stores
>to cacheable RAM, byteswapping
> __readl/__writel: not ordered (needs mb/rmb/wmb to order with
>othe
On May 8, 2008, at 3:22 PM, Sam Ravnborg wrote:
On Thu, May 08, 2008 at 09:16:10AM -0500, Kumar Gala wrote:
On May 5, 2008, at 3:44 PM, Sam Ravnborg wrote:
Let me know if this does address your question.
The problem is MODPOST complains about undefined symbols:
MODPOST 24 modules
ERROR
On Jun 2, 2008, at 3:09 PM, Timur Tabi wrote:
Currently, fsl_i2c_of_init() uses the order of the I2C adapter nodes
in the
device tree to enumerate the I2C adapters. Instead, let's check for
the
cell-index property and use it if it exists.
This is handy for device drivers that need to iden
This is a patch that adds kprobes support for book-e style debug. Its
based on the patch posted by Madhvesh and assumes the exception cleanup
that I've already posted.
Post to get any feedback. The code needs some cleaning up but wanted to
see if there were any initial comments.
- k
---
arch/
On Jun 3, 2008, at 12:48 AM, Ananth N Mavinakayanahalli wrote:
On Tue, Jun 03, 2008 at 12:30:51AM -0500, Kumar Gala wrote:
This is a patch that adds kprobes support for book-e style debug.
Its
based on the patch posted by Madhvesh and assumes the exception
cleanup
that I've already posted
On Tuesday 03 June 2008 14:32, Benjamin Herrenschmidt wrote:
> > This whole thread also ties in with my posts about mmiowb (which IMO
> > should go away).
> >
> > readl/writel: strongly ordered wrt one another and other stores
> >to cacheable RAM, byteswapping
> > __readl/__writel:
On Tue, Jun 03, 2008 at 12:30:51AM -0500, Kumar Gala wrote:
> This is a patch that adds kprobes support for book-e style debug. Its
> based on the patch posted by Madhvesh and assumes the exception cleanup
> that I've already posted.
>
> Post to get any feedback. The code needs some cleaning up
On Tue, 2008-06-03 at 16:11 +1000, Nick Piggin wrote:
> > - readl is synchronous (ie, makes the CPU think the
> > data was actually used before executing subsequent
> > instructions, thus waits for the data to come back,
> > for example to ensure that a read used
Hello,
I am trying to enable the SD over SPI on a emebedded system with one
processor powerpc mpc5200b; you have enabled mmc over spi into a native
spi or psc spi?
regards,
Fabio
Andre Schwarz ha scritto:
All,
has anybody made some investigations about performance of a SD/MMC card
on SPI ?
Nick Piggin writes:
> So your readl can pass an earlier cacheable store or earlier writel?
No. It's quite gross at the moment, it has a sync before the access
(i.e. a full mb()) and a twi; isync sequence after the access that
stalls execution until the data comes back.
> > We don't provide mean
75 matches
Mail list logo
