linux-next: build failure after merge of the final tree (tty tree related)

2011-08-25 Thread Stephen Rothwell 
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).

I have reverted that commit for today.
-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpdHbwbwdanV.pgp
Description: PGP signature
___
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

2011-08-25 Thread 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 b36...@freescale.com
Signed-off-by: Chunhe Lan chunhe@freescale.com
Cc: Chris Ball c...@laptop.org
---
 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 w.s...@pengutronix.de
@@ -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

[PATCH 2/2] mmc: Use mmc_delay() instead of mdelay() for time delay

2011-08-25 Thread 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 b36...@freescale.com
Signed-off-by: Chunhe Lan chunhe@freescale.com
Cc: Chris Ball c...@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
 
 #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

Re: [PATCH 2/2] mmc: Use mmc_delay() instead of mdelay() for time delay

2011-08-25 Thread Kyungmin Park 
On Thu, Aug 25, 2011 at 5:54 PM, Chunhe Lan chunhe@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 b36...@freescale.com
 Signed-off-by: Chunhe Lan chunhe@freescale.com
 Cc: Chris Ball c...@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.

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

Re: kvm PCI assignment VFIO ramblings

2011-08-25 Thread Roedel, Joerg 
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 linux/bug.h
 +#include linux/device.h
  #include linux/types.h
  #include linux/module.h
  #include linux/slab.h
  #include linux/errno.h
  #include linux/iommu.h
 +#include linux/pci.h
  
  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))
 + return -ENODEV;
 +
 +

Re: kvm PCI assignment VFIO ramblings

2011-08-25 Thread Roedel, Joerg 
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: [PATCH v3] mtd/nand : workaround for Freescale FCM to support large-page Nand chip

2011-08-25 Thread Artem Bityutskiy 
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: Kernel boot up

2011-08-25 Thread Gary Thomas 

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 bio-0 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 m...@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
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

Re: [PATCH v3] mtd/nand : workaround for Freescale FCM to support large-page Nand chip

2011-08-25 Thread Artem Bityutskiy 
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: [PATCH v3] mtd/nand : workaround for Freescale FCM to support large-page Nand chip

2011-08-25 Thread Matthieu CASTET 
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 Shuob35...@freescale.com

 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

When set mtu 9600 by gfar_change_mtu, the maxfrm register is greater than 9600

2011-08-25 Thread Rongqing Li 

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

[PATCH] powerpc/time: When starting the decrementer don't zero the other bits in TCR

2011-08-25 Thread Laurentiu Tudor 
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 laurentiu.tu...@freescale.com
---
 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

Re: kvm PCI assignment VFIO ramblings

2011-08-25 Thread Roedel, Joerg 
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

Re: linux-next: build failure after merge of the final tree (tty tree related)

2011-08-25 Thread Timur Tabi 


On Aug 25, 2011, at 9:08 AM, Greg KH g...@kroah.com 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: linux-next: build failure after merge of the final tree (tty tree related)

2011-08-25 Thread Greg KH 
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: kvm PCI assignment VFIO ramblings

2011-08-25 Thread Alexander Graf 

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)

2011-08-25 Thread Timur Tabi 
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

[PATCH] [v4] tty/powerpc: introduce the ePAPR embedded hypervisor byte channel driver

2011-08-25 Thread Timur Tabi 
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 ti...@freescale.com
---
 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 ti...@freescale.com
+ *
+ * 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

Re: kvm PCI assignment VFIO ramblings

2011-08-25 Thread Don Dutile 

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 @@
   */

  #includelinux/bug.h
+#includelinux/device.h
  #includelinux/types.h
  #includelinux/module.h
  #includelinux/slab.h
  #includelinux/errno.h
  #includelinux/iommu.h
+#includelinux/pci.h

  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

Re: linux-next: build failure after merge of the final tree (tty tree related)

2011-08-25 Thread Stephen Rothwell 
Hi Timur,

On Thu, 25 Aug 2011 10:22:05 -0500 Timur Tabi ti...@freescale.com 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: [PATCH] [v4] tty/powerpc: introduce the ePAPR embedded hypervisor byte channel driver

2011-08-25 Thread Greg KH 
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 ti...@freescale.com

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: [PATCH] [v4] tty/powerpc: introduce the ePAPR embedded hypervisor byte channel driver

