On Fri, 3 Sep 2010 17:47:24 -0700 "Ira W. Snyder" wrote:
> On Fri, Sep 03, 2010 at 04:40:33PM -0700, Andrew Morton wrote:
> > On Thu, 2 Sep 2010 12:47:52 -0700
> > "Ira W. Snyder" wrote:
> >
> > > The slab.h header is required to use the kmalloc() family of functions.
> > > Due to recent kernel
On Fri, Sep 03, 2010 at 04:40:33PM -0700, Andrew Morton wrote:
> On Thu, 2 Sep 2010 12:47:52 -0700
> "Ira W. Snyder" wrote:
>
> > The slab.h header is required to use the kmalloc() family of functions.
> > Due to recent kernel changes, this header must be directly included by
> > code that calls
On Thu, 2 Sep 2010 12:47:52 -0700
"Ira W. Snyder" wrote:
> The slab.h header is required to use the kmalloc() family of functions.
> Due to recent kernel changes, this header must be directly included by
> code that calls into the memory allocator.
>
> Signed-off-by: Ira W. Snyder
> ---
>
> Wi
On Fri, 3 Sep 2010 15:30:51 -0700 Ira W. Snyder wrote:
> This driver allows userspace to access the data processing FPGAs on the
> OVRO CARMA board. It has two modes of operation:
>
> 1) random access
>
> This allows users to poke any DATA-FPGA registers by using mmap to map
> the address regio
This adds support for programming the data processing FPGAs on the OVRO
CARMA board. These FPGAs have a special programming sequence that
requires that we program the Freescale DMA engine, which is only
available inside the kernel.
Signed-off-by: Ira W. Snyder
---
drivers/fpga/carma/Kconfig
This driver allows userspace to access the data processing FPGAs on the
OVRO CARMA board. It has two modes of operation:
1) random access
This allows users to poke any DATA-FPGA registers by using mmap to map
the address region directly into their memory map.
2) correlation dumping
When correla
This adds basic support for the system controller FPGA on the OVRO CARMA
board. This patch only adds infrastructure that will be used by later
drivers.
Signed-off-by: Ira W. Snyder
---
drivers/Kconfig |2 +
drivers/Makefile|1 +
drivers/fpga/Kconfig|1
Hello everyone,
Yesterday I asked where board specific drivers should be located in the
source tree. Several people suggested I just post the drivers for review
right away, and let the reviewers comment on where to put the drivers.
Here they are. I've created a new drivers/fpga/carma/ directory f
> >APM821xx is Applied Micro Circuits Corporations naming convention for
> >new line of SoCs.
>
> So is it a 440x6 core then? Or what core is inside the SoC?
[Marri] It is 464 core.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://list
dvh...@linux.vnet.ibm.com wrote on 09/02/2010 01:04:28 AM:
> Subject
>
> Re: [PATCH][RFC] preempt_count corruption across H_CEDE call with
> CONFIG_PREEMPT on pseries
> With this in place, we no longer see the preempt_count dropping below
> zero. However, if I offline/online a CPU about 246 time
On Fri, 3 Sep 2010 15:43:57 +0400
Anton Vorontsov wrote:
> On Fri, Aug 06, 2010 at 10:51:35AM +0800, Roy Zang wrote:
> [...]
> >
> > +static struct fsl_elbc_fcm_ctrl *elbc_fcm_ctrl;
> > +
>
> Are you sure that you want it as a global var? A bit scary change.
>
> Oh, you probably don't need it
Tighten up time timing around the gpio reset functionality. Add a 200ns
delay before remuxing the pins back to ac97 to comply with the ac97 spec.
Signed-off-by: Eric Millbrandt
---
Scope shots availible upon request
changes since v1
- amended with comments from Wolfram Sang
arch/powerpc/plat
> > Yes, but it is way more readable. Does the extra delay hurt? The value
> > of 7 looks a bit magic to me. Are you sure it will do for various
> > clock frequencies?
> >
>
> The reset is happening in the gpio spinlock, so I am trying to keep busy
> waiting to a minimum. The magic value of 7 ca
On Fri, 3 Sep 2010 at 12:22:24 Wolfram Sang wrote:
- udelay(2);
+ udelay(1);
/* Deassert reset */
setbits8(&wkup_gpio->wkup_dvo, reset);
+ /* wait at least 200ns */
+ __delay(7);
>>>
>>> ndelay(200)?
>> Is ndelay defin
> >> - udelay(2);
> >> + udelay(1);
> >>
> >> /* Deassert reset */
> >> setbits8(&wkup_gpio->wkup_dvo, reset);
> >>
> >> + /* wait at least 200ns */
> >> + __delay(7);
> >
> > ndelay(200)?
>
> Is ndelay defined for powerpc? I was under the impression that i
On Fri, 3 Sep 2010 at 12:02:09 Wolfram Sang wrote:
> On Fri, Sep 03, 2010 at 11:45:22AM -0400, Eric Millbrandt wrote:
>> Tighten up time timing around the gpio reset functionality. Add a 200ns
>> delay before remuxing the pins back to ac97 to comply with the ac97
>> spec. This delay ensures that sy
On Fri, Sep 03, 2010 at 11:45:22AM -0400, Eric Millbrandt wrote:
> Tighten up time timing around the gpio reset functionality. Add a 200ns
> delay before remuxing the pins back to ac97 to comply with the ac97 spec.
> This delay ensures that sync and sdata_out are held low while reset
> transitions
Tighten up time timing around the gpio reset functionality. Add a 200ns
delay before remuxing the pins back to ac97 to comply with the ac97 spec.
This delay ensures that sync and sdata_out are held low while reset
transitions to high.
Signed-off-by: Eric Millbrandt
---
Scope shots are availible
On Fri, 2010-03-09 at 10:05 +0300, Ioannis Kokkoris wrote:
> We are using a board revision 2 (pilot version). Our main concern is whether
> this issue affects the working UCC1 eth interface performance.
No, it won't affect the performance. We got line rate for performance
for UECs on this board.
On Fri, Sep 03, 2010 at 10:36:19AM +0200, André Schwarz wrote:
> Hi,
>
> we're about to get new MPC8377 based hardware with various peripherals.
> There are two I2C-to-SPI bridge devices (NXP SC18IS602) and I'm not sure
> how to define a proper dts...
>
> Of course it's an easy thing creating 2 c
Hello,
I have a board with 2 PHYs attached to one FEC.
I want to implement some kind of main-standby attachment to LAN by
setting the ISOLATE bit on one on the two PHYs then monitoring the link
status and switch to the other PHY when the link status goes down.
What would be the most proper w
On Fri, Aug 06, 2010 at 10:51:35AM +0800, Roy Zang wrote:
[...]
>
> +static struct fsl_elbc_fcm_ctrl *elbc_fcm_ctrl;
> +
Are you sure that you want it as a global var? A bit scary change.
Oh, you probably don't need it, as you can get it from
fsl_lbc_ctrl_dev->nand?
I wonder if Scott saw these
On Fri, Aug 06, 2010 at 10:51:36AM +0800, Roy Zang wrote:
[...]
> /**
> + * convert_lbc_address - convert the base address
> + * @addr_base: base address of the memory bank
> + *
> + * This function converts a base address of lbc into the right format for
> the BR
> + * registers. If the SO
On Fri, Aug 06, 2010 at 10:51:34AM +0800, Roy Zang wrote:
> From: Lan Chunhe-B25806
>
> Move Freescale elbc interrupt from nand dirver to elbc driver.
> Then all elbc devices can use the interrupt instead of ONLY nand.
>
> Signed-off-by: Lan Chunhe-B25806
> Signed-off-by: Roy Zang
> ---
> send
> -Original Message-
> From: Zang Roy-R61911
> Sent: Friday, August 06, 2010 10:52 AM
> To: linux-...@lists.infradead.org
> Cc: linuxppc-...@ozlabs.org; a...@linux-foundation.org; Gala
Kumar-B11780; Lan
> Chunhe-B25806
> Subject: [PATCH 1/3][MTD] P4080/eLBC: Make Freescale elbc interrupt
Hi,
we're about to get new MPC8377 based hardware with various peripherals.
There are two I2C-to-SPI bridge devices (NXP SC18IS602) and I'm not sure
how to define a proper dts...
Of course it's an easy thing creating 2 child nodes on the CPU's I2C
device - but how can I represent the created SPI
> Subject: RE: P1021MDS QE Ethernet Ports
> From: haiying.w...@freescale.com
> To: johnko...@hotmail.com
> CC: linuxppc-dev@lists.ozlabs.org
> Date: Thu, 2 Sep 2010 09:32:48 -0400
>
> On Thu, 2010-02-09 at 11:26 +0300, Ioannis Kokkoris wrote:
>>> From: johnko...@hotmail.com
>>> To: linuxppc-dev@li
27 matches
Mail list logo
