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 eve
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
ice. If there are transactions 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
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
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
>>&
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
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
---
Anton Vorontsov wrote:
> There is a recursive locking bug: _set() takes the same spinlock.
> So you'd better move this cal
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
---
I can't think of a reason not to do this. The data register has no
effect except when the pin is configured as an output,
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
Linuxppc-dev@lists.ozlab
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
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
---
Anton,
thanks to your device table matching support patch I can use open firmware
to configure two spi devices on
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
amp;spi->dev, "ignoring %d default partitions on %s\n",
data->nr_parts, data->name);
Or am I misunderstanding something?
--
Michael Barkowski
RuggedCom
___
Linuxppc-dev mailing list
Linuxppc-dev
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 in
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 in U-Boot) should be enet1 (UCC3/eth1), and
ethernet1 should be enet0 (UCC2/eth0), to be
David Gibson wrote:
On Thu, Nov 13, 2008 at 10:18:28AM -0500, Michael Barkowski wrote:
ethernet0 (called FSL UEC0 in U-Boot) should be enet1 (UCC3/eth1), and
ethernet1 should be enet0 (UCC2/eth0), to be consistent with U-Boot so
that the interfaces do not swap addresses when control passes from
ethernet0 (called FSL UEC0 in U-Boot) should be enet1 (UCC3/eth1), and
ethernet1 should be enet0 (UCC2/eth0), to be consistent with U-Boot so
that the interfaces do not swap addresses when control passes from
U-Boot to the kernel.
Signed-off-by: Michael Barkowski <[EMAIL PROTECTED]>
Ac
17 matches
Mail list logo
