> On PowerPC we should always use generic ISA DMA API implementation
> as there is simply no other implementation exist.
>
> Without this patch, the following build error pops up:
>
> sound/built-in.o: In function 'snd_dma_pointer':
> (.text+0x74ae): undefined reference to 'dma_spin_lock'
>
> > Aaron pointed the issue on FSL BookE.
> >
> http://lists.ozlabs.org/pipermail/linuxppc-dev/2010-January/079738.htm
> > l
>
> Right, but I think 64-bit BookE has the same issue. We can
> fix that later tho.
Ben,
We also find the _PAGE_USER is different between pte-book3e and old
fsl-booke
I
> Not looking at the code right now ... but do we have the same
> issue on 64e ?
Aaron pointed the issue on FSL BookE.
http://lists.ozlabs.org/pipermail/linuxppc-dev/2010-January/079738.html
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
ht
> I've updated the commit message to be a bit more clear on why
> we need to do this.
I'm curious why the _PAGE_EXEC have different definition in pte-book3e.h
and pte-fsl-booke.h?
It is UX permission in pte-book3e, but is SX permission in
pte-fsl-booke.h.
Thanks, Dave
__
> On Fri, Nov 27, 2009 at 04:16:43PM +0800, Dave Liu wrote:
> > current the Rx/Tx FIFO size settings cause problem
> > when four UEC ethernets work simultaneously.
> >
> > eg: GETH1, UEM-J15, GETH2, UEC-J5 on 8569MDS board
> >
> > $ ifconfig eth0 10.193.20.166
> > $ ifconfig eth1 10.193.20.167
One possible cause is the two board has different RCW.
So that the freq of core/csb/ Is different.
> -Original Message-
> From:
> linuxppc-dev-bounces+daveliu=freescale@lists.ozlabs.org
> [mailto:linuxppc-dev-bounces+daveliu=freescale@lists.ozlab
> s.org] On Behalf Of RONETI
> Some discussion with the the freescale rep. lead to the CSB frequency
> of the 8313 (166MHz) being significantly lower than that of the 8343.
> Is the CSB the critical point here?
I believe the CSB is critical point here. They are right.
> Note: the IXP42x uses an internal bus speed of 133MHz
> > On Aug 6, 2009, at 1:00 PM, Lutz Jaenicke wrote:
> >> With the mpc8...@400mhz I get a throughput of approx.
> 24500 frames/s
> >> using the predefined firewall rules.
>
> >> With the MPC8313 I get a significantly lower value:
> >> mpc8...@250mhz 12500fps
> >> mpc8...@333mhz
I believe the question should be sent to u-b...@lists.denx.de,
not linuxppc-dev list.
What is the TLB settings for NAND FCM buffer? Pay attention
to set the TLB as cache inhibited and guarded attribute.
If not set the guarded bit, it is possible to cause the speculate
load from FCM buffer below t
Guys,
The ucc_geth ethernet driver have dozens of strong sync read/write
operation, such as in_be32/16/8, out_be32/16/8.
all of them is sync read/write, it is very expensive for performance.
For the critical patch, we can remove some unnecessary in_be(x),
out_be(x) with normal memory operation,
> I have a custom board similar to MPC8560ADS board with 1GB
> DDR SDRAM. The DDR SDRAM Make
> is MT18VDDF12872DG-335D3. In U-BOOT (2009.01) config file I
> have enabled CONFIG_SPD_EEPROM
> so U-boot configures MPC8560ADS DDR controller with the
> values read from SPD_EEPROM (i2c
> address 0x51)
>> You are assuming the PCI memory space is prefetchable( no side effect)
>> for DMA.
>> Is it possible that DMA is from non-prefetchable memory space?
> This should be a safe assumption for this driver. Remember, this
> driver just does offload memcpy, from one region to another. So the
> PCI m
> Subject: [PATCH 2/2] powerpc/85xx: Add new LAW & MCM device
> tree nodes for all85xx systems
One nit/typo, the tittle of the two patches should be "ECM"
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc
> >> You can mark the pci inbound window on the 83xx as
> >> non-prefetchable(assuming 83xx is host). On a x86 host
> >> I doubt there is any easy way to get non-prefetchable memory.
> One more note; we don't have access to a host-mode MPC8349EA,
> our boards are all targets.
Actually we also ca
> Here's a few results from DMA tests between two
> MPC8349EA boards housed in a CPCI chassis.
>
> 1. DMA mode register (DMAMRn)
> PCI read command (PRC, bits 11:10)
>
> a) DMAMRn[PRC] = 00 = PCI Read
>
>The PCI read command is 6h on the PCI bus.
>For DMA lengths of less
> > You are assuming the PCI memory space is prefetchable( no
> > side effect) for DMA.
> > Is it possible that DMA is from non-prefetchable memory space?
>
> This should be a safe assumption for this driver. Remember, this
> driver just does offload memcpy, from one region to another. So the
>
> By default, the Freescale 83xx DMA controller uses the PCI Read Line
> command when reading data over the PCI bus. Setting the
> controller to use the PCI Read Multiple command instead allows the
> controller to read much larger bursts of data, which provides a
drastic
> speed increase.
IIRC, t
So the host bridge is important, what is the bridge?
Marvell or Tundra chipset?
From: Nicolas Lavocat [mailto:nicolas.lavo...@fr.thalesgroup.com]
Sent: Wednesday, April 22, 2009 4:32 PM
To: Liu Dave-R63238
Cc: linuxppc-dev
> I' am trying to configure a PCI bridge on a private board, with a
> powerpc . In a first time, I tried to get informations about PCI
> devices, in order to be sure that my read and write methods work (
> using 2 configuration registers, like on an x86 architecture.) . 2
> configuration reg
> + L2: l2-cache-control...@2 {
> + compatible = "fsl,p2020-l2-cache-controller";
> + reg = <0x2 0x1000>;
> + cache-line-size = <32>; // 32 bytes
> + cache-size = <0x10>; // L2, 1M
> +
Guys,
The commit 03d70617 is using the dcbf for all of unaligned start
or non-multi cache line of size. It will cause performance lost
due to dcbf all M-state cache line in the whole address range
(start->end). It causes unnecessary bus traffic (when the mid part
of range with M-state).
However,
> It's because the irqs are remapped by the kernel, the number in the
> device tree is a hardware irq number. The number you're printing out is
> a virtual irq number.
> of_irq_to_resource() is doing the remapping for you.
> You can turn on CONFIG_VIRQ_DEBUG and you'll get a file in debugfs that
--- a/arch/powerpc/include/asm/mpic.h
+++ b/arch/powerpc/include/asm/mpic.h
@@ -22,6 +22,7 @@
#define MPIC_GREG_FEATURE_10x00010
#define MPIC_GREG_GLOBAL_CONF_00x00020
#defineMPIC_GREG_GCONF_RESET 0x8000
+#defineMP
ehavior of the initiator's transaction.
For 8315, it is outbound, not inbound transaction.
Thanks, Dave
From: Ben Menchaca [mailto:ben.mench...@gmail.com]
Sent: Saturday, March 07, 2009 12:30 AM
To: Liu Dave-R63238
C
ehavior of the initiator's transaction.
For 8315, it is outbound, not inbound transaction.
Thanks, Dave
From: Ben Menchaca [mailto:ben.mench...@gmail.com]
Sent: Saturday, March 07, 2009 12:30 AM
To: Liu Dave-R63238
C
Timur,
See the section 14.7.1 DMA Description Format at page 14-112
of MPC8315ERM rev.1.
> -Original Message-
> From: timur.t...@gmail.com [mailto:timur.t...@gmail.com] On
> Behalf Of Tabi Timur-B04825
> Sent: Sunday, March 08, 2009 11:20 PM
> To: Liu Dave-R63238
>
Did you enable the descriptor bit 3 to have a try?
From: Ben Menchaca [mailto:ben.mench...@gmail.com]
Sent: Friday, March 06, 2009 2:10 PM
To: Liu Dave-R63238
Cc: linuxppc-dev@ozlabs.org
Subject: Re: 83xx: Marking or
could you try to set '1' to DMA description bit3?
From: Liu Dave-R63238
Sent: Friday, March 06, 2009 1:41 PM
To: 'Ben Menchaca'
Cc: linuxppc-dev@ozlabs.org
Subject: RE: 83xx: Marking or Allocating Page
what is the value of ACR register?
From: Ben Menchaca [mailto:ben.mench...@gmail.com]
Sent: Friday, March 06, 2009 1:38 PM
To: Liu Dave-R63238
Cc: linuxppc-dev@ozlabs.org
Subject: Re: 83xx: Marking or Allocating Pages as
and what settings is DMA description bit 3?
> -Original Message-
> From: linuxppc-dev-bounces+daveliu=freescale@ozlabs.org
> [mailto:linuxppc-dev-bounces+daveliu=freescale@ozlabs.org]
> On Behalf Of Liu Dave-R63238
> Sent: Friday, March 06, 2009 1:22 PM
>
Did you enable the snoop bit at PEX_WDMA_CTRL[SNOOP]
and PEX_RDMA_CTRL[SNOOP]?
What is the freq settings? CORE/CSB bus.
Thanks, Dave
From: linuxppc-dev-bounces+daveliu=freescale@ozlabs.org
[mailto:linuxppc-dev-bounces+daveliu=freescale@ozlabs.org
> Now i'm porting the u-boot to my board refer to the mpc8313erdb.
> I see that in the header file mpc8313erdb.h there is a define:
> #define CFG_INIT_RAM_ADDR 0xFD00
> In the memory map ,this address does not locate at any window.
> So what is the ram?
xiangyu,
It is one trick, we are using
> I'm afraid I haven't seen any readily available sources for their
> driver. If you meant Ben's version, you can find the latest revision
> here:
>
> http://marc.info/?t=12282326615
>
> Unfortunately marc.info didn't sort out the threading, but you should
> be able to find all the patches th
> Probably because it was quicker. Samsung did the same thing, but now
> Ben Dooks has patches to properly support it via sdhci.
Pierre,
What samsung driver are you talking? Could you point it to me?
Thanks, Dave
___
Linuxppc-dev mailing list
Linuxppc-d
> This patch adds support for the Freescale Enhanced Secure Digital
> Host Controller Interface as found in some Freescale PowerPC
> microprocessors (e.g. MPC837x SOCs).
The Freescale ESDHC controller is basically compatible with the
standard SDHC controller. but the eshdc expand some bits.
The e
> I'm using the MPC8313ERDB.I readed the BSP user manual.
> I found the NAND is 32M bytes.
> But in the UM's memory map,it is only from 0xe280_ to
> 0xe280_7fff,just 32K bytes.
> Can anyone help to understand this problem?
It is indirect access the NAND flash by 8313,
the 8313 has to use o
Acked-by: Dave Liu
> -Original Message-
> From: linuxppc-dev-bounces+daveliu=freescale@ozlabs.org
> [mailto:linuxppc-dev-bounces+daveliu=freescale@ozlabs.org]
> On Behalf Of Kumar Gala
> Sent: 2009?1?9? 8:15 AM
> To: linuxppc-dev@ozlabs.org
> Subject: [PATCH 2/2] powerpc/e500mc:
> +static void __iomem *mpc83xx_pcie_remap_cfg(struct pci_bus *bus,
> + unsigned int devfn,
[snip]
> + if (pcie->dev_base == dev_base)
> + goto mapped;
> +
> + out_le32(hose->cfg_data + PEX_OUTWIN0_TAL, dev_base);
> +
> + pcie->dev_
They seem like worm virus. or
The linuxppc-dev really doesn't have love?
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
> +static void __iomem *mpc83xx_pcie_remap_cfg(struct pci_bus *bus,
> + unsigned int devfn, int offset)
> +{
> + struct pci_controller *hose = bus->sysdata;
> + struct mpc83xx_pcie *pcie = hose->dn->data;
> + u8 bus_no = bus->number - hose->first_busno;
>
> > Basic PM support for 83xx. Standby is implemented as sleep.
> > Suspend-to-RAM is implemented as "deep sleep" (with the processor
> > turned off) on 831x. PCI agent power management is supported.
> >
> > Device power management of SOC peripherals is not yet supported.
>
> (Not comments on th
Thanks Paul.
> > So, does power management patch from Scott Wood need to respin?
>
> No, because Scott's original patch did that too.
Yes, one of scott's patchset did the same function too. So the patch
http://patchwork.ozlabs.org/linuxppc/patch?id=18182
will conflict with your patch.
That is
> This provides a way to defer processing of an interrupt that wakes the
> processor out of sleep mode. On 32-bit platforms that use an
> interrupt to wake the processor, we have to have interrupts enabled in
> hardware at the point where we go to sleep, otherwise the processor
> will never wake
> On Oct 19, 2007, at 10:35 AM, Grant Likely wrote:
>
> > On 10/19/07, Li Yang <[EMAIL PROTECTED]> wrote:
> >> The SerDes(serializer/deserializer) PHY block is a new SoC
> block used
> >> in Freescale chips to support multiple serial interfaces,
> such as PCI
> >> Express, SGMII, SATA.
> >
> > T
> > The end result simply adds a line to set MBAR to match IMMRBAR.
> >
> > lis r3, [EMAIL PROTECTED]
> > ori r3, r3, [EMAIL PROTECTED]
> > stw r3, IMMRBAR(r4)
> > + mtspr MBAR, r3
> >
> > Are these patches routinely added to the mainstream u-boot code?
45 matches
Mail list logo
