> -Original Message-
> From: linuxppc-dev-bounces+b13201=freescale@ozlabs.org
> [mailto:linuxppc-dev-bounces+b13201=freescale@ozlabs.org]
> On Behalf Of derekzheng
> Sent: Sunday, April 19, 2009 5:25 PM
> To: 'linuxppc-dev'; microblaze-ucli...@itee.uq.edu.au;
> linux-ker...@vger
thanks for you help.
i am sorry,i make a mistake , i can not update my mail list
derek zheng
在2009-04-20,"Kumar Gala" 写道:
>
>On Apr 19, 2009, at 4:25 AM, derekzheng wrote:
>
>> Hi all guys:
>>
>> The Freescale MPC8536DS board Integrated TestFloat cases, and I do
>> not know how to tes
My thinking is that these drivers are likely to be used as a group,
hence it would be nice to make it easy to get them all visible/enabled somehow.
Steve
-Original Message-
From: John Williams [mailto:john.willi...@petalogix.com]
Sent: Sun 4/19/2009 4:03 PM
To: microblaze-ucli...@itee.uq
Hi Ben,
Wolfgang Grandegger wrote:
> Wolfgang Grandegger wrote:
>> Kumar Gala wrote:
>>> On Apr 8, 2009, at 2:25 AM, Wolfgang Grandegger wrote:
>>>
> So I'm a bit concerned with the output we now get:
>
> mpc-i2c fffe03000.i2c: clock 0 Hz (dfsrr=16 fdr=49)
>
> why 0? is that ri
On Fri, Apr 17, 2009 at 8:32 PM, Kyle Moffett wrote:
> Hello,
>
> I'm currently fiddling with a custom embedded prototype board using
> the ibm_newemac driver with some currently-unsupported PHYs. Those
> PHYs *are* supported by phylib, but the emac driver seems to have its
> own PHY layer cribbe
On Mon, Apr 20, 2009 at 3:01 AM, Wolfgang Grandegger
wrote:
> Hi Ben,
>
> Wolfgang Grandegger wrote:
>> Wolfgang Grandegger wrote:
>>> Kumar Gala wrote:
On Apr 8, 2009, at 2:25 AM, Wolfgang Grandegger wrote:
>> So I'm a bit concerned with the output we now get:
>>
>> mpc-i2c
With PREEMPT_RT and HIGHMEM on ppc32 (8572ds eval board), there is a
lot of coredumps (data access, 0x300) very early in the boot
process. There is no problem when using only one of PREEMPT_RT or
HIGHMEM.
I also tried rt1 and rt7 and it's the same behavior.
Ccing linuxppc-dev in case someone
Hi EveryOne!
This is first time I send a letter to everyone. If I make mistake,
please free to correct me. :)
I'm trying to write the first driver which is concerned with DMA. I'm
reading dmatest.c and have some confused problem. Oh! No! I have many
problem..:D
MPC8349's DMA controller like I
> -Original Message-
> From: Stephen Neuendorffer
> Sent: Sunday, April 19, 2009 11:52 PM
> To: John Williams; microblaze-ucli...@itee.uq.edu.au
> Cc: grant.lik...@secretlab.ca; linuxppc-dev; linux-ker...@vger.kernel.org;
> John Linn
> Subject: RE: [microblaze-uclinux] [PATCH 11/11] microb
On Mon, Apr 20, 2009 at 8:36 AM, John Linn wrote:
>> -Original Message-
>> From: Stephen Neuendorffer
>> Sent: Sunday, April 19, 2009 11:52 PM
>> To: John Williams; microblaze-ucli...@itee.uq.edu.au
>> Cc: grant.lik...@secretlab.ca; linuxppc-dev; linux-ker...@vger.kernel.org;
>> John Linn
The ULI 1575 PCI quirk function for the Freescale MPC8610 HPCD was disabling
the SATA INTx interrupt, even when SATA support was enabled. This was safe,
because the SATA driver re-enabled it. But with commit a5bfc471 ("ahci: drop
intx manipulation on msi enable"), the driver no longer does this,
On Mon, Apr 20, 2009 at 07:38:13PM +0700, lhthanh wrote:
>
> Hi EveryOne!
>
> This is first time I send a letter to everyone. If I make mistake,
> please free to correct me. :)
Please post in plaintext, not HTML.
> MPC8349's DMA controller like ISA controller but with more features?
No. It i
GIT: Please enter your email below.
GIT: Lines beginning in "GIT: " will be removed.
GIT: Consider including an overall diffstat or table of contents
GIT: for the patch you are writing.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs
GIT: Please enter your email below.
GIT: Lines beginning in "GIT: " will be removed.
GIT: Consider including an overall diffstat or table of contents
GIT: for the patch you are writing.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs
Also, convert them to resource_size_t (which is unsigned long
on 64-bit, so it's not a change there).
We will be using these on fsl 32b to indicate the start and size
address of memory that the pci controller can actually reach - this
is needed to determine if an address requires bounce buffering.
Currently, the 32-bit code uses sg->length instead of sg->dma_lentgh
to report sg_dma_len. However, since the default dma code for 32-bit
(the dma_direct case) sets dma_length and length to the same thing,
we should be able to use dma_length there as well. This gets rid of
some 32-vs-64-bit ifdef
This patch series allows the use of swiotlb on mpc86xx, with 85xx
support soon to follow. The most notable change here is the addition
of addr_needs_map to dma_ops. This is used to tell if a device
can reach an address without bounce buffering. I believe that patches
will be coming out soon to
Minor code to allow enabling swiotlb on mpc86xx, including
Kconfig addition for SWIOTLB.
Signed-off-by: Becky Bruce
---
arch/powerpc/Kconfig | 10 ++
arch/powerpc/kernel/dma-swiotlb.c |2 ++
arch/powerpc/platforms/86xx/mpc86xx_hpcn.c |3 +++
3 fil
The new dts places most of the devices in physical address space
above 32-bits, which allows us to have more than 4GB of RAM present.
Signed-off-by: Becky Bruce
---
arch/powerpc/boot/dts/mpc8641_hpcn_36b.dts | 597
1 files changed, 597 insertions(+), 0 deletions(-)
This patch includes the basic infrastructure to use swiotlb
bounce buffering on 32-bit powerpc. It is not yet enabled on
any platforms.
Signed-off-by: Becky Bruce
---
arch/powerpc/Kconfig |2 +-
arch/powerpc/include/asm/dma-mapping.h | 11 ++
arch/powerpc/include/asm/swi
FAIL.
Here's the text that should have been there :)
-B
This patch series allows the use of swiotlb on mpc86xx, with 85xx
upport soon to follow. The most notable change here is the addition
of addr_needs_map to dma_ops. This is used to tell if a device
can reach an address without bounce buff
On Apr 20, 2009, at 11:26 AM, Becky Bruce wrote:
This patch includes the basic infrastructure to use swiotlb
bounce buffering on 32-bit powerpc. It is not yet enabled on
any platforms.
Signed-off-by: Becky Bruce
---
arch/powerpc/Kconfig |2 +-
arch/powerpc/include/asm/dm
On Apr 20, 2009, at 11:26 AM, Becky Bruce wrote:
Also, convert them to resource_size_t (which is unsigned long
on 64-bit, so it's not a change there).
We will be using these on fsl 32b to indicate the start and size
address of memory that the pci controller can actually reach - this
is needed
On Apr 20, 2009, at 11:26 AM, Becky Bruce wrote:
Minor code to allow enabling swiotlb on mpc86xx, including
Kconfig addition for SWIOTLB.
Signed-off-by: Becky Bruce
---
arch/powerpc/Kconfig | 10 ++
arch/powerpc/kernel/dma-swiotlb.c |2 ++
arch/power
On Mon, Apr 20, 2009 at 10:55 AM, Scott Wood wrote:
> No. It is for software-directed memory-to-memory transfers (where
> "memory" can be main-memory, or the buffer of a device that doesn't do
> DMA itself).
It can also be used to transfer data to/from a single I/O register,
which is how ISA DM
On Apr 20, 2009, at 12:00 PM, Kumar Gala wrote:
On Apr 20, 2009, at 11:26 AM, Becky Bruce wrote:
Minor code to allow enabling swiotlb on mpc86xx, including
Kconfig addition for SWIOTLB.
Signed-off-by: Becky Bruce
---
arch/powerpc/Kconfig | 10 ++
arch/powerpc
On Apr 20, 2009, at 11:57 AM, Kumar Gala wrote:
On Apr 20, 2009, at 11:26 AM, Becky Bruce wrote:
This patch includes the basic infrastructure to use swiotlb
bounce buffering on 32-bit powerpc. It is not yet enabled on
any platforms.
Signed-off-by: Becky Bruce
---
arch/powerpc/Kconfig
On Apr 20, 2009, at 11:26 AM, Becky Bruce wrote:
+static int ppc_swiotlb_bus_notify(struct notifier_block *nb,
+ unsigned long action, void *data)
+{
+ struct device *dev = data;
+
+ /* We are only intereted in device addition */
+ if (action !=
On Apr 20, 2009, at 1:31 PM, Kumar Gala wrote:
On Apr 20, 2009, at 11:26 AM, Becky Bruce wrote:
+static int ppc_swiotlb_bus_notify(struct notifier_block *nb,
+ unsigned long action, void *data)
+{
+ struct device *dev = data;
+
+ /* We are only int
On Apr 20, 2009, at 2:06 PM, Becky Bruce wrote:
On Apr 20, 2009, at 1:31 PM, Kumar Gala wrote:
On Apr 20, 2009, at 11:26 AM, Becky Bruce wrote:
+static int ppc_swiotlb_bus_notify(struct notifier_block *nb,
+ unsigned long action, void *data)
+{
+ stru
On Apr 20, 2009, at 11:26 AM, Becky Bruce wrote:
Currently, the 32-bit code uses sg->length instead of sg->dma_lentgh
to report sg_dma_len. However, since the default dma code for 32-bit
(the dma_direct case) sets dma_length and length to the same thing,
we should be able to use dma_length the
Kumar Gala wrote:
I'm suggesting we do it one for FSL in fsl_soc.c, the 4xx guys can do it
once, etc. Since the behavior desired is going to be a bit unique to
SoCs/chipsets.
Perhaps we should have a dma_mask in platform/of_platform device
structs? The driver knows best how many bits it can
The legacy i2c binding model is going away soon, so convert the AOA
codec drivers to the new model or they'll break.
Signed-off-by: Jean Delvare
Tested-by: Johannes Berg
Tested-by: Andreas Schwab
Cc: Benjamin Herrenschmidt
Cc: Takashi Iwai
---
Takashi, please push this patch to Linus quickly,
The legacy i2c binding model is going away soon, so convert the ppc
keywest sound driver to the new model or it will break.
Signed-off-by: Jean Delvare
Cc: Benjamin Herrenschmidt
Cc: Takashi Iwai
---
Takashi, please push this patch to Linus quickly, as this is blocking
the removal of the legacy
On Mon, 2009-04-20 at 22:54 +0200, Jean Delvare wrote:
> The legacy i2c binding model is going away soon, so convert the AOA
> codec drivers to the new model or they'll break.
>
> Signed-off-by: Jean Delvare
> Tested-by: Johannes Berg
> Tested-by: Andreas Schwab
> Cc: Benjamin Herrenschmidt
>
On Fri, Apr 17, 2009 at 11:35 PM, Grant Likely
wrote:
> On Fri, Apr 17, 2009 at 4:07 PM, Ilpo Järvinen
>> [PATCH] powerpc & microblaze: add missing of_node_put to error handling
>>
>> While reviewing some microblaze patches a while ago, I noticed
>> a suspicious error handling in of_irq_map_one(),
Hi Ben/Paul,
Here's an updated pull request with 5200 defconfig updates and a
bugfix to prom_parse.c
Cheers,
g.
The following changes since commit 0882e8dd3aad33eca41696d463bb896e6c8817eb:
Linus Torvalds (1):
Linux 2.6.30-rc2
are available in the git repository at:
git://git.secret
Jean Delvare writes:
> Takashi, please push this patch to Linus quickly, as this is blocking
> the removal of the legacy i2c binding model, which is scheduled for
> 2.6.30.
I really don't think you can remove it from Linus' tree at this stage
in the 2.6.30 cycle. If it was going to be removed it
On Mon, Apr 20, 2009 at 11:26:47AM -0500, Becky Bruce wrote:
> The new dts places most of the devices in physical address space
> above 32-bits, which allows us to have more than 4GB of RAM present.
>
> Signed-off-by: Becky Bruce
> ---
> arch/powerpc/boot/dts/mpc8641_hpcn_36b.dts | 597
> +
On Mon, 2009-04-20 at 12:58 -0500, Becky Bruce wrote:
> On Apr 20, 2009, at 12:00 PM, Kumar Gala wrote:
> > On Apr 20, 2009, at 11:26 AM, Becky Bruce wrote:
> >>
> >> config PPC_NEED_DMA_SYNC_OPS
> >>def_bool y
> >>depends on (NOT_COHERENT_CACHE || SWIOTLB)
> >> diff --git a/arch/powerpc/ke
On Tue, Apr 21, 2009 at 12:48 AM, Grant Likely
wrote:
> On Mon, Apr 20, 2009 at 8:36 AM, John Linn wrote:
>>> -Original Message-
>>> From: Stephen Neuendorffer
>>> Sent: Sunday, April 19, 2009 11:52 PM
>>> To: John Williams; microblaze-ucli...@itee.uq.edu.au
>>> Cc: grant.lik...@secretlab
On Mon, 20 Apr 2009 15:06:16 -0500
Kumar Gala wrote:
>
> On Apr 20, 2009, at 11:26 AM, Becky Bruce wrote:
>
> > Currently, the 32-bit code uses sg->length instead of sg->dma_lentgh
> > to report sg_dma_len. However, since the default dma code for 32-bit
> > (the dma_direct case) sets dma_lengt
On Mon, 20 Apr 2009 13:03:20 -0500
Becky Bruce wrote:
>
> On Apr 20, 2009, at 11:57 AM, Kumar Gala wrote:
>
> >
> > On Apr 20, 2009, at 11:26 AM, Becky Bruce wrote:
> >
> >> This patch includes the basic infrastructure to use swiotlb
> >> bounce buffering on 32-bit powerpc. It is not yet enabl
On Mon, Apr 20, 2009 at 8:29 AM, Josh Boyer wrote:
> On Fri, Apr 17, 2009 at 8:32 PM, Kyle Moffett wrote:
>> Hello,
>>
>> I'm currently fiddling with a custom embedded prototype board using
>> the ibm_newemac driver with some currently-unsupported PHYs. Those
>> PHYs *are* supported by phylib, b
On Tue, Apr 07, 2009 at 03:17:29PM +1000, Paul Mackerras wrote:
> David Gibson writes:
>
> > The vast bulk of this patch is a literal move, the rest is adjusting
> > the various Makefiles to use dtc and libfdt correctly from their new
> > locations.
>
> Did you test this with a separate object di
The powerpc kernel always requires an Open Firmware like device tree
to supply device information. On systems without OF, this comes from
a flattened device tree blob. This blob is usually generated by dtc,
a tool which compiles a text description of the device tree into the
flattened format used
On Thu, Feb 26, 2009 at 3:49 PM, Ira Snyder wrote:
> On Thu, Feb 26, 2009 at 09:37:14PM +0100, Arnd Bergmann wrote:
>> If the registers for setting up this window don't logically fit
>> into the same device as the one you already use, the cleanest
>> solution would be to have another device just f
At Mon, 20 Apr 2009 22:54:25 +0200,
Jean Delvare wrote:
>
> The legacy i2c binding model is going away soon, so convert the AOA
> codec drivers to the new model or they'll break.
>
> Signed-off-by: Jean Delvare
> Tested-by: Johannes Berg
> Tested-by: Andreas Schwab
> Cc: Benjamin Herrenschmidt
At Mon, 20 Apr 2009 22:56:59 +0200,
Jean Delvare wrote:
>
> The legacy i2c binding model is going away soon, so convert the ppc
> keywest sound driver to the new model or it will break.
>
> Signed-off-by: Jean Delvare
> Cc: Benjamin Herrenschmidt
> Cc: Takashi Iwai
> ---
> Takashi, please push
At Tue, 21 Apr 2009 08:34:02 +1000,
Paul Mackerras wrote:
>
> Jean Delvare writes:
>
> > Takashi, please push this patch to Linus quickly, as this is blocking
> > the removal of the legacy i2c binding model, which is scheduled for
> > 2.6.30.
>
> I really don't think you can remove it from Linus
50 matches
Mail list logo