RE: Kernel boot up
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 100 200 c0 ## Current stack ends at 0x03e93cc8 * kernel: cmdline image address = 0x0100 ## Booting kernel from Legacy Image at 0100 ... Image Name: Linux-2.6.39 Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size:1765760 Bytes = 1.7 MiB Load Address: Entry Point: Verifying Checksum ... OK kernel data at 0x0140, len = 0x001af180 (1765760) * ramdisk: cmdline image address = 0x0200 ## Loading init Ramdisk from Legacy Image at 0200 ... Image Name: uboot ext2 ramdisk rootfs Image Type: PowerPC Linux RAMDisk Image (gzip compressed) Data Size:3972156 Bytes = 3.8 MiB Load Address: Entry Point: Verifying Checksum ... OK ramdisk start = 0x0240, ramdisk end = 0x023c9c7c * fdt: cmdline image address = 0x00c0 ## Checking for 'FDT'/'FDT Image' at 00c0 * fdt: raw FDT blob ## Flattened Device Tree blob at 00c0 Booting using the fdt blob at 0xc0 of_flat_tree at 0x00c0 size 0x0f12 Uncompressing Kernel Image ... OK kernel loaded at 0x, end = 0x0038bd20 ## initrd_high = 0x, copy_to_ram = 1 Loading Ramdisk to 03ac9000, end 03e92c3c ... OK ramdisk load start = 0x03ac9000, ramdisk load end = 0x03e92c3c ## device tree at 00c0 ... 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 ) ... 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 0x -> 0x4000 Normal empty Movable zone start PFN for each node early_node_map[1] active PFN ranges 0: 0x -> 0x4000 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..0xf000 : fixmap * 0xfdfb6000..0xfe00 : early ioremap * 0xc500..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 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 ff80
Re: [PATCH] dtc: remove some warnings
Hi David, On Fri, 26 Aug 2011 14:49:02 +1000 David Gibson 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 Rothwells...@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ pgpKpGnrYykpR.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] dtc: remove some warnings
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 Acked-by: David Gibson 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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2] [PowerPC Book3E] Introduce new ptrace debug feature flag
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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: kvm PCI assignment & VFIO ramblings
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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: kvm PCI assignment & VFIO ramblings
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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] [v2] tty/powerpc: fix build break with ehv_bytechan.c on allyesconfig
Hi all, On Thu, 25 Aug 2011 13:06:57 -0500 Timur Tabi 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 Rothwells...@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ pgpicvZZ4tOiR.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] dtc: remove some warnings
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
---
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 Rothwells...@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: build failure after merge of the final tree (tty tree related)
Hi Arnaud, On Thu, 25 Aug 2011 12:09:20 -0400 Arnaud Lacombe 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 Rothwells...@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ pgpAyjjoNMIXF.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] xics/icp_natives: add __init to marker icp_native_init()
Hi,
On Thu, Aug 25, 2011 at 3:24 PM, Timur Tabi wrote:
> Arnaud Lacombe wrote:
>> This should fix the following warning:
>>
>> LD arch/powerpc/sysdev/xics/built-in.o
>> WARNING: arch/powerpc/sysdev/xics/built-in.o(.text+0x1310): Section mismatch
>> in
>> reference from the function .icp_native_init() to the function
>> .init.text:.icp_native_init_one_node()
>> The function .icp_native_init() references
>> the function __init .icp_native_init_one_node().
>> This is often because .icp_native_init lacks a __init
>> annotation or the annotation of .icp_native_init_one_node is wrong.
>>
>> icp_native_init() is only referenced in
>> `arch/powerpc/sysdev/xics/xics-common.c'
>> by xics_init() which is itself marked with __init.
>>
>> = not built-tested =
>>
>> Reported-by: Timur Tabi
>> Signed-off-by: Arnaud Lacombe
>
> Acked-by: Timur Tabi
>
> This warning still appears, though:
>
> WARNING: arch/powerpc/sysdev/built-in.o(.text+0xf6b8): Section mismatch in
> reference from the function .ics_rtas_init() to the function
> .init.text:.xics_register_ics()
> The function .ics_rtas_init() references
> the function __init .xics_register_ics().
> This is often because .ics_rtas_init lacks a __init
> annotation or the annotation of .xics_register_ics is wrong.
>
he, chain-reaction :)
> To fix this warning, you'll also need:
>
> diff --git a/arch/powerpc/sysdev/xics/ics-rtas.c
> b/arch/powerpc/sysdev/xics/ics-
> index c782f85..a125721 100644
> --- a/arch/powerpc/sysdev/xics/ics-rtas.c
> +++ b/arch/powerpc/sysdev/xics/ics-rtas.c
> @@ -213,7 +213,7 @@ static int ics_rtas_host_match(struct ics *ics, struct
> devic
> return !of_device_is_compatible(node, "chrp,iic");
> }
>
> -int ics_rtas_init(void)
> +int __init ics_rtas_init(void)
> {
> ibm_get_xive = rtas_token("ibm,get-xive");
> ibm_set_xive = rtas_token("ibm,set-xive");
>
>
> However, now we get another similar warning:
>
> WARNING: drivers/built-in.o(.text+0x259c484): Section mismatch in reference
> from
> the function .tc3589x_keypad_open() to the function
> .devinit.text:.tc3589x_keypad_init_key_hardware()
> The function .tc3589x_keypad_open() references
> the function __devinit .tc3589x_keypad_init_key_hardware().
> This is often because .tc3589x_keypad_open lacks a __devinit
> annotation or the annotation of .tc3589x_keypad_init_key_hardware is wrong.
>
> I'm not sure what to do at this point, because I have a suspicion that adding
> __devinit to tc3589x_keypad_open() is wrong.
>
tc3589x_keypad_init_key_hardware() annotation looks plain wrong.
- Arnaud
> --
> Timur Tabi
> Linux kernel developer at Freescale
>
>
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Kernel boot up
On 08/25/2011 02:57 AM, smitha.va...@wipro.com wrote: > Hi Scott, > > I am currently trying to bring up 2.6.39 kernel on a target based on MPC8247 > Processor, using the attched .dts file . I get the below logs while the > kernel is booting. > I see that the unflattening of the device tree and the initial loading > of the kernel and ramdisk file system is happening correctly. Can you > point me where exactly I can look for this issue. I am attaching the > .config and .dts file I am using. Which error are you referring to? > of-flash ff80.flash: do_map_probe() failed What kind of flash chip do you have? Does the node in the device tree accurately describe it (four interleaved 8-bit chips that only do JEDEC and not CFI)? > 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 > eth0: fs_enet: 00:00:00:00:00:00 > eth1: fs_enet: 00:00:00:00:00:00 These MAC addresses should have been set in the device tree. If you're using U-Boot, it should be doing the fixup. > Populating /dev using udev: /sbin/udevd: '/lib/libc.so.6' library > contains unsup > ported TLS > /sbin/udevd: '/lib/libc.so.6' library contains unsupported TLS > /sbin/udevd: can't load library 'libc.so.6' > FAIL > /sbin/udevstart: '/lib/libc.so.6' library contains unsupported TLS > /sbin/udevstart: '/lib/libc.so.6' library contains unsupported TLS > /sbin/udevstart: can't load library 'libc.so.6' > FAIL This is a problem with the root filesystem, not the kernel. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] xics/icp_natives: add __init to marker icp_native_init()
Arnaud Lacombe wrote:
> This should fix the following warning:
>
> LD arch/powerpc/sysdev/xics/built-in.o
> WARNING: arch/powerpc/sysdev/xics/built-in.o(.text+0x1310): Section mismatch
> in
> reference from the function .icp_native_init() to the function
> .init.text:.icp_native_init_one_node()
> The function .icp_native_init() references
> the function __init .icp_native_init_one_node().
> This is often because .icp_native_init lacks a __init
> annotation or the annotation of .icp_native_init_one_node is wrong.
>
> icp_native_init() is only referenced in
> `arch/powerpc/sysdev/xics/xics-common.c'
> by xics_init() which is itself marked with __init.
>
> = not built-tested =
>
> Reported-by: Timur Tabi
> Signed-off-by: Arnaud Lacombe
Acked-by: Timur Tabi
This warning still appears, though:
WARNING: arch/powerpc/sysdev/built-in.o(.text+0xf6b8): Section mismatch in
reference from the function .ics_rtas_init() to the function
.init.text:.xics_register_ics()
The function .ics_rtas_init() references
the function __init .xics_register_ics().
This is often because .ics_rtas_init lacks a __init
annotation or the annotation of .xics_register_ics is wrong.
To fix this warning, you'll also need:
diff --git a/arch/powerpc/sysdev/xics/ics-rtas.c b/arch/powerpc/sysdev/xics/ics-
index c782f85..a125721 100644
--- a/arch/powerpc/sysdev/xics/ics-rtas.c
+++ b/arch/powerpc/sysdev/xics/ics-rtas.c
@@ -213,7 +213,7 @@ static int ics_rtas_host_match(struct ics *ics, struct devic
return !of_device_is_compatible(node, "chrp,iic");
}
-int ics_rtas_init(void)
+int __init ics_rtas_init(void)
{
ibm_get_xive = rtas_token("ibm,get-xive");
ibm_set_xive = rtas_token("ibm,set-xive");
However, now we get another similar warning:
WARNING: drivers/built-in.o(.text+0x259c484): Section mismatch in reference from
the function .tc3589x_keypad_open() to the function
.devinit.text:.tc3589x_keypad_init_key_hardware()
The function .tc3589x_keypad_open() references
the function __devinit .tc3589x_keypad_init_key_hardware().
This is often because .tc3589x_keypad_open lacks a __devinit
annotation or the annotation of .tc3589x_keypad_init_key_hardware is wrong.
I'm not sure what to do at this point, because I have a suspicion that adding
__devinit to tc3589x_keypad_open() is wrong.
--
Timur Tabi
Linux kernel developer at Freescale
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] tty/powerpc: fix build break with ehv_bytechan.c on allyesconfig
On Thu, Aug 25, 2011 at 01:51:20PM -0500, Timur Tabi wrote: > Greg KH wrote: > > But don't you really want this type of check at runtime? What happens > > if you load this driver on a machine that is not a guest? Will things > > break? Shouldn't you still refuse to load somehow? > > This is in the udbg code, which falls under the category of, "turn this on > only > if you know what you're doing." > > The udbg code runs very early, before the device tree is available. There's > no > way of knowing at this point whether or not we're running under a hypervisor. > If you turn on udbg support, then it means that you're trying to do some very > specific debugging on a specific platform. > > So I'm not removing this code just to fix the build break. It really should > never have been there in the first place. Ok, thanks for the details, I'll queue up the patch in a bit. greg k-h ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] tty/powerpc: fix build break with ehv_bytechan.c on allyesconfig
Greg KH wrote: > But don't you really want this type of check at runtime? What happens > if you load this driver on a machine that is not a guest? Will things > break? Shouldn't you still refuse to load somehow? This is in the udbg code, which falls under the category of, "turn this on only if you know what you're doing." The udbg code runs very early, before the device tree is available. There's no way of knowing at this point whether or not we're running under a hypervisor. If you turn on udbg support, then it means that you're trying to do some very specific debugging on a specific platform. So I'm not removing this code just to fix the build break. It really should never have been there in the first place. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] tty/powerpc: fix build break with ehv_bytechan.c on allyesconfig
On Thu, Aug 25, 2011 at 01:02:01PM -0500, Timur Tabi wrote: > Greg KH wrote: > > tested doesn't mean that it shouldn't still build properly for other > > platforms, right? > > The problem is the dependency on MSR_GS, which is defined only for Book-E > PowerPC chips, not all PowerPC. > > So I gave it some more thought, and technically ePAPR extends beyond Book-E, > so > it's wrong for the driver to depend on anything specific to Book-E. I've > removed the code that breaks: > > /* Check if we're running as a guest of a hypervisor */ > if (!(mfmsr() & MSR_GS)) > return; But don't you really want this type of check at runtime? What happens if you load this driver on a machine that is not a guest? Will things break? Shouldn't you still refuse to load somehow? thanks, greg k-h ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] [v2] tty/powerpc: fix build break with ehv_bytechan.c on allyesconfig
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.
Signed-off-by: Timur Tabi
---
drivers/tty/ehv_bytechan.c |8 ++--
1 files changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/tty/ehv_bytechan.c b/drivers/tty/ehv_bytechan.c
index e67f70b..f733718 100644
--- a/drivers/tty/ehv_bytechan.c
+++ b/drivers/tty/ehv_bytechan.c
@@ -226,10 +226,6 @@ void __init udbg_init_ehv_bc(void)
unsigned int rx_count, tx_count;
unsigned int ret;
- /* Check if we're running as a guest of a hypervisor */
- if (!(mfmsr() & MSR_GS))
- return;
-
/* Verify the byte channel handle */
ret = ev_byte_channel_poll(CONFIG_PPC_EARLY_DEBUG_EHV_BC_HANDLE,
&rx_count, &tx_count);
@@ -286,7 +282,7 @@ static int ehv_bc_console_byte_channel_send(unsigned int
handle, const char *s,
static void ehv_bc_console_write(struct console *co, const char *s,
unsigned int count)
{
- unsigned int handle = (unsigned int)co->data;
+ unsigned int handle = (uintptr_t)co->data;
char s2[EV_BYTE_CHANNEL_MAX_BYTES];
unsigned int i, j = 0;
char c;
@@ -352,7 +348,7 @@ static int __init ehv_bc_console_init(void)
CONFIG_PPC_EARLY_DEBUG_EHV_BC_HANDLE);
#endif
- ehv_bc_console.data = (void *)stdout_bc;
+ ehv_bc_console.data = (void *)(uintptr_t)stdout_bc;
/* add_preferred_console() must be called before register_console(),
otherwise it won't work. However, we don't want to enumerate all the
--
1.7.3.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: kvm PCI assignment & VFIO ramblings
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).
> > > @@ -438,6 +439,10 @@ static int __init intel_iommu_setup(char *str)
> > > printk(KERN_INFO
> > > "Intel-IOMMU: disable supported super page\n");
> > > intel_iommu_superpage = 0;
> > > + } else if (!strncmp(str, "no_mf_groups", 12)) {
> > > + printk(KERN_INFO
> > > + "Intel-IOMMU: disable separate groups for
> > > multifunction devices\n");
> > > + intel_iommu_no_mf_groups = 1;
> >
> > This should really be a global iommu option and not be VT-d specific.
>
> You think? It's meaningless on benh's power systems.
But it is not meaningless on AMD-Vi systems :) There should be one
option for both.
On the other hand this requires an iommu= parameter on ia64, but thats
probably not that bad.
> > This looks like code duplication in the VT-d driver. It doesn't need to
> > be generalized now, but we should keep in mind to do a more general
> > solution later.
> > Maybe it is beneficial if the IOMMU drivers only setup the number in
> > dev->arch.iommu.groupid and the iommu-api fetches it from there then.
> > But as I said, this is some more work and does not need to be done for
> > this patch(-set).
>
> The iommu-api reaches into dev->arch.iommu.groupid? I figured we should
> at least start out with a lightweight, optional interface without the
> overhead of predefining groupids setup by bus notification callbacks in
> each iommu driver. Thanks,
As I said, this is just an idea for an later optimization. It is fine
for now as it is in this patch.
Joerg
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] tty/powerpc: fix build break with ehv_bytechan.c on allyesconfig
Greg KH wrote: > tested doesn't mean that it shouldn't still build properly for other > platforms, right? The problem is the dependency on MSR_GS, which is defined only for Book-E PowerPC chips, not all PowerPC. So I gave it some more thought, and technically ePAPR extends beyond Book-E, so it's wrong for the driver to depend on anything specific to Book-E. I've removed the code that breaks: /* Check if we're running as a guest of a hypervisor */ if (!(mfmsr() & MSR_GS)) return; > What is keeping the driver from building on all PPC, or even all arches > today? I've made a few changes, and it builds on all PPC now. I'll post a new patch. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: kvm PCI assignment & VFIO ramblings
On Thu, 2011-08-25 at 12:54 +0200, Roedel, Joerg wrote:
> Hi Alex,
>
> On Wed, Aug 24, 2011 at 05:13:49PM -0400, Alex Williamson wrote:
> > Is this roughly what you're thinking of for the iommu_group component?
> > Adding a dev_to_group iommu ops callback let's us consolidate the sysfs
> > support in the iommu base. Would AMD-Vi do something similar (or
> > exactly the same) for group #s? Thanks,
>
> The concept looks good, I have some comments, though. On AMD-Vi the
> implementation would look a bit different because there is a
> data-structure were the information can be gathered from, so no need for
> PCI bus scanning there.
>
> > diff --git a/drivers/base/iommu.c b/drivers/base/iommu.c
> > index 6e6b6a1..6b54c1a 100644
> > --- a/drivers/base/iommu.c
> > +++ b/drivers/base/iommu.c
> > @@ -17,20 +17,56 @@
> > */
> >
> > #include
> > +#include
> > #include
> > #include
> > #include
> > #include
> > #include
> > +#include
> >
> > static struct iommu_ops *iommu_ops;
> >
> > +static ssize_t show_iommu_group(struct device *dev,
> > + struct device_attribute *attr, char *buf)
> > +{
> > + return sprintf(buf, "%lx", iommu_dev_to_group(dev));
>
> Probably add a 0x prefix so userspace knows the format?
I think I'll probably change it to %u. Seems common to have decimal in
sysfs and doesn't get confusing if we cat it with a string. As a bonus,
it abstracts that vt-d is just stuffing a PCI device address in there,
which nobody should ever rely on.
> > +}
> > +static DEVICE_ATTR(iommu_group, S_IRUGO, show_iommu_group, NULL);
> > +
> > +static int add_iommu_group(struct device *dev, void *unused)
> > +{
> > + if (iommu_dev_to_group(dev) >= 0)
> > + return device_create_file(dev, &dev_attr_iommu_group);
> > +
> > + return 0;
> > +}
> > +
> > +static int device_notifier(struct notifier_block *nb,
> > + unsigned long action, void *data)
> > +{
> > + struct device *dev = data;
> > +
> > + if (action == BUS_NOTIFY_ADD_DEVICE)
> > + return add_iommu_group(dev, NULL);
> > +
> > + return 0;
> > +}
> > +
> > +static struct notifier_block device_nb = {
> > + .notifier_call = device_notifier,
> > +};
> > +
> > void register_iommu(struct iommu_ops *ops)
> > {
> > if (iommu_ops)
> > BUG();
> >
> > iommu_ops = ops;
> > +
> > + /* FIXME - non-PCI, really want for_each_bus() */
> > + bus_register_notifier(&pci_bus_type, &device_nb);
> > + bus_for_each_dev(&pci_bus_type, NULL, NULL, add_iommu_group);
> > }
>
> 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.
> > bool iommu_found(void)
> > @@ -94,6 +130,14 @@ int iommu_domain_has_cap(struct iommu_domain *domain,
> > }
> > EXPORT_SYMBOL_GPL(iommu_domain_has_cap);
> >
> > +long iommu_dev_to_group(struct device *dev)
> > +{
> > + if (iommu_ops->dev_to_group)
> > + return iommu_ops->dev_to_group(dev);
> > + return -ENODEV;
> > +}
> > +EXPORT_SYMBOL_GPL(iommu_dev_to_group);
>
> Please rename this to iommu_device_group(). The dev_to_group name
> suggests a conversion but it is actually just a property of the device.
Ok.
> 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)
> > +
> > int iommu_map(struct iommu_domain *domain, unsigned long iova,
> > phys_addr_t paddr, int gfp_order, int prot)
> > {
> > diff --git a/drivers/pci/intel-iommu.c b/drivers/pci/intel-iommu.c
> > index f02c34d..477259c 100644
> > --- a/drivers/pci/intel-iommu.c
> > +++ b/drivers/pci/intel-iommu.c
> > @@ -404,6 +404,7 @@ static int dmar_map_gfx = 1;
> > static int dmar_forcedac;
> > static int intel_iommu_strict;
> > static int intel_iommu_superpage = 1;
> > +static int intel_iommu_no_mf_groups;
> >
> > #define DUMMY_DEVICE_DOMAIN_INFO ((struct device_domain_info *)(-1))
> > static DEFINE_SPINLOCK(device_domain_lock);
> > @@ -438,6 +439,10 @@ static int __init intel_iommu_setup(char *str)
> > printk(KERN_INFO
> > "Intel-IOMMU: disable supported super page\n");
> > intel_iommu_superpage = 0;
> > + } else if (!strncmp(str, "no_mf_groups", 12)) {
> > + printk(KERN_INFO
> > + "Intel-IOMMU: disable separate groups for
> > multifunction devices\n");
> > + intel_iommu_no_mf_groups = 1;
>
> This should r
Re: kvm PCI assignment & VFIO ramblings
On Thu, Aug 25, 2011 at 11:38:09AM -0400, Don Dutile wrote: > On 08/25/2011 06:54 AM, 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. > > > When you think of a system where there isn't just one bus-type > with iommu support, it makes more sense. > Additionally, it also allows the long-term architecture to use different types > of IOMMUs on each bus segment -- think per-PCIe-switch/bridge IOMMUs -- > esp. 'tuned' IOMMUs -- ones better geared for networks, ones better geared > for direct-attach disk hba's. Not sure how likely it is to have different types of IOMMUs within a given bus-type. But if they become reality we can multiplex in the iommu-api without much hassle :) For now, something like bus_set_iommu() or bus_register_iommu() would provide a nice way to do bus-specific setups for a given iommu implementation. 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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] tty/powerpc: fix build break with ehv_bytechan.c on allyesconfig
On Thu, Aug 25, 2011 at 11:20:45AM -0500, Timur Tabi wrote: > The Kconfig for the ePAPR hypervisor byte channel driver has a "depends on > PPC", > which means it would compile on all PowerPC platforms, even though it's > only been tested on Freescale platforms. Change the Kconfig to depend on > FSL_SOC instead. tested doesn't mean that it shouldn't still build properly for other platforms, right? What is keeping the driver from building on all PPC, or even all arches today? greg k-h ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] tty/powerpc: fix build break with ehv_bytechan.c on allyesconfig
The Kconfig for the ePAPR hypervisor byte channel driver has a "depends on PPC", which means it would compile on all PowerPC platforms, even though it's only been tested on Freescale platforms. Change the Kconfig to depend on FSL_SOC instead. Signed-off-by: Timur Tabi --- drivers/tty/Kconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/tty/Kconfig b/drivers/tty/Kconfig index f1ea59b..535af0a 100644 --- a/drivers/tty/Kconfig +++ b/drivers/tty/Kconfig @@ -353,7 +353,7 @@ config TRACE_SINK config PPC_EPAPR_HV_BYTECHAN tristate "ePAPR hypervisor byte channel driver" - depends on PPC + depends on FSL_SOC help This driver creates /dev entries for each ePAPR hypervisor byte channel, thereby allowing applications to communicate with byte -- 1.7.3.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: build failure after merge of the final tree (tty tree related)
Hi, On Thu, Aug 25, 2011 at 11:51 AM, Stephen Rothwell wrote: > Hi Timur, > > On Thu, 25 Aug 2011 10:22:05 -0500 Timur Tabi wrote: >> >> Is there some trick to building allyesconfig on PowerPC? When I do try >> that, I >> get all sorts of weird build errors, and it dies long before it gets to my >> driver. I get stuff like: >> >> LD arch/powerpc/sysdev/xics/built-in.o >> WARNING: arch/powerpc/sysdev/xics/built-in.o(.text+0x1310): Section mismatch >> in >> reference from the function .icp_native_init() to the function >> .init.text:.icp_native_init_one_node() >> The function .icp_native_init() references >> the function __init .icp_native_init_one_node(). >> This is often because .icp_native_init lacks a __init >> annotation or the annotation of .icp_native_init_one_node is wrong. > > We get lots of those in many builds. :-( Just a warning. > 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 ? - Arnaud >> and >> >> AS arch/powerpc/kernel/head_64.o >> arch/powerpc/kernel/exceptions-64s.S: Assembler messages: >> arch/powerpc/kernel/exceptions-64s.S:1151: Error: attempt to move .org >> backwards >> arch/powerpc/kernel/exceptions-64s.S:1160: Error: attempt to move .org >> backwards > > There is a patch for that pending with either the kvm guys or the powerpc > guys. > >> I guess I don't have the right compiler. > > Yours seems to be OK. If you pass -k to make it will get further. Or > you could configure it and then just try building your driver rather than > the whole tree. > >> Anyway, I think I know how to fix the break that Stephen is seeing. I will >> post >> a v4 patch in a few minutes. > > Thanks. > -- > Cheers, > Stephen Rothwell s...@canb.auug.org.au > http://www.canb.auug.org.au/~sfr/ > ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] xics/icp_natives: add __init to marker icp_native_init()
This should fix the following warning:
LD arch/powerpc/sysdev/xics/built-in.o
WARNING: arch/powerpc/sysdev/xics/built-in.o(.text+0x1310): Section mismatch in
reference from the function .icp_native_init() to the function
.init.text:.icp_native_init_one_node()
The function .icp_native_init() references
the function __init .icp_native_init_one_node().
This is often because .icp_native_init lacks a __init
annotation or the annotation of .icp_native_init_one_node is wrong.
icp_native_init() is only referenced in `arch/powerpc/sysdev/xics/xics-common.c'
by xics_init() which is itself marked with __init.
= not built-tested =
Reported-by: Timur Tabi
Signed-off-by: Arnaud Lacombe
---
arch/powerpc/sysdev/xics/icp-native.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/sysdev/xics/icp-native.c
b/arch/powerpc/sysdev/xics/icp-native.c
index 50e32af..4c79b6f 100644
--- a/arch/powerpc/sysdev/xics/icp-native.c
+++ b/arch/powerpc/sysdev/xics/icp-native.c
@@ -276,7 +276,7 @@ static const struct icp_ops icp_native_ops = {
#endif
};
-int icp_native_init(void)
+int __init icp_native_init(void)
{
struct device_node *np;
u32 indx = 0;
--
1.7.6.153.g78432
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] [v4] tty/powerpc: introduce the ePAPR embedded hypervisor byte channel driver
Greg KH wrote: > No, this doesn't work, I need just a fix, as I took your previous patch > already. Sorry, coming right up. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] [v4] tty/powerpc: introduce the ePAPR embedded hypervisor byte channel driver
On Thu, Aug 25, 2011 at 10:32:25AM -0500, Timur Tabi wrote: > The ePAPR embedded hypervisor specification provides an API for "byte > channels", which are serial-like virtual devices for sending and receiving > streams of bytes. This driver provides Linux kernel support for byte > channels via three distinct interfaces: > > 1) An early-console (udbg) driver. This provides early console output > through a byte channel. The byte channel handle must be specified in a > Kconfig option. > > 2) A normal console driver. Output is sent to the byte channel designated > for stdout in the device tree. The console driver is for handling kernel > printk calls. > > 3) A tty driver, which is used to handle user-space input and output. The > byte channel used for the console is designated as the default tty. > > Signed-off-by: Timur Tabi No, this doesn't work, I need just a fix, as I took your previous patch already. greg k-h ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: build failure after merge of the final tree (tty tree related)
Hi Timur, On Thu, 25 Aug 2011 10:22:05 -0500 Timur Tabi wrote: > > Is there some trick to building allyesconfig on PowerPC? When I do try that, > I > get all sorts of weird build errors, and it dies long before it gets to my > driver. I get stuff like: > > LD arch/powerpc/sysdev/xics/built-in.o > WARNING: arch/powerpc/sysdev/xics/built-in.o(.text+0x1310): Section mismatch > in > reference from the function .icp_native_init() to the function > .init.text:.icp_native_init_one_node() > The function .icp_native_init() references > the function __init .icp_native_init_one_node(). > This is often because .icp_native_init lacks a __init > annotation or the annotation of .icp_native_init_one_node is wrong. We get lots of those in many builds. :-( Just a warning. > and > > AS arch/powerpc/kernel/head_64.o > arch/powerpc/kernel/exceptions-64s.S: Assembler messages: > arch/powerpc/kernel/exceptions-64s.S:1151: Error: attempt to move .org > backwards > arch/powerpc/kernel/exceptions-64s.S:1160: Error: attempt to move .org > backwards There is a patch for that pending with either the kvm guys or the powerpc guys. > I guess I don't have the right compiler. Yours seems to be OK. If you pass -k to make it will get further. Or you could configure it and then just try building your driver rather than the whole tree. > Anyway, I think I know how to fix the break that Stephen is seeing. I will > post > a v4 patch in a few minutes. Thanks. -- Cheers, Stephen Rothwells...@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ pgpVhblnqGQKI.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: kvm PCI assignment & VFIO ramblings
On 08/25/2011 06:54 AM, Roedel, Joerg wrote:
Hi Alex,
On Wed, Aug 24, 2011 at 05:13:49PM -0400, Alex Williamson wrote:
Is this roughly what you're thinking of for the iommu_group component?
Adding a dev_to_group iommu ops callback let's us consolidate the sysfs
support in the iommu base. Would AMD-Vi do something similar (or
exactly the same) for group #s? Thanks,
The concept looks good, I have some comments, though. On AMD-Vi the
implementation would look a bit different because there is a
data-structure were the information can be gathered from, so no need for
PCI bus scanning there.
diff --git a/drivers/base/iommu.c b/drivers/base/iommu.c
index 6e6b6a1..6b54c1a 100644
--- a/drivers/base/iommu.c
+++ b/drivers/base/iommu.c
@@ -17,20 +17,56 @@
*/
#include
+#include
#include
#include
#include
#include
#include
+#include
static struct iommu_ops *iommu_ops;
+static ssize_t show_iommu_group(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ return sprintf(buf, "%lx", iommu_dev_to_group(dev));
Probably add a 0x prefix so userspace knows the format?
+}
+static DEVICE_ATTR(iommu_group, S_IRUGO, show_iommu_group, NULL);
+
+static int add_iommu_group(struct device *dev, void *unused)
+{
+ if (iommu_dev_to_group(dev)>= 0)
+ return device_create_file(dev,&dev_attr_iommu_group);
+
+ return 0;
+}
+
+static int device_notifier(struct notifier_block *nb,
+ unsigned long action, void *data)
+{
+ struct device *dev = data;
+
+ if (action == BUS_NOTIFY_ADD_DEVICE)
+ return add_iommu_group(dev, NULL);
+
+ return 0;
+}
+
+static struct notifier_block device_nb = {
+ .notifier_call = device_notifier,
+};
+
void register_iommu(struct iommu_ops *ops)
{
if (iommu_ops)
BUG();
iommu_ops = ops;
+
+ /* FIXME - non-PCI, really want for_each_bus() */
+ bus_register_notifier(&pci_bus_type,&device_nb);
+ bus_for_each_dev(&pci_bus_type, NULL, NULL, add_iommu_group);
}
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.
When you think of a system where there isn't just one bus-type
with iommu support, it makes more sense.
Additionally, it also allows the long-term architecture to use different types
of IOMMUs on each bus segment -- think per-PCIe-switch/bridge IOMMUs --
esp. 'tuned' IOMMUs -- ones better geared for networks, ones better geared
for direct-attach disk hba's.
bool iommu_found(void)
@@ -94,6 +130,14 @@ int iommu_domain_has_cap(struct iommu_domain *domain,
}
EXPORT_SYMBOL_GPL(iommu_domain_has_cap);
+long iommu_dev_to_group(struct device *dev)
+{
+ if (iommu_ops->dev_to_group)
+ return iommu_ops->dev_to_group(dev);
+ return -ENODEV;
+}
+EXPORT_SYMBOL_GPL(iommu_dev_to_group);
Please rename this to iommu_device_group(). The dev_to_group name
suggests a conversion but it is actually just a property of the device.
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.
+
int iommu_map(struct iommu_domain *domain, unsigned long iova,
phys_addr_t paddr, int gfp_order, int prot)
{
diff --git a/drivers/pci/intel-iommu.c b/drivers/pci/intel-iommu.c
index f02c34d..477259c 100644
--- a/drivers/pci/intel-iommu.c
+++ b/drivers/pci/intel-iommu.c
@@ -404,6 +404,7 @@ static int dmar_map_gfx = 1;
static int dmar_forcedac;
static int intel_iommu_strict;
static int intel_iommu_superpage = 1;
+static int intel_iommu_no_mf_groups;
#define DUMMY_DEVICE_DOMAIN_INFO ((struct device_domain_info *)(-1))
static DEFINE_SPINLOCK(device_domain_lock);
@@ -438,6 +439,10 @@ static int __init intel_iommu_setup(char *str)
printk(KERN_INFO
"Intel-IOMMU: disable supported super page\n");
intel_iommu_superpage = 0;
+ } else if (!strncmp(str, "no_mf_groups", 12)) {
+ printk(KERN_INFO
+ "Intel-IOMMU: disable separate groups for
multifunction devices\n");
+ intel_iommu_no_mf_groups = 1;
This should really be a global iommu option and not be VT-d specific.
str += strcspn(str, ",");
@@ -3902,6 +3907,52 @@ static int intel_iommu_domain_has_cap(struct
iommu_domain *domain,
return 0;
}
+/* Group numbers are arbitrary. Device with the same group number
+ * indicate the iommu cannot differentiate between them. To avoid
+ * tracking used groups we just use the seg|bus|devfn of the lowest
+ * level we're able to differentiate devices */
+static long intel_iommu_dev_to_group(struct device *dev)
+{
+ struct pci_dev *pdev = to_pci_dev(dev);
+ struct pci_d
[PATCH] [v4] tty/powerpc: introduce the ePAPR embedded hypervisor byte channel driver
The ePAPR embedded hypervisor specification provides an API for "byte channels", which are serial-like virtual devices for sending and receiving streams of bytes. This driver provides Linux kernel support for byte channels via three distinct interfaces: 1) An early-console (udbg) driver. This provides early console output through a byte channel. The byte channel handle must be specified in a Kconfig option. 2) A normal console driver. Output is sent to the byte channel designated for stdout in the device tree. The console driver is for handling kernel printk calls. 3) A tty driver, which is used to handle user-space input and output. The byte channel used for the console is designated as the default tty. Signed-off-by: Timur Tabi --- arch/powerpc/include/asm/udbg.h |1 + arch/powerpc/kernel/udbg.c |2 + drivers/tty/Kconfig | 34 ++ drivers/tty/Makefile|1 + drivers/tty/ehv_bytechan.c | 888 +++ 5 files changed, 926 insertions(+), 0 deletions(-) create mode 100644 drivers/tty/ehv_bytechan.c diff --git a/arch/powerpc/include/asm/udbg.h b/arch/powerpc/include/asm/udbg.h index 93e05d1..5354ae9 100644 --- a/arch/powerpc/include/asm/udbg.h +++ b/arch/powerpc/include/asm/udbg.h @@ -54,6 +54,7 @@ extern void __init udbg_init_40x_realmode(void); extern void __init udbg_init_cpm(void); extern void __init udbg_init_usbgecko(void); extern void __init udbg_init_wsp(void); +extern void __init udbg_init_ehv_bc(void); #endif /* __KERNEL__ */ #endif /* _ASM_POWERPC_UDBG_H */ diff --git a/arch/powerpc/kernel/udbg.c b/arch/powerpc/kernel/udbg.c index faa82c1..b4607a9 100644 --- a/arch/powerpc/kernel/udbg.c +++ b/arch/powerpc/kernel/udbg.c @@ -67,6 +67,8 @@ void __init udbg_early_init(void) udbg_init_usbgecko(); #elif defined(CONFIG_PPC_EARLY_DEBUG_WSP) udbg_init_wsp(); +#elif defined(CONFIG_PPC_EARLY_DEBUG_EHV_BC) + udbg_init_ehv_bc(); #endif #ifdef CONFIG_PPC_EARLY_DEBUG diff --git a/drivers/tty/Kconfig b/drivers/tty/Kconfig index bd7cc05..535af0a 100644 --- a/drivers/tty/Kconfig +++ b/drivers/tty/Kconfig @@ -350,3 +350,37 @@ config TRACE_SINK If you select this option, you need to select "Trace data router for MIPI P1149.7 cJTAG standard". + +config PPC_EPAPR_HV_BYTECHAN + tristate "ePAPR hypervisor byte channel driver" + depends on FSL_SOC + help + This driver creates /dev entries for each ePAPR hypervisor byte + channel, thereby allowing applications to communicate with byte + channels as if they were serial ports. + +config PPC_EARLY_DEBUG_EHV_BC + bool "Early console (udbg) support for ePAPR hypervisors" + depends on PPC_EPAPR_HV_BYTECHAN + help + Select this option to enable early console (a.k.a. "udbg") support + via an ePAPR byte channel. You also need to choose the byte channel + handle below. + +config PPC_EARLY_DEBUG_EHV_BC_HANDLE + int "Byte channel handle for early console (udbg)" + depends on PPC_EARLY_DEBUG_EHV_BC + default 0 + help + If you want early console (udbg) output through a byte channel, + specify the handle of the byte channel to use. + + For this to work, the byte channel driver must be compiled + in-kernel, not as a module. + + Note that only one early console driver can be enabled, so don't + enable any others if you enable this one. + + If the number you specify is not a valid byte channel handle, then + there simply will be no early console output. This is true also + if you don't boot under a hypervisor at all. diff --git a/drivers/tty/Makefile b/drivers/tty/Makefile index ea89b0b..2953059 100644 --- a/drivers/tty/Makefile +++ b/drivers/tty/Makefile @@ -26,5 +26,6 @@ obj-$(CONFIG_ROCKETPORT) += rocket.o obj-$(CONFIG_SYNCLINK_GT) += synclink_gt.o obj-$(CONFIG_SYNCLINKMP) += synclinkmp.o obj-$(CONFIG_SYNCLINK) += synclink.o +obj-$(CONFIG_PPC_EPAPR_HV_BYTECHAN) += ehv_bytechan.o obj-y += ipwireless/ diff --git a/drivers/tty/ehv_bytechan.c b/drivers/tty/ehv_bytechan.c new file mode 100644 index 000..e67f70b --- /dev/null +++ b/drivers/tty/ehv_bytechan.c @@ -0,0 +1,888 @@ +/* ePAPR hypervisor byte channel device driver + * + * Copyright 2009-2011 Freescale Semiconductor, Inc. + * + * Author: Timur Tabi + * + * This file is licensed under the terms of the GNU General Public License + * version 2. This program is licensed "as is" without any warranty of any + * kind, whether express or implied. + * + * This driver support three distinct interfaces, all of which are related to + * ePAPR hypervisor byte channels. + * + * 1) An early-console (udbg) driver. This provides early console output + * through a byte channel. The byte channel handle must be specified in a + * Kconfig option. + * + * 2) A normal console driver. Output is sent
Re: linux-next: build failure after merge of the final tree (tty tree related)
Greg KH wrote: >> > MSR_GS is defined in arch/powerpc/include/asm/reg_booke.h which is >> > included by arch/powerpc/include/asm/reg.h but only when defined >> > (CONFIG_BOOKE) || defined(CONFIG_40x). > Thanks for the report. > > Timur, care to send a fixup patch for this so this gets resolved? Is there some trick to building allyesconfig on PowerPC? When I do try that, I get all sorts of weird build errors, and it dies long before it gets to my driver. I get stuff like: LD arch/powerpc/sysdev/xics/built-in.o WARNING: arch/powerpc/sysdev/xics/built-in.o(.text+0x1310): Section mismatch in reference from the function .icp_native_init() to the function .init.text:.icp_native_init_one_node() The function .icp_native_init() references the function __init .icp_native_init_one_node(). This is often because .icp_native_init lacks a __init annotation or the annotation of .icp_native_init_one_node is wrong. and AS arch/powerpc/kernel/head_64.o arch/powerpc/kernel/exceptions-64s.S: Assembler messages: arch/powerpc/kernel/exceptions-64s.S:1151: Error: attempt to move .org backwards arch/powerpc/kernel/exceptions-64s.S:1160: Error: attempt to move .org backwards make[1]: *** [arch/powerpc/kernel/head_64.o] Error 1 I guess I don't have the right compiler. Anyway, I think I know how to fix the break that Stephen is seeing. I will post a v4 patch in a few minutes. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: kvm PCI assignment & VFIO ramblings
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. Alex ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: build failure after merge of the final tree (tty tree related)
On Thu, Aug 25, 2011 at 04:18:43PM +1000, Stephen Rothwell wrote:
> Hi all,
>
> After merging the final tree, today's linux-next build (powerpc
> allyesconfig) failed like this:
>
> drivers/tty/ehv_bytechan.c: In function 'udbg_init_ehv_bc':
> drivers/tty/ehv_bytechan.c:230:18: error: 'MSR_GS' undeclared (first use in
> this function)
> drivers/tty/ehv_bytechan.c: In function 'ehv_bc_console_write':
> drivers/tty/ehv_bytechan.c:289:24: warning: cast from pointer to integer of
> different size
> drivers/tty/ehv_bytechan.c: In function 'ehv_bc_console_init':
> drivers/tty/ehv_bytechan.c:355:24: warning: cast to pointer from integer of
> different size
>
> Caused by commit dcd83aaff1c8 ("tty/powerpc: introduce the ePAPR embedded
> hypervisor byte channel driver").
>
> MSR_GS is defined in arch/powerpc/include/asm/reg_booke.h which is
> included by arch/powerpc/include/asm/reg.h but only when defined
> (CONFIG_BOOKE) || defined(CONFIG_40x).
Thanks for the report.
Timur, care to send a fixup patch for this so this gets resolved?
greg k-h
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: build failure after merge of the final tree (tty tree related)
On Aug 25, 2011, at 9:08 AM, Greg KH wrote: > On Thu, Aug 25, 2011 at 04:18:43PM +1000, Stephen Rothwell wrote: >> > > Thanks for the report. > > Timur, care to send a fixup patch for this so this gets resolved? Yes, I will do it ASAP, probably within the next two hours. > ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: kvm PCI assignment & VFIO ramblings
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: > > On Tue, Aug 23, 2011 at 01:08:29PM -0400, Alex Williamson wrote: > > > On Tue, 2011-08-23 at 15:14 +0200, Roedel, Joerg wrote: > > > > > > Handling it through fds is a good idea. This makes sure that everything > > > > belongs to one process. I am not really sure yet if we go the way to > > > > just bind plain groups together or if we create meta-groups. The > > > > meta-groups thing seems somewhat cleaner, though. > > > > > > I'm leaning towards binding because we need to make it dynamic, but I > > > don't really have a good picture of the lifecycle of a meta-group. > > > > In my view the life-cycle of the meta-group is a subrange of the > > qemu-instance's life-cycle. > > I guess I mean the lifecycle of a super-group that's actually exposed as > a new group in sysfs. Who creates it? How? How are groups dynamically > added and removed from the super-group? The group merging makes sense > to me because it's largely just an optimization that qemu will try to > merge groups. If it works, great. If not, it manages them separately. > When all the devices from a group are unplugged, unmerge the group if > necessary. Right. The super-group thing is an optimization. > 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? 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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/time: When starting the decrementer don't zero the other bits in TCR
Clearing the other TCR bits might break code that sets them (e.g. to setup the watchdog or fixed interval timer) before start_cpu_decrementer() gets called. Signed-off-by: Laurentiu Tudor --- arch/powerpc/kernel/time.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c index 03b29a6..e8b5cdc 100644 --- a/arch/powerpc/kernel/time.c +++ b/arch/powerpc/kernel/time.c @@ -721,7 +721,7 @@ void start_cpu_decrementer(void) mtspr(SPRN_TSR, TSR_ENW | TSR_WIS | TSR_DIS | TSR_FIS); /* Enable decrementer interrupt */ - mtspr(SPRN_TCR, TCR_DIE); + mtspr(SPRN_TCR, mfspr(SPRN_TCR) | TCR_DIE); #endif /* defined(CONFIG_BOOKE) || defined(CONFIG_40x) */ } -- 1.7.1 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
When set mtu 9600 by gfar_change_mtu, the maxfrm register is greater than 9600
Hi: When set MTU to 9600 by gfar_change_mtu(), the maxfrm register will be set to 9728 which is greater than 9600 in gianfar.c. But the MPC8315 Reference manual says the value of maxfrm can not greater than 9600. Is it a defect, Do we need to fix it? -- Best Reagrds, Roy | RongQing Li ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3] mtd/nand : workaround for Freescale FCM to support large-page Nand chip
Hi, LiuShuo a écrit : > 于 2011年08月23日 18:02, Matthieu CASTET 写道: >> LiuShuo a écrit : >>> 于 2011年08月19日 00:25, Scott Wood 写道: On 08/17/2011 09:33 PM, b35...@freescale.com wrote: > From: Liu Shuo > > Freescale FCM controller has a 2K size limitation of buffer RAM. In order > to support the Nand flash chip whose page size is larger than 2K bytes, > we divide a page into multi-2K pages for MTD layer driver. In that case, > we force to set the page size to 2K bytes. We convert the page address of > MTD layer driver to a real page address in flash chips and a column index > in fsl_elbc driver. We can issue any column address by UA instruction of > elbc controller. > > NOTE: Due to there is a limitation of 'Number of Partial Program Cycles in > the Same Page (NOP)', the flash chip which is supported by this workaround > have to meet below conditions. > 1. page size is not greater than 4KB > 2. 1) if main area and spare area have independent NOPs: > main area NOP:>=3 > spare area NOP:>=2? How often are the NOPs split like this? > 2) if main area and spare area have a common NOP: > NOP :>=4 This depends on how the flash is used. If you treat it as a NOP1 flash (e.g. run ubifs rather than jffs2), then you need NOP2 for a 4K chip and NOP4 for an 8K chip. OTOH, if you would be making full use of NOP4 on a real 2K chip, you'll need NOP8 for a 4K chip. The NOP restrictions should be documented in the code itself, not just in the git changelog. Maybe print it to the console when this hack is used, along with the NOP value read from the ID. >>> We can't read the NOP from the ID on any chip. Some chips don't >>> give this infomation.(e.g. Micron MT29F4G08BAC) >> Doesn't the micron chip provide it with onfi info ? > Sorry, there is something wrong with my expression. > We can get the NOP info from datasheet, but can't get it by READID > command in code. > ok I was thinking the micron chip was a 4K nand. But it is an old 2K. Why do you want NOP from it ? Also can you reply my question about the sequence you use when trying to read 4k with one command. Thanks Matthieu ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3] mtd/nand : workaround for Freescale FCM to support large-page Nand chip
On Tue, 2011-08-23 at 11:12 -0500, Scott Wood wrote: > On 08/23/2011 05:02 AM, Matthieu CASTET wrote: > > LiuShuo a écrit : > >> We can't read the NOP from the ID on any chip. Some chips don't > >> give this infomation.(e.g. Micron MT29F4G08BAC) > > Are there any 4K+ chips (especially ones with insufficient NOP) that > don't have the info? > > This chip is 2K and NOP8. > > Is there an easy way (without needing to have every datasheet for every > chip ever made) to determine at runtime which chips supply this information? > > > Doesn't the micron chip provide it with onfi info ? > > This chip doesn't appear to be ONFI. Few quick thoughts. 1. I think that if driver is able to detect flash NOP parameter and refuse flashes with too low NOP, then your change is OK. 2. For ONFI flashes, can we take NOP from ONFI info? 3. For non-ONFI chip, is it fair to conclude that MLCs _all_ have NOP 1? Can distinguish between MLC/SLC? If not, can this table help: http://www.linux-mtd.infradead.org/nand-data/nanddata.html? If needed, can we put "bits-per-cell" data to 'struct nand_flash_dev nand_flash_ids' ? 4. Can we add a NOP field to 'struct nand_flash_dev nand_flash_ids' array? -- Best Regards, Artem Bityutskiy ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Kernel boot up
On 2011-08-25 01:57, smitha.va...@wipro.com wrote: Hi Scott, I am currently trying to bring up 2.6.39 kernel on a target based on MPC8247 Processor, using the attched .dts file . I get the below logs while the kernel is booting. I see that the unflattening of the device tree and the initial loading of the kernel and ramdisk file system is happening correctly. Can you point me where exactly I can look for this issue. I am attaching the .config and .dts file I am using. There doesn't seem to be anything wrong with the kernel in this log. The failure is in the user code - in particular, udev is giving up with these errors: /sbin/udevstart: '/lib/libc.so.6' library contains unsupported TLS After that, all is lost as there will be no console, etc, for the rest of the system to use... You need to examine how you built the root file system and why you are getting these errors. This problem seems to be unique to uclibc bootm 100 200 c0 ## Current stack ends at 0x03e93cc8 * kernel: cmdline image address = 0x0100 ## Booting kernel from Legacy Image at 0100 ... Image Name: Linux-2.6.39 Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size: 1766015 Bytes = 1.7 MiB Load Address: Entry Point: Verifying Checksum ... OK kernel data at 0x0140, len = 0x001af27f (1766015) * ramdisk: cmdline image address = 0x0200 ## Loading init Ramdisk from Legacy Image at 0200 ... Image Name: Image Type: PowerPC Linux RAMDisk Image (gzip compressed) Data Size: 221 Bytes = 2.1 MiB Load Address: Entry Point: Verifying Checksum ... OK ramdisk start = 0x0240, ramdisk end = 0x0221bd67 * fdt: cmdline image address = 0x00c0 ## Checking for 'FDT'/'FDT Image' at 00c0 * fdt: raw FDT blob ## Flattened Device Tree blob at 00c0 Booting using the fdt blob at 0xc0 of_flat_tree at 0x00c0 size 0x0f12 Uncompressing Kernel Image ... OK kernel loaded at 0x, end = 0x00389d20 ## initrd_high = 0x, copy_to_ram = 1 Loading Ramdisk to 03c76000, end 03e91d27 ... OK ramdisk load start = 0x03c76000, ramdisk load end = 0x03e91d27 ## device tree at 00c0 ... 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 ) ... 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) ) #5 Wed Aug 24 15:02:07 IST 2011 Found initrd at 0xc3c76000:0xc3e91d27 No bcsr in device tree Zone PFN ranges: DMA 0x -> 0x4000 Normal empty Movable zone start PFN for each node early_node_map[1] active PFN ranges 0: 0x -> 0x4000 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: 57972k/65536k available (3524k kernel code, 7564k reserved, 100k data, 1 137k bss, 168k init) Kernel virtual memory layout: * 0xfffdf000..0xf000 : fixmap * 0xfdfb6000..0xfe00 : early ioremap * 0xc500..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 at 0 vgaarb: loaded Switching to clocksource timebase brd: module loaded loop: module loaded of-flash ff80.flash: do_map_probe() failed 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 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 Freeing unused kernel memory: 168k init Populating /dev using udev: /sbin/udevd: '/lib/libc.so.6' library contains unsup ported TLS /sbin/udevd: '/lib/libc.so.6' library contains unsupported TLS /sbin/udevd: can't load library 'libc.so.6' FAIL /sbin/udevstart: '/lib/libc.so.6' library contains unsupported TLS /sbin/udevstart: '/lib/libc.so.6' library contains unsupported TLS /sbin/udevstart: can't load library 'libc.so.6' FAIL done Starting network... Regards, Smitha *Please do not print this email unless it is absolutely necessary. * The information contained in this electron
Re: [PATCH v3] mtd/nand : workaround for Freescale FCM to support large-page Nand chip
On Mon, 2011-08-22 at 10:58 -0500, Scott Wood wrote: > On 08/22/2011 05:58 AM, Artem Bityutskiy wrote: > > On Fri, 2011-08-19 at 13:10 -0500, Scott Wood wrote: > >> On 08/19/2011 03:57 AM, Matthieu CASTET wrote: > >>> How the bad block marker are handled with this remapping ? > >> > >> It has to be migrated prior to first use (this needs to be documented, > >> and ideally a U-Boot command provided do do this), or else special > >> handling would be needed when building the BBT. The only way around > >> this would be to do ECC in software, and do the buffering needed to let > >> MTD treat it as a 4K chip. > > > > It really feels like a special hack which would better not go to > > mainline - am I the only one with such feeling? If yes, probably I am > > wrong... > > While the implementation is (of necessity) a hack, the feature is > something that multiple people have been asking for (it's not a special > case for a specific user). They say 2K chips are getting more difficult > to obtain. It doesn't change anything for people using 512/2K chips, > and (in its current form) doesn't introduce significant complexity to > the driver. I'm not sure how maintaining it out of tree would be a > better situation for anyone. I am just afraid that (a) other drivers will do this (b) this will start causing various weird bug-reports... -- Best Regards, Artem Bityutskiy ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: kvm PCI assignment & VFIO ramblings
On Wed, Aug 24, 2011 at 10:56:13AM -0400, Alex Williamson wrote: > On Wed, 2011-08-24 at 10:43 +0200, Joerg Roedel wrote: > > A side-note: Might it be better to expose assigned devices in a guest on > > a seperate bus? This will make it easier to emulate an IOMMU for the > > guest inside qemu. > > I think we want that option, sure. A lot of guests aren't going to > support hotplugging buses though, so I think our default, map the entire > guest model should still be using bus 0. The ACPI gets a lot more > complicated for that model too; dynamic SSDTs? Thanks, Ok, if only AMD-Vi should be emulated then it is not strictly necessary. For this IOMMU we can specify that devices on the same bus belong to different IOMMUs. So we can implement an IOMMU that handles internal qemu-devices and one that handles pass-through devices. Not sure if this is possible with VT-d too. Okay VT-d emulation would also require that the devices emulation of a PCIe bridge, 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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: kvm PCI assignment & VFIO ramblings
Hi Alex,
On Wed, Aug 24, 2011 at 05:13:49PM -0400, Alex Williamson wrote:
> Is this roughly what you're thinking of for the iommu_group component?
> Adding a dev_to_group iommu ops callback let's us consolidate the sysfs
> support in the iommu base. Would AMD-Vi do something similar (or
> exactly the same) for group #s? Thanks,
The concept looks good, I have some comments, though. On AMD-Vi the
implementation would look a bit different because there is a
data-structure were the information can be gathered from, so no need for
PCI bus scanning there.
> diff --git a/drivers/base/iommu.c b/drivers/base/iommu.c
> index 6e6b6a1..6b54c1a 100644
> --- a/drivers/base/iommu.c
> +++ b/drivers/base/iommu.c
> @@ -17,20 +17,56 @@
> */
>
> #include
> +#include
> #include
> #include
> #include
> #include
> #include
> +#include
>
> static struct iommu_ops *iommu_ops;
>
> +static ssize_t show_iommu_group(struct device *dev,
> + struct device_attribute *attr, char *buf)
> +{
> + return sprintf(buf, "%lx", iommu_dev_to_group(dev));
Probably add a 0x prefix so userspace knows the format?
> +}
> +static DEVICE_ATTR(iommu_group, S_IRUGO, show_iommu_group, NULL);
> +
> +static int add_iommu_group(struct device *dev, void *unused)
> +{
> + if (iommu_dev_to_group(dev) >= 0)
> + return device_create_file(dev, &dev_attr_iommu_group);
> +
> + return 0;
> +}
> +
> +static int device_notifier(struct notifier_block *nb,
> +unsigned long action, void *data)
> +{
> + struct device *dev = data;
> +
> + if (action == BUS_NOTIFY_ADD_DEVICE)
> + return add_iommu_group(dev, NULL);
> +
> + return 0;
> +}
> +
> +static struct notifier_block device_nb = {
> + .notifier_call = device_notifier,
> +};
> +
> void register_iommu(struct iommu_ops *ops)
> {
> if (iommu_ops)
> BUG();
>
> iommu_ops = ops;
> +
> + /* FIXME - non-PCI, really want for_each_bus() */
> + bus_register_notifier(&pci_bus_type, &device_nb);
> + bus_for_each_dev(&pci_bus_type, NULL, NULL, add_iommu_group);
> }
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.
> bool iommu_found(void)
> @@ -94,6 +130,14 @@ int iommu_domain_has_cap(struct iommu_domain *domain,
> }
> EXPORT_SYMBOL_GPL(iommu_domain_has_cap);
>
> +long iommu_dev_to_group(struct device *dev)
> +{
> + if (iommu_ops->dev_to_group)
> + return iommu_ops->dev_to_group(dev);
> + return -ENODEV;
> +}
> +EXPORT_SYMBOL_GPL(iommu_dev_to_group);
Please rename this to iommu_device_group(). The dev_to_group name
suggests a conversion but it is actually just a property of the device.
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.
> +
> int iommu_map(struct iommu_domain *domain, unsigned long iova,
> phys_addr_t paddr, int gfp_order, int prot)
> {
> diff --git a/drivers/pci/intel-iommu.c b/drivers/pci/intel-iommu.c
> index f02c34d..477259c 100644
> --- a/drivers/pci/intel-iommu.c
> +++ b/drivers/pci/intel-iommu.c
> @@ -404,6 +404,7 @@ static int dmar_map_gfx = 1;
> static int dmar_forcedac;
> static int intel_iommu_strict;
> static int intel_iommu_superpage = 1;
> +static int intel_iommu_no_mf_groups;
>
> #define DUMMY_DEVICE_DOMAIN_INFO ((struct device_domain_info *)(-1))
> static DEFINE_SPINLOCK(device_domain_lock);
> @@ -438,6 +439,10 @@ static int __init intel_iommu_setup(char *str)
> printk(KERN_INFO
> "Intel-IOMMU: disable supported super page\n");
> intel_iommu_superpage = 0;
> + } else if (!strncmp(str, "no_mf_groups", 12)) {
> + printk(KERN_INFO
> + "Intel-IOMMU: disable separate groups for
> multifunction devices\n");
> + intel_iommu_no_mf_groups = 1;
This should really be a global iommu option and not be VT-d specific.
>
> str += strcspn(str, ",");
> @@ -3902,6 +3907,52 @@ static int intel_iommu_domain_has_cap(struct
> iommu_domain *domain,
> return 0;
> }
>
> +/* Group numbers are arbitrary. Device with the same group number
> + * indicate the iommu cannot differentiate between them. To avoid
> + * tracking used groups we just use the seg|bus|devfn of the lowest
> + * level we're able to differentiate devices */
> +static long intel_iommu_dev_to_group(struct device *dev)
> +{
> + struct pci_dev *pdev = to_pci_dev(dev);
> + struct pci_dev *bridge;
> + union {
> + struct {
> + u8 devfn;
> + u8 bus;
> + u16 segment;
> + } pci;
> + u32 group;
> + } id;
> +
> + if (iommu_no_mapping(dev))
Re: [PATCH 2/2] mmc: Use mmc_delay() instead of mdelay() for time delay
On Thu, Aug 25, 2011 at 5:54 PM, Chunhe Lan 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 > Signed-off-by: Chunhe Lan > Cc: Chris Ball > --- > 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 > > #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. Thank you, Kyungmin Park > > #define DRIVER_NAME "sdhci" > > @@ -186,7 +187,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 +958,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 +1128,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 +1193,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 +1713,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 > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-mmc" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/2] mmc: Use mmc_delay() instead of mdelay() for time delay
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 Signed-off-by: Chunhe Lan Cc: Chris Ball --- 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 #include "sdhci.h" +#include "../core/core.h" #define DRIVER_NAME "sdhci" @@ -186,7 +187,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 +958,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 +1128,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 +1193,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 +1713,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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/2] mmc: Use mmc_delay() instead of mdelay() for time delay
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 Signed-off-by: Chunhe Lan Cc: Chris Ball --- drivers/mmc/host/sdhci-esdhc.h |6 -- 1 files changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/mmc/host/sdhci-esdhc.h b/drivers/mmc/host/sdhci-esdhc.h index c3b08f1..42b1d9eb 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 @@ -14,6 +14,8 @@ #ifndef _DRIVERS_MMC_SDHCI_ESDHC_H #define _DRIVERS_MMC_SDHCI_ESDHC_H +#include "../core/core.h" + /* * Ops and quirks for the Freescale eSDHC controller. */ @@ -73,7 +75,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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
