* Re: [Qemu-devel] [PATCH V5] docs: add PCIe devices placement guidelines
From: Marcel Apfelbaum @ 2016-11-09 14:30 UTC (permalink / raw)
To: Marcel Apfelbaum, qemu-devel, mst
Cc: drjones, abologna, alex.williamson, kraxel, laine, lersek
In-Reply-To: <1478007587-4560-1-git-send-email-marcel@redhat.com>
On 11/01/2016 03:39 PM, Marcel Apfelbaum wrote:
> Proposes best practices on how to use PCI Express/PCI device
> in PCI Express based machines and explain the reasoning behind them.
>
Hi Michael,
Can you please apply this doc for 2.8 ?
Thanks,
Marcel
> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
> Signed-off-by: Marcel Apfelbaum <marcel@redhat.com>
> ---
>
> Hi,
>
> v4->v5:
> - Addressed Laine's comments:
> - Advertize (slot,chassis) parameters as mandatory
> - Stated the Downstream ports are not hot-pluggable
> - Other minor typos
>
> v3->v4:
> - Addressed minor typos spotted by Laszlo, thanks!
>
> v2->v3:
> - Addressed the comments from Andrea Bolognani and Laszlo Ersek, which are
> much appreciated!
> - Added links to presentations that may help the understanding of the document.
>
> RFC->v2:
> - Addressed a lot of comments from the reviewers (many thanks to all, especially to Laszlo)
>
>
> Thanks,
> Marcel
>
>
> docs/pcie.txt | 311 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 311 insertions(+)
> create mode 100644 docs/pcie.txt
>
> diff --git a/docs/pcie.txt b/docs/pcie.txt
> new file mode 100644
> index 0000000..1d9bd18
> --- /dev/null
> +++ b/docs/pcie.txt
> @@ -0,0 +1,311 @@
> +PCI EXPRESS GUIDELINES
> +======================
> +
> +1. Introduction
> +================
> +The doc proposes best practices on how to use PCI Express/PCI device
> +in PCI Express based machines and explains the reasoning behind them.
> +
> +The following presentations accompany this document:
> + (1) Q35 overview.
> + http://wiki.qemu.org/images/4/4e/Q35.pdf
> + (2) A comparison between PCI and PCI Express technologies.
> + http://wiki.qemu.org/images/f/f6/PCIvsPCIe.pdf
> +
> +Note: The usage examples are not intended to replace the full
> +documentation, please use QEMU help to retrieve all options.
> +
> +2. Device placement strategy
> +============================
> +QEMU does not have a clear socket-device matching mechanism
> +and allows any PCI/PCI Express device to be plugged into any
> +PCI/PCI Express slot.
> +Plugging a PCI device into a PCI Express slot might not always work and
> +is weird anyway since it cannot be done for "bare metal".
> +Plugging a PCI Express device into a PCI slot will hide the Extended
> +Configuration Space thus is also not recommended.
> +
> +The recommendation is to separate the PCI Express and PCI hierarchies.
> +PCI Express devices should be plugged only into PCI Express Root Ports and
> +PCI Express Downstream ports.
> +
> +2.1 Root Bus (pcie.0)
> +=====================
> +Place only the following kinds of devices directly on the Root Complex:
> + (1) PCI Devices (e.g. network card, graphics card, IDE controller),
> + not controllers. Place only legacy PCI devices on
> + the Root Complex. These will be considered Integrated Endpoints.
> + Note: Integrated Endpoints are not hot-pluggable.
> +
> + Although the PCI Express spec does not forbid PCI Express devices as
> + Integrated Endpoints, existing hardware mostly integrates legacy PCI
> + devices with the Root Complex. Guest OSes are suspected to behave
> + strangely when PCI Express devices are integrated
> + with the Root Complex.
> +
> + (2) PCI Express Root Ports (ioh3420), for starting exclusively PCI Express
> + hierarchies.
> +
> + (3) DMI-PCI Bridges (i82801b11-bridge), for starting legacy PCI
> + hierarchies.
> +
> + (4) Extra Root Complexes (pxb-pcie), if multiple PCI Express Root Buses
> + are needed.
> +
> + pcie.0 bus
> + ----------------------------------------------------------------------------
> + | | | |
> + ----------- ------------------ ------------------ --------------
> + | PCI Dev | | PCIe Root Port | | DMI-PCI Bridge | | pxb-pcie |
> + ----------- ------------------ ------------------ --------------
> +
> +2.1.1 To plug a device into pcie.0 as a Root Complex Integrated Endpoint use:
> + -device <dev>[,bus=pcie.0]
> +2.1.2 To expose a new PCI Express Root Bus use:
> + -device pxb-pcie,id=pcie.1,bus_nr=x[,numa_node=y][,addr=z]
> + Only PCI Express Root Ports and DMI-PCI bridges can be connected
> + to the pcie.1 bus:
> + -device ioh3420,id=root_port1[,bus=pcie.1][,chassis=x][,slot=y][,addr=z] \
> + -device i82801b11-bridge,id=dmi_pci_bridge1,bus=pcie.1
> +
> +
> +2.2 PCI Express only hierarchy
> +==============================
> +Always use PCI Express Root Ports to start PCI Express hierarchies.
> +
> +A PCI Express Root bus supports up to 32 devices. Since each
> +PCI Express Root Port is a function and a multi-function
> +device may support up to 8 functions, the maximum possible
> +number of PCI Express Root Ports per PCI Express Root Bus is 256.
> +
> +Prefer grouping PCI Express Root Ports into multi-function devices
> +to keep a simple flat hierarchy that is enough for most scenarios.
> +Only use PCI Express Switches (x3130-upstream, xio3130-downstream)
> +if there is no more room for PCI Express Root Ports.
> +Please see section 4. for further justifications.
> +
> +Plug only PCI Express devices into PCI Express Ports.
> +
> +
> + pcie.0 bus
> + ----------------------------------------------------------------------------------
> + | | |
> + ------------- ------------- -------------
> + | Root Port | | Root Port | | Root Port |
> + ------------ ------------- -------------
> + | -------------------------|------------------------
> + ------------ | ----------------- |
> + | PCIe Dev | | PCI Express | Upstream Port | |
> + ------------ | Switch ----------------- |
> + | | | |
> + | ------------------- ------------------- |
> + | | Downstream Port | | Downstream Port | |
> + | ------------------- ------------------- |
> + -------------|-----------------------|------------
> + ------------
> + | PCIe Dev |
> + ------------
> +
> +2.2.1 Plugging a PCI Express device into a PCI Express Root Port:
> + -device ioh3420,id=root_port1,chassis=x,slot=y[,bus=pcie.0][,addr=z] \
> + -device <dev>,bus=root_port1
> +2.2.2 Using multi-function PCI Express Root Ports:
> + -device ioh3420,id=root_port1,multifunction=on,chassis=x,slot=y[,bus=pcie.0][,addr=z.0] \
> + -device ioh3420,id=root_port2,chassis=x1,slot=y1[,bus=pcie.0][,addr=z.1] \
> + -device ioh3420,id=root_port3,chassis=x2,slot=y2[,bus=pcie.0][,addr=z.2] \
> +2.2.2 Plugging a PCI Express device into a Switch:
> + -device ioh3420,id=root_port1,chassis=x,slot=y[,bus=pcie.0][,addr=z] \
> + -device x3130-upstream,id=upstream_port1,bus=root_port1[,addr=x] \
> + -device xio3130-downstream,id=downstream_port1,bus=upstream_port1,chassis=x1,slot=y1[,addr=z1]] \
> + -device <dev>,bus=downstream_port1
> +
> +Notes:
> + - (slot, chassis) pair is mandatory and must be
> + unique for each PCI Express Root Port.
> + - 'addr' parameter can be 0 for all the examples above.
> +
> +
> +2.3 PCI only hierarchy
> +======================
> +Legacy PCI devices can be plugged into pcie.0 as Integrated Endpoints,
> +but, as mentioned in section 5, doing so means the legacy PCI
> +device in question will be incapable of hot-unplugging.
> +Besides that use DMI-PCI Bridges (i82801b11-bridge) in combination
> +with PCI-PCI Bridges (pci-bridge) to start PCI hierarchies.
> +
> +Prefer flat hierarchies. For most scenarios a single DMI-PCI Bridge
> +(having 32 slots) and several PCI-PCI Bridges attached to it
> +(each supporting also 32 slots) will support hundreds of legacy devices.
> +The recommendation is to populate one PCI-PCI Bridge under the DMI-PCI Bridge
> +until is full and then plug a new PCI-PCI Bridge...
> +
> + pcie.0 bus
> + ----------------------------------------------
> + | |
> + ----------- ------------------
> + | PCI Dev | | DMI-PCI BRIDGE |
> + ---------- ------------------
> + | |
> + ------------------ ------------------
> + | PCI-PCI Bridge | | PCI-PCI Bridge | ...
> + ------------------ ------------------
> + | |
> + ----------- -----------
> + | PCI Dev | | PCI Dev |
> + ----------- -----------
> +
> +2.3.1 To plug a PCI device into pcie.0 as an Integrated Endpoint use:
> + -device <dev>[,bus=pcie.0]
> +2.3.2 Plugging a PCI device into a PCI-PCI Bridge:
> + -device i82801b11-bridge,id=dmi_pci_bridge1[,bus=pcie.0] \
> + -device pci-bridge,id=pci_bridge1,bus=dmi_pci_bridge1[,chassis_nr=x][,addr=y] \
> + -device <dev>,bus=pci_bridge1[,addr=x]
> + Note that 'addr' cannot be 0 unless shpc=off parameter is passed to
> + the PCI Bridge.
> +
> +3. IO space issues
> +===================
> +The PCI Express Root Ports and PCI Express Downstream ports are seen by
> +Firmware/Guest OS as PCI-PCI Bridges. As required by the PCI spec, each
> +such Port should be reserved a 4K IO range for, even though only one
> +(multifunction) device can be plugged into each Port. This results in
> +poor IO space utilization.
> +
> +The firmware used by QEMU (SeaBIOS/OVMF) may try further optimizations
> +by not allocating IO space for each PCI Express Root / PCI Express
> +Downstream port if:
> + (1) the port is empty, or
> + (2) the device behind the port has no IO BARs.
> +
> +The IO space is very limited, to 65536 byte-wide IO ports, and may even be
> +fragmented by fixed IO ports owned by platform devices resulting in at most
> +10 PCI Express Root Ports or PCI Express Downstream Ports per system
> +if devices with IO BARs are used in the PCI Express hierarchy. Using the
> +proposed device placing strategy solves this issue by using only
> +PCI Express devices within PCI Express hierarchy.
> +
> +The PCI Express spec requires that PCI Express devices work properly
> +without using IO ports. The PCI hierarchy has no such limitations.
> +
> +
> +4. Bus numbers issues
> +======================
> +Each PCI domain can have up to only 256 buses and the QEMU PCI Express
> +machines do not support multiple PCI domains even if extra Root
> +Complexes (pxb-pcie) are used.
> +
> +Each element of the PCI Express hierarchy (Root Complexes,
> +PCI Express Root Ports, PCI Express Downstream/Upstream ports)
> +uses one bus number. Since only one (multifunction) device
> +can be attached to a PCI Express Root Port or PCI Express Downstream
> +Port it is advised to plan in advance for the expected number of
> +devices to prevent bus number starvation.
> +
> +Avoiding PCI Express Switches (and thereby striving for a 'flatter' PCI
> +Express hierarchy) enables the hierarchy to not spend bus numbers on
> +Upstream Ports.
> +
> +The bus_nr properties of the pxb-pcie devices partition the 0..255 bus
> +number space. All bus numbers assigned to the buses recursively behind a
> +given pxb-pcie device's root bus must fit between the bus_nr property of
> +that pxb-pcie device, and the lowest of the higher bus_nr properties
> +that the command line sets for other pxb-pcie devices.
> +
> +
> +5. Hot-plug
> +============
> +The PCI Express root buses (pcie.0 and the buses exposed by pxb-pcie devices)
> +do not support hot-plug, so any devices plugged into Root Complexes
> +cannot be hot-plugged/hot-unplugged:
> + (1) PCI Express Integrated Endpoints
> + (2) PCI Express Root Ports
> + (3) DMI-PCI Bridges
> + (4) pxb-pcie
> +
> +Be aware that PCI Express Downstream Ports can't be hot-plugged into
> +an existing PCI Express Upstream Port.
> +
> +PCI devices can be hot-plugged into PCI-PCI Bridges. The PCI hot-plug is ACPI
> +based and can work side by side with the PCI Express native hot-plug.
> +
> +PCI Express devices can be natively hot-plugged/hot-unplugged into/from
> +PCI Express Root Ports (and PCI Express Downstream Ports).
> +
> +5.1 Planning for hot-plug:
> + (1) PCI hierarchy
> + Leave enough PCI-PCI Bridge slots empty or add one
> + or more empty PCI-PCI Bridges to the DMI-PCI Bridge.
> +
> + For each such PCI-PCI Bridge the Guest Firmware is expected to reserve
> + 4K IO space and 2M MMIO range to be used for all devices behind it.
> +
> + Because of the hard IO limit of around 10 PCI Bridges (~ 40K space)
> + per system don't use more than 9 PCI-PCI Bridges, leaving 4K for the
> + Integrated Endpoints. (The PCI Express Hierarchy needs no IO space).
> +
> + (2) PCI Express hierarchy:
> + Leave enough PCI Express Root Ports empty. Use multifunction
> + PCI Express Root Ports (up to 8 ports per pcie.0 slot)
> + on the Root Complex(es), for keeping the
> + hierarchy as flat as possible, thereby saving PCI bus numbers.
> + Don't use PCI Express Switches if you don't have
> + to, each one of those uses an extra PCI bus (for its Upstream Port)
> + that could be put to better use with another Root Port or Downstream
> + Port, which may come handy for hot-plugging another device.
> +
> +
> +5.3 Hot-plug example:
> +Using HMP: (add -monitor stdio to QEMU command line)
> + device_add <dev>,id=<id>,bus=<PCI Express Root Port Id/PCI Express Downstream Port Id/PCI-PCI Bridge Id/>
> +
> +
> +6. Device assignment
> +====================
> +Host devices are mostly PCI Express and should be plugged only into
> +PCI Express Root Ports or PCI Express Downstream Ports.
> +PCI-PCI Bridge slots can be used for legacy PCI host devices.
> +
> +6.1 How to detect if a device is PCI Express:
> + > lspci -s 03:00.0 -v (as root)
> +
> + 03:00.0 Network controller: Intel Corporation Wireless 7260 (rev 83)
> + Subsystem: Intel Corporation Dual Band Wireless-AC 7260
> + Flags: bus master, fast devsel, latency 0, IRQ 50
> + Memory at f0400000 (64-bit, non-prefetchable) [size=8K]
> + Capabilities: [c8] Power Management version 3
> + Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
> + Capabilities: [40] Express Endpoint, MSI 00
> + ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> + Capabilities: [100] Advanced Error Reporting
> + Capabilities: [140] Device Serial Number 7c-7a-91-ff-ff-90-db-20
> + Capabilities: [14c] Latency Tolerance Reporting
> + Capabilities: [154] Vendor Specific Information: ID=cafe Rev=1 Len=014
> +
> +If you can see the "Express Endpoint" capability in the
> +output, then the device is indeed PCI Express.
> +
> +
> +7. Virtio devices
> +=================
> +Virtio devices plugged into the PCI hierarchy or as Integrated Endpoints
> +will remain PCI and have transitional behaviour as default.
> +Transitional virtio devices work in both IO and MMIO modes depending on
> +the guest support. The Guest firmware will assign both IO and MMIO resources
> +to transitional virtio devices.
> +
> +Virtio devices plugged into PCI Express ports are PCI Express devices and
> +have "1.0" behavior by default without IO support.
> +In both cases disable-legacy and disable-modern properties can be used
> +to override the behaviour.
> +
> +Note that setting disable-legacy=off will enable legacy mode (enabling
> +legacy behavior) for PCI Express virtio devices causing them to
> +require IO space, which, given the limited available IO space, may quickly
> +lead to resource exhaustion, and is therefore strongly discouraged.
> +
> +
> +8. Conclusion
> +==============
> +The proposal offers a usage model that is easy to understand and follow
> +and at the same time overcomes the PCI Express architecture limitations.
> +
>
^ permalink raw reply
* [PATCH 0/2] media: Exynos GScaller: add support for Exynos 5433 SoC
From: Marek Szyprowski @ 2016-11-09 14:29 UTC (permalink / raw)
To: linux-media, linux-samsung-soc
Cc: Marek Szyprowski, Sylwester Nawrocki, Krzysztof Kozlowski,
Bartlomiej Zolnierkiewicz, Javier Martinez Canillas
In-Reply-To: <CGME20161109142950eucas1p27459d022bf3945618deb1b77fe6c4611@eucas1p2.samsung.com>
Hi!
This patchset add support for Exynos 5433 SoC to Exynos GScaller driver.
This patchset requires fixes for Exynos GScaller driver posted
in the "[PATCH 00/12] media: Exynos GScaller driver fixes" thread.
Tested on Exynos5433-based TM2 board.
Best regards
Marek Szyprowski
Samsung R&D Institute Poland
Patch summary:
Marek Szyprowski (2):
exynos-gsc: Enable driver on ARCH_EXYNOS
exynos-gsc: Add support for Exynos5433 specific version
.../devicetree/bindings/media/exynos5-gsc.txt | 3 +-
drivers/media/platform/Kconfig | 2 +-
drivers/media/platform/exynos-gsc/gsc-core.c | 74 ++++++++++++++++------
drivers/media/platform/exynos-gsc/gsc-core.h | 6 +-
4 files changed, 63 insertions(+), 22 deletions(-)
--
1.9.1
^ permalink raw reply
* [OSSTEST PATCH 1/3] ts-xen-build: Support passing arguments to configure
From: Ian Jackson @ 2016-11-09 14:30 UTC (permalink / raw)
To: xen-devel; +Cc: Ian Jackson
In-Reply-To: <1478701847-30651-1-git-send-email-ian.jackson@eu.citrix.com>
No functional change with existing callers.
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
ts-xen-build | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/ts-xen-build b/ts-xen-build
index 3e53d74..7dfcda7 100755
--- a/ts-xen-build
+++ b/ts-xen-build
@@ -37,7 +37,15 @@ while (@ARGV && $ARGV[0] =~ m/^-/) {
die "$_ ?";
}
}
+
+my ($dashdashdash) = grep { $ARGV[$_] eq '---' } 0..$#ARGV;
+my (@configure_args, @make_args);
+$dashdashdash //= -1;
+@configure_args = @ARGV[0..$dashdashdash-1];
+@make_args = @ARGV[$dashdashdash+1..$#ARGV];
+
# remaining arguments are passed as targets to "make"
+# if there is a ---, those before that are arguments to "configure"
builddirsprops();
@@ -126,7 +134,7 @@ sub build () {
ovmf=$ovmf_opt
fi
END
- $configure_prefix ./configure --sysconfdir=/etc \$xend \$ovmf $configure_suffix
+ $configure_prefix ./configure --sysconfdir=/etc \$xend \$ovmf $configure_suffix @configure_args
END
fi
END
@@ -139,7 +147,7 @@ END
END
buildcmd_stamped_logged(9000, 'xen', 'build', '',<<END,'');
- $make_prefix make $makeflags @ARGV
+ $make_prefix make $makeflags @make_args
END
if ($enable_xsm) {
--
2.1.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply related
* Re: [PATCH 2/3] ipmi/bt-bmc: maintain a request expiry list
From: Cédric Le Goater @ 2016-11-09 14:30 UTC (permalink / raw)
To: minyard, openipmi-developer, Joel Stanley
Cc: devicetree, Rob Herring, Brendan Higgins, linux-arm-kernel,
Arnd Bergmann
In-Reply-To: <a7aea2a7-6cb4-655e-3c69-1a156945e27b@acm.org>
On 11/07/2016 08:04 PM, Corey Minyard wrote:
> On 11/02/2016 02:57 AM, Cédric Le Goater wrote:
>> Regarding the response expiration handling, the IPMI spec says :
>>
>> The BMC must not return a given response once the corresponding
>> Request-to-Response interval has passed. The BMC can ensure this
>> by maintaining its own internal list of outstanding requests through
>> the interface. The BMC could age and expire the entries in the list
>> by expiring the entries at an interval that is somewhat shorter than
>> the specified Request-to-Response interval....
>>
>> To handle such case, we maintain list of received requests using the
>> seq number of the BT message to identify them. The list is updated
>> each time a request is received and a response is sent. The expiration
>> of the reponses is handled at each updates but also with a timer.
>
> This looks correct, but it seems awfully complicated.
>
> Why can't you get the current time before the wait_event_interruptible()
> and then compare the time before you do the write? That would seem to
> accomplish the same thing without any lists or extra locks.
Well, the expiry list needs a request identifier and it is currently using
the Seq byte for this purpose. So the BT message needs to be read to grab
that byte. The request is added to a list and that involves some locking.
When the response is written, the first matching request is removed from
the list and a garbage collector loop is also run. Then, as we might not
get any responses to run that loop, we use a timer to empty the list from
any expired requests.
The read/write ops of the driver are protected with a mutex, the list and
the timer add their share of locking. That could have been done with RCU
surely but we don't really need performance in this driver.
Caveats :
bt_bmc_remove_request() should not be done in the writing loop though.
It needs a fix.
The request identifier is currently Seq but the spec say we should use
Seq, NetFn, and Command or an internal Seq value as a request identifier.
Google is also working on an OEM/Group extension (Brendan in CC: )
which has a different message format. I need to look closer at what
should be done in this case.
> Also, if you are going to have multiple writers on this interface, I don't
> think the interface will work correctly. I think you need to claim the
> mutex first. Otherwise you might get into a situation where two writers
> will wake up at the same time, the first writes and releases the mutex,
> then the second will find that the interface is busy and fail.
yes. that is a current problem in the driver and it is not really an
elegant way to handle concurrency. We are fine for the moment as we
only have one single threaded process using the device.
> If I am correct, the mutex will need to become interruptible and come
> first, I think. (And the timing would have to start before the mutex,
> of course.) This applies to both the read and write interface.
OK. I will look into fixing this problem first.
> Another thing is that this is request-to-release time. If a request takes
> a long time to process (say, a write to a flash device) the timeout would
> need to be decreased by the processing time.
Hmm, how would that fit with the "BT Interface Capabilities" which
defines :
BMC Request-to-Response time, in seconds, 1 based. 30 seconds, maximum.
This is a fixed value. And the spec only say :
The BMC could age and expire the entries in the list by expiring
the entries at an interval that is somewhat shorter than the
specified Request-to-Response interval.
May be I am misunderstanding.
> It's probably ok to not do that for the moment, but you may want to add
> a note. Fixing that would require adding a timeout for each message.
Thanks,
C.
> -corey
>
>
>> Signed-off-by: Cédric Le Goater <clg@kaod.org>
>> ---
>> drivers/char/ipmi/bt-bmc.c | 132 +++++++++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 132 insertions(+)
>>
>> diff --git a/drivers/char/ipmi/bt-bmc.c b/drivers/char/ipmi/bt-bmc.c
>> index fc9e8891eae3..e751e4a754b7 100644
>> --- a/drivers/char/ipmi/bt-bmc.c
>> +++ b/drivers/char/ipmi/bt-bmc.c
>> @@ -17,6 +17,7 @@
>> #include <linux/platform_device.h>
>> #include <linux/poll.h>
>> #include <linux/sched.h>
>> +#include <linux/slab.h>
>> #include <linux/timer.h>
>> /*
>> @@ -57,6 +58,15 @@
>> #define BT_BMC_BUFFER_SIZE 256
>> +#define BT_BMC_RESPONSE_TIME 5 /* seconds */
>> +
>> +struct ipmi_request {
>> + struct list_head list;
>> +
>> + u8 seq;
>> + unsigned long expires;
>> +};
>> +
>> struct bt_bmc {
>> struct device dev;
>> struct miscdevice miscdev;
>> @@ -65,6 +75,11 @@ struct bt_bmc {
>> wait_queue_head_t queue;
>> struct timer_list poll_timer;
>> struct mutex mutex;
>> +
>> + unsigned int response_time;
>> + struct timer_list requests_timer;
>> + spinlock_t requests_lock;
>> + struct list_head requests;
>> };
>> static atomic_t open_count = ATOMIC_INIT(0);
>> @@ -163,6 +178,94 @@ static int bt_bmc_open(struct inode *inode, struct file *file)
>> }
>> /*
>> + * lock should be held
>> + */
>> +static void drop_expired_requests(struct bt_bmc *bt_bmc)
>> +{
>> + unsigned long flags = 0;
>> + struct ipmi_request *req, *next;
>> + unsigned long next_expires = 0;
>> + int start_timer = 0;
>> +
>> + spin_lock_irqsave(&bt_bmc->requests_lock, flags);
>> + list_for_each_entry_safe(req, next, &bt_bmc->requests, list) {
>> + if (time_after_eq(jiffies, req->expires)) {
>> + pr_warn("BT: request seq:%d has expired. dropping\n",
>> + req->seq);
>> + list_del(&req->list);
>> + kfree(req);
>> + continue;
>> + }
>> + if (!start_timer) {
>> + start_timer = 1;
>> + next_expires = req->expires;
>> + } else {
>> + next_expires = min(next_expires, req->expires);
>> + }
>> + }
>> + spin_unlock_irqrestore(&bt_bmc->requests_lock, flags);
>> +
>> + /* and possibly restart */
>> + if (start_timer)
>> + mod_timer(&bt_bmc->requests_timer, next_expires);
>> +}
>> +
>> +static void requests_timer(unsigned long data)
>> +{
>> + struct bt_bmc *bt_bmc = (void *)data;
>> +
>> + drop_expired_requests(bt_bmc);
>> +}
>> +
>> +static int bt_bmc_add_request(struct bt_bmc *bt_bmc, u8 seq)
>> +{
>> + struct ipmi_request *req;
>> +
>> + req = kmalloc(sizeof(*req), GFP_KERNEL);
>> + if (!req)
>> + return -ENOMEM;
>> +
>> + req->seq = seq;
>> + req->expires = jiffies +
>> + msecs_to_jiffies(bt_bmc->response_time * 1000);
>> +
>> + spin_lock(&bt_bmc->requests_lock);
>> + list_add(&req->list, &bt_bmc->requests);
>> + spin_unlock(&bt_bmc->requests_lock);
>> +
>> + drop_expired_requests(bt_bmc);
>> + return 0;
>> +}
>> +
>> +static int bt_bmc_remove_request(struct bt_bmc *bt_bmc, u8 seq)
>> +{
>> + struct ipmi_request *req, *next;
>> + int ret = -EBADRQC; /* Invalid request code */
>> +
>> + spin_lock(&bt_bmc->requests_lock);
>> + list_for_each_entry_safe(req, next, &bt_bmc->requests, list) {
>> + /*
>> + * The sequence number should be unique, so remove the
>> + * first matching request found. If there are others,
>> + * they should expire
>> + */
>> + if (req->seq == seq) {
>> + list_del(&req->list);
>> + kfree(req);
>> + ret = 0;
>> + break;
>> + }
>> + }
>> + spin_unlock(&bt_bmc->requests_lock);
>> +
>> + if (ret)
>> + pr_warn("BT: request seq:%d is invalid\n", seq);
>> +
>> + drop_expired_requests(bt_bmc);
>> + return ret;
>> +}
>> +
>> +/*
>> * The BT (Block Transfer) interface means that entire messages are
>> * buffered by the host before a notification is sent to the BMC that
>> * there is data to be read. The first byte is the length and the
>> @@ -231,6 +334,13 @@ static ssize_t bt_bmc_read(struct file *file, char __user *buf,
>> len_byte = 0;
>> }
>> + if (ret > 0) {
>> + int ret2 = bt_bmc_add_request(bt_bmc, kbuffer[2]);
>> +
>> + if (ret2)
>> + ret = ret2;
>> + }
>> +
>> clr_b_busy(bt_bmc);
>> out_unlock:
>> @@ -283,12 +393,20 @@ static ssize_t bt_bmc_write(struct file *file, const char __user *buf,
>> clr_wr_ptr(bt_bmc);
>> while (count) {
>> + int ret2;
>> +
>> nwritten = min_t(ssize_t, count, sizeof(kbuffer));
>> if (copy_from_user(&kbuffer, buf, nwritten)) {
>> ret = -EFAULT;
>> break;
>> }
>> + ret2 = bt_bmc_remove_request(bt_bmc, kbuffer[2]);
>> + if (ret2) {
>> + ret = ret2;
>> + break;
>> + }
>> +
>> bt_writen(bt_bmc, kbuffer, nwritten);
>> count -= nwritten;
>> @@ -438,6 +556,8 @@ static int bt_bmc_probe(struct platform_device *pdev)
>> mutex_init(&bt_bmc->mutex);
>> init_waitqueue_head(&bt_bmc->queue);
>> + INIT_LIST_HEAD(&bt_bmc->requests);
>> + spin_lock_init(&bt_bmc->requests_lock);
>> bt_bmc->miscdev.minor = MISC_DYNAMIC_MINOR,
>> bt_bmc->miscdev.name = DEVICE_NAME,
>> @@ -451,6 +571,8 @@ static int bt_bmc_probe(struct platform_device *pdev)
>> bt_bmc_config_irq(bt_bmc, pdev);
>> + bt_bmc->response_time = BT_BMC_RESPONSE_TIME;
>> +
>> if (bt_bmc->irq) {
>> dev_info(dev, "Using IRQ %d\n", bt_bmc->irq);
>> } else {
>> @@ -468,6 +590,9 @@ static int bt_bmc_probe(struct platform_device *pdev)
>> BT_CR0_ENABLE_IBT,
>> bt_bmc->base + BT_CR0);
>> + setup_timer(&bt_bmc->requests_timer, requests_timer,
>> + (unsigned long)bt_bmc);
>> +
>> clr_b_busy(bt_bmc);
>> return 0;
>> @@ -476,10 +601,17 @@ static int bt_bmc_probe(struct platform_device *pdev)
>> static int bt_bmc_remove(struct platform_device *pdev)
>> {
>> struct bt_bmc *bt_bmc = dev_get_drvdata(&pdev->dev);
>> + struct ipmi_request *req, *next;
>> misc_deregister(&bt_bmc->miscdev);
>> if (!bt_bmc->irq)
>> del_timer_sync(&bt_bmc->poll_timer);
>> +
>> + del_timer_sync(&bt_bmc->requests_timer);
>> + list_for_each_entry_safe(req, next, &bt_bmc->requests, list) {
>> + list_del(&req->list);
>> + kfree(req);
>> + }
>> return 0;
>> }
>>
>
>
------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
Openipmi-developer mailing list
Openipmi-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openipmi-developer
^ permalink raw reply
* [PATCH 2/3] ipmi/bt-bmc: maintain a request expiry list
From: Cédric Le Goater @ 2016-11-09 14:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <a7aea2a7-6cb4-655e-3c69-1a156945e27b@acm.org>
On 11/07/2016 08:04 PM, Corey Minyard wrote:
> On 11/02/2016 02:57 AM, C?dric Le Goater wrote:
>> Regarding the response expiration handling, the IPMI spec says :
>>
>> The BMC must not return a given response once the corresponding
>> Request-to-Response interval has passed. The BMC can ensure this
>> by maintaining its own internal list of outstanding requests through
>> the interface. The BMC could age and expire the entries in the list
>> by expiring the entries at an interval that is somewhat shorter than
>> the specified Request-to-Response interval....
>>
>> To handle such case, we maintain list of received requests using the
>> seq number of the BT message to identify them. The list is updated
>> each time a request is received and a response is sent. The expiration
>> of the reponses is handled at each updates but also with a timer.
>
> This looks correct, but it seems awfully complicated.
>
> Why can't you get the current time before the wait_event_interruptible()
> and then compare the time before you do the write? That would seem to
> accomplish the same thing without any lists or extra locks.
Well, the expiry list needs a request identifier and it is currently using
the Seq byte for this purpose. So the BT message needs to be read to grab
that byte. The request is added to a list and that involves some locking.
When the response is written, the first matching request is removed from
the list and a garbage collector loop is also run. Then, as we might not
get any responses to run that loop, we use a timer to empty the list from
any expired requests.
The read/write ops of the driver are protected with a mutex, the list and
the timer add their share of locking. That could have been done with RCU
surely but we don't really need performance in this driver.
Caveats :
bt_bmc_remove_request() should not be done in the writing loop though.
It needs a fix.
The request identifier is currently Seq but the spec say we should use
Seq, NetFn, and Command or an internal Seq value as a request identifier.
Google is also working on an OEM/Group extension (Brendan in CC: )
which has a different message format. I need to look closer at what
should be done in this case.
> Also, if you are going to have multiple writers on this interface, I don't
> think the interface will work correctly. I think you need to claim the
> mutex first. Otherwise you might get into a situation where two writers
> will wake up at the same time, the first writes and releases the mutex,
> then the second will find that the interface is busy and fail.
yes. that is a current problem in the driver and it is not really an
elegant way to handle concurrency. We are fine for the moment as we
only have one single threaded process using the device.
> If I am correct, the mutex will need to become interruptible and come
> first, I think. (And the timing would have to start before the mutex,
> of course.) This applies to both the read and write interface.
OK. I will look into fixing this problem first.
> Another thing is that this is request-to-release time. If a request takes
> a long time to process (say, a write to a flash device) the timeout would
> need to be decreased by the processing time.
Hmm, how would that fit with the "BT Interface Capabilities" which
defines :
BMC Request-to-Response time, in seconds, 1 based. 30 seconds, maximum.
This is a fixed value. And the spec only say :
The BMC could age and expire the entries in the list by expiring
the entries at an interval that is somewhat shorter than the
specified Request-to-Response interval.
May be I am misunderstanding.
> It's probably ok to not do that for the moment, but you may want to add
> a note. Fixing that would require adding a timeout for each message.
Thanks,
C.
> -corey
>
>
>> Signed-off-by: C?dric Le Goater <clg@kaod.org>
>> ---
>> drivers/char/ipmi/bt-bmc.c | 132 +++++++++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 132 insertions(+)
>>
>> diff --git a/drivers/char/ipmi/bt-bmc.c b/drivers/char/ipmi/bt-bmc.c
>> index fc9e8891eae3..e751e4a754b7 100644
>> --- a/drivers/char/ipmi/bt-bmc.c
>> +++ b/drivers/char/ipmi/bt-bmc.c
>> @@ -17,6 +17,7 @@
>> #include <linux/platform_device.h>
>> #include <linux/poll.h>
>> #include <linux/sched.h>
>> +#include <linux/slab.h>
>> #include <linux/timer.h>
>> /*
>> @@ -57,6 +58,15 @@
>> #define BT_BMC_BUFFER_SIZE 256
>> +#define BT_BMC_RESPONSE_TIME 5 /* seconds */
>> +
>> +struct ipmi_request {
>> + struct list_head list;
>> +
>> + u8 seq;
>> + unsigned long expires;
>> +};
>> +
>> struct bt_bmc {
>> struct device dev;
>> struct miscdevice miscdev;
>> @@ -65,6 +75,11 @@ struct bt_bmc {
>> wait_queue_head_t queue;
>> struct timer_list poll_timer;
>> struct mutex mutex;
>> +
>> + unsigned int response_time;
>> + struct timer_list requests_timer;
>> + spinlock_t requests_lock;
>> + struct list_head requests;
>> };
>> static atomic_t open_count = ATOMIC_INIT(0);
>> @@ -163,6 +178,94 @@ static int bt_bmc_open(struct inode *inode, struct file *file)
>> }
>> /*
>> + * lock should be held
>> + */
>> +static void drop_expired_requests(struct bt_bmc *bt_bmc)
>> +{
>> + unsigned long flags = 0;
>> + struct ipmi_request *req, *next;
>> + unsigned long next_expires = 0;
>> + int start_timer = 0;
>> +
>> + spin_lock_irqsave(&bt_bmc->requests_lock, flags);
>> + list_for_each_entry_safe(req, next, &bt_bmc->requests, list) {
>> + if (time_after_eq(jiffies, req->expires)) {
>> + pr_warn("BT: request seq:%d has expired. dropping\n",
>> + req->seq);
>> + list_del(&req->list);
>> + kfree(req);
>> + continue;
>> + }
>> + if (!start_timer) {
>> + start_timer = 1;
>> + next_expires = req->expires;
>> + } else {
>> + next_expires = min(next_expires, req->expires);
>> + }
>> + }
>> + spin_unlock_irqrestore(&bt_bmc->requests_lock, flags);
>> +
>> + /* and possibly restart */
>> + if (start_timer)
>> + mod_timer(&bt_bmc->requests_timer, next_expires);
>> +}
>> +
>> +static void requests_timer(unsigned long data)
>> +{
>> + struct bt_bmc *bt_bmc = (void *)data;
>> +
>> + drop_expired_requests(bt_bmc);
>> +}
>> +
>> +static int bt_bmc_add_request(struct bt_bmc *bt_bmc, u8 seq)
>> +{
>> + struct ipmi_request *req;
>> +
>> + req = kmalloc(sizeof(*req), GFP_KERNEL);
>> + if (!req)
>> + return -ENOMEM;
>> +
>> + req->seq = seq;
>> + req->expires = jiffies +
>> + msecs_to_jiffies(bt_bmc->response_time * 1000);
>> +
>> + spin_lock(&bt_bmc->requests_lock);
>> + list_add(&req->list, &bt_bmc->requests);
>> + spin_unlock(&bt_bmc->requests_lock);
>> +
>> + drop_expired_requests(bt_bmc);
>> + return 0;
>> +}
>> +
>> +static int bt_bmc_remove_request(struct bt_bmc *bt_bmc, u8 seq)
>> +{
>> + struct ipmi_request *req, *next;
>> + int ret = -EBADRQC; /* Invalid request code */
>> +
>> + spin_lock(&bt_bmc->requests_lock);
>> + list_for_each_entry_safe(req, next, &bt_bmc->requests, list) {
>> + /*
>> + * The sequence number should be unique, so remove the
>> + * first matching request found. If there are others,
>> + * they should expire
>> + */
>> + if (req->seq == seq) {
>> + list_del(&req->list);
>> + kfree(req);
>> + ret = 0;
>> + break;
>> + }
>> + }
>> + spin_unlock(&bt_bmc->requests_lock);
>> +
>> + if (ret)
>> + pr_warn("BT: request seq:%d is invalid\n", seq);
>> +
>> + drop_expired_requests(bt_bmc);
>> + return ret;
>> +}
>> +
>> +/*
>> * The BT (Block Transfer) interface means that entire messages are
>> * buffered by the host before a notification is sent to the BMC that
>> * there is data to be read. The first byte is the length and the
>> @@ -231,6 +334,13 @@ static ssize_t bt_bmc_read(struct file *file, char __user *buf,
>> len_byte = 0;
>> }
>> + if (ret > 0) {
>> + int ret2 = bt_bmc_add_request(bt_bmc, kbuffer[2]);
>> +
>> + if (ret2)
>> + ret = ret2;
>> + }
>> +
>> clr_b_busy(bt_bmc);
>> out_unlock:
>> @@ -283,12 +393,20 @@ static ssize_t bt_bmc_write(struct file *file, const char __user *buf,
>> clr_wr_ptr(bt_bmc);
>> while (count) {
>> + int ret2;
>> +
>> nwritten = min_t(ssize_t, count, sizeof(kbuffer));
>> if (copy_from_user(&kbuffer, buf, nwritten)) {
>> ret = -EFAULT;
>> break;
>> }
>> + ret2 = bt_bmc_remove_request(bt_bmc, kbuffer[2]);
>> + if (ret2) {
>> + ret = ret2;
>> + break;
>> + }
>> +
>> bt_writen(bt_bmc, kbuffer, nwritten);
>> count -= nwritten;
>> @@ -438,6 +556,8 @@ static int bt_bmc_probe(struct platform_device *pdev)
>> mutex_init(&bt_bmc->mutex);
>> init_waitqueue_head(&bt_bmc->queue);
>> + INIT_LIST_HEAD(&bt_bmc->requests);
>> + spin_lock_init(&bt_bmc->requests_lock);
>> bt_bmc->miscdev.minor = MISC_DYNAMIC_MINOR,
>> bt_bmc->miscdev.name = DEVICE_NAME,
>> @@ -451,6 +571,8 @@ static int bt_bmc_probe(struct platform_device *pdev)
>> bt_bmc_config_irq(bt_bmc, pdev);
>> + bt_bmc->response_time = BT_BMC_RESPONSE_TIME;
>> +
>> if (bt_bmc->irq) {
>> dev_info(dev, "Using IRQ %d\n", bt_bmc->irq);
>> } else {
>> @@ -468,6 +590,9 @@ static int bt_bmc_probe(struct platform_device *pdev)
>> BT_CR0_ENABLE_IBT,
>> bt_bmc->base + BT_CR0);
>> + setup_timer(&bt_bmc->requests_timer, requests_timer,
>> + (unsigned long)bt_bmc);
>> +
>> clr_b_busy(bt_bmc);
>> return 0;
>> @@ -476,10 +601,17 @@ static int bt_bmc_probe(struct platform_device *pdev)
>> static int bt_bmc_remove(struct platform_device *pdev)
>> {
>> struct bt_bmc *bt_bmc = dev_get_drvdata(&pdev->dev);
>> + struct ipmi_request *req, *next;
>> misc_deregister(&bt_bmc->miscdev);
>> if (!bt_bmc->irq)
>> del_timer_sync(&bt_bmc->poll_timer);
>> +
>> + del_timer_sync(&bt_bmc->requests_timer);
>> + list_for_each_entry_safe(req, next, &bt_bmc->requests, list) {
>> + list_del(&req->list);
>> + kfree(req);
>> + }
>> return 0;
>> }
>>
>
>
^ permalink raw reply
* [PATCH] drm/i915: Trim the object sg table
From: Tvrtko Ursulin @ 2016-11-09 14:30 UTC (permalink / raw)
To: Intel-gfx
From: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
At the moment we allocate enough sg table entries assuming we
will not be able to do any coallescing. But since in practice
we most often can, and more so very effectively, this ends up
wasting a lot of memory.
A simple and effective way of trimming the over-allocated
entries is to copy the table over to a new one allocated to the
exact size.
Experiment on my freshly logged and idle desktop (KDE) showed
that by doing this we can save approximately 1 MiB of RAM, or
when running a typical benchmark like gl_manhattan I have
even seen a 6 MiB saving.
v2:
* Update commit message.
* Use temporary sg_table on stack. (Chris Wilson)
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
---
drivers/gpu/drm/i915/i915_gem.c | 25 +++++++++++++++++++++++++
1 file changed, 25 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index d2ad73d0b5b9..411aae535abe 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2232,6 +2232,28 @@ static unsigned int swiotlb_max_size(void)
#endif
}
+static void i915_sg_trim(struct sg_table *orig_st)
+{
+ struct sg_table new_st;
+ struct scatterlist *sg, *new_sg;
+ unsigned int i;
+
+ if (orig_st->nents == orig_st->orig_nents)
+ return;
+
+ if (sg_alloc_table(&new_st, orig_st->nents, GFP_KERNEL))
+ return;
+
+ new_sg = new_st.sgl;
+ for_each_sg(orig_st->sgl, sg, orig_st->nents, i) {
+ sg_set_page(new_sg, sg_page(sg), sg->length, 0);
+ new_sg = sg_next(new_sg);
+ }
+
+ sg_free_table(orig_st);
+ memcpy(orig_st, &new_st, sizeof(*orig_st));
+}
+
static struct sg_table *
i915_gem_object_get_pages_gtt(struct drm_i915_gem_object *obj)
{
@@ -2317,6 +2339,9 @@ i915_gem_object_get_pages_gtt(struct drm_i915_gem_object *obj)
if (sg) /* loop terminated early; short sg table */
sg_mark_end(sg);
+ /* Trim unused sg entries to avoid wasting memory. */
+ i915_sg_trim(st);
+
ret = i915_gem_gtt_prepare_pages(obj, st);
if (ret)
goto err_pages;
--
2.7.4
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related
* [PATCH 2/2] exynos-gsc: Add support for Exynos5433 specific version
From: Marek Szyprowski @ 2016-11-09 14:29 UTC (permalink / raw)
To: linux-media, linux-samsung-soc
Cc: Marek Szyprowski, Sylwester Nawrocki, Krzysztof Kozlowski,
Bartlomiej Zolnierkiewicz, Javier Martinez Canillas
In-Reply-To: <1478701778-29452-1-git-send-email-m.szyprowski@samsung.com>
This patch add support for Exynos5433 specific version of GScaller module.
The main difference is between Exynos 5433 and earlier is addition of
new clocks that have to be controlled.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
---
.../devicetree/bindings/media/exynos5-gsc.txt | 3 +-
drivers/media/platform/exynos-gsc/gsc-core.c | 74 ++++++++++++++++------
drivers/media/platform/exynos-gsc/gsc-core.h | 6 +-
3 files changed, 62 insertions(+), 21 deletions(-)
diff --git a/Documentation/devicetree/bindings/media/exynos5-gsc.txt b/Documentation/devicetree/bindings/media/exynos5-gsc.txt
index 5fe9372..26ca25b 100644
--- a/Documentation/devicetree/bindings/media/exynos5-gsc.txt
+++ b/Documentation/devicetree/bindings/media/exynos5-gsc.txt
@@ -3,7 +3,8 @@
G-Scaler is used for scaling and color space conversion on EXYNOS5 SoCs.
Required properties:
-- compatible: should be "samsung,exynos5-gsc"
+- compatible: should be "samsung,exynos5-gsc" (for Exynos 5250, 5420 and
+ 5422 SoCs) or "samsung,exynos5433-gsc" (Exynos 5433)
- reg: should contain G-Scaler physical address location and length.
- interrupts: should contain G-Scaler interrupt number
diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c b/drivers/media/platform/exynos-gsc/gsc-core.c
index 664398c..827c1bb 100644
--- a/drivers/media/platform/exynos-gsc/gsc-core.c
+++ b/drivers/media/platform/exynos-gsc/gsc-core.c
@@ -29,8 +29,6 @@
#include "gsc-core.h"
-#define GSC_CLOCK_GATE_NAME "gscl"
-
static const struct gsc_fmt gsc_formats[] = {
{
.name = "RGB565",
@@ -965,6 +963,19 @@ static irqreturn_t gsc_irq_handler(int irq, void *priv)
[3] = &gsc_v_100_variant,
},
.num_entities = 4,
+ .clk_names = { "gscl" },
+ .num_clocks = 1,
+};
+
+static struct gsc_driverdata gsc_5433_drvdata = {
+ .variant = {
+ [0] = &gsc_v_100_variant,
+ [1] = &gsc_v_100_variant,
+ [2] = &gsc_v_100_variant,
+ },
+ .num_entities = 3,
+ .clk_names = { "pclk", "aclk", "aclk_xiu", "aclk_gsclbend" },
+ .num_clocks = 4,
};
static const struct of_device_id exynos_gsc_match[] = {
@@ -972,6 +983,10 @@ static irqreturn_t gsc_irq_handler(int irq, void *priv)
.compatible = "samsung,exynos5-gsc",
.data = &gsc_v_100_drvdata,
},
+ {
+ .compatible = "samsung,exynos5433-gsc",
+ .data = &gsc_5433_drvdata,
+ },
{},
};
MODULE_DEVICE_TABLE(of, exynos_gsc_match);
@@ -983,6 +998,7 @@ static int gsc_probe(struct platform_device *pdev)
struct device *dev = &pdev->dev;
const struct gsc_driverdata *drv_data = of_device_get_match_data(dev);
int ret;
+ int i;
gsc = devm_kzalloc(dev, sizeof(struct gsc_dev), GFP_KERNEL);
if (!gsc)
@@ -998,6 +1014,7 @@ static int gsc_probe(struct platform_device *pdev)
return -EINVAL;
}
+ gsc->num_clocks = drv_data->num_clocks;
gsc->variant = drv_data->variant[gsc->id];
gsc->pdev = pdev;
@@ -1016,18 +1033,24 @@ static int gsc_probe(struct platform_device *pdev)
return -ENXIO;
}
- gsc->clock = devm_clk_get(dev, GSC_CLOCK_GATE_NAME);
- if (IS_ERR(gsc->clock)) {
- dev_err(dev, "failed to get clock~~~: %s\n",
- GSC_CLOCK_GATE_NAME);
- return PTR_ERR(gsc->clock);
+ for (i = 0; i < gsc->num_clocks; i++) {
+ gsc->clock[i] = devm_clk_get(dev, drv_data->clk_names[i]);
+ if (IS_ERR(gsc->clock[i])) {
+ dev_err(dev, "failed to get clock: %s\n",
+ drv_data->clk_names[i]);
+ return PTR_ERR(gsc->clock[i]);
+ }
}
- ret = clk_prepare_enable(gsc->clock);
- if (ret) {
- dev_err(&gsc->pdev->dev, "clock prepare failed for clock: %s\n",
- GSC_CLOCK_GATE_NAME);
- return ret;
+ for (i = 0; i < gsc->num_clocks; i++) {
+ ret = clk_prepare_enable(gsc->clock[i]);
+ if (ret) {
+ dev_err(dev, "clock prepare failed for clock: %s\n",
+ drv_data->clk_names[i]);
+ while (--i >= 0)
+ clk_disable_unprepare(gsc->clock[i]);
+ return ret;
+ }
}
ret = devm_request_irq(dev, res->start, gsc_irq_handler,
@@ -1062,13 +1085,15 @@ static int gsc_probe(struct platform_device *pdev)
err_v4l2:
v4l2_device_unregister(&gsc->v4l2_dev);
err_clk:
- clk_disable_unprepare(gsc->clock);
+ for (i = gsc->num_clocks - 1; i >= 0; i--)
+ clk_disable_unprepare(gsc->clock[i]);
return ret;
}
static int gsc_remove(struct platform_device *pdev)
{
struct gsc_dev *gsc = platform_get_drvdata(pdev);
+ int i;
pm_runtime_get_sync(&pdev->dev);
@@ -1076,7 +1101,8 @@ static int gsc_remove(struct platform_device *pdev)
v4l2_device_unregister(&gsc->v4l2_dev);
vb2_dma_contig_clear_max_seg_size(&pdev->dev);
- clk_disable_unprepare(gsc->clock);
+ for (i = 0; i < gsc->num_clocks; i++)
+ clk_disable_unprepare(gsc->clock[i]);
pm_runtime_put_noidle(&pdev->dev);
@@ -1126,12 +1152,18 @@ static int gsc_runtime_resume(struct device *dev)
{
struct gsc_dev *gsc = dev_get_drvdata(dev);
int ret = 0;
+ int i;
pr_debug("gsc%d: state: 0x%lx\n", gsc->id, gsc->state);
- ret = clk_prepare_enable(gsc->clock);
- if (ret)
- return ret;
+ for (i = 0; i < gsc->num_clocks; i++) {
+ ret = clk_prepare_enable(gsc->clock[i]);
+ if (ret) {
+ while (--i >= 0)
+ clk_disable_unprepare(gsc->clock[i]);
+ return ret;
+ }
+ }
gsc_hw_set_sw_reset(gsc);
gsc_wait_reset(gsc);
@@ -1144,10 +1176,14 @@ static int gsc_runtime_suspend(struct device *dev)
{
struct gsc_dev *gsc = dev_get_drvdata(dev);
int ret = 0;
+ int i;
ret = gsc_m2m_suspend(gsc);
- if (!ret)
- clk_disable_unprepare(gsc->clock);
+ if (ret)
+ return ret;
+
+ for (i = gsc->num_clocks - 1; i >= 0; i--)
+ clk_disable_unprepare(gsc->clock[i]);
pr_debug("gsc%d: state: 0x%lx\n", gsc->id, gsc->state);
return ret;
diff --git a/drivers/media/platform/exynos-gsc/gsc-core.h b/drivers/media/platform/exynos-gsc/gsc-core.h
index e5aa8f4..696217e 100644
--- a/drivers/media/platform/exynos-gsc/gsc-core.h
+++ b/drivers/media/platform/exynos-gsc/gsc-core.h
@@ -33,6 +33,7 @@
#define GSC_SHUTDOWN_TIMEOUT ((100*HZ)/1000)
#define GSC_MAX_DEVS 4
+#define GSC_MAX_CLOCKS 4
#define GSC_M2M_BUF_NUM 0
#define GSC_MAX_CTRL_NUM 10
#define GSC_SC_ALIGN_4 4
@@ -307,6 +308,8 @@ struct gsc_variant {
*/
struct gsc_driverdata {
struct gsc_variant *variant[GSC_MAX_DEVS];
+ const char *clk_names[GSC_MAX_CLOCKS];
+ int num_clocks;
int num_entities;
};
@@ -330,7 +333,8 @@ struct gsc_dev {
struct platform_device *pdev;
struct gsc_variant *variant;
u16 id;
- struct clk *clock;
+ int num_clocks;
+ struct clk *clock[GSC_MAX_CLOCKS];
void __iomem *regs;
wait_queue_head_t irq_queue;
struct gsc_m2m_device m2m;
--
1.9.1
^ permalink raw reply related
* Re: [PATCH 2/4] perf hist browser: Show folded sign properly on --hierarchy
From: Arnaldo Carvalho de Melo @ 2016-11-09 14:29 UTC (permalink / raw)
To: Namhyung Kim
Cc: Ingo Molnar, Peter Zijlstra, Jiri Olsa, LKML, Markus Trippelsdorf
In-Reply-To: <20161109142811.GF12125@kernel.org>
Em Wed, Nov 09, 2016 at 11:28:11AM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Tue, Nov 08, 2016 at 10:08:31PM +0900, Namhyung Kim escreveu:
> > When horizontall scrolling is used in hierarchy mode, the folded signed
> > disappears at the right most column.
>
> Humm, this indeed shows the '+' folded signal after pressing ->, but it
> moves from the first to the third column :-\
>
> > +++ b/tools/perf/ui/browsers/hists.c
> > @@ -1381,8 +1381,14 @@ static int hist_browser__show_hierarchy_entry(struct hist_browser *browser,
> > }
> >
> > perf_hpp_list__for_each_format(entry->hpp_list, fmt) {
> > - ui_browser__write_nstring(&browser->b, "", 2);
> > - width -= 2;
Also why move this invariant to both branches?
> > + if (first) {
> > + ui_browser__printf(&browser->b, "%c ", folded_sign);
> > + width -= 2;
> > + first = false;
> > + } else {
> > + ui_browser__write_nstring(&browser->b, "", 2);
> > + width -= 2;
> > + }
> >
> > /*
> > * No need to call hist_entry__snprintf_alignment()
> > --
> > 2.10.1
^ permalink raw reply
* Btrfs progs pre-release 4.8.3-rc1
From: David Sterba @ 2016-11-09 14:29 UTC (permalink / raw)
To: linux-btrfs; +Cc: clm
Hi,
a pre-release has been tagged. Handful of fixes and lots of cleanups.
ETA for 4.8.3 is in +2 days (2016-11-11).
The queued changes for the 4.9 release are: check low-mem mode updates and send
stream dump, plus the usual small stuff.
Changes:
* check:
* support for clearing space cache (v1)
* size reduction of inode backref structure
* send:
* fix handling of multiple snapshots (-p and -c options)
* transfer buffer increased (should reduce number of context switches)
* reuse existing file for output (-f), eg. when root cannot create files (NFS)
* dump-tree:
* print missing items for various structures
* new: dev stats, balance status item
* sync key names with kernel (the persistent items)
* subvol show: now able to print the toplevel subvolume -- the creation time
might be wrong though
* mkfs: store the creation time of toplevel root inode
* build: travis CI for devel
* other:
* lots of cleanups and refactoring
* switched to on-stack path structure
* fixes from coverity, asan, ubsan
* new tests
Tarballs: https://www.kernel.org/pub/linux/kernel/people/kdave/btrfs-progs/
Git: git://git.kernel.org/pub/scm/linux/kernel/git/kdave/btrfs-progs.git
Shortlog:
David Sterba (134):
btrfs-progs: tests: switch to dump- commands from inspect
btrfs-progs: convert: switch more messages to common helpers
btrfs-progs: qgroups show: handle errors when resolving root id
btrfs-progs: remove unused function btrfs_get_path_rootid
btrfs-progs: rename lookup_ino_rootid
btrfs-progs: use existing rootid resolving helper in btrfs_list_get_path_rootid
btrfs-progs: opencode trivial helper __free_all_subvolumn
btrfs-progs: remove leading underscores from several helper
btrfs-progs: use symbolic tree name when searching
btrfs-progs: list: constify prefix arugment
btrfs-progs: use enum for list layout type
btrfs-progs: list: rename some helpers
btrfs-progs: list: switch to common message helpers
btrfs-progs: subvol list: setup list filters later
btrfs-progs: return void from btrfs_list_setup_filter
btrfs-progs: subvol list: cleanup layout argument setup
btrfs-progs: subvol list: remove useless comments
btrfs-progs: subvol list: simplify value assignments
btrfs-progs: subvol list: consilidate naming of otime varaibles
btrfs-progs: subvol list: add simplified helper for adding root backrefs
btrfs-progs: subvol list: consolidate uuid types accross functions
btrfs-progs: remove trivial helper root_lookup_init
btrfs-progs: subvol list: remove ugly goto construct
btrfs-progs: subvol list: better error message if subvol insertion fails
btrfs-progs: subvol show: print more details about toplevel subvolume
btrfs-progs: dump-tree: print missing dev_item data
btrfs-progs: dump-tree: print missing chunk data
btrfs-progs: dump-tree: print missing dev_extent data
btrfs-progs: dump-tree: factor inode_item dump to function
btrfs-progs: dump-tree: add helper to print timespec
btrfs-progs: dump-tree: print missing inode_item data
btrfs-progs: dump-tree: print missing dir_item data
btrfs-progs: dump-tree: print more root_item data
btrfs-progs: dump-tree: print missing data for file extent item
btrfs-progs: mkfs: store creation time of the toplevel subvolume
btrfs-progs: introduce key type for persistent temporary items
btrfs-progs: print-tree: extract offset from the item key
btrfs-progs: introduce key type for persistent permanent items
btrfs-progs: switch dev stats item to the permanent item key
btrfs-progs: teach print_leaf about permanent item subtypes
btrfs-progs: teach print_leaf about temporary item subtypes
btrfs-progs: add balance status structures
btrfs-progs: dump-tree: print balance status item
btrfs-progs: add dev stats on-disk structure
btrfs-progs: dump-tree: print dev stats
btrfs-progs: dump-tree: consolidate data key names
btrfs-progs: remove unused parameter from print_inode_item
btrfs-progs: dump-tree: pass item size instead of item
btrfs-progs: dump-tree: return void from print_* functions
btrfs-progs: dump-tree: simplify and fix check for empty uuid
btrfs-progs: dump-tree: constify char argument in print_root_ref
btrfs-progs: dump-tree: add untyped item ptr helper and use it
btrfs-progs: dump-tree: rename extent buffer variable in btrfs_print_leaf
btrfs-progs: dump-tree: move variable declarations closer to their use
btrfs-progs: dump-tree: move remaining item variables to the scope of use
btrfs-progs: dump-tree: cleanup types for item number iteration
btrfs-progs: dump-tree: convert key-to-string to table
btrfs-progs: dump-tree: convert dir-item-to-string to table
btrfs-progs: tests: add test for multi-subvolume send from parent
btrfs-progs: send: constify some arugments
btrfs-progs: send: increase size of transfer buffer
btrfs-progs: send: use proper type for read result, and rename the variable
btrfs-progs: send: clean types in write_buf
btrfs-progs: send: cleanup, rename some variables in dump_thread
btrfs-progs: send: cleanup, rename send context variables
btrfs-progs: send: cleanup use of ctransid delta temporary variable in find_good_parent
btrfs-progs: check: unify type for inode_backref::filetype
btrfs-progs: check: unify type for inode_backref::itemtype
btrfs-progs: check: reorder fields in inode_backref for better packing
btrfs-progs: mkfs: use const char for unmodified members of directory_name_entry
btrfs-progs: mkfs: constify some char parameters
btrfs-progs: reduce size of btrfs_path, locks are not used
btrfs-progs: reduce size of btrfs_path::reada
btrfs-progs: reduce size of btrfs_path::lowest_level
btrfs-progs: mkfs: use on-stack path buffer in cleanup_temp_chunks
btrfs-progs: convert: use on-stack path buffer in record_file_blocks
btrfs-progs: convert: use on-stack path buffer in create_image
btrfs-progs: convert: use on-stack path buffer in link_subvol
btrfs-progs: image: use on-stack path buffer in create_metadump
btrfs-progs: image: use on-stack path buffer in fixup_devices
btrfs-progs: image: add symbolic constant for max thread count
btrfs-progs: image: use fixed-size array for worker thread pointers
btrfs-progs: image: use embedded array for metadump cluster buffer
btrfs-progs: dump-tree: use new names for obsoleted keys
btrfs-progs: fi du: don't redefine standard macro/function
btrfs-progs: utils: remove useless check in make_btrfs
btrfs-progs: qgroup: use on-stack path buffer in repair_qgroup_info
btrfs-progs: qgroup: use on-stack path buffer in repair_qgroup_status
btrfs-progs: convert bitfield to separate variables in btrfs_path
btrfs-progs: check: use on-stack path buffer in add_missing_dir_index
btrfs-progs: check: use on-stack path buffer in delete_dir_index
btrfs-progs: check: use on-stack path buffer in find_normal_file_extent
btrfs-progs: check: use on-stack path buffer in try_repair_inode
btrfs-progs: check: use on-stack path buffer in repair_btree
btrfs-progs: check: use on-stack path buffer in try_to_fix_bad_block
btrfs-progs: check: use on-stack path buffer in verify_space_cache
btrfs-progs: check: use on-stack path buffer in check_extent_csums
btrfs-progs: check: use on-stack path buffer in check_extent_exists
btrfs-progs: check: use on-stack path buffer in delete_duplicate_records
btrfs-progs: check: use on-stack path buffer in record_orphan_data_extents
btrfs-progs: check: use on-stack path buffer in fixup_extent_refs
btrfs-progs: check: use on-stack path buffer in fixup_extent_flags
btrfs-progs: check: use on-stack path buffer in reset_block_groups
btrfs-progs: check: use on-stack path buffer in reset_balance
btrfs-progs: check: use on-stack path buffer in recow_extent_buffer
btrfs-progs: check: use on-stack path buffer in delete_bad_item
btrfs-progs: check: use on-stack path buffer in fill_csum_tree_from_one_fs_root
btrfs-progs: check: use on-stack path buffer in fill_csum_tree_from_fs
btrfs-progs: check: use on-stack path buffer in fill_csum_tree_from_extent
btrfs-progs: check: use on-stack path buffer in build_roots_info_cache
btrfs-progs: check: use on-stack path buffer in repair_root_items
btrfs-progs: tree-stats: use on-stack path buffer in calc_root_size
btrfs-progs: restore: use on-stack path buffer in set_file_xattrs
btrfs-progs: restore: use on-stack path buffer in copy_metadata
btrfs-progs: restore: use on-stack path buffer in copy_file
btrfs-progs: restore: use on-stack path buffer in copy_symlink
btrfs-progs: restore: use on-stack path buffer in search_dir
btrfs-progs: restore: use on-stack path buffer in do_list_roots
btrfs-progs: restore: use on-stack path buffer in find_first_dir
btrfs-progs: check: remove unused variable in record_extent
btrfs-progs: chunk-recover: use on-stack path buffer in rebuild_block_group
btrfs-progs: btrfstune: use on-stack path buffer in change_extents_uuid
btrfs-progs: btrfstune: use on-stack path buffer in change_devices_uuid
btrfs-progs: mkfs: simplify checks in directory_select
btrfs-progs: docs: update mkfs help string and manual page
btrfs-progs: fix unaligned u64 access in btrfs_alloc_data_chunk
btrfs-progs: fix search tree v2 ioctl detection
btrfs-progs: tests: teach scan-results about more errors
btrfs-progs: crc32: use fallback implementation for unaligned buffers
btrfs-progs: use correct type for device id iteration in get_fs_info
btrfs-progs: send: check for output file existence before creating
btrfs-progs: tests: teach extract_image about packed streams
btrfs-progs: update CHANGES for v4.8.3
Btrfs progs v4.8.3-rc1
Qu Wenruo (5):
btrfs-progs: check: add support to clear v1 free space cache
btrfs-progs: fsck-tests: Check if clear space cache works
btrfs-progs: Ignore clang complete file
btrfs-progs: remove send-test tool
btrfs-progs: Fix memory leak in write_raid56_with_parity
Roman Lebedev (1):
btrfs-progs: Add travis CI build support
Tsutomu Itoh (3):
btrfs-progs: send: fix handling of multiple snapshots (-p option)
btrfs-progs: send: fix handling of -c option
btrfs-progs: tests: add checking of send multiple clone source option
^ permalink raw reply
* [PATCH 1/2] exynos-gsc: Enable driver on ARCH_EXYNOS
From: Marek Szyprowski @ 2016-11-09 14:29 UTC (permalink / raw)
To: linux-media, linux-samsung-soc
Cc: Marek Szyprowski, Sylwester Nawrocki, Krzysztof Kozlowski,
Bartlomiej Zolnierkiewicz, Javier Martinez Canillas
In-Reply-To: <1478701778-29452-1-git-send-email-m.szyprowski@samsung.com>
This driver can be also used on Exynos5433, which is ARM64-based
platform, which selects only ARCH_EXYNOS symbol.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
---
drivers/media/platform/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 754edbf1..90ae790 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -266,7 +266,7 @@ config VIDEO_MX2_EMMAPRP
config VIDEO_SAMSUNG_EXYNOS_GSC
tristate "Samsung Exynos G-Scaler driver"
depends on VIDEO_DEV && VIDEO_V4L2
- depends on ARCH_EXYNOS5 || COMPILE_TEST
+ depends on ARCH_EXYNOS || COMPILE_TEST
depends on HAS_DMA
select VIDEOBUF2_DMA_CONTIG
select V4L2_MEM2MEM_DEV
--
1.9.1
^ permalink raw reply related
* [qemu-mainline test] 102049: regressions - FAIL
From: osstest service owner @ 2016-11-09 14:29 UTC (permalink / raw)
To: xen-devel, osstest-admin
flight 102049 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102049/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt 11 guest-start fail REGR. vs. 101909
test-amd64-i386-libvirt-xsm 11 guest-start fail REGR. vs. 101909
test-amd64-i386-libvirt 11 guest-start fail REGR. vs. 101909
test-amd64-i386-libvirt-pair 20 guest-start/debian fail REGR. vs. 101909
test-amd64-amd64-libvirt-xsm 11 guest-start fail REGR. vs. 101909
test-amd64-amd64-libvirt-vhd 9 debian-di-install fail REGR. vs. 101909
test-amd64-amd64-xl-qcow2 9 debian-di-install fail REGR. vs. 101909
test-amd64-amd64-libvirt-pair 20 guest-start/debian fail REGR. vs. 101909
test-armhf-armhf-libvirt-xsm 11 guest-start fail REGR. vs. 101909
test-armhf-armhf-xl-vhd 9 debian-di-install fail REGR. vs. 101909
test-armhf-armhf-libvirt 11 guest-start fail REGR. vs. 101909
test-armhf-armhf-libvirt-raw 9 debian-di-install fail REGR. vs. 101909
test-armhf-armhf-libvirt-qcow2 9 debian-di-install fail REGR. vs. 101909
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 101909
test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 101909
test-armhf-armhf-xl-rtds 15 guest-start/debian.repeat fail like 101909
test-amd64-amd64-xl-rtds 9 debian-install fail like 101909
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass
test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass
test-armhf-armhf-xl-xsm 12 migrate-support-check fail never pass
test-armhf-armhf-xl-xsm 13 saverestore-support-check fail never pass
test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass
test-armhf-armhf-xl 12 migrate-support-check fail never pass
test-armhf-armhf-xl 13 saverestore-support-check fail never pass
test-armhf-armhf-xl-arndale 12 migrate-support-check fail never pass
test-armhf-armhf-xl-arndale 13 saverestore-support-check fail never pass
test-armhf-armhf-xl-cubietruck 12 migrate-support-check fail never pass
test-armhf-armhf-xl-cubietruck 13 saverestore-support-check fail never pass
test-armhf-armhf-xl-credit2 12 migrate-support-check fail never pass
test-armhf-armhf-xl-credit2 13 saverestore-support-check fail never pass
test-armhf-armhf-xl-multivcpu 12 migrate-support-check fail never pass
test-armhf-armhf-xl-multivcpu 13 saverestore-support-check fail never pass
test-armhf-armhf-xl-rtds 12 migrate-support-check fail never pass
test-armhf-armhf-xl-rtds 13 saverestore-support-check fail never pass
version targeted for testing:
qemuu 207faf24c58859f5240f66bf6decc33b87a1776e
baseline version:
qemuu 199a5bde46b0eab898ab1ec591f423000302569f
Last test of basis 101909 2016-11-03 23:21:40 Z 5 days
Failing since 101943 2016-11-04 22:40:48 Z 4 days 7 attempts
Testing same since 102031 2016-11-08 07:59:22 Z 1 days 2 attempts
------------------------------------------------------------
People who touched revisions under test:
Christian Borntraeger <borntraeger@de.ibm.com>
Cornelia Huck <cornelia.huck@de.ibm.com>
Julian Brown <julian@codesourcery.com>
Marcin Krzeminski <marcin.krzeminski@nokia.com>
Olaf Hering <olaf@aepfle.de>
Peter Maydell <peter.maydell@linaro.org>
Prasad J Pandit <pjp@fedoraproject.org>
Sander Eikelenboom <linux@eikelenboom.it>
Stefan Hajnoczi <stefanha@redhat.com>
Stefano Stabellini <sstabellini@kernel.org>
Thomas Huth <thuth@redhat.com>
Wei Liu <wei.liu2@citrix.com>
jobs:
build-amd64-xsm pass
build-armhf-xsm pass
build-i386-xsm pass
build-amd64 pass
build-armhf pass
build-i386 pass
build-amd64-libvirt pass
build-armhf-libvirt pass
build-i386-libvirt pass
build-amd64-pvops pass
build-armhf-pvops pass
build-i386-pvops pass
test-amd64-amd64-xl pass
test-armhf-armhf-xl pass
test-amd64-i386-xl pass
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass
test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm pass
test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass
test-amd64-amd64-libvirt-xsm fail
test-armhf-armhf-libvirt-xsm fail
test-amd64-i386-libvirt-xsm fail
test-amd64-amd64-xl-xsm pass
test-armhf-armhf-xl-xsm pass
test-amd64-i386-xl-xsm pass
test-amd64-amd64-qemuu-nested-amd fail
test-amd64-amd64-xl-pvh-amd fail
test-amd64-i386-qemuu-rhel6hvm-amd pass
test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass
test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
test-amd64-i386-freebsd10-amd64 pass
test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
test-amd64-i386-xl-qemuu-ovmf-amd64 pass
test-amd64-amd64-xl-qemuu-win7-amd64 fail
test-amd64-i386-xl-qemuu-win7-amd64 fail
test-armhf-armhf-xl-arndale pass
test-amd64-amd64-xl-credit2 pass
test-armhf-armhf-xl-credit2 pass
test-armhf-armhf-xl-cubietruck pass
test-amd64-i386-freebsd10-i386 pass
test-amd64-amd64-qemuu-nested-intel pass
test-amd64-amd64-xl-pvh-intel fail
test-amd64-i386-qemuu-rhel6hvm-intel pass
test-amd64-amd64-libvirt fail
test-armhf-armhf-libvirt fail
test-amd64-i386-libvirt fail
test-amd64-amd64-xl-multivcpu pass
test-armhf-armhf-xl-multivcpu pass
test-amd64-amd64-pair pass
test-amd64-i386-pair pass
test-amd64-amd64-libvirt-pair fail
test-amd64-i386-libvirt-pair fail
test-amd64-amd64-amd64-pvgrub pass
test-amd64-amd64-i386-pvgrub pass
test-amd64-amd64-pygrub pass
test-armhf-armhf-libvirt-qcow2 fail
test-amd64-amd64-xl-qcow2 fail
test-armhf-armhf-libvirt-raw fail
test-amd64-i386-xl-raw pass
test-amd64-amd64-xl-rtds fail
test-armhf-armhf-xl-rtds fail
test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 pass
test-amd64-amd64-libvirt-vhd fail
test-armhf-armhf-xl-vhd fail
test-amd64-amd64-xl-qemuu-winxpsp3 pass
test-amd64-i386-xl-qemuu-winxpsp3 pass
------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images
Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs
Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
Not pushing.
------------------------------------------------------------
commit 207faf24c58859f5240f66bf6decc33b87a1776e
Merge: 0ea3eb6 9706e01
Author: Stefan Hajnoczi <stefanha@redhat.com>
Date: Mon Nov 7 14:02:15 2016 +0000
Merge remote-tracking branch 'pm215/tags/pull-target-arm-20161107' into staging
target-arm queue:
* bitbang_i2c: Handle NACKs from devices
* Fix corruption of CPSR when SCTLR.EE is set
* nvic: set pending status for not active interrupts
* char: cadence: check baud rate generator and divider values
# gpg: Signature made Mon 07 Nov 2016 10:43:07 AM GMT
# gpg: using RSA key 0x3C2525ED14360CDE
# gpg: Good signature from "Peter Maydell <peter.maydell@linaro.org>"
# gpg: aka "Peter Maydell <pmaydell@gmail.com>"
# gpg: aka "Peter Maydell <pmaydell@chiark.greenend.org.uk>"
# Primary key fingerprint: E1A5 C593 CD41 9DE2 8E83 15CF 3C25 25ED 1436 0CDE
* pm215/tags/pull-target-arm-20161107:
hw/i2c/bitbang_i2c: Handle NACKs from devices
Fix corruption of CPSR when SCTLR.EE is set
nvic: set pending status for not active interrupts
char: cadence: check baud rate generator and divider values
Message-id: 1478515653-6361-1-git-send-email-peter.maydell@linaro.org
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
commit 0ea3eb65e84c5d4665dbeee3e3e5ed56b43f7648
Author: Cornelia Huck <cornelia.huck@de.ibm.com>
Date: Wed Nov 2 17:21:03 2016 +0100
s390x/kvm: fix run_on_cpu sigp conversions
Commit 14e6fe12a ("*_run_on_cpu: introduce run_on_cpu_data type")
attempted to convert all users of run_on_cpu to use the new
run_on_cpu_data type. It missed to change the called sigp_* routines,
however. Fix that.
Fixes: 14e6fe12a ("*_run_on_cpu: introduce run_on_cpu_data type")
Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
Acked-by: Christian Borntraeger <borntraeger@de.ibm.com>
Message-id: 20161102162103.66480-1-cornelia.huck@de.ibm.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
commit 9706e0162d2405218fd7376ffdf13baed8569a4b
Author: Peter Maydell <peter.maydell@linaro.org>
Date: Mon Oct 24 19:12:29 2016 +0100
hw/i2c/bitbang_i2c: Handle NACKs from devices
If the guest attempts to talk to a nonexistent device over i2c,
the i2c_start_transfer() function will return non-zero, indicating
that the bus is signalling a NACK. Similarly, if the i2c_send()
function returns nonzero then the target device returned a NACK.
Handle this possibility in the bitbang_i2c code, by returning
the state machine to the STOPPED state and returning the NACK
bit to the guest.
This bit of missing functionality was spotted by Coverity
(it noticed that we weren't checking the return value from
i2c_start_transfer()).
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Message-id: 1477332749-27098-1-git-send-email-peter.maydell@linaro.org
commit 3823b9db77e753041c04c161ac9f4d4cfc661520
Author: Julian Brown <julian@codesourcery.com>
Date: Mon Nov 7 10:00:24 2016 +0000
Fix corruption of CPSR when SCTLR.EE is set
Fix a typo in arm_cpu_do_interrupt_aarch32 (OR'ing with ~CPSR_E
instead of CPSR_E) which meant that when we took an interrupt with
SCTLR.EE set we would corrupt the CPSR.
Signed-off-by: Julian Brown <julian@codesourcery.com>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
commit 3bc4b52ccd7754de4fb177871f1c5eaaa61ec7ef
Author: Marcin Krzeminski <marcin.krzeminski@nokia.com>
Date: Mon Nov 7 10:00:24 2016 +0000
nvic: set pending status for not active interrupts
According to ARM DUI 0552A 4.2.10. NVIC set pending status
also for disabled interrupts. Correct the logic for
when interrupts are marked pending both on input level
transition and when interrupts are dismissed, to match
the NVIC behaviour rather than the 11MPCore GIC.
Signed-off-by: Marcin Krzeminski <marcin.krzeminski@nokia.com>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
commit 6e29651c5e3a0e0336818574f273b3f6ecea491d
Author: Prasad J Pandit <pjp@fedoraproject.org>
Date: Mon Nov 7 10:00:24 2016 +0000
char: cadence: check baud rate generator and divider values
The Cadence UART device emulator calculates speed by dividing the
baud rate by a 'baud rate generator' & 'baud rate divider' value.
The device specification defines these register values to be
non-zero and within certain limits. Add checks for these limits
to avoid errors like divide by zero.
Reported-by: Huawei PSIRT <psirt@huawei.com>
Signed-off-by: Prasad J Pandit <pjp@fedoraproject.org>
Reviewed-by: Alistair Francis <alistair.francis@xilinx.com>
Message-id: 1477596278-1470-1-git-send-email-ppandit@redhat.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
commit 9226682a401f34b10fd79dfe17ba334da0800747
Merge: 199a5bd 021746c
Author: Stefan Hajnoczi <stefanha@redhat.com>
Date: Fri Nov 4 09:26:24 2016 +0000
Merge remote-tracking branch 'sstabellini/tags/xen-20161102-tag' into staging
Xen 2016/11/02
# gpg: Signature made Wed 02 Nov 2016 07:28:40 PM GMT
# gpg: using RSA key 0x894F8F4870E1AE90
# gpg: Good signature from "Stefano Stabellini <sstabellini@kernel.org>"
# gpg: aka "Stefano Stabellini <stefano.stabellini@eu.citrix.com>"
# Primary key fingerprint: D04E 33AB A51F 67BA 07D3 0AEA 894F 8F48 70E1 AE90
* sstabellini/tags/xen-20161102-tag:
PCMachineState: introduce acpi_build_enabled field
hw/xen/xen_pvdev: Include qemu/log.h for qemu_log_vprintf()
Message-id: alpine.DEB.2.10.1611021227530.19454@sstabellini-ThinkPad-X260
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
commit 021746c131cdfeab9d82ff918795a9f18d20d7ae
Author: Wei Liu <wei.liu2@citrix.com>
Date: Tue Nov 1 17:44:16 2016 +0000
PCMachineState: introduce acpi_build_enabled field
Introduce this field to control whether ACPI build is enabled by a
particular machine or accelerator.
It defaults to true if the machine itself supports ACPI build. Xen
accelerator will disable it because Xen is in charge of building ACPI
tables for the guest.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
Tested-by: Sander Eikelenboom <linux@eikelenboom.it>
commit b5863634181a655bd2201cf51a363ac94a43f145
Author: Thomas Huth <thuth@redhat.com>
Date: Wed Nov 2 11:19:18 2016 +0100
hw/xen/xen_pvdev: Include qemu/log.h for qemu_log_vprintf()
Olaf Hering reported a build failure due to an undefined reference
to 'qemu_log_vprintf'. Explicitely including qemu/log.h seems to
fix the issue.
Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
Tested-by: Olaf Hering <olaf@aepfle.de>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply
* Re: [v3 4/5] vfio: implement APIs to set/put kvm to/from vfio group
From: Paolo Bonzini @ 2016-11-09 14:28 UTC (permalink / raw)
To: Xiao Guangrong, Jike Song
Cc: Alex Williamson, kwankhede, cjia, kevin.tian, kvm
In-Reply-To: <56d1a231-d989-d36d-d374-4188a2451db9@linux.intel.com>
On 09/11/2016 15:00, Xiao Guangrong wrote:
>>
>> The *group* driver doesn't need it indeed. The mdev vendor driver
>> however does, so it will use kvm_get_kvm under its own mutex. That is:
>
> Yes, own mutex is definitely can work.:) It is vendor driver internal
> operation and it depends on the internal implementation.
>
> My idea is that we can make sure the KVM instance is valid before calling
> DETACH callback. So if we can properly release all the resource associated
> with the kvm instance in this callback, it is okay without additional kvm
> ref.
That should work if they have their own mutex, but please add a comment. :)
Paolo
^ permalink raw reply
* Re: [PATCH] x86/vm_event: Added support for VM_EVENT_REASON_INTERRUPT
From: Razvan Cojocaru @ 2016-11-09 14:28 UTC (permalink / raw)
To: Jan Beulich
Cc: kevin.tian, sstabellini, suravee.suthikulpanit, andrew.cooper3,
xen-devel, julien.grall, tamas, jun.nakajima, boris.ostrovsky
In-Reply-To: <582313E5020000780011D518@prv-mh.provo.novell.com>
On 11/09/2016 01:17 PM, Jan Beulich wrote:
>>>> On 09.11.16 at 10:42, <rcojocaru@bitdefender.com> wrote:
>> +static bool svm_get_pending_event(struct vcpu *v, struct hvm_trap *info)
>> +{
>> + struct vmcb_struct *vmcb = v->arch.hvm_svm.vmcb;
>> +
>> + if ( vmcb->eventinj.fields.v )
>> + return false;
>> +
>> + info->vector = vmcb->eventinj.fields.vector;
>> + info->type = vmcb->eventinj.fields.type;
>> + info->error_code = vmcb->eventinj.fields.errorcode;
>> + info->cr2 = v->arch.hvm_vcpu.guest_cr[2];
>
> I'd prefer for this last part to be put into generic code (i.e. the
> wrapper).
Actually, doing this:
static inline bool hvm_get_pending_event(struct vcpu *v, struct hvm_trap
*info)
{
info->cr2 = v->arch.hvm_vcpu.guest_cr[2];
return hvm_funcs.get_pending_event(v, info);
}
leads to "error: dereferencing pointer to incomplete type" about v->, so
to do this an additional #include will be necessary. Is that acceptable?
Thanks,
Razvan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply
* Re: [PATCH 2/4] perf hist browser: Show folded sign properly on --hierarchy
From: Arnaldo Carvalho de Melo @ 2016-11-09 14:28 UTC (permalink / raw)
To: Namhyung Kim
Cc: Ingo Molnar, Peter Zijlstra, Jiri Olsa, LKML, Markus Trippelsdorf
In-Reply-To: <20161108130833.9263-3-namhyung@kernel.org>
Em Tue, Nov 08, 2016 at 10:08:31PM +0900, Namhyung Kim escreveu:
> When horizontall scrolling is used in hierarchy mode, the folded signed
> disappears at the right most column.
Humm, this indeed shows the '+' folded signal after pressing ->, but it
moves from the first to the third column :-\
- Arnaldo
> Signed-off-by: Namhyung Kim <namhyung@kernel.org>
> ---
> tools/perf/ui/browsers/hists.c | 10 ++++++++--
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/tools/perf/ui/browsers/hists.c b/tools/perf/ui/browsers/hists.c
> index fe5677ccbc22..7722ad311318 100644
> --- a/tools/perf/ui/browsers/hists.c
> +++ b/tools/perf/ui/browsers/hists.c
> @@ -1381,8 +1381,14 @@ static int hist_browser__show_hierarchy_entry(struct hist_browser *browser,
> }
>
> perf_hpp_list__for_each_format(entry->hpp_list, fmt) {
> - ui_browser__write_nstring(&browser->b, "", 2);
> - width -= 2;
> + if (first) {
> + ui_browser__printf(&browser->b, "%c ", folded_sign);
> + width -= 2;
> + first = false;
> + } else {
> + ui_browser__write_nstring(&browser->b, "", 2);
> + width -= 2;
> + }
>
> /*
> * No need to call hist_entry__snprintf_alignment()
> --
> 2.10.1
^ permalink raw reply
* Re: [Qemu-devel] [PATCH 0/2] Current Travis patches
From: Stefan Hajnoczi @ 2016-11-09 14:27 UTC (permalink / raw)
To: Alex Bennée; +Cc: qemu-devel
In-Reply-To: <20161109121157.30815-1-alex.bennee@linaro.org>
[-- Attachment #1: Type: text/plain, Size: 949 bytes --]
On Wed, Nov 09, 2016 at 12:11:55PM +0000, Alex Bennée wrote:
> Hi,
>
> Not much here but since Daniel sped up the build by trimming out most
> of the clang mirrors of gcc I added one additional clang build which
> uses the current stable branch. Hopefully this still gives us enough
> coverage.
>
> As this speeds up testing on merges and doesn't affect QEMU code
> itself I'll ask if we can merge this in the 2.8 cycle? If so I'll send
> a pull request in a few days assuming no objection to the patches
> themselves.
>
> Alex Bennée (1):
> travis: add Trusty with clang stable build
>
> Daniel P. Berrange (1):
> travis: trim out most clang builds
>
> .travis.yml | 24 +++++++++++++++++++++++-
> 1 file changed, 23 insertions(+), 1 deletion(-)
Despite .travis.yml not affecting the QEMU binary I want to stick to the
"bug fixes only" soft freeze policy for the 2.8 release. Please queue
it for 2.9.
Stefan
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
^ permalink raw reply
* Re: [drm-intel:topic/drm-misc 1/2] backtracetest.c:undefined reference to `save_stack_trace'
From: Matthew Auld @ 2016-11-09 14:26 UTC (permalink / raw)
To: Chris Wilson, kbuild test robot, kbuild-all,
Intel Graphics Development, ML dri-devel, Daniel Vetter
In-Reply-To: <20161109141238.GA7229@nuc-i3427.alporthouse.com>
On 9 November 2016 at 14:12, Chris Wilson <chris@chris-wilson.co.uk> wrote:
> On Wed, Nov 09, 2016 at 10:01:37PM +0800, kbuild test robot wrote:
>> tree: git://anongit.freedesktop.org/drm-intel topic/drm-misc
>> head: 77d150b90d58ae6a43bf67af28feb26384d06cd6
>> commit: cd456f8d06d2036e1e013136c3fbf5721d04f6d7 [1/2] drm: Restrict stackdepot usage to builtin drm.ko
>> config: m68k-allyesconfig (attached as .config)
>> compiler: m68k-linux-gcc (GCC) 4.9.0
>> reproduce:
>> wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
>> chmod +x ~/bin/make.cross
>> git checkout cd456f8d06d2036e1e013136c3fbf5721d04f6d7
>> # save the attached .config to linux build tree
>> make.cross ARCH=m68k
>>
>> All errors (new ones prefixed by >>):
>>
>> kernel/built-in.o: In function `backtrace_regression_test':
>> >> backtracetest.c:(.text+0x550d4): undefined reference to `save_stack_trace'
>> mm/built-in.o: In function `set_track':
>> slub.c:(.text+0x41414): undefined reference to `save_stack_trace'
>> drivers/built-in.o: In function `save_stack.isra.7':
>> >> drm_mm.c:(.text+0x16be82): undefined reference to `save_stack_trace'
>
> Anyone got an idea for this one? m68k is missing save_stack_trace().
> There's no arch CONFIG_HAS_SAVE_STACK_TRACE, it looks like an oversight
> in arch/m68k.
STACKTRACE_SUPPORT ?
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [Qemu-devel] [PATCH v6 00/10] Convert msix_init() to error
From: Marcel Apfelbaum @ 2016-11-09 14:25 UTC (permalink / raw)
To: Cao jin, qemu-devel
Cc: Jiri Pirko, Gerd Hoffmann, Dmitry Fleytman, Jason Wang,
Michael S. Tsirkin, Hannes Reinecke, Paolo Bonzini,
Alex Williamson, Markus Armbruster
In-Reply-To: <1478311649-22027-1-git-send-email-caoj.fnst@cn.fujitsu.com>
On 11/05/2016 04:07 AM, Cao jin wrote:
> v6 changelog:
> 1. re-spin vfio-pci related code on patch 3: for -ENOTSUP, report & free Error,
> for other error, propagate the Error. (Marcel)
>
> CC: Jiri Pirko <jiri@resnulli.us>
> CC: Gerd Hoffmann <kraxel@redhat.com>
> CC: Dmitry Fleytman <dmitry@daynix.com>
> CC: Jason Wang <jasowang@redhat.com>
> CC: Michael S. Tsirkin <mst@redhat.com>
> CC: Hannes Reinecke <hare@suse.de>
> CC: Paolo Bonzini <pbonzini@redhat.com>
> CC: Alex Williamson <alex.williamson@redhat.com>
> CC: Markus Armbruster <armbru@redhat.com>
> CC: Marcel Apfelbaum <marcel@redhat.com>
>
> Cao jin (10):
> msix: Follow CODING_STYLE
> hcd-xhci: check & correct param before using it
> pci: Convert msix_init() to Error and fix callers to check it
> megasas: change behaviour of msix switch
> hcd-xhci: change behaviour of msix switch
> megasas: remove unnecessary megasas_use_msix()
> megasas: undo the overwrites of msi user configuration
> vmxnet3: fix reference leak issue
> vmxnet3: remove unnecessary internal msix flag
> msi_init: convert assert to return -errno
>
> hw/block/nvme.c | 5 +++-
> hw/misc/ivshmem.c | 8 +++---
> hw/net/e1000e.c | 6 ++++-
> hw/net/rocker/rocker.c | 7 ++++-
> hw/net/vmxnet3.c | 46 ++++++++++++++------------------
> hw/pci/msi.c | 9 ++++---
> hw/pci/msix.c | 42 ++++++++++++++++++++++++-----
> hw/scsi/megasas.c | 49 +++++++++++++++++++---------------
> hw/usb/hcd-xhci.c | 71 ++++++++++++++++++++++++++++++--------------------
> hw/vfio/pci.c | 8 ++++--
> hw/virtio/virtio-pci.c | 11 ++++----
> include/hw/pci/msix.h | 5 ++--
> 12 files changed, 165 insertions(+), 102 deletions(-)
>
Acked-by: Marcel Apfelbaum <marcel@redhat.com>
Thanks,
Marcel
^ permalink raw reply
* [GIT PULL] kvm/page_track changes for i915 KVMGT
From: Paolo Bonzini @ 2016-11-09 14:25 UTC (permalink / raw)
To: linux-kernel, kvm
Cc: rkrcmar, intel-gfx, Daniel Wetter, Jike Song, Jani Nikula,
Zhenyu Wang
Daniel,
The following changes since commit d9092f52d7e61dd1557f2db2400ddb430e85937e:
kvm: x86: Check memopp before dereference (CVE-2016-8630) (2016-11-02 21:31:53 +0100)
are available in the git repository at:
git://git.kernel.org/pub/scm/virt/kvm/kvm.git tags/for-kvmgt
for you to fetch changes up to 871b7ef2a1850d0b435c8b324bf4a5d391adde3f:
kvm/page_track: export symbols for external usage (2016-11-04 12:13:20 +0100)
----------------------------------------------------------------
The three KVM patches that KVMGT needs.
----------------------------------------------------------------
Jike Song (2):
kvm/page_track: call notifiers with kvm_page_track_notifier_node
kvm/page_track: export symbols for external usage
Xiaoguang Chen (1):
KVM: x86: add track_flush_slot page track notifier
arch/x86/include/asm/kvm_page_track.h | 14 +++++++++++++-
arch/x86/kvm/mmu.c | 11 ++++++++++-
arch/x86/kvm/page_track.c | 31 ++++++++++++++++++++++++++++++-
arch/x86/kvm/x86.c | 2 +-
4 files changed, 54 insertions(+), 4 deletions(-)
^ permalink raw reply
* Re: [PATCH] perf/x86: Fix overlap counter scheduling bug
From: Robert Richter @ 2016-11-09 14:25 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Liang, Kan, Andi Kleen, Jiri Olsa, Vince Weaver, lkml,
Ingo Molnar
In-Reply-To: <20161108182739.GO3117@twins.programming.kicks-ass.net>
On 08.11.16 19:27:39, Peter Zijlstra wrote:
> The comment with EVENT_CONSTRAINT_OVERLAP states: "This is the case if
> the counter mask of such an event is not a subset of any other counter
> mask of a constraint with an equal or higher weight".
>
> Esp. that latter part is of interest here I think, our overlapping mask
> is 0x0e, that has 3 bits set and is the highest weight mask in on the
> PMU, therefore it will be placed last. Can we still create a scenario
> where we would need to rewind that?
>
> The scenario for AMD Fam15h is we're having masks like:
>
> 0x3F -- 111111
> 0x38 -- 111000
> 0x07 -- 000111
>
> 0x09 -- 001001
>
> And we mark 0x09 as overlapping, because it is not a direct subset of
> 0x38 or 0x07 and has less weight than either of those. This means we'll
> first try and place the 0x09 event, then try and place 0x38/0x07 events.
> Now imagine we have:
>
> 3 * 0x07 + 0x09
>
> and the initial pick for the 0x09 event is counter 0, then we'll fail to
> place all 0x07 events. So we'll pop back, try counter 4 for the 0x09
> event, and then re-try all 0x07 events, which will now work.
>
>
>
> But given, that in the uncore case, the overlapping event is the
> heaviest mask, I don't think this can happen. Or did I overlook
> something.... takes a bit to page all this back in.
Right, IMO 0xE mask may not be marked as overlapping. It is placed
last and if there is no space left we are lost. There is no other
combination or state we could try then. So the fix is to remove the
overlapping bit for that counter, the state is then never saved.
This assumes there are no other counters than 0x3 and 0xc that overlap
with 0xe. It becomes a bit tricky if there is another counter with the
same or higher weight that overlaps with 0xe, e.g. 0x7.
-Robert
^ permalink raw reply
* [GIT PULL] kvm/page_track changes for i915 KVMGT
From: Paolo Bonzini @ 2016-11-09 14:25 UTC (permalink / raw)
To: linux-kernel, kvm; +Cc: rkrcmar, Jani Nikula, intel-gfx
Daniel,
The following changes since commit d9092f52d7e61dd1557f2db2400ddb430e85937e:
kvm: x86: Check memopp before dereference (CVE-2016-8630) (2016-11-02 21:31:53 +0100)
are available in the git repository at:
git://git.kernel.org/pub/scm/virt/kvm/kvm.git tags/for-kvmgt
for you to fetch changes up to 871b7ef2a1850d0b435c8b324bf4a5d391adde3f:
kvm/page_track: export symbols for external usage (2016-11-04 12:13:20 +0100)
----------------------------------------------------------------
The three KVM patches that KVMGT needs.
----------------------------------------------------------------
Jike Song (2):
kvm/page_track: call notifiers with kvm_page_track_notifier_node
kvm/page_track: export symbols for external usage
Xiaoguang Chen (1):
KVM: x86: add track_flush_slot page track notifier
arch/x86/include/asm/kvm_page_track.h | 14 +++++++++++++-
arch/x86/kvm/mmu.c | 11 ++++++++++-
arch/x86/kvm/page_track.c | 31 ++++++++++++++++++++++++++++++-
arch/x86/kvm/x86.c | 2 +-
4 files changed, 54 insertions(+), 4 deletions(-)
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* [PATCH 12/12] exynos-gsc: Use of_device_get_match_data() helper
From: Marek Szyprowski @ 2016-11-09 14:24 UTC (permalink / raw)
To: linux-media, linux-samsung-soc
Cc: Marek Szyprowski, Sylwester Nawrocki, Krzysztof Kozlowski,
Ulf Hansson, Bartlomiej Zolnierkiewicz, Javier Martinez Canillas
In-Reply-To: <1478701441-29107-1-git-send-email-m.szyprowski@samsung.com>
Replace open-coded driver data extraction code with generic helper.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
---
drivers/media/platform/exynos-gsc/gsc-core.c | 15 ++-------------
1 file changed, 2 insertions(+), 13 deletions(-)
diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c b/drivers/media/platform/exynos-gsc/gsc-core.c
index ac4c96c..664398c 100644
--- a/drivers/media/platform/exynos-gsc/gsc-core.c
+++ b/drivers/media/platform/exynos-gsc/gsc-core.c
@@ -24,6 +24,7 @@
#include <linux/slab.h>
#include <linux/clk.h>
#include <linux/of.h>
+#include <linux/of_device.h>
#include <media/v4l2-ioctl.h>
#include "gsc-core.h"
@@ -975,24 +976,12 @@ static irqreturn_t gsc_irq_handler(int irq, void *priv)
};
MODULE_DEVICE_TABLE(of, exynos_gsc_match);
-static void *gsc_get_drv_data(struct platform_device *pdev)
-{
- struct gsc_driverdata *driver_data = NULL;
- const struct of_device_id *match;
-
- match = of_match_node(exynos_gsc_match, pdev->dev.of_node);
- if (match)
- driver_data = (struct gsc_driverdata *)match->data;
-
- return driver_data;
-}
-
static int gsc_probe(struct platform_device *pdev)
{
struct gsc_dev *gsc;
struct resource *res;
- struct gsc_driverdata *drv_data = gsc_get_drv_data(pdev);
struct device *dev = &pdev->dev;
+ const struct gsc_driverdata *drv_data = of_device_get_match_data(dev);
int ret;
gsc = devm_kzalloc(dev, sizeof(struct gsc_dev), GFP_KERNEL);
--
1.9.1
^ permalink raw reply related
* [PATCH 10/12] exynos-gsc: Remove unused lclk_freqency entry
From: Marek Szyprowski @ 2016-11-09 14:23 UTC (permalink / raw)
To: linux-media, linux-samsung-soc
Cc: Marek Szyprowski, Sylwester Nawrocki, Krzysztof Kozlowski,
Ulf Hansson, Bartlomiej Zolnierkiewicz, Javier Martinez Canillas
In-Reply-To: <1478701441-29107-1-git-send-email-m.szyprowski@samsung.com>
Remove dead, unused code.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
---
drivers/media/platform/exynos-gsc/gsc-core.c | 1 -
drivers/media/platform/exynos-gsc/gsc-core.h | 2 --
2 files changed, 3 deletions(-)
diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c b/drivers/media/platform/exynos-gsc/gsc-core.c
index 1e8b216..ff35909 100644
--- a/drivers/media/platform/exynos-gsc/gsc-core.c
+++ b/drivers/media/platform/exynos-gsc/gsc-core.c
@@ -964,7 +964,6 @@ static irqreturn_t gsc_irq_handler(int irq, void *priv)
[3] = &gsc_v_100_variant,
},
.num_entities = 4,
- .lclk_frequency = 266000000UL,
};
static const struct of_device_id exynos_gsc_match[] = {
diff --git a/drivers/media/platform/exynos-gsc/gsc-core.h b/drivers/media/platform/exynos-gsc/gsc-core.h
index 8480aec..e5aa8f4 100644
--- a/drivers/media/platform/exynos-gsc/gsc-core.h
+++ b/drivers/media/platform/exynos-gsc/gsc-core.h
@@ -303,12 +303,10 @@ struct gsc_variant {
* struct gsc_driverdata - per device type driver data for init time.
*
* @variant: the variant information for this driver.
- * @lclk_frequency: G-Scaler clock frequency
* @num_entities: the number of g-scalers
*/
struct gsc_driverdata {
struct gsc_variant *variant[GSC_MAX_DEVS];
- unsigned long lclk_frequency;
int num_entities;
};
--
1.9.1
^ permalink raw reply related
* [PATCH 07/12] exynos-gsc: Make system PM callbacks available for CONFIG_PM_SLEEP
From: Marek Szyprowski @ 2016-11-09 14:23 UTC (permalink / raw)
To: linux-media, linux-samsung-soc
Cc: Marek Szyprowski, Sylwester Nawrocki, Krzysztof Kozlowski,
Ulf Hansson, Bartlomiej Zolnierkiewicz, Javier Martinez Canillas
In-Reply-To: <1478701441-29107-1-git-send-email-m.szyprowski@samsung.com>
From: Ulf Hansson <ulf.hansson@linaro.org>
There are no need to set up the system PM callbacks unless they are
being used. It also causes compiler warnings about unused functions.
Silence the warnings by making them available for CONFIG_PM_SLEEP.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
[mszyprow: rebased onto v4.9-rc4]
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
---
drivers/media/platform/exynos-gsc/gsc-core.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c b/drivers/media/platform/exynos-gsc/gsc-core.c
index 9ba1619..af6502c 100644
--- a/drivers/media/platform/exynos-gsc/gsc-core.c
+++ b/drivers/media/platform/exynos-gsc/gsc-core.c
@@ -1166,6 +1166,7 @@ static int gsc_runtime_suspend(struct device *dev)
}
#endif
+#ifdef CONFIG_PM_SLEEP
static int gsc_resume(struct device *dev)
{
struct gsc_dev *gsc = dev_get_drvdata(dev);
@@ -1202,10 +1203,10 @@ static int gsc_suspend(struct device *dev)
return 0;
}
+#endif
static const struct dev_pm_ops gsc_pm_ops = {
- .suspend = gsc_suspend,
- .resume = gsc_resume,
+ SET_SYSTEM_SLEEP_PM_OPS(gsc_suspend, gsc_resume)
SET_RUNTIME_PM_OPS(gsc_runtime_suspend, gsc_runtime_resume, NULL)
};
--
1.9.1
^ permalink raw reply related
* [PATCH 11/12] exynos-gsc: Add missing newline char in debug messages
From: Marek Szyprowski @ 2016-11-09 14:24 UTC (permalink / raw)
To: linux-media, linux-samsung-soc
Cc: Marek Szyprowski, Sylwester Nawrocki, Krzysztof Kozlowski,
Ulf Hansson, Bartlomiej Zolnierkiewicz, Javier Martinez Canillas
In-Reply-To: <1478701441-29107-1-git-send-email-m.szyprowski@samsung.com>
Fix missing newline char in debug messages.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
---
drivers/media/platform/exynos-gsc/gsc-core.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c b/drivers/media/platform/exynos-gsc/gsc-core.c
index ff35909..ac4c96c 100644
--- a/drivers/media/platform/exynos-gsc/gsc-core.c
+++ b/drivers/media/platform/exynos-gsc/gsc-core.c
@@ -1138,7 +1138,7 @@ static int gsc_runtime_resume(struct device *dev)
struct gsc_dev *gsc = dev_get_drvdata(dev);
int ret = 0;
- pr_debug("gsc%d: state: 0x%lx", gsc->id, gsc->state);
+ pr_debug("gsc%d: state: 0x%lx\n", gsc->id, gsc->state);
ret = clk_prepare_enable(gsc->clock);
if (ret)
@@ -1160,7 +1160,7 @@ static int gsc_runtime_suspend(struct device *dev)
if (!ret)
clk_disable_unprepare(gsc->clock);
- pr_debug("gsc%d: state: 0x%lx", gsc->id, gsc->state);
+ pr_debug("gsc%d: state: 0x%lx\n", gsc->id, gsc->state);
return ret;
}
#endif
--
1.9.1
^ permalink raw reply related
* [PATCH 08/12] exynos-gsc: Simplify system PM
From: Marek Szyprowski @ 2016-11-09 14:23 UTC (permalink / raw)
To: linux-media, linux-samsung-soc
Cc: Marek Szyprowski, Sylwester Nawrocki, Krzysztof Kozlowski,
Ulf Hansson, Bartlomiej Zolnierkiewicz, Javier Martinez Canillas
In-Reply-To: <1478701441-29107-1-git-send-email-m.szyprowski@samsung.com>
From: Ulf Hansson <ulf.hansson@linaro.org>
It's not needed to keep a local flag about the current system PM state.
Let's just remove that code and the corresponding debug print.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
[mszyprow: rebased onto v4.9-rc4]
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
---
drivers/media/platform/exynos-gsc/gsc-core.c | 21 ---------------------
drivers/media/platform/exynos-gsc/gsc-core.h | 3 ---
2 files changed, 24 deletions(-)
diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c b/drivers/media/platform/exynos-gsc/gsc-core.c
index af6502c..4859727 100644
--- a/drivers/media/platform/exynos-gsc/gsc-core.c
+++ b/drivers/media/platform/exynos-gsc/gsc-core.c
@@ -1169,20 +1169,6 @@ static int gsc_runtime_suspend(struct device *dev)
#ifdef CONFIG_PM_SLEEP
static int gsc_resume(struct device *dev)
{
- struct gsc_dev *gsc = dev_get_drvdata(dev);
- unsigned long flags;
-
- pr_debug("gsc%d: state: 0x%lx", gsc->id, gsc->state);
-
- /* Do not resume if the device was idle before system suspend */
- spin_lock_irqsave(&gsc->slock, flags);
- if (!test_and_clear_bit(ST_SUSPEND, &gsc->state) ||
- !gsc_m2m_opened(gsc)) {
- spin_unlock_irqrestore(&gsc->slock, flags);
- return 0;
- }
- spin_unlock_irqrestore(&gsc->slock, flags);
-
if (!pm_runtime_suspended(dev))
return gsc_runtime_resume(dev);
@@ -1191,13 +1177,6 @@ static int gsc_resume(struct device *dev)
static int gsc_suspend(struct device *dev)
{
- struct gsc_dev *gsc = dev_get_drvdata(dev);
-
- pr_debug("gsc%d: state: 0x%lx", gsc->id, gsc->state);
-
- if (test_and_set_bit(ST_SUSPEND, &gsc->state))
- return 0;
-
if (!pm_runtime_suspended(dev))
return gsc_runtime_suspend(dev);
diff --git a/drivers/media/platform/exynos-gsc/gsc-core.h b/drivers/media/platform/exynos-gsc/gsc-core.h
index 7ad7b9d..8480aec 100644
--- a/drivers/media/platform/exynos-gsc/gsc-core.h
+++ b/drivers/media/platform/exynos-gsc/gsc-core.h
@@ -48,9 +48,6 @@
#define GSC_CTX_ABORT (1 << 7)
enum gsc_dev_flags {
- /* for global */
- ST_SUSPEND,
-
/* for m2m node */
ST_M2M_OPEN,
ST_M2M_RUN,
--
1.9.1
^ 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.