eth1 on nfsboot problem

[yamazaki seiji]

Hi all,

I am running the Linux kernel 2.6.28.7 on my PPC8347 BRD.
I have a problem.

nfsboot is succeeded,but eth1 fail to ifup like following message.

IP-Config: Complete:
 device=eth0, addr=192.168.0.131, mask=255.255.255.0, gw=192.168.0.1,
 host=mpc8347TPRO, domain=, nis-domain=(none),
 bootserver=192.168.0.123, rootserver=192.168.0.123, rootpath=
md: Waiting for all devices to be available before autodetect
md: If you don't use raid, use raid=noautodetect
md: Autodetecting RAID arrays.
md: Scanned 0 and added 0 devices.
md: autorun ...
md: ... autorun DONE.
Looking up port of RPC 13/2 on 192.168.0.123
PHY: 24520:01 - Link is Up - 100/Full
Looking up port of RPC 15/1 on 192.168.0.123
VFS: Mounted root (nfs filesystem).
Freeing unused kernel memory: 184k init
INIT: version 2.86 booting
Starting the hotplug events dispatcher: udevd.
Synthesizing the initial hotplug events...done.
Waiting for /dev to be fully populated...done.
Activating swap...done.
Remounting root filesystem...done.
mount: according to mtab, /dev/root is already mounted on /

Calculating module dependencies
Loading modules:
Starting checking all file systems: fsck
fsck 1.40 (29-Jun-2007)
Starting mounting local filesystems: mount /dev/mtdblock1 on /mnt/flash type 
jffs2 (rw)
/dev/mtdblock2 on /mnt/flash2 type jffs2 (rw)
umount.nfs: /dev/root: not found or not mounted
Setting up networking 
/etc/network/options is deprecated.
Setting up IP spoofing protection: rp_filter done.
Disabling TCP/IP SYN cookies: done.
Disabling IPv4 packet forwarding: done.
Disabling TCP/IP Explicit Congestion Notification: done.
Starting network interfaces: SIOCADDRT: File exists
Failed to bring up eth0.
SIOCSIFADDR: No such device
eth1: ERROR while getting interface flags: No such device
SIOCSIFNETMASK: No such device
eth1: ERROR while getting interface flags: No such device
Failed to bring up eth1.
done.

but on ramboot,eth1 succeed to ifup.
What is the difference between nfsboot and ramboot?

-- 
yamazaki seiji yamazaki.se...@kk.jp.panasonic.com

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

RE: who know's what is TestFloat cases and how to test this feature onthe Freescale MPC8536DS board

[Liu Yu-B13201]

 -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.kernel.org
 Subject: who know's what is TestFloat cases and how to test 
 this feature onthe Freescale MPC8536DS board
 
 Hi all guys:
 
 The Freescale MPC8536DS board Integrated TestFloat cases, and 
 I do not know how to test this feature on this board.
 Please tell me how to test it if you known
 

You can find the user manual E500v2 SPE Floating Point in BSP iso.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re:Re: who know's what is TestFloat cases and how to test this feature on the Freescale MPC8536DS board

[zhengxiang9]

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 ga...@kernel.crashing.org 写道：

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 test this feature on this board.
 Please tell me how to test it if you known

1. why are you CC' the microblaze list on this question?
2. I assume you are talking about the FSL BSP for MPC8536DS
3. testfloat is a set of tests.  Its not clear what your question is.   
You build testfloat and run it and it reports pass/fails.

- k
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

RE: [microblaze-uclinux] [PATCH 11/11] microblaze: Kconfig: Enable drivers for Microblaze

[Stephen Neuendorffer]

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.edu.au
Cc: grant.lik...@secretlab.ca; Stephen Neuendorffer; linuxppc-dev; 
linux-ker...@vger.kernel.org; John Linn
Subject: Re: [microblaze-uclinux] [PATCH 11/11] microblaze: Kconfig: Enable 
drivers for Microblaze
 
On Sun, Apr 19, 2009 at 12:41 PM, Stephen Neuendorffer
stephen.neuendorf...@gmail.com wrote:


 On Fri, Apr 17, 2009 at 10:49 PM, Grant Likely grant.lik...@secretlab.ca
 wrote:

 On Fri, Apr 17, 2009 at 11:06 AM, Stephen Neuendorffer
 stephen.neuendorf...@xilinx.com wrote:
 
  Can we have XILINX_DRIVERS, please?  That way this can also be enabled
  on any architecture that has FPGA peripherals.

 I've thought about this more, and I'd really rather not.  The list of
 affected drivers is short and is not a large maintenance burden.  I
 don't think a list of 2 or 3 architecture selects for each driver is
 unreasonable.  A XILINX_DRIVERS config item doesn't really help much
 anyway.  At any given time one of these drivers may be needed on
 another platform.  ie. the SystemACE device is present on at least one
 non-virtex, non-spartan platform.

 Which is exactly why having it architecture dependent isn't right...  All of
 these drivers
 could be needed and used on any OF-based platform.  If you have a platform
 (for instance, a processor connected to an FPGA which has these peripherals
 in the FPGA) then you should be able to enable these drivers.  Just my 2
 cents...

What about the radical approach of having NO architecture
filters/selectors?  Even if some random i386 user selects one of these
drivers, so what?  It will still compile cleanly (if it doesn't we
have to fix it), but there'll be no platform_device_register() call in
their machine startup to actually cause driver / device binding.

No harm, no foul.  Problem goes away.

Then, as Grant points out, the rare cases where non-Xilinx platforms
do use this stuff, they'll presumably know what they're doing and it's
their responsibility to register the appropriate platform_device
structures and make the magic happen.

John
-- 
John Williams, PhD, B.Eng, B.IT
PetaLogix - Linux Solutions for a Reconfigurable World
w: www.petalogix.com  p: +61-7-30090663  f: +61-7-30090663




This email and any attachments are intended for the sole use of the named 
recipient(s) and contain(s) confidential information that may be proprietary, 
privileged or copyrighted under applicable law. If you are not the intended 
recipient, do not read, copy, or forward this email message or any attachments. 
Delete this email message and any attachments immediately.

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH v3 0/5] i2c: i2c-mpc: make I2C bus speed configurable

[Wolfgang Grandegger]

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 right?
 This is the backward compatibility mode using hard-coded FDR values. The
 output is missleading, I agree.

 Wolfgang.
 Can the output be fixed.  0 Hz seemed bad to me.
 Of course. No info message will be printed for the legacy case
 like it was with the old driver version. I just realized a bug in the
 MPC52xx part. Will send patches tomorrow, after some more thorough testing.
 
 The patch below fixes both issues. Ben, could you please apply it. Sorry for
 the inconvenience caused.
 
 Thanks,
 
 Wolfgang.
 
 
 
 [PATCH] i2c: i2c-mpc: bug fix for MPC52xx clock setting and printout
 
 The clock setting did not work for the MPC52xx due to a stupid bug.
 Furthermore, the dev info output clock=0 for old device trees was
 misleading. This patch fixes both issues.
 
 Signed-off-by: Wolfgang Grandegger w...@grandegger.com

Could you please apply this bug-fix for the MPC driver for 2.6.30.

  http://marc.info/?l=linux-i2cm=123927120910293w=2

Thanks,

Wolfgang.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: Porting the ibm_newemac driver to use phylib (and other PHY/MAC questions)

[Josh Boyer]

On Fri, Apr 17, 2009 at 8:32 PM, Kyle Moffett k...@moffetthome.net 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 cribbed from the sungem driver.  I'm curious if there's
 some particular reason it hasn't been ported (aside from nobody has
 bothered yet).

IIRC, Ben had some issues with how phylib and the EMAC would need to
interact.  Not sure if he has those written down somewhere or not.
(CC'd).

 I've temporarily hacked a PHY driver together for the moment, but it
 would be much easier for us to maintain and update our board if the
 PHY drivers were integrated.  As a result I'm also interested in how
 complicated it might be to port the driver (and possibly sungem as
 well) over to phylib, if that is indeed feasible.  Also, if I end up
 going that route, are there others available with other hardware
 variants who would be willing to test my patches on their boards?

I have a large variety of boards that I can test with since the entire
4xx line relies on this driver for on-board network.

josh
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH v3 0/5] i2c: i2c-mpc: make I2C bus speed configurable

[Grant Likely]

On Mon, Apr 20, 2009 at 3:01 AM, Wolfgang Grandegger w...@grandegger.com 
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 fffe03000.i2c: clock 0 Hz (dfsrr=16 fdr=49)

 why 0? is that right?
 This is the backward compatibility mode using hard-coded FDR values. The
 output is missleading, I agree.

 Wolfgang.
 Can the output be fixed.  0 Hz seemed bad to me.
 Of course. No info message will be printed for the legacy case
 like it was with the old driver version. I just realized a bug in the
 MPC52xx part. Will send patches tomorrow, after some more thorough testing.

 The patch below fixes both issues. Ben, could you please apply it. Sorry for
 the inconvenience caused.

 Thanks,

 Wolfgang.



 [PATCH] i2c: i2c-mpc: bug fix for MPC52xx clock setting and printout

 The clock setting did not work for the MPC52xx due to a stupid bug.
 Furthermore, the dev info output clock=0 for old device trees was
 misleading. This patch fixes both issues.

 Signed-off-by: Wolfgang Grandegger w...@grandegger.com

 Could you please apply this bug-fix for the MPC driver for 2.6.30.

Acked-by: Grant Likely grant.lik...@secretlab.ca


  http://marc.info/?l=linux-i2cm=123927120910293w=2

 Thanks,

 Wolfgang.
 ___
 Linuxppc-dev mailing list
 Linuxppc-dev@ozlabs.org
 https://ozlabs.org/mailman/listinfo/linuxppc-dev




-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [Announce] 2.6.29.1-rt8

[Stephane Couture]

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 already  tried this configuration.

backtrace and registers dump:

