* Re: linux-next: build failure after merge of the final tree (tty tree related)
From: Stephen Rothwell @ 2011-08-26 0:39 UTC (permalink / raw)
To: Arnaud Lacombe; +Cc: Greg KH, linux-next, ppc-dev, Timur Tabi, linux-kernel
In-Reply-To: <CACqU3MUs_97=MuuKAjr-LeUT7kSRxtzSntwUeKeeH4n8s7SSGg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 604 bytes --]
Hi Arnaud,
On Thu, 25 Aug 2011 12:09:20 -0400 Arnaud Lacombe <lacombar@gmail.com> wrote:
>
> If you could provide an exhaustive list of them, I'd be interested. Do
> you account/reference them in the report you make on each new -next
> tree ?
I don't refer to them at all :-(
If you are not just referring to powerpc ones, then an x86_64
allmodconfig is a good place to start, there are several in there.
Otherwise, I will send you the results of some of my builds this evening.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* [PATCH] dtc: remove some warnings
From: Stephen Rothwell @ 2011-08-26 1:26 UTC (permalink / raw)
To: David Gibson, jdl; +Cc: John Bonesio, ppc-dev, linux-kernel
I assume that these variables were used in the past but not removed when
their usage was removed.
Fixes these warnings:
scripts/dtc/dtc.c: In function 'main':
scripts/dtc/dtc.c:102:17: warning: variable 'check' set but not used [-Wunused-but-set-variable]
scripts/dtc/flattree.c: In function 'flat_read_mem_reserve':
scripts/dtc/flattree.c:700:14: warning: variable 'p' set but not used [-Wunused-but-set-variable]
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
scripts/dtc/dtc.c | 5 +----
scripts/dtc/flattree.c | 2 --
2 files changed, 1 insertions(+), 6 deletions(-)
diff --git a/scripts/dtc/dtc.c b/scripts/dtc/dtc.c
index cbc0193..fc83355 100644
--- a/scripts/dtc/dtc.c
+++ b/scripts/dtc/dtc.c
@@ -99,7 +99,7 @@ int main(int argc, char *argv[])
const char *inform = "dts";
const char *outform = "dts";
const char *outname = "-";
- int force = 0, check = 0, sort = 0;
+ int force = 0, sort = 0;
const char *arg;
int opt;
FILE *outf = NULL;
@@ -137,9 +137,6 @@ int main(int argc, char *argv[])
case 'f':
force = 1;
break;
- case 'c':
- check = 1;
- break;
case 'q':
quiet++;
break;
diff --git a/scripts/dtc/flattree.c b/scripts/dtc/flattree.c
index ead0332..28d0b23 100644
--- a/scripts/dtc/flattree.c
+++ b/scripts/dtc/flattree.c
@@ -697,7 +697,6 @@ static struct reserve_info *flat_read_mem_reserve(struct inbuf *inb)
{
struct reserve_info *reservelist = NULL;
struct reserve_info *new;
- const char *p;
struct fdt_reserve_entry re;
/*
@@ -706,7 +705,6 @@ static struct reserve_info *flat_read_mem_reserve(struct inbuf *inb)
*
* First pass, count entries.
*/
- p = inb->ptr;
while (1) {
flat_read_chunk(inb, &re, sizeof(re));
re.address = fdt64_to_cpu(re.address);
--
1.7.5.4
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
^ permalink raw reply related
* Re: [PATCH] [v2] tty/powerpc: fix build break with ehv_bytechan.c on allyesconfig
From: Stephen Rothwell @ 2011-08-26 3:33 UTC (permalink / raw)
To: Timur Tabi; +Cc: greg, linux-next, linux-kernel, linuxppc-dev
In-Reply-To: <1314295617-2953-1-git-send-email-timur@freescale.com>
[-- Attachment #1: Type: text/plain, Size: 505 bytes --]
Hi all,
On Thu, 25 Aug 2011 13:06:57 -0500 Timur Tabi <timur@freescale.com> wrote:
>
> The ePAPR hypervisor byte channel driver is supposed to work on all
> ePAPR-compliant embedded PowerPC systems, but it had a reference to the MSR_GS
> bit, which is available only on Book-E systems.
>
> Also fix a couple integer-to-pointer typecast problems.
I applied this to linux-next today.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: kvm PCI assignment & VFIO ramblings
From: David Gibson @ 2011-08-26 4:20 UTC (permalink / raw)
To: Roedel, Joerg
Cc: chrisw, Alexey Kardashevskiy, kvm@vger.kernel.org, Paul Mackerras,
linux-pci@vger.kernel.org, qemu-devel, aafabbri, iommu,
Avi Kivity, Anthony Liguori, linuxppc-dev, benve@cisco.com
In-Reply-To: <20110824110332.GH2079@amd.com>
On Wed, Aug 24, 2011 at 01:03:32PM +0200, Roedel, Joerg wrote:
> On Wed, Aug 24, 2011 at 05:33:00AM -0400, David Gibson wrote:
> > On Wed, Aug 24, 2011 at 11:14:26AM +0200, Roedel, Joerg wrote:
>
> > > I don't see a reason to make this meta-grouping static. It would harm
> > > flexibility on x86. I think it makes things easier on power but there
> > > are options on that platform to get the dynamic solution too.
> >
> > I think several people are misreading what Ben means by "static". I
> > would prefer to say 'persistent', in that the meta-groups lifetime is
> > not tied to an fd, but they can be freely created, altered and removed
> > during runtime.
>
> Even if it can be altered at runtime, from a usability perspective it is
> certainly the best to handle these groups directly in qemu. Or are there
> strong reasons to do it somewhere else?
Funny, Ben and I think usability demands it be the other way around.
If the meta-groups are transient - that is lifetime tied to an fd -
then any program that wants to use meta-groups *must* know the
interfaces for creating one, whatever they are.
But if they're persistent, the admin can use other tools to create the
meta-group then just hand it to a program to use, since the interfaces
for _using_ a meta-group are identical to those for an atomic group.
This doesn't preclude a program from being meta-group aware, and
creating its own if it wants to, of course. My guess is that qemu
would not want to build its own meta-groups, but libvirt probably
would.
--
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
^ permalink raw reply
* Re: kvm PCI assignment & VFIO ramblings
From: David Gibson @ 2011-08-26 4:24 UTC (permalink / raw)
To: Alexander Graf
Cc: Alex Williamson, Alexey Kardashevskiy, kvm@vger.kernel.org,
Paul Mackerras, Roedel, Joerg, qemu-devel, chrisw, iommu,
Avi Kivity, Anthony Liguori, linux-pci@vger.kernel.org,
linuxppc-dev, benve@cisco.com
In-Reply-To: <EC0C2298-1EC9-42A0-9A71-3671E21BCA56@suse.de>
On Thu, Aug 25, 2011 at 08:25:45AM -0500, Alexander Graf wrote:
>
> On 25.08.2011, at 07:31, Roedel, Joerg wrote:
>
> > On Wed, Aug 24, 2011 at 11:07:46AM -0400, Alex Williamson wrote:
> >> On Wed, 2011-08-24 at 10:52 +0200, Roedel, Joerg wrote:
> >
>
> [...]
>
> >> We need to try the polite method of attempting to hot unplug the device
> >> from qemu first, which the current vfio code already implements. We can
> >> then escalate if it doesn't respond. The current code calls abort in
> >> qemu if the guest doesn't respond, but I agree we should also be
> >> enforcing this at the kernel interface. I think the problem with the
> >> hard-unplug is that we don't have a good revoke mechanism for the mmio
> >> mmaps.
> >
> > For mmio we could stop the guest and replace the mmio region with a
> > region that is filled with 0xff, no?
>
> Sure, but that happens in user space. The question is how does
> kernel space enforce an MMIO region to not be mapped after the
> hotplug event occured? Keep in mind that user space is pretty much
> untrusted here - it doesn't have to be QEMU. It could just as well
> be a generic user space driver. And that can just ignore hotplug
> events.
We're saying you hard yank the mapping from the userspace process.
That is, you invalidate all its PTEs mapping the MMIO space, and don't
let it fault them back in.
As I see it there are two options: (a) make subsequent accesses from
userspace or the guest result in either a SIGBUS that userspace must
either deal with or die, or (b) replace the mapping with a dummy RO
mapping containing 0xff, with any trapped writes emulated as nops.
--
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
^ permalink raw reply
* Re: [PATCH 2/2] [PowerPC Book3E] Introduce new ptrace debug feature flag
From: David Gibson @ 2011-08-26 4:41 UTC (permalink / raw)
To: Thiago Jung Bauermann; +Cc: linuxppc-dev, K.Prasad, Edjunior Barbosa Machado
In-Reply-To: <1314232903.14168.4.camel@hactar>
On Wed, Aug 24, 2011 at 09:41:43PM -0300, Thiago Jung Bauermann wrote:
> On Wed, 2011-08-24 at 14:00 +1000, David Gibson wrote:
> > On Tue, Aug 23, 2011 at 02:57:56PM +0530, K.Prasad wrote:
> > > On Tue, Aug 23, 2011 at 03:09:31PM +1000, David Gibson wrote:
> > > > On Fri, Aug 19, 2011 at 01:23:38PM +0530, K.Prasad wrote:
> > > > >
> > > > > While PPC_PTRACE_SETHWDEBUG ptrace flag in PowerPC accepts
> > > > > PPC_BREAKPOINT_MODE_EXACT mode of breakpoint, the same is not intimated to the
> > > > > user-space debuggers (like GDB) who may want to use it. Hence we introduce a
> > > > > new PPC_DEBUG_FEATURE_DATA_BP_EXACT flag which will be populated on the
> > > > > "features" member of "struct ppc_debug_info" to advertise support for the
> > > > > same on Book3E PowerPC processors.
> > > >
> > > > I thought the idea was that the BP_EXACT mode was the default - if the
> > > > new interface was supported at all, then BP_EXACT was always
> > > > supported. So, why do you need a new flag?
> > > >
> > >
> > > Yes, BP_EXACT was always supported but not advertised through
> > > PPC_PTRACE_GETHWDBGINFO. We're now doing that.
> >
> > I can see that. But you haven't answered why.
>
> BookS doesn't support BP_EXACT, that's why I suggested this flag.
Surely you can support it with exactly the same sort of filtering
you're using for the 8-byte ranges now?
> A BP_EXACT watchpoint triggers only when there's a memory access exactly
> at the given address. It doesn't trigger when there's (for example) a
> 4-byte write at an address immediately before which also changes the
> memory contents of the byte watched by the BP_EXACT watchpoint. a ranged
> watchpoint would trigger, so the semantics are different.
>
> As a general rule, GDB only sets ranged watchpoints and only uses
> BP_EXACT ones when the user sets a flag. I want GDB to fail when the
> user sets the flag on BookS since it can't provide the feature.
--
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
^ permalink raw reply
* Re: [PATCH] dtc: remove some warnings
From: David Gibson @ 2011-08-26 4:49 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: John Bonesio, jdl, ppc-dev, linux-kernel
In-Reply-To: <20110826112643.f86132d55edc5d452df3ebd0@canb.auug.org.au>
On Fri, Aug 26, 2011 at 11:26:43AM +1000, Stephen Rothwell wrote:
> I assume that these variables were used in the past but not removed when
> their usage was removed.
>
> Fixes these warnings:
>
> scripts/dtc/dtc.c: In function 'main':
> scripts/dtc/dtc.c:102:17: warning: variable 'check' set but not used [-Wunused-but-set-variable]
> scripts/dtc/flattree.c: In function 'flat_read_mem_reserve':
> scripts/dtc/flattree.c:700:14: warning: variable 'p' set but not used [-Wunused-but-set-variable]
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Acked-by: David Gibson <david@gibson.dropbear.id.au>
Yeah, I noticed these gcc 4.6 warnings recently, but didn't get around
to sending a patch.
Jon, please apply. Uh.. except that this is a patch against the in
kernel dtc, rather than upstream.
--
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
^ permalink raw reply
* Re: [PATCH] dtc: remove some warnings
From: Stephen Rothwell @ 2011-08-26 5:34 UTC (permalink / raw)
To: David Gibson; +Cc: John Bonesio, jdl, ppc-dev, linux-kernel
In-Reply-To: <20110826044902.GJ2308@yookeroo.fritz.box>
[-- Attachment #1: Type: text/plain, Size: 418 bytes --]
Hi David,
On Fri, 26 Aug 2011 14:49:02 +1000 David Gibson <dwg@au1.ibm.com> wrote:
>
> Jon, please apply. Uh.. except that this is a patch against the in
> kernel dtc, rather than upstream.
Yeah, Josh pointed out that these are fixed in upstream. I guess we need
to do another snapshot merge ...
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* RE: Kernel boot up
From: smitha.vanga @ 2011-08-26 6:00 UTC (permalink / raw)
To: scottwood; +Cc: linuxppc-dev
In-Reply-To: <4E56A30F.4010509@freescale.com>
[-- Attachment #1: Type: text/plain, Size: 12768 bytes --]
Thanks scott.
There was an issue with the file system. Now my board is up with the
linux boot prompt .
But ping is not working. The local loopback ping works. My phy chip
BCM5221 is connected on port A
I am using FCC1 as the MAC. I see that the intrrupt handler is being
registered properly. And even the fs_enet_start_xmit() gets called and
it returns with return NETDEV_TX_OK. When I do a ifconfig -a
I see the TX packets count increases for the loop back device but not
for eth0. I am using the wireshark tool to see any packets on the witr.
But don't see any ARP packets coming out on the wire.
Can you please suggest . Below are the logs. Attache dis the .dts file.
I have commented the bcsr register part in the .dts is this required.
EPN412> bootm 1000000 2000000 c00000
## Current stack ends at 0x03e93cc8
* kernel: cmdline image address = 0x01000000
## Booting kernel from Legacy Image at 01000000 ...
Image Name: Linux-2.6.39
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 1765760 Bytes = 1.7 MiB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
kernel data at 0x01000040, len = 0x001af180 (1765760)
* ramdisk: cmdline image address = 0x02000000
## Loading init Ramdisk from Legacy Image at 02000000 ...
Image Name: uboot ext2 ramdisk rootfs
Image Type: PowerPC Linux RAMDisk Image (gzip compressed)
Data Size: 3972156 Bytes = 3.8 MiB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
ramdisk start = 0x02000040, ramdisk end = 0x023c9c7c
* fdt: cmdline image address = 0x00c00000
## Checking for 'FDT'/'FDT Image' at 00c00000
* fdt: raw FDT blob
## Flattened Device Tree blob at 00c00000
Booting using the fdt blob at 0xc00000
of_flat_tree at 0x00c00000 size 0x00000f12
Uncompressing Kernel Image ... OK
kernel loaded at 0x00000000, end = 0x0038bd20
## initrd_high = 0xffffffff, copy_to_ram = 1
Loading Ramdisk to 03ac9000, end 03e92c3c ... OK
ramdisk load start = 0x03ac9000, ramdisk load end = 0x03e92c3c
## device tree at 00c00000 ... 00c00f11 (len=16146 [0x3F12])
Loading Device Tree to 007fc000, end 007fff11 ... OK
Updating property 'clock-frequency' = 00 fe 70 b8
Updating property 'bus-frequency' = 03 f9 c2 e0
Updating property 'timebase-frequency' = 00 7f 38 5c
Updating property 'clock-frequency' = 09 f0 67 30
## Transferring control to Linux (at address 00000000) ...
Booting using OF flat tree...
Using Freescale MPC8272 ADS machine description
Linux version 2.6.39 (2.6.39) (ktuser@ktuser) (gcc version 4.4.5
(Buildroot 2011.02) ) #7
Thu Aug 25 20:59:40 IST 2011
Found initrd at 0xc3ac9000:0xc3e92c3c
No bcsr in device tree
Zone PFN ranges:
DMA 0x00000000 -> 0x00004000
Normal empty
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
0: 0x00000000 -> 0x00004000
Built 1 zonelists in Zone order, mobility grouping on. Total pages:
16256
Kernel command line: mem=64M root=/dev/ram rw
PID hash table entries: 256 (order: -2, 1024 bytes)
Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
Memory: 56244k/65536k available (3528k kernel code, 9292k reserved, 104k
data, 1137k bss,
168k init)
Kernel virtual memory layout:
* 0xfffdf000..0xfffff000 : fixmap
* 0xfdfb6000..0xfe000000 : early ioremap
* 0xc5000000..0xfdfb6000 : vmalloc & ioremap
SLUB: Genslabs=15, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
NR_IRQS:512 nr_irqs:512 16
No pci pic node in device tree.
clocksource: timebase mult[1dfc2974] shift[22] registered
console [ttyCPM0] enabled
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 512
NET: Registered protocol family 16
PCI: Probing PCI hardware
bio: create slab <bio-0> at 0
vgaarb: loaded
Switching to clocksource timebase
Switched to NOHz mode on CPU #0
NET: Registered protocol family 2
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
TCP established hash table entries: 2048 (order: 2, 16384 bytes)
TCP bind hash table entries: 2048 (order: 1, 8192 bytes)
TCP: Hash tables configured (established 2048 bind 2048)
TCP reno registered
UDP hash table entries: 256 (order: 0, 4096 bytes)
UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
NET: Registered protocol family 1
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
RPC: Registered tcp NFSv4.1 backchannel transport module.
Trying to unpack rootfs image as initramfs...
rootfs image is not initramfs (no cpio magic); looks like an initrd
Freeing initrd memory: 3879k freed
msgmni has been set to 119
Block layer SCSI generic (bsg) driver version 0.4 loaded (major 254)
io scheduler noop registered
io scheduler deadline registered
io scheduler cfq registered (default)
f0011a00.serial: ttyCPM0 at MMIO 0xc5014a00 (irq = 40) is a CPM UART
f0011a60.serial: ttyCPM1 at MMIO 0xc5018a60 (irq = 43) is a CPM UART
brd: module loaded
loop: module loaded
of-flash ff800000.flash: do_map_probe() failed
=====raj gem init
PPP generic driver version 2.4.2
PPP Deflate Compression module registered
tun: Universal TUN/TAP device driver, 1.6
tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
eth0: fs_enet: 00:00:00:00:00:00
eth1: fs_enet: 00:00:00:00:00:00
CPM2 Bitbanged MII: probed
mousedev: PS/2 mouse device common for all mice
TCP cubic registered
NET: Registered protocol family 10
IPv6 over IPv4 tunneling driver
NET: Registered protocol family 17
RAMDISK: gzip image found at block 0
VFS: Mounted root (ext2 filesystem) on device 1:0.
Freeing unused kernel memory: 168k init
Mounting /proc and /sys
Setting the hostname to mpc837xemds
Mounting filesystems
mount: mounting usbfs on /proc/bus/usb failed: No such file or directory
Starting syslogd and klogd
Running sysctl
Setting up networking on loopback device:
Setting up networking on eth0:
SIOCSIFFLAGS: Cannot assign requested address
Adding static route for default gateway to 192.168.1.1:
SIOCADDRT: Network is unreachable
Setting nameserver to 192.168.1.1 in /etc/resolv.conf:
Setting up networking on eth1:
SIOCSIFFLAGS: Cannot assign requested address
Adding static route for default gateway to 192.168.1.1:
SIOCADDRT: Network is unreachable
Setting nameserver to 192.168.1.1 in /etc/resolv.conf:
Starting inetd:
Please set the system time using
date <mmddhhmnyyyy>
/sbin/hwclock -w
Welcome to Freescale Semiconductor Embedded Linux Environment
!!!!! WARNING !!!!!!!
The default password for the root account is: root
please change this password using the 'passwd' command
and then edit this message (/etc/issue) to remove this message
mpc837xemds login: root
Password:
[root@mpc837xemds /root]#
[root@mpc837xemds /root]#
[root@mpc837xemds /root]#
[root@mpc837xemds /root]# cat /proc/interrupts
CPU0
40: 55 CPM2 SIU Level cpm_uart
LOC: 3507 Local timer interrupts
SPU: 0 Spurious interrupts
CNT: 0 Performance monitoring interrupts
MCE: 0 Machine check exceptions
[root@mpc837xemds /root]# cat /proc/interrupts
CPU0
40: 67 CPM2 SIU Level cpm_uart
LOC: 3536 Local timer interrupts
SPU: 0 Spurious interrupts
CNT: 0 Performance monitoring interrupts
MCE: 0 Machine check exceptions
[root@mpc837xemds /root]# ping localhost
PING localhost (127.0.0.1): 56 data bytes
64 bytes from 127.0.0.1: seq=0 ttl=64 time=1.803 ms
64 bytes from 127.0.0.1: seq=1 ttl=64 time=1.784 ms
64 bytes from 127.0.0.1: seq=2 ttl=64 time=1.190 ms
64 bytes from 127.0.0.1: seq=3 ttl=64 time=1.187 ms
--- localhost ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 1.187/1.491/1.803 ms
[root@mpc837xemds /root]# cat /proc/interrupts
CPU0
40: 106 CPM2 SIU Level cpm_uart
LOC: 3636 Local timer interrupts
SPU: 0 Spurious interrupts
CNT: 0 Performance monitoring interrupts
MCE: 0 Machine check exceptions
[root@mpc837xemds /root]# ping l
[root@mpc837xemds /root]# ifconfig
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:8 errors:0 dropped:0 overruns:0 frame:0
TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:672 (672.0 b) TX bytes:672 (672.0 b)
[root@mpc837xemds /root]# ifconfig eth0 up
SIOCSIFFLAGS: Cannot assign requested address
[root@mpc837xemds /root]# ifconfig -a
eth0 Link encap:Ethernet HWaddr 00:00:00:00:00:00
inet addr:192.168.1.100 Bcast:192.168.1.255
Mask:255.255.255.0
BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
eth1 Link encap:Ethernet HWaddr 00:00:00:00:00:00
inet addr:192.168.1.101 Bcast:192.168.1.255
Mask:255.255.255.0
BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:8 errors:0 dropped:0 overruns:0 frame:0
TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:672 (672.0 b) TX bytes:672 (672.0 b)
sit0 Link encap:UNSPEC HWaddr
00-00-00-00-04-22-10-02-00-00-00-00-00-00-00-00
NOARP MTU:1480 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
[root@mpc837xemds /root]# ifconfig eth0 hw ether 00:00:00:00:00:01
[root@mpc837xemds /root]# ifconfig eth0 up
ADDRCONF(NETDEV_UP): eth0: link is not ready
[root@mpc837xemds /root]# ADDRCONF(NETDEV_CHANGE): eth0: link becomes
ready
[root@mpc837xemds /root]#
[root@mpc837xemds /root]#
[root@mpc837xemds /root]#
[root@mpc837xemds /root]# ifconfig
eth0 Link encap:Ethernet HWaddr 00:00:00:00:00:01
inet addr:192.168.1.100 Bcast:192.168.1.255
Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:5
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 b) TX bytes:398 (398.0 b)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:8 errors:0 dropped:0 overruns:0 frame:0
TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:672 (672.0 b) TX bytes:672 (672.0 b)
[root@mpc837xemds /root]# ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1): 56 data bytes
--- 192.168.1.1 ping statistics ---
3 packets transmitted, 0 packets received, 100% packet loss
[root@mpc837xemds /root]# cat /proc/interrupts
CPU0
32: 9 CPM2 SIU Level fs_enet-mac
40: 384 CPM2 SIU Level cpm_uart
LOC: 4369 Local timer interrupts
SPU: 0 Spurious interrupts
CNT: 0 Performance monitoring interrupts
MCE: 0 Machine check exceptions
[root@mpc837xemds /root]#
Regards,
Smitha
Please do not print this email unless it is absolutely necessary.
The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments.
WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.
www.wipro.com
[-- Attachment #2: mpc8272ads.dts --]
[-- Type: application/octet-stream, Size: 6684 bytes --]
/*
* MPC8272 ADS Device Tree Source
*
* Copyright 2005,2008 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 = "MPC8272ADS";
compatible = "fsl,mpc8272ads";
#address-cells = <1>;
#size-cells = <1>;
aliases {
ethernet0 = ð0;
ethernet1 = ð1;
serial0 = &scc1;
serial1 = &scc4;
};
cpus {
#address-cells = <1>;
#size-cells = <0>;
PowerPC,8247@0 {
device_type = "cpu";
reg = <0x0>;
d-cache-line-size = <32>;
i-cache-line-size = <32>;
d-cache-size = <16384>;
i-cache-size = <16384>;
timebase-frequency = <0>;
bus-frequency = <0>;
clock-frequency = <0>;
};
};
memory {
device_type = "memory";
reg = <0x0 0x4000000>;
};
localbus@f0010100 {
compatible = "fsl,mpc8272-localbus",
"fsl,pq2-localbus";
#address-cells = <2>;
#size-cells = <1>;
reg = <0xf0010100 0x40>;
ranges = <0x0 0x0 0xff800000 0x00800000>;
/* 0x1 0x0 0xf4500000 0x8000
0x3 0x0 0xf8200000 0x8000>; */
flash@0,0 {
compatible = "jedec-flash";
reg = <0x0 0x0 0x00800000>;
bank-width = <4>;
device-width = <1>;
};
/*
board-control@1,0 {
reg = <0x1 0x0 0x20>;
compatible = "fsl,mpc8272ads-bcsr";
};
PCI_PIC: interrupt-controller@3,0 {
compatible = "fsl,mpc8272ads-pci-pic",
"fsl,pq2ads-pci-pic";
#interrupt-cells = <1>;
interrupt-controller;
reg = <0x3 0x0 0x8>;
interrupt-parent = <&PIC>;
interrupts = <20 8>;
};
*/ };
/*
pci@f0010800 {
device_type = "pci";
reg = <0xf0010800 0x10c 0xf00101ac 0x8 0xf00101c4 0x8>;
compatible = "fsl,mpc8272-pci", "fsl,pq2-pci";
#interrupt-cells = <1>;
#size-cells = <2>;
#address-cells = <3>;
clock-frequency = <66666666>;
interrupt-map-mask = <0xf800 0x0 0x0 0x7>;
interrupt-map = <
/* IDSEL 0x16
0xb000 0x0 0x0 0x1 &PCI_PIC 0
0xb000 0x0 0x0 0x2 &PCI_PIC 1
0xb000 0x0 0x0 0x3 &PCI_PIC 2
0xb000 0x0 0x0 0x4 &PCI_PIC 3
/* IDSEL 0x17
0xb800 0x0 0x0 0x1 &PCI_PIC 4
0xb800 0x0 0x0 0x2 &PCI_PIC 5
0xb800 0x0 0x0 0x3 &PCI_PIC 6
0xb800 0x0 0x0 0x4 &PCI_PIC 7
/* IDSEL 0x18
0xc000 0x0 0x0 0x1 &PCI_PIC 8
0xc000 0x0 0x0 0x2 &PCI_PIC 9
0xc000 0x0 0x0 0x3 &PCI_PIC 10
0xc000 0x0 0x0 0x4 &PCI_PIC 11>;
interrupt-parent = <&PIC>;
interrupts = <18 8>;
ranges = <0x42000000 0x0 0x80000000 0x80000000 0x0 0x20000000
0x2000000 0x0 0xa0000000 0xa0000000 0x0 0x20000000
0x1000000 0x0 0x0 0xf6000000 0x0 0x2000000>;
};
*/
soc@f0000000 {
#address-cells = <1>;
#size-cells = <1>;
device_type = "soc";
compatible = "fsl,mpc8272", "fsl,pq2-soc";
ranges = <0x0 0xf0000000 0x53000>;
// Temporary -- will go away once kernel uses ranges for get_immrbase().
reg = <0xf0000000 0x53000>;
cpm@119c0 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "fsl,mpc8272-cpm", "fsl,cpm2";
reg = <0x119c0 0x30>;
ranges;
muram@0 {
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0x0 0x10000>;
data@0 {
compatible = "fsl,cpm-muram-data";
reg = <0x0 0x2000 0x9800 0x800>;
};
};
brg@119f0 {
compatible = "fsl,mpc8272-brg",
"fsl,cpm2-brg",
"fsl,cpm-brg";
reg = <0x119f0 0x10 0x115f0 0x10>;
};
scc1: serial@11a00 {
device_type = "serial";
compatible = "fsl,mpc8272-scc-uart",
"fsl,cpm2-scc-uart";
reg = <0x11a00 0x20 0x8000 0x100>;
interrupts = <40 8>;
interrupt-parent = <&PIC>;
fsl,cpm-brg = <1>;
fsl,cpm-command = <0x800000>;
};
scc4: serial@11a60 {
device_type = "serial";
compatible = "fsl,mpc8272-scc-uart",
"fsl,cpm2-scc-uart";
reg = <0x11a60 0x20 0x8300 0x100>;
interrupts = <43 8>;
interrupt-parent = <&PIC>;
fsl,cpm-brg = <4>;
fsl,cpm-command = <0xce00000>;
};
/* usb@11b60 {
compatible = "fsl,mpc8272-cpm-usb";
reg = <0x11b60 0x40 0x8b00 0x100>;
interrupts = <11 8>;
interrupt-parent = <&PIC>;
mode = "peripheral";
}; */
mdio@10d40 {
device_type = "mdio";
compatible = "fsl,mpc8272ads-mdio-bitbang",
"fsl,mpc8272-mdio-bitbang",
"fsl,cpm2-mdio-bitbang";
reg = <0x10d40 0x14>;
#address-cells = <1>;
#size-cells = <0>;
fsl,mdio-pin = <23>;
fsl,mdc-pin = <22>;
PHY0: ethernet-phy@0 {
interrupt-parent = <&PIC>;
interrupts = <23 8>;
reg = <0x0>;
device_type = "ethernet-phy";
};
PHY1: ethernet-phy@1 {
interrupt-parent = <&PIC>;
interrupts = <23 8>;
reg = <0x3>;
device_type = "ethernet-phy";
};
};
eth0: ethernet@11300 {
device_type = "network";
compatible = "fsl,mpc8272-fcc-enet",
"fsl,cpm2-fcc-enet";
reg = <0x11300 0x20 0x8400 0x100 0x11390 0x1>;
local-mac-address = [ 00 00 00 00 00 00 ];
interrupts = <32 8>;
interrupt-parent = <&PIC>;
phy-handle = <&PHY0>;
linux,network-index = <0>;
fsl,cpm-command = <0x12000300>;
};
eth1: ethernet@11320 {
device_type = "network";
compatible = "fsl,mpc8272-fcc-enet",
"fsl,cpm2-fcc-enet";
reg = <0x11320 0x20 0x8500 0x100 0x113b0 0x1>;
local-mac-address = [ 00 00 00 00 00 00 ];
interrupts = <33 8>;
interrupt-parent = <&PIC>;
phy-handle = <&PHY1>;
linux,network-index = <1>;
fsl,cpm-command = <0x16200300>;
};
i2c@11860 {
compatible = "fsl,mpc8272-i2c",
"fsl,cpm2-i2c";
reg = <0x11860 0x20 0x8afc 0x2>;
interrupts = <1 8>;
interrupt-parent = <&PIC>;
fsl,cpm-command = <0x29600000>;
#address-cells = <1>;
#size-cells = <0>;
};
};
PIC: interrupt-controller@10c00 {
#interrupt-cells = <2>;
interrupt-controller;
reg = <0x10c00 0x80>;
compatible = "fsl,mpc8272-pic", "fsl,cpm2-pic";
};
crypto@30000 {
compatible = "fsl,sec1.0";
reg = <0x40000 0x13000>;
interrupts = <47 0x8>;
interrupt-parent = <&PIC>;
fsl,num-channels = <4>;
fsl,channel-fifo-len = <24>;
fsl,exec-units-mask = <0x7e>;
fsl,descriptor-types-mask = <0x1010415>;
};
};
chosen {
linux,stdout-path = "/soc/cpm/serial@11a00";
};
};
^ permalink raw reply
* Re: [PATCH 2/2] mmc: Use mmc_delay() instead of mdelay() for time delay
From: Lan Chunhe @ 2011-08-26 8:45 UTC (permalink / raw)
To: Kyungmin Park, Chunhe Lan
Cc: linuxppc-dev, kumar.gala, Chris Ball, linux-mmc, Shengzhou Liu
In-Reply-To: <CAH9JG2VUA_5c=3LPEvoVmTrYN9WibY87AgEkNgV3uFpAS0euQA@mail.gmail.com>
On Thu, 25 Aug 2011 18:23:35 +0800, Kyungmin Park <kmpark@infradead.org>
wrote:
> On Thu, Aug 25, 2011 at 5:54 PM, Chunhe Lan <Chunhe.Lan@freescale.com>
> wrote:
>> The mmc_delay() is a wrapper function for mdelay() and msleep().
>>
>> o mdelay() -- block the system when busy-waiting.
>> o msleep() -- suspend the currently running task to enable CPU
>> to process other tasks, so it is non-blocking
>> regarding the whole system.
>>
>> When the desired delay time is more than a period of timer interrupt,
>> just use msleep(). Change mdelay() to mmc_delay() to avoid chewing
>> CPU when busy wait.
>>
>> Signed-off-by: Shengzhou Liu <b36685@freescale.com>
>> Signed-off-by: Chunhe Lan <Chunhe.Lan@freescale.com>
>> Cc: Chris Ball <cjb@laptop.org>
>> ---
>> drivers/mmc/host/sdhci.c | 11 ++++++-----
>> 1 files changed, 6 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
>> index 0e02cc1..0cb5dc1 100644
>> --- a/drivers/mmc/host/sdhci.c
>> +++ b/drivers/mmc/host/sdhci.c
>> @@ -27,6 +27,7 @@
>> #include <linux/mmc/host.h>
>>
>> #include "sdhci.h"
>> +#include "../core/core.h"
>
> Doesn't better to move the mmc_delay() to "include/linux/mmc/core.h"?
> and include it.
> I think It's not proper include syntax using relative path.
Yes, your suggestion is very good.
I will move the mmc_delay() to "include/linux/mmc/core.h" .
Thanks.
-Jack Lan
> Thank you,
> Kyungmin Park
>>
>> #define DRIVER_NAME "sdhci"
>>
^ permalink raw reply
* RE: [PATCH 2/2 v2] eSDHC: Fix errors when booting kernel with fsl esdhc
From: Zang Roy-R61911 @ 2011-08-26 8:44 UTC (permalink / raw)
To: Anton Vorontsov
Cc: Wood Scott-B07421, Xu Lei-B33228, linux-mmc@vger.kernel.org,
akpm@linux-foundation.org, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20110812100450.GA23333@oksana.dev.rtsoft.ru>
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQW50b24gVm9yb250c292
IFttYWlsdG86Y2JvdWF0bWFpbHJ1QGdtYWlsLmNvbV0NCj4gU2VudDogRnJpZGF5LCBBdWd1c3Qg
MTIsIDIwMTEgMTg6MDUgUE0NCj4gVG86IFphbmcgUm95LVI2MTkxMQ0KPiBDYzogbGludXgtbW1j
QHZnZXIua2VybmVsLm9yZzsgbGludXhwcGMtZGV2QGxpc3RzLm96bGFicy5vcmc7IGFrcG1AbGlu
dXgtDQo+IGZvdW5kYXRpb24ub3JnOyBYdSBMZWktQjMzMjI4OyBLdW1hciBHYWxhOyBXb29kIFNj
b3R0LUIwNzQyMQ0KPiBTdWJqZWN0OiBSZTogW1BBVENIIDIvMiB2Ml0gZVNESEM6IEZpeCBlcnJv
cnMgd2hlbiBib290aW5nIGtlcm5lbCB3aXRoIGZzbCBlc2RoYw0KPiANCj4gSGVsbG8sDQo+IA0K
PiBPbiBGcmksIEF1ZyAxMiwgMjAxMSBhdCAwOTo0NDoyNkFNICswMDAwLCBaYW5nIFJveS1SNjE5
MTEgd3JvdGU6DQo+IFsuLi5dDQo+ID4gPiBXZSB0cnkgdG8gbm90IHBvbGx1dGUgZ2VuZXJpYyBz
ZGhjaS5jIGRyaXZlciB3aXRoIGNoaXAtc3BlY2lmaWMNCj4gPiA+IHF1aXJrcy4NCj4gPiA+DQo+
ID4gPiBNYXliZSB5b3UgY2FuIGRvIHRoZSBmaXh1cHMgdmlhIElPIGFjY2Vzc29ycz8gT3IgYnkg
aW50cm9kdWNpbmcNCj4gPiA+IHNvbWUgYWRkaXRpb25hbCBzZGhjaSBvcD8NCj4gPiBBbnRvbiwN
Cj4gPiB0aGFua3MgZm9yIHRoZSBjb21tZW50LCBhcyB3ZSBkaXNjdXNzZWQsIHRoZSBvcmlnaW5h
bCBjb2RlIHVzZSA4IGJpdCBieXRlDQo+IG9wZXJhdGlvbiwNCj4gPiB3aGlsZSBpbiBmYWN0LCBv
biBzb21lIHBvd2VycGMgcGxhdGZvcm0sIDMyIGJpdCBvcGVyYXRpb24gaXMgbmVlZGVkLg0KPiA+
IHNob3VsZCBpdCBiZSBwb3NzaWJsZSBmaXhlZCBieSBhZGRpbmcgc29tZSB3cmFwcGVyIGluIElP
IGFjY2Vzc29ycyBvcg0KPiBpbnRyb2R1Y2UgYWRkaXRpb25hbCBzZGhjaSBvcD8NCj4gDQo+IEkg
d291bGQgZG8gaXQgaW4gdGhlIElPIGFjY2Vzc29ycy4NCkkgbWF5IG1pc3MgeW91ciBlbWFpbC4g
SSBuZXZlciBzZWUgeW91ciBwYXRjaCBhYm91dCAiIEkgd291bGQgZG8gaXQgaW4gdGhlIElPIGFj
Y2Vzc29ycyAiLg0KVGhhbmtzLg0KUm95DQoNCg==
^ permalink raw reply
* [PATCH 1/3 v2] mmc: Move mmc_delay() to include/linux/mmc/core.h
From: Chunhe Lan @ 2011-08-26 7:52 UTC (permalink / raw)
To: linux-mmc; +Cc: kumar.gala, Chris Ball, linuxppc-dev, Chunhe Lan
Move mmc_delay() from drivers/mmc/core/core.h to
include/linux/mmc/core.h. So when other functions
call it with include syntax using <linux/mmc/core.h>
of absolute path rather than "../core/core.h" of
relative path.
Signed-off-by: Chunhe Lan <Chunhe.Lan@freescale.com>
Cc: Chris Ball <cjb@laptop.org>
---
drivers/mmc/core/core.h | 12 ------------
include/linux/mmc/core.h | 11 +++++++++++
2 files changed, 11 insertions(+), 12 deletions(-)
diff --git a/drivers/mmc/core/core.h b/drivers/mmc/core/core.h
index d9411ed..58c3f10 100644
--- a/drivers/mmc/core/core.h
+++ b/drivers/mmc/core/core.h
@@ -11,8 +11,6 @@
#ifndef _MMC_CORE_CORE_H
#define _MMC_CORE_CORE_H
-#include <linux/delay.h>
-
#define MMC_CMD_RETRIES 3
struct mmc_bus_ops {
@@ -44,16 +42,6 @@ int mmc_set_signal_voltage(struct mmc_host *host, int signal_voltage,
void mmc_set_timing(struct mmc_host *host, unsigned int timing);
void mmc_set_driver_type(struct mmc_host *host, unsigned int drv_type);
-static inline void mmc_delay(unsigned int ms)
-{
- if (ms < 1000 / HZ) {
- cond_resched();
- mdelay(ms);
- } else {
- msleep(ms);
- }
-}
-
void mmc_rescan(struct work_struct *work);
void mmc_start_host(struct mmc_host *host);
void mmc_stop_host(struct mmc_host *host);
diff --git a/include/linux/mmc/core.h b/include/linux/mmc/core.h
index b8b1b7a..7bc2798 100644
--- a/include/linux/mmc/core.h
+++ b/include/linux/mmc/core.h
@@ -10,6 +10,7 @@
#include <linux/interrupt.h>
#include <linux/device.h>
+#include <linux/delay.h>
struct request;
struct mmc_data;
@@ -182,6 +183,16 @@ static inline void mmc_claim_host(struct mmc_host *host)
__mmc_claim_host(host, NULL);
}
+static inline void mmc_delay(unsigned int ms)
+{
+ if (ms < 1000 / HZ) {
+ cond_resched();
+ mdelay(ms);
+ } else {
+ msleep(ms);
+ }
+}
+
extern u32 mmc_vddrange_to_ocrmask(int vdd_min, int vdd_max);
#endif /* LINUX_MMC_CORE_H */
--
1.7.5.1
^ permalink raw reply related
* [PATCH 2/3 v2] mmc: Use mmc_delay() instead of mdelay() for time delay
From: Chunhe Lan @ 2011-08-26 7:54 UTC (permalink / raw)
To: linux-mmc; +Cc: Shengzhou Liu, kumar.gala, Chris Ball, linuxppc-dev, Chunhe Lan
The mmc_delay() is a wrapper function for mdelay() and msleep().
o mdelay() -- block the system when busy-waiting.
o msleep() -- suspend the currently running task to enable CPU
to process other tasks, so it is non-blocking
regarding the whole system.
When the desired delay time is more than a period of timer interrupt,
just use msleep(). Change mdelay() to mmc_delay() to avoid chewing
CPU when busy wait.
Signed-off-by: Shengzhou Liu <b36685@freescale.com>
Signed-off-by: Chunhe Lan <Chunhe.Lan@freescale.com>
Cc: Chris Ball <cjb@laptop.org>
---
drivers/mmc/host/sdhci-esdhc.h | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/sdhci-esdhc.h b/drivers/mmc/host/sdhci-esdhc.h
index c3b08f1..b8c0ab1 100644
--- a/drivers/mmc/host/sdhci-esdhc.h
+++ b/drivers/mmc/host/sdhci-esdhc.h
@@ -1,7 +1,7 @@
/*
* Freescale eSDHC controller driver generics for OF and pltfm.
*
- * Copyright (c) 2007 Freescale Semiconductor, Inc.
+ * Copyright (c) 2007, 2011 Freescale Semiconductor, Inc.
* Copyright (c) 2009 MontaVista Software, Inc.
* Copyright (c) 2010 Pengutronix e.K.
* Author: Wolfram Sang <w.sang@pengutronix.de>
@@ -73,7 +73,7 @@ static inline void esdhc_set_clock(struct sdhci_host *host, unsigned int clock)
| (div << ESDHC_DIVIDER_SHIFT)
| (pre_div << ESDHC_PREDIV_SHIFT));
sdhci_writel(host, temp, ESDHC_SYSTEM_CONTROL);
- mdelay(100);
+ mmc_delay(100);
out:
host->clock = clock;
}
--
1.7.5.1
^ permalink raw reply related
* [PATCH 3/3 v2] mmc: Use mmc_delay() instead of mdelay() for time delay
From: Chunhe Lan @ 2011-08-26 7:55 UTC (permalink / raw)
To: linux-mmc; +Cc: Shengzhou Liu, kumar.gala, Chris Ball, linuxppc-dev, Chunhe Lan
The mmc_delay() is a wrapper function for mdelay() and msleep().
o mdelay() -- block the system when busy-waiting.
o msleep() -- suspend the currently running task to enable CPU
to process other tasks, so it is non-blocking
regarding the whole system.
When the desired delay time is more than a period of timer interrupt,
just use msleep(). Change mdelay() to mmc_delay() to avoid chewing
CPU when busy wait.
Signed-off-by: Shengzhou Liu <b36685@freescale.com>
Signed-off-by: Chunhe Lan <Chunhe.Lan@freescale.com>
Cc: Chris Ball <cjb@laptop.org>
---
drivers/mmc/host/sdhci.c | 10 +++++-----
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 0e02cc1..b0cf79f 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -186,7 +186,7 @@ static void sdhci_reset(struct sdhci_host *host, u8 mask)
return;
}
timeout--;
- mdelay(1);
+ mmc_delay(1);
}
if (host->ops->platform_reset_exit)
@@ -957,7 +957,7 @@ static void sdhci_send_command(struct sdhci_host *host, struct mmc_command *cmd)
return;
}
timeout--;
- mdelay(1);
+ mmc_delay(1);
}
mod_timer(&host->timer, jiffies + 10 * HZ);
@@ -1127,7 +1127,7 @@ static void sdhci_set_clock(struct sdhci_host *host, unsigned int clock)
return;
}
timeout--;
- mdelay(1);
+ mmc_delay(1);
}
clk |= SDHCI_CLOCK_CARD_EN;
@@ -1192,7 +1192,7 @@ static void sdhci_set_power(struct sdhci_host *host, unsigned short power)
* can apply clock after applying power
*/
if (host->quirks & SDHCI_QUIRK_DELAY_AFTER_POWER)
- mdelay(10);
+ mmc_delay(10);
}
/*****************************************************************************\
@@ -1712,7 +1712,7 @@ static int sdhci_execute_tuning(struct mmc_host *mmc)
ctrl = sdhci_readw(host, SDHCI_HOST_CONTROL2);
tuning_loop_counter--;
timeout--;
- mdelay(1);
+ mmc_delay(1);
} while (ctrl & SDHCI_CTRL_EXEC_TUNING);
/*
--
1.7.5.1
^ permalink raw reply related
* Re: kvm PCI assignment & VFIO ramblings
From: Roedel, Joerg @ 2011-08-26 9:24 UTC (permalink / raw)
To: Alexander Graf, Alexey Kardashevskiy, kvm@vger.kernel.org,
Paul Mackerras, qemu-devel, iommu, chrisw, Alex Williamson,
Avi Kivity, Anthony Liguori, linux-pci@vger.kernel.org,
linuxppc-dev, benve@cisco.com
In-Reply-To: <20110826042423.GF2308@yookeroo.fritz.box>
On Fri, Aug 26, 2011 at 12:24:23AM -0400, David Gibson wrote:
> On Thu, Aug 25, 2011 at 08:25:45AM -0500, Alexander Graf wrote:
> > On 25.08.2011, at 07:31, Roedel, Joerg wrote:
> > > For mmio we could stop the guest and replace the mmio region with a
> > > region that is filled with 0xff, no?
> >
> > Sure, but that happens in user space. The question is how does
> > kernel space enforce an MMIO region to not be mapped after the
> > hotplug event occured? Keep in mind that user space is pretty much
> > untrusted here - it doesn't have to be QEMU. It could just as well
> > be a generic user space driver. And that can just ignore hotplug
> > events.
>
> We're saying you hard yank the mapping from the userspace process.
> That is, you invalidate all its PTEs mapping the MMIO space, and don't
> let it fault them back in.
>
> As I see it there are two options: (a) make subsequent accesses from
> userspace or the guest result in either a SIGBUS that userspace must
> either deal with or die, or (b) replace the mapping with a dummy RO
> mapping containing 0xff, with any trapped writes emulated as nops.
The biggest problem with this approach is that it has to happen in the
context of the given process. Linux can't really modify an mm which
which belong to another context in a safe way.
The more I think about this, I come to the conclusion that it would be
the best to just kill the process accessing the device if it is manually
de-assigned from vfio. It should be a non-standard path anyway so it
doesn't make a lot of sense to implement complicated handling semantics
for it, no?
Joerg
--
AMD Operating System Research Center
Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach
General Managers: Alberto Bozzo, Andrew Bowd
Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632
^ permalink raw reply
* Re: kvm PCI assignment & VFIO ramblings
From: Roedel, Joerg @ 2011-08-26 9:33 UTC (permalink / raw)
To: aafabbri, Alexey Kardashevskiy, kvm@vger.kernel.org,
Paul Mackerras, linux-pci@vger.kernel.org, qemu-devel, chrisw,
iommu, Avi Kivity, Anthony Liguori, linuxppc-dev, benve@cisco.com
In-Reply-To: <20110826042000.GE2308@yookeroo.fritz.box>
On Fri, Aug 26, 2011 at 12:20:00AM -0400, David Gibson wrote:
> On Wed, Aug 24, 2011 at 01:03:32PM +0200, Roedel, Joerg wrote:
> > On Wed, Aug 24, 2011 at 05:33:00AM -0400, David Gibson wrote:
> > > On Wed, Aug 24, 2011 at 11:14:26AM +0200, Roedel, Joerg wrote:
> >
> > > > I don't see a reason to make this meta-grouping static. It would harm
> > > > flexibility on x86. I think it makes things easier on power but there
> > > > are options on that platform to get the dynamic solution too.
> > >
> > > I think several people are misreading what Ben means by "static". I
> > > would prefer to say 'persistent', in that the meta-groups lifetime is
> > > not tied to an fd, but they can be freely created, altered and removed
> > > during runtime.
> >
> > Even if it can be altered at runtime, from a usability perspective it is
> > certainly the best to handle these groups directly in qemu. Or are there
> > strong reasons to do it somewhere else?
>
> Funny, Ben and I think usability demands it be the other way around.
The reason is that you mean the usability for the programmer and I mean
it for the actual user of qemu :)
> If the meta-groups are transient - that is lifetime tied to an fd -
> then any program that wants to use meta-groups *must* know the
> interfaces for creating one, whatever they are.
>
> But if they're persistent, the admin can use other tools to create the
> meta-group then just hand it to a program to use, since the interfaces
> for _using_ a meta-group are identical to those for an atomic group.
>
> This doesn't preclude a program from being meta-group aware, and
> creating its own if it wants to, of course. My guess is that qemu
> would not want to build its own meta-groups, but libvirt probably
> would.
Doing it in libvirt makes it really hard for a plain user of qemu to
assign more than one device to a guest. What I want it that a user just
types
qemu -device vfio,host=00:01.0 -device vfio,host=00:02.0 ...
and it just works. Qemu creates the meta-groups and they are
automatically destroyed when qemu exits. That the programs are not aware
of meta-groups is not a big problem because all software using vfio
needs still to be written :)
Btw, with this concept the programmer can still decide to not use
meta-groups and just multiplex the mappings to all open device-fds it
uses.
Joerg
--
AMD Operating System Research Center
Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach
General Managers: Alberto Bozzo, Andrew Bowd
Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632
^ permalink raw reply
* Re: [PATCH 1/2] [hw-breakpoint] Use generic hw-breakpoint interfaces for new PPC ptrace flags
From: K.Prasad @ 2011-08-26 9:35 UTC (permalink / raw)
To: linuxppc-dev, Thiago Jung Bauermann, Edjunior Barbosa Machado
In-Reply-To: <20110824035939.GB30097@yookeroo.fritz.box>
On Wed, Aug 24, 2011 at 01:59:39PM +1000, David Gibson wrote:
> On Tue, Aug 23, 2011 at 02:55:13PM +0530, K.Prasad wrote:
> > On Tue, Aug 23, 2011 at 03:08:50PM +1000, David Gibson wrote:
> > > On Fri, Aug 19, 2011 at 01:21:36PM +0530, K.Prasad wrote:
> > > > PPC_PTRACE_GETHWDBGINFO, PPC_PTRACE_SETHWDEBUG and PPC_PTRACE_DELHWDEBUG are
> > > > PowerPC specific ptrace flags that use the watchpoint register. While they are
> > > > targeted primarily towards BookE users, user-space applications such as GDB
> > > > have started using them for BookS too.
> > > >
> > > > This patch enables the use of generic hardware breakpoint interfaces for these
> > > > new flags. The version number of the associated data structures
> > > > "ppc_hw_breakpoint" and "ppc_debug_info" is incremented to denote new semantics.
> > >
> > > So, the structure itself doesn't seem to have been extended. I don't
> > > understand what the semantic difference is - your patch comment needs
> > > to explain this clearly.
> > >
> >
> > We had a request to extend the structure but thought it was dangerous to
> > do so. For instance if the user-space used version1 of the structure,
> > while kernel did a copy_to_user() pertaining to version2, then we'd run
> > into problems. Unfortunately the ptrace flags weren't designed to accept
> > a version number as input from the user through the
> > PPC_PTRACE_GETHWDBGINFO flag (which would have solved this issue).
>
> I still don't follow you.
>
Two things here.
One, the change of semantics warranted an increment of the version
number. The new semantics accepts PPC_BREAKPOINT_MODE_RANGE_INCLUSIVE on
BookS, while the old version number did not. I've added a small comment
in the code to this effect.
Two, regarding changes in the "ppc_hw_breakpoint" and "ppc_debug_info"
structures - we would like to add more members to it if we can (GDB has a
pending request to add more members to it). However the problem foreseen
is that there could be a mismatch between the versions of the structure
used by the user vs kernel-space i.e. if a new version of the structure,
known to the kernel, had an extra member while the user-space still had
the old version, then it becomes dangerous because the __copy_to_user
function would overflow the buffer size in user-space.
This could have been avoided if PPC_PTRACE_GETHWDBGINFO was originally
designed to accept a version number (and provide corresponding
"struct ppc_debug_info") rather than send a populated "ppc_debug_info"
structure along with the version number.
> > I'll add a comment w.r.t change in semantics - such as the ability to
> > accept 'range' breakpoints in BookS.
> >
> > > > Apart from the usual benefits of using generic hw-breakpoint interfaces, these
> > > > changes allow debuggers (such as GDB) to use a common set of ptrace flags for
> > > > their watchpoint needs and allow more precise breakpoint specification (length
> > > > of the variable can be specified).
> > >
> > > What is the mechanism for implementing the range breakpoint on book3s?
> > >
> >
> > The hw-breakpoint interface, accepts length as an argument in BookS (any
> > value <= 8 Bytes) and would filter out extraneous interrupts arising out
> > of accesses outside the range comprising <addr, addr + len> inside
> > hw_breakpoint_handler function.
> >
> > We put that ability to use here.
>
> Ah, so in hardware the breakpoints are always 8 bytes long, but you
> filter out false hits on a shorter range? Of course, the utility of
> range breakpoints is questionable when length <=8, but the start must
> be aligned on an 8-byte boundary.
>
Yes, we ensure that through
+ attr.bp_addr = (unsigned long)bp_info->addr & ~HW_BREAKPOINT_ALIGN;
> [snip]
> > > > if ((unsigned long)bp_info->addr >= TASK_SIZE)
> > > > return -EIO;
> > > >
> > > > @@ -1398,15 +1400,86 @@ static long ppc_set_hwdebug(struct task_struct *child,
> > > > dabr |= DABR_DATA_READ;
> > > > if (bp_info->trigger_type & PPC_BREAKPOINT_TRIGGER_WRITE)
> > > > dabr |= DABR_DATA_WRITE;
> > > > +#ifdef CONFIG_HAVE_HW_BREAKPOINT
> > > > + if (bp_info->version == 1)
> > > > + goto version_one;
> > >
> > > There are several legitimate uses of goto in the kernel, but this is
> > > definitely not one of them. You're essentially using it to put the
> > > old and new versions of the same function in one block. Nasty.
> > >
> >
> > Maybe it's the label that's causing bother here. It might look elegant
> > if it was called something like exit_* or error_* :-)
> >
> > The goto here helps reduce code, is similar to the error exits we use
> > everywhere.
>
> Rubbish, it is not an exception exit at all, it is two separate code
> paths for the different versions which would be much clearer as two
> different functions.
>
I've re-written this part of the code to avoid a goto statement.
> > > > + if (ptrace_get_breakpoints(child) < 0)
> > > > + return -ESRCH;
> > > >
> > > > - child->thread.dabr = dabr;
> > > > + bp = thread->ptrace_bps[0];
> > > > + if (!bp_info->addr) {
> > > > + if (bp) {
> > > > + unregister_hw_breakpoint(bp);
> > > > + thread->ptrace_bps[0] = NULL;
> > > > + }
> > > > + ptrace_put_breakpoints(child);
> > > > + return 0;
> > >
> > > Why are you making setting a 0 watchpoint remove the existing one (I
> > > think that's what this does). I thought there was an explicit del
> > > breakpoint operation instead.
> >
> > We had to define the semantics for what writing a 0 to DABR could mean,
> > and I think it is intuitive to consider it as deletion
> > request...couldn't think of a case where DABR with addr=0 and RW=1 would
> > be required.
>
> When a user space program maps pages at virtual address 0, which it
> can do.
>
Agreed. I've removed the code under if (!bp_info->addr) branch.
> > > > + }
> > > > + /*
> > > > + * Check if the request is for 'range' breakpoints. We can
> > > > + * support it if range < 8 bytes.
> > > > + */
> > > > + if (bp_info->addr_mode == PPC_BREAKPOINT_MODE_RANGE_INCLUSIVE)
> > > > + len = bp_info->addr2 - bp_info->addr;
> > >
> > > So you compute the length here, but I don't see you ever test if it is
> > > < 8 and return an error.
> > >
> >
> > The hw-breakpoint interfaces would fail if the length was > 8.
>
> Ok.
>
> > > > + else if (bp_info->addr_mode != PPC_BREAKPOINT_MODE_EXACT) {
> > > > + ptrace_put_breakpoints(child);
> > > > + return -EINVAL;
> > > > + }
> > > > + if (bp) {
> > > > + attr = bp->attr;
> > > > + attr.bp_addr = (unsigned long)bp_info->addr & ~HW_BREAKPOINT_ALIGN;
> > > > + arch_bp_generic_fields(dabr &
> > > > + (DABR_DATA_WRITE | DABR_DATA_READ),
> > > > + &attr.bp_type);
> > > > + attr.bp_len = len;
> > > > + ret = modify_user_hw_breakpoint(bp, &attr);
> > > > + if (ret) {
> > > > + ptrace_put_breakpoints(child);
> > > > + return ret;
> > > > + }
> > > > + thread->ptrace_bps[0] = bp;
> > > > + ptrace_put_breakpoints(child);
> > > > + thread->dabr = dabr;
> > > > + return 0;
> > > > + }
> > > >
> > > > + /* Create a new breakpoint request if one doesn't exist already */
> > > > + hw_breakpoint_init(&attr);
> > > > + attr.bp_addr = (unsigned long)bp_info->addr & ~HW_BREAKPOINT_ALIGN;
> > >
> > > You seem to be silently masking the given address, which seems
> > > completely wrong.
> > >
> >
> > We have two ways of looking at the input address.
> > a) Assume that the input address is not multiplexed with the read/write
> > bits and return -EINVAL (for not confirming to the 8-byte alignment
> > requirement).
> > b) Consider the input address to be encoded with the read/write
> > watchpoint type request and align the address by default. This is how
> > the code behaves presently for the !CONFIG_HAVE_HW_BREAKPOINT case.
>
> Hrm, ok, but this needs commenting.
>
Added a comment to this effect.
I'm pasting the modified patch below. Kindly let me know your comments.
PPC_PTRACE_GETHWDBGINFO, PPC_PTRACE_SETHWDEBUG and PPC_PTRACE_DELHWDEBUG are
PowerPC specific ptrace flags that use the watchpoint register. While they are
targeted primarily towards BookE users, user-space applications such as GDB
have started using them for BookS too.
This patch enables the use of generic hardware breakpoint interfaces for these
new flags. The version number of the associated data structures
"ppc_hw_breakpoint" and "ppc_debug_info" is incremented to denote new semantics.
Apart from the usual benefits of using generic hw-breakpoint interfaces, these
changes allow debuggers (such as GDB) to use a common set of ptrace flags for
their watchpoint needs and allow more precise breakpoint specification (length
of the variable can be specified).
[Edjunior: Identified an issue in the patch with the sanity check for version
numbers]
diff --git a/Documentation/powerpc/ptrace.txt b/Documentation/powerpc/ptrace.txt
index f4a5499..97301ae 100644
--- a/Documentation/powerpc/ptrace.txt
+++ b/Documentation/powerpc/ptrace.txt
@@ -127,6 +127,22 @@ Some examples of using the structure to:
p.addr2 = (uint64_t) end_range;
p.condition_value = 0;
+- set a watchpoint in server processors (BookS) using version 2
+
+ p.version = 2;
+ p.trigger_type = PPC_BREAKPOINT_TRIGGER_RW;
+ p.addr_mode = PPC_BREAKPOINT_MODE_RANGE_INCLUSIVE;
+ or
+ p.addr_mode = PPC_BREAKPOINT_MODE_RANGE_EXACT;
+
+ p.condition_mode = PPC_BREAKPOINT_CONDITION_NONE;
+ p.addr = (uint64_t) begin_range;
+ /* For PPC_BREAKPOINT_MODE_RANGE_INCLUSIVE addr2 needs to be specified, where
+ * addr2 - addr <= 8 Bytes.
+ */
+ p.addr2 = (uint64_t) end_range;
+ p.condition_value = 0;
+
3. PTRACE_DELHWDEBUG
Takes an integer which identifies an existing breakpoint or watchpoint
diff --git a/arch/powerpc/kernel/ptrace.c b/arch/powerpc/kernel/ptrace.c
index 05b7dd2..f9a4548 100644
--- a/arch/powerpc/kernel/ptrace.c
+++ b/arch/powerpc/kernel/ptrace.c
@@ -1339,11 +1339,17 @@ static int set_dac_range(struct task_struct *child,
static long ppc_set_hwdebug(struct task_struct *child,
struct ppc_hw_breakpoint *bp_info)
{
+#ifdef CONFIG_HAVE_HW_BREAKPOINT
+ int ret, len = 0;
+ struct thread_struct *thread = &(child->thread);
+ struct perf_event *bp;
+ struct perf_event_attr attr;
+#endif /* CONFIG_HAVE_HW_BREAKPOINT */
#ifndef CONFIG_PPC_ADV_DEBUG_REGS
unsigned long dabr;
#endif
- if (bp_info->version != 1)
+ if ((bp_info->version != 1) && (bp_info->version != 2))
return -ENOTSUPP;
#ifdef CONFIG_PPC_ADV_DEBUG_REGS
/*
@@ -1382,13 +1388,9 @@ static long ppc_set_hwdebug(struct task_struct *child,
*/
if ((bp_info->trigger_type & PPC_BREAKPOINT_TRIGGER_RW) == 0 ||
(bp_info->trigger_type & ~PPC_BREAKPOINT_TRIGGER_RW) != 0 ||
- bp_info->addr_mode != PPC_BREAKPOINT_MODE_EXACT ||
bp_info->condition_mode != PPC_BREAKPOINT_CONDITION_NONE)
return -EINVAL;
- if (child->thread.dabr)
- return -ENOSPC;
-
if ((unsigned long)bp_info->addr >= TASK_SIZE)
return -EIO;
@@ -1399,14 +1401,84 @@ static long ppc_set_hwdebug(struct task_struct *child,
if (bp_info->trigger_type & PPC_BREAKPOINT_TRIGGER_WRITE)
dabr |= DABR_DATA_WRITE;
- child->thread.dabr = dabr;
+ if (bp_info->version == 1) {
+ if (bp_info->addr_mode != PPC_BREAKPOINT_MODE_EXACT)
+ return -EINVAL;
+ if (child->thread.dabr)
+ return -ENOSPC;
+ child->thread.dabr = dabr;
+ return 1;
+ }
+#ifdef CONFIG_HAVE_HW_BREAKPOINT
+ /*
+ * We will use version = 2, to denote the use of
+ * PPC_BREAKPOINT_MODE_RANGE_INCLUSIVE mode of watchpoints.
+ */
+ if (bp_info->version != 2)
+ return -EINVAL;
+ if (ptrace_get_breakpoints(child) < 0)
+ return -ESRCH;
+ bp = thread->ptrace_bps[0];
+ /*
+ * Check if the request is for 'range' breakpoints. We can
+ * support it if range < 8 bytes.
+ */
+ if (bp_info->addr_mode == PPC_BREAKPOINT_MODE_RANGE_INCLUSIVE)
+ len = bp_info->addr2 - bp_info->addr;
+ else if (bp_info->addr_mode != PPC_BREAKPOINT_MODE_EXACT) {
+ ptrace_put_breakpoints(child);
+ return -EINVAL;
+ }
+ if (bp) {
+ attr = bp->attr;
+ /*
+ * Consider the input address to be encoded with the read/write
+ * watchpoint type request and align the address by default.
+ */
+ attr.bp_addr = (unsigned long)bp_info->addr & ~HW_BREAKPOINT_ALIGN;
+ arch_bp_generic_fields(dabr &
+ (DABR_DATA_WRITE | DABR_DATA_READ),
+ &attr.bp_type);
+ attr.bp_len = len;
+ ret = modify_user_hw_breakpoint(bp, &attr);
+ if (ret) {
+ ptrace_put_breakpoints(child);
+ return ret;
+ }
+ thread->ptrace_bps[0] = bp;
+ ptrace_put_breakpoints(child);
+ thread->dabr = dabr;
+ return 0;
+ }
+
+ /* Create a new breakpoint request if one doesn't exist already */
+ hw_breakpoint_init(&attr);
+ attr.bp_addr = (unsigned long)bp_info->addr & ~HW_BREAKPOINT_ALIGN;
+ attr.bp_len = len;
+ arch_bp_generic_fields(dabr & (DABR_DATA_WRITE | DABR_DATA_READ),
+ &attr.bp_type);
+
+ thread->ptrace_bps[0] = bp = register_user_hw_breakpoint(&attr,
+ ptrace_triggered, NULL, child);
+ if (IS_ERR(bp)) {
+ thread->ptrace_bps[0] = NULL;
+ ptrace_put_breakpoints(child);
+ return PTR_ERR(bp);
+ }
+
+ ptrace_put_breakpoints(child);
return 1;
+#endif /* CONFIG_HAVE_HW_BREAKPOINT */
#endif /* !CONFIG_PPC_ADV_DEBUG_DVCS */
}
static long ppc_del_hwdebug(struct task_struct *child, long addr, long data)
{
+#ifdef CONFIG_HAVE_HW_BREAKPOINT
+ struct thread_struct *thread = &(child->thread);
+ struct perf_event *bp;
+#endif /* CONFIG_HAVE_HW_BREAKPOINT */
#ifdef CONFIG_PPC_ADV_DEBUG_REGS
int rc;
@@ -1426,10 +1498,24 @@ static long ppc_del_hwdebug(struct task_struct *child, long addr, long data)
#else
if (data != 1)
return -EINVAL;
+
+#ifdef CONFIG_HAVE_HW_BREAKPOINT
+ if (ptrace_get_breakpoints(child) < 0)
+ return -ESRCH;
+
+ bp = thread->ptrace_bps[0];
+ if (bp) {
+ unregister_hw_breakpoint(bp);
+ thread->ptrace_bps[0] = NULL;
+ }
+ ptrace_put_breakpoints(child);
+ return 0;
+#else /* CONFIG_HAVE_HW_BREAKPOINT */
if (child->thread.dabr == 0)
return -ENOENT;
child->thread.dabr = 0;
+#endif /* CONFIG_HAVE_HW_BREAKPOINT */
return 0;
#endif
@@ -1536,7 +1622,8 @@ long arch_ptrace(struct task_struct *child, long request,
case PPC_PTRACE_GETHWDBGINFO: {
struct ppc_debug_info dbginfo;
- dbginfo.version = 1;
+ /* We return the highest version number supported */
+ dbginfo.version = 2;
#ifdef CONFIG_PPC_ADV_DEBUG_REGS
dbginfo.num_instruction_bps = CONFIG_PPC_ADV_DEBUG_IACS;
dbginfo.num_data_bps = CONFIG_PPC_ADV_DEBUG_DACS;
@@ -1560,7 +1647,7 @@ long arch_ptrace(struct task_struct *child, long request,
dbginfo.data_bp_alignment = 4;
#endif
dbginfo.sizeof_condition = 0;
- dbginfo.features = 0;
+ dbginfo.features = PPC_DEBUG_FEATURE_DATA_BP_RANGE;
#endif /* CONFIG_PPC_ADV_DEBUG_REGS */
if (!access_ok(VERIFY_WRITE, datavp,
^ permalink raw reply related
* Re: kvm PCI assignment & VFIO ramblings
From: Alexander Graf @ 2011-08-26 14:07 UTC (permalink / raw)
To: Roedel, Joerg
Cc: chrisw, Alexey Kardashevskiy, kvm@vger.kernel.org, Paul Mackerras,
linux-pci@vger.kernel.org, qemu-devel, aafabbri, iommu,
Avi Kivity, Anthony Liguori, linuxppc-dev, benve@cisco.com
In-Reply-To: <20110826093356.GP1923@amd.com>
On 26.08.2011, at 04:33, Roedel, Joerg wrote:
> On Fri, Aug 26, 2011 at 12:20:00AM -0400, David Gibson wrote:
>> On Wed, Aug 24, 2011 at 01:03:32PM +0200, Roedel, Joerg wrote:
>>> On Wed, Aug 24, 2011 at 05:33:00AM -0400, David Gibson wrote:
>>>> On Wed, Aug 24, 2011 at 11:14:26AM +0200, Roedel, Joerg wrote:
>>>=20
>>>>> I don't see a reason to make this meta-grouping static. It would =
harm
>>>>> flexibility on x86. I think it makes things easier on power but =
there
>>>>> are options on that platform to get the dynamic solution too.
>>>>=20
>>>> I think several people are misreading what Ben means by "static". =
I
>>>> would prefer to say 'persistent', in that the meta-groups lifetime =
is
>>>> not tied to an fd, but they can be freely created, altered and =
removed
>>>> during runtime.
>>>=20
>>> Even if it can be altered at runtime, from a usability perspective =
it is
>>> certainly the best to handle these groups directly in qemu. Or are =
there
>>> strong reasons to do it somewhere else?
>>=20
>> Funny, Ben and I think usability demands it be the other way around.
>=20
> The reason is that you mean the usability for the programmer and I =
mean
> it for the actual user of qemu :)
No, we mean the actual user of qemu. The reason being that making a =
device available for any user space application is an administrative =
task.
Forget the KVM case for a moment and think of a user space device =
driver. I as a user am not root. But I as a user when having access to =
/dev/vfioX want to be able to access the device and manage it - and only =
it. The admin of that box needs to set it up properly for me to be able =
to access it.
So having two steps is really the correct way to go:
* create VFIO group
* use VFIO group
because the two are done by completely different users. It's similar to =
how tun/tap works in Linux too. Of course nothing keeps you from also =
creating a group on the fly, but it shouldn't be the only interface =
available. The persistent setup is definitely more useful.
>=20
>> If the meta-groups are transient - that is lifetime tied to an fd -
>> then any program that wants to use meta-groups *must* know the
>> interfaces for creating one, whatever they are.
>>=20
>> But if they're persistent, the admin can use other tools to create =
the
>> meta-group then just hand it to a program to use, since the =
interfaces
>> for _using_ a meta-group are identical to those for an atomic group.
>>=20
>> This doesn't preclude a program from being meta-group aware, and
>> creating its own if it wants to, of course. My guess is that qemu
>> would not want to build its own meta-groups, but libvirt probably
>> would.
>=20
> Doing it in libvirt makes it really hard for a plain user of qemu to
> assign more than one device to a guest. What I want it that a user =
just
> types
>=20
> qemu -device vfio,host=3D00:01.0 -device vfio,host=3D00:02.0 ...
>=20
> and it just works. Qemu creates the meta-groups and they are
> automatically destroyed when qemu exits. That the programs are not =
aware
> of meta-groups is not a big problem because all software using vfio
> needs still to be written :)
>=20
> Btw, with this concept the programmer can still decide to not use
> meta-groups and just multiplex the mappings to all open device-fds it
> uses.
What I want to see is:
# vfio-create 00:01.0
/dev/vfio0
# vftio-create -a /dev/vfio0 00:02.0
/dev/vfio0
$ qemu -vfio dev=3D/dev/vfio0,id=3Dvfio0 -device vfio,vfio=3Dvfio0.0 =
-device vfio,vfio=3Dvfio0.1
Alex
^ permalink raw reply
* Re: kvm PCI assignment & VFIO ramblings
From: Joerg Roedel @ 2011-08-26 15:24 UTC (permalink / raw)
To: Alexander Graf
Cc: chrisw, Alexey Kardashevskiy, kvm@vger.kernel.org, Paul Mackerras,
Roedel, Joerg, qemu-devel, aafabbri, iommu, Avi Kivity,
Anthony Liguori, linux-pci@vger.kernel.org, linuxppc-dev,
benve@cisco.com
In-Reply-To: <571DC890-A1A3-4528-92BE-566F033FD4BF@suse.de>
On Fri, Aug 26, 2011 at 09:07:35AM -0500, Alexander Graf wrote:
> On 26.08.2011, at 04:33, Roedel, Joerg wrote:
> >
> > The reason is that you mean the usability for the programmer and I mean
> > it for the actual user of qemu :)
>
> No, we mean the actual user of qemu. The reason being that making a
> device available for any user space application is an administrative
> task.
>
> Forget the KVM case for a moment and think of a user space device
> driver. I as a user am not root. But I as a user when having access to
> /dev/vfioX want to be able to access the device and manage it - and
> only it. The admin of that box needs to set it up properly for me to
> be able to access it.
Right, and that task is being performed by attaching the device(s) in
question to the vfio driver. The rights-management happens on the
/dev/vfio/$group file.
> So having two steps is really the correct way to go:
>
> * create VFIO group
> * use VFIO group
>
> because the two are done by completely different users. It's similar
> to how tun/tap works in Linux too. Of course nothing keeps you from
> also creating a group on the fly, but it shouldn't be the only
> interface available. The persistent setup is definitely more useful.
I see the use-case. But to make it as easy as possible for the end-user
we can do both.
So the user of (qemu again) does this:
# vfio-ctl attach 00:01.0
vfio-ctl: attached to group 8
# vfio-ctl attach 00:02.0
vfio-ctl: attached to group 16
$ qemu -device vfio-pci,host=00:01.0 -device vfio,host=00:01.0 ...
which should cover the usecase you prefer. Qemu still creates the
meta-group that allow the devices to share the same page-table. But what
should also be possible is:
# qemu -device vfio-pci,host=00:01.0 -device vfio-pci,host=00:02.0
In that case qemu detects that the devices are not yet bound to vfio and
will do so and also unbinds them afterwards (essentially the developer
use-case).
Your interface which requires pre-binding of devices into one group by
the administrator only makes sense if you want to force userspace to
use certain devices (which do not belong to the same hw-group) only
together. But I don't see a usecase for defining such constraints (yet).
Joerg
^ permalink raw reply
* Re: kvm PCI assignment & VFIO ramblings
From: Alexander Graf @ 2011-08-26 15:29 UTC (permalink / raw)
To: Joerg Roedel
Cc: chrisw, Alexey Kardashevskiy, kvm@vger.kernel.org, Paul Mackerras,
Roedel, Joerg, qemu-devel, aafabbri, iommu, Avi Kivity,
Anthony Liguori, linux-pci@vger.kernel.org, linuxppc-dev,
benve@cisco.com
In-Reply-To: <20110826152404.GF8978@8bytes.org>
On 26.08.2011, at 10:24, Joerg Roedel wrote:
> On Fri, Aug 26, 2011 at 09:07:35AM -0500, Alexander Graf wrote:
>> On 26.08.2011, at 04:33, Roedel, Joerg wrote:
>>>=20
>>> The reason is that you mean the usability for the programmer and I =
mean
>>> it for the actual user of qemu :)
>>=20
>> No, we mean the actual user of qemu. The reason being that making a
>> device available for any user space application is an administrative
>> task.
>>=20
>> Forget the KVM case for a moment and think of a user space device
>> driver. I as a user am not root. But I as a user when having access =
to
>> /dev/vfioX want to be able to access the device and manage it - and
>> only it. The admin of that box needs to set it up properly for me to
>> be able to access it.
>=20
> Right, and that task is being performed by attaching the device(s) in
> question to the vfio driver. The rights-management happens on the
> /dev/vfio/$group file.
Yup :)
>=20
>> So having two steps is really the correct way to go:
>>=20
>> * create VFIO group
>> * use VFIO group
>>=20
>> because the two are done by completely different users. It's similar
>> to how tun/tap works in Linux too. Of course nothing keeps you from
>> also creating a group on the fly, but it shouldn't be the only
>> interface available. The persistent setup is definitely more useful.
>=20
> I see the use-case. But to make it as easy as possible for the =
end-user
> we can do both.
>=20
> So the user of (qemu again) does this:
>=20
> # vfio-ctl attach 00:01.0
> vfio-ctl: attached to group 8
> # vfio-ctl attach 00:02.0
> vfio-ctl: attached to group 16
> $ qemu -device vfio-pci,host=3D00:01.0 -device vfio,host=3D00:01.0 ...
>=20
> which should cover the usecase you prefer. Qemu still creates the
> meta-group that allow the devices to share the same page-table. But =
what
> should also be possible is:
>=20
> # qemu -device vfio-pci,host=3D00:01.0 -device vfio-pci,host=3D00:02.0
>=20
> In that case qemu detects that the devices are not yet bound to vfio =
and
> will do so and also unbinds them afterwards (essentially the developer
> use-case).
I agree. The same it works with tun today. You can either have qemu =
spawn a tun device dynamically or have a preallocated one you use. If =
you run qemu as a user (which I always do), I preallocate a tun device =
and attach qemu to it.
> Your interface which requires pre-binding of devices into one group by
> the administrator only makes sense if you want to force userspace to
> use certain devices (which do not belong to the same hw-group) only
> together. But I don't see a usecase for defining such constraints =
(yet).
Agreed. As long as the kernel backend can always figure out the =
hw-groups, we're good :)
Alex
^ permalink raw reply
* VFIO v2 design plan
From: Alex Williamson @ 2011-08-26 17:05 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: chrisw, Alexey Kardashevskiy, kvm, Paul Mackerras,
linux-pci@vger.kernel.org, agraf, qemu-devel, David Gibson,
aafabbri, iommu, Avi Kivity, Anthony Liguori, Roedel, Joerg,
linuxppc-dev, benve
I don't think too much has changed since the previous email went out,
but it seems like a good idea to post a summary in case there were
suggestions or objections that I missed.
VFIO v2 will rely on the platform iommu driver reporting grouping
information. Again, a group is a set of devices for which the iommu
cannot differentiate transactions. An example would be a set of devices
behind a PCI-to-PCI bridge. All transactions appear to be from the
bridge itself rather than devices behind the bridge. Platforms are free
to have whatever constraints they need to for what constitutes a group.
I posted a rough draft of patch to implement that for the base iommu
driver and VT-d, adding an iommu_device_group callback on iommu ops.
The iommu base driver also populates an iommu_group sysfs file for each
device that's part of a group. Members of the same group return the
same value via either the sysfs or iommu_device_group. The value
returned is arbitrary, should not be assumed to be persistent across
boots, and is left to the iommu driver to generate. There are some
implementation details around how to do this without favoring one bus
over another, but the interface should be bus/device type agnostic in
the end.
When the vfio module is loaded, character devices will be created for
each group in /dev/vfio/$GROUP. Setting file permissions on these files
should be sufficient for providing a user with complete access to the
group. Opening this device file provides what we'll call the "group
fd". The group fd is restricted to only work with a single mm context.
Concurrent opens will be denied if the opening process mm does not
match. The group fd will provide interfaces for enumerating the devices
in the group, returning a file descriptor for each device in the group
(the "device fd"), binding groups together, and returning a file
descriptor for iommu operations (the "iommu fd").
A group is "viable" when all member devices of the group are bound to
the vfio driver. Until that point, the group fd only allows enumeration
interfaces (ie. listing of group devices). I'm currently thinking
enumeration will be done by a simple read() on the device file returning
a list of dev_name()s. Once the group is viable, the user may bind the
group to another group, retrieve the iommu fd, or retrieve device fds.
Internally, each of these operations will result in an iommu domain
being allocated and all of the devices attached to the domain.
The purpose of binding groups is to share the iommu domain. Groups
making use of incompatible iommu domains will fail to bind. Groups
making use of different mm's will fail to bind. The vfio driver may
reject some binding based on domain capabilities, but final veto power
is left to the iommu driver[1]. If a user makes use of a group
independently and later wishes to bind it to another group, all the
device fds and the iommu fd must first be closed. This prevents using a
stale iommu fd or accessing devices while the iommu is being switched.
Operations on any group fds of a merged group are performed globally on
the group (ie. enumerating the devices lists all devices in the merged
group, retrieving the iommu fd from any group fd results in the same fd,
device fds from any group can be retrieved from any group fd[2]).
Groups can be merged and unmerged dynamically. Unmerging a group
requires the device fds for the outgoing group are closed. The iommu fd
will remain persistent for the remaining merged group.
If a device within a group is unbound from the vfio driver while it's in
use (iommu fd refcnt > 0 || device fd recnt > 0), vfio will block the
release and send netlink remove requests for every opened device in the
group (or merged group). If the device fds are not released and
subsequently the iommu fd released as well, vfio will kill the user
process after some delay. At some point in the future we may be able to
adapt this to perform a hard removal and revoke all device access
without killing the user.
The iommu fd supports dma mapping and unmapping ioctls as well as some,
yet to be defined and possibly architecture specific, iommu description
interfaces. At some point we may also make use of read/write/mmap on
the iommu fd as means to setup dma.
The device fds will largely support the existing vfio interface, with
generalizations to make it non-pci specific. We'll access mmio/pio/pci
config using segmented offset into the device fd. Interrupts will use
the existing mechanisms (eventfds/irqfd). We'll need to add ioctls to
describe the type of device, number, size, and type of each resource and
available interrupts.
We still have outstanding questions with how devices are exposed in
qemu, but I think that's largely a qemu-vfio problem and the vfio kernel
interface described here supports all the interesting ways that devices
can be exposed as individuals or sets. I'm currently working on code
changes to support the above and will post as I complete useful chunks.
Thanks,
Alex
[1] Implementation note: the current iommu ops makes some of this
awkward. We'll need to temporarily setup a domain for incoming devices
to validate the capabilities of that domain, then tear it down and try
to attach devices to the existing domain. In particular I'm thinking of
the cache coherence capability and whether we remap existing dma
mappings to allow this to change or just reject as incompatible (I'm
leaning to the latter).
[2] Implementation note: I think a container object makes sense here
where reads/ioctls are passed from the group to the container, which
performs them across all groups making use of that container (there are
no performance critical paths through the group fd). This also implies
the enumeration interface should report groups so we can easily see
which groups are merged. The group fd could simply read as:
group: 1234
device: 0000:00:19.0
group: 5678
device: 0000:01:00.0
device: 0000:01:00.1
Some might say this is screaming for xml. Do we need to go there? We
could also do this via the netlink interface. Suggestions welcome.
^ permalink raw reply
* Re: kvm PCI assignment & VFIO ramblings
From: Aaron Fabbri @ 2011-08-26 17:52 UTC (permalink / raw)
To: Alexander Graf, Roedel, Joerg
Cc: Alexey Kardashevskiy, kvm@vger.kernel.org, Paul Mackerras,
linux-pci@vger.kernel.org, qemu-devel, chrisw, iommu, Avi Kivity,
Anthony Liguori, linuxppc-dev, benve@cisco.com
In-Reply-To: <571DC890-A1A3-4528-92BE-566F033FD4BF@suse.de>
On 8/26/11 7:07 AM, "Alexander Graf" <agraf@suse.de> wrote:
>
<snip>
>
> Forget the KVM case for a moment and think of a user space device driver. I as
> a user am not root. But I as a user when having access to /dev/vfioX want to
> be able to access the device and manage it - and only it. The admin of that
> box needs to set it up properly for me to be able to access it.
>
> So having two steps is really the correct way to go:
>
> * create VFIO group
> * use VFIO group
>
> because the two are done by completely different users.
This is not the case for my userspace drivers using VFIO today.
Each process will open vfio devices on the fly, and they need to be able to
share IOMMU resources.
So I need the ability to dynamically bring up devices and assign them to a
group. The number of actual devices and how they map to iommu domains is
not known ahead of time. We have a single piece of silicon that can expose
hundreds of pci devices.
In my case, the only administrative task would be to give my processes/users
access to the vfio groups (which are initially singletons), and the
application actually opens them and needs the ability to merge groups
together to conserve IOMMU resources (assuming we're not going to expose
uiommu).
-Aaron
^ permalink raw reply
* Re: kvm PCI assignment & VFIO ramblings
From: Alex Williamson @ 2011-08-26 18:04 UTC (permalink / raw)
To: Joerg Roedel
Cc: chrisw, Alexey Kardashevskiy, kvm@vger.kernel.org, Paul Mackerras,
Roedel, Joerg, linux-pci@vger.kernel.org, qemu-devel,
Aaron Fabbri, iommu, Avi Kivity, Anthony Liguori, linuxppc-dev,
benve@cisco.com
In-Reply-To: <20110825180557.GD8978@8bytes.org>
On Thu, 2011-08-25 at 20:05 +0200, Joerg Roedel wrote:
> On Thu, Aug 25, 2011 at 11:20:30AM -0600, Alex Williamson wrote:
> > On Thu, 2011-08-25 at 12:54 +0200, Roedel, Joerg wrote:
>
> > > We need to solve this differently. ARM is starting to use the iommu-api
> > > too and this definitly does not work there. One possible solution might
> > > be to make the iommu-ops per-bus.
> >
> > That sounds good. Is anyone working on it? It seems like it doesn't
> > hurt to use this in the interim, we may just be watching the wrong bus
> > and never add any sysfs group info.
>
> I'll cook something up for RFC over the weekend.
>
> > > Also the return type should not be long but something that fits into
> > > 32bit on all platforms. Since you use -ENODEV, probably s32 is a good
> > > choice.
> >
> > The convenience of using seg|bus|dev|fn was too much to resist, too bad
> > it requires a full 32bits. Maybe I'll change it to:
> > int iommu_device_group(struct device *dev, unsigned int *group)
>
> If we really expect segment numbers that need the full 16 bit then this
> would be the way to go. Otherwise I would prefer returning the group-id
> directly and partition the group-id space for the error values (s32 with
> negative numbers being errors).
It's unlikely to have segments using the top bit, but it would be broken
for an iommu driver to define it's group numbers using pci s:b:d.f if we
don't have that bit available. Ben/David, do PEs have an identifier of
a convenient size? I'd guess any hardware based identifier is going to
use a full unsigned bit width. Thanks,
Alex
^ permalink raw reply
* Re: Kernel boot up
From: Scott Wood @ 2011-08-26 20:08 UTC (permalink / raw)
To: smitha.vanga; +Cc: linuxppc-dev
In-Reply-To: <07ACDFB8ECA8EF47863A613BC01BBB22035E3D59@HYD-MKD-MBX02.wipro.com>
On 08/26/2011 01:00 AM, smitha.vanga@wipro.com wrote:
>
> Thanks scott.
>
> There was an issue with the file system. Now my board is up with the
> linux boot prompt .
> But ping is not working.
You still haven't set your MAC address. U-Boot should be fixing this up
in the device tree.
> The local loopback ping works. My phy chip
> BCM5221 is connected on port A
Your device tree describes a connection on port C. You need to update
the mdio node's reg to point to port A's registers (0x10d00), and
fsl,mdio-pin and fsl,mdc-pin need to be set to the particular pins your
board uses.
-Scott
^ permalink raw reply
* Re: kvm PCI assignment & VFIO ramblings
From: Aaron Fabbri @ 2011-08-26 20:17 UTC (permalink / raw)
To: Chris Wright
Cc: Alexey Kardashevskiy, kvm@vger.kernel.org, Paul Mackerras,
linux-pci@vger.kernel.org, Alexander Graf, qemu-devel, iommu,
Avi Kivity, Anthony Liguori, Roedel, Joerg, linuxppc-dev,
benve@cisco.com
In-Reply-To: <20110826193559.GD13060@sequoia.sous-sol.org>
On 8/26/11 12:35 PM, "Chris Wright" <chrisw@sous-sol.org> wrote:
> * Aaron Fabbri (aafabbri@cisco.com) wrote:
>> On 8/26/11 7:07 AM, "Alexander Graf" <agraf@suse.de> wrote:
>>> Forget the KVM case for a moment and think of a user space device driver. I
>>> as
>>> a user am not root. But I as a user when having access to /dev/vfioX want to
>>> be able to access the device and manage it - and only it. The admin of that
>>> box needs to set it up properly for me to be able to access it.
>>>
>>> So having two steps is really the correct way to go:
>>>
>>> * create VFIO group
>>> * use VFIO group
>>>
>>> because the two are done by completely different users.
>>
>> This is not the case for my userspace drivers using VFIO today.
>>
>> Each process will open vfio devices on the fly, and they need to be able to
>> share IOMMU resources.
>
> How do you share IOMMU resources w/ multiple processes, are the processes
> sharing memory?
Sorry, bad wording. I share IOMMU domains *within* each process.
E.g. If one process has 3 devices and another has 10, I can get by with two
iommu domains (and can share buffers among devices within each process).
If I ever need to share devices across processes, the shared memory case
might be interesting.
>
>> So I need the ability to dynamically bring up devices and assign them to a
>> group. The number of actual devices and how they map to iommu domains is
>> not known ahead of time. We have a single piece of silicon that can expose
>> hundreds of pci devices.
>
> This does not seem fundamentally different from the KVM use case.
>
> We have 2 kinds of groupings.
>
> 1) low-level system or topoolgy grouping
>
> Some may have multiple devices in a single group
>
> * the PCIe-PCI bridge example
> * the POWER partitionable endpoint
>
> Many will not
>
> * singleton group, e.g. typical x86 PCIe function (majority of
> assigned devices)
>
> Not sure it makes sense to have these administratively defined as
> opposed to system defined.
>
> 2) logical grouping
>
> * multiple low-level groups (singleton or otherwise) attached to same
> process, allowing things like single set of io page tables where
> applicable.
>
> These are nominally adminstratively defined. In the KVM case, there
> is likely a privileged task (i.e. libvirtd) involved w/ making the
> device available to the guest and can do things like group merging.
> In your userspace case, perhaps it should be directly exposed.
Yes. In essence, I'd rather not have to run any other admin processes.
Doing things programmatically, on the fly, from each process, is the
cleanest model right now.
>
>> In my case, the only administrative task would be to give my processes/users
>> access to the vfio groups (which are initially singletons), and the
>> application actually opens them and needs the ability to merge groups
>> together to conserve IOMMU resources (assuming we're not going to expose
>> uiommu).
>
> I agree, we definitely need to expose _some_ way to do this.
>
> thanks,
> -chris
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox