Just wondering - is there a case where using volatile for UCC parameter RAM for
example will not work, or is the use of I/O accessors everywhere an attempt to
be portable to other architectures?
I'm asking because I really want to know ;)
--
Michael Barkowski
905-482-4577
Kumar Gala wrote:
On Oct 2, 2009, at 9:46 AM, Timur Tabi wrote:
Michael Barkowski wrote:
Just wondering - is there a case where using volatile for UCC
parameter RAM for example will not work, or is the use of I/O
accessors everywhere an attempt to be portable to other architectures
Just wondering how I can get kgdb to show me the contents of MURAM on the QE?
--
Michael Barkowski
905-482-4577
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
to other devices on the
same bus in the meantime, this device may be confused and fail the first
transaction.
Maybe the chip select should be disabled until the device entry is initialized
with full knowledge of its configuration. Not sure of the right solution.
--
Michael Barkowski
905-482
Anton Vorontsov wrote:
On Tue, Aug 18, 2009 at 05:33:00PM -0500, Timur Tabi wrote:
Anton Vorontsov wrote:
On Tue, Aug 18, 2009 at 05:20:44PM -0400, Michael Barkowski wrote:
This avoids having a short glitch if the desired initial value is not
the same as what was previously in the data
If we use open firmware, then alow_flags handles active-low
chipselects, which is the same as SPI_CS_HIGH. This patch fixes the
double negative.
Signed-off-by: Michael Barkowski michaelbarkow...@ruggedcom.com
---
Anton,
thanks to your device table matching support patch I can use open firmware
Michael Barkowski wrote:
If we use open firmware, then alow_flags handles active-low
chipselects, which is the same as SPI_CS_HIGH. This patch fixes the
double negative.
Hang on - I missed your most recent patches to spi_mpc8xxx
--Michael
Anton - thanks for the offline correction.
SPI_CS_HIGH means that the device interprets high as active.
The alow flag means there is an inverter somewhere.
My mistake - patch retracted.
--
Michael
___
Linuxppc-dev mailing list
This avoids having a short glitch if the desired initial value is not
the same as what was previously in the data register.
Signed-off-by: Michael Barkowski michaelbarkow...@ruggedcom.com
---
I can't think of a reason not to do this. The data register has no
effect except when the pin
This avoids having a short glitch if the desired initial value is not
the same as what was previously in the data register.
Signed-off-by: Michael Barkowski michaelbarkow...@ruggedcom.com
---
Anton Vorontsov wrote:
There is a recursive locking bug: _set() takes the same spinlock.
So you'd
Timur Tabi wrote:
Michael Barkowski wrote:
diff --git a/arch/powerpc/sysdev/qe_lib/gpio.c
b/arch/powerpc/sysdev/qe_lib/gpio.c
index 3485288..e7bf136 100644
--- a/arch/powerpc/sysdev/qe_lib/gpio.c
+++ b/arch/powerpc/sysdev/qe_lib/gpio.c
@@ -107,12 +107,11 @@ static int qe_gpio_dir_out
default partitions on %s\n,
data-nr_parts, data-name);
Or am I misunderstanding something?
--
Michael Barkowski
RuggedCom
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc
Anton Vorontsov wrote:
On Wed, Aug 12, 2009 at 04:45:55PM -0400, Michael Barkowski wrote:
Hello Anton,
Is m25p_probe now valid with dev.platform_data == NULL, for of platforms?
Then shouldn't you have the following change as well, near the end of
the function?
-} else if (data
David Gibson wrote:
On Mon, Nov 17, 2008 at 11:28:52AM -0500, Michael Barkowski wrote:
David Gibson wrote:
On Fri, Nov 14, 2008 at 10:16:19AM -0500, Michael Barkowski wrote:
David Gibson wrote:
On Thu, Nov 13, 2008 at 10:18:28AM -0500, Michael Barkowski wrote:
ethernet0 (called FSL UEC0
14 matches
Mail list logo