(no debugging symbols found)
(no debugging symbols found)
Core was generated by `sed s/\/.*//'.
Program terminated with signal 11, Segmentation fault.
[New process 2189]
#0  0x10089fa8 in ?? ()
(gdb) bt
#0  0x10089fa8 in ?? ()
#1  0x10089f90 in ?? ()
#2  0x1006975c in ?? ()
#3  0x1005ceec in ?? ()
#4  0x1005d190 in ?? ()
#5  0x1005dd64 in ?? ()
#6  0x1560 in ?? ()
#7  0x1590 in ?? ()
#8  0x1888 in ?? ()
#9  0x1009894c in ?? ()
#10 0x in ?? ()
(gdb) info register
r0 0x1  1
r1 0xbfc609e0   3217426912
r2 0x0  0
r3 0xd  13
r4 0x1009a0bc   269066428
r5 0x20082044   537403460
r6 0xd  13
r7 0x1007ccd4   268946644
r8 0x2d000  184320
r9 0x0  0
r100x0  0
r110xeee1df40   4007780160
r120xeee1c000   4007772160
r130x100cf11c   269283612
r140xbfd9cdb0   321874
r150xbfd9cda0   3218722208
r160x0  0
r170x0  0
r180x100aa854   269133908
r190x100a3aed   269105901
r200x0  0
r210x100d61ac   269312428
r220xbfd9c1c8   3218719176
r230x1824   268437540
r240x0  0
r250xbfc60a38   3217427000
r260x0  0
r270x0  0
r280x0  0
r290x100c69a8   269248936
r300x100c7110   269250832
r310x100c69a8   269248936
pc 0x10089fa8   0x10089fa8
msr0x2d900  186624
cr 0x40082044   1074274372
lr 0x10089f90   0x10089f90
ctr0xc00feff0   369936
xer0x2000   536870912
orig_r30x0  0
trap   0x300768

Thanks.

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

MPC8349E's DMA controller like ISA controller but with more feature?

[lhthanh]

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 ISA controller but with more features? I
want to mean that MPC8349E's DMA controller will send -MEMR, -MEMW,
-IOR, -IOW ?.
So in DMA APIs such as dma_addr_t dma_map_single(struct device *dev,
void *cpu_addr, size_t size, enum dma_data_direction direction)

*dev will pointer to DMA controller or to peripheral device(FPGA, ISA
device)? From dmatest.c , *dev seem to pointer to a channel of DMA
controller. 
The channel is connected to a peripheral device. So calling the API,
DMA controller will be able to access memory from cpu_addr, and
peripheral device does too?

Look struct dma_async_tx_descriptor *(*device_prep_dma_memcpy)(struct
dma_chan *chan,   dma_addr_t    dest,   dma_addr_t    src,
   
size_t len, unsigned long flags);
I want to DMA from device to memory. So how to I can get address of
peripheral device ?

Regards!


___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

RE: [microblaze-uclinux] [PATCH 11/11] microblaze: Kconfig: Enable drivers for Microblaze

[John Linn]

 -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] microblaze: Kconfig: Enable 
 drivers for Microblaze
 
 
 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


It seems like John's suggestion of no arch filters would satisfy that also. 
Since FPGAs are used in so many different applications this would seem to open 
the drivers up to everyone regardless of what processor they're using. It's 
certainly less complex so I like it in that way.

But maybe I'm missing something here and there's a downside?

-- John

 
 -Original Message-
 From: John Williams [mailto:john.willi...@petalogix.com]
 Sent: Sun 4/19/2009 4:03 PM
 To: microblaze-ucli...@itee.uq.edu.au
 Cc: grant.lik...@secretlab.ca; Stephen Neuendorffer; linuxppc-dev; 
 linux-ker...@vger.kernel.org; John
 Linn
 Subject: Re: [microblaze-uclinux] [PATCH 11/11] microblaze: Kconfig: Enable 
 drivers for Microblaze
 
 On Sun, Apr 19, 2009 at 12:41 PM, Stephen Neuendorffer
 stephen.neuendorf...@gmail.com wrote:
 
 
  On Fri, Apr 17, 2009 at 10:49 PM, Grant Likely grant.lik...@secretlab.ca
  wrote:
 
  On Fri, Apr 17, 2009 at 11:06 AM, Stephen Neuendorffer
  stephen.neuendorf...@xilinx.com wrote:
  
   Can we have XILINX_DRIVERS, please?  That way this can also be enabled
   on any architecture that has FPGA peripherals.
 
  I've thought about this more, and I'd really rather not.  The list of
  affected drivers is short and is not a large maintenance burden.  I
  don't think a list of 2 or 3 architecture selects for each driver is
  unreasonable.  A XILINX_DRIVERS config item doesn't really help much
  anyway.  At any given time one of these drivers may be needed on
  another platform.  ie. the SystemACE device is present on at least one
  non-virtex, non-spartan platform.
 
  Which is exactly why having it architecture dependent isn't right...  All of
  these drivers
  could be needed and used on any OF-based platform.  If you have a platform
  (for instance, a processor connected to an FPGA which has these peripherals
  in the FPGA) then you should be able to enable these drivers.  Just my 2
  cents...
 
 What about the radical approach of having NO architecture
 filters/selectors?  Even if some random i386 user selects one of these
 drivers, so what?  It will still compile cleanly (if it doesn't we
 have to fix it), but there'll be no platform_device_register() call in
 their machine startup to actually cause driver / device binding.
 
 No harm, no foul.  Problem goes away.
 
 Then, as Grant points out, the rare cases where non-Xilinx platforms
 do use this stuff, they'll presumably know what they're doing and it's
 their responsibility to register the appropriate platform_device
 structures and make the magic happen.
 
 John
 --
 John Williams, PhD, B.Eng, B.IT
 PetaLogix - Linux Solutions for a Reconfigurable World
 w: www.petalogix.com  p: +61-7-30090663  f: +61-7-30090663
 


This email and any attachments are intended for the sole use of the named 
recipient(s) and contain(s) confidential information that may be proprietary, 
privileged or copyrighted under applicable law. If you are not the intended 
recipient, do not read, copy, or forward this email message or any attachments. 
Delete this email message and any attachments immediately.


___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

[PATCH] powerpc: don't disable SATA interrupts on Freescale MPC8610 HPCD

[Timur Tabi]

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, and so SATA
support on the 8610 HPCD is broken.

The original quirk function disabled INTx because it caused some other
interrupt problem during early development on this board, but no one remembers
any more what that problem was, and it doesn't seem to occur any more.

Signed-off-by: Timur Tabi ti...@freescale.com
---
 arch/powerpc/platforms/fsl_uli1575.c |5 -
 1 files changed, 0 insertions(+), 5 deletions(-)

diff --git a/arch/powerpc/platforms/fsl_uli1575.c 
b/arch/powerpc/platforms/fsl_uli1575.c
index 1db6b9e..65a35f3 100644
--- a/arch/powerpc/platforms/fsl_uli1575.c
+++ b/arch/powerpc/platforms/fsl_uli1575.c
@@ -275,11 +275,6 @@ static void __devinit hpcd_quirk_uli5288(struct pci_dev 
*dev)
if (!machine_is(mpc86xx_hpcd))
return;
 
-   /* Interrupt Disable, Needed when SATA disabled */
-   pci_read_config_word(dev, PCI_COMMAND, temp);
-   temp |= 110;
-   pci_write_config_word(dev, PCI_COMMAND, temp);
-
pci_read_config_byte(dev, 0x83, c);
c |= 0x80;
pci_write_config_byte(dev, 0x83, c);
-- 
1.6.0.6

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: MPC8349E's DMA controller like ISA controller but with more feature?

[Scott Wood]

On Mon, Apr 20, 2009 at 07:38:13PM +0700, lhthanh wrote:
 body bgcolor=#ff text=#00
 font size=+1Hi EveryOne!br
 br
 This is first time I send a letter to everyone. If I make mistake,
 please free to correct me. :)br

Please post in plaintext, not HTML.

 MPC8349's DMA controller like ISA controller but with more features? 

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).

There is no need for anything like ISA's DMA controller, as devices that
want to initiate DMA can master the bus themselves.

 So in DMA APIs such as dma_addr_t dma_map_single(struct device *dev,
 void *cpu_addr, size_t size, enum dma_data_direction direction)
 *dev will pointer to DMA controller or to peripheral device(FPGA,
 ISA device)?

It is whatever device is going to be doing the DMA.

 From dmatest.c , *dev seem to pointer to a channel of DMA
 controller. 

That's because in that case, the DMA controller is the peripheral
device being used.

 I want to DMA from device to memory. 

What kind of device?

 So how to I can get address of peripheral device ?

If you have to ask that, it probably means you don't have a specific
device buffer in mind that you want an external entity to stuff data into
(or suck data from), but rather are dealing with device-initiated DMA. 
In that case, ignore the DMA controller.

-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

[PATCH 0/5] Allow swiotlb use on ppc/mpc86xx

[Becky Bruce]

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.org/mailman/listinfo/linuxppc-dev

[PATCH 0/5] enable swiotlb on ppc/86xx

[Becky Bruce]

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.org/mailman/listinfo/linuxppc-dev

[PATCH 3/5] powerpc: make dma_window_* in pci_controller struct avail on 32b

[Becky Bruce]

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.  For
now, initialize them to a standard value; in the near future, the
value will be calculated based on how the inbound windows are
programmed.

Signed-off-by: Becky Bruce bec...@kernel.crashing.org
---
 arch/powerpc/include/asm/pci-bridge.h |6 --
 arch/powerpc/sysdev/fsl_pci.c |4 
 2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/include/asm/pci-bridge.h 
b/arch/powerpc/include/asm/pci-bridge.h
index 84007af..9861258 100644
--- a/arch/powerpc/include/asm/pci-bridge.h
+++ b/arch/powerpc/include/asm/pci-bridge.h
@@ -140,10 +140,12 @@ struct pci_controller {
struct resource io_resource;
struct resource mem_resources[3];
int global_number;  /* PCI domain number */
+
+   resource_size_t dma_window_base_cur;
+   resource_size_t dma_window_size;
+
 #ifdef CONFIG_PPC64
unsigned long buid;
-   unsigned long dma_window_base_cur;
-   unsigned long dma_window_size;
 
void *private_data;
 #endif /* CONFIG_PPC64 */
diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c
index 78021d8..376603d 100644
--- a/arch/powerpc/sysdev/fsl_pci.c
+++ b/arch/powerpc/sysdev/fsl_pci.c
@@ -152,6 +152,10 @@ static void __init setup_pci_atmu(struct pci_controller 
*hose,
out_be32(pci-piw[2].piwbar,0x);
out_be32(pci-piw[2].piwar, PIWAR_2G);
 
+   /* Save the base address and size covered by inbound window mappings */
+   hose-dma_window_base_cur = 0x;
+   hose-dma_window_size = 0x8000;
+
iounmap(pci);
 }
 
-- 
1.6.0.6

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

[PATCH 1/5] powerpc: Use sg-dma_length in sg_dma_len() macro on 32-bit

[Becky Bruce]

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 ifdefs, and is needed by the swiotlb code which
actually distinguishes between dma_length and length.

Signed-off-by: Becky Bruce bec...@kernel.crashing.org
---
 arch/powerpc/include/asm/scatterlist.h |6 +-
 1 files changed, 1 insertions(+), 5 deletions(-)

diff --git a/arch/powerpc/include/asm/scatterlist.h 
b/arch/powerpc/include/asm/scatterlist.h
index fcf7d55..912bf59 100644
--- a/arch/powerpc/include/asm/scatterlist.h
+++ b/arch/powerpc/include/asm/scatterlist.h
@@ -21,7 +21,7 @@ struct scatterlist {
unsigned int offset;
unsigned int length;
 
-   /* For TCE support */
+   /* For TCE or SWIOTLB support */
dma_addr_t dma_address;
u32 dma_length;
 };
@@ -34,11 +34,7 @@ struct scatterlist {
  * is 0.
  */
 #define sg_dma_address(sg) ((sg)-dma_address)
-#ifdef __powerpc64__
 #define sg_dma_len(sg) ((sg)-dma_length)
-#else
-#define sg_dma_len(sg) ((sg)-length)
-#endif
 
 #ifdef __powerpc64__
 #define ISA_DMA_THRESHOLD  (~0UL)
-- 
1.6.0.6

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

[PATCH 0/5] SWIOTLB for ppc/mpc86xx

[Becky Bruce]

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 make dma_ops non-arch-specific, and
I expect to see something similar there as well.

I've also changed sg_dma_len to be the same on both 32 and 64-bit.
We now look at sg-dma_length in both cases (see patch log).

The dma_window* elements in the pci_controller struct are hoisted
out of an #ifdef CONFIG_PPC64 so we can use them to store off
information about how much memory is mapped via the inbound pci
windows.

A dma-swiotlb.c is created in arch/powerpc/kernel to contain
all the platform-specific iotlb code.

Finally, hooks are provided to allow enabling of this feature on 
86xx via Kconfig, and a 36-bit device tree for 8641hpcn is provided.

Ye Olde Diffstat:

 arch/powerpc/Kconfig   |2 +-
 arch/powerpc/boot/dts/mpc8641_hpcn_36b.dts |  597 
 arch/powerpc/include/asm/dma-mapping.h |   11 +
 arch/powerpc/include/asm/pci-bridge.h  |6 +-
 arch/powerpc/include/asm/scatterlist.h |6 +-
 arch/powerpc/include/asm/swiotlb.h |   24 ++
 arch/powerpc/kernel/Makefile   |1 +
 arch/powerpc/kernel/dma-swiotlb.c  |  161 
 arch/powerpc/kernel/dma.c  |2 +-
 arch/powerpc/kernel/setup_32.c |4 +
 arch/powerpc/sysdev/fsl_pci.c  |4 +
 11 files changed, 809 insertions(+), 9 deletions(-)

Cheers,
Becky

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

[PATCH 5/5] powerpc: Add 86xx support for SWIOTLB

[Becky Bruce]

Minor code to allow enabling swiotlb on mpc86xx, including
Kconfig addition for SWIOTLB.

Signed-off-by: Becky Bruce bec...@kernel.crashing.org
---
 arch/powerpc/Kconfig   |   10 ++
 arch/powerpc/kernel/dma-swiotlb.c  |2 ++
 arch/powerpc/platforms/86xx/mpc86xx_hpcn.c |3 +++
 3 files changed, 15 insertions(+), 0 deletions(-)

diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 197f6a3..e47c81d 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -292,6 +292,16 @@ config IOMMU_VMERGE
 config IOMMU_HELPER
def_bool PPC64
 
+config SWIOTLB
+   bool SWIOTLB support
+   depends on PPC_86xx
+   select IOMMU_HELPER
+   ---help---
+ Support for IO bounce buffering for systems without an IOMMU.
+ This allows us to DMA to the full physical address space on
+ platforms where the size of a physical address is larger
+ than the bus address.
+
 config PPC_NEED_DMA_SYNC_OPS
def_bool y
depends on (NOT_COHERENT_CACHE || SWIOTLB)
diff --git a/arch/powerpc/kernel/dma-swiotlb.c 
b/arch/powerpc/kernel/dma-swiotlb.c
index 29a68e6..3065d03 100644
--- a/arch/powerpc/kernel/dma-swiotlb.c
+++ b/arch/powerpc/kernel/dma-swiotlb.c
@@ -159,3 +159,5 @@ static int __init setup_bus_notifier(void)
 
return 0;
 }
+
+machine_arch_initcall(mpc86xx_hpcn, setup_bus_notifier);
diff --git a/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c 
b/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c
index c4ec49b..f7b88b9 100644
--- a/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c
+++ b/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c
@@ -88,6 +88,9 @@ mpc86xx_hpcn_setup_arch(void)
 
ppc_md.pci_exclude_device = mpc86xx_exclude_device;
 
+#ifdef CONFIG_SWIOTLB
+   set_pci_dma_ops(swiotlb_pci_dma_ops);
+#endif
 #endif
 
printk(MPC86xx HPCN board from Freescale Semiconductor\n);
-- 
1.6.0.6

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

[PATCH 2/5] powerpc: Add 36-bit device tree for mpc8641hpcn

[Becky Bruce]

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 bec...@kernel.crashing.org
---
 arch/powerpc/boot/dts/mpc8641_hpcn_36b.dts |  597 
 1 files changed, 597 insertions(+), 0 deletions(-)
 create mode 100644 arch/powerpc/boot/dts/mpc8641_hpcn_36b.dts

diff --git a/arch/powerpc/boot/dts/mpc8641_hpcn_36b.dts 
b/arch/powerpc/boot/dts/mpc8641_hpcn_36b.dts
new file mode 100644
index 000..baa3dba
--- /dev/null
+++ b/arch/powerpc/boot/dts/mpc8641_hpcn_36b.dts
@@ -0,0 +1,597 @@
+/*
+ * MPC8641 HPCN Device Tree Source
+ *
+ * Copyright 2006 Freescale Semiconductor Inc.
+ *
+ * This program is free software; you can redistribute  it and/or modify it
+ * under  the terms of  the GNU General  Public License as published by the
+ * Free Software Foundation;  either version 2 of the  License, or (at your
+ * option) any later version.
+ */
+
+/dts-v1/;
+
+/ {
+   model = MPC8641HPCN;
+   compatible = fsl,mpc8641hpcn;
+   #address-cells = 2;
+   #size-cells = 2;
+
+   aliases {
+   ethernet0 = enet0;
+   ethernet1 = enet1;
+   ethernet2 = enet2;
+   ethernet3 = enet3;
+   serial0 = serial0;
+   serial1 = serial1;
+   pci0 = pci0;
+   pci1 = pci1;
+   };
+
+   cpus {
+   #address-cells = 1;
+   #size-cells = 0;
+
+   PowerPC,8...@0 {
+   device_type = cpu;
+   reg = 0;
+   d-cache-line-size = 32;   // 32 bytes
+   i-cache-line-size = 32;   // 32 bytes
+   d-cache-size = 32768; // L1, 32K
+   i-cache-size = 32768; // L1, 32K
+   timebase-frequency = 0;   // 33 MHz, from uboot
+   bus-frequency = 0;// From uboot
+   clock-frequency = 0;  // From uboot
+   };
+   PowerPC,8...@1 {
+   device_type = cpu;
+   reg = 1;
+   d-cache-line-size = 32;   // 32 bytes
+   i-cache-line-size = 32;   // 32 bytes
+   d-cache-size = 32768; // L1, 32K
+   i-cache-size = 32768; // L1, 32K
+   timebase-frequency = 0;   // 33 MHz, from uboot
+   bus-frequency = 0;// From uboot
+   clock-frequency = 0;  // From uboot
+   };
+   };
+
+   memory {
+   device_type = memory;
+   reg = 0x0 0x 0x0 0x4000;  // 1G at 0x0
+   };
+
+   local...@fffe05000 {
+   #address-cells = 2;
+   #size-cells = 1;
+   compatible = fsl,mpc8641-localbus, simple-bus;
+   reg = 0x0f 0xffe05000 0x0 0x1000;
+   interrupts = 19 2;
+   interrupt-parent = mpic;
+
+   ranges = 0 0 0xf 0xef80 0x0080
+ 2 0 0xf 0xffdf8000 0x8000
+ 3 0 0xf 0xffdf 0x8000;
+
+   fl...@0,0 {
+   compatible = cfi-flash;
+   reg = 0 0 0x0080;
+   bank-width = 2;
+   device-width = 2;
+   #address-cells = 1;
+   #size-cells = 1;
+   partit...@0 {
+   label = kernel;
+   reg = 0x 0x0030;
+   };
+   partit...@30 {
+   label = firmware b;
+   reg = 0x0030 0x0010;
+   read-only;
+   };
+   partit...@40 {
+   label = fs;
+   reg = 0x0040 0x0030;
+   };
+   partit...@70 {
+   label = firmware a;
+   reg = 0x0070 0x0010;
+   read-only;
+   };
+   };
+   };
+
+   soc8...@fffe0 {
+   #address-cells = 1;
+   #size-cells = 1;
+   device_type = soc;
+   compatible = simple-bus;
+   ranges = 0x 0x0f 0xffe0 0x0010;
+   reg = 0x0f 0xffe0 0x0 0x1000; // CCSRBAR
+   bus-frequency = 0;
+
+   i...@3000 {
+   #address-cells = 1;
+   #size-cells = 0;
+   cell-index = 0;
+   compatible = fsl-i2c;
+ 

[PATCH 4/5] powerpc: Add support for swiotlb on 32-bit

[Becky Bruce]

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 bec...@kernel.crashing.org
---
 arch/powerpc/Kconfig   |2 +-
 arch/powerpc/include/asm/dma-mapping.h |   11 ++
 arch/powerpc/include/asm/swiotlb.h |   24 +
 arch/powerpc/kernel/Makefile   |1 +
 arch/powerpc/kernel/dma-swiotlb.c  |  161 
 arch/powerpc/kernel/dma.c  |2 +-
 arch/powerpc/kernel/setup_32.c |4 +
 7 files changed, 203 insertions(+), 2 deletions(-)
 create mode 100644 arch/powerpc/include/asm/swiotlb.h
 create mode 100644 arch/powerpc/kernel/dma-swiotlb.c

diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 5b50e1a..197f6a3 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -294,7 +294,7 @@ config IOMMU_HELPER
 
 config PPC_NEED_DMA_SYNC_OPS
def_bool y
-   depends on NOT_COHERENT_CACHE
+   depends on (NOT_COHERENT_CACHE || SWIOTLB)
 
 config HOTPLUG_CPU
bool Support for enabling/disabling CPUs
diff --git a/arch/powerpc/include/asm/dma-mapping.h 
b/arch/powerpc/include/asm/dma-mapping.h
index c69f2b5..71bbc17 100644
--- a/arch/powerpc/include/asm/dma-mapping.h
+++ b/arch/powerpc/include/asm/dma-mapping.h
@@ -15,9 +15,18 @@
 #include linux/scatterlist.h
 #include linux/dma-attrs.h
 #include asm/io.h
+#include asm/swiotlb.h
 
 #define DMA_ERROR_CODE (~(dma_addr_t)0x0)
 
+/* Some dma direct funcs must be visible for use in other dma_ops */
+extern void *dma_direct_alloc_coherent(struct device *dev, size_t size,
+  dma_addr_t *dma_handle, gfp_t flag);
+extern void dma_direct_free_coherent(struct device *dev, size_t size,
+void *vaddr, dma_addr_t dma_handle);
+
+extern unsigned long get_dma_direct_offset(struct device *dev);
+
 #ifdef CONFIG_NOT_COHERENT_CACHE
 /*
  * DMA-consistent mapping functions for PowerPCs that don't support
@@ -76,6 +85,8 @@ struct dma_mapping_ops {
dma_addr_t dma_address, size_t size,
enum dma_data_direction direction,
struct dma_attrs *attrs);
+   int (*addr_needs_map)(struct device *dev, dma_addr_t addr,
+   size_t size);
 #ifdef CONFIG_PPC_NEED_DMA_SYNC_OPS
void(*sync_single_range_for_cpu)(struct device *hwdev,
dma_addr_t dma_handle, unsigned long offset,
diff --git a/arch/powerpc/include/asm/swiotlb.h 
b/arch/powerpc/include/asm/swiotlb.h
new file mode 100644
index 000..6440fdf
--- /dev/null
+++ b/arch/powerpc/include/asm/swiotlb.h
@@ -0,0 +1,24 @@
+/*
+ * Copyright (C) 2009 Becky Bruce, Freescale Semiconductor
+ *
+ * This program is free software; you can redistribute  it and/or modify it
+ * under  the terms of  the GNU General  Public License as published by the
+ * Free Software Foundation;  either version 2 of the  License, or (at your
+ * option) any later version.
+ *
+ */
+
+#ifndef __ASM_SWIOTLB_H
+#define __ASM_SWIOTLB_H
+
+#include linux/swiotlb.h
+
+extern struct dma_mapping_ops swiotlb_dma_ops;
+extern struct dma_mapping_ops swiotlb_pci_dma_ops;
+
+int swiotlb_arch_address_needs_mapping(struct device *, dma_addr_t,
+  size_t size);
+
+static inline void dma_mark_clean(void *addr, size_t size) {}
+
+#endif /* __ASM_SWIOTLB_H */
diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
index 71901fb..34c0a95 100644
--- a/arch/powerpc/kernel/Makefile
+++ b/arch/powerpc/kernel/Makefile
@@ -82,6 +82,7 @@ obj-$(CONFIG_SMP) += smp.o
 obj-$(CONFIG_KPROBES)  += kprobes.o
 obj-$(CONFIG_PPC_UDBG_16550)   += legacy_serial.o udbg_16550.o
 obj-$(CONFIG_STACKTRACE)   += stacktrace.o
+obj-$(CONFIG_SWIOTLB)  += dma-swiotlb.o
 
 pci64-$(CONFIG_PPC64)  += pci_dn.o isa-bridge.o
 obj-$(CONFIG_PCI)  += pci_$(CONFIG_WORD_SIZE).o $(pci64-y) \
diff --git a/arch/powerpc/kernel/dma-swiotlb.c 
b/arch/powerpc/kernel/dma-swiotlb.c
new file mode 100644
index 000..29a68e6
--- /dev/null
+++ b/arch/powerpc/kernel/dma-swiotlb.c
@@ -0,0 +1,161 @@
+/*
+ * Contains routines needed to support swiotlb for ppc.
+ *
+ * Copyright (C) 2009 Becky Bruce, Freescale Semiconductor
+ *
+ * This program is free software; you can redistribute  it and/or modify it
+ * under  the terms of  the GNU General  Public License as published by the
+ * Free Software Foundation;  either version 2 of the  License, or (at your
+ * option) any later version.
+ *
+ */
+
+#include linux/dma-mapping.h
+#include linux/pfn.h
+#include linux/of_platform.h
+#include linux/platform_device.h
+#include linux/pci.h
+
+#include asm/machdep.h
+#include asm/swiotlb.h
+#include asm/dma.h
+#include asm/abs_addr.h
+
+int swiotlb __read_mostly;
+
+void 

Re: [PATCH 0/5] Allow swiotlb use on ppc/mpc86xx

[Becky Bruce]

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 buffering.  I believe that patches
will be coming out soon to make dma_ops non-arch-specific, and
I expect to see something similar there as well.

I've also changed sg_dma_len to be the same on both 32 and 64-bit.
We now look at sg-dma_length in both cases (see patch log).

The dma_window* elements in the pci_controller struct are hoisted
out of an #ifdef CONFIG_PPC64 so we can use them to store off
information about how much memory is mapped via the inbound pci
windows.

A dma-swiotlb.c is created in arch/powerpc/kernel to contain
all the platform-specific iotlb code.

Finally, hooks are provided to allow enabling of this feature on
86xx via Kconfig, and a 36-bit device tree for 8641hpcn is provided.

Ye Olde Diffstat:
 arch/powerpc/Kconfig   |2 +-
 arch/powerpc/boot/dts/mpc8641_hpcn_36b.dts |  597 +++ 
+

 arch/powerpc/include/asm/dma-mapping.h |   11 +
 arch/powerpc/include/asm/pci-bridge.h  |6 +-
 arch/powerpc/include/asm/scatterlist.h |6 +-
 arch/powerpc/include/asm/swiotlb.h |   24 ++
 arch/powerpc/kernel/Makefile   |1 +
 arch/powerpc/kernel/dma-swiotlb.c  |  161 
 arch/powerpc/kernel/dma.c  |2 +-
 arch/powerpc/kernel/setup_32.c |4 +
 arch/powerpc/sysdev/fsl_pci.c  |4 +
 11 files changed, 809 insertions(+), 9 deletions(-)

Cheers,
Becky
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH 4/5] powerpc: Add support for swiotlb on 32-bit

[Kumar Gala]

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 bec...@kernel.crashing.org
---
arch/powerpc/Kconfig   |2 +-
arch/powerpc/include/asm/dma-mapping.h |   11 ++
arch/powerpc/include/asm/swiotlb.h |   24 +
arch/powerpc/kernel/Makefile   |1 +
arch/powerpc/kernel/dma-swiotlb.c  |  161 +++ 
+

arch/powerpc/kernel/dma.c  |2 +-
arch/powerpc/kernel/setup_32.c |4 +
7 files changed, 203 insertions(+), 2 deletions(-)
create mode 100644 arch/powerpc/include/asm/swiotlb.h
create mode 100644 arch/powerpc/kernel/dma-swiotlb.c

diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 5b50e1a..197f6a3 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -294,7 +294,7 @@ config IOMMU_HELPER

config PPC_NEED_DMA_SYNC_OPS
def_bool y
-   depends on NOT_COHERENT_CACHE
+   depends on (NOT_COHERENT_CACHE || SWIOTLB)


This isn't right, since you haven't introduced the SWIOTLB Kconfig.

Why don't we just put the SWIOTLB Kconfig option in here and default  
it no (and remove the dep on 86xx).



config HOTPLUG_CPU
bool Support for enabling/disabling CPUs



diff --git a/arch/powerpc/kernel/dma-swiotlb.c b/arch/powerpc/kernel/ 
dma-swiotlb.c

new file mode 100644
index 000..29a68e6
--- /dev/null
+++ b/arch/powerpc/kernel/dma-swiotlb.c
@@ -0,0 +1,161 @@
+/*
+ * Contains routines needed to support swiotlb for ppc.
+ *
+ * Copyright (C) 2009 Becky Bruce, Freescale Semiconductor
+ *
+ * This program is free software; you can redistribute  it and/or  
modify it
+ * under  the terms of  the GNU General  Public License as  
published by the
+ * Free Software Foundation;  either version 2 of the  License, or  
(at your

+ * option) any later version.
+ *
+ */


[snip]



+
+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 != BUS_NOTIFY_ADD_DEVICE)
+   return 0;
+
+   if (dma_get_mask(dev)  DMA_BIT_MASK(36))
+   set_dma_ops(dev, swiotlb_dma_ops);
+


this isn't right.  Isn't possible for a PCI dev to have a  
DMA_BIT_MASK(64) but us still not be able to dma to it?  Also, I dont  
like the assumption of 36-bit physical here.




+   return NOTIFY_DONE;
+}
+
+static struct notifier_block ppc_swiotlb_plat_bus_notifier = {
+   .notifier_call = ppc_swiotlb_bus_notify,
+   .priority = 0,
+};
+
+static struct notifier_block ppc_swiotlb_of_bus_notifier = {
+   .notifier_call = ppc_swiotlb_bus_notify,
+   .priority = 0,
+};
+
+static int __init setup_bus_notifier(void)
+{
+   bus_register_notifier(platform_bus_type,
+ ppc_swiotlb_plat_bus_notifier);
+   bus_register_notifier(of_platform_bus_type,
+ ppc_swiotlb_of_bus_notifier);
+
+   return 0;
+}

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH 3/5] powerpc: make dma_window_* in pci_controller struct avail on 32b

[Kumar Gala]

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 to determine if an address requires bounce buffering.  For
now, initialize them to a standard value; in the near future, the
value will be calculated based on how the inbound windows are
programmed.

Signed-off-by: Becky Bruce bec...@kernel.crashing.org
---
arch/powerpc/include/asm/pci-bridge.h |6 --
arch/powerpc/sysdev/fsl_pci.c |4 
2 files changed, 8 insertions(+), 2 deletions(-)


Ben, your ack on this patch would be appreciated as I've got some  
other FSL PCI patches that I want to fold this into my tree for.


- k
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH 5/5] powerpc: Add 86xx support for SWIOTLB

[Kumar Gala]

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 bec...@kernel.crashing.org
---
arch/powerpc/Kconfig   |   10 ++
arch/powerpc/kernel/dma-swiotlb.c  |2 ++
arch/powerpc/platforms/86xx/mpc86xx_hpcn.c |3 +++
3 files changed, 15 insertions(+), 0 deletions(-)

diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 197f6a3..e47c81d 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -292,6 +292,16 @@ config IOMMU_VMERGE
config IOMMU_HELPER
def_bool PPC64

+config SWIOTLB
+   bool SWIOTLB support
+   depends on PPC_86xx
+   select IOMMU_HELPER
+   ---help---
+ Support for IO bounce buffering for systems without an IOMMU.
+ This allows us to DMA to the full physical address space on
+ platforms where the size of a physical address is larger
+ than the bus address.
+


As stated on previous patch, move the bulk of this into 4/5.



config PPC_NEED_DMA_SYNC_OPS
def_bool y
depends on (NOT_COHERENT_CACHE || SWIOTLB)
diff --git a/arch/powerpc/kernel/dma-swiotlb.c b/arch/powerpc/kernel/ 
dma-swiotlb.c

index 29a68e6..3065d03 100644
--- a/arch/powerpc/kernel/dma-swiotlb.c
+++ b/arch/powerpc/kernel/dma-swiotlb.c
@@ -159,3 +159,5 @@ static int __init setup_bus_notifier(void)

return 0;
}
+
+machine_arch_initcall(mpc86xx_hpcn, setup_bus_notifier);


Hmm, not sure what we chatted about here, but I don't want to have to  
add every board into this file to register the bus notifiers.




diff --git a/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c b/arch/ 
powerpc/platforms/86xx/mpc86xx_hpcn.c

index c4ec49b..f7b88b9 100644
--- a/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c
+++ b/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c
@@ -88,6 +88,9 @@ mpc86xx_hpcn_setup_arch(void)

ppc_md.pci_exclude_device = mpc86xx_exclude_device;

+#ifdef CONFIG_SWIOTLB
+   set_pci_dma_ops(swiotlb_pci_dma_ops);
+#endif
#endif

printk(MPC86xx HPCN board from Freescale Semiconductor\n);
--
1.6.0.6

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: MPC8349E's DMA controller like ISA controller but with more feature?

[Timur Tabi]

On Mon, Apr 20, 2009 at 10:55 AM, Scott Wood scottw...@freescale.com 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 DMA is frequently used.

-- 
Timur Tabi
Linux kernel developer at Freescale
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH 5/5] powerpc: Add 86xx support for SWIOTLB

[Becky Bruce]

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 bec...@kernel.crashing.org
---
arch/powerpc/Kconfig   |   10 ++
arch/powerpc/kernel/dma-swiotlb.c  |2 ++
arch/powerpc/platforms/86xx/mpc86xx_hpcn.c |3 +++
3 files changed, 15 insertions(+), 0 deletions(-)

diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 197f6a3..e47c81d 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -292,6 +292,16 @@ config IOMMU_VMERGE
config IOMMU_HELPER
def_bool PPC64

+config SWIOTLB
+   bool SWIOTLB support
+   depends on PPC_86xx
+   select IOMMU_HELPER
+   ---help---
+ Support for IO bounce buffering for systems without an IOMMU.
+ This allows us to DMA to the full physical address space on
+ platforms where the size of a physical address is larger
+ than the bus address.
+


As stated on previous patch, move the bulk of this into 4/5.


Yep.






config PPC_NEED_DMA_SYNC_OPS
def_bool y
depends on (NOT_COHERENT_CACHE || SWIOTLB)
diff --git a/arch/powerpc/kernel/dma-swiotlb.c b/arch/powerpc/ 
kernel/dma-swiotlb.c

index 29a68e6..3065d03 100644
--- a/arch/powerpc/kernel/dma-swiotlb.c
+++ b/arch/powerpc/kernel/dma-swiotlb.c
@@ -159,3 +159,5 @@ static int __init setup_bus_notifier(void)

return 0;
}
+
+machine_arch_initcall(mpc86xx_hpcn, setup_bus_notifier);


Hmm, not sure what we chatted about here, but I don't want to have  
to add every board into this file to register the bus notifiers.


We talked about this, and this was what we decided on - I don't really  
like the idea, either, but there's a lot of precedent for it.  I'd  
like to do this differently, but Im not sure what the solution is -  
we'd need to look into that more (or perhaps someone here will have  
some sage advice).


Cheers,
B
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH 4/5] powerpc: Add support for swiotlb on 32-bit

[Becky Bruce]

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 bec...@kernel.crashing.org
---
arch/powerpc/Kconfig   |2 +-
arch/powerpc/include/asm/dma-mapping.h |   11 ++
arch/powerpc/include/asm/swiotlb.h |   24 +
arch/powerpc/kernel/Makefile   |1 +
arch/powerpc/kernel/dma-swiotlb.c  |  161 ++ 
++

arch/powerpc/kernel/dma.c  |2 +-
arch/powerpc/kernel/setup_32.c |4 +
7 files changed, 203 insertions(+), 2 deletions(-)
create mode 100644 arch/powerpc/include/asm/swiotlb.h
create mode 100644 arch/powerpc/kernel/dma-swiotlb.c

diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 5b50e1a..197f6a3 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -294,7 +294,7 @@ config IOMMU_HELPER

config PPC_NEED_DMA_SYNC_OPS
def_bool y
-   depends on NOT_COHERENT_CACHE
+   depends on (NOT_COHERENT_CACHE || SWIOTLB)


This isn't right, since you haven't introduced the SWIOTLB Kconfig.


Why don't we just put the SWIOTLB Kconfig option in here and default  
it no (and remove the dep on 86xx).


Sure.  I'll probably add a comment or something though so people don't  
think they can just enable it on anything and expect it to work.  Too  
many people seem to read the config files and decide things are  
possible that actually aren't :)






config HOTPLUG_CPU
bool Support for enabling/disabling CPUs



diff --git a/arch/powerpc/kernel/dma-swiotlb.c b/arch/powerpc/ 
kernel/dma-swiotlb.c

new file mode 100644
index 000..29a68e6
--- /dev/null
+++ b/arch/powerpc/kernel/dma-swiotlb.c
@@ -0,0 +1,161 @@
+/*
+ * Contains routines needed to support swiotlb for ppc.
+ *
+ * Copyright (C) 2009 Becky Bruce, Freescale Semiconductor
+ *
+ * This program is free software; you can redistribute  it and/or  
modify it
+ * under  the terms of  the GNU General  Public License as  
published by the
+ * Free Software Foundation;  either version 2 of the  License, or  
(at your

+ * option) any later version.
+ *
+ */


[snip]



+
+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 != BUS_NOTIFY_ADD_DEVICE)
+   return 0;
+
+   if (dma_get_mask(dev)  DMA_BIT_MASK(36))
+   set_dma_ops(dev, swiotlb_dma_ops);
+


this isn't right.  Isn't possible for a PCI dev to have a  
DMA_BIT_MASK(64) but us still not be able to dma to it?  Also, I  
dont like the assumption of 36-bit physical here.


You're right - this is just handling the basic case and for now I'm  
assuming that we don't bounce 64-bit devices (or any device that can  
handle 36 bits).   We'll need to talk in more detail about a solution  
to that problem, because knowing if a 64b dev *might* need to bounce  
(which is all this is really saying) requires more information.   We  
also don't really have infrastructure to deal with holes in the  
visible dev memory, and I don't know if we want to handle that as  
well. I don't want to set the dma_ops to swiotlb unless we have to  
because there's a slight perf hit in running all the checks to see if  
an address needs to be bounced.


Thanks,
B

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH 4/5] powerpc: Add support for swiotlb on 32-bit

[Kumar Gala]

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 != BUS_NOTIFY_ADD_DEVICE)
+   return 0;
+
+   if (dma_get_mask(dev)  DMA_BIT_MASK(36))
+   set_dma_ops(dev, swiotlb_dma_ops);
+
+   return NOTIFY_DONE;
+}
+
+static struct notifier_block ppc_swiotlb_plat_bus_notifier = {
+   .notifier_call = ppc_swiotlb_bus_notify,
+   .priority = 0,
+};
+
+static struct notifier_block ppc_swiotlb_of_bus_notifier = {
+   .notifier_call = ppc_swiotlb_bus_notify,
+   .priority = 0,
+};
+
+static int __init setup_bus_notifier(void)
+{
+   bus_register_notifier(platform_bus_type,
+ ppc_swiotlb_plat_bus_notifier);
+   bus_register_notifier(of_platform_bus_type,
+ ppc_swiotlb_of_bus_notifier);
+
+   return 0;
+}


I think we should move all this into the platform code for now.  I  
don't like having to duplicate it but that gives us the proper  
flexibility for now.


- k
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH 4/5] powerpc: Add support for swiotlb on 32-bit

[Becky Bruce]

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 intereted in device addition */
+   if (action != BUS_NOTIFY_ADD_DEVICE)
+   return 0;
+
+   if (dma_get_mask(dev)  DMA_BIT_MASK(36))
+   set_dma_ops(dev, swiotlb_dma_ops);
+
+   return NOTIFY_DONE;
+}
+
+static struct notifier_block ppc_swiotlb_plat_bus_notifier = {
+   .notifier_call = ppc_swiotlb_bus_notify,
+   .priority = 0,
+};
+
+static struct notifier_block ppc_swiotlb_of_bus_notifier = {
+   .notifier_call = ppc_swiotlb_bus_notify,
+   .priority = 0,
+};
+
+static int __init setup_bus_notifier(void)
+{
+   bus_register_notifier(platform_bus_type,
+ ppc_swiotlb_plat_bus_notifier);
+   bus_register_notifier(of_platform_bus_type,
+ ppc_swiotlb_of_bus_notifier);
+
+   return 0;
+}


I think we should move all this into the platform code for now.  I  
don't like having to duplicate it but that gives us the proper  
flexibility for now.


Ugh, gross.  I'd like to think about this some more.

-B

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH 4/5] powerpc: Add support for swiotlb on 32-bit

[Kumar Gala]

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)
+{
+   struct device *dev = data;
+
+   /* We are only intereted in device addition */
+   if (action != BUS_NOTIFY_ADD_DEVICE)
+   return 0;
+
+   if (dma_get_mask(dev)  DMA_BIT_MASK(36))
+   set_dma_ops(dev, swiotlb_dma_ops);
+
+   return NOTIFY_DONE;
+}
+
+static struct notifier_block ppc_swiotlb_plat_bus_notifier = {
+   .notifier_call = ppc_swiotlb_bus_notify,
+   .priority = 0,
+};
+
+static struct notifier_block ppc_swiotlb_of_bus_notifier = {
+   .notifier_call = ppc_swiotlb_bus_notify,
+   .priority = 0,
+};
+
+static int __init setup_bus_notifier(void)
+{
+   bus_register_notifier(platform_bus_type,
+ ppc_swiotlb_plat_bus_notifier);
+   bus_register_notifier(of_platform_bus_type,
+ ppc_swiotlb_of_bus_notifier);
+
+   return 0;
+}


I think we should move all this into the platform code for now.  I  
don't like having to duplicate it but that gives us the proper  
flexibility for now.


Ugh, gross.  I'd like to think about this some more.


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.


- k
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH 1/5] powerpc: Use sg-dma_length in sg_dma_len() macro on 32-bit

[Kumar Gala]

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 there as well.  This gets rid of
some 32-vs-64-bit ifdefs, and is needed by the swiotlb code which
actually distinguishes between dma_length and length.

Signed-off-by: Becky Bruce bec...@kernel.crashing.org
---
arch/powerpc/include/asm/scatterlist.h |6 +-
1 files changed, 1 insertions(+), 5 deletions(-)

diff --git a/arch/powerpc/include/asm/scatterlist.h b/arch/powerpc/ 
include/asm/scatterlist.h

index fcf7d55..912bf59 100644
--- a/arch/powerpc/include/asm/scatterlist.h
+++ b/arch/powerpc/include/asm/scatterlist.h
@@ -21,7 +21,7 @@ struct scatterlist {
unsigned int offset;
unsigned int length;


can we get rid of length?




-   /* For TCE support */
+   /* For TCE or SWIOTLB support */
dma_addr_t dma_address;
u32 dma_length;
};
@@ -34,11 +34,7 @@ struct scatterlist {
 * is 0.
 */
#define sg_dma_address(sg)  ((sg)-dma_address)
-#ifdef __powerpc64__
#define sg_dma_len(sg)  ((sg)-dma_length)
-#else
-#define sg_dma_len(sg) ((sg)-length)
-#endif

#ifdef __powerpc64__
#define ISA_DMA_THRESHOLD   (~0UL)
--
1.6.0.6


- k
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH 4/5] powerpc: Add support for swiotlb on 32-bit

[Scott Wood]

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 shove into a DMA 
address register, and it would let us avoid hardcoding 36 bits into this 
code.


What other platform-specific behavior do you have in mind?  Could we 
supply a default implementation that platforms can override if they need 
something weird, rather than duplicating it per soc family?


-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

[PATCH] AOA: Convert onyx and tas codecs to new-style i2c drivers

[Jean Delvare]

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 kh...@linux-fr.org
Tested-by: Johannes Berg johan...@sipsolutions.net
Tested-by: Andreas Schwab sch...@linux-m68k.org
Cc: Benjamin Herrenschmidt b...@kernel.crashing.org
Cc: Takashi Iwai ti...@suse.de
---
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.

 sound/aoa/codecs/onyx.c |   76 ---
 sound/aoa/codecs/tas.c  |   66 +---
 2 files changed, 95 insertions(+), 47 deletions(-)

--- linux-2.6.30-rc2.orig/sound/aoa/codecs/onyx.c   2009-04-15 
09:55:20.0 +0200
+++ linux-2.6.30-rc2/sound/aoa/codecs/onyx.c2009-04-15 14:07:50.0 
+0200
@@ -47,7 +47,7 @@ MODULE_DESCRIPTION(pcm3052 (onyx) codec
 struct onyx {
/* cache registers 65 to 80, they are write-only! */
u8  cache[16];
-   struct i2c_client   i2c;
+   struct i2c_client   *i2c;
struct aoa_codeccodec;
u32 initialised:1,
spdif_locked:1,
@@ -72,7 +72,7 @@ static int onyx_read_register(struct ony
*value = onyx-cache[reg-FIRSTREGISTER];
return 0;
}
-   v = i2c_smbus_read_byte_data(onyx-i2c, reg);
+   v = i2c_smbus_read_byte_data(onyx-i2c, reg);
if (v  0)
return -1;
*value = (u8)v;
@@ -84,7 +84,7 @@ static int onyx_write_register(struct on
 {
int result;
 
-   result = i2c_smbus_write_byte_data(onyx-i2c, reg, value);
+   result = i2c_smbus_write_byte_data(onyx-i2c, reg, value);
if (!result)
onyx-cache[reg-FIRSTREGISTER] = value;
return result;
@@ -996,12 +996,45 @@ static void onyx_exit_codec(struct aoa_c
onyx-codec.soundbus_dev-detach_codec(onyx-codec.soundbus_dev, onyx);
 }
 
-static struct i2c_driver onyx_driver;
-
 static int onyx_create(struct i2c_adapter *adapter,
   struct device_node *node,
   int addr)
 {
+   struct i2c_board_info info;
+   struct i2c_client *client;
+
+   memset(info, 0, sizeof(struct i2c_board_info));
+   strlcpy(info.type, aoa_codec_onyx, I2C_NAME_SIZE);
+   info.addr = addr;
+   info.platform_data = node;
+   client = i2c_new_device(adapter, info);
+   if (!client)
+   return -ENODEV;
+
+   /*
+* We know the driver is already loaded, so the device should be
+* already bound. If not it means binding failed, which suggests
+* the device doesn't really exist and should be deleted.
+* Ideally this would be replaced by better checks _before_
+* instantiating the device.
+*/
+   if (!client-driver) {
+   i2c_unregister_device(client);
+   return -ENODEV;
+   }
+
+   /*
+* Let i2c-core delete that device on driver removal.
+* This is safe because i2c-core holds the core_lock mutex for us.
+*/
+   list_add_tail(client-detected, client-driver-clients);
+   return 0;
+}
+
+static int onyx_i2c_probe(struct i2c_client *client,
+ const struct i2c_device_id *id)
+{
+   struct device_node *node = client-dev.platform_data;
struct onyx *onyx;
u8 dummy;
 
@@ -1011,20 +1044,12 @@ static int onyx_create(struct i2c_adapte
return -ENOMEM;
 
mutex_init(onyx-mutex);
-   onyx-i2c.driver = onyx_driver;
-   onyx-i2c.adapter = adapter;
-   onyx-i2c.addr = addr  0x7f;
-   strlcpy(onyx-i2c.name, onyx audio codec, I2C_NAME_SIZE);
-
-   if (i2c_attach_client(onyx-i2c)) {
-   printk(KERN_ERR PFX failed to attach to i2c\n);
-   goto fail;
-   }
+   onyx-i2c = client;
+   i2c_set_clientdata(client, onyx);
 
/* we try to read from register ONYX_REG_CONTROL
 * to check if the codec is present */
if (onyx_read_register(onyx, ONYX_REG_CONTROL, dummy) != 0) {
-   i2c_detach_client(onyx-i2c);
printk(KERN_ERR PFX failed to read control register\n);
goto fail;
}
@@ -1036,14 +1061,14 @@ static int onyx_create(struct i2c_adapte
onyx-codec.node = of_node_get(node);
 
if (aoa_codec_register(onyx-codec)) {
-   i2c_detach_client(onyx-i2c);
goto fail;
}
printk(KERN_DEBUG PFX created and attached onyx instance\n);
return 0;
  fail:
+   i2c_set_clientdata(client, NULL);
kfree(onyx);
-   return -EINVAL;
+   return -ENODEV;
 }
 
 static int onyx_i2c_attach(struct i2c_adapter *adapter)
@@ -1080,28 +1105,33 @@ static int onyx_i2c_attach(struct i2c_ad
return onyx_create(adapter, NULL, 0x47);
 }
 

[PATCH] keywest: Convert to new-style i2c driver

[Jean Delvare]

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 kh...@linux-fr.org
Cc: Benjamin Herrenschmidt b...@kernel.crashing.org
Cc: Takashi Iwai ti...@suse.de
---
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 did not get any test report for this one, but it's relatively simple
so I am confident I got it right.

 sound/ppc/keywest.c |   82 +--
 1 file changed, 41 insertions(+), 41 deletions(-)

--- linux-2.6.30-rc2.orig/sound/ppc/keywest.c   2009-04-20 22:40:27.0 
+0200
+++ linux-2.6.30-rc2/sound/ppc/keywest.c2009-04-20 22:47:34.0 
+0200
@@ -33,26 +33,25 @@
 static struct pmac_keywest *keywest_ctx;
 
 
-static int keywest_attach_adapter(struct i2c_adapter *adapter);
-static int keywest_detach_client(struct i2c_client *client);
-
-struct i2c_driver keywest_driver = {  
-   .driver = {
-   .name = PMac Keywest Audio,
-   },
-   .attach_adapter = keywest_attach_adapter,
-   .detach_client = keywest_detach_client,
-};
-
-
 #ifndef i2c_device_name
 #define i2c_device_name(x) ((x)-name)
 #endif
 
+static int keywest_probe(struct i2c_client *client,
+const struct i2c_device_id *id)
+{
+   i2c_set_clientdata(client, keywest_ctx);
+   return 0;
+}
+
+/*
+ * This is kind of a hack, best would be to turn powermac to fixed i2c
+ * bus numbers and declare the sound device as part of platform
+ * initialization
+ */
 static int keywest_attach_adapter(struct i2c_adapter *adapter)
 {
-   int err;
-   struct i2c_client *new_client;
+   struct i2c_board_info info;
 
if (! keywest_ctx)
return -EINVAL;
@@ -60,46 +59,47 @@ static int keywest_attach_adapter(struct
if (strncmp(i2c_device_name(adapter), mac-io, 6))
return 0; /* ignored */
 
-   new_client = kzalloc(sizeof(struct i2c_client), GFP_KERNEL);
-   if (! new_client)
-   return -ENOMEM;
-
-   new_client-addr = keywest_ctx-addr;
-   i2c_set_clientdata(new_client, keywest_ctx);
-   new_client-adapter = adapter;
-   new_client-driver = keywest_driver;
-   new_client-flags = 0;
-
-   strcpy(i2c_device_name(new_client), keywest_ctx-name);
-   keywest_ctx-client = new_client;
+   memset(info, 0, sizeof(struct i2c_board_info));
+   strlcpy(info.type, keywest, I2C_NAME_SIZE);
+   info.addr = keywest_ctx-addr;
+   keywest_ctx-client = i2c_new_device(adapter, info);

-   /* Tell the i2c layer a new client has arrived */
-   if (i2c_attach_client(new_client)) {
-   snd_printk(KERN_ERR tumbler: cannot attach i2c client\n);
-   err = -ENODEV;
-   goto __err;
-   }
-
+   /*
+* Let i2c-core delete that device on driver removal.
+* This is safe because i2c-core holds the core_lock mutex for us.
+*/
+   list_add_tail(keywest_ctx-client-detected,
+ keywest_ctx-client-driver-clients);
return 0;
-
- __err:
-   kfree(new_client);
-   keywest_ctx-client = NULL;
-   return err;
 }
 
-static int keywest_detach_client(struct i2c_client *client)
+static int keywest_remove(struct i2c_client *client)
 {
+   i2c_set_clientdata(client, NULL);
if (! keywest_ctx)
return 0;
if (client == keywest_ctx-client)
keywest_ctx-client = NULL;
 
-   i2c_detach_client(client);
-   kfree(client);
return 0;
 }
 
+
+static const struct i2c_device_id keywest_i2c_id[] = {
+   { keywest, 0 },
+   { }
+};
+
+struct i2c_driver keywest_driver = {
+   .driver = {
+   .name = PMac Keywest Audio,
+   },
+   .attach_adapter = keywest_attach_adapter,
+   .probe = keywest_probe,
+   .remove = keywest_remove,
+   .id_table = keywest_i2c_id,
+};
+
 /* exported */
 void snd_pmac_keywest_cleanup(struct pmac_keywest *i2c)
 {


-- 
Jean Delvare
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH] AOA: Convert onyx and tas codecs to new-style i2c drivers

[Johannes Berg]

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 kh...@linux-fr.org
 Tested-by: Johannes Berg johan...@sipsolutions.net
 Tested-by: Andreas Schwab sch...@linux-m68k.org
 Cc: Benjamin Herrenschmidt b...@kernel.crashing.org
 Cc: Takashi Iwai ti...@suse.de
 ---
 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.

Have you taken care of snd-powermac similarly?

johannes


signature.asc
Description: This is a digitally signed message part
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: Proposed prom parse fix + moving.

[Grant Likely]

On Fri, Apr 17, 2009 at 11:35 PM, Grant Likely
grant.lik...@secretlab.ca 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(), which turned
 out to be a copy from arch/powerpc. Grant Likely
 grant.lik...@secretlab.ca confirmed that this is a real bug.

 Merge error handling paths using goto with the normal return
 path.

 Powerppc compile tested.

 Signed-off-by: Ilpo Järvinen ilpo.jarvi...@helsinki.fi

 Looks right to me (but I haven't tested).

 Acked-by: Grant Likely grant.lik...@secretlab.ca

I've picked up the powerpc half of this patch, tested it, and pushed
it out to my -next tree and asked Ben or Paul to pull.

Michal, I leave it to you to pick up the Microblaze half.

Cheers,
g.



 ---
  arch/microblaze/kernel/prom_parse.c |   11 +--
  arch/powerpc/kernel/prom_parse.c    |   11 +--
  2 files changed, 10 insertions(+), 12 deletions(-)

 diff --git a/arch/microblaze/kernel/prom_parse.c 
 b/arch/microblaze/kernel/prom_parse.c
 index ae0352e..d16c32f 100644
 --- a/arch/microblaze/kernel/prom_parse.c
 +++ b/arch/microblaze/kernel/prom_parse.c
 @@ -903,7 +903,7 @@ int of_irq_map_one(struct device_node *device,
        struct device_node *p;
        const u32 *intspec, *tmp, *addr;
        u32 intsize, intlen;
 -       int res;
 +       int res = -EINVAL;

        pr_debug(of_irq_map_one: dev=%s, index=%d\n,
                        device-full_name, index);
 @@ -926,21 +926,20 @@ int of_irq_map_one(struct device_node *device,

        /* Get size of interrupt specifier */
        tmp = of_get_property(p, #interrupt-cells, NULL);
 -       if (tmp == NULL) {
 -               of_node_put(p);
 -               return -EINVAL;
 -       }
 +       if (tmp == NULL)
 +               goto out;
        intsize = *tmp;

        pr_debug( intsize=%d intlen=%d\n, intsize, intlen);

        /* Check index */
        if ((index + 1) * intsize  intlen)
 -               return -EINVAL;
 +               goto out;

        /* Get new specifier and map it */
        res = of_irq_map_raw(p, intspec + index * intsize, intsize,
                                addr, out_irq);
 +out:
        of_node_put(p);
        return res;
  }
 diff --git a/arch/powerpc/kernel/prom_parse.c 
 b/arch/powerpc/kernel/prom_parse.c
 index 8f0856f..8362620 100644
 --- a/arch/powerpc/kernel/prom_parse.c
 +++ b/arch/powerpc/kernel/prom_parse.c
 @@ -971,7 +971,7 @@ int of_irq_map_one(struct device_node *device, int 
 index, struct of_irq *out_irq
        struct device_node *p;
        const u32 *intspec, *tmp, *addr;
        u32 intsize, intlen;
 -       int res;
 +       int res = -EINVAL;

        DBG(of_irq_map_one: dev=%s, index=%d\n, device-full_name, index);

 @@ -995,21 +995,20 @@ int of_irq_map_one(struct device_node *device, int 
 index, struct of_irq *out_irq

        /* Get size of interrupt specifier */
        tmp = of_get_property(p, #interrupt-cells, NULL);
 -       if (tmp == NULL) {
 -               of_node_put(p);
 -               return -EINVAL;
 -       }
 +       if (tmp == NULL)
 +               goto out;
        intsize = *tmp;

        DBG( intsize=%d intlen=%d\n, intsize, intlen);

        /* Check index */
        if ((index + 1) * intsize  intlen)
 -               return -EINVAL;
 +               goto out;

        /* Get new specifier and map it */
        res = of_irq_map_raw(p, intspec + index * intsize, intsize,
                             addr, out_irq);
 +out:
        of_node_put(p);
        return res;
  }
 --
 1.5.6.5




 --
 Grant Likely, B.Sc., P.Eng.
 Secret Lab Technologies Ltd.




-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: Please pull merge branch from git.secretlab.ca

[Grant Likely]

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.secretlab.ca/git/linux-2.6 merge

Anton Vorontsov (1):
  powerpc/5200: Bring the legacy fsl_spi_platform_data hooks back

Grant Likely (2):
  powerpc/5200: Add FLASH nodes to lite5200 device tree
  powerpc/5200: defconfig updates

Ilpo Järvinen (1):
  powerpc: Fix of_node_put() exit path in of_irq_map_one()

Stefan Roese (2):
  powerpc/of-device-tree: Factor MTD physmap bindings out of
booting-without-of
  powerpc/device-tree: Document MTD nodes with multiple reg tuples

 Documentation/powerpc/booting-without-of.txt   |   89 ++
 Documentation/powerpc/dts-bindings/mtd-physmap.txt |   80 +
 arch/powerpc/boot/dts/lite5200b.dts|   39 
 arch/powerpc/configs/52xx/cm5200_defconfig |   69 +--
 arch/powerpc/configs/52xx/lite5200b_defconfig  |   74 ++--
 arch/powerpc/configs/52xx/motionpro_defconfig  |   77 ++--
 arch/powerpc/configs/52xx/pcm030_defconfig |   69 +--
 arch/powerpc/configs/52xx/tqm5200_defconfig|   76 ++--
 arch/powerpc/configs/mpc5200_defconfig |  188 
 arch/powerpc/kernel/prom_parse.c   |   11 +-
 include/linux/fsl_devices.h|4 +
 11 files changed, 568 insertions(+), 208 deletions(-)
 create mode 100644 Documentation/powerpc/dts-bindings/mtd-physmap.txt


On Thu, Apr 16, 2009 at 11:58 PM, Grant Likely
grant.lik...@secretlab.ca wrote:
 Hi Ben/Paul,

 Here are some fixups and documentation updates for 2.6.30

 The following changes since commit 0882e8dd3aad33eca41696d463bb896e6c8817eb:
  Linus Torvalds (1):
        Linux 2.6.30-rc2

 are available in the git repository at:

  git://git.secretlab.ca/git/linux-2.6 merge

 Anton Vorontsov (1):
      powerpc/5200: Bring the legacy fsl_spi_platform_data hooks back

 Grant Likely (1):
      powerpc/5200: Add FLASH nodes to lite5200 device tree

 Stefan Roese (2):
      powerpc/of-device-tree: Factor MTD physmap bindings out of
 booting-without-of
      powerpc/device-tree: Document MTD nodes with multiple reg tuples

  Documentation/powerpc/booting-without-of.txt       |   89 
 +++-
  Documentation/powerpc/dts-bindings/mtd-physmap.txt |   80 ++
  arch/powerpc/boot/dts/lite5200b.dts                |   39 +
  include/linux/fsl_devices.h                        |    4 +
  4 files changed, 135 insertions(+), 77 deletions(-)
  create mode 100644 Documentation/powerpc/dts-bindings/mtd-physmap.txt


 --
 Grant Likely, B.Sc., P.Eng.
 Secret Lab Technologies Ltd.




-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH] keywest: Convert to new-style i2c driver

[Paul Mackerras]

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 should have
been removed in the merge window.  Removing it now has too much risk
of introducing regressions in my opinion.

I presume you have a development tree where you queue up commits for
the i2c subsystem for the next merge window.  I suggest you do the
removal there now (or whenever you like) and push it to Linus in the
next merge window.

Paul.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH 2/5] powerpc: Add 36-bit device tree for mpc8641hpcn

[David Gibson]

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 bec...@kernel.crashing.org
 ---
  arch/powerpc/boot/dts/mpc8641_hpcn_36b.dts |  597 
 
  1 files changed, 597 insertions(+), 0 deletions(-)
  create mode 100644 arch/powerpc/boot/dts/mpc8641_hpcn_36b.dts
 
 diff --git a/arch/powerpc/boot/dts/mpc8641_hpcn_36b.dts 
 b/arch/powerpc/boot/dts/mpc8641_hpcn_36b.dts
 new file mode 100644
 index 000..baa3dba
 --- /dev/null
 +++ b/arch/powerpc/boot/dts/mpc8641_hpcn_36b.dts
 @@ -0,0 +1,597 @@
 +/*
 + * MPC8641 HPCN Device Tree Source
 + *
 + * Copyright 2006 Freescale Semiconductor Inc.
 + *
 + * This program is free software; you can redistribute  it and/or modify it
 + * under  the terms of  the GNU General  Public License as published by the
 + * Free Software Foundation;  either version 2 of the  License, or (at your
 + * option) any later version.
 + */

[snip]
 + soc8...@fffe0 {
 + #address-cells = 1;
 + #size-cells = 1;
 + device_type = soc;
 + compatible = simple-bus;

Uh, you definitely need something more specific in the compatible
property before simple-bus.

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH 5/5] powerpc: Add 86xx support for SWIOTLB

[Michael Ellerman]

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/kernel/dma-swiotlb.c b/arch/powerpc/ 
  kernel/dma-swiotlb.c
  index 29a68e6..3065d03 100644
  --- a/arch/powerpc/kernel/dma-swiotlb.c
  +++ b/arch/powerpc/kernel/dma-swiotlb.c
  @@ -159,3 +159,5 @@ static int __init setup_bus_notifier(void)
 
 return 0;
  }
  +
  +machine_arch_initcall(mpc86xx_hpcn, setup_bus_notifier);
 
  Hmm, not sure what we chatted about here, but I don't want to have  
  to add every board into this file to register the bus notifiers.
 
 We talked about this, and this was what we decided on - I don't really  
 like the idea, either, but there's a lot of precedent for it.  I'd  
 like to do this differently, but Im not sure what the solution is -  
 we'd need to look into that more (or perhaps someone here will have  
 some sage advice).

Give it a better name, export it, and call it from the board setup file?

Actually what depends on the board anyway? It's just the dma window
config in the pci_controller isn't it? So maybe you can always call the
notifier, and if the dma mask isn't 36 bits, and the controller has the
window configured then you use swiotlb?

cheers


signature.asc
Description: This is a digitally signed message part
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [microblaze-uclinux] [PATCH 11/11] microblaze: Kconfig: Enable drivers for Microblaze

[John Williams]

On Tue, Apr 21, 2009 at 12:48 AM, Grant Likely
grant.lik...@secretlab.ca wrote:
 On Mon, Apr 20, 2009 at 8:36 AM, John Linn john.l...@xilinx.com 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
 Subject: RE: [microblaze-uclinux] [PATCH 11/11] microblaze: Kconfig: Enable 
 drivers for Microblaze


 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


 It seems like John's suggestion of no arch filters would satisfy that also. 
 Since FPGAs are used in so many different applications this would seem to 
 open the drivers up to everyone regardless of what processor they're using. 
 It's certainly less complex so I like it in that way.

 But maybe I'm missing something here and there's a downside?

 No, I don't think there is.

 I think CONFIG_OF is the right thing to do.

Some (most?) of the Xilinx drivers currently have this construct:

#ifdef CONFIG_OF

// probe using OF

#else

// probe using platform_device

#endif

so unless this is going to change some time soon, maybe even CONFIG_OF
is too restrictive?

John
-- 
John Williams, PhD, B.Eng, B.IT
PetaLogix - Linux Solutions for a Reconfigurable World
w: www.petalogix.com  p: +61-7-30090663  f: +61-7-30090663
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH 1/5] powerpc: Use sg-dma_length in sg_dma_len() macro on 32-bit

[FUJITA Tomonori]

On Mon, 20 Apr 2009 15:06:16 -0500
Kumar Gala ga...@kernel.crashing.org 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_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 ifdefs, and is needed by the swiotlb code which
  actually distinguishes between dma_length and length.
 
  Signed-off-by: Becky Bruce bec...@kernel.crashing.org
  ---
  arch/powerpc/include/asm/scatterlist.h |6 +-
  1 files changed, 1 insertions(+), 5 deletions(-)
 
  diff --git a/arch/powerpc/include/asm/scatterlist.h b/arch/powerpc/ 
  include/asm/scatterlist.h
  index fcf7d55..912bf59 100644
  --- a/arch/powerpc/include/asm/scatterlist.h
  +++ b/arch/powerpc/include/asm/scatterlist.h
  @@ -21,7 +21,7 @@ struct scatterlist {
  unsigned int offset;
  unsigned int length;
 
 can we get rid of length?

You can't.


 
 
  -   /* For TCE support */
  +   /* For TCE or SWIOTLB support */
  dma_addr_t dma_address;
  u32 dma_length;
  };
  @@ -34,11 +34,7 @@ struct scatterlist {
   * is 0.
   */
  #define sg_dma_address(sg)  ((sg)-dma_address)
  -#ifdef __powerpc64__
  #define sg_dma_len(sg)  ((sg)-dma_length)
  -#else
  -#define sg_dma_len(sg) ((sg)-length)
  -#endif
 
  #ifdef __powerpc64__
  #define ISA_DMA_THRESHOLD   (~0UL)
  -- 
  1.6.0.6
 
 - k
 
 
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH 4/5] powerpc: Add support for swiotlb on 32-bit

[FUJITA Tomonori]

On Mon, 20 Apr 2009 13:03:20 -0500
Becky Bruce bec...@kernel.crashing.org 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 enabled on
  any platforms.
 
  Signed-off-by: Becky Bruce bec...@kernel.crashing.org
  ---
  arch/powerpc/Kconfig   |2 +-
  arch/powerpc/include/asm/dma-mapping.h |   11 ++
  arch/powerpc/include/asm/swiotlb.h |   24 +
  arch/powerpc/kernel/Makefile   |1 +
  arch/powerpc/kernel/dma-swiotlb.c  |  161 ++ 
  ++
  arch/powerpc/kernel/dma.c  |2 +-
  arch/powerpc/kernel/setup_32.c |4 +
  7 files changed, 203 insertions(+), 2 deletions(-)
  create mode 100644 arch/powerpc/include/asm/swiotlb.h
  create mode 100644 arch/powerpc/kernel/dma-swiotlb.c
 
  diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
  index 5b50e1a..197f6a3 100644
  --- a/arch/powerpc/Kconfig
  +++ b/arch/powerpc/Kconfig
  @@ -294,7 +294,7 @@ config IOMMU_HELPER
 
  config PPC_NEED_DMA_SYNC_OPS
 def_bool y
  -  depends on NOT_COHERENT_CACHE
  +  depends on (NOT_COHERENT_CACHE || SWIOTLB)
 
  This isn't right, since you haven't introduced the SWIOTLB Kconfig.
 
 
  Why don't we just put the SWIOTLB Kconfig option in here and default  
  it no (and remove the dep on 86xx).
 
 Sure.  I'll probably add a comment or something though so people don't  
 think they can just enable it on anything and expect it to work.  Too  
 many people seem to read the config files and decide things are  
 possible that actually aren't :)
 
 
 
  config HOTPLUG_CPU
 bool Support for enabling/disabling CPUs
 
 
  diff --git a/arch/powerpc/kernel/dma-swiotlb.c b/arch/powerpc/ 
  kernel/dma-swiotlb.c
  new file mode 100644
  index 000..29a68e6
  --- /dev/null
  +++ b/arch/powerpc/kernel/dma-swiotlb.c
  @@ -0,0 +1,161 @@
  +/*
  + * Contains routines needed to support swiotlb for ppc.
  + *
  + * Copyright (C) 2009 Becky Bruce, Freescale Semiconductor
  + *
  + * This program is free software; you can redistribute  it and/or  
  modify it
  + * under  the terms of  the GNU General  Public License as  
  published by the
  + * Free Software Foundation;  either version 2 of the  License, or  
  (at your
  + * option) any later version.
  + *
  + */
 
  [snip]
 
 
  +
  +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 != BUS_NOTIFY_ADD_DEVICE)
  +  return 0;
  +
  +  if (dma_get_mask(dev)  DMA_BIT_MASK(36))
  +  set_dma_ops(dev, swiotlb_dma_ops);
  +
 
  this isn't right.  Isn't possible for a PCI dev to have a  
  DMA_BIT_MASK(64) but us still not be able to dma to it?  Also, I  
  dont like the assumption of 36-bit physical here.
 
 You're right - this is just handling the basic case and for now I'm  
 assuming that we don't bounce 64-bit devices (or any device that can  
 handle 36 bits).   We'll need to talk in more detail about a solution  
 to that problem, because knowing if a 64b dev *might* need to bounce  
 (which is all this is really saying) requires more information.   We  
 also don't really have infrastructure to deal with holes in the  
 visible dev memory, and I don't know if we want to handle that as  
 well. I don't want to set the dma_ops to swiotlb unless we have to  
 because there's a slight perf hit in running all the checks to see if  
 an address needs to be bounced.

I think that you always just set the dma_ops to swiotlb. It's the
cleanest solution. Do you really see the performance drop due to the
checking?
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: Porting the ibm_newemac driver to use phylib (and other PHY/MAC questions)

[Kyle Moffett]

On Mon, Apr 20, 2009 at 8:29 AM, Josh Boyer jwbo...@linux.vnet.ibm.com wrote:
 On Fri, Apr 17, 2009 at 8:32 PM, Kyle Moffett k...@moffetthome.net 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 cribbed from the sungem driver.  I'm curious if there's
 some particular reason it hasn't been ported (aside from nobody has
 bothered yet).

 IIRC, Ben had some issues with how phylib and the EMAC would need to
 interact.  Not sure if he has those written down somewhere or not.
 (CC'd).

Hmm, yeah, I'd be interested to see those.  There's enough similar
between phylib and the EMAC and sungem drivers that I'm considering a
series of somewhat-mechanical patches to make EMAC and sungem use the
struct phy_device and struct mii_bus from phylib, possibly
abstracting out some helper functions along the way.

 Also, if I end up
 going that route, are there others available with other hardware
 variants who would be willing to test my patches on their boards?

 I have a large variety of boards that I can test with since the entire
 4xx line relies on this driver for on-board network.

Wonderful!  If/when I hack together a patch series I'll make sure to
put you on the CC list.  Thanks!

Cheers,
Kyle Moffett
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: Move dtc and libfdt sources from arch/powerpc/boot to scripts/dtc

[David Gibson]

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 directory?  I get:

Ugh.  Obviously not.  New patch coming.

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

[PATCH] Move dtc and libfdt sources from arch/powerpc/boot to scripts/dtc

[David Gibson]

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 by the kernel.  Sometimes, the bootwrapper makes
small changes to the pre-compiled device tree blob (e.g. filling in
the size of RAM).  To do this it uses the libfdt library.

Because these are only used on powerpc, the code for both these tools
is included under arch/powerpc/boot (these were imported and are
periodically updated from the upstream dtc tree).

However, the microblaze architecture, currently being prepared for
merging to mainline also uses dtc to produce device tree blobs.  A few
other archs have also mentioned some interest in using dtc.
Therefore, this patch moves dtc and libfdt from arch/powerpc into
scripts, where it can be used by any architecture.

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.

Signed-off-by: David Gibson da...@gibson.dropbear.id.au
---
 arch/powerpc/Kconfig   |4 +
 arch/powerpc/boot/Makefile |   67 +++-
 arch/powerpc/boot/simpleboot.c |2 +-
 scripts/Makefile   |1 +
 scripts/dtc/Makefile   |   54 
 .../boot/dtc-src = scripts/dtc}/Makefile.dtc  |0
 .../powerpc/boot/dtc-src = scripts/dtc}/checks.c  |0
 {arch/powerpc/boot/dtc-src = scripts/dtc}/data.c  |0
 .../boot/dtc-src = scripts/dtc}/dtc-lexer.l   |0
 .../dtc}/dtc-lexer.lex.c_shipped   |0
 .../dtc}/dtc-parser.tab.c_shipped  |0
 .../dtc}/dtc-parser.tab.h_shipped  |0
 .../boot/dtc-src = scripts/dtc}/dtc-parser.y  |0
 {arch/powerpc/boot/dtc-src = scripts/dtc}/dtc.c   |0
 {arch/powerpc/boot/dtc-src = scripts/dtc}/dtc.h   |0
 .../boot/dtc-src = scripts/dtc}/flattree.c|0
 .../powerpc/boot/dtc-src = scripts/dtc}/fstree.c  |0
 .../boot = scripts/dtc}/libfdt/Makefile.libfdt|0
 {arch/powerpc/boot = scripts/dtc}/libfdt/fdt.c|0
 {arch/powerpc/boot = scripts/dtc}/libfdt/fdt.h|0
 {arch/powerpc/boot = scripts/dtc}/libfdt/fdt_ro.c |0
 {arch/powerpc/boot = scripts/dtc}/libfdt/fdt_rw.c |0
 .../boot = scripts/dtc}/libfdt/fdt_strerror.c |0
 {arch/powerpc/boot = scripts/dtc}/libfdt/fdt_sw.c |0
 .../powerpc/boot = scripts/dtc}/libfdt/fdt_wip.c  |0
 {arch/powerpc/boot = scripts/dtc}/libfdt/libfdt.h |0
 .../dtc-src = scripts/dtc/libfdt}/libfdt_env.h|0
 .../boot = scripts/dtc}/libfdt/libfdt_internal.h  |0
 .../boot/dtc-src = scripts/dtc}/livetree.c|0
 .../powerpc/boot/dtc-src = scripts/dtc}/srcpos.c  |0
 .../powerpc/boot/dtc-src = scripts/dtc}/srcpos.h  |0
 .../boot/dtc-src = scripts/dtc}/treesource.c  |0
 .../boot/dtc-src = scripts/dtc}/version_gen.h |0
 33 files changed, 83 insertions(+), 45 deletions(-)
 create mode 100644 scripts/dtc/Makefile
 rename {arch/powerpc/boot/dtc-src = scripts/dtc}/Makefile.dtc (100%)
 rename {arch/powerpc/boot/dtc-src = scripts/dtc}/checks.c (100%)
 rename {arch/powerpc/boot/dtc-src = scripts/dtc}/data.c (100%)
 rename {arch/powerpc/boot/dtc-src = scripts/dtc}/dtc-lexer.l (100%)
 rename {arch/powerpc/boot/dtc-src = scripts/dtc}/dtc-lexer.lex.c_shipped 
(100%)
 rename {arch/powerpc/boot/dtc-src = scripts/dtc}/dtc-parser.tab.c_shipped 
(100%)
 rename {arch/powerpc/boot/dtc-src = scripts/dtc}/dtc-parser.tab.h_shipped 
(100%)
 rename {arch/powerpc/boot/dtc-src = scripts/dtc}/dtc-parser.y (100%)
 rename {arch/powerpc/boot/dtc-src = scripts/dtc}/dtc.c (100%)
 rename {arch/powerpc/boot/dtc-src = scripts/dtc}/dtc.h (100%)
 rename {arch/powerpc/boot/dtc-src = scripts/dtc}/flattree.c (100%)
 rename {arch/powerpc/boot/dtc-src = scripts/dtc}/fstree.c (100%)
 rename {arch/powerpc/boot = scripts/dtc}/libfdt/Makefile.libfdt (100%)
 rename {arch/powerpc/boot = scripts/dtc}/libfdt/fdt.c (100%)
 rename {arch/powerpc/boot = scripts/dtc}/libfdt/fdt.h (100%)
 rename {arch/powerpc/boot = scripts/dtc}/libfdt/fdt_ro.c (100%)
 rename {arch/powerpc/boot = scripts/dtc}/libfdt/fdt_rw.c (100%)
 rename {arch/powerpc/boot = scripts/dtc}/libfdt/fdt_strerror.c (100%)
 rename {arch/powerpc/boot = scripts/dtc}/libfdt/fdt_sw.c (100%)
 rename {arch/powerpc/boot = scripts/dtc}/libfdt/fdt_wip.c (100%)
 rename {arch/powerpc/boot = scripts/dtc}/libfdt/libfdt.h (100%)
 rename {arch/powerpc/boot/dtc-src = scripts/dtc/libfdt}/libfdt_env.h (100%)
 rename {arch/powerpc/boot = scripts/dtc}/libfdt/libfdt_internal.h (100%)
 rename {arch/powerpc/boot/dtc-src = scripts/dtc}/livetree.c (100%)
 rename {arch/powerpc/boot/dtc-src = scripts/dtc}/srcpos.c (100%)
 rename