* Re: [patch] infiniband: uverbs: limit the number of entries
From: Dan Carpenter @ 2010-10-07 16:59 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Roland Dreier, Sean Hefty, Hal Rosenstock,
linux-rdma-u79uwXL29TY76Z2rM5mHXA,
kernel-janitors-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20101007161649.GD21206-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
On Thu, Oct 07, 2010 at 10:16:49AM -0600, Jason Gunthorpe wrote:
> On Thu, Oct 07, 2010 at 09:16:10AM +0200, Dan Carpenter wrote:
> > If we don't limit cmd.ne then the multiplications can overflow. This
> > will allocate a small amount of RAM successfully for the "resp" and
> > "wc" buffers. The heap will get corrupted when we call ib_poll_cq().
>
> I think you could cap the number of returned entries to
> UVERBS_MAX_NUM_ENTRIES rather than return EINVAL. That might be more
> compatible with user space..
>
Good idea. I don't actually have this hardware, so I can't test it, but
that definitely sounds reasonable.
If we did that then UVERBS_MAX_NUM_ENTRIES could be lower than 1000.
What is a reasonable number?
regards,
dan carpenter
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [patch] infiniband: uverbs: limit the number of entries
From: Dan Carpenter @ 2010-10-07 16:59 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Roland Dreier, Sean Hefty, Hal Rosenstock,
linux-rdma-u79uwXL29TY76Z2rM5mHXA,
kernel-janitors-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20101007161649.GD21206-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
On Thu, Oct 07, 2010 at 10:16:49AM -0600, Jason Gunthorpe wrote:
> On Thu, Oct 07, 2010 at 09:16:10AM +0200, Dan Carpenter wrote:
> > If we don't limit cmd.ne then the multiplications can overflow. This
> > will allocate a small amount of RAM successfully for the "resp" and
> > "wc" buffers. The heap will get corrupted when we call ib_poll_cq().
>
> I think you could cap the number of returned entries to
> UVERBS_MAX_NUM_ENTRIES rather than return EINVAL. That might be more
> compatible with user space..
>
Good idea. I don't actually have this hardware, so I can't test it, but
that definitely sounds reasonable.
If we did that then UVERBS_MAX_NUM_ENTRIES could be lower than 1000.
What is a reasonable number?
regards,
dan carpenter
^ permalink raw reply
* Re: [PATCH 13/15] cifs: convert cifsFileInfo->count to non-atomic counter
From: Jeff Layton @ 2010-10-07 16:59 UTC (permalink / raw)
To: Steve French; +Cc: Suresh Jayaraman, linux-cifs-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <AANLkTi=MMzU6nr6+19PKW=gPKTdk9e-O5pjrYWmbV4AJ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Thu, 7 Oct 2010 10:37:54 -0500
Steve French <smfrench-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On Thu, Oct 7, 2010 at 7:43 AM, Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> > On Thu, 07 Oct 2010 17:42:57 +0530
> > Suresh Jayaraman <sjayaraman-l3A5Bk7waGM@public.gmane.org> wrote:
> >
> >> On 10/07/2010 04:48 PM, Jeff Layton wrote:
> >> > On Thu, 07 Oct 2010 14:18:50 +0530
> >> > Suresh Jayaraman <sjayaraman-l3A5Bk7waGM@public.gmane.org> wrote:
> >> >
> >> >> On 10/07/2010 01:24 AM, Jeff Layton wrote:
> >> >>> The count for cifsFileInfo is currently an atomic, but that just adds
> >> >>> complexity for little value. We generally need to hold cifs_file_list_lock
> >> >>> to traverse the lists anyway so we might as well make this counter
> >> >>> non-atomic and simply use the cifs_file_list_lock to protect it.
> >> >>>
> >> >>> Signed-off-by: Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> >> >>> ---
> >> >>> fs/cifs/cifsglob.h | 9 ++++++---
> >> >>> fs/cifs/file.c | 8 +++++---
> >> >>> 2 files changed, 11 insertions(+), 6 deletions(-)
> >> >>>
> >> >>> diff --git a/fs/cifs/cifsglob.h b/fs/cifs/cifsglob.h
> >> >>> index 531a768..f3c4e00 100644
> >> >>> --- a/fs/cifs/cifsglob.h
> >> >>> +++ b/fs/cifs/cifsglob.h
> >> >>> @@ -393,16 +393,19 @@ struct cifsFileInfo {
> >> >>> struct list_head llist; /* list of byte range locks we have. */
> >> >>> bool invalidHandle:1; /* file closed via session abend */
> >> >>> bool oplock_break_cancelled:1;
> >> >>> - atomic_t count; /* reference count */
> >> >>> + int count; /* refcount -- protected by cifs_file_list_lock */
> >> >>> struct mutex fh_mutex; /* prevents reopen race after dead ses*/
> >> >>> struct cifs_search_info srch_inf;
> >> >>> struct work_struct oplock_break; /* work for oplock breaks */
> >> >>> };
> >> >>>
> >> >>> -/* Take a reference on the file private data */
> >> >>> +/*
> >> >>> + * Take a reference on the file private data. Must be called with
> >> >>> + * cifs_file_list_lock held for read or write.
> >> >>> + */
> >> >>> static inline void cifsFileInfo_get(struct cifsFileInfo *cifs_file)
> >> >>> {
> >> >>> - atomic_inc(&cifs_file->count);
> >> >>> + ++cifs_file->count;
> >> >>
> >> >> Since we now use cifs_file_list_lock to protect cifs_file->count too,
> >> >> shouldn't all the callers of cifsFileInfo_get() need to acquire a write
> >> >> lock instead of read lock?
> >> >>
> >> >
> >> > I puzzled over that too, but it's not really necessary. The lock is
> >> > really there to make sure that the list traversals are safe from
> >> > removals. We do need the write lock when inserting or removing the
> >> > cifsFileInfo into the lists, but for incrementing a non-zero refcount a
> >> > read lock is sufficient. That will prevent cifsFileInfo_put from
> >> > racing in, decrementing the refcount and modifying the list since it
> >> > needs a write lock.
> >>
> >> Fine, but, isn't possible to get the refcount wrong due to calls to
> >> cifsFileInfo_get() from multiple callers?
> >>
> >
> > Argh...good point. Maybe we do need to make this a regular spinlock
> > after all. The times you can use a read lock safely are pretty limited
> > here.
> >
> >> > TBH, I think it would be far simpler (and maybe even more efficient) to
> >> > use a regular spinlock here, but I figured this would be easier to get
> >> > past review.
> >> >
> >>
> >> I'm little worried about the overhead as I'm not sure whether all the
> >> paths are low contention paths...
> >>
> >
> > I think they are generally low contention paths. Also, the lists are
> > generally very short so the time the lock is held is too. Unless most
> > of your accesses (like 90%) are read locked, then it's actually worse
> > to use a rwlock than a regular spinlock.
> >
> > Even if a regular spinlock adds some overhead, it's really unlikely to
> > make any real difference in performance. CIFS is almost always bound by
> > network latency, not CPU time.
> >
> > Steve, I mostly left this as a rwlock as I figured you might have
> > issues moving this to a normal spinlock. Would you?
>
> I doubt that a spinlock vs. a rwlock makes much difference,
> but a rwlock lock for list insertion/removal seems more intuitive
> and overloading it to also protect a counter adds complexity.
> Seems more natural to leave it as an atomic counter.
>
Unfortunately, it's not that simple. When the count goes to 0 on a put,
you need to atomically take the lock that protects the lists so that
you can safely remove it from those lists. You can't do that with a
rwlock_t.
It gets worse though -- if the atomic_t refcount can be increased while
you're holding the lock, then you need to check that refcount twice.
Once to get the lock, and then again to make sure it didn't change
while you were spinning on it.
For instance:
+ if (!atomic_dec_and_lock(&cifs_file->count, &cifs_file_list_lock))
+ return;
+
+ /* count can be incremented inside the lock, so must check again */
+ if (atomic_read(&cifs_file->count) > 0) {
+ spin_unlock(&cifs_file_list_lock);
+ return;
+ }
If we don't want to use atomics then we can go with a rwlock_t, but
then you need to ensure that any time you could increment the refcount
that you take a write_lock. That's almost all of the code that runs
under this lock. There will only be one or two seldom-used functions
that are able to use a read_lock at that point. rwlocks have more
overhead than simple spinlocks so again that's a loss.
Based on the above, I would argue that the most clear way to do this is
to use a simple spinlock and a simple (non-atomic) counter that is
protected by that lock.
Thoughts?
--
Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
^ permalink raw reply
* Re: [PATCH] sysctl: fix min/max handling in __do_proc_doulongvec_minmax()
From: Eric Dumazet @ 2010-10-07 16:59 UTC (permalink / raw)
To: Eric W. Biederman, Andrew Morton
Cc: Américo Wang, Robin Holt, linux-kernel, Willy Tarreau,
David S. Miller, netdev, James Morris, Pekka Savola (ipv6),
Patrick McHardy, Alexey Kuznetsov
In-Reply-To: <m1iq1e3qnn.fsf@fess.ebiederm.org>
Le jeudi 07 octobre 2010 à 09:37 -0700, Eric W. Biederman a écrit :
> The difference between long handling and int handling is a
> usability issue. I don't expect we will be exporting new
> vectors via sysctl, so the conversion of a handful of vectors
> from int to long is where this is most likely to be used.
>
> I skimmed through all of what I presume are the current users
> aka linux-2.6.36-rcX and there don't appear to be any users
> of proc_dounlongvec_minmax that use it's vector properties there.
>
> Which doubly tells me that incrementing the min and max pointers
> is not what we want to do.
>
Thats fine by me, thanks Eric.
Andrew, please remove previous patch from your tree and replace it by
following one :
[PATCH v2] sysctl: fix min/max handling in __do_proc_doulongvec_minmax()
When proc_doulongvec_minmax() is used with an array of longs,
and no min/max check requested (.extra1 or .extra2 being NULL), we
dereference a NULL pointer for the second element of the array.
Noticed while doing some changes in network stack for the "16TB problem"
Fix is to not change min & max pointers in
__do_proc_doulongvec_minmax(), so that all elements of the vector share
an unique min/max limit, like proc_dointvec_minmax().
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
kernel/sysctl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index f88552c..8e45451 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -2485,7 +2485,7 @@ static int __do_proc_doulongvec_minmax(void *data, struct ctl_table *table, int
kbuf[left] = 0;
}
- for (; left && vleft--; i++, min++, max++, first=0) {
+ for (; left && vleft--; i++, first=0) {
unsigned long val;
if (write) {
^ permalink raw reply related
* [U-Boot] Testing Data Cache for armv7 (beagleboard)
From: chris c @ 2010-10-07 16:57 UTC (permalink / raw)
To: u-boot
In-Reply-To: <4CAD6539.4030900@denx.de>
Heiko,
I was comparing time just by timing it manually. How did you instrument
u-boot to display the time?
As for the small versus large file, I did the same test for 1MB of data
using nand read and saw a x4 performance advantage. I also did a test on
mmc with 100 MB file and saw no performance increase. Looks like file size
doesn't matter.
So does that mean that MMC file loading will not benefit from dcache
enabled? Can anybody explain this?
Thanks.
On Thu, Oct 7, 2010 at 1:14 AM, Heiko Schocher <hs@denx.de> wrote:
> Hello Chris,
>
> chris chriss wrote:
> > I'm trying to test the cache on my beagle with a snapshot from the git
> tree
> > today. I tried it out by loading a file from the mmc with dcache off and
> > then dcache on. I didn't see any difference in speed. After reading
> this
> > commit (http://git.denx.de/?p=u-boot.git;a=commit;h=95c6f6d), I expected
> to
> > see a performance improvement.
>
> Here a log which actual reloacte code from Albert Aribaud and
> my fix patch for the beagle on the beagle board:
>
> 170.880 U-Boot 2010.09-00102-g456a0da-dirty (Oct 05 2010 - 14:41:10)
> 170.880
> 170.920 OMAP3530-GP ES3.0, CPU-OPP2, L3-165MHz, Max CPU Clock 600 mHz
> 170.920 OMAP3 Beagle board + LPDDR/NAND
> 170.960 I2C: ready
> 170.960 DRAM: 128 MiB
> 171.000 NAND: 256 MiB
> 174.000 In: serial
> 174.000 Out: serial
> 174.000 Err: serial
> 174.000 Beagle Rev C1/C2/C3
> 174.360 Die ID #00b000030000000004013f8a1700900c
> 175.200 Hit any key to stop autoboot: 0
> 175.440 OMAP3 beagleboard.org #
> 178.280 OMAP3 beagleboard.org # ica off
> 178.280 Instruction Cache is OFF
> 180.480 OMAP3 beagleboard.org # dca off
> 180.480 Data (writethrough) Cache is OFF
> 183.520 OMAP3 beagleboard.org # echo start ; nand read 80800000 0 7000000
> ; echo stop
> 0.000 start
> 0.000
> 0.000 NAND read: device 0 offset 0x0, size 0x7000000
> 114.040 NAND read from offset 0 failed -74
> 114.040 117440512 bytes read: ERROR
> 114.040 stop
> 135.880 OMAP3 beagleboard.org # ica on
> 135.880 Instruction Cache is ON
> 138.280 OMAP3 beagleboard.org # echo start ; nand read 80800000 0 7000000
> ; echo stop
> 0.000 start
> 0.000
> 0.000 NAND read: device 0 offset 0x0, size 0x7000000
> 95.120 NAND read from offset 0 failed -74
> 95.120 117440512 bytes read: ERROR
> 95.120 stop
> 160.880 OMAP3 beagleboard.org # dca on
> 160.880 Data (writethrough) Cache is ON
> 164.600 OMAP3 beagleboard.org # ica on
> 164.600 Instruction Cache is ON
> 166.080 OMAP3 beagleboard.org # echo start ; nand read 80800000 0 7000000
> ; echo stop
> 0.000 start
> 0.000
> 0.000 NAND read: device 0 offset 0x0, size 0x7000000
> 26.680 NAND read from offset 0 failed -74
> 26.680 117440512 bytes read: ERROR
> 26.680 stop
>
> > This is a capture of how I tested it...
> >
> > <capture>
> >
> > OMAP3 beagleboard.org # mmc init 1
> > mmc1 is available
> > OMAP3 beagleboard.org # dcache
> > Data (writethrough) Cache is OFF
> > OMAP3 beagleboard.org # fatload mmc 0:1 0x80000000 uImage.bin
> > reading uImage.bin
> >
> > 3852836 bytes read
> > OMAP3 beagleboard.org # dcache on
> > Data (writethrough) Cache is ON
> > OMAP3 beagleboard.org # fatload mmc 0:1 0x80000000 uImage.bin
> > reading uImage.bin
> >
> > 3852836 bytes read
> > OMAP3 beagleboard.org #
> >
> > </capture>
>
> How did you measured the time between start an end?
>
> Maybe uImage.bin is a little bit to small for seeing some
> effect?
>
> bye,
> Heiko
>
^ permalink raw reply
* [RFC][QEMU] ATI graphics VBIOS passthru support
From: Huang2, Wei @ 2010-10-07 16:56 UTC (permalink / raw)
To: Ian Jackson; +Cc: Xen-devel, Kay, Allen M
[-- Attachment #1.1: Type: text/plain, Size: 467 bytes --]
Hi Ian,
There have been a lot of interest on gfx passthru recently. This patch enables ATI VBIOS in passthru mode. The guest VM system BIOS (including Windows boot logo) can now show in passthru screen. We have tested with various Windows and Linux guest VMs. Please help review it. We are also looking forward to comments and suggestions from Xen community users.
Signed-off-by: Wei Huang <wei.huang2@amd.com>
Signed-off-by: Wei Wang <wei.wang2@amd.com>
[-- Attachment #1.2: Type: text/html, Size: 2524 bytes --]
[-- Attachment #2: ati_vbios_passthru_patch_v1.txt --]
[-- Type: text/plain, Size: 15074 bytes --]
diff --git a/hw/pass-through.c b/hw/pass-through.c
index 014144e..d27aeea 100644
--- a/hw/pass-through.c
+++ b/hw/pass-through.c
@@ -1379,9 +1379,17 @@ static void pt_ioport_map(PCIDevice *d, int i,
if (e_phys != -1)
{
/* Create new mapping */
- ret = xc_domain_ioport_mapping(xc_handle, domid, e_phys,
- assigned_device->bases[i].access.pio_base, e_size,
- DPCI_ADD_MAPPING);
+ if ( vga_skip_ioport_map(d) )
+ {
+ assigned_device->bases[i].e_physbase = -1;
+ }
+ else
+ {
+ ret = xc_domain_ioport_mapping(xc_handle, domid, e_phys,
+ assigned_device->bases[i].access.pio_base, e_size,
+ DPCI_ADD_MAPPING);
+ }
+
if ( ret != 0 )
{
PT_LOG("Error: create new mapping failed!\n");
diff --git a/hw/pass-through.h b/hw/pass-through.h
index e59eb52..19652c4 100644
--- a/hw/pass-through.h
+++ b/hw/pass-through.h
@@ -411,6 +411,11 @@ int pt_pci_host_write(int bus, int dev, int fn, u32 addr, u32 val, int len);
void intel_pch_init(PCIBus *bus);
int register_vga_regions(struct pt_dev *real_device);
int unregister_vga_regions(struct pt_dev *real_device);
+int vga_skip_ioport_map(PCIDevice *d);
+int igd_register_vga_regions(struct pt_dev *real_device);
+int igd_unregister_vga_regions(struct pt_dev *real_device);
+int ati_register_vga_regions(struct pt_dev *real_device);
+int ati_unregister_vga_regions(struct pt_dev *real_device);
int setup_vga_pt(struct pt_dev *real_device);
PCIBus *intel_pci_bridge_init(PCIBus *bus, int devfn, uint16_t vid,
uint16_t did, const char *name, uint16_t revision);
diff --git a/hw/pci.h b/hw/pci.h
index e4cc79a..4aa0373 100644
--- a/hw/pci.h
+++ b/hw/pci.h
@@ -54,6 +54,8 @@ extern target_phys_addr_t pci_mem_base;
#define PCI_VENDOR_ID_CIRRUS 0x1013
+#define PCI_VENDOR_ID_ATI 0x1002
+
#define PCI_VENDOR_ID_IBM 0x1014
#define PCI_DEVICE_ID_IBM_OPENPIC2 0xffff
diff --git a/hw/pt-graphics.c b/hw/pt-graphics.c
index 5dfcca2..b8f5a3a 100644
--- a/hw/pt-graphics.c
+++ b/hw/pt-graphics.c
@@ -8,11 +8,213 @@
#include <unistd.h>
#include <sys/ioctl.h>
+#include <sys/io.h>
#include <assert.h>
extern int gfx_passthru;
extern int igd_passthru;
+/*********************************/
+/* Code for ATI GFX Passthru */
+/*********************************/
+/* ATI VBIOS Working Mechanism
+ *
+ * Generally there are three memory resources (two MMIO and one PIO)
+ * associated with modern ATI gfx. VBIOS uses special tricks to figure out
+ * BARs, instead of using regular PCI config space read.
+ *
+ * (1) VBIOS relies on I/O port 0x3C3 to retrieve PIO BAR
+ * (2) VBIOS maintains a shadow copy of PCI configure space. It retries the
+ * MMIO BARs from this shadow copy via sending I/O requests to first two
+ * registers of PIO (MMINDEX and MMDATA). The workflow is like this:
+ * MMINDEX (register 0) is written with an index value, specifying the
+ * register VBIOS wanting to access. Then the shadowed data can be
+ * read/written from MMDATA (register 1). For two MMIO BARs, the index
+ * values are 0x4010 and 0x4014 respectively.
+ *
+ */
+
+#define ATI_BAR1_INDEX 0 //MMIO BAR1
+#define ATI_BAR2_INDEX 1 //MMIO BAR2
+#define ATI_BAR5_INDEX 4 //PIO BAR == BAR5
+
+#define ATI_BAR1_MMINDEX 0x4010 //data written to MMINDEX for MMIO BAR1
+#define ATI_BAR2_MMINDEX 0x4014 //data written to MMINDEX FOR MMIO BAR2
+
+struct ati_gfx_info {
+ int initialized; /* initialized already? */
+
+ /* PIO */
+ uint32_t host_pio_base; /* host base addr of PIO */
+ uint32_t guest_pio_base; /* guest base addr of PIO */
+ uint32_t pio_size; /* PIO size */
+
+ /* MMIO */
+ uint32_t guest_mmio_base1; /* guest base addr of MMIO 1 */
+ uint32_t guest_mmio_base2; /* guest base addr of MMIO 2 */
+
+ /* PIO MMINDEX access recording */
+ uint32_t pre_mmindex_data; /* previous data written to MMINDEX */
+};
+
+static struct ati_gfx_info gfx_info;
+
+/* Convert guest PIO port to host PIO port */
+static uint16_t gport_to_hport(uint16_t gport)
+{
+ return (gport - gfx_info.guest_pio_base) + gfx_info.host_pio_base;
+}
+
+/* Read host PIO port */
+static uint32_t ati_hw_in(uint16_t hport)
+{
+ unsigned val;
+
+ ioperm(gfx_info.host_pio_base, gfx_info.pio_size, 1);
+ asm volatile ("in %1,%0":"=a"(val):"Nd"(hport));
+ ioperm(gfx_info.host_pio_base, gfx_info.pio_size, 0);
+
+ return val;
+}
+
+/* Write data to host PIO */
+static void ati_hw_out(uint16_t hport, uint32_t data)
+{
+ ioperm(gfx_info.host_pio_base, gfx_info.pio_size, 1);
+ asm volatile ("out %1, %0"::"Nd"(hport),"a"(data));
+ ioperm(gfx_info.host_pio_base, gfx_info.pio_size, 0);
+}
+
+static uint32_t ati_io_regs_read(void *opaque, uint32_t addr)
+{
+ uint32_t val;
+
+ val = ati_hw_in(gport_to_hport(addr));
+
+ /* tweak the value if VBIOS is reading MMIO BAR1 and BAR2 */
+ if ( addr == (gfx_info.guest_pio_base + 4) )
+ {
+ switch ( gfx_info.pre_mmindex_data )
+ {
+ case ATI_BAR1_MMINDEX:
+ val = gfx_info.guest_mmio_base1 | (val & 0x0000000f);
+ break;
+ case ATI_BAR2_MMINDEX:
+ val = gfx_info.guest_mmio_base2 | (val & 0x0000000f);
+ break;
+ default:
+ break;
+ }
+ }
+
+ return val;
+}
+
+static void ati_io_regs_write(void *opaque, uint32_t addr, uint32_t val)
+{
+ ati_hw_out(gport_to_hport(addr), val);
+
+ /* book keeping */
+ if ( addr == gfx_info.guest_pio_base )
+ gfx_info.pre_mmindex_data = val;
+}
+
+static void ati_gfx_init(struct pt_dev *assigned)
+{
+ PCIDevice *dev = (PCIDevice *)&assigned->dev;
+
+ register_ioport_read(dev->io_regions[ATI_BAR5_INDEX].addr,
+ dev->io_regions[ATI_BAR5_INDEX].size, 4, ati_io_regs_read, assigned);
+
+ register_ioport_write(dev->io_regions[ATI_BAR5_INDEX].addr,
+ dev->io_regions[ATI_BAR5_INDEX].size, 4, ati_io_regs_write, assigned);
+
+ /* initialize IO registers */
+ gfx_info.guest_pio_base = dev->io_regions[ATI_BAR5_INDEX].addr;
+ gfx_info.pio_size = dev->io_regions[ATI_BAR5_INDEX].size;
+ gfx_info.host_pio_base = assigned->bases[ATI_BAR5_INDEX].access.pio_base;
+
+ gfx_info.guest_mmio_base1 = dev->io_regions[ATI_BAR1_INDEX].addr;
+ gfx_info.guest_mmio_base2 = dev->io_regions[ATI_BAR2_INDEX].addr;
+ gfx_info.initialized = 1;
+
+ PT_LOG("guest_pio_bar = 0x%x, host_pio_bar = 0x%x, pio_size=0x%x "
+ "guest_mmio_bar1=0x%x, guest_mmio_bar2=0x%x\n",
+ gfx_info.guest_pio_base, gfx_info.host_pio_base, gfx_info.pio_size,
+ gfx_info.guest_mmio_base1, gfx_info.guest_mmio_base2);
+}
+
+static uint32_t ati_legacy_io_read(void *opaque, uint32_t addr)
+{
+ struct pt_dev *assigned_device = opaque;
+ PCIDevice *dev = (PCIDevice *)&assigned_device->dev;
+ uint32_t val = 0xFF;
+
+ switch( addr )
+ {
+ case 0x3c3:
+ val = dev->io_regions[ATI_BAR5_INDEX].addr >> 8;
+ /* Intercept GFX IO registers. This supposes to happen in
+ * ati_register_vga_regions(). But we cannot get guest phys IO BAR
+ * over there. */
+ if ( !gfx_info.initialized )
+ ati_gfx_init(assigned_device);
+ break;
+ default:
+ PT_LOG("ERROR: port 0x%x I/O read not handled\n", addr);
+ break;
+ }
+
+ return val;
+}
+
+static void ati_legacy_io_write(void *opaque, uint32_t addr, uint32_t val)
+{
+ PT_LOG("ERROR: port 0x%x I/O write not handled\n", addr);
+}
+
+int ati_register_vga_regions(struct pt_dev *real_device)
+{
+ PCIDevice *dev = (PCIDevice *)&real_device->dev;
+ int ret = 0;
+
+ /* We need to intercept VBIOS accesses to port 0x3C3, which returns
+ * device port I/O BAR. For the rest of legacy I/O ports, we allow direct
+ * accesses.
+ */
+ ret |= xc_domain_ioport_mapping(xc_handle, domid, 0x3C0,
+ 0x3C0, 0x3, DPCI_ADD_MAPPING);
+
+ ret |= xc_domain_ioport_mapping(xc_handle, domid, 0x3C4,
+ 0x3C4, 0x1C, DPCI_ADD_MAPPING);
+
+ register_ioport_read(0x3c3, 1, 1, ati_legacy_io_read, real_device);
+ register_ioport_write(0x3c3, 1, 1, ati_legacy_io_write, real_device);
+
+ /* initialized on the first port 0x3C3 access in ati_gfx_init */
+ gfx_info.initialized = 0;
+
+ return ret;
+}
+
+int ati_unregister_vga_regions(struct pt_dev *real_device)
+{
+ int ret = 0;
+
+ ret |= xc_domain_ioport_mapping(xc_handle, domid, 0x3C0,
+ 0x3C0, 0x3, DPCI_REMOVE_MAPPING);
+
+ ret |= xc_domain_ioport_mapping(xc_handle, domid, 0x3C4,
+ 0x3C4, 0x1C, DPCI_REMOVE_MAPPING);
+
+ gfx_info.initialized = 0;
+
+ return ret;
+}
+
+/*********************************/
+/* Code for Intel IGD Passthru */
+/*********************************/
static int pch_map_irq(PCIDevice *pci_dev, int irq_num)
{
PT_LOG("pch_map_irq called\n");
@@ -88,6 +290,77 @@ uint32_t igd_pci_read(PCIDevice *pci_dev, int config_addr, int len)
return val;
}
+int igd_register_vga_regions(struct pt_dev *real_device)
+{
+ u32 vendor_id, igd_opregion;
+ int ret = 0;
+
+ /* legacy I/O ports 0x3C0 -- 0x3E0 */
+ ret |= xc_domain_ioport_mapping(xc_handle, domid, 0x3C0,
+ 0x3C0, 0x20, DPCI_ADD_MAPPING);
+
+ /* 1:1 map ASL Storage register value */
+ vendor_id = pt_pci_host_read(0, 2, 0, 0, 2);
+ igd_opregion = pt_pci_host_read(0, 2, 0, 0xfc, 4);
+ if ( (vendor_id == 0x8086) && igd_opregion )
+ {
+ ret |= xc_domain_memory_mapping(xc_handle, domid,
+ igd_opregion >> XC_PAGE_SHIFT,
+ igd_opregion >> XC_PAGE_SHIFT,
+ 2,
+ DPCI_ADD_MAPPING);
+ PT_LOG("register_vga: igd_opregion = %x\n", igd_opregion);
+ }
+
+ return ret;
+}
+
+int igd_unregister_vga_regions(struct pt_dev *real_device)
+{
+ u32 vendor_id, igd_opregion;
+ int ret = 0;
+
+ ret |= xc_domain_ioport_mapping(xc_handle, domid, 0x3C0,
+ 0x3C0, 0x20, DPCI_REMOVE_MAPPING);
+
+ vendor_id = pt_pci_host_read(0, 2, 0, 0, 2);
+ igd_opregion = pt_pci_host_read(0, 2, 0, 0xfc, 4);
+ if ( (vendor_id == 0x8086) && igd_opregion )
+ {
+ ret |= xc_domain_memory_mapping(xc_handle, domid,
+ igd_opregion >> XC_PAGE_SHIFT,
+ igd_opregion >> XC_PAGE_SHIFT,
+ 2,
+ DPCI_REMOVE_MAPPING);
+ }
+
+ return ret;
+}
+/*********************************/
+/* Generic Code for GFX Passthru */
+/*********************************/
+/* This function decides whether I/O port map should be skipped */
+int vga_skip_ioport_map(PCIDevice *d)
+{
+ struct pt_dev *dev = (struct pt_dev *)d;
+ int skip = 0;
+
+ if ( !gfx_passthru || dev->pci_dev->device_class != 0x0300 )
+ return 0;
+
+ switch( dev->pci_dev->vendor_id )
+ {
+ case PCI_VENDOR_ID_ATI:
+ case PCI_VENDOR_ID_AMD:
+ skip = 1;
+ break;
+ default:
+ skip = 0;
+ break;
+ }
+
+ return skip;
+}
/*
* register VGA resources for the domain with assigned gfx
*/
@@ -99,29 +372,31 @@ int register_vga_regions(struct pt_dev *real_device)
if ( !gfx_passthru || real_device->pci_dev->device_class != 0x0300 )
return ret;
+ /* legacy I/O ports 0x3B0 - 0x3BC */
ret |= xc_domain_ioport_mapping(xc_handle, domid, 0x3B0,
0x3B0, 0xC, DPCI_ADD_MAPPING);
-
- ret |= xc_domain_ioport_mapping(xc_handle, domid, 0x3C0,
- 0x3C0, 0x20, DPCI_ADD_MAPPING);
-
+
+ /* legacy video MMIO range 0xA0000 - 0xBFFFF */
ret |= xc_domain_memory_mapping(xc_handle, domid,
0xa0000 >> XC_PAGE_SHIFT,
0xa0000 >> XC_PAGE_SHIFT,
0x20,
DPCI_ADD_MAPPING);
- /* 1:1 map ASL Storage register value */
- vendor_id = pt_pci_host_read(0, 2, 0, 0, 2);
- igd_opregion = pt_pci_host_read(0, 2, 0, 0xfc, 4);
- if ( (vendor_id == 0x8086) && igd_opregion )
+ /* Other VGA regions are vendor specific */
+ switch( real_device->pci_dev->vendor_id )
{
- ret |= xc_domain_memory_mapping(xc_handle, domid,
- igd_opregion >> XC_PAGE_SHIFT,
- igd_opregion >> XC_PAGE_SHIFT,
- 2,
- DPCI_ADD_MAPPING);
- PT_LOG("register_vga: igd_opregion = %x\n", igd_opregion);
+ case PCI_VENDOR_ID_INTEL:
+ ret = igd_register_vga_regions(real_device);
+ break;
+ case PCI_VENDOR_ID_ATI:
+ case PCI_VENDOR_ID_AMD:
+ ret = ati_register_vga_regions(real_device);
+ break;
+ default:
+ PT_LOG("gfx card wasn't supported by Xen passthru!\n");
+ ret = 1;
+ break;
}
if ( ret != 0 )
@@ -135,33 +410,36 @@ int register_vga_regions(struct pt_dev *real_device)
*/
int unregister_vga_regions(struct pt_dev *real_device)
{
- u32 vendor_id, igd_opregion;
int ret = 0;
if ( !gfx_passthru || real_device->pci_dev->device_class != 0x0300 )
return ret;
+ /* legacy I/O ports 0x3B0 - 0x3BC */
ret |= xc_domain_ioport_mapping(xc_handle, domid, 0x3B0,
0x3B0, 0xC, DPCI_REMOVE_MAPPING);
- ret |= xc_domain_ioport_mapping(xc_handle, domid, 0x3C0,
- 0x3C0, 0x20, DPCI_REMOVE_MAPPING);
-
+ /* legacy video MMIO range 0xA0000 - 0xBFFFF */
ret |= xc_domain_memory_mapping(xc_handle, domid,
0xa0000 >> XC_PAGE_SHIFT,
0xa0000 >> XC_PAGE_SHIFT,
20,
DPCI_REMOVE_MAPPING);
- vendor_id = pt_pci_host_read(0, 2, 0, 0, 2);
- igd_opregion = pt_pci_host_read(0, 2, 0, 0xfc, 4);
- if ( (vendor_id == 0x8086) && igd_opregion )
+ /* Other VGA regions are vendor specific */
+ switch( real_device->pci_dev->vendor_id )
{
- ret |= xc_domain_memory_mapping(xc_handle, domid,
- igd_opregion >> XC_PAGE_SHIFT,
- igd_opregion >> XC_PAGE_SHIFT,
- 2,
- DPCI_REMOVE_MAPPING);
+ case PCI_VENDOR_ID_INTEL:
+ ret = igd_unregister_vga_regions(real_device);
+ break;
+ case PCI_VENDOR_ID_ATI:
+ case PCI_VENDOR_ID_AMD:
+ ret = ati_unregister_vga_regions(real_device);
+ break;
+ default:
+ PT_LOG("gfx card wasn't supported by Xen passthru!\n");
+ ret = 1;
+ break;
}
if ( ret != 0 )
[-- Attachment #3: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply related
* Re: [PATCH 4/7] [RFC] OMAP: hwmod implementation for MCBSP
From: kishon @ 2010-10-07 16:53 UTC (permalink / raw)
To: ABRAHAM, KISHON VIJAY
Cc: Cousson, Benoit, linux-omap@vger.kernel.org, Kamat, Nishant,
Varadarajan, Charulatha, Datta, Shubhrajyoti, Basak, Partha
In-Reply-To: <4CAC51D5.8070101@ti.com>
On Wednesday 06 October 2010 04:09 PM, ABRAHAM, KISHON VIJAY wrote:
> On Wednesday 06 October 2010 03:04 PM, Cousson, Benoit wrote:
>> On 10/5/2010 6:37 PM, Kishon Vijay Abraham I wrote:
>>> Signed-off-by: Kishon Vijay Abraham I<kishon@ti.com>
>>> Signed-off-by: Charulatha V<charu@ti.com>
>>> Signed-off-by: Shubhrajyoti D<shubhrajyoti@ti.com>
>>> Cc: Partha Basak<p-basak2@ti.com>
>>> ---
>>> arch/arm/mach-omap2/mcbsp.c | 251 +++++++++----------------------
>>> arch/arm/plat-omap/include/plat/mcbsp.h | 6 +-
>>> arch/arm/plat-omap/mcbsp.c | 189 +++++++++++-------------
>>> 3 files changed, 159 insertions(+), 287 deletions(-)
>>>
>>> diff --git a/arch/arm/mach-omap2/mcbsp.c b/arch/arm/mach-omap2/mcbsp.c
>>> index eba9fa1..25c6703 100644
>>> --- a/arch/arm/mach-omap2/mcbsp.c
>>> +++ b/arch/arm/mach-omap2/mcbsp.c
>>> @@ -22,9 +22,13 @@
>>> #include<plat/dma.h>
>>> #include<plat/cpu.h>
>>> #include<plat/mcbsp.h>
>>> +#include<plat/omap_hwmod.h>
>>> +#include<plat/omap_device.h>
>>>
>>> #include "control.h"
>>>
>>> +static struct omap_hwmod *oh_st_device[] = {NULL, NULL};
>>> +static int no_of_st;
>>>
>>> /* McBSP internal signal muxing functions */
>>>
>>> @@ -101,199 +105,90 @@ int omap2_mcbsp_set_clks_src(u8 id, u8 fck_src_id)
>>> }
>>> EXPORT_SYMBOL(omap2_mcbsp_set_clks_src);
>>>
>>> -
>>> -/* Platform data */
>>> -
>>> -#ifdef CONFIG_ARCH_OMAP2420
>>> -static struct omap_mcbsp_platform_data omap2420_mcbsp_pdata[] = {
>>> - {
>>> - .phys_base = OMAP24XX_MCBSP1_BASE,
>>> - .dma_rx_sync = OMAP24XX_DMA_MCBSP1_RX,
>>> - .dma_tx_sync = OMAP24XX_DMA_MCBSP1_TX,
>>> - .rx_irq = INT_24XX_MCBSP1_IRQ_RX,
>>> - .tx_irq = INT_24XX_MCBSP1_IRQ_TX,
>>> - },
>>> +struct omap_device_pm_latency omap2_mcbsp_latency[] = {
>>> {
>>> - .phys_base = OMAP24XX_MCBSP2_BASE,
>>> - .dma_rx_sync = OMAP24XX_DMA_MCBSP2_RX,
>>> - .dma_tx_sync = OMAP24XX_DMA_MCBSP2_TX,
>>> - .rx_irq = INT_24XX_MCBSP2_IRQ_RX,
>>> - .tx_irq = INT_24XX_MCBSP2_IRQ_TX,
>>> + .deactivate_func = omap_device_idle_hwmods,
>>> + .activate_func = omap_device_enable_hwmods,
>>> + .flags = OMAP_DEVICE_LATENCY_AUTO_ADJUST,
>>> },
>>> };
>>> -#define OMAP2420_MCBSP_PDATA_SZ ARRAY_SIZE(omap2420_mcbsp_pdata)
>>> -#define OMAP2420_MCBSP_REG_NUM (OMAP_MCBSP_REG_RCCR / sizeof(u32) + 1)
>>> -#else
>>> -#define omap2420_mcbsp_pdata NULL
>>> -#define OMAP2420_MCBSP_PDATA_SZ 0
>>> -#define OMAP2420_MCBSP_REG_NUM 0
>>> -#endif
>>>
>>> -#ifdef CONFIG_ARCH_OMAP2430
>>> -static struct omap_mcbsp_platform_data omap2430_mcbsp_pdata[] = {
>>> - {
>>> - .phys_base = OMAP24XX_MCBSP1_BASE,
>>> - .dma_rx_sync = OMAP24XX_DMA_MCBSP1_RX,
>>> - .dma_tx_sync = OMAP24XX_DMA_MCBSP1_TX,
>>> - .rx_irq = INT_24XX_MCBSP1_IRQ_RX,
>>> - .tx_irq = INT_24XX_MCBSP1_IRQ_TX,
>>> - },
>>> - {
>>> - .phys_base = OMAP24XX_MCBSP2_BASE,
>>> - .dma_rx_sync = OMAP24XX_DMA_MCBSP2_RX,
>>> - .dma_tx_sync = OMAP24XX_DMA_MCBSP2_TX,
>>> - .rx_irq = INT_24XX_MCBSP2_IRQ_RX,
>>> - .tx_irq = INT_24XX_MCBSP2_IRQ_TX,
>>> - },
>>> - {
>>> - .phys_base = OMAP2430_MCBSP3_BASE,
>>> - .dma_rx_sync = OMAP24XX_DMA_MCBSP3_RX,
>>> - .dma_tx_sync = OMAP24XX_DMA_MCBSP3_TX,
>>> - .rx_irq = INT_24XX_MCBSP3_IRQ_RX,
>>> - .tx_irq = INT_24XX_MCBSP3_IRQ_TX,
>>> - },
>>> - {
>>> - .phys_base = OMAP2430_MCBSP4_BASE,
>>> - .dma_rx_sync = OMAP24XX_DMA_MCBSP4_RX,
>>> - .dma_tx_sync = OMAP24XX_DMA_MCBSP4_TX,
>>> - .rx_irq = INT_24XX_MCBSP4_IRQ_RX,
>>> - .tx_irq = INT_24XX_MCBSP4_IRQ_TX,
>>> - },
>>> - {
>>> - .phys_base = OMAP2430_MCBSP5_BASE,
>>> - .dma_rx_sync = OMAP24XX_DMA_MCBSP5_RX,
>>> - .dma_tx_sync = OMAP24XX_DMA_MCBSP5_TX,
>>> - .rx_irq = INT_24XX_MCBSP5_IRQ_RX,
>>> - .tx_irq = INT_24XX_MCBSP5_IRQ_TX,
>>> - },
>>> -};
>>> -#define OMAP2430_MCBSP_PDATA_SZ ARRAY_SIZE(omap2430_mcbsp_pdata)
>>> -#define OMAP2430_MCBSP_REG_NUM (OMAP_MCBSP_REG_RCCR / sizeof(u32) + 1)
>>> -#else
>>> -#define omap2430_mcbsp_pdata NULL
>>> -#define OMAP2430_MCBSP_PDATA_SZ 0
>>> -#define OMAP2430_MCBSP_REG_NUM 0
>>> -#endif
>>> +static int omap_init_mcbsp(struct omap_hwmod *oh, void *user)
>>> +{
>>> + int id, count = 1, i;
>>> + char *name = "omap-mcbsp";
>>> + char dev_name[16];
>>> + struct omap_hwmod *oh_device[2];
>>> + struct omap_mcbsp_platform_data *pdata;
>>> + struct omap_device *od;
>>> +
>>> + if (!oh) {
>>> + pr_err("%s:NULL hwmod pointer (oh)\n", __func__);
>>> + return -EINVAL;
>>> + }
>>>
>>> -#ifdef CONFIG_ARCH_OMAP3
>>> -static struct omap_mcbsp_platform_data omap34xx_mcbsp_pdata[] = {
>>> - {
>>> - .phys_base = OMAP34XX_MCBSP1_BASE,
>>> - .dma_rx_sync = OMAP24XX_DMA_MCBSP1_RX,
>>> - .dma_tx_sync = OMAP24XX_DMA_MCBSP1_TX,
>>> - .rx_irq = INT_24XX_MCBSP1_IRQ_RX,
>>> - .tx_irq = INT_24XX_MCBSP1_IRQ_TX,
>>> - .buffer_size = 0x80, /* The FIFO has 128 locations */
>>> - },
>>> - {
>>> - .phys_base = OMAP34XX_MCBSP2_BASE,
>>> - .phys_base_st = OMAP34XX_MCBSP2_ST_BASE,
>>> - .dma_rx_sync = OMAP24XX_DMA_MCBSP2_RX,
>>> - .dma_tx_sync = OMAP24XX_DMA_MCBSP2_TX,
>>> - .rx_irq = INT_24XX_MCBSP2_IRQ_RX,
>>> - .tx_irq = INT_24XX_MCBSP2_IRQ_TX,
>>> - .buffer_size = 0x500, /* The FIFO has 1024 + 256 locations */
>>> - },
>>> - {
>>> - .phys_base = OMAP34XX_MCBSP3_BASE,
>>> - .phys_base_st = OMAP34XX_MCBSP3_ST_BASE,
>>> - .dma_rx_sync = OMAP24XX_DMA_MCBSP3_RX,
>>> - .dma_tx_sync = OMAP24XX_DMA_MCBSP3_TX,
>>> - .rx_irq = INT_24XX_MCBSP3_IRQ_RX,
>>> - .tx_irq = INT_24XX_MCBSP3_IRQ_TX,
>>> - .buffer_size = 0x80, /* The FIFO has 128 locations */
>>> - },
>>> - {
>>> - .phys_base = OMAP34XX_MCBSP4_BASE,
>>> - .dma_rx_sync = OMAP24XX_DMA_MCBSP4_RX,
>>> - .dma_tx_sync = OMAP24XX_DMA_MCBSP4_TX,
>>> - .rx_irq = INT_24XX_MCBSP4_IRQ_RX,
>>> - .tx_irq = INT_24XX_MCBSP4_IRQ_TX,
>>> - .buffer_size = 0x80, /* The FIFO has 128 locations */
>>> - },
>>> - {
>>> - .phys_base = OMAP34XX_MCBSP5_BASE,
>>> - .dma_rx_sync = OMAP24XX_DMA_MCBSP5_RX,
>>> - .dma_tx_sync = OMAP24XX_DMA_MCBSP5_TX,
>>> - .rx_irq = INT_24XX_MCBSP5_IRQ_RX,
>>> - .tx_irq = INT_24XX_MCBSP5_IRQ_TX,
>>> - .buffer_size = 0x80, /* The FIFO has 128 locations */
>>> - },
>>> -};
>>> -#define OMAP34XX_MCBSP_PDATA_SZ ARRAY_SIZE(omap34xx_mcbsp_pdata)
>>> -#define OMAP34XX_MCBSP_REG_NUM (OMAP_MCBSP_REG_RCCR / sizeof(u32) + 1)
>>> -#else
>>> -#define omap34xx_mcbsp_pdata NULL
>>> -#define OMAP34XX_MCBSP_PDATA_SZ 0
>>> -#define OMAP34XX_MCBSP_REG_NUM 0
>>> -#endif
>>> + pdata = kzalloc(sizeof(struct omap_mcbsp_platform_data), GFP_KERNEL);
>>> + if (!pdata) {
>>> + pr_err("%s: No memory for mcbsp\n", __func__);
>>> + return -ENOMEM;
>>> + }
>>>
>>> -static struct omap_mcbsp_platform_data omap44xx_mcbsp_pdata[] = {
>>> - {
>>> - .phys_base = OMAP44XX_MCBSP1_BASE,
>>> - .dma_rx_sync = OMAP44XX_DMA_MCBSP1_RX,
>>> - .dma_tx_sync = OMAP44XX_DMA_MCBSP1_TX,
>>> - .tx_irq = OMAP44XX_IRQ_MCBSP1,
>>> - },
>>> - {
>>> - .phys_base = OMAP44XX_MCBSP2_BASE,
>>> - .dma_rx_sync = OMAP44XX_DMA_MCBSP2_RX,
>>> - .dma_tx_sync = OMAP44XX_DMA_MCBSP2_TX,
>>> - .tx_irq = OMAP44XX_IRQ_MCBSP2,
>>> - /* XXX .ops ? */
>>> - },
>>> - {
>>> - .phys_base = OMAP44XX_MCBSP3_BASE,
>>> - .dma_rx_sync = OMAP44XX_DMA_MCBSP3_RX,
>>> - .dma_tx_sync = OMAP44XX_DMA_MCBSP3_TX,
>>> - .tx_irq = OMAP44XX_IRQ_MCBSP3,
>>> - /* XXX .ops ? */
>>> - },
>>> - {
>>> - .phys_base = OMAP44XX_MCBSP4_BASE,
>>> - .dma_rx_sync = OMAP44XX_DMA_MCBSP4_RX,
>>> - .dma_tx_sync = OMAP44XX_DMA_MCBSP4_TX,
>>> - .tx_irq = OMAP44XX_IRQ_MCBSP4,
>>> - /* XXX .ops ? */
>>> - },
>>> -};
>>> -#define OMAP44XX_MCBSP_PDATA_SZ ARRAY_SIZE(omap44xx_mcbsp_pdata)
>>> -#define OMAP44XX_MCBSP_REG_NUM (OMAP_MCBSP_REG_RCCR / sizeof(u32) + 1)
>>> + if (cpu_is_omap34xx()) {
>>> + pdata->dma_op_mode = MCBSP_DMA_MODE_ELEMENT;
>>> + if (id == 2)
>>> + pdata->buffer_size = 0x500;
>>> + else
>>> + pdata->buffer_size = 0x80;
>>> + } else {
>>> + pdata->dma_op_mode = -EINVAL;
>>> + pdata->buffer_size = 0;
>>> + }
>>>
>>> -static int __init omap2_mcbsp_init(void)
>>> + sscanf(oh->name, "mcbsp%d",&id);
>>> + sprintf(dev_name, "mcbsp%d_sidetone", id);
>>> + oh_device[0] = oh;
>>> +
>>> + for (i = 0; i< no_of_st ; i++) {
>>> + if (!strcmp(dev_name, oh_st_device[i]->name)) {
>>> + oh_device[1] = oh_st_device[i];
>>> + count++;
>>> + }
>>> + }
>>
>> Pfuu, it took me a while to follow how all that stuff was working :-)
> sorry for that :-)
>>
>> Since the sidetone block is tightly coupled to the mcbsp, you should
>> simply add this information directly as a attribute of the mcbsp2& 3
>> hwmod dev_attr.
>>
>> You will then easily detect which one does have a sidetone connected to
>> it and avoid all this code.
>>
>> +static struct omap_mcbsp_dev_attr omap34xx_mcbsp2_dev_attr = {
>> + .sidetone = "mcbsp2_sidetone",
>> +};
>>
>> +static struct omap_hwmod omap34xx_mcbsp2_hwmod = {
>> ...
>> + .dev_attr =&omap34xx_mcbsp2_dev_attr,
>> ...
>
> Thats a good suggestion. Thanks.
Ahh... there's a problem with that approach. Using a device attribute
will help to get rid of only
+ sprintf(dev_name, "mcbsp%d_sidetone", id);
We'll still need to have omap_mcbsp_st() and the following code
snippet
+ for (i = 0; i< no_of_st ; i++) {
+ if (!strcmp(dev_name, oh_st_device[i]->name)) {
+ oh_device[1] = oh_st_device[i];
+ count++;
+ }
+ }
using a dev_attr to get the name of sidetone will be helpful only
when we can use omap_hwmod_lookup() to get the oh address in
omap_init_mcbsp(). But omap_init_mcbsp() is called as a callback to
omap_hwmod_for_each_by_class() holding 'omap_hwmod_mutex' which
disallows call to any other hwmod functions.
I feel adding a dev_attr to get rid of two sprintf instructions
which involve modifying hwmod database file, adding a new structure
is not a better option.
Please give your take on this.
-Kishon
> -Kishon
>>
>>
>> Regards,
>> Benoit
>>
>>
>>> +
>>> + od = omap_device_build_ss(name, id, oh_device, count, pdata,
>>> + sizeof(*pdata), omap2_mcbsp_latency,
>>> + ARRAY_SIZE(omap2_mcbsp_latency), false);
>>> + if (IS_ERR(od)) {
>>> + pr_err("%s: Cant build omap_device for %s:%s.\n", __func__,
>>> + name, oh->name);
>>> + kfree(pdata);
>>> + return PTR_ERR(od);
>>> + }
>>> + omap_mcbsp_count++;
>>> + return 0;
>>> +}
>>> +
>>> +static int omap_mcbsp_st(struct omap_hwmod *oh, void *user)
>>> {
>>> - if (cpu_is_omap2420()) {
>>> - omap_mcbsp_count = OMAP2420_MCBSP_PDATA_SZ;
>>> - omap_mcbsp_cache_size = OMAP2420_MCBSP_REG_NUM * sizeof(u16);
>>> - } else if (cpu_is_omap2430()) {
>>> - omap_mcbsp_count = OMAP2430_MCBSP_PDATA_SZ;
>>> - omap_mcbsp_cache_size = OMAP2430_MCBSP_REG_NUM * sizeof(u32);
>>> - } else if (cpu_is_omap34xx()) {
>>> - omap_mcbsp_count = OMAP34XX_MCBSP_PDATA_SZ;
>>> - omap_mcbsp_cache_size = OMAP34XX_MCBSP_REG_NUM * sizeof(u32);
>>> - } else if (cpu_is_omap44xx()) {
>>> - omap_mcbsp_count = OMAP44XX_MCBSP_PDATA_SZ;
>>> - omap_mcbsp_cache_size = OMAP44XX_MCBSP_REG_NUM * sizeof(u32);
>>> + if (!oh) {
>>> + pr_err("%s:NULL hwmod pointer (oh)\n", __func__);
>>> + return -EINVAL;
>>> }
>>> + oh_st_device[no_of_st++] = oh;
>>> + return 0;
>>> +}
>>> +
>>> +static int __init omap2_mcbsp_init(void)
>>> +{
>>> + omap_hwmod_for_each_by_class("mcbsp_sidetone", omap_mcbsp_st,
>>> + NULL);
>>> + omap_hwmod_for_each_by_class("mcbsp", omap_init_mcbsp, NULL);
>>>
>>> mcbsp_ptr = kzalloc(omap_mcbsp_count * sizeof(struct omap_mcbsp *),
>>> GFP_KERNEL);
>>> if (!mcbsp_ptr)
>>> return -ENOMEM;
>>>
>>> - if (cpu_is_omap2420())
>>> - omap_mcbsp_register_board_cfg(omap2420_mcbsp_pdata,
>>> - OMAP2420_MCBSP_PDATA_SZ);
>>> - if (cpu_is_omap2430())
>>> - omap_mcbsp_register_board_cfg(omap2430_mcbsp_pdata,
>>> - OMAP2430_MCBSP_PDATA_SZ);
>>> - if (cpu_is_omap34xx())
>>> - omap_mcbsp_register_board_cfg(omap34xx_mcbsp_pdata,
>>> - OMAP34XX_MCBSP_PDATA_SZ);
>>> - if (cpu_is_omap44xx())
>>> - omap_mcbsp_register_board_cfg(omap44xx_mcbsp_pdata,
>>> - OMAP44XX_MCBSP_PDATA_SZ);
>>> -
>>> return omap_mcbsp_init();
>>> }
>>> arch_initcall(omap2_mcbsp_init);
>>> diff --git a/arch/arm/plat-omap/include/plat/mcbsp.h b/arch/arm/plat-omap/include/plat/mcbsp.h
>>> index 4da6f94..1ff283c 100644
>>> --- a/arch/arm/plat-omap/include/plat/mcbsp.h
>>> +++ b/arch/arm/plat-omap/include/plat/mcbsp.h
>>> @@ -418,11 +418,9 @@ struct omap_mcbsp_platform_data {
>>> u8 dma_rx_sync, dma_tx_sync;
>>> u16 rx_irq, tx_irq;
>>> struct omap_mcbsp_ops *ops;
>>> -#ifdef CONFIG_ARCH_OMAP3
>>> - /* Sidetone block for McBSP 2 and 3 */
>>> unsigned long phys_base_st;
>>> u16 buffer_size;
>>> -#endif
>>> + int dma_op_mode;
>>> };
>>>
>>> struct omap_mcbsp_st_data {
>>> @@ -466,12 +464,10 @@ struct omap_mcbsp {
>>> struct omap_mcbsp_platform_data *pdata;
>>> struct clk *iclk;
>>> struct clk *fclk;
>>> -#ifdef CONFIG_ARCH_OMAP3
>>> struct omap_mcbsp_st_data *st_data;
>>> int dma_op_mode;
>>> u16 max_tx_thres;
>>> u16 max_rx_thres;
>>> -#endif
>>> void *reg_cache;
>>> };
>>> extern struct omap_mcbsp **mcbsp_ptr;
>>> diff --git a/arch/arm/plat-omap/mcbsp.c b/arch/arm/plat-omap/mcbsp.c
>>> index eac4b97..c7c6a83 100644
>>> --- a/arch/arm/plat-omap/mcbsp.c
>>> +++ b/arch/arm/plat-omap/mcbsp.c
>>> @@ -27,6 +27,8 @@
>>>
>>> #include<plat/dma.h>
>>> #include<plat/mcbsp.h>
>>> +#include<plat/omap_hwmod.h>
>>> +#include<plat/omap_device.h>
>>>
>>> #include "../mach-omap2/cm-regbits-34xx.h"
>>>
>>> @@ -1466,7 +1468,6 @@ void omap_mcbsp_set_spi_mode(unsigned int id,
>>> }
>>> EXPORT_SYMBOL(omap_mcbsp_set_spi_mode);
>>>
>>> -#ifdef CONFIG_ARCH_OMAP3
>>> #define max_thres(m) (mcbsp->pdata->buffer_size)
>>> #define valid_threshold(m, val) ((val)<= max_thres(m))
>>> #define THRESHOLD_PROP_BUILDER(prop) \
>>> @@ -1645,98 +1646,6 @@ static const struct attribute_group sidetone_attr_group = {
>>> .attrs = (struct attribute **)sidetone_attrs,
>>> };
>>>
>>> -static int __devinit omap_st_add(struct omap_mcbsp *mcbsp)
>>> -{
>>> - struct omap_mcbsp_platform_data *pdata = mcbsp->pdata;
>>> - struct omap_mcbsp_st_data *st_data;
>>> - int err;
>>> -
>>> - st_data = kzalloc(sizeof(*mcbsp->st_data), GFP_KERNEL);
>>> - if (!st_data) {
>>> - err = -ENOMEM;
>>> - goto err1;
>>> - }
>>> -
>>> - st_data->io_base_st = ioremap(pdata->phys_base_st, SZ_4K);
>>> - if (!st_data->io_base_st) {
>>> - err = -ENOMEM;
>>> - goto err2;
>>> - }
>>> -
>>> - err = sysfs_create_group(&mcbsp->dev->kobj,&sidetone_attr_group);
>>> - if (err)
>>> - goto err3;
>>> -
>>> - mcbsp->st_data = st_data;
>>> - return 0;
>>> -
>>> -err3:
>>> - iounmap(st_data->io_base_st);
>>> -err2:
>>> - kfree(st_data);
>>> -err1:
>>> - return err;
>>> -
>>> -}
>>> -
>>> -static void __devexit omap_st_remove(struct omap_mcbsp *mcbsp)
>>> -{
>>> - struct omap_mcbsp_st_data *st_data = mcbsp->st_data;
>>> -
>>> - if (st_data) {
>>> - sysfs_remove_group(&mcbsp->dev->kobj,&sidetone_attr_group);
>>> - iounmap(st_data->io_base_st);
>>> - kfree(st_data);
>>> - }
>>> -}
>>> -
>>> -static inline void __devinit omap34xx_device_init(struct omap_mcbsp *mcbsp)
>>> -{
>>> - mcbsp->dma_op_mode = MCBSP_DMA_MODE_ELEMENT;
>>> - if (cpu_is_omap34xx()) {
>>> - /*
>>> - * Initially configure the maximum thresholds to a safe value.
>>> - * The McBSP FIFO usage with these values should not go under
>>> - * 16 locations.
>>> - * If the whole FIFO without safety buffer is used, than there
>>> - * is a possibility that the DMA will be not able to push the
>>> - * new data on time, causing channel shifts in runtime.
>>> - */
>>> - mcbsp->max_tx_thres = max_thres(mcbsp) - 0x10;
>>> - mcbsp->max_rx_thres = max_thres(mcbsp) - 0x10;
>>> - /*
>>> - * REVISIT: Set dmap_op_mode to THRESHOLD as default
>>> - * for mcbsp2 instances.
>>> - */
>>> - if (omap_additional_add(mcbsp->dev))
>>> - dev_warn(mcbsp->dev,
>>> - "Unable to create additional controls\n");
>>> -
>>> - if (mcbsp->id == 2 || mcbsp->id == 3)
>>> - if (omap_st_add(mcbsp))
>>> - dev_warn(mcbsp->dev,
>>> - "Unable to create sidetone controls\n");
>>> -
>>> - } else {
>>> - mcbsp->max_tx_thres = -EINVAL;
>>> - mcbsp->max_rx_thres = -EINVAL;
>>> - }
>>> -}
>>> -
>>> -static inline void __devexit omap34xx_device_exit(struct omap_mcbsp *mcbsp)
>>> -{
>>> - if (cpu_is_omap34xx()) {
>>> - omap_additional_remove(mcbsp->dev);
>>> -
>>> - if (mcbsp->id == 2 || mcbsp->id == 3)
>>> - omap_st_remove(mcbsp);
>>> - }
>>> -}
>>> -#else
>>> -static inline void __devinit omap34xx_device_init(struct omap_mcbsp *mcbsp) {}
>>> -static inline void __devexit omap34xx_device_exit(struct omap_mcbsp *mcbsp) {}
>>> -#endif /* CONFIG_ARCH_OMAP3 */
>>> -
>>> /*
>>> * McBSP1 and McBSP3 are directly mapped on 1610 and 1510.
>>> * 730 has only 2 McBSP, and both of them are MPU peripherals.
>>> @@ -1746,6 +1655,7 @@ static int __devinit omap_mcbsp_probe(struct platform_device *pdev)
>>> struct omap_mcbsp_platform_data *pdata = pdev->dev.platform_data;
>>> struct omap_mcbsp *mcbsp;
>>> int id = pdev->id - 1;
>>> + struct resource *res;
>>> int ret = 0;
>>>
>>> if (!pdata) {
>>> @@ -1775,25 +1685,50 @@ static int __devinit omap_mcbsp_probe(struct platform_device *pdev)
>>> mcbsp->dma_tx_lch = -1;
>>> mcbsp->dma_rx_lch = -1;
>>>
>>> - mcbsp->phys_base = pdata->phys_base;
>>> - mcbsp->io_base = ioremap(pdata->phys_base, SZ_4K);
>>> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>>> + if (!res) {
>>> + dev_err(&pdev->dev, "%s:mcbsp%d has invalid memory resource\n",
>>> + __func__, pdev->id);
>>> + ret = -ENOMEM;
>>> + goto exit;
>>> + }
>>> + mcbsp->phys_base = res->start;
>>> + mcbsp->io_base = ioremap(res->start, resource_size(res));
>>> if (!mcbsp->io_base) {
>>> ret = -ENOMEM;
>>> goto err_ioremap;
>>> }
>>>
>>> + omap_mcbsp_cache_size = resource_size(res);
>>> +
>>> /* Default I/O is IRQ based */
>>> mcbsp->io_type = OMAP_MCBSP_IRQ_IO;
>>> - mcbsp->tx_irq = pdata->tx_irq;
>>> - mcbsp->rx_irq = pdata->rx_irq;
>>> - mcbsp->dma_rx_sync = pdata->dma_rx_sync;
>>> - mcbsp->dma_tx_sync = pdata->dma_tx_sync;
>>> + mcbsp->tx_irq = platform_get_irq_byname(pdev, "tx");
>>> + mcbsp->rx_irq = platform_get_irq_byname(pdev, "rx");
>>> +
>>> + res = platform_get_resource_byname(pdev, IORESOURCE_DMA, "rx");
>>> + if (!res) {
>>> + dev_err(&pdev->dev, "%s:mcbsp%d has invalid DMA channel\n",
>>> + __func__, pdev->id);
>>> + ret = -ENODEV;
>>> + goto err_res;
>>> + }
>>> + mcbsp->dma_rx_sync = res->start;
>>> +
>>> + res = platform_get_resource_byname(pdev, IORESOURCE_DMA, "tx");
>>> + if (!res) {
>>> + dev_err(&pdev->dev, "%s:mcbsp%d has invalid DMA channel\n",
>>> + __func__, pdev->id);
>>> + ret = -ENODEV;
>>> + goto err_res;
>>> + }
>>> + mcbsp->dma_tx_sync = res->start;
>>>
>>> mcbsp->iclk = clk_get(&pdev->dev, "ick");
>>> if (IS_ERR(mcbsp->iclk)) {
>>> ret = PTR_ERR(mcbsp->iclk);
>>> dev_err(&pdev->dev, "unable to get ick: %d\n", ret);
>>> - goto err_iclk;
>>> + goto err_res;
>>> }
>>>
>>> mcbsp->fclk = clk_get(&pdev->dev, "fck");
>>> @@ -1808,14 +1743,53 @@ static int __devinit omap_mcbsp_probe(struct platform_device *pdev)
>>> mcbsp_ptr[id] = mcbsp;
>>> platform_set_drvdata(pdev, mcbsp);
>>>
>>> - /* Initialize mcbsp properties for OMAP34XX if needed / applicable */
>>> - omap34xx_device_init(mcbsp);
>>> + omap_additional_add(mcbsp->dev);
>>> + if (pdata->dma_op_mode != -EINVAL) {
>>> + /*
>>> + * Initially configure the maximum thresholds to a safe value.
>>> + * The McBSP FIFO usage with these values should not go under
>>> + * 16 locations.
>>> + * If the whole FIFO without safety buffer is used, than there
>>> + * is a possibility that the DMA will be not able to push the
>>> + * new data on time, causing channel shifts in runtime.
>>> + */
>>> + mcbsp->max_tx_thres = max_thres(mcbsp) - 0x10 ;
>>> + mcbsp->max_rx_thres = max_thres(mcbsp) - 0x10 ;
>>> + }
>>> +
>>> + if (cpu_is_omap34xx()) {
>>> + res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
>>> + if (res) {
>>> + mcbsp->st_data = kzalloc(sizeof(*mcbsp->st_data),
>>> + GFP_KERNEL);
>>> + if (!mcbsp->st_data) {
>>> + ret = -ENOMEM;
>>> + goto err_st_data;
>>> + }
>>> + mcbsp->st_data->io_base_st = ioremap(res->start,
>>> + resource_size(res));
>>> + if (!mcbsp->st_data->io_base_st) {
>>> + ret = -ENOMEM;
>>> + goto err_io_st;
>>> + }
>>> + ret = sysfs_create_group(&mcbsp->dev->kobj,
>>> +&sidetone_attr_group);
>>> + if (ret)
>>> + goto err_sysfs;
>>> + }
>>> + }
>>>
>>> return 0;
>>>
>>> +err_sysfs:
>>> + iounmap(mcbsp->st_data->io_base_st);
>>> +err_io_st:
>>> + kfree(mcbsp->st_data);
>>> +err_st_data:
>>> + clk_put(mcbsp->fclk);
>>> err_fclk:
>>> clk_put(mcbsp->iclk);
>>> -err_iclk:
>>> +err_res:
>>> iounmap(mcbsp->io_base);
>>> err_ioremap:
>>> kfree(mcbsp);
>>> @@ -1834,7 +1808,14 @@ static int __devexit omap_mcbsp_remove(struct platform_device *pdev)
>>> mcbsp->pdata->ops->free)
>>> mcbsp->pdata->ops->free(mcbsp->id);
>>>
>>> - omap34xx_device_exit(mcbsp);
>>> + omap_additional_remove(mcbsp->dev);
>>> +
>>> + if (mcbsp->st_data) {
>>> + sysfs_remove_group(&mcbsp->dev->kobj,
>>> +&sidetone_attr_group);
>>> + iounmap(mcbsp->st_data->io_base_st);
>>> + kfree(mcbsp->st_data);
>>> + }
>>>
>>> clk_disable(mcbsp->fclk);
>>> clk_disable(mcbsp->iclk);
>>> --
>>> 1.7.0.4
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>
^ permalink raw reply
* [Qemu-devel] [PATCH] win32: Set unbuffered stdout
From: Stefan Weil @ 2010-10-07 16:55 UTC (permalink / raw)
To: QEMU Developers; +Cc: Blue Swirl
Win32 does not support line-buffering, but it allows
unbuffered output.
Unbuffered output is a good approximation. For typical output
statements which usually end with '\n', it's even identical.
Buffered output is unusable for program traces because of
its large delay.
Cc: Blue Swirl <blauwirbel@gmail.com>
Signed-off-by: Stefan Weil <weil@mail.berlios.de>
---
os-win32.c | 6 ++++++
qemu-os-win32.h | 3 +--
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/os-win32.c b/os-win32.c
index dd46bf4..3c6f50f 100644
--- a/os-win32.c
+++ b/os-win32.c
@@ -221,6 +221,12 @@ char *os_find_datadir(const char *argv0)
return NULL;
}
+void os_set_line_buffering(void)
+{
+ setbuf(stdout, NULL);
+ setbuf(stderr, NULL);
+}
+
/*
* Parse OS specific command line options.
* return 0 if option handled, -1 otherwise
diff --git a/qemu-os-win32.h b/qemu-os-win32.h
index 2ff9f45..c63778d 100644
--- a/qemu-os-win32.h
+++ b/qemu-os-win32.h
@@ -45,8 +45,7 @@ void os_host_main_loop_wait(int *timeout);
static inline void os_setup_signal_handling(void) {}
static inline void os_daemonize(void) {}
static inline void os_setup_post(void) {}
-/* Win32 doesn't support line-buffering and requires size >= 2 */
-static inline void os_set_line_buffering(void) {}
+void os_set_line_buffering(void);
static inline void os_set_proc_name(const char *dummy) {}
#if !defined(EPROTONOSUPPORT)
--
1.7.1
^ permalink raw reply related
* [Qemu-devel] Re: [PATCH 0/6] Save state error handling (kill off no_migrate)
From: Alex Williamson @ 2010-10-07 16:55 UTC (permalink / raw)
To: Avi Kivity, Marcelo Tosatti; +Cc: qemu-devel, cam, kvm, quintela
In-Reply-To: <20101006204546.32127.70109.stgit@s20.home>
[-- Attachment #1: Type: text/plain, Size: 4783 bytes --]
Avi, Marcelo,
Assuming this gets merged to qemu.git, you'll need the attached trivial
updates for the qemu-kvm.git merge. Thanks,
Alex
On Wed, 2010-10-06 at 14:58 -0600, Alex Williamson wrote:
> Our code paths for saving or migrating a VM are full of functions that
> return void, leaving no opportunity for a device to cancel a migration,
> either from error or incompatibility. The ivshmem driver attempted to
> solve this with a no_migrate flag on the save state entry. I think the
> more generic and flexible way to solve this is to allow driver save
> functions to fail. This series implements that and converts ivshmem
> to uses a set_params function to NAK migration much earlier in the
> processes. This touches a lot of files, but bulk of those changes are
> simply s/void/int/ and tacking a "return 0" to the end of functions.
> Thanks,
>
> Alex
>
> ---
>
> Alex Williamson (6):
> savevm: Remove register_device_unmigratable()
> savevm: Allow set_params and save_live_state to error
> virtio: Allow virtio_save() errors
> pci: Allow pci_device_save() to return error
> savevm: Allow vmsd->pre_save to return error
> savevm: Allow SaveStateHandler() to return error
>
>
> block-migration.c | 4 +-
> hw/adb.c | 8 +++-
> hw/ads7846.c | 4 +-
> hw/arm_gic.c | 4 +-
> hw/arm_timer.c | 6 ++-
> hw/armv7m_nvic.c | 4 +-
> hw/cuda.c | 4 +-
> hw/fdc.c | 3 +
> hw/g364fb.c | 4 +-
> hw/grackle_pci.c | 4 +-
> hw/gt64xxx.c | 4 +-
> hw/heathrow_pic.c | 4 +-
> hw/hpet.c | 3 +
> hw/hw.h | 12 ++----
> hw/i2c.c | 3 +
> hw/ide/core.c | 4 +-
> hw/ivshmem.c | 30 +++++++++++----
> hw/lsi53c895a.c | 4 +-
> hw/m48t59.c | 4 +-
> hw/mac_dbdma.c | 4 +-
> hw/mac_nvram.c | 4 +-
> hw/max111x.c | 4 +-
> hw/mipsnet.c | 4 +-
> hw/mst_fpga.c | 3 +
> hw/nand.c | 3 +
> hw/openpic.c | 4 +-
> hw/pci.c | 9 +++-
> hw/pci.h | 2 -
> hw/piix4.c | 4 +-
> hw/pl011.c | 4 +-
> hw/pl022.c | 4 +-
> hw/pl061.c | 4 +-
> hw/ppc4xx_pci.c | 11 ++++-
> hw/ppce500_pci.c | 11 ++++-
> hw/pxa2xx.c | 28 ++++++++++----
> hw/pxa2xx_dma.c | 4 +-
> hw/pxa2xx_gpio.c | 4 +-
> hw/pxa2xx_keypad.c | 3 +
> hw/pxa2xx_lcd.c | 4 +-
> hw/pxa2xx_mmci.c | 4 +-
> hw/pxa2xx_pic.c | 4 +-
> hw/pxa2xx_timer.c | 4 +-
> hw/rc4030.c | 4 +-
> hw/rtl8139.c | 4 +-
> hw/serial.c | 3 +
> hw/spitz.c | 14 +++++--
> hw/ssd0323.c | 4 +-
> hw/ssi-sd.c | 4 +-
> hw/stellaris.c | 20 +++++++---
> hw/stellaris_enet.c | 4 +-
> hw/stellaris_input.c | 4 +-
> hw/syborg_fb.c | 4 +-
> hw/syborg_interrupt.c | 3 +
> hw/syborg_keyboard.c | 3 +
> hw/syborg_pointer.c | 3 +
> hw/syborg_rtc.c | 4 +-
> hw/syborg_serial.c | 4 +-
> hw/syborg_timer.c | 4 +-
> hw/tsc2005.c | 4 +-
> hw/tsc210x.c | 4 +-
> hw/twl92230.c | 3 +
> hw/unin_pci.c | 4 +-
> hw/usb-uhci.c | 3 +
> hw/virtio-balloon.c | 9 +++-
> hw/virtio-blk.c | 10 ++++-
> hw/virtio-net.c | 11 ++++-
> hw/virtio-pci.c | 10 ++++-
> hw/virtio-serial-bus.c | 10 ++++-
> hw/virtio.c | 14 +++++--
> hw/virtio.h | 4 +-
> hw/wm8750.c | 3 +
> hw/zaurus.c | 4 +-
> qemu-common.h | 2 -
> savevm.c | 88 +++++++++++++++++++------------------------
> slirp/slirp.c | 6 ++-
> target-arm/machine.c | 3 +
> target-cris/machine.c | 3 +
> target-i386/machine.c | 7 ++-
> target-microblaze/machine.c | 3 +
> target-mips/machine.c | 3 +
> target-ppc/machine.c | 3 +
> target-s390x/machine.c | 3 +
> target-sparc/machine.c | 3 +
> 83 files changed, 365 insertions(+), 181 deletions(-)
[-- Attachment #2: kvm-1.patch --]
[-- Type: text/x-patch, Size: 868 bytes --]
kvm: update for: savevm: Allow SaveStateHandler() to return error
From: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
---
kvm-tpr-opt.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/kvm-tpr-opt.c b/kvm-tpr-opt.c
index 46890e2..632b6d6 100644
--- a/kvm-tpr-opt.c
+++ b/kvm-tpr-opt.c
@@ -296,7 +296,7 @@ void kvm_tpr_access_report(CPUState *env, uint64_t rip, int is_write)
patch_instruction(env, rip);
}
-static void tpr_save(QEMUFile *f, void *s)
+static int tpr_save(QEMUFile *f, void *s)
{
int i;
@@ -307,6 +307,8 @@ static void tpr_save(QEMUFile *f, void *s)
qemu_put_be32s(f, &bios_addr);
qemu_put_be32s(f, &vapic_phys);
qemu_put_be32s(f, &vbios_desc_phys);
+
+ return 0;
}
static int tpr_load(QEMUFile *f, void *s, int version_id)
[-- Attachment #3: kvm-2.patch --]
[-- Type: text/x-patch, Size: 2542 bytes --]
kvm: update for: savevm: Allow vmsd->pre_save to return error
From: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
---
hw/i8254-kvm.c | 3 ++-
hw/i8259.c | 3 ++-
hw/ioapic.c | 3 ++-
qemu-kvm-x86.c | 4 +++-
4 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/hw/i8254-kvm.c b/hw/i8254-kvm.c
index 6125213..9c62b87 100644
--- a/hw/i8254-kvm.c
+++ b/hw/i8254-kvm.c
@@ -32,7 +32,7 @@ extern VMStateDescription vmstate_pit;
static PITState pit_state;
-static void kvm_pit_pre_save(void *opaque)
+static int kvm_pit_pre_save(void *opaque)
{
PITState *s = (void *)opaque;
struct kvm_pit_state2 pit2;
@@ -64,6 +64,7 @@ static void kvm_pit_pre_save(void *opaque)
sc->gate = c->gate;
sc->count_load_time = c->count_load_time;
}
+ return 0;
}
static int kvm_pit_post_load(void *opaque, int version_id)
diff --git a/hw/i8259.c b/hw/i8259.c
index 986dcf5..fc06c44 100644
--- a/hw/i8259.c
+++ b/hw/i8259.c
@@ -470,13 +470,14 @@ static uint32_t elcr_ioport_read(void *opaque, uint32_t addr1)
static void kvm_kernel_pic_save_to_user(PicState *s);
static int kvm_kernel_pic_load_from_user(PicState *s);
-static void pic_pre_save(void *opaque)
+static int pic_pre_save(void *opaque)
{
PicState *s = opaque;
if (kvm_enabled() && kvm_irqchip_in_kernel()) {
kvm_kernel_pic_save_to_user(s);
}
+ return 0;
}
static int pic_post_load(void *opaque, int version_id)
diff --git a/hw/ioapic.c b/hw/ioapic.c
index 276c72e..4f71027 100644
--- a/hw/ioapic.c
+++ b/hw/ioapic.c
@@ -249,13 +249,14 @@ static void kvm_kernel_ioapic_load_from_user(IOAPICState *s)
#endif
}
-static void ioapic_pre_save(void *opaque)
+static int ioapic_pre_save(void *opaque)
{
IOAPICState *s = (void *)opaque;
if (kvm_enabled() && kvm_irqchip_in_kernel()) {
kvm_kernel_ioapic_save_to_user(s);
}
+ return 0;
}
static int ioapic_pre_load(void *opaque)
diff --git a/qemu-kvm-x86.c b/qemu-kvm-x86.c
index fd974b3..1dcea38 100644
--- a/qemu-kvm-x86.c
+++ b/qemu-kvm-x86.c
@@ -561,11 +561,13 @@ static int kvm_enable_tpr_access_reporting(CPUState *env)
#ifdef KVM_CAP_ADJUST_CLOCK
static struct kvm_clock_data kvmclock_data;
-static void kvmclock_pre_save(void *opaque)
+static int kvmclock_pre_save(void *opaque)
{
struct kvm_clock_data *cl = opaque;
kvm_vm_ioctl(kvm_state, KVM_GET_CLOCK, cl);
+
+ return 0;
}
static int kvmclock_post_load(void *opaque, int version_id)
^ permalink raw reply related
* Re: [PATCH 0/6] Save state error handling (kill off no_migrate)
From: Alex Williamson @ 2010-10-07 16:55 UTC (permalink / raw)
To: Avi Kivity, Marcelo Tosatti; +Cc: kvm, cam, quintela, anthony, qemu-devel
In-Reply-To: <20101006204546.32127.70109.stgit@s20.home>
[-- Attachment #1: Type: text/plain, Size: 4783 bytes --]
Avi, Marcelo,
Assuming this gets merged to qemu.git, you'll need the attached trivial
updates for the qemu-kvm.git merge. Thanks,
Alex
On Wed, 2010-10-06 at 14:58 -0600, Alex Williamson wrote:
> Our code paths for saving or migrating a VM are full of functions that
> return void, leaving no opportunity for a device to cancel a migration,
> either from error or incompatibility. The ivshmem driver attempted to
> solve this with a no_migrate flag on the save state entry. I think the
> more generic and flexible way to solve this is to allow driver save
> functions to fail. This series implements that and converts ivshmem
> to uses a set_params function to NAK migration much earlier in the
> processes. This touches a lot of files, but bulk of those changes are
> simply s/void/int/ and tacking a "return 0" to the end of functions.
> Thanks,
>
> Alex
>
> ---
>
> Alex Williamson (6):
> savevm: Remove register_device_unmigratable()
> savevm: Allow set_params and save_live_state to error
> virtio: Allow virtio_save() errors
> pci: Allow pci_device_save() to return error
> savevm: Allow vmsd->pre_save to return error
> savevm: Allow SaveStateHandler() to return error
>
>
> block-migration.c | 4 +-
> hw/adb.c | 8 +++-
> hw/ads7846.c | 4 +-
> hw/arm_gic.c | 4 +-
> hw/arm_timer.c | 6 ++-
> hw/armv7m_nvic.c | 4 +-
> hw/cuda.c | 4 +-
> hw/fdc.c | 3 +
> hw/g364fb.c | 4 +-
> hw/grackle_pci.c | 4 +-
> hw/gt64xxx.c | 4 +-
> hw/heathrow_pic.c | 4 +-
> hw/hpet.c | 3 +
> hw/hw.h | 12 ++----
> hw/i2c.c | 3 +
> hw/ide/core.c | 4 +-
> hw/ivshmem.c | 30 +++++++++++----
> hw/lsi53c895a.c | 4 +-
> hw/m48t59.c | 4 +-
> hw/mac_dbdma.c | 4 +-
> hw/mac_nvram.c | 4 +-
> hw/max111x.c | 4 +-
> hw/mipsnet.c | 4 +-
> hw/mst_fpga.c | 3 +
> hw/nand.c | 3 +
> hw/openpic.c | 4 +-
> hw/pci.c | 9 +++-
> hw/pci.h | 2 -
> hw/piix4.c | 4 +-
> hw/pl011.c | 4 +-
> hw/pl022.c | 4 +-
> hw/pl061.c | 4 +-
> hw/ppc4xx_pci.c | 11 ++++-
> hw/ppce500_pci.c | 11 ++++-
> hw/pxa2xx.c | 28 ++++++++++----
> hw/pxa2xx_dma.c | 4 +-
> hw/pxa2xx_gpio.c | 4 +-
> hw/pxa2xx_keypad.c | 3 +
> hw/pxa2xx_lcd.c | 4 +-
> hw/pxa2xx_mmci.c | 4 +-
> hw/pxa2xx_pic.c | 4 +-
> hw/pxa2xx_timer.c | 4 +-
> hw/rc4030.c | 4 +-
> hw/rtl8139.c | 4 +-
> hw/serial.c | 3 +
> hw/spitz.c | 14 +++++--
> hw/ssd0323.c | 4 +-
> hw/ssi-sd.c | 4 +-
> hw/stellaris.c | 20 +++++++---
> hw/stellaris_enet.c | 4 +-
> hw/stellaris_input.c | 4 +-
> hw/syborg_fb.c | 4 +-
> hw/syborg_interrupt.c | 3 +
> hw/syborg_keyboard.c | 3 +
> hw/syborg_pointer.c | 3 +
> hw/syborg_rtc.c | 4 +-
> hw/syborg_serial.c | 4 +-
> hw/syborg_timer.c | 4 +-
> hw/tsc2005.c | 4 +-
> hw/tsc210x.c | 4 +-
> hw/twl92230.c | 3 +
> hw/unin_pci.c | 4 +-
> hw/usb-uhci.c | 3 +
> hw/virtio-balloon.c | 9 +++-
> hw/virtio-blk.c | 10 ++++-
> hw/virtio-net.c | 11 ++++-
> hw/virtio-pci.c | 10 ++++-
> hw/virtio-serial-bus.c | 10 ++++-
> hw/virtio.c | 14 +++++--
> hw/virtio.h | 4 +-
> hw/wm8750.c | 3 +
> hw/zaurus.c | 4 +-
> qemu-common.h | 2 -
> savevm.c | 88 +++++++++++++++++++------------------------
> slirp/slirp.c | 6 ++-
> target-arm/machine.c | 3 +
> target-cris/machine.c | 3 +
> target-i386/machine.c | 7 ++-
> target-microblaze/machine.c | 3 +
> target-mips/machine.c | 3 +
> target-ppc/machine.c | 3 +
> target-s390x/machine.c | 3 +
> target-sparc/machine.c | 3 +
> 83 files changed, 365 insertions(+), 181 deletions(-)
[-- Attachment #2: kvm-1.patch --]
[-- Type: text/x-patch, Size: 868 bytes --]
kvm: update for: savevm: Allow SaveStateHandler() to return error
From: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
---
kvm-tpr-opt.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/kvm-tpr-opt.c b/kvm-tpr-opt.c
index 46890e2..632b6d6 100644
--- a/kvm-tpr-opt.c
+++ b/kvm-tpr-opt.c
@@ -296,7 +296,7 @@ void kvm_tpr_access_report(CPUState *env, uint64_t rip, int is_write)
patch_instruction(env, rip);
}
-static void tpr_save(QEMUFile *f, void *s)
+static int tpr_save(QEMUFile *f, void *s)
{
int i;
@@ -307,6 +307,8 @@ static void tpr_save(QEMUFile *f, void *s)
qemu_put_be32s(f, &bios_addr);
qemu_put_be32s(f, &vapic_phys);
qemu_put_be32s(f, &vbios_desc_phys);
+
+ return 0;
}
static int tpr_load(QEMUFile *f, void *s, int version_id)
[-- Attachment #3: kvm-2.patch --]
[-- Type: text/x-patch, Size: 2542 bytes --]
kvm: update for: savevm: Allow vmsd->pre_save to return error
From: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
---
hw/i8254-kvm.c | 3 ++-
hw/i8259.c | 3 ++-
hw/ioapic.c | 3 ++-
qemu-kvm-x86.c | 4 +++-
4 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/hw/i8254-kvm.c b/hw/i8254-kvm.c
index 6125213..9c62b87 100644
--- a/hw/i8254-kvm.c
+++ b/hw/i8254-kvm.c
@@ -32,7 +32,7 @@ extern VMStateDescription vmstate_pit;
static PITState pit_state;
-static void kvm_pit_pre_save(void *opaque)
+static int kvm_pit_pre_save(void *opaque)
{
PITState *s = (void *)opaque;
struct kvm_pit_state2 pit2;
@@ -64,6 +64,7 @@ static void kvm_pit_pre_save(void *opaque)
sc->gate = c->gate;
sc->count_load_time = c->count_load_time;
}
+ return 0;
}
static int kvm_pit_post_load(void *opaque, int version_id)
diff --git a/hw/i8259.c b/hw/i8259.c
index 986dcf5..fc06c44 100644
--- a/hw/i8259.c
+++ b/hw/i8259.c
@@ -470,13 +470,14 @@ static uint32_t elcr_ioport_read(void *opaque, uint32_t addr1)
static void kvm_kernel_pic_save_to_user(PicState *s);
static int kvm_kernel_pic_load_from_user(PicState *s);
-static void pic_pre_save(void *opaque)
+static int pic_pre_save(void *opaque)
{
PicState *s = opaque;
if (kvm_enabled() && kvm_irqchip_in_kernel()) {
kvm_kernel_pic_save_to_user(s);
}
+ return 0;
}
static int pic_post_load(void *opaque, int version_id)
diff --git a/hw/ioapic.c b/hw/ioapic.c
index 276c72e..4f71027 100644
--- a/hw/ioapic.c
+++ b/hw/ioapic.c
@@ -249,13 +249,14 @@ static void kvm_kernel_ioapic_load_from_user(IOAPICState *s)
#endif
}
-static void ioapic_pre_save(void *opaque)
+static int ioapic_pre_save(void *opaque)
{
IOAPICState *s = (void *)opaque;
if (kvm_enabled() && kvm_irqchip_in_kernel()) {
kvm_kernel_ioapic_save_to_user(s);
}
+ return 0;
}
static int ioapic_pre_load(void *opaque)
diff --git a/qemu-kvm-x86.c b/qemu-kvm-x86.c
index fd974b3..1dcea38 100644
--- a/qemu-kvm-x86.c
+++ b/qemu-kvm-x86.c
@@ -561,11 +561,13 @@ static int kvm_enable_tpr_access_reporting(CPUState *env)
#ifdef KVM_CAP_ADJUST_CLOCK
static struct kvm_clock_data kvmclock_data;
-static void kvmclock_pre_save(void *opaque)
+static int kvmclock_pre_save(void *opaque)
{
struct kvm_clock_data *cl = opaque;
kvm_vm_ioctl(kvm_state, KVM_GET_CLOCK, cl);
+
+ return 0;
}
static int kvmclock_post_load(void *opaque, int version_id)
^ permalink raw reply related
* Re: (no subject)
From: George Shuklin @ 2010-10-07 16:54 UTC (permalink / raw)
To: xen-devel@lists.xensource.com
In-Reply-To: <1286461291.23155.20294.camel@zakaz.uk.xensource.com>
В Чтв, 07/10/2010 в 15:21 +0100, Ian Campbell пишет:
> On Thu, 2010-10-07 at 14:43 +0100, George Shuklin wrote:
> > Please note this bug:
> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=595711
> >
> > This behavior confirmed in lenny and squeeze. Kernel is very unstable
> > (compare to centos/suse) and cause OOM killer without any rational
> > reason.
>
> I wasn't aware that this issue was present on Squeeze as well as Lenny,
> there is no mention of that in the bug.
>
> The two kernels have practically nothing in common wrt the Xen port
> (Lenny was classic-Xen patch based and Squeeze is pvops based) so if you
> are seeing something similar under Squeeze as well please file a
> separate bug report.
OK, I'll recheck bug in squeeze and report it separately.
Main problem for this bug is very high value of free memory when OOM
killer starts. In my tests it appear when about 300MiB was free. And it
kill not most 'badness' process, but runs repeatedly for few (or even
all) process.
But, again, I'll recheck it in clean environment with reproducible
behavior and submit it.
^ permalink raw reply
* SRP submaintainership
From: Roland Dreier @ 2010-10-07 16:54 UTC (permalink / raw)
To: linux-rdma-u79uwXL29TY76Z2rM5mHXA
Dave Dillow has been involved with both kernel development and SRP for
a long time, and I trust Dave's technical judgement and good taste
about the SRP code. Dave has graciously agreed to serve as a
submaintainer for the SRP initiator, which should mean that SRP
patches will get more focus and also free me to spend more time on
other maintenance/patch review.
Thanks Dave!
- Roland
===
MAINTAINERS: Hand off SCSI RDMA Protocol (SRP) initiator to Dave Dillow
Signed-off-by: Roland Dreier <rolandd-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org>
---
MAINTAINERS | 10 ++++++++++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index f46d8e6..1c72a42 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5041,6 +5041,16 @@ W: http://www.kernel.dk
S: Maintained
F: drivers/scsi/sr*
+SCSI RDMA PROTOCOL (SRP) INITIATOR
+M: David Dillow <dillowda-1Heg1YXhbW8@public.gmane.org>
+L: linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
+S: Supported
+W: http://www.openfabrics.org
+Q: http://patchwork.kernel.org/project/linux-rdma/list/
+T: git git://git.kernel.org/pub/scm/linux/kernel/git/dad/srp-initiator.git
+F: drivers/infiniband/ulp/srp/
+F: include/scsi/srp.h
+
SCSI SG DRIVER
M: Doug Gilbert <dgilbert-qazKcTl6WRFWk0Htik3J/w@public.gmane.org>
L: linux-scsi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* RE: [PATCH 0/2] mmc: omap_hsmmc: support SDIO cards (#2)
From: Madhusudhan @ 2010-10-07 16:52 UTC (permalink / raw)
To: 'Steve Sakoman', 'Mike Rapoport'
Cc: 'David Vrabel', 'Chris Ball', linux-mmc,
linux-omap, 'Adrian Hunter'
In-Reply-To: <AANLkTimvHnLAchE-Ed1Zve-PU6S98Euj=bFaAtkDWWji@mail.gmail.com>
> -----Original Message-----
> From: Steve Sakoman [mailto:sakoman@gmail.com]
> Sent: Thursday, October 07, 2010 8:57 AM
> To: Mike Rapoport
> Cc: Madhusudhan Chikkature; David Vrabel; Chris Ball; linux-
> mmc@vger.kernel.org; linux-omap@vger.kernel.org; Adrian Hunter
> Subject: Re: [PATCH 0/2] mmc: omap_hsmmc: support SDIO cards (#2)
>
> On Thu, Oct 7, 2010 at 12:15 AM, Mike Rapoport <mike@compulab.co.il>
> wrote:
> > Hi Madhu,
> >
> > Madhusudhan Chikkature wrote:
> >>
> >> <snip>
> >>
> >>> You are correct! The version of the patch in the repo indeed has
> >>> 'out' in the wrong place and generates a compile error.
> >>>
> >>> Could you post the patch you are using and I will try to reproduce
> >>> what you are seeing on my hardware? Best we all work from exactly the
> >>> same patch!
> >>>
> >>> Steve
> >>>
> >>
> >> Yes. I think that check breaking the compilation is not needed. How
> about
> >> the
> >> below version? It just removes that check.
> >>
> >> This version should apply fine on the latest kernel. I did a sanity
> test
> >> of
> >> MMC/SD cards on OMAP4 SDP.
> >>
> >> Steve or Mike can check if SDIO interrupts are working.
> >
> > With you patch I get the same:
> >
> > libertas_sdio: Libertas SDIO driver
> > libertas_sdio: Copyright Pierre Ossman
> > libertas: command 0x0003 timed out
> > libertas: Timeout submitting command 0x0003
> > libertas: PREP_CMD: command 0x0003 failed: -110
> > libertas_sdio: probe of mmc1:0001:1 failed with error -110
>
> I can confirm exactly the same behavior on my hardware with this
> version of the patch.
>
Steve,
Okay. Did the version you had in your tree worked? I just want to check if I
messed up something in my patch.
Regards,
Madhu
> Steve
^ permalink raw reply
* [PATCHv2 1/2] mx51: Move OTG initialisation for all boards to a single file
From: Sascha Hauer @ 2010-10-07 16:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e36487b7aeb3a70ad411456180ec5f245430e48a.1286463146.git.amit.kucheria@linaro.org>
On Thu, Oct 07, 2010 at 06:07:21PM +0300, Amit Kucheria wrote:
> The OTG initialisation is the same for all MX51 boards currently known. Move
> to a common file.
>
> Fix the pll divider name while at it: MX51_USB_PLL_DIV_24_MHZ corresponds to
> 0x1, not MX51_USB_PLL_DIV_19_2_MHZ
>
> Signed-off-by: Amit Kucheria <amit.kucheria@linaro.org>
> ---
> arch/arm/mach-mx5/Makefile | 2 +-
> arch/arm/mach-mx5/board-cpuimx51.c | 30 ++--------------------
> arch/arm/mach-mx5/board-mx51_babbage.c | 30 ++--------------------
> arch/arm/mach-mx5/usb.c | 42 ++++++++++++++++++++++++++++++++
> arch/arm/mach-mx5/usb.h | 1 +
> 5 files changed, 50 insertions(+), 55 deletions(-)
> create mode 100644 arch/arm/mach-mx5/usb.c
> create mode 100644 arch/arm/mach-mx5/usb.h
>
> diff --git a/arch/arm/mach-mx5/Makefile b/arch/arm/mach-mx5/Makefile
> index 86c66e7..ac0d14c 100644
> --- a/arch/arm/mach-mx5/Makefile
> +++ b/arch/arm/mach-mx5/Makefile
> @@ -3,7 +3,7 @@
> #
>
> # Object file lists.
> -obj-y := cpu.o mm.o clock-mx51.o devices.o
> +obj-y := cpu.o mm.o clock-mx51.o devices.o usb.o
>
> obj-$(CONFIG_MACH_MX51_BABBAGE) += board-mx51_babbage.o
> obj-$(CONFIG_MACH_MX51_3DS) += board-mx51_3ds.o
> diff --git a/arch/arm/mach-mx5/board-cpuimx51.c b/arch/arm/mach-mx5/board-cpuimx51.c
> index a6c09c7..ff5d223 100644
> --- a/arch/arm/mach-mx5/board-cpuimx51.c
> +++ b/arch/arm/mach-mx5/board-cpuimx51.c
> @@ -39,6 +39,7 @@
>
> #include "devices-imx51.h"
> #include "devices.h"
> +#include "usb.h"
>
> #define CPUIMX51_USBH1_STP (0*32 + 27)
> #define CPUIMX51_QUARTA_GPIO (2*32 + 28)
> @@ -56,10 +57,6 @@
> #define MX51_USB_CTRL_1_OFFSET 0x10
> #define MX51_USB_CTRL_UH1_EXT_CLK_EN (1 << 25)
>
> -#define MX51_USB_PLLDIV_12_MHZ 0x00
> -#define MX51_USB_PLL_DIV_19_2_MHZ 0x01
> -#define MX51_USB_PLL_DIV_24_MHZ 0x02
> -
> #if defined(CONFIG_SERIAL_8250) || defined(CONFIG_SERIAL_8250_MODULE)
> static struct plat_serial8250_port serial_platform_data[] = {
> {
> @@ -162,27 +159,6 @@ static struct i2c_board_info eukrea_cpuimx51_i2c_devices[] = {
> },
> };
>
> -/* This function is board specific as the bit mask for the plldiv will also
> -be different for other Freescale SoCs, thus a common bitmask is not
> -possible and cannot get place in /plat-mxc/ehci.c.*/
> -static int initialize_otg_port(struct platform_device *pdev)
> -{
> - u32 v;
> - void __iomem *usb_base;
> - void __iomem *usbother_base;
> -
> - usb_base = ioremap(MX51_OTG_BASE_ADDR, SZ_4K);
> - usbother_base = usb_base + MX5_USBOTHER_REGS_OFFSET;
> -
> - /* Set the PHY clock to 19.2MHz */
> - v = __raw_readl(usbother_base + MXC_USB_PHY_CTR_FUNC2_OFFSET);
> - v &= ~MX5_USB_UTMI_PHYCTRL1_PLLDIV_MASK;
> - v |= MX51_USB_PLL_DIV_19_2_MHZ;
> - __raw_writel(v, usbother_base + MXC_USB_PHY_CTR_FUNC2_OFFSET);
> - iounmap(usb_base);
> - return 0;
> -}
> -
> static int initialize_usbh1_port(struct platform_device *pdev)
> {
> u32 v;
> @@ -200,7 +176,7 @@ static int initialize_usbh1_port(struct platform_device *pdev)
> }
>
> static struct mxc_usbh_platform_data dr_utmi_config = {
> - .init = initialize_otg_port,
> + .init = mx51_initialize_otg_port,
> .portsc = MXC_EHCI_UTMI_16BIT,
> .flags = MXC_EHCI_INTERNAL_PHY,
> };
> @@ -262,7 +238,7 @@ static void __init eukrea_cpuimx51_init(void)
> if (otg_mode_host)
> mxc_register_device(&mxc_usbdr_host_device, &dr_utmi_config);
> else {
> - initialize_otg_port(NULL);
> + mx51_initialize_otg_port(NULL);
> mxc_register_device(&mxc_usbdr_udc_device, &usb_pdata);
> }
> mxc_register_device(&mxc_usbh1_device, &usbh1_config);
> diff --git a/arch/arm/mach-mx5/board-mx51_babbage.c b/arch/arm/mach-mx5/board-mx51_babbage.c
> index 7c0b661..a84de02 100644
> --- a/arch/arm/mach-mx5/board-mx51_babbage.c
> +++ b/arch/arm/mach-mx5/board-mx51_babbage.c
> @@ -32,6 +32,7 @@
>
> #include "devices-imx51.h"
> #include "devices.h"
> +#include "usb.h"
>
> #define BABBAGE_USB_HUB_RESET (0*32 + 7) /* GPIO_1_7 */
> #define BABBAGE_USBH1_STP (0*32 + 27) /* GPIO_1_27 */
> @@ -42,10 +43,6 @@
> #define MX51_USB_CTRL_1_OFFSET 0x10
> #define MX51_USB_CTRL_UH1_EXT_CLK_EN (1 << 25)
>
> -#define MX51_USB_PLLDIV_12_MHZ 0x00
> -#define MX51_USB_PLL_DIV_19_2_MHZ 0x01
> -#define MX51_USB_PLL_DIV_24_MHZ 0x02
> -
> static struct platform_device *devices[] __initdata = {
> &mxc_fec_device,
> };
> @@ -210,27 +207,6 @@ static inline void babbage_fec_reset(void)
> gpio_set_value(BABBAGE_FEC_PHY_RESET, 1);
> }
>
> -/* This function is board specific as the bit mask for the plldiv will also
> -be different for other Freescale SoCs, thus a common bitmask is not
> -possible and cannot get place in /plat-mxc/ehci.c.*/
> -static int initialize_otg_port(struct platform_device *pdev)
> -{
> - u32 v;
> - void __iomem *usb_base;
> - void __iomem *usbother_base;
> -
> - usb_base = ioremap(MX51_OTG_BASE_ADDR, SZ_4K);
> - usbother_base = usb_base + MX5_USBOTHER_REGS_OFFSET;
> -
> - /* Set the PHY clock to 19.2MHz */
> - v = __raw_readl(usbother_base + MXC_USB_PHY_CTR_FUNC2_OFFSET);
> - v &= ~MX5_USB_UTMI_PHYCTRL1_PLLDIV_MASK;
> - v |= MX51_USB_PLL_DIV_19_2_MHZ;
> - __raw_writel(v, usbother_base + MXC_USB_PHY_CTR_FUNC2_OFFSET);
> - iounmap(usb_base);
> - return 0;
> -}
> -
> static int initialize_usbh1_port(struct platform_device *pdev)
> {
> u32 v;
> @@ -248,7 +224,7 @@ static int initialize_usbh1_port(struct platform_device *pdev)
> }
>
> static struct mxc_usbh_platform_data dr_utmi_config = {
> - .init = initialize_otg_port,
> + .init = mx51_initialize_otg_port,
> .portsc = MXC_EHCI_UTMI_16BIT,
> .flags = MXC_EHCI_INTERNAL_PHY,
> };
> @@ -299,7 +275,7 @@ static void __init mxc_board_init(void)
> if (otg_mode_host)
> mxc_register_device(&mxc_usbdr_host_device, &dr_utmi_config);
> else {
> - initialize_otg_port(NULL);
> + mx51_initialize_otg_port(NULL);
> mxc_register_device(&mxc_usbdr_udc_device, &usb_pdata);
> }
>
> diff --git a/arch/arm/mach-mx5/usb.c b/arch/arm/mach-mx5/usb.c
> new file mode 100644
> index 0000000..ebb7c3a
> --- /dev/null
> +++ b/arch/arm/mach-mx5/usb.c
> @@ -0,0 +1,42 @@
> +/*
> + * Copyright (C) 2010 Linaro Limited
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include <linux/platform_device.h>
> +#include <linux/io.h>
> +
> +#include <mach/hardware.h>
> +#include <mach/mxc_ehci.h>
> +
> +#define MX51_USB_PLL_DIV_24_MHZ 0x01
> +
> +/* This function is SoC-specific as the bit mask for the plldiv will also
> + * be different for other Freescale SoCs, thus a common bitmask is not
> + * possible and cannot get place in /plat-mxc/ehci.c.
> + */
> +int mx51_initialize_otg_port(struct platform_device *pdev)
> +{
> + u32 v;
> + void __iomem *usb_base;
> + void __iomem *usbother_base;
> +
> + usb_base = ioremap(MX51_OTG_BASE_ADDR, SZ_4K);
> + if (!usb_base) {
> + dev_err(&pdev->dev, "OTG ioremap failed\n");
> + return -ENOMEM;
> + }
> + usbother_base = usb_base + MX5_USBOTHER_REGS_OFFSET;
> +
> + /* Set the PHY clock to 24 MHz */
> + v = __raw_readl(usbother_base + MXC_USB_PHY_CTR_FUNC2_OFFSET);
> + v &= ~MX5_USB_UTMI_PHYCTRL1_PLLDIV_MASK;
> + v |= MX51_USB_PLL_DIV_24_MHZ;
> + __raw_writel(v, usbother_base + MXC_USB_PHY_CTR_FUNC2_OFFSET);
> + iounmap(usb_base);
> +
> + return 0;
> +}
Hm, can't we have a function which gets a pointer to a struct containing
all relevant register settings like described in my other mail this day?
We could even start doing so by only changing the i.MX51 code.
BTW this function only works because the i.MX51 clock layer forgets to
turn of unused clocks. I tried to turn off the clocks to get the CPU a
bit cooler and this one place where it failed.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* Re: [RFC PATCH] poll(): add poll_wait_set_exclusive()
From: Mathieu Desnoyers @ 2010-10-07 16:53 UTC (permalink / raw)
To: Linus Torvalds
Cc: Steven Rostedt, LKML, Andrew Morton, Peter Zijlstra, Ingo Molnar,
Frederic Weisbecker, Thomas Gleixner, Christoph Hellwig, Li Zefan,
Lai Jiangshan, Johannes Berg, Masami Hiramatsu,
Arnaldo Carvalho de Melo, Tom Zanussi, KOSAKI Motohiro,
Andi Kleen, Paul E. McKenney, Davide Libenzi
In-Reply-To: <AANLkTin6na1PyFDK5Oua0_ep8PzUNi=iceYdGQ03=F-Y@mail.gmail.com>
* Linus Torvalds (torvalds@linux-foundation.org) wrote:
> On Wed, Oct 6, 2010 at 12:04 PM, Mathieu Desnoyers
> <mathieu.desnoyers@efficios.com> wrote:
[...]
> So no, I don't think it's acceptable to say that certain files just
> act differently wrt "poll".
Agreed.
>
> > Maybe what I am trying to do is too far from the poll() semantic and does not
> > apply in the general case, but I clearly see the need, at least in the use-case
> > detailed below, to wake up only one thread at a time, whether we call this
> > "poll" or something else. One way to make it available more generally might be
> > to add a new open() flag and require that all open() of a given file should use
> > the flag to provide the "wakeup only one thread" behavior.
>
> I think that would be a better interface, but still sucky and badly
> designed. Why? Because the obvious case where you might want to have
> the whole "only wake up a single thread" is actually for sockets, so
> having an open-time flag is just insane.
Good point.
> Making it be an file status flag (and then use fcntl F_[GS]ETFL on it)
> might work. At the same time, I have the suspicion that it would be
> much nicer to embed it into the "requested events" field to poll, and
> simply add a "exclusive read" poll event (POLLINEX or whatever).
> Because it's really the "poll()" function itself that says "I promise
> that if you return a readable file descriptor, I will read everything
> from it" - it's really an attribute local to the "poll()", not to the
> file descriptor.
This is interesting. I'm just concerned that if we have many poll() waiting on
the same file descriptor, some with POLLINEX and others without, the poll()
calls expecting the standard POSIX behavior might be hurt. Having a single
poll() call with POLLINEX would affect the behavior of the wakeup list for the
whole file descriptor, with side-effect on non-POLLINEX poll() calls.
Also, the whole question seems to depend on the notion of edge-triggered vs
level-triggered, which is better defined in epoll(). The poll specification by
the opengroup states that "The poll() function shall identify those file
descriptors on which an application can read or write data, or on which certain
events have occurred.", which is basically some blurry definition allowing both
edge- or level- triggering.
I think the POLLINEX scheme you propose here would only work with
the level-triggering semantic, and seems to have a blurry semantic for mix of
POLLINEX/non-POLLINEX poll() calls. I would personally be inclined to go for the
fnctl F_[GS]ETFL solution that applies to the whole file descriptor, so all
users of a file descriptor would agree that the poll semantic of this fd.
> Regardless, I really think that for anything like this to make sense,
> it needs way more than a single use case. So you'd really want to get
> some web server developers excited or something like that. Over the
> years we have learnt that one-off use cases are worthless.
Indeed.
> Also, doesn't eventpoll already support exclusive polling? I dunno.
> Davide might be interested in the discussion regardless.
Looking at epoll(7), the behavior of EPOLLONESHOT when there are multiple epoll
instances monitoring a file descriptor seems unclear: does it stop event
propagation after delivery to the first epoll instance (this is the behavior I
am looking for), or does it stop the event delivery after having woken up all
epoll instances monitoring the file descriptor ? Davide might have the answer to
this one.
Thanks,
Mathieu
--
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com
^ permalink raw reply
* Re: [PATCH] PM: add synchronous runtime interface for interrupt handlers
From: Kevin Hilman @ 2010-10-07 16:52 UTC (permalink / raw)
To: Alan Stern
Cc: Rafael J. Wysocki, Linux-pm mailing list, Partha Basak,
linux-omap
In-Reply-To: <Pine.LNX.4.44L0.1010071048100.1753-100000@iolanthe.rowland.org>
Alan Stern <stern@rowland.harvard.edu> writes:
> On Wed, 6 Oct 2010, Rafael J. Wysocki wrote:
>
>> Defer the resume. That's the only thing you can do in any case, whether you're
>> going to busy loop or just use a workqueue.
>
> They are not the same. With a busy-wait you handle the device as soon
> as possible, before the interrupt routine returns. With a workqueue
> you have to mask the entire IRQ line, possibly losing interrupt
> requests from other devices, until the workqueue routine can run.
>
>> > On the whole, I don't see any striking reason for the PM core not to
>> > busy-wait during a concurrent state change.
>>
>> I do. That shouldn't happen in a fast path and we're talking about one,
>> aren't we? Besides, I don't like busy waiting as a rule.
>
> On Wed, 6 Oct 2010, Kevin Hilman wrote:
>
>> Not sure I follow where you're going with this last paragraph. Of
>> course, calls from ISR context cannot busy wait.
>
> What do you guys think spin_lock() does? It busy-waits until the lock
> is free! If you don't like busy-waiting then you don't like spinlocks,
> and if you believe ISR's can't busy-wait then you believe they can't
> acquire spinlocks. :-)
My confusion is not about the use of spinlocks, it's a question of what
is being busy-waited for, and the thread that is being waited for is
going to complete when interrupts are disabled.
Sorry to be dense, but can you (re)summarize what you're proposing as I
think I'm getting mixed up with all the various options we've been
tossing around.
If it can work, I'm certainly in favor of a busy-wait approach as it
really ensures that sync requests are handled quickly.
Kevin
^ permalink raw reply
* Re: [PATCH] PM: add synchronous runtime interface for interrupt handlers
From: Kevin Hilman @ 2010-10-07 16:52 UTC (permalink / raw)
To: Alan Stern; +Cc: Partha Basak, Linux-pm mailing list, linux-omap
In-Reply-To: <Pine.LNX.4.44L0.1010071048100.1753-100000@iolanthe.rowland.org>
Alan Stern <stern@rowland.harvard.edu> writes:
> On Wed, 6 Oct 2010, Rafael J. Wysocki wrote:
>
>> Defer the resume. That's the only thing you can do in any case, whether you're
>> going to busy loop or just use a workqueue.
>
> They are not the same. With a busy-wait you handle the device as soon
> as possible, before the interrupt routine returns. With a workqueue
> you have to mask the entire IRQ line, possibly losing interrupt
> requests from other devices, until the workqueue routine can run.
>
>> > On the whole, I don't see any striking reason for the PM core not to
>> > busy-wait during a concurrent state change.
>>
>> I do. That shouldn't happen in a fast path and we're talking about one,
>> aren't we? Besides, I don't like busy waiting as a rule.
>
> On Wed, 6 Oct 2010, Kevin Hilman wrote:
>
>> Not sure I follow where you're going with this last paragraph. Of
>> course, calls from ISR context cannot busy wait.
>
> What do you guys think spin_lock() does? It busy-waits until the lock
> is free! If you don't like busy-waiting then you don't like spinlocks,
> and if you believe ISR's can't busy-wait then you believe they can't
> acquire spinlocks. :-)
My confusion is not about the use of spinlocks, it's a question of what
is being busy-waited for, and the thread that is being waited for is
going to complete when interrupts are disabled.
Sorry to be dense, but can you (re)summarize what you're proposing as I
think I'm getting mixed up with all the various options we've been
tossing around.
If it can work, I'm certainly in favor of a busy-wait approach as it
really ensures that sync requests are handled quickly.
Kevin
^ permalink raw reply
* Re: Where is the latest GIT for opensm?
From: Jason Gunthorpe @ 2010-10-07 16:50 UTC (permalink / raw)
To: Jeff Becker
Cc: Sasha Khapyorsky, Linux RDMA list,
ewg-ZwoEplunGu1OwGhvXhtEPSCwEArCW2h5@public.gmane.org,
Vladimir Sokolovsky
In-Reply-To: <4CADEB86.10408-NSQ8wuThN14@public.gmane.org>
On Thu, Oct 07, 2010 at 08:47:18AM -0700, Jeff Becker wrote:
> It would be great if developers could move their git repo's to the new
> server so OFA can stop using (and paying) for the old server. Vlad sent
> out a note about this earlier.
I hate to say it, but could you just rsync everything over, maybe into
a archival dir or something? It would really suck to loose any of the
repositories.
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH V2] Use firmware provided index to register a network interface
From: David Lamparter @ 2010-10-07 16:49 UTC (permalink / raw)
To: Matt Domsch
Cc: Greg KH, Narendra_K, netdev, linux-hotplug, linux-pci,
Jordan_Hargrave, Vijay_Nijhawan, Charles_Rose
In-Reply-To: <20101007163113.GA14260@auslistsprd01.us.dell.com>
Hi Matt,
On Thu, Oct 07, 2010 at 11:31:13AM -0500, Matt Domsch wrote:
> At most, they'll have to deal with the same "eth0_rename"
Getting that "eth0_rename" stuff is not something unchangeably imposed
by the kernel. I think this should be considered an udev bug most of all
things, since if the udev scripts did it right, this wouldn't happen. A
"right" way to do this would for example be to first rename all devices
to "tmpwhatever0", then rename them back to their proper ethX names.
Now I don't know even a single bit about udev scripting, so maybe this
isn't possible with the current udev infrastructure, but there's
certainly no kernel part stopping a proper implementation.
Btw, what happened to nameif(8)? It's totally outdated (and deprecated I
guess?), but it got the job done...
-David
^ permalink raw reply
* Re: [PATCH V2] Use firmware provided index to register a network
From: David Lamparter @ 2010-10-07 16:49 UTC (permalink / raw)
To: Matt Domsch
Cc: Greg KH, Narendra_K, netdev, linux-hotplug, linux-pci,
Jordan_Hargrave, Vijay_Nijhawan, Charles_Rose
In-Reply-To: <20101007163113.GA14260@auslistsprd01.us.dell.com>
Hi Matt,
On Thu, Oct 07, 2010 at 11:31:13AM -0500, Matt Domsch wrote:
> At most, they'll have to deal with the same "eth0_rename"
Getting that "eth0_rename" stuff is not something unchangeably imposed
by the kernel. I think this should be considered an udev bug most of all
things, since if the udev scripts did it right, this wouldn't happen. A
"right" way to do this would for example be to first rename all devices
to "tmpwhatever0", then rename them back to their proper ethX names.
Now I don't know even a single bit about udev scripting, so maybe this
isn't possible with the current udev infrastructure, but there's
certainly no kernel part stopping a proper implementation.
Btw, what happened to nameif(8)? It's totally outdated (and deprecated I
guess?), but it got the job done...
-David
^ permalink raw reply
* Re: [PATCH V2] Use firmware provided index to register a network interface
From: Greg KH @ 2010-10-07 16:48 UTC (permalink / raw)
To: Matt Domsch
Cc: Narendra_K, netdev, linux-hotplug, linux-pci, Jordan_Hargrave,
Vijay_Nijhawan, Charles_Rose
In-Reply-To: <20101007163113.GA14260@auslistsprd01.us.dell.com>
On Thu, Oct 07, 2010 at 11:31:13AM -0500, Matt Domsch wrote:
> On Thu, Oct 07, 2010 at 08:11:34AM -0700, Greg KH wrote:
> > On Thu, Oct 07, 2010 at 07:23:35AM -0700, Narendra_K@Dell.com wrote:
> > > Hello,
> > >
> > > V1 -> V2:
> > >
> > > This patch addresses the scenario of buggy firmware/BIOS tables. The
> > > patch introduces a command line parameter 'no_netfwindex', passing which
> > > firmware provided index will not be used to derive 'eth' names. By
> > > default, firmware index will be used and the parameter can be used to
> > > work around buggy firmware/BIOS tables.
> > >
> > > Please find the patch below.
> > >
> > > From: Narendra K <narendra_k@dell.com>
> > > Subject: [PATCH] Use firmware provided index to register a network device
> > >
> > > This patch uses the firmware provided index to derive the ethN name.
> > > If the firmware provides an index for the corresponding pdev, the N
> > > is derived from the index.
> >
> > No, this has the very big chance to reorder existing network names and
> > should all be done in userspace with the firmware information exported
> > in sysfs, if the user so desires.
>
> Existing names that use 70-persistent-net.rules won't change.
But users that don't use it would cause their names to change, and you
can't break that, no matter how naturally fragile those types of systems
are. Sorry.
> The kernel patch has the advantage of not requiring users to change
> their scripts, by reserving the first N values for onboard devices as
> BIOS describes them.
So you feel that updating a kernel is easier than getting a user to
update their userspace scripts? While I might also feel it is that way,
in reality, it isn't, sorry.
> Userspace udev rules require us to change user behavior, and likely
> their scripts, to use a new namespace such as ethlom1, in order to get
> deterministic naming.
Then use that, don't put this in the kernel please.
> > > It took some time to find out the details asked above. Right,
> > > windows does not use SMBIOS type 41 record to derive names. But as
> > > a datapoint, windows also has the same problem.
>
> > If windows does not use this field, then you can guarantee it will
> > show up incorrectly in BIOSes and never be tested by manufacturers
> > before they ship their machines.
>
> There are 2 methods of exporting the information that have gotten
> confusing here.
>
> 1) SMBIOS type 41 method. Windows does not use this today, and I
> can't speak to their future plans. Narendra's kernel patch does,
> as has biosdevname, the udev helper we first wrote for this
> purpose, for several years.
Then stick with that udev helper please :)
> 2) soon-to-be-released PCIe Firmware Spec, exporting label and index
> as an ACPI _DSM(). It is anticipated that Windows will use this
> information in some fashion at some point, per our conversations
> with Microsoft as part of the PCI SIG proposal process. We've held
> off submitting a kernel patch until the spec is public.
Let's worry about that _when_ it is public, and when there is a Windows
version that supports it please. Until then, there will not be support
for this in BIOSes in any usable way.
> Cases:
> 1) BIOS doesn't provide this information (the common case today for
> all but Dell 10G and newer servers), nothing is reserved, and
> therefore the existing 70-persistent-net.rules take effect to name
> devices. No change in behavior for existing systems. New installs
> will have NICs named non-deterministically, and recorded in
> 70-persistent-net.rules. Users desiring consistent naming must
> adjust 70-persistent-net.rules after install, and to avoid
> eth0_rename collisions, must rename into another namespace.
That's fine and is how things work today, right?
> 2) BIOS provides this information correctly (Dell 10G and newer servers, or
> anyone else implementing the spec). The first N values for onboard
> devices are reserved and assigned by the kernel to onboard
> devices.
And you just broke people's machines that don't use udev for network
naming. Sorry, that's not going to work.
> 70-persistent-net.rules may still try to rename the
> ports, and may fail with eth0_rename collisions.
So you just broke their machines as well, when it was working, again,
not acceptable.
> 3) BIOS provides this information incorrectly (none known today).
Only because we have no way of testing for this :)
> What I can't find here is a solution where the user gets determistic
> naming, without being forced to change the namespace and adjust their
> scripts. Can anyone?
No, and they shoudn't.
You should only have "deterministic" naming if you want it, and you set
it up to do so, from userspace. The kernel is not responsible for this,
sorry.
If you want to do it in userspace, you have all the tools, and the data
exported from the kernel to do so.
> I'm not opposed to "do it all in userspace" - really, I'm not. But
> the 'where' is only part of the problem. No userspace solution has
> yet been proposed that doesn't require a namespace change, and I'm
> still hoping to avoid that.
Just use a new script for people who want this, they will have to know
they want it anyway, right?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH V2] Use firmware provided index to register a network
From: Greg KH @ 2010-10-07 16:48 UTC (permalink / raw)
To: Matt Domsch
Cc: Narendra_K, netdev, linux-hotplug, linux-pci, Jordan_Hargrave,
Vijay_Nijhawan, Charles_Rose
In-Reply-To: <20101007163113.GA14260@auslistsprd01.us.dell.com>
On Thu, Oct 07, 2010 at 11:31:13AM -0500, Matt Domsch wrote:
> On Thu, Oct 07, 2010 at 08:11:34AM -0700, Greg KH wrote:
> > On Thu, Oct 07, 2010 at 07:23:35AM -0700, Narendra_K@Dell.com wrote:
> > > Hello,
> > >
> > > V1 -> V2:
> > >
> > > This patch addresses the scenario of buggy firmware/BIOS tables. The
> > > patch introduces a command line parameter 'no_netfwindex', passing which
> > > firmware provided index will not be used to derive 'eth' names. By
> > > default, firmware index will be used and the parameter can be used to
> > > work around buggy firmware/BIOS tables.
> > >
> > > Please find the patch below.
> > >
> > > From: Narendra K <narendra_k@dell.com>
> > > Subject: [PATCH] Use firmware provided index to register a network device
> > >
> > > This patch uses the firmware provided index to derive the ethN name.
> > > If the firmware provides an index for the corresponding pdev, the N
> > > is derived from the index.
> >
> > No, this has the very big chance to reorder existing network names and
> > should all be done in userspace with the firmware information exported
> > in sysfs, if the user so desires.
>
> Existing names that use 70-persistent-net.rules won't change.
But users that don't use it would cause their names to change, and you
can't break that, no matter how naturally fragile those types of systems
are. Sorry.
> The kernel patch has the advantage of not requiring users to change
> their scripts, by reserving the first N values for onboard devices as
> BIOS describes them.
So you feel that updating a kernel is easier than getting a user to
update their userspace scripts? While I might also feel it is that way,
in reality, it isn't, sorry.
> Userspace udev rules require us to change user behavior, and likely
> their scripts, to use a new namespace such as ethlom1, in order to get
> deterministic naming.
Then use that, don't put this in the kernel please.
> > > It took some time to find out the details asked above. Right,
> > > windows does not use SMBIOS type 41 record to derive names. But as
> > > a datapoint, windows also has the same problem.
>
> > If windows does not use this field, then you can guarantee it will
> > show up incorrectly in BIOSes and never be tested by manufacturers
> > before they ship their machines.
>
> There are 2 methods of exporting the information that have gotten
> confusing here.
>
> 1) SMBIOS type 41 method. Windows does not use this today, and I
> can't speak to their future plans. Narendra's kernel patch does,
> as has biosdevname, the udev helper we first wrote for this
> purpose, for several years.
Then stick with that udev helper please :)
> 2) soon-to-be-released PCIe Firmware Spec, exporting label and index
> as an ACPI _DSM(). It is anticipated that Windows will use this
> information in some fashion at some point, per our conversations
> with Microsoft as part of the PCI SIG proposal process. We've held
> off submitting a kernel patch until the spec is public.
Let's worry about that _when_ it is public, and when there is a Windows
version that supports it please. Until then, there will not be support
for this in BIOSes in any usable way.
> Cases:
> 1) BIOS doesn't provide this information (the common case today for
> all but Dell 10G and newer servers), nothing is reserved, and
> therefore the existing 70-persistent-net.rules take effect to name
> devices. No change in behavior for existing systems. New installs
> will have NICs named non-deterministically, and recorded in
> 70-persistent-net.rules. Users desiring consistent naming must
> adjust 70-persistent-net.rules after install, and to avoid
> eth0_rename collisions, must rename into another namespace.
That's fine and is how things work today, right?
> 2) BIOS provides this information correctly (Dell 10G and newer servers, or
> anyone else implementing the spec). The first N values for onboard
> devices are reserved and assigned by the kernel to onboard
> devices.
And you just broke people's machines that don't use udev for network
naming. Sorry, that's not going to work.
> 70-persistent-net.rules may still try to rename the
> ports, and may fail with eth0_rename collisions.
So you just broke their machines as well, when it was working, again,
not acceptable.
> 3) BIOS provides this information incorrectly (none known today).
Only because we have no way of testing for this :)
> What I can't find here is a solution where the user gets determistic
> naming, without being forced to change the namespace and adjust their
> scripts. Can anyone?
No, and they shoudn't.
You should only have "deterministic" naming if you want it, and you set
it up to do so, from userspace. The kernel is not responsible for this,
sorry.
If you want to do it in userspace, you have all the tools, and the data
exported from the kernel to do so.
> I'm not opposed to "do it all in userspace" - really, I'm not. But
> the 'where' is only part of the problem. No userspace solution has
> yet been proposed that doesn't require a namespace change, and I'm
> still hoping to avoid that.
Just use a new script for people who want this, they will have to know
they want it anyway, right?
thanks,
greg k-h
^ permalink raw reply
* [Xenomai-core] [git pull v2] Refreshed & host-clock-enhanced queue for head
From: Jan Kiszka @ 2010-10-07 16:48 UTC (permalink / raw)
To: Philippe Gerum; +Cc: Xenomai core
The following changes since commit 0f0db62bc5ed90aaf85c87af876fbc319131a640:
Merge remote branch 'v2.5.x' (2010-10-04 10:27:03 +0200)
are available in the git repository at:
git://git.xenomai.org/xenomai-jki.git for-upstream
This extended version comes with three more fixes for head, otherwise
no changes:
- SMI PCI-ID fix (2.5.x already has a similar version)
- a minor cleanup for rtipc
- fixes for /proc/xenomai/rtdm/{named_devices,protocol_devices} output
Jan Kiszka (8):
rt_print: Properly return printed length
RTDM: Plug race between proc_read_dev_info and device deregistration
RTDM: Properly clean up on xnvfile setup errors
RTDM: Extend device name space in open_fildes proc output
nucleus: Fix lock imbalance in registry_proc_callback
Fix copy&paste mistake in SMI device ID for legacy kernels
rtipc: Fix types of internal thread variables
RTDM: Fix iterations for vfile device listings
Wolfgang Mauerer (7):
nucleus: Spelling fix for check-vdso.c
nucleus: Add userland cpu_relax() definition for x86
nucleus: Infrastructure for CLOCK_HOST_REALTIME
posix: Support reading the host realtime clock in realtime context
posix: Userspace hostrt reading without switching to kernel mode
Convert clocktest to Xenomai indentation style
Update clocktest for CLOCK_HOST_REALTIME
include/asm-generic/hal.h | 11 +
include/asm-generic/pci_ids.h | 4 +-
include/asm-generic/system.h | 3 +
include/asm-sim/system.h | 3 +
include/asm-x86/atomic.h | 5 +
include/nucleus/Makefile.am | 2 +
include/nucleus/hostrt.h | 54 ++++++
include/nucleus/seqlock_user.h | 57 ++++++
include/nucleus/vdso.h | 20 ++-
include/posix/time.h | 7 +
ksrc/drivers/ipc/bufp.c | 4 +-
ksrc/nucleus/Kconfig | 4 +
ksrc/nucleus/module.c | 64 ++++++-
ksrc/nucleus/registry.c | 3 +-
ksrc/skins/posix/clock.c | 86 +++++++++-
ksrc/skins/rtdm/proc.c | 75 +++++---
src/rtdk/rt_print.c | 1 +
src/skins/posix/clock.c | 92 ++++++++--
src/testsuite/clocktest/clocktest.c | 350 ++++++++++++++++++++---------------
src/testsuite/unit/check-vdso.c | 2 +-
20 files changed, 649 insertions(+), 198 deletions(-)
create mode 100644 include/nucleus/hostrt.h
create mode 100644 include/nucleus/seqlock_user.h
^ permalink raw reply
* Re: .* entries in official release source tarballs
From: Ian Jackson @ 2010-10-07 16:47 UTC (permalink / raw)
To: Jan Beulich; +Cc: xen-devel@lists.xensource.com
In-Reply-To: <4CA3069202000078000197F3@vpn.id2.novell.com>
Jan Beulich writes ("[Xen-devel] .* entries in official release source tarballs"):
> Since these are - afaict - meaningless outside of mercurial, would it be
> possible to drop them when creating the tarballs?
It would be possible but I don't think it's a good idea. The more
steps are involved in creating the official release tarballs, the more
likely it is that something will go wrong.
Are these files causing some kind of problem for you ?
Ian.
^ permalink raw reply
* Re: [PATCH] fix oops in ext4_mb_release_group_pa tracing
From: Eric Sandeen @ 2010-10-07 16:47 UTC (permalink / raw)
To: ext4 development; +Cc: Josef Bacik
In-Reply-To: <4C6D7116.2080905@redhat.com>
On 08/19/2010 12:59 PM, Eric Sandeen wrote:
> Our QA reported an oops in the ext4_mb_release_group_pa tracing,
> and Josef Bacik pointed out that it was because we may have a
> non-null but uninitialized ac_inode in the allocation context.
>
> I can reproduce it when running xfstests with ext4 tracepoints on,
> on a CONFIG_SLAB_DEBUG kernel.
>
> We call trace_ext4_mb_release_group_pa from 2 places,
> ext4_mb_discard_group_preallocations and
> ext4_mb_discard_lg_preallocations
>
> In both cases we allocate an ac as a container just for tracing (!)
> and never fill in the ac_inode. There's no reason to be assigning,
> testing, or printing it as far as I can see, so just remove it from
> the tracepoint.
>
> Signed-off-by: Eric Sandeen <sandeen@redhat.com>
ping on this one too, oopsing while tracing is bad ... ;)
-Eric
> ---
>
> diff --git a/include/trace/events/ext4.h b/include/trace/events/ext4.h
> index 01e9e00..e352c77 100644
> --- a/include/trace/events/ext4.h
> +++ b/include/trace/events/ext4.h
> @@ -432,7 +432,6 @@ TRACE_EVENT(ext4_mb_release_group_pa,
>
> TP_STRUCT__entry(
> __field( dev_t, dev )
> - __field( ino_t, ino )
> __field( __u64, pa_pstart )
> __field( __u32, pa_len )
>
> @@ -440,8 +439,6 @@ TRACE_EVENT(ext4_mb_release_group_pa,
>
> TP_fast_assign(
> __entry->dev = sb->s_dev;
> - __entry->ino = (ac && ac->ac_inode) ?
> - ac->ac_inode->i_ino : 0;
> __entry->pa_pstart = pa->pa_pstart;
> __entry->pa_len = pa->pa_len;
> ),
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.