* PCIe ASPM, PCI Bridges, e.g. PEX8311
From: Roman Fietze @ 2012-01-17 9:53 UTC (permalink / raw)
To: Kenji Kaneshige; +Cc: linux-pci
Hello Kenji, hello Linux PCI list members,
Using the current code it seems, that I cannot use ASPM on links
between any PCIe node and a PCI(e) bridge.
The current ASPM code in drivers/pci/pcie/aspm.c contains the
following statements inside pcie_aspm_cap_init(), as of the current
HEAD around line 402-410:
list_for_each_entry(child, &linkbus->devices, bus_list) {
if (child->pcie_type == PCI_EXP_TYPE_PCI_BRIDGE) {
link->aspm_disable = ASPM_STATE_ALL;
break;
}
}
I simply do not yet understand, why this is necessary. Is this
required by the PCI(e) specification (1), or would enabling ASPM cause
problems with the current code as it is right now (2)?
If (2), would it be a solution to check which kind of PCI- bridge the
device is, mainly checking if it is a PCIe-PCIe bridge or if it
connects only to one PCIe link?
Anything that could get me started, or stops me right here, would be
very helpful.
PCI layout of our board:
00:00.0 Host bridge: Intel Corporation System Controller Hub (SCH Poulsbo) (rev 07)
..
00:1c.1 PCI bridge: Intel Corporation System Controller Hub (SCH Poulsbo) PCI Express Port 2 (rev 07)
..
02:00.0 PCI bridge: PLX Technology, Inc. PEX 8509 8-lane, 8-port PCI Express Switch (rev aa)
03:01.0 PCI bridge: PLX Technology, Inc. PEX 8509 8-lane, 8-port PCI Express Switch (rev aa)
03:02.0 PCI bridge: PLX Technology, Inc. PEX 8509 8-lane, 8-port PCI Express Switch (rev aa)
..
.. (8 -ports, downstream on on 03:0[1-7].0, see below)
..
03:07.0 PCI bridge: PLX Technology, Inc. PEX 8509 8-lane, 8-port PCI Express Switch (rev aa)
04:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection
05:00.0 PCI bridge: PLX Technology, Inc. PEX 8111 PCI Express-to-PCI Bridge (rev 21)
06:04.0 Bridge: PLX Technology, Inc. Device 3456 (rev ba)
07:00.0 PCI bridge: PLX Technology, Inc. PEX 8111 PCI Express-to-PCI Bridge (rev 21)
08:04.0 Bridge: PLX Technology, Inc. Device 3455 (rev ba)
..
-[0000:00]-+-00.0
+-02.0
+-1a.0
+-1c.0-[01]----00.0
+-1c.1-[02-0c]----00.0-[03-0c]--+-01.0-[04]----00.0
| +-02.0-[05-06]--*--00.0-[06]----04.0
| +-03.0-[07-08]--*--00.0-[08]----04.0
| +-04.0-[09]----00.0
| +-05.0-[0a]--
| +-06.0-[0b]--
| \-07.0-[0c]--
+-1d.0
+-1d.1
+-1d.2
+-1d.7
+-1f.0
\-1f.1
The two devices 05:00.0 and 07:00.0 are members of a PEX8311, which
internally contains a PEX8111 PCIe-PCI-X bridge and a PCI-X-Localbus
bridge, the EP 04.0). They both are marked as PCI_EXP_TYPE_PCI_BRIDGE,
and therefore I cannot enable ASPM on the PCIe links on the buses 05
and 07 (marked with a * in the lspci -t output above).
Test scenario:
- enable ASPM by setting the appropriate bits in the 8509 and the 8111
PECS of 03:03.0, 03:04.0, 05:00.0 and 07:00.0
- enable ASPM in the kernel using /sys/module/pcie_aspm/parameters/policy
Roman
--
Roman Fietze Telemotive AG Buero Muehlhausen
Breitwiesen 73347 Muehlhausen
Tel.: +49(0)7335/18493-45 http://www.telemotive.de
^ permalink raw reply
* Re: Driver domains and hotplug scripts, redux
From: Roger Pau Monné @ 2012-01-17 10:00 UTC (permalink / raw)
To: Ian Campbell
Cc: xen-devel@lists.xensource.com, Ian Jackson, Stefano Stabellini
In-Reply-To: <1326793927.14689.80.camel@zakaz.uk.xensource.com>
2012/1/17 Ian Campbell <Ian.Campbell@citrix.com>:
> On Tue, 2012-01-17 at 09:40 +0000, Roger Pau Monné wrote:
>> 2012/1/17 Ian Campbell <Ian.Campbell@citrix.com>:
>> > However xend should not be transition to this new scheme but should
>> > continue to use its existing scripts in the current manner.
>> >
>> > There was a conversation last year[0] about how a toolstack could
>> > opt-in/out of the use of the hotplug scripts. We decided that toolstacks
>> > should have to opt into the use of these scripts, by touching a stamp
>> > file.
>> >
>> > Although this wasn't implemented yet (unless I missed it) I guess the
>> > same scheme would apply to this work if that sort of thing turns out to
>> > be necessary.
>>
>> Sorry for replying so many times, this is a big maybe, and possibly
>> it's too drastic, but after this changes xl and xend will not be
>> compatible anymore, so why don't we disable xend by default, and only
>> build xl?
>
> I don't think they are compatible now, are they? I've certainly seen odd
> behaviour when using xl with xend (accidentally) running, usually xend
> reaps the domain I've just started...
>
> I'm all for disabling the build of xend by default but I had assumed
> that others would think 4.2 was rather an aggressive timeline for that.
>
>> When the new configure script is in, it will be trivial to select if
>> you want xl or xend, and only install one of those. Adding the option
>> --enable-xend should disable xl and only build and install xend
>> (printing a very big warning that xend is deprecated).
>
> I don't think --enable-xend should ever disable xl (or vice versa). Many
> folks (e.g. distros) will want to build both, perhaps to package them in
> two different binary packages, but certainly to offer their users the
> choice, at least for the time being.
My main concern with this is that xend and xl will start to use
different udev rules (well, xend will continue to use the existing
ones, while xl will only use a subset of those). So we have to decide
which udev rules file to install, because we can't have both installed
at the same time.
Another option is to install xl udev rules by default, and make xend
move it's own rules in the init script. Since xl doesn't use a daemon,
xl should always check if xend is running before doing anything and
fail if xend is found.
>>
>> > Ian.
>> >
>> > [0] http://lists.xen.org/archives/html/xen-devel/2011-06/msg00952.html
>> >
>
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply
* [PATCH v2] NFC: Add NCI data exchange timer
From: ilanelias78 @ 2012-01-17 10:03 UTC (permalink / raw)
To: samuel, lauro.venancio, aloisio.almeida, linville
Cc: linux-wireless, Ilan Elias
From: Ilan Elias <ilane@ti.com>
Add NCI data exchange timer to catch timeouts,
and call the data exchange callback with an error.
Signed-off-by: Ilan Elias <ilane@ti.com>
---
v2: remove 2 unrelated changes (Thanks Samuel)
include/net/nfc/nci_core.h | 3 +++
net/nfc/nci/core.c | 24 ++++++++++++++++++++++++
net/nfc/nci/data.c | 4 ++++
3 files changed, 31 insertions(+), 0 deletions(-)
diff --git a/include/net/nfc/nci_core.h b/include/net/nfc/nci_core.h
index f4963ea..9154663 100644
--- a/include/net/nfc/nci_core.h
+++ b/include/net/nfc/nci_core.h
@@ -41,6 +41,7 @@ enum {
NCI_DISCOVERY,
NCI_POLL_ACTIVE,
NCI_DATA_EXCHANGE,
+ NCI_DATA_EXCHANGE_TO,
};
/* NCI timeouts */
@@ -49,6 +50,7 @@ enum {
#define NCI_RF_DISC_TIMEOUT 5000
#define NCI_RF_DEACTIVATE_TIMEOUT 30000
#define NCI_CMD_TIMEOUT 5000
+#define NCI_DATA_TIMEOUT 700
struct nci_dev;
@@ -74,6 +76,7 @@ struct nci_dev {
atomic_t credits_cnt;
struct timer_list cmd_timer;
+ struct timer_list data_timer;
struct workqueue_struct *cmd_wq;
struct work_struct cmd_work;
diff --git a/net/nfc/nci/core.c b/net/nfc/nci/core.c
index 7650139..815d28a 100644
--- a/net/nfc/nci/core.c
+++ b/net/nfc/nci/core.c
@@ -286,6 +286,7 @@ static int nci_close_device(struct nci_dev *ndev)
if (!test_and_clear_bit(NCI_UP, &ndev->flags)) {
del_timer_sync(&ndev->cmd_timer);
+ del_timer_sync(&ndev->data_timer);
mutex_unlock(&ndev->req_lock);
return 0;
}
@@ -331,6 +332,15 @@ static void nci_cmd_timer(unsigned long arg)
queue_work(ndev->cmd_wq, &ndev->cmd_work);
}
+/* NCI data exchange timer function */
+static void nci_data_timer(unsigned long arg)
+{
+ struct nci_dev *ndev = (void *) arg;
+
+ set_bit(NCI_DATA_EXCHANGE_TO, &ndev->flags);
+ queue_work(ndev->rx_wq, &ndev->rx_work);
+}
+
static int nci_dev_up(struct nfc_dev *nfc_dev)
{
struct nci_dev *ndev = nfc_get_drvdata(nfc_dev);
@@ -585,6 +595,8 @@ int nci_register_device(struct nci_dev *ndev)
setup_timer(&ndev->cmd_timer, nci_cmd_timer,
(unsigned long) ndev);
+ setup_timer(&ndev->data_timer, nci_data_timer,
+ (unsigned long) ndev);
mutex_init(&ndev->req_lock);
@@ -722,6 +734,9 @@ static void nci_tx_work(struct work_struct *work)
nci_plen(skb->data));
nci_send_frame(skb);
+
+ mod_timer(&ndev->data_timer,
+ jiffies + msecs_to_jiffies(NCI_DATA_TIMEOUT));
}
}
@@ -753,6 +768,15 @@ static void nci_rx_work(struct work_struct *work)
break;
}
}
+
+ /* check if a data exchange timout has occurred */
+ if (test_bit(NCI_DATA_EXCHANGE_TO, &ndev->flags)) {
+ /* complete the data exchange transaction, if exists */
+ if (test_bit(NCI_DATA_EXCHANGE, &ndev->flags))
+ nci_data_exchange_complete(ndev, NULL, -ETIMEDOUT);
+
+ clear_bit(NCI_DATA_EXCHANGE_TO, &ndev->flags);
+ }
}
/* ----- NCI TX CMD worker thread ----- */
diff --git a/net/nfc/nci/data.c b/net/nfc/nci/data.c
index e5756b3..7880ae9 100644
--- a/net/nfc/nci/data.c
+++ b/net/nfc/nci/data.c
@@ -44,6 +44,10 @@ void nci_data_exchange_complete(struct nci_dev *ndev,
pr_debug("len %d, err %d\n", skb ? skb->len : 0, err);
+ /* data exchange is complete, stop the data timer */
+ del_timer_sync(&ndev->data_timer);
+ clear_bit(NCI_DATA_EXCHANGE_TO, &ndev->flags);
+
if (cb) {
ndev->data_exchange_cb = NULL;
ndev->data_exchange_cb_context = 0;
--
1.7.0.4
^ permalink raw reply related
* DaVinci unbanked GPIO IRQs broken
From: Nori, Sekhar @ 2012-01-17 10:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <70E876B0EA86DD4BAF101844BC814DFE0BF403DA89@Cloud.RL.local>
Hi Jon,
On Mon, Jan 16, 2012 at 17:08:30, Jon Povey wrote:
> Sorry, last email had some lies, I had testing errors:
>
> Jon Povey wrote:
> > But I did try reverting the genirq change too, and
> > the interrupt handler still wasn't called
>
> This was incorrect, interrupt DOES work with genirq reverted on 3.2.
>
> > 3.2 vanilla: oops requesting irq
> > 3.2 + your patch: no oops, isr is not run
>
> These are still the case
>
> > 3.2 + reverted genirq: no oops, isr is not run
>
> This was incorrect, real result is: no oops, isr WORKS.
> (with or without your patch).
I was able to reproduce this on the EVM using v2.6.38 (works)
and v3.2 + my patch (doesn't work). I just started poking some
registers to see what is happening. Will keep you updated
on any progress.
Thanks,
Sekhar
^ permalink raw reply
* [RFC][PATCH 1/2] Btrfs: try to allocate new chunks with degenerated profile
From: Miao Xie @ 2012-01-17 10:02 UTC (permalink / raw)
To: Linux Btrfs
If there is no free space, the free space allocator will try to get space from
the block group with the degenerated profile. For example, if there is no free
space in the RAID1 block groups, the allocator will try to allocate space from
the DUP block groups. And besides that, the space reservation has the similar
behaviour: if there is no enough space in the space cache to reserve, it will
reserve the space according to the disk space, and it just take mirror storage
into account, no RAID0, RAID1, or RAID10.
So we'd better make the behaviour of chunk allocation correspond with space
reservation and free space allocation, if there is no enough disk space to
allocate RAID(RAID0, RAID1, RAID10) chunks, we degenerate the profile and try
to allocate chunks again. Otherwise, enospc will happen though we reserve
the space successfully and BUG_ON() will be triggered.
Degenerating rule:
RAID10 -> RAID1 -> DUP
RAID0 -> SINGLE
Signed-off-by: Miao Xie <miaox@cn.fujitsu.com>
---
fs/btrfs/extent-tree.c | 43 +++++++++++++++++++++++++++++++++++++++++--
1 files changed, 41 insertions(+), 2 deletions(-)
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index 3e68e2b..87cd611 100644
--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -3065,6 +3065,30 @@ u64 btrfs_reduce_alloc_profile(struct btrfs_root *root, u64 flags)
return flags;
}
+/*
+ * Degenerate the alloc profile:
+ * RAID10 -> RAID1 -> DUP
+ * RAID0 -> SINGLE
+ *
+ * This is used when there is no enough disk space to do chunk allocation.
+ * After degenerating the profile, we will try to allocate new chunks again.
+ */
+static u64 btrfs_degenerate_alloc_profile(u64 flags)
+{
+ if (flags & BTRFS_BLOCK_GROUP_RAID10) {
+ flags &= ~BTRFS_BLOCK_GROUP_RAID10;
+ flags |= BTRFS_BLOCK_GROUP_RAID1;
+ } else if (flags & BTRFS_BLOCK_GROUP_RAID1) {
+ flags &= ~BTRFS_BLOCK_GROUP_RAID1;
+ flags |= BTRFS_BLOCK_GROUP_DUP;
+ } else if (flags & BTRFS_BLOCK_GROUP_RAID0) {
+ flags &= ~BTRFS_BLOCK_GROUP_RAID0;
+ } else
+ flags = ULLONG_MAX;
+
+ return flags;
+}
+
static u64 get_alloc_profile(struct btrfs_root *root, u64 flags)
{
if (flags & BTRFS_BLOCK_GROUP_DATA)
@@ -3356,8 +3380,23 @@ again:
}
ret = btrfs_alloc_chunk(trans, extent_root, flags);
- if (ret < 0 && ret != -ENOSPC)
- goto out;
+ if (ret < 0) {
+ if (ret != -ENOSPC)
+ goto out;
+
+ /*
+ * Degenerate the alloc profile:
+ * RAID10 -> RAID1 -> DUP
+ * RAID0 -> SINGLE
+ * then we will try to allocate new chunks again. By this way,
+ * we can utilize the whole disk spacem and make the behaviour
+ * of the chunk allocation correspond with the space reservation
+ * and the free space allocation.
+ */
+ flags = btrfs_degenerate_alloc_profile(flags);
+ if (flags != ULLONG_MAX)
+ goto again;
+ }
spin_lock(&space_info->lock);
if (ret)
--
1.7.6.5
^ permalink raw reply related
* Re: [GIT PULL] tracing: make signal tracepoints more useful
From: Ingo Molnar @ 2012-01-17 10:02 UTC (permalink / raw)
To: Steven Rostedt
Cc: Oleg Nesterov, Linus Torvalds, Ingo Molnar, Masami Hiramatsu,
Seiji Aguchi, linux-kernel, Masami Hiramatsu
In-Reply-To: <1326729123.7642.146.camel@gandalf.stny.rr.com>
* Steven Rostedt <rostedt@goodmis.org> wrote:
> On Mon, 2012-01-16 at 13:53 +0100, Ingo Molnar wrote:
> > * Steven Rostedt <rostedt@goodmis.org> wrote:
>
> > Say if an app relies on the smaller data structure, it sure
> > might get surprised by the kernel writing a wider record ...
>
> Ingo,
>
> The kernel does this all the time. We have syscalls that may
> extend the data structure. [...]
That is not true *AT ALL* in such an unqualified manner. Steve,
stop being stupid.
The kernel syscall ABI may indeed sometimes expand *INPUT*
structures (if via some mechanism it's possible to make sure
that old ABI uses don't cause the kernel to read undefined
data), but the trace events are *OUTPUT* structures.
The kernel ABI never ever expands output structures, unless the
ABI itself is expanded in a safe way that makes it impossible
for old apps to trigger the new output logic, i.e. which makes
sure that all old apps work as well. We never ever write beyond
an already existing 40 byte ABI structure and corrupt the 41th
byte for an existing app!
In this case we simply don't know whether such an app exists. It
might be OK to do it, or it might be not so ok.
Thanks,
Ingo
^ permalink raw reply
* [RFC][PATCH 2/2] Btrfs: change the calculation of available space since the data profile can be degenerated
From: Miao Xie @ 2012-01-17 10:03 UTC (permalink / raw)
To: Linux Btrfs
Since the data profile can be degenerated(RAID10 -> RAID1 -> DUP, RAID0 ->
SINGLE), btrfs can utilize almost the whole disk space, we can simplify the
calculation of the available space in btrfs_statfs(). The new method just
ignore the disk space(one BTRFS_STRIPE_LEN at most) that can not be used to
allocate a DUP chunk, the other space will be considered as the available
space, and be count.
Signed-off-by: Miao Xie <miaox@cn.fujitsu.com>
---
fs/btrfs/super.c | 105 +++++++++++------------------------------------------
1 files changed, 22 insertions(+), 83 deletions(-)
diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c
index 34a8b61..0284620 100644
--- a/fs/btrfs/super.c
+++ b/fs/btrfs/super.c
@@ -1039,32 +1039,6 @@ static int btrfs_remount(struct super_block *sb, int *flags, char *data)
return 0;
}
-/* Used to sort the devices by max_avail(descending sort) */
-static int btrfs_cmp_device_free_bytes(const void *dev_info1,
- const void *dev_info2)
-{
- if (((struct btrfs_device_info *)dev_info1)->max_avail >
- ((struct btrfs_device_info *)dev_info2)->max_avail)
- return -1;
- else if (((struct btrfs_device_info *)dev_info1)->max_avail <
- ((struct btrfs_device_info *)dev_info2)->max_avail)
- return 1;
- else
- return 0;
-}
-
-/*
- * sort the devices by max_avail, in which max free extent size of each device
- * is stored.(Descending Sort)
- */
-static inline void btrfs_descending_sort_devices(
- struct btrfs_device_info *devices,
- size_t nr_devices)
-{
- sort(devices, nr_devices, sizeof(struct btrfs_device_info),
- btrfs_cmp_device_free_bytes, NULL);
-}
-
/*
* The helper to calc the free space on the devices that can be used to store
* file data.
@@ -1072,7 +1046,6 @@ static inline void btrfs_descending_sort_devices(
static int btrfs_calc_avail_data_space(struct btrfs_root *root, u64 *free_bytes)
{
struct btrfs_fs_info *fs_info = root->fs_info;
- struct btrfs_device_info *devices_info;
struct btrfs_fs_devices *fs_devices = fs_info->fs_devices;
struct btrfs_device *device;
u64 skip_space;
@@ -1080,31 +1053,12 @@ static int btrfs_calc_avail_data_space(struct btrfs_root *root, u64 *free_bytes)
u64 avail_space;
u64 used_space;
u64 min_stripe_size;
- int min_stripes = 1, num_stripes = 1;
- int i = 0, nr_devices;
int ret;
- nr_devices = fs_info->fs_devices->open_devices;
- BUG_ON(!nr_devices);
-
- devices_info = kmalloc(sizeof(*devices_info) * nr_devices,
- GFP_NOFS);
- if (!devices_info)
- return -ENOMEM;
+ *free_bytes = 0;
/* calc min stripe number for data space alloction */
type = btrfs_get_alloc_profile(root, 1);
- if (type & BTRFS_BLOCK_GROUP_RAID0) {
- min_stripes = 2;
- num_stripes = nr_devices;
- } else if (type & BTRFS_BLOCK_GROUP_RAID1) {
- min_stripes = 2;
- num_stripes = 2;
- } else if (type & BTRFS_BLOCK_GROUP_RAID10) {
- min_stripes = 4;
- num_stripes = 4;
- }
-
if (type & BTRFS_BLOCK_GROUP_DUP)
min_stripe_size = 2 * BTRFS_STRIPE_LEN;
else
@@ -1117,8 +1071,7 @@ static int btrfs_calc_avail_data_space(struct btrfs_root *root, u64 *free_bytes)
avail_space = device->total_bytes - device->bytes_used;
/* align with stripe_len */
- do_div(avail_space, BTRFS_STRIPE_LEN);
- avail_space *= BTRFS_STRIPE_LEN;
+ avail_space = round_down(avail_space, BTRFS_STRIPE_LEN);
/*
* In order to avoid overwritting the superblock on the drive,
@@ -1139,10 +1092,8 @@ static int btrfs_calc_avail_data_space(struct btrfs_root *root, u64 *free_bytes)
*/
ret = btrfs_account_dev_extents_size(device, 0, skip_space - 1,
&used_space);
- if (ret) {
- kfree(devices_info);
+ if (ret)
return ret;
- }
/* calc the free space in [0, skip_space - 1] */
skip_space -= used_space;
@@ -1156,40 +1107,28 @@ static int btrfs_calc_avail_data_space(struct btrfs_root *root, u64 *free_bytes)
else
avail_space = 0;
- if (avail_space < min_stripe_size)
- continue;
-
- devices_info[i].dev = device;
- devices_info[i].max_avail = avail_space;
-
- i++;
+ avail_space = round_down(avail_space, min_stripe_size);
+ *free_bytes += avail_space;
}
- nr_devices = i;
-
- btrfs_descending_sort_devices(devices_info, nr_devices);
-
- i = nr_devices - 1;
- avail_space = 0;
- while (nr_devices >= min_stripes) {
- if (num_stripes > nr_devices)
- num_stripes = nr_devices;
-
- if (devices_info[i].max_avail >= min_stripe_size) {
- int j;
- u64 alloc_size;
-
- avail_space += devices_info[i].max_avail * num_stripes;
- alloc_size = devices_info[i].max_avail;
- for (j = i + 1 - num_stripes; j <= i; j++)
- devices_info[j].max_avail -= alloc_size;
- }
- i--;
- nr_devices--;
- }
+ /*
+ * If there is no enough disk space for new RAID chunk allocation,
+ * the chunk allocator will degenerate the profile:
+ * RAID0 -> SINGLE
+ * RAID10 -> RAID1 -> DUP
+ *
+ * So if the profile is RAID0, the profile will be degenerated to
+ * SINGLE at last, and we can utilize the whole free disk space.
+ * Note: aligned with BTRFS_STRIPE_LEN, it is dealt with above, we
+ * needn't do anything here.
+ *
+ * If the profile is RAID1 or RAID10, the profile will be DUP at last.
+ * So the free size must be even times BTRFS_STRIPE_LEN.
+ */
+ if (type & (BTRFS_BLOCK_GROUP_RAID1 |
+ BTRFS_BLOCK_GROUP_RAID10))
+ *free_bytes = round_down(*free_bytes, 2 * BTRFS_STRIPE_LEN);
- kfree(devices_info);
- *free_bytes = avail_space;
return 0;
}
--
1.7.6.5
^ permalink raw reply related
* Re: Xen 4.2 TODO List Update
From: Roger Pau Monné @ 2012-01-17 10:04 UTC (permalink / raw)
To: Ian Campbell
Cc: Olaf Hering, xen-devel, Keir Fraser, George Dunlap, Ian Jackson,
Tim Deegan, Stefano Stabellini, Andres Lagar-Cavilla, Jan Beulich,
Anthony Perard
In-Reply-To: <1326794401.14689.84.camel@zakaz.uk.xensource.com>
2012/1/17 Ian Campbell <Ian.Campbell@citrix.com>:
> An updated version of the list is below. Some items are marked "nice to
> have" meaning that we don't think they should block the release. I'll
> try and post an update on a semi-regular basis as and when things are
> completed.
>
> I think I have incorporated all the updates made in the last thread as
> well as correctly reflected the status of each item. Please let me know
> if something is out of date e.g. if progress has been made which I
> haven't reflected below.
>
> hypervisor, blockers:
>
> * round-up of the closing of the security hole in MSI-X
> passthrough (uniformly - i.e. even for Dom0 - disallowing write
> access to MSI-X table pages). (Jan Beulich, after upstream qemu
> patch series also incorporates the respective recent qemu-xen
> change)
> * domctls / sysctls set up to modify scheduler parameters, like
> the credit1 timeslice (and schedule rate, if that ever makes it
> in). (George Dunlap)
> * get the interface changes for sharing/paging/mem-events done and
> dusted so that 4.2 is a stable API that we hold to. (Tim Deegan,
> Andres Lagar-Cavilla et al)
> * mem event ring management posted, seems close to going
> in.
> * sharing patches posted
> *
>
> tools, blockers:
>
> * libxl stable API -- we would like 4.2 to define a stable API
> which downstream's can start to rely on not changing. Aspects of
> this are:
> * event handling (Ian Jackson, posted several rounds,
> nearing completion?)
> * drop libxl_device_model_info (move bits to build_info or
> elsewhere as appropriate) (Ian Campbell, first RFC sent)
> * add libxl_defbool and generally try and arrange that
> memset(foo,0,...) requests the defaults (Ian Campbell,
> first RFC sent)
> * The topologyinfo datastructure should be a list of
> tuples, not a tuple of lists. (nobody currently looking
> at this, not 100% sure this makes sense, could possibly
> defer and change after 4.2 in a compatible way)
> * Block script support -- can be done post 4.2? should be
> nice to have not blocker? Somewhere on IanJ's todo?
This is quite related to xl hotplug stuff, once the hotplug thing is
in, it should be trivial to add this.
> * xl to use json for machine readable output instead of sexp by
> default (Ian Campbell to revisit existing patch)
> * xl feature parity with xend wrt driver domain support (George
> Dunlap)
> * Integrate qemu+seabios upstream into the build (Stefano to
> repost). No change in default qemu for 4.2.
> * More formally deprecate xm/xend. Manpage patches already in
> tree. Needs release noting and communication around -rc1 to
> remind people to test xl.
>
> hypervisor, nice to have:
>
> * solid implementation of sharing/paging/mem-events (using work
> queues) (Tim Deegan, Olaf Herring et al)
> * A long standing issue is a fully synchronized p2m (locking
> lookups) (Andres Lagar-Cavilla)
>
> tools, nice to have:
>
> * Hotplug script stuff -- internal to libxl (I think, therefore I
> didn't put this under stable API above) but still good to have
> for 4.2? Roger Pau Monet was looking at this but its looking
> like a big can-o-worms. (discussion on-going)
> * Upstream qemu feature patches:
> * Upstream qemu PCI passthrough support (Anthony Perard)
> * Upstream qemu save restore (Anthony Perard)
> * Nested-virtualisation (currently should be marked experimental,
> likely to release that way? Consider nested-svm separate to
> nested-vmx. Nested-svm is in better shape)
>
>
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply
* Re: [xen-unstable bisection] complete test-i386-i386-xl
From: Paul Durrant @ 2012-01-17 10:04 UTC (permalink / raw)
To: Ian Jackson
Cc: xen-devel@lists.xensource.com, Keir (Xen.org), Ian Campbell,
Stefano Stabellini
In-Reply-To: <20244.13470.956567.815603@mariner.uk.xensource.com>
So far I've been unable to repro. with a build of staging tip from yesterday (running a 512MB PV debian guest with a 3.2.0-rc2+ kernel). I'll revert to the appropriate c/s and see if I can repro. with that. The errors unfortunately don't give much away other than the receiving process clearly didn't like something about the migration data stream.
libxl: error: libxl_utils.c:409:libxl_read_exactly: file/stream truncated reading ready message from migration receiver stream
libxl: info: libxl_exec.c:124:libxl_report_child_exitstatus: migration target process [14446] exited with error status 255
Paul
> -----Original Message-----
> From: Ian Jackson [mailto:Ian.Jackson@eu.citrix.com]
> Sent: 16 January 2012 14:31
> To: Paul Durrant
> Cc: Ian Campbell; xen-devel@lists.xensource.com; Keir (Xen.org); Stefano
> Stabellini
> Subject: RE: [Xen-devel] [xen-unstable bisection] complete test-i386-i386-xl
>
> Paul Durrant writes ("RE: [Xen-devel] [xen-unstable bisection] complete
> test-i386-i386-xl"):
> > > -----Original Message-----
> > > From: Ian Jackson [mailto:Ian.Jackson@eu.citrix.com]
> ...
> > > So as you were the author of the original patch, can you please try
> > > to reproduce the problem and fix it ?
> > >
> >
> > Already on it.
>
> Great, thanks. If you need any help, or to borrow the machine from my test
> pool, or something, just let me know.
>
> Ian.
^ permalink raw reply
* Re: [PATCH 1/2] drm/i915: simplify pipe checking
From: Daniel Vetter @ 2012-01-17 10:05 UTC (permalink / raw)
To: Cyril Brulebois; +Cc: intel-gfx, Eugeni Dodonov
In-Reply-To: <20120116202825.GH3627@phenom.ffwll.local>
On Mon, Jan 16, 2012 at 21:28, Daniel Vetter <daniel@ffwll.ch> wrote:
> On Sun, Jan 08, 2012 at 03:01:12AM +0100, Cyril Brulebois wrote:
>> Eugeni Dodonov <eugeni.dodonov@intel.com> (07/01/2012):
>> > This is also handled by i915_reg.h, so just reuse this trick to reduce
>> > universe enthropy.
>>
>> entropy.
>>
>> Besides that:
>>
>> Reviewed-by: Cyril Brulebois <kibi@debian.org>
>
> Both patches queued for -next, thanks.
I've botched my cross-checking with Keith's -fixes, these two are
already there. Dropped them from my queue.
-Daniel
--
Daniel Vetter
daniel.vetter@ffwll.ch - +41 (0) 79 364 57 48 - http://blog.ffwll.ch
^ permalink raw reply
* Re: [RFC 2/3] vmscan hook
From: KAMEZAWA Hiroyuki @ 2012-01-17 10:05 UTC (permalink / raw)
To: Minchan Kim
Cc: linux-mm, LKML, leonid.moiseichuk, penberg, Rik van Riel, mel,
rientjes, KOSAKI Motohiro, Johannes Weiner, Marcelo Tosatti,
Andrew Morton, Ronen Hod
In-Reply-To: <20120117091356.GA29736@barrios-desktop.redhat.com>
On Tue, 17 Jan 2012 18:13:56 +0900
Minchan Kim <minchan@kernel.org> wrote:
> On Tue, Jan 17, 2012 at 05:39:32PM +0900, KAMEZAWA Hiroyuki wrote:
> > On Tue, 17 Jan 2012 17:13:57 +0900
> > Minchan Kim <minchan@kernel.org> wrote:
> >
> >
> > > + /*
> > > + * We want to avoid dropping page cache excessively
> > > + * in no swap system
> > > + */
> > > + if (nr_swap_pages <= 0) {
> > > + free = zone_page_state(mz->zone, NR_FREE_PAGES);
> > > + file = zone_page_state(mz->zone, NR_ACTIVE_FILE) +
> > > + zone_page_state(mz->zone, NR_INACTIVE_FILE);
> > > + /*
> > > + * If we have very few page cache pages,
> > > + * notify to user
> > > + */
> > > + if (file < free)
> > > + low_mem = true;
> > > + }
> >
> > I can't understand why you think you can check lowmem condition by "file < free".
>
> The reason I thought so is I want to maintain some page cache to some degree.
> But I admit It's very naive heuristic and should be improved.
>
> > And I don't think using per-zone data is good.
> > (I'm not sure how many zones embeded guys using..)
>
> Agree. In case of swapless system, we need another heuristic.
>
> >
> > Another idea:
> > 1. can't we use some technique like cleancache to detect the condition ?
>
> I totally forgot cleancache approach. Could you remind that?
>
Similar to 'victim cache'. Then, cache some clean pages somewhere when
vmscan pageout it.
page -> vmscan's pageout -> cleancache -> may be discarded.
If a filesystem look up a page which is in a cleancache, cache-hit and
bring it back to radix-tree. If not, read from disk again.
And cleancache for swap(frontswap) was posted, too.
> > 2. can't we measure page-in/page-out distance by recording something ?
>
> I can't understand your point. What's relation does it with swapout prevent?
>
If distance between pageout -> pagein is short, it means thrashing.
For example, recoding the timestamp when the page(mapping, index) was
paged-out, and check it at page-in.
> > 3. NR_ANON + NR_FILE_MAPPED can't mean the amount of core memory if we can
> > ignore the data file cache ?
>
> It's good but how do we define some amount?
> It's very vague but I guess we can get a good idea from that.
> Perhaps, you already has it.
>
Hm, a rough idea is...
- we now have rss counter per mm.
- mapped anon
- mapped file
- swapents
Ok, here, add one more counter.
- paged-out file. (I think this can be recorded in pte.)
+1 when try_to_unmap_file() unmaps it.
-1 when a page is back or unmapped.
Then, scanning all tasks. Then,
mapped_anon + mapped_file
active_map_ratio = ----------------------------------------------------- * 100
mapped_anon + mapped_file + swapents + paged_out_file
Ok, how to use this value...
Like memcg's threshold notify interface, you can change the mem_notify interface
to use eventfd() as
<event_fd, fd of /dev/mem_notify, threshold of active_map_ratio>
This will inform you an event when active_map_ratio crosses passed threshold.
complicated ?
> > 4. how about checking kswapd's busy status ?
>
> Could you elaborate on your idea?
>
I just thought kswapd may not stop when the situation is very bad.
Thanks,
-Kame
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [RFC 2/3] vmscan hook
From: KAMEZAWA Hiroyuki @ 2012-01-17 10:05 UTC (permalink / raw)
To: Minchan Kim
Cc: linux-mm, LKML, leonid.moiseichuk, penberg, Rik van Riel, mel,
rientjes, KOSAKI Motohiro, Johannes Weiner, Marcelo Tosatti,
Andrew Morton, Ronen Hod
In-Reply-To: <20120117091356.GA29736@barrios-desktop.redhat.com>
On Tue, 17 Jan 2012 18:13:56 +0900
Minchan Kim <minchan@kernel.org> wrote:
> On Tue, Jan 17, 2012 at 05:39:32PM +0900, KAMEZAWA Hiroyuki wrote:
> > On Tue, 17 Jan 2012 17:13:57 +0900
> > Minchan Kim <minchan@kernel.org> wrote:
> >
> >
> > > + /*
> > > + * We want to avoid dropping page cache excessively
> > > + * in no swap system
> > > + */
> > > + if (nr_swap_pages <= 0) {
> > > + free = zone_page_state(mz->zone, NR_FREE_PAGES);
> > > + file = zone_page_state(mz->zone, NR_ACTIVE_FILE) +
> > > + zone_page_state(mz->zone, NR_INACTIVE_FILE);
> > > + /*
> > > + * If we have very few page cache pages,
> > > + * notify to user
> > > + */
> > > + if (file < free)
> > > + low_mem = true;
> > > + }
> >
> > I can't understand why you think you can check lowmem condition by "file < free".
>
> The reason I thought so is I want to maintain some page cache to some degree.
> But I admit It's very naive heuristic and should be improved.
>
> > And I don't think using per-zone data is good.
> > (I'm not sure how many zones embeded guys using..)
>
> Agree. In case of swapless system, we need another heuristic.
>
> >
> > Another idea:
> > 1. can't we use some technique like cleancache to detect the condition ?
>
> I totally forgot cleancache approach. Could you remind that?
>
Similar to 'victim cache'. Then, cache some clean pages somewhere when
vmscan pageout it.
page -> vmscan's pageout -> cleancache -> may be discarded.
If a filesystem look up a page which is in a cleancache, cache-hit and
bring it back to radix-tree. If not, read from disk again.
And cleancache for swap(frontswap) was posted, too.
> > 2. can't we measure page-in/page-out distance by recording something ?
>
> I can't understand your point. What's relation does it with swapout prevent?
>
If distance between pageout -> pagein is short, it means thrashing.
For example, recoding the timestamp when the page(mapping, index) was
paged-out, and check it at page-in.
> > 3. NR_ANON + NR_FILE_MAPPED can't mean the amount of core memory if we can
> > ignore the data file cache ?
>
> It's good but how do we define some amount?
> It's very vague but I guess we can get a good idea from that.
> Perhaps, you already has it.
>
Hm, a rough idea is...
- we now have rss counter per mm.
- mapped anon
- mapped file
- swapents
Ok, here, add one more counter.
- paged-out file. (I think this can be recorded in pte.)
+1 when try_to_unmap_file() unmaps it.
-1 when a page is back or unmapped.
Then, scanning all tasks. Then,
mapped_anon + mapped_file
active_map_ratio = ----------------------------------------------------- * 100
mapped_anon + mapped_file + swapents + paged_out_file
Ok, how to use this value...
Like memcg's threshold notify interface, you can change the mem_notify interface
to use eventfd() as
<event_fd, fd of /dev/mem_notify, threshold of active_map_ratio>
This will inform you an event when active_map_ratio crosses passed threshold.
complicated ?
> > 4. how about checking kswapd's busy status ?
>
> Could you elaborate on your idea?
>
I just thought kswapd may not stop when the situation is very bad.
Thanks,
-Kame
^ permalink raw reply
* RE: [PATCH v2] NFC: Download TI NFC init script
From: Elias, Ilan @ 2012-01-17 10:06 UTC (permalink / raw)
To: Samuel Ortiz
Cc: lauro.venancio@openbossa.org, aloisio.almeida@openbossa.org,
linville@tuxdriver.com, linux-wireless@vger.kernel.org
In-Reply-To: <1326747643.22824.23.camel@sortiz-mobl>
Hi Samuel,
> > @@ -208,11 +489,13 @@ static int nfcwilink_send(struct sk_buff *skb)
> >
> > nfc_dev_dbg(&drv->pdev->dev, "send entry, len %d", skb->len);
> >
> > - if (!test_bit(NFCWILINK_RUNNING, &drv->flags))
> > - return -EBUSY;
> > + if (!test_bit(NFCWILINK_RUNNING, &drv->flags)) {
> > + kfree_skb(skb);
> > + return -EINVAL;
> > + }
> This is not related to this patch.
>
>
> > /* add the ST hdr to the start of the buffer */
> > - hdr.len = skb->len;
> > + hdr.len = cpu_to_le16(skb->len);
> Same here.
>
>
> > memcpy(skb_push(skb, NFCWILINK_HDR_LEN), &hdr,
> NFCWILINK_HDR_LEN);
> >
> > /* Insert skb to shared transport layer's transmit queue.
> > @@ -239,7 +522,7 @@ static int nfcwilink_probe(struct
> platform_device *pdev)
> > {
> > static struct nfcwilink *drv;
> > int rc;
> > - u32 protocols;
> > + __u32 protocols;
> Ditto.
You're correct, I will split the patch.
> Cheers,
> Samuel.
Thanks & BR,
Ilan
^ permalink raw reply
* Re: fdisk: off-by-one issue in (n)new command
From: Karel Zak @ 2012-01-17 10:07 UTC (permalink / raw)
To: Gerardo Exequiel Pozzi; +Cc: util-linux
In-Reply-To: <4F14A512.2030904@yahoo.com.ar>
On Mon, Jan 16, 2012 at 07:30:42PM -0300, Gerardo Exequiel Pozzi wrote:
> Last sector, +sectors or +size{K,M,G} (2048-524287, default 524287): +255M
> Value out of range.
The size of the device is 268435456 bytes,
+255M is relative to the begin of the partition, it means
(2048 * 512) + (255 * 1024 * 1024) = 268435456 bytes
but the begin of the last sector (in bytes) is
268435456 - 512 = 268434944 bytes (LBA sector 524287)
Right?
Karel
--
Karel Zak <kzak@redhat.com>
http://karelzak.blogspot.com
^ permalink raw reply
* KVM call agenda for Tuesday 17
From: Juan Quintela @ 2012-01-17 10:08 UTC (permalink / raw)
To: KVM devel mailing list, Developers qemu-devel
Hi
Please send in any agenda items you are interested in covering.
Later, Juan.
^ permalink raw reply
* [Qemu-devel] KVM call agenda for Tuesday 17
From: Juan Quintela @ 2012-01-17 10:08 UTC (permalink / raw)
To: KVM devel mailing list, Developers qemu-devel
Hi
Please send in any agenda items you are interested in covering.
Later, Juan.
^ permalink raw reply
* Re: Xen 4.2 TODO List Update
From: Olaf Hering @ 2012-01-17 10:08 UTC (permalink / raw)
To: Ian Campbell
Cc: xen-devel, Keir Fraser, George Dunlap, Ian Jackson, Tim Deegan,
Roger Pau Monne, Stefano Stabellini, Andres Lagar-Cavilla,
Jan Beulich, Anthony Perard
In-Reply-To: <1326794401.14689.84.camel@zakaz.uk.xensource.com>
On Tue, Jan 17, Ian Campbell wrote:
> I think I have incorporated all the updates made in the last thread as
> well as correctly reflected the status of each item. Please let me know
> if something is out of date e.g. if progress has been made which I
> haven't reflected below.
Now that paging is reasonable mature, it should be possible to configure
and tune it via libxl/xl in some way. There is some discussion going on
about how it could be done. I will follow up and prepare a patch.
Olaf
^ permalink raw reply
* Re: [PATCH] drm/i915: Check that plane/pipe is disabled before removing the fb
From: Daniel Vetter @ 2012-01-17 10:09 UTC (permalink / raw)
To: Chris Wilson; +Cc: intel-gfx
In-Reply-To: <1326754873-2021-1-git-send-email-chris@chris-wilson.co.uk>
On Mon, Jan 16, 2012 at 11:01:13PM +0000, Chris Wilson wrote:
> Staring at an error state such as:
>
> PGTBL_ER: 0x00000400
> Display B: Invalid tiling
> fence[0] = 05001001
> valid, x-tiled, pitch: 512, start: 0x05000000, size: 1048576
> Pinned [2]:
> 00000000 131072 0001 0001 00000000 P uncached
> 00020000 4096000 0041 0000 00000000 P uncached (name: 1)
> Plane [1]:
> CNTR: c0000000 # enabled | gamma
> STRIDE: 00001400
> SIZE: 03ff04ff
> POS: 00000000
> ADDR: 05000000
>
> Suggests that we did not clear the DSPBCNTR prior to unpinning the
> framebuffer and reusing the GTT space. Impossible! Unless our DPMS
> bookkeeping ran afoul again...
>
> In the meantime add an assertion that the plane is decoupled from the
> framebuffer prior to release.
>
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>
> Cc: Daniel Vetter <daniel@ffwll.ch>
Queued for -next, thanks for the patch.
-Daniel
--
Daniel Vetter
Mail: daniel@ffwll.ch
Mobile: +41 (0)79 365 57 48
^ permalink raw reply
* Available PCIe lanes for VGA passthrough
From: Sandi Romih @ 2012-01-17 10:10 UTC (permalink / raw)
To: xen-devel
[-- Attachment #1.1: Type: text/plain, Size: 1328 bytes --]
Hello,
I hope that I am posting the correct list with this question.
I have been trying to get VGA passthrough working on my system for some
time now without success.
I do not have the system with me right now, so I will not be able to
provide any logs or error messages right now. I will be able to to do so in
a couple of hours.
I have a VT-d enabled system (Motherboard and CPU) on which I wish to pass
the secondary graphics card (EVGA GTX480 SE) through to the HVM (WinXP
32-bit).
Currently I am testing with Debian Squeeze, using the 3.1.8 kernel and Xen
4.2.unstable according to these instructions:
http://www.davidgis.fr/blog/index.php?2011/12/07/860-xen-42unstable-patches-for-vga-pass-through
I can only boot the WinXP client via the VNC console (gfx_passthrough=0),
and from within WinXP I see that the OS has detected the GTX480 card (as
its secondary card), but I am not able to use it. I have tried the 275.33
drives, and they make no difference.
My question is related to the number of PCIe lanes I have available to the
graphics card.
I only have 8 lanes available for the GTX480 (which is a PCIe x16 card),
could this pose an issue for Xen?
I plan to test VGA passthrough with an ATI graphics card (also in a PCIe x8
slot) later to see if it will work or not. I will update what I find.
Regards
Sandi
[-- Attachment #1.2: Type: text/html, Size: 2312 bytes --]
[-- Attachment #2: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply
* [PATCH 8/8] dmaengine/dw_dmac: Add support for DMA_SLAVE_CONFIG
From: Jassi Brar @ 2012-01-17 10:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4F140D25.1000309@st.com>
On 16 January 2012 17:12, Viresh Kumar <viresh.kumar@st.com> wrote:
> On 1/16/2012 3:20 PM, Viresh KUMAR wrote:
>> + ? ? /*
>> + ? ? ?* Fix sconfig's burst size according to dw_dmac. We need to convert
>> + ? ? ?* them as: 1 -> 0, 2 -> 1, 4 -> 2, 8 -> 3, 16 -> 4.
>> + ? ? ?*
>> + ? ? ?* This can be done by findiding least significant bit set: n & (n - 1)
>> + ? ? ?*/
>> + ? ? sconfig->src_maxburst &= sconfig->src_maxburst - 1;
>> + ? ? sconfig->dst_maxburst &= sconfig->dst_maxburst - 1;
>
> Perhaps, this looks incorrect. It will always return 0. :(
> Can somebody suggest any inbuild function to do this, i think
>
Calculating log2(n) which isn't very tidy. For that reason usually we make do
the other way around by saving values as power of 2 and simply left shifting
1 by that value.
In case at hand since most likely only valid values are power of 2,
maybe you can do
maxburst = ffs(maxburst) - 1
-j
^ permalink raw reply
* Re: [PATCH 8/8] dmaengine/dw_dmac: Add support for DMA_SLAVE_CONFIG
From: Jassi Brar @ 2012-01-17 10:10 UTC (permalink / raw)
To: Viresh Kumar
Cc: vinod.koul@intel.com, Pratyush ANAND, Rajeev KUMAR,
linux@arm.linux.org.uk, Bhupesh SHARMA, Armando VISCONTI,
linus.walleij@linaro.org, Mirko GARDI,
linux-kernel@vger.kernel.org, Vipin KUMAR, Shiraz HASHIM,
Amit VIRDI, Vipul Kumar SAMAR, viresh.linux@gmail.com,
Deepak SIKRI, Bhavna YADAV, dan.j.williams@intel.com,
linux-arm-kernel@lists.infradead.org, Vincenzo FRASCINO
In-Reply-To: <4F140D25.1000309@st.com>
On 16 January 2012 17:12, Viresh Kumar <viresh.kumar@st.com> wrote:
> On 1/16/2012 3:20 PM, Viresh KUMAR wrote:
>> + /*
>> + * Fix sconfig's burst size according to dw_dmac. We need to convert
>> + * them as: 1 -> 0, 2 -> 1, 4 -> 2, 8 -> 3, 16 -> 4.
>> + *
>> + * This can be done by findiding least significant bit set: n & (n - 1)
>> + */
>> + sconfig->src_maxburst &= sconfig->src_maxburst - 1;
>> + sconfig->dst_maxburst &= sconfig->dst_maxburst - 1;
>
> Perhaps, this looks incorrect. It will always return 0. :(
> Can somebody suggest any inbuild function to do this, i think
>
Calculating log2(n) which isn't very tidy. For that reason usually we make do
the other way around by saving values as power of 2 and simply left shifting
1 by that value.
In case at hand since most likely only valid values are power of 2,
maybe you can do
maxburst = ffs(maxburst) - 1
-j
^ permalink raw reply
* [PATCH 1/2] ARM: vmlinux.lds.S: do not hardcode cacheline size as 32 bytes
From: Will Deacon @ 2012-01-17 10:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.02.1201161425040.2722@xanadu.home>
On Mon, Jan 16, 2012 at 07:35:43PM +0000, Nicolas Pitre wrote:
> On Mon, 16 Jan 2012, Will Deacon wrote:
> > On Mon, Jan 16, 2012 at 06:30:23PM +0000, Stephen Boyd wrote:
> > > I haven't measured anything yet. I just see that it's another value
> > > hard-coded to 32 in the linker script and that tile has decided to use
> > > L1_CACHE_BYTES for it.
> >
> > Hmm, that's intriguing. The exception table entries are 8 bytes on ARM and
> > are aligned as such by things like the USER macro, so I'm not sure why we
> > align the section to 32 bytes. I guess it must be for performance reasons,
> > but whether that's due to cacheline size, I don't know.
> >
> > Nico, can you enlighten us please (it was introduced in 13b1f64c ("[ARM]
> > 3008/1: the exception table is not read-only"))?
>
> It probably was due to the fact that the surrounding data was also cache
> line aligned. I don't think there is any particular reason why it
> should be aligned to a cache line boundary given that the list is
> accessed with a binary search. The minimum required alignment would be
> __alignof__(struct exception_table_entry).
Given that the struct just contains two unsigned longs, we should be alright
with 4 byte alignment here. I can add a follow-on patch to change that.
Thanks,
Will
^ permalink raw reply
* Re: [patch v2, kernel version 3.2.1] net/ipv4/ip_gre: Ethernet multipoint GRE over IP
From: David Lamparter @ 2012-01-17 10:11 UTC (permalink / raw)
To: Štefan Gula
Cc: David Lamparter, Alexey Kuznetsov, David S. Miller, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy, netdev, linux-kernel
In-Reply-To: <CAGsizz+irKwP5VVmL3_0et+c9YwrHYZ6843dowZmMzA0osXNYg@mail.gmail.com>
On Tue, Jan 17, 2012 at 10:56:51AM +0100, Štefan Gula wrote:
> Dňa 17. januára 2012 10:50, David Lamparter <equinox@diac24.net> napísal/a:
> > On Mon, Jan 16, 2012 at 11:52:25PM +0100, Štefan Gula wrote:
> >> Dňa 16. januára 2012 21:29, David Lamparter <equinox@diac24.net> napísal/a:
> >> > At the risk of repeating myself, Linux GRE support already has
> >> > provisions for multipoint tunnels. And unlike your code, those reuse the
> >> > existing neighbor table infrastructure, including all of its user
> >> > interface and introspection capabilities.
> >> >
> >> > It's actually slightly visible in your patch:
> >> >
> >> > On Mon, Jan 16, 2012 at 08:45:14PM +0100, Štefan Gula wrote:
> >> >> +++ linux-3.2.1-my/net/ipv4/ip_gre.c 2012-01-16 20:42:03.000000000 +0100
> >> >> @@ -716,7 +942,19 @@ static netdev_tx_t ipgre_tunnel_xmit(str
> >> > [...]
> >> >> /* NBMA tunnel */
> >> >>
> >> >> if (skb_dst(skb) == NULL) {
> >> >
> >> >
> >> > -David
> >>
> >> That code you are referring to is used only for routed traffic inside
> >> GRE - L3 traffic over L3 routed infrastructure. My patch is dealing
> >> with L2 traffic over L3 routed infrastructure - so the decision here
> >> is based on destination MAC addresses and not based on IPv4/IPv6
> >> addresses.
> >
> > Yes, it currently only does IPv4/IPv6 -> IPv4 through the neighbor
> > table. That doesn't mean it can't be extended to handle ethernet
> > addresses the same way.
>
> Routing mechanisms and switching mechanisms works completely
> different, in switching you simply don't have anything like next-hop
> from routing, which can be resolved by utilizing modified ARP message
> and there is also absolutely no hierarchy in MAC address (like you
> have in routing table), so I seriously doubt that it can be done the
> same way, but I am opened to ideas here. So how would you do like to
> do that?
NBMA GRE does not use routing mechanisms, it uses the neighbor table.
The neighbor table does not use any hierarchy in its lookups.
So you have the existing neighbor table use cases:
- IPv4 -> MAC with in-kernel ARP
- IPv6 -> MAC with in-kernel ND
- IPv4 -> IPv4 on NBMA GRE devices (without in-kernel filling)
- IPv6 -> IPv4 on NBMA GRE devices (without in-kernel filling)
You could add to that:
- MAC -> IPv4 on NBMA GRETAP devices
-David
^ permalink raw reply
* [U-Boot] [PATCH 1/2] fsl_pmic.h: add regulator mode 0 and 1 bits
From: Stefano Babic @ 2012-01-17 10:12 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1326712216-11197-2-git-send-email-helmut.raiger@hale.at>
On 16/01/2012 12:10, Helmut Raiger wrote:
> Add bit definitions for register 32 and 33 of Freescale PMIC.
>
> Signed-off-by: Helmut Raiger <helmut.raiger@hale.at>
> ---
> include/fsl_pmic.h | 52 ++++++++++++++++++++++++++++++++++++++++++++++++++++
> 1 files changed, 52 insertions(+), 0 deletions(-)
>
Hi Helmut,
> diff --git a/include/fsl_pmic.h b/include/fsl_pmic.h
> index 742f2e1..17e7b82 100644
> --- a/include/fsl_pmic.h
> +++ b/include/fsl_pmic.h
> @@ -102,6 +102,58 @@ enum {
> PMIC_NUM_OF_REGS,
> };
>
> +/* REG_MODE_0 */
> +#define VAUDIOEN (1 << 0)
> +#define VAUDIOSTBY (1 << 1)
No, this is not correct. I explain it better. Freescale's PMIC that we
currently support have the same register names, but their layout
differs. What you are defining here is valid for the MC13783, but
conflicts with the mc13892.
See the comments inside fsl_pmic.h:
/*
* The registers of different PMIC has the same meaning
* but the bit positions of the fields can differ or
* some fields has a meaning only on some devices.
* You have to check with the internal SPI bitmap
* (see Freescale Documentation) to set the registers
* for the device you are using
*/
I checked the REG_0 registers in both PMIC and they differ. The way to
do is to have a pmic specific header file with the bit definitions. We
have already include/mc13892.h, and you can add include/mc13783.h with
the constants you need.
Best regards,
Stefano Babic
--
=====================================================================
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de
=====================================================================
^ permalink raw reply
* [GIT PULL] sound fix for 3.3-rc1
From: Takashi Iwai @ 2012-01-17 10:12 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel
Linus,
please pull sound fixes for v3.3-rc1 from:
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git for-linus
The topmost commit is f0e48b6bd4e407459715240cd241ddb6b89bdf81
All small fixes below after the first merge.
Thanks!
Takashi
===
Clemens Ladisch (1):
ALSA: virtuoso: Xonar DS: fix polarity of front output
David Henningsson (2):
ALSA: HDA: Use LPIB position fix for Macbook Pro 7,1
ALSA: HDA: Fix internal microphone on Dell Studio 16 XPS 1645
Raymond Yau (2):
ALSA: Au88x0 - Support 4 channels playback when AC97 codecs has SDAC bit
ALSA: Au88x0 - Reduce the number of playback subdevices of au8830 from 32 to 16
Takashi Iwai (1):
ALSA: Don't prompt for CONFIG_SND_COMPRESS_OFFLOAD
---
sound/core/Kconfig | 13 +++----------
sound/pci/au88x0/au88x0.c | 13 +++++++------
sound/pci/au88x0/au88x0.h | 1 +
sound/pci/au88x0/au88x0_pcm.c | 1 +
sound/pci/hda/hda_intel.c | 1 +
sound/pci/hda/patch_sigmatel.c | 2 +-
sound/pci/oxygen/xonar_wm87x6.c | 1 +
7 files changed, 15 insertions(+), 17 deletions(-)
diff --git a/sound/core/Kconfig b/sound/core/Kconfig
index ad40938..b413ed0 100644
--- a/sound/core/Kconfig
+++ b/sound/core/Kconfig
@@ -12,6 +12,9 @@ config SND_HWDEP
config SND_RAWMIDI
tristate
+config SND_COMPRESS_OFFLOAD
+ tristate
+
# To be effective this also requires INPUT - users should say:
# select SND_JACK if INPUT=y || INPUT=SND
# to avoid having to force INPUT on.
@@ -154,16 +157,6 @@ config SND_DYNAMIC_MINORS
If you are unsure about this, say N here.
-config SND_COMPRESS_OFFLOAD
- tristate "ALSA Compressed audio offload support"
- default n
- help
- If you want support for offloading compressed audio and have such
- a hardware, then you should say Y here and also to the DSP driver
- of your platform.
-
- If you are unsure about this, say N here.
-
config SND_SUPPORT_OLD_API
bool "Support old ALSA API"
default y
diff --git a/sound/pci/au88x0/au88x0.c b/sound/pci/au88x0/au88x0.c
index 762bb10..f13ad53 100644
--- a/sound/pci/au88x0/au88x0.c
+++ b/sound/pci/au88x0/au88x0.c
@@ -268,8 +268,14 @@ snd_vortex_probe(struct pci_dev *pci, const struct pci_device_id *pci_id)
card->shortname, chip->io, chip->irq);
// (4) Alloc components.
+ err = snd_vortex_mixer(chip);
+ if (err < 0) {
+ snd_card_free(card);
+ return err;
+ }
// ADB pcm.
- if ((err = snd_vortex_new_pcm(chip, VORTEX_PCM_ADB, NR_ADB)) < 0) {
+ err = snd_vortex_new_pcm(chip, VORTEX_PCM_ADB, NR_PCM);
+ if (err < 0) {
snd_card_free(card);
return err;
}
@@ -299,11 +305,6 @@ snd_vortex_probe(struct pci_dev *pci, const struct pci_device_id *pci_id)
return err;
}
#endif
- // snd_ac97_mixer and Vortex mixer.
- if ((err = snd_vortex_mixer(chip)) < 0) {
- snd_card_free(card);
- return err;
- }
if ((err = snd_vortex_midi(chip)) < 0) {
snd_card_free(card);
return err;
diff --git a/sound/pci/au88x0/au88x0.h b/sound/pci/au88x0/au88x0.h
index 02f6e08..bb93815 100644
--- a/sound/pci/au88x0/au88x0.h
+++ b/sound/pci/au88x0/au88x0.h
@@ -105,6 +105,7 @@
#define MIX_SPDIF(x) (vortex->mixspdif[x])
#define NR_WTPB 0x20 /* WT channels per each bank. */
+#define NR_PCM 0x10
/* Structs */
typedef struct {
diff --git a/sound/pci/au88x0/au88x0_pcm.c b/sound/pci/au88x0/au88x0_pcm.c
index 0488633..0ef2f97 100644
--- a/sound/pci/au88x0/au88x0_pcm.c
+++ b/sound/pci/au88x0/au88x0_pcm.c
@@ -168,6 +168,7 @@ static int snd_vortex_pcm_open(struct snd_pcm_substream *substream)
runtime->hw = snd_vortex_playback_hw_adb;
#ifdef CHIP_AU8830
if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK &&
+ VORTEX_IS_QUAD(vortex) &&
VORTEX_PCM_TYPE(substream->pcm) == VORTEX_PCM_ADB) {
runtime->hw.channels_max = 4;
snd_pcm_hw_constraint_list(runtime, 0,
diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
index 0852e20..fb35474 100644
--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -2498,6 +2498,7 @@ static struct snd_pci_quirk position_fix_list[] __devinitdata = {
SND_PCI_QUIRK(0x1043, 0x81b3, "ASUS", POS_FIX_LPIB),
SND_PCI_QUIRK(0x1043, 0x81e7, "ASUS M2V", POS_FIX_LPIB),
SND_PCI_QUIRK(0x104d, 0x9069, "Sony VPCS11V9E", POS_FIX_LPIB),
+ SND_PCI_QUIRK(0x10de, 0xcb89, "Macbook Pro 7,1", POS_FIX_LPIB),
SND_PCI_QUIRK(0x1297, 0x3166, "Shuttle", POS_FIX_LPIB),
SND_PCI_QUIRK(0x1458, 0xa022, "ga-ma770-ud3", POS_FIX_LPIB),
SND_PCI_QUIRK(0x1462, 0x1002, "MSI Wind U115", POS_FIX_LPIB),
diff --git a/sound/pci/hda/patch_sigmatel.c b/sound/pci/hda/patch_sigmatel.c
index 87e684f..3556408 100644
--- a/sound/pci/hda/patch_sigmatel.c
+++ b/sound/pci/hda/patch_sigmatel.c
@@ -1596,7 +1596,7 @@ static const struct snd_pci_quirk stac92hd73xx_cfg_tbl[] = {
SND_PCI_QUIRK(PCI_VENDOR_ID_DELL, 0x02bd,
"Dell Studio 1557", STAC_DELL_M6_DMIC),
SND_PCI_QUIRK(PCI_VENDOR_ID_DELL, 0x02fe,
- "Dell Studio XPS 1645", STAC_DELL_M6_BOTH),
+ "Dell Studio XPS 1645", STAC_DELL_M6_DMIC),
SND_PCI_QUIRK(PCI_VENDOR_ID_DELL, 0x0413,
"Dell Studio 1558", STAC_DELL_M6_DMIC),
{} /* terminator */
diff --git a/sound/pci/oxygen/xonar_wm87x6.c b/sound/pci/oxygen/xonar_wm87x6.c
index 478303e..63cff90 100644
--- a/sound/pci/oxygen/xonar_wm87x6.c
+++ b/sound/pci/oxygen/xonar_wm87x6.c
@@ -177,6 +177,7 @@ static void wm8776_registers_init(struct oxygen *chip)
struct xonar_wm87x6 *data = chip->model_data;
wm8776_write(chip, WM8776_RESET, 0);
+ wm8776_write(chip, WM8776_PHASESWAP, WM8776_PH_MASK);
wm8776_write(chip, WM8776_DACCTRL1, WM8776_DZCEN |
WM8776_PL_LEFT_LEFT | WM8776_PL_RIGHT_RIGHT);
wm8776_write(chip, WM8776_DACMUTE, chip->dac_mute ? WM8776_DMUTE : 0);
^ permalink raw reply related
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.