2011-08-25 Thread Timur Tabi 
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

[PATCH] xics/icp_natives: add __init to marker icp_native_init()

2011-08-25 Thread Arnaud Lacombe 
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 ti...@freescale.com
Signed-off-by: Arnaud Lacombe lacom...@gmail.com
---
 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: linux-next: build failure after merge of the final tree (tty tree related)

2011-08-25 Thread Arnaud Lacombe 
Hi,

On Thu, Aug 25, 2011 at 11:51 AM, Stephen Rothwell s...@canb.auug.org.au 
wrote:
 Hi Timur,

 On Thu, 25 Aug 2011 10:22:05 -0500 Timur Tabi ti...@freescale.com 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] tty/powerpc: fix build break with ehv_bytechan.c on allyesconfig

2011-08-25 Thread Timur Tabi 
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 ti...@freescale.com
---
 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: [PATCH] tty/powerpc: fix build break with ehv_bytechan.c on allyesconfig

2011-08-25 Thread Greg KH 
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

Re: kvm PCI assignment VFIO ramblings

2011-08-25 Thread Roedel, Joerg 
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: kvm PCI assignment VFIO ramblings

2011-08-25 Thread Alex Williamson 
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 linux/bug.h
  +#include linux/device.h
   #include linux/types.h
   #include linux/module.h
   #include linux/slab.h
   #include linux/errno.h
   #include linux/iommu.h
  +#include linux/pci.h
   
   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 really be a global iommu option and not be VT-d specific.

You think?  It's meaningless on benh's power systems.

   
  str

Re: [PATCH] tty/powerpc: fix build break with ehv_bytechan.c on allyesconfig

2011-08-25 Thread Timur Tabi 
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

2011-08-25 Thread Joerg Roedel 
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

[PATCH] [v2] tty/powerpc: fix build break with ehv_bytechan.c on allyesconfig

2011-08-25 Thread Timur Tabi 
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 ti...@freescale.com
---
 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: [PATCH] tty/powerpc: fix build break with ehv_bytechan.c on allyesconfig

2011-08-25 Thread Greg KH 
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

Re: [PATCH] tty/powerpc: fix build break with ehv_bytechan.c on allyesconfig

2011-08-25 Thread Timur Tabi 
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

2011-08-25 Thread Greg KH 
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] xics/icp_natives: add __init to marker icp_native_init()

2011-08-25 Thread Timur Tabi 
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 ti...@freescale.com
 Signed-off-by: Arnaud Lacombe lacom...@gmail.com

Acked-by: Timur Tabi ti...@freescale.com

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: Kernel boot up

2011-08-25 Thread Scott Wood 
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 m...@qualcomm.com
 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()

2011-08-25 Thread Arnaud Lacombe 
Hi,

On Thu, Aug 25, 2011 at 3:24 PM, Timur Tabi ti...@freescale.com 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 ti...@freescale.com
 Signed-off-by: Arnaud Lacombe lacom...@gmail.com

 Acked-by: Timur Tabi ti...@freescale.com

 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: linux-next: build failure after merge of the final tree (tty tree related)

2011-08-25 Thread Stephen Rothwell 
Hi Arnaud,

On Thu, 25 Aug 2011 12:09:20 -0400 Arnaud Lacombe lacom...@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 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

[PATCH] dtc: remove some warnings

2011-08-25 Thread Stephen Rothwell 
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 s...@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 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: [PATCH] [v2] tty/powerpc: fix build break with ehv_bytechan.c on allyesconfig

2011-08-25 Thread Stephen Rothwell 
Hi all,

On Thu, 25 Aug 2011 13:06:57 -0500 Timur Tabi ti...@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 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

Re: kvm PCI assignment VFIO ramblings

2011-08-25 Thread David Gibson 
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: kvm PCI assignment VFIO ramblings

2011-08-25 Thread David Gibson 
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: [PATCH 2/2] [PowerPC Book3E] Introduce new ptrace debug feature flag

2011-08-25 Thread David Gibson 
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: [PATCH] dtc: remove some warnings

2011-08-25 Thread David Gibson 
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 s...@canb.auug.org.au

Acked-by: David Gibson da...@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
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] dtc: remove some warnings

2011-08-25 Thread Stephen Rothwell 
Hi David,

On Fri, 26 Aug 2011 14:49:02 +1000 David Gibson d...@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 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