Hello Christopher,
Varlese, Christopher wrote:
> (FYI I working on the kmeter1)
>
> kmeter1.c reuses the same QE_ENET10 RGMII errata workaround code from
> mpc836x_mds.c (MPC8360EMDS eval board).
>
> In my view errata nodes in the dts is overkill. Maybe the errata code can
> go into a reusab
On Wed, May 6, 2009 at 3:07 PM, Grant Likely wrote:
> On Wed, May 6, 2009 at 2:15 PM, Wolfgang Denk wrote:
> > From: Piotr Ziecik
> >
> > This patch adds initial version of MPC512x DMA driver.
> > Only memory to memory transfers are currenly supported.
> >
> > Signed-off-by: Piotr Ziecik
> > Si
Can we get 5121 support in and add 5200 support later? They are not
identical.
On Wed, May 6, 2009 at 4:40 PM, Grant Likely wrote:
>
> On Wed, May 6, 2009 at 3:06 PM, Wolfram Sang
> wrote:
> > On Wed, May 06, 2009 at 10:15:17PM +0200, Wolfgang Denk wrote:
> >> From: John Rigby
> >>
> >> Based
I was having deja-vu with this and realized that I have fixed at least some
of the objections to this patch.
Wolfgang you may want to look at the patch in my 5121 git tree here:
http://git.denx.de/?p=linux-mpc512x.git;a=commit;h=2950be3be42af7449941c3340998c27ef918f10f
It does runtime tx packet
On Wed, May 6, 2009 at 2:59 PM, Grant Likely wrote:
>
>
> > diff --git a/arch/powerpc/platforms/512x/mpc512x_shared.c
> b/arch/powerpc/platforms/512x/mpc512x_shared.c
> > index d8cd579..7135d89 100644
> > --- a/arch/powerpc/platforms/512x/mpc512x_shared.c
> > +++ b/arch/powerpc/platforms/512x/mpc5
Ok, the interrupt enabling should happen in the driver. Should it key off
compatible or should a new property be added like the existing 5200 clocking
property?
On Wed, May 6, 2009 at 8:41 PM, Grant Likely wrote:
> On Wed, May 6, 2009 at 4:51 PM, Grant Likely
> wrote:
> > On Wed, May 6, 2009 at
I think the fec's parent clock is the ipb clock not the ppc core clock.
Could that be the problem?
On Wed, May 6, 2009 at 2:21 PM, Wolfgang Denk wrote:
> Signed-off-by: Wolfgang Denk
> Cc: Grant Likely
> Cc: John Rigby
> ---
> This patch is NOT intended for inclusion into mainline, but rather
Wolfgang,
Welcome to my world and why I gave up on this months ago.
Everyone else,
One thing to consider here is a rewrite with the goal of a new improved fec
driver that would work on both 5121 and the various mx platforms that also
have this same fec core.
Also don't forget that the register
On Thu, May 7, 2009 at 8:22 PM, John Rigby wrote:
>
>
> On Wed, May 6, 2009 at 2:59 PM, Grant Likely
> wrote:
>>
>>
>> > diff --git a/arch/powerpc/platforms/512x/mpc512x_shared.c
>> > b/arch/powerpc/platforms/512x/mpc512x_shared.c
>> > index d8cd579..7135d89 100644
>> > --- a/arch/powerpc/platfor
On Thu, May 7, 2009 at 8:12 PM, John Rigby wrote:
> Ok, the interrupt enabling should happen in the driver. Should it key off
> compatible or should a new property be added like the existing 5200 clocking
> property?
key off compatible. And the 5200 clocking property has been depreciated.
g.
thanks for Scott's following
> You need to pass your physical address (0xd000) to ioremap() to
> obtain a virtual address that you can dereference.
actually, i have done that like you said. pass my phy addr to a virtual
addr, but i suppose it is a kernel virtual addr. i wanna get data from p
Hi Ben,
On Thu, 7 May 2009 10:07:52 +1000 Stephen Rothwell
wrote:
>
> This is a regression in v2.6.29 from v2.6.28, so I guess we need to
> send this to the stable team (backported if necessary) after it is upstream.
This same patch applies to 2.6.29.2 and fixes the problem there.
--
Cheers,
Hi Wolfgang,
> Trouble using with Kegel cross tool chain
> Wolfgang Denk wd at denx.de
> Thu May 7 15:32:36 EST 2009
>
> * Previous message: Trouble using with Kegel cross tool chain
> * Next message: Trouble using with Kegel cross tool chain
> * Messages sorted by: [ date ] [ thr
> > + echo 'SRC_DIR not set, so source tarballs will be unpacked in the
> > build dir
> > ectory'
> > SRC_DIR not set, so source tarballs will be unpacked in the build
> > directory
> > + case x$PREFIX in
> > + case x$USER in
> > + abort 'Don'\''t run all.sh or crosstool.sh as root, it'\''s
> >
Dear Damien,
in message you
wrote:
>
> We are attempting to bring up a new MPC5121e board, somewhat based on the
> Silicon Turnkey's ADS5121 development board. We are using a kernel and
> u-boot based on Freescale/STx's board support package.
I recommend to use current code - tip of tree in U
Hello all,
(FYI I working on the kmeter1)
kmeter1.c reuses the same QE_ENET10 RGMII errata workaround code from
mpc836x_mds.c (MPC8360EMDS eval board).
In my view errata nodes in the dts is overkill. Maybe the errata code can go
into a reusable function somewhere in 83xx/ or in ucc_geth.c?
From: Maynard Johnson
Description
---
Change ppc64 oprofile kernel driver to use the SLOT bits (MMCRA[37:39]only on
older processors where those bits are defined.
Background
--
The performance monitor unit of the 64-bit POWER processor family has the
ability to collect accurate i
On Thursday 07 May 2009 10:43:49 Damien Dusha wrote:
> Dear all,
>
> We are attempting to bring up a new MPC5121e board, somewhat based on the
> Silicon Turnkey's ADS5121 development board. We are using a kernel and
> u-boot based on Freescale/STx's board support package.
Somewhat based on the AD
On May 7, 2009, at 9:10 AM, Jan Neskudla wrote:
And one more think, when I enabled usage of DMA, rionet does not
compile too,
but in this case I do not have a fix. I tested this on kernel
2.6.29.1 and
EP8548 as target board.
What exactly do you mean by that? What CONFIG options cause com
We have a network-switch connected via PCI which comes with 3rd
party (kernel) software.
The frames trapped by the switch and sent to CPU (with DMA)
are corrupt.
To rule out any data cache problems (which probably isn't causing
our problem) I thought I "quickly" disable the data cache.
we use a
Hallo,
I tested your patches, and the MMIO is working when enabled in the
rionet driver. Only the compilation of rionet as modules was a problem.
I had to add following lines into rio.c to export missing symbols.
EXPORT_SYMBOL_GPL(rio_unmap_inb_region);
EXPORT_SYMBOL_GPL(rio_map_inb_region);
EXP
On Wed, May 6, 2009 at 4:41 PM, Wolfgang Denk wrote:
> Dear Grant,
>
> In message you
> wrote:
>>
>> > Agreed that it's ugly, but duplicatio9ng the code would have been even
>> > worse. I don't think that it has multiplatform - at least not as long
>> > as you don't ask for one image that runs o
On May 6, 2009, at 5:01 PM, Wolfgang Denk wrote:
Dear Grant,
in message > you wrote:
...
#ifdef CONFIG_FS_ENET_HAS_FEC
+#ifdef CONFIG_FS_ENET_MPC5121_FEC
+{
+.compatible = "fsl,mpc5121-fec",
+.data = (void *)&fs_fec_ops,
+},
+#else
{
.compatible = "fsl,pq1-f
* Nicholas Miell wrote:
> On Wed, 2009-05-06 at 15:21 -0700, Markus Gutschke (顧孟勤) wrote:
> > On Wed, May 6, 2009 at 15:13, Ingo Molnar wrote:
> > > doing a (per arch) bitmap of harmless syscalls and replacing the
> > > mode1_syscalls[] check with that in kernel/seccomp.c would be a
> > > prett
Wolfgang Denk wrote on 07/05/2009 11:19:48:
>
> Dear Joakim Tjernlund,
>
> In message
you wrote:
> >
> > Just a stab in the dark: Perhaps the fec->fecp->fec_mii_speed field is
> > misaligned or is 16 bits ?
>
> Good idea. The RM documents the register at offset 0x44 and describes
> it as 32
Dear Joakim Tjernlund,
In message
you
wrote:
>
> Just a stab in the dark: Perhaps the fec->fecp->fec_mii_speed field is
> misaligned or is 16 bits ?
Good idea. The RM documents the register at offset 0x44 and describes
it as 32 bits... and it's working fine on the MPC5121ADS board, but
fails
>
> Signed-off-by: Wolfgang Denk
> Cc: Grant Likely
> Cc: John Rigby
> ---
> This patch is NOT intended for inclusion into mainline, but rather a
> request for help. For some reason which I don't understand yet, the
> Ethernet interface on the ARIA board does not work in the default
> configura
On Thursday 07 May 2009 00:29:59 Grant Likely wrote:
> On Wed, May 6, 2009 at 4:01 PM, Wolfgang Denk wrote:
> > Dear Grant,
> >
> > in message
> > you wrote:
> >
> > ...
> >
> >> > #ifdef CONFIG_FS_ENET_HAS_FEC
> >> > +#ifdef CONFIG_FS_ENET_MPC5121_FEC
> >> > + {
> >> > + .compatible =
On Thu, May 7, 2009 at 00:03, Roland McGrath wrote:
>
> That is not a "ptrace problem" per se at all. It's an intrinsic problem
> with any method based on "generic" syscall interception, if the filtering
> and enforcement decisions depend on examining user memory.
Yes, this is indeed the main pr
On Wednesday 06 May 2009 22:15:13 Wolfgang Denk wrote:
> --- /dev/null
> +++ b/drivers/mtd/nand/mpc5121_nfc.c
>[...]
> +/* Init external chip select logic on ADS5121 board */
> +static int ads5121_chipselect_init(struct mtd_info *mtd)
> +{
> + struct nand_chip *chip = mtd->priv;
> + struct
> Ptrace has performance and/or reliability problems when used to
> sandbox threaded applications due to potential race conditions when
> inspecting system call arguments. We hope that we can avoid this
> problem with seccomp.
ptrace certainly has performance issues. I take it the only "reliabili
> Ptrace has performance and/or reliability problems when used to
> sandbox threaded applications due to potential race conditions when
> inspecting system call arguments. We hope that we can avoid this
> problem with seccomp.
ptrace certainly has performance issues. I take it the only "reliabili
> Ptrace has performance and/or reliability problems when used to
> sandbox threaded applications due to potential race conditions when
> inspecting system call arguments. We hope that we can avoid this
> problem with seccomp.
ptrace certainly has performance issues. I take it the only "reliabili
33 matches
Mail list logo
