* Re: [PATCH v5 4/7] i2c: core: Make i2c_acpi_get_irq available to the rest of the I2C core
From: Charles Keepax @ 2019-06-20 15:12 UTC (permalink / raw)
To: Andy Shevchenko
Cc: wsa, mika.westerberg, jarkko.nikula, linux-i2c, linux-acpi,
linux-kernel, benjamin.tissoires, jbroadus, patches
In-Reply-To: <20190620145950.GE9224@smile.fi.intel.com>
On Thu, Jun 20, 2019 at 05:59:50PM +0300, Andy Shevchenko wrote:
> On Thu, Jun 20, 2019 at 02:34:17PM +0100, Charles Keepax wrote:
> > In preparation for more refactoring make i2c_acpi_get_irq available
> > outside i2c-core-acpi.c.
>
> > Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> > Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
>
> I'm not sure Rb tags are suitable for patches 4 and 5 since the changes made.
>
Apologies I figured the changes were small enough will remove for
any changes in future.
> > +struct acpi_device;
>
> Hmm... Doesn't acpi.h define that for !ACPI case?
>
Pretty sure I was getting a build error in that case.
> > #ifdef CONFIG_ACPI
> > const struct acpi_device_id *
> > i2c_acpi_match_device(const struct acpi_device_id *matches,
> > struct i2c_client *client);
> > void i2c_acpi_register_devices(struct i2c_adapter *adap);
> > +
> > +int i2c_acpi_get_irq(struct acpi_device *adev);
>
> Since you call this afterwards with struct device from which companion is
> derived, can't we directly use struct device as a parameter?
>
> Yes, in case of adev call, it might be &adev->dev I suppose?
>
A good idea I will investigate and do a respin taking in the
other comments too.
Thanks,
Charles
^ permalink raw reply
* [Buildroot] [git commit] package/haproxy: re-enable package on microblaze
From: Thomas Petazzoni @ 2019-06-20 15:12 UTC (permalink / raw)
To: buildroot
commit: https://git.buildroot.net/buildroot/commit/?id=cff148640564a3040a1d5f9e5545734b4791b2ce
branch: https://git.buildroot.net/buildroot/commit/?id=refs/heads/master
With Microblaze ccc version < 8.x and optimization, the build fails
with;
'internal compiler error: in do_output_reload, at reload1.c:7978'
This is due to gcc bug 90620:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90620. To avoid this, the
haproxy package has a !BR2_microblaze dependency. However, this gcc
bug 90620 only triggers when optimization is enabled, so we can work
around the issue by passing -O0, which is what we do in other
Buildroot packages to work around similar Microblaze issues.
So, this commit passes -O0 when BR2_TOOLCHAIN_HAS_GCC_BUG_90620, and
re-enables haproxy on Microblaze.
Signed-off-by: Giulio Benetti <giulio.benetti@micronovasrl.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
---
package/haproxy/Config.in | 2 --
package/haproxy/haproxy.mk | 8 +++++++-
2 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/package/haproxy/Config.in b/package/haproxy/Config.in
index 670de5a3ee..db63143a74 100644
--- a/package/haproxy/Config.in
+++ b/package/haproxy/Config.in
@@ -1,8 +1,6 @@
config BR2_PACKAGE_HAPROXY_ARCH_SUPPORTS
bool
default y
- # internal compiler error: in do_output_reload, at reload1.c:7978
- depends on !BR2_microblaze
# src/proto_http.c:6330:1: internal compiler error: Segmentation fault
depends on !BR2_nios2
# https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60040
diff --git a/package/haproxy/haproxy.mk b/package/haproxy/haproxy.mk
index e382f61f8e..36ac704222 100644
--- a/package/haproxy/haproxy.mk
+++ b/package/haproxy/haproxy.mk
@@ -69,9 +69,15 @@ endif
HAPROXY_MAKE_OPTS += ADDLIB="$(HAPROXY_LIBS)"
+HAPROXY_CFLAGS = $(TARGET_CFLAGS)
+
+ifeq ($(BR2_TOOLCHAIN_HAS_GCC_BUG_90620),y)
+HAPROXY_CFLAGS += -O0
+endif
+
define HAPROXY_BUILD_CMDS
$(TARGET_MAKE_ENV) $(MAKE) $(TARGET_CONFIGURE_OPTS) \
- $(HAPROXY_MAKE_OPTS) -C $(@D)
+ $(HAPROXY_MAKE_OPTS) CFLAGS="$(HAPROXY_CFLAGS)" -C $(@D)
endef
define HAPROXY_INSTALL_TARGET_CMDS
^ permalink raw reply related
* Re: [PATCH][v2] btrfs: run delayed iput at unlink time
From: David Sterba @ 2019-06-20 15:13 UTC (permalink / raw)
To: Josef Bacik; +Cc: linux-btrfs
In-Reply-To: <20190618145918.12641-1-josef@toxicpanda.com>
On Tue, Jun 18, 2019 at 10:59:18AM -0400, Josef Bacik wrote:
> We have been seeing issues in production where a cleaner script will end
> up unlinking a bunch of files that have pending iputs. This means they
> will get their final iput's run at btrfs-cleaner time and thus are not
> throttled, which impacts the workload.
>
> Since we are unlinking these files we can just drop the delayed iput at
> unlink time. We are already holding a reference to the inode so this
> will not be the final iput and thus is completely safe to do at this
> point. Doing this means we are more likely to be doing the final iput
> at unlink time, and thus will get the IO charged to the caller and get
> throttled appropriately without affecting the main workload.
>
> Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Added to misc-next, thanks.
^ permalink raw reply
* Re: [PATCH net] ipv6: fix neighbour resolution with raw socket
From: David Ahern @ 2019-06-20 15:12 UTC (permalink / raw)
To: Nicolas Dichtel, davem; +Cc: netdev
In-Reply-To: <20190620123434.7219-1-nicolas.dichtel@6wind.com>
On 6/20/19 6:34 AM, Nicolas Dichtel wrote:
> The scenario is the following: the user uses a raw socket to send an ipv6
> packet, destinated to a not-connected network, and specify a connected nh.
> Here is the corresponding python script to reproduce this scenario:
>
> import socket
> IPPROTO_RAW = 255
> send_s = socket.socket(socket.AF_INET6, socket.SOCK_RAW, IPPROTO_RAW)
> # scapy
> # p = IPv6(src='fd00:100::1', dst='fd00:200::fa')/ICMPv6EchoRequest()
> # str(p)
> req = b'`\x00\x00\x00\x00\x08:@\xfd\x00\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x01\xfd\x00\x02\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xfa\x80\x00\x81\xc0\x00\x00\x00\x00'
> send_s.sendto(req, ('fd00:175::2', 0, 0, 0))
>
> fd00:175::/64 is a connected route and fd00:200::fa is not a connected
> host.
>
> With this scenario, the kernel starts by sending a NS to resolve
> fd00:175::2. When it receives the NA, it flushes its queue and try to send
> the initial packet. But instead of sending it, it sends another NS to
> resolve fd00:200::fa, which obvioulsy fails, thus the packet is dropped. If
> the user sends again the packet, it now uses the right nh (fd00:175::2).
>
what's the local address and route setup? You reference fd00:100::1 and
fd00:200::fa with connected route fd00:175::/64.
^ permalink raw reply
* Re: [PATCH v5 2/7] i2c: acpi: Use available IRQ helper functions
From: Charles Keepax @ 2019-06-20 15:11 UTC (permalink / raw)
To: Andy Shevchenko
Cc: wsa, mika.westerberg, jarkko.nikula, linux-i2c, linux-acpi,
linux-kernel, benjamin.tissoires, jbroadus, patches
In-Reply-To: <20190620145221.GC9224@smile.fi.intel.com>
On Thu, Jun 20, 2019 at 05:52:21PM +0300, Andy Shevchenko wrote:
> On Thu, Jun 20, 2019 at 02:34:15PM +0100, Charles Keepax wrote:
> > Use the available IRQ helper functions, most of the functions have
> > additional helpful side affects like configuring the trigger type of the
> > IRQ.
> >
> > Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
> > Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> > Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
>
> Some last minute observations / questions.
>
> > + struct resource r;
> > +
> > + if (*irq <= 0 && acpi_dev_resource_interrupt(ares, 0, &r))
> > + *irq = i2c_dev_irq_from_resources(&r, 1);
> > +
> > + return 1; /* No need to add resource to the list */
>
> If we don't add it to the list, do we still need to manage the empty
> resource_list below?
>
I think you are right looking closely I think we can skip this. I
might update the comment here to make it clear the list needs
freed if this is changed though.
> > /* Then fill IRQ number if any */
> > INIT_LIST_HEAD(&resource_list);
> > - ret = acpi_dev_get_resources(adev, &resource_list, NULL, NULL);
> > + ret = acpi_dev_get_resources(adev, &resource_list,
> > + i2c_acpi_add_resource, &irq);
> > if (ret < 0)
> > return -EINVAL;
> >
> > - resource_list_for_each_entry(entry, &resource_list) {
> > - if (resource_type(entry->res) == IORESOURCE_IRQ) {
> > - info->irq = entry->res->start;
> > - break;
> > - }
> > - }
>
> > + if (irq > 0)
> > + info->irq = irq;
>
> Hmm... can't we just assign it directly inside the _add_resource() call back as
> original code did?
>
Again I think you are correct here, my thinking had been to
preserve the original functionality of only overwriting the value
in info->irq if we found one. But it looks like all callers don't
pass anything meaningful in this field so changing that behaviour
shouldn't matter.
Thanks,
Charles
^ permalink raw reply
* Re: [PATCH] usb: core: devio: add ioctls for suspend and resume
From: Mayuresh Kulkarni @ 2019-06-20 15:11 UTC (permalink / raw)
To: Alan Stern, Oliver Neukum; +Cc: Greg KH, patches, linux-usb
In-Reply-To: <Pine.LNX.4.44L0.1906191024150.1596-100000@iolanthe.rowland.org>
On Wed, 2019-06-19 at 10:40 -0400, Alan Stern wrote:
> On Wed, 19 Jun 2019, Oliver Neukum wrote:
>
> >
> > Am Dienstag, den 18.06.2019, 11:50 -0400 schrieb Alan Stern:
> > >
> > > On Tue, 18 Jun 2019, Mayuresh Kulkarni wrote:
> > >
> > > >
> > > > >
> > > > > You're right that the program needs to know when the device is
> > > > > about
> > > > > to
> > > > > be suspended. But waiting for an ioctl to return isn't a good
> > > > > way
> > > > > to do it; this needs to be a callback of some sort. That is,
> > > > > the
> > > > > kernel also needs to know when the program is ready for the
> > > > > suspend.
> > > > >
> > > > > I don't know what is the best approach.
> > > > This is becoming tricky now.
> > > Yes. There probably are mechanisms already in use in other parts
> > > of
> > > the kernel that would be suitable here, but I don't know what they
> > > are.
> > > We could try asking some other people for advice.
> > Waiting for an ioctl() is horrible. If you really want to do this
> > poll() would be the obvious API. It is made for waiting for changes
> > of states.
> >
> > [..]
> > >
> > > The suspend callback is _not_ responsible for actually suspending
> > > the
> > > device; that is handled by the USB subsystem core.
> > >
> > > These ideas are indeed applicable to programs using usbfs. The
> > > kernel
> > Not fully. Usbfs has the same issue as FUSE here. Drivers are per
> > interface but power management is per device. Hence every driver
> > is in the block IO path for these issues. You cannot do block IO
> > in user space. The best you can do is notify of state changes,
> > but you cannot wait for them.
> usbfs access is per-device, not per-interface, but your point remains
> valid.
>
> >
> > >
> > > needs to have a way to inform the program that the device is about
> > > enter (or has just left) a low-power state, so that the program
> > > can
> > > stop (or start) trying to communicate with the device. And the
> > > kernel
> > > needs to know when the program is ready for the state change.
> > That has difficulties based in fundamental issues. We can let user
> > space block power transitions. We can notify it. But we cannot
> > block on it.
> >
> > It would be easiest to export the usb_autopm_* API to user space.
> But ->suspend and ->resume callbacks are part of that API, and as you
> say, it is not feasible to have these callbacks run in userspace.
>
> The only solution I can think of is for the userspace program to first
> set the device's autosuspend delay to 0. Then whenever the
> WAIT_FOR_RESUME ioctl returns -- even if it returns immediately -- the
> program should assume the suspend is over or is not going to happen.
> Then the program can run normally for a short while (10 seconds,
> perhaps) before making another attempt to suspend.
>
Looks like usb_autosuspend_delay parameter is applicable to all USB
devices. Also, since it is a module parameter, it might be tuned on a
particular platform (e.g.: from init.<vendor>.rc on Android).
So, I am not sure if it is good idea to rely on user-space to change it
and restore it to original value when the USB device of interest is
detached.
> The only change I would make to the patch posted earlier is to have
> proc_wait_for_resume() call usb_autoresume_device() and set
> ps->suspend_requested = false before returning.
>
> Mayuresh, how does that sound?
With the code-changes you send me (in response to the
patch), usb_autoresume_device() will be called when the waiter
in proc_wait_for_resume() will return and send some message to "know"
why resume happened.
With above proposed change, proc_wait_for_resume() will return
with usb_autoresume_device() and suspend_requested = false. So when the
user-space will send some message to "know" resume reason, the checks in
ioctl() handler will be skipped.
(Apologies if above is obvious, but still wanted to comment so that we
are on same page).
With that said, I think there would be an issue with "host-wake" case as
below - the sequence of operations are:
- suspend ioctl called: assume actual bus suspend happens
- wait-for-resume ioctl called
- after a while user-space wants to send a message (due to end user
interaction for example)
Here the ioctl() will do usb_autoresume_device() since suspend_requested
= true. This will end up calling usbfs_notify_resume() which will
release waiter in proc_wait_for_resume(). And due to above proposed
change, it will end up calling usb_autoresume_device() again.
As a result, suspend will not happen for next suspend ioctl call.
So, looks like the original proposed change seems better here. On the
side note, I am still in process of verifying the code changes.
>
> Alan Stern
>
^ permalink raw reply
* Re: [PATCH v1 5/5] coresight: etm4x: save/restore state across CPU low power states
From: Andrew Murray @ 2019-06-20 15:11 UTC (permalink / raw)
To: Mathieu Poirier; +Cc: Alexander Shishkin, linux-arm-kernel, Suzuki K Poulose
In-Reply-To: <CANLsYkx0LNg+Ld7D4_9d_ng8s3eVWbxaBKCMPpMFR9hrD7ny6A@mail.gmail.com>
On Thu, Jun 20, 2019 at 08:49:47AM -0600, Mathieu Poirier wrote:
> Hi Andrew,
>
> On Thu, 20 Jun 2019 at 05:07, Andrew Murray <andrew.murray@arm.com> wrote:
> >
> > On Tue, Jun 18, 2019 at 04:55:49PM -0600, Mathieu Poirier wrote:
> > > On Tue, Jun 18, 2019 at 01:54:33PM +0100, Andrew Murray wrote:
> > > > Some hardware will ignore bit TRCPDCR.PU which is used to signal
> > > > to hardware that power should not be removed from the trace unit.
> > > > Let's mitigate against this by saving and restoring the trace
> > > > unit state when the CPU enters low power states.
> > > >
> > > > To provide the benefit to both self-hosted and external debuggers
> > > > we save/restore the entire state which includes etmv4_config data
> > > > and dynamic data such as inflight counter values, sequencer
> > > > states, etc.
> > > >
> > > > To reduce CPU suspend/resume latency the state is only saved or
> > > > restored if coresight is in use as determined by the claimset
> > > > registers.
> > > >
> > > > To aid debug of CPU suspend/resume a disable_pm_save parameter
> > > > is provided to disable this feature.
> > > >
> > > > Signed-off-by: Andrew Murray <andrew.murray@arm.com>
> > > > ---
> > > > drivers/hwtracing/coresight/coresight-etm4x.c | 245 ++++++++++++++++++
> > > > drivers/hwtracing/coresight/coresight-etm4x.h | 66 ++++-
> > > > drivers/hwtracing/coresight/coresight.c | 2 +-
> > > > include/linux/coresight.h | 7 +
> > > > 4 files changed, 318 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/drivers/hwtracing/coresight/coresight-etm4x.c b/drivers/hwtracing/coresight/coresight-etm4x.c
> > > > index bda90d4cd62b..d27c5e0d9aec 100644
> > > > --- a/drivers/hwtracing/coresight/coresight-etm4x.c
> > > > +++ b/drivers/hwtracing/coresight/coresight-etm4x.c
> > > > @@ -18,6 +18,7 @@
> > > > #include <linux/stat.h>
> > > > #include <linux/clk.h>
> > > > #include <linux/cpu.h>
> > > > +#include <linux/cpu_pm.h>
> > > > #include <linux/coresight.h>
> > > > #include <linux/coresight-pmu.h>
> > > > #include <linux/pm_wakeup.h>
> > > > @@ -36,6 +37,9 @@
> > > > static int boot_enable;
> > > > module_param_named(boot_enable, boot_enable, int, 0444);
> > > >
> > > > +static int disable_pm_save;
> > > > +module_param_named(disable_pm_save, disable_pm_save, int, 0444);
> > > > +
> > > > /* The number of ETMv4 currently registered */
> > > > static int etm4_count;
> > > > static struct etmv4_drvdata *etmdrvdata[NR_CPUS];
> > > > @@ -53,6 +57,14 @@ static void etm4_os_unlock(struct etmv4_drvdata *drvdata)
> > > > isb();
> > > > }
> > > >
> > > > +static void etm4_os_lock(struct etmv4_drvdata *drvdata)
> > > > +{
> > > > + /* Writing 0x1 to TRCOSLAR unlocks the trace registers */
> > > > + writel_relaxed(0x1, drvdata->base + TRCOSLAR);
> > > > + drvdata->os_unlock = false;
> > > > + isb();
> > > > +}
> > > > +
> > > > static bool etm4_arch_supported(u8 arch)
> > > > {
> > > > /* Mask out the minor version number */
> > > > @@ -1076,6 +1088,235 @@ static void etm4_init_trace_id(struct etmv4_drvdata *drvdata)
> > > > drvdata->trcid = coresight_get_trace_id(drvdata->cpu);
> > > > }
> > > >
> > > > +#ifdef CONFIG_CPU_PM
> > > > +static void etm4_cpu_save(struct etmv4_drvdata *drvdata)
> > > > +{
> > > > + int i;
> > > > + u32 control;
> > > > + struct etmv4_save_state *state;
> > >
> > > Before going any further I would make sure the CPU this is running on it equal
> > > to drvdata->cpu. Otherwise something very wrong happened.
> > >
> >
> > Sure I'll add that.
> >
> > > > +
> > > > + /* As recommended by 3.4.1 of ARM IHI 0064D */
> > > > + dsb(sy);
> > > > + isb();
> > > > +
> > > > + CS_UNLOCK(drvdata->base);
> > > > + etm4_os_lock(drvdata);
> > >
> > > Please add a comment to explain that you are using the OS lock to disable
> > > external debugger access to the trace registers while the unit is powered down.
> > > Otherwise people will get confused and will submit patches that changes
> > > etm4_os_lock() to etm4_os_unlock().
> >
> > Yes sure, it deserves a comment.
> >
> > >
> > > > +
> > > > + /* wait for TRCSTATR.PMSTABLE to go up */
> > > > + if (coresight_timeout(drvdata->base, TRCSTATR,
> > > > + TRCSTATR_PMSTABLE_BIT, 1))
> > > > + dev_err(drvdata->dev,
> > > > + "timeout while waiting for Idle Trace Status\n");
> > >
> > > The above comment is not accurate since we are waiting for the PMSTABLE bit.
> >
> > I'll change that.
> >
> > >
> > > > +
> > > > + state = &drvdata->save_state;
> > > > +
> > > > + state->trcprgctlr = readl(drvdata->base + TRCPRGCTLR);
> > > > + state->trcprocselr = readl(drvdata->base + TRCPROCSELR);
> > > > + state->trcconfigr = readl(drvdata->base + TRCCONFIGR);
> > > > + state->trcauxctlr = readl(drvdata->base + TRCAUXCTLR);
> > > > + state->trceventctl0r = readl(drvdata->base + TRCEVENTCTL0R);
> > > > + state->trceventctl1r = readl(drvdata->base + TRCEVENTCTL1R);
> > > > + state->trcstallctlr = readl(drvdata->base + TRCSTALLCTLR);
> > > > + state->trctsctlr = readl(drvdata->base + TRCTSCTLR);
> > > > + state->trcsyncpr = readl(drvdata->base + TRCSYNCPR);
> > > > + state->trcccctlr = readl(drvdata->base + TRCCCCTLR);
> > > > + state->trcbbctlr = readl(drvdata->base + TRCBBCTLR);
> > > > + state->trctraceidr = readl(drvdata->base + TRCTRACEIDR);
> > > > + state->trcqctlr = readl(drvdata->base + TRCQCTLR);
> > > > +
> > > > + state->trcvictlr = readl(drvdata->base + TRCVICTLR);
> > > > + state->trcviiectlr = readl(drvdata->base + TRCVIIECTLR);
> > > > + state->trcvissctlr = readl(drvdata->base + TRCVISSCTLR);
> > > > + state->trcvipcssctlr = readl(drvdata->base + TRCVIPCSSCTLR);
> > > > + state->trcvdctlr = readl(drvdata->base + TRCVDCTLR);
> > > > + state->trcvdsacctlr = readl(drvdata->base + TRCVDSACCTLR);
> > > > + state->trcvdarcctlr = readl(drvdata->base + TRCVDARCCTLR);
> > > > +
> > > > + for (i = 0; i < drvdata->nrseqstate; i++)
> > > > + state->trcseqevr[i] = readl(drvdata->base + TRCSEQEVRn(i));
> > > > +
> > > > + state->trcseqrstevr = readl(drvdata->base + TRCSEQRSTEVR);
> > > > + state->trcseqstr = readl(drvdata->base + TRCSEQSTR);
> > > > + state->trcextinselr = readl(drvdata->base + TRCEXTINSELR);
> > > > +
> > > > + for (i = 0; i < drvdata->nr_cntr; i++) {
> > > > + state->trccntrldvr[i] = readl(drvdata->base + TRCCNTRLDVRn(i));
> > > > + state->trccntctlr[i] = readl(drvdata->base + TRCCNTCTLRn(i));
> > > > + state->trccntvr[i] = readl(drvdata->base + TRCCNTVRn(i));
> > > > + }
> > > > +
> > > > + for (i = 0; i < drvdata->nr_resource * 2; i++)
> > > > + state->trcrsctlr[i] = readl(drvdata->base + TRCRSCTLRn(i));
> > > > +
> > > > + for (i = 0; i < drvdata->nr_ss_cmp; i++) {
> > > > + state->trcssccr[i] = readl(drvdata->base + TRCSSCCRn(i));
> > > > + state->trcsscsr[i] = readl(drvdata->base + TRCSSCSRn(i));
> > > > + state->trcsspcicr[i] = readl(drvdata->base + TRCSSPCICRn(i));
> > > > + }
> > > > +
> > > > + for (i = 0; i < drvdata->nr_addr_cmp * 2; i++) {
> > > > + state->trcacvr[i] = readl(drvdata->base + TRCACVRn(i));
> > > > + state->trcacatr[i] = readl(drvdata->base + TRCACATRn(i));
> > > > + }
> > > > +
> > > > + for (i = 0; i < drvdata->numcidc; i++)
> > > > + state->trccidcvr[i] = readl(drvdata->base + TRCCIDCVRn(i));
> > > > +
> > > > + for (i = 0; i < drvdata->numvmidc; i++)
> > > > + state->trcvmidcvr[i] = readl(drvdata->base + TRCVMIDCVRn(i));
> > > > +
> > > > + state->trccidcctlr0 = readl(drvdata->base + TRCCIDCCTLR0);
> > > > + state->trccidcctlr1 = readl(drvdata->base + TRCCIDCCTLR1);
> > > > +
> > > > + state->trcvmidcctlr0 = readl(drvdata->base + TRCVMIDCCTLR0);
> > > > + state->trcvmidcctlr0 = readl(drvdata->base + TRCVMIDCCTLR1);
> > > > +
> > > > + state->trcclaimset = readl(drvdata->base + TRCCLAIMCLR);
> > > > +
> > > > + /* wait for TRCSTATR.IDLE to go up */
> > > > + if (coresight_timeout(drvdata->base, TRCSTATR, TRCSTATR_IDLE_BIT, 1))
> > > > + dev_err(drvdata->dev,
> > > > + "timeout while waiting for Idle Trace Status\n");
> > > > +
> > > > + /* power can be removed from the trace unit now */
> > > > + control = readl_relaxed(drvdata->base + TRCPDCR);
> > > > + control &= ~TRCPDCR_PU;
> > > > + writel_relaxed(control, drvdata->base + TRCPDCR);
> > > > +
> > > > + CS_LOCK(drvdata->base);
> > > > +}
> > > > +
> > > > +static void etm4_cpu_restore(struct etmv4_drvdata *drvdata)
> > > > +{
> > > > + int i;
> > > > + struct etmv4_save_state *state;
> > > > +
> > > > + state = &drvdata->save_state;
> > >
> > > Same comment as above about the running CPU.
> > >
> > > > +
> > > > + CS_UNLOCK(drvdata->base);
> > > > +
> > > > + writel_relaxed(state->trcclaimset, drvdata->base + TRCCLAIMSET);
> > > > +
> > > > + writel_relaxed(state->trcprgctlr, drvdata->base + TRCPRGCTLR);
> > > > + writel_relaxed(state->trcprocselr, drvdata->base + TRCPROCSELR);
> > > > + writel_relaxed(state->trcconfigr, drvdata->base + TRCCONFIGR);
> > > > + writel_relaxed(state->trcauxctlr, drvdata->base + TRCAUXCTLR);
> > > > + writel_relaxed(state->trceventctl0r, drvdata->base + TRCEVENTCTL0R);
> > > > + writel_relaxed(state->trceventctl1r, drvdata->base + TRCEVENTCTL1R);
> > > > + writel_relaxed(state->trcstallctlr, drvdata->base + TRCSTALLCTLR);
> > > > + writel_relaxed(state->trctsctlr, drvdata->base + TRCTSCTLR);
> > > > + writel_relaxed(state->trcsyncpr, drvdata->base + TRCSYNCPR);
> > > > + writel_relaxed(state->trcccctlr, drvdata->base + TRCCCCTLR);
> > > > + writel_relaxed(state->trcbbctlr, drvdata->base + TRCBBCTLR);
> > > > + writel_relaxed(state->trctraceidr, drvdata->base + TRCTRACEIDR);
> > > > + writel_relaxed(state->trcqctlr, drvdata->base + TRCQCTLR);
> > > > +
> > > > + writel_relaxed(state->trcvictlr, drvdata->base + TRCVICTLR);
> > > > + writel_relaxed(state->trcviiectlr, drvdata->base + TRCVIIECTLR);
> > > > + writel_relaxed(state->trcvissctlr, drvdata->base + TRCVISSCTLR);
> > > > + writel_relaxed(state->trcvipcssctlr, drvdata->base + TRCVIPCSSCTLR);
> > > > + writel_relaxed(state->trcvdctlr, drvdata->base + TRCVDCTLR);
> > > > + writel_relaxed(state->trcvdsacctlr, drvdata->base + TRCVDSACCTLR);
> > > > + writel_relaxed(state->trcvdarcctlr, drvdata->base + TRCVDARCCTLR);
> > > > +
> > > > + for (i = 0; i < drvdata->nrseqstate; i++)
> > > > + writel_relaxed(state->trcseqevr[i],
> > > > + drvdata->base + TRCSEQEVRn(i));
> > > > +
> > > > + writel_relaxed(state->trcseqrstevr, drvdata->base + TRCSEQRSTEVR);
> > > > + writel_relaxed(state->trcseqstr, drvdata->base + TRCSEQSTR);
> > > > + writel_relaxed(state->trcextinselr, drvdata->base + TRCEXTINSELR);
> > > > +
> > > > + for (i = 0; i < drvdata->nr_cntr; i++) {
> > > > + writel_relaxed(state->trccntrldvr[i],
> > > > + drvdata->base + TRCCNTRLDVRn(i));
> > > > + writel_relaxed(state->trccntctlr[i],
> > > > + drvdata->base + TRCCNTCTLRn(i));
> > > > + writel_relaxed(state->trccntvr[i],
> > > > + drvdata->base + TRCCNTVRn(i));
> > > > + }
> > > > +
> > > > + for (i = 0; i < drvdata->nr_resource * 2; i++)
> > > > + writel_relaxed(state->trcrsctlr[i],
> > > > + drvdata->base + TRCRSCTLRn(i));
> > > > +
> > > > + for (i = 0; i < drvdata->nr_ss_cmp; i++) {
> > > > + writel_relaxed(state->trcssccr[i],
> > > > + drvdata->base + TRCSSCCRn(i));
> > > > + writel_relaxed(state->trcsscsr[i],
> > > > + drvdata->base + TRCSSCSRn(i));
> > > > + writel_relaxed(state->trcsspcicr[i],
> > > > + drvdata->base + TRCSSPCICRn(i));
> > > > + }
> > > > +
> > > > + for (i = 0; i < drvdata->nr_addr_cmp * 2; i++) {
> > > > + writel_relaxed(state->trcacvr[i],
> > > > + drvdata->base + TRCACVRn(i));
> > > > + writel_relaxed(state->trcacatr[i],
> > > > + drvdata->base + TRCACATRn(i));
> > > > + }
> > > > +
> > > > + for (i = 0; i < drvdata->numcidc; i++)
> > > > + writel_relaxed(state->trccidcvr[i],
> > > > + drvdata->base + TRCCIDCVRn(i));
> > > > +
> > > > + for (i = 0; i < drvdata->numvmidc; i++)
> > > > + writel_relaxed(state->trcvmidcvr[i],
> > > > + drvdata->base + TRCVMIDCVRn(i));
> > > > +
> > > > + writel_relaxed(state->trccidcctlr0, drvdata->base + TRCCIDCCTLR0);
> > > > + writel_relaxed(state->trccidcctlr1, drvdata->base + TRCCIDCCTLR1);
> > > > +
> > > > + writel_relaxed(state->trcvmidcctlr0, drvdata->base + TRCVMIDCCTLR0);
> > > > + writel_relaxed(state->trcvmidcctlr0, drvdata->base + TRCVMIDCCTLR1);
> > > > +
> > > > + writel_relaxed(state->trcclaimset, drvdata->base + TRCCLAIMSET);
> > > > +
> > > > + /* As recommended by 4.3.7 of ARM IHI 0064D */
> > > > + dsb(sy);
> > > > + isb();
> > > > +
> > > > + etm4_os_unlock(drvdata);
> > >
> > > Same comment as above.
> > >
> > > > + CS_LOCK(drvdata->base);
> > > > +}
> > > > +
> > > > +static int etm4_cpu_pm_notify(struct notifier_block *nb, unsigned long cmd,
> > > > + void *v)
> > > > +{
> > > > + struct etmv4_drvdata *drvdata = container_of(nb,
> > > > + struct etmv4_drvdata, nb);
> > > > +
> > > > + if (disable_pm_save)
> > > > + return NOTIFY_OK;
> > > > +
> > > > + switch (cmd) {
> > > > + case CPU_PM_ENTER:
> > > > + /* save the state if coresight is in use */
> > > > + if (coresight_is_claimed_any(drvdata->base))
> > >
> > > claimed_any()? At this point if coresight_is_claimed_self_hosted() == false an
> > > external agent is competing with the framework and we should abdicate.
> >
> > If we only support save/restore for self-hosted, then we don't actually need
> > to store as much state as much of it is in the etmv4_config structure.
> >
> > My thinking here was that if an external agent is being used and we power down
> > then we'd also potentially suffer the same issue where state is lost. So
> > saving/restoring may be helpful for external agents as well (or at least
> > wouldn't do harm)...
>
> There is no point in trying to cover cases where external agents are
> involved - we will always get it wrong.
OK, given that I don't know of any particular cases where this is an issue
I'm happy to change this to !coresight_is_claimed_self_hosted().
> And the notifiers shouldn't
> return immediately if a tracer is not being used.
What should they do? We only need to save/restore when there is an active
session don't we? Have I misunderstood?
Thanks,
Andrew Murray
>
> >
> > However I don't know if this is a real issue.
> >
> > >
> > > > + etm4_cpu_save(drvdata);
> > > > + break;
> > > > + case CPU_PM_EXIT:
> > > > + case CPU_PM_ENTER_FAILED:
> > > > + /* trcclaimset is set when there is state to restore */
> > > > + if (drvdata->save_state.trcclaimset)
> > > > + etm4_cpu_restore(drvdata);
> > > > + break;
> > > > + default:
> > > > + return NOTIFY_DONE;
> > > > + }
> > > > +
> > > > + return NOTIFY_OK;
> > > > +}
> > > > +
> > > > +static int etm4_cpu_pm_register(struct etmv4_drvdata *drvdata)
> > > > +{
> > > > + drvdata->nb.notifier_call = etm4_cpu_pm_notify;
> > > > + return cpu_pm_register_notifier(&drvdata->nb);
> > > > +}
> > > > +#else
> > > > +static int etm4_cpu_pm_register(struct etmv4_drvdata *drvdata) { return 0; }
> > > > +#endif
> > > > +
> > > > static int etm4_probe(struct amba_device *adev, const struct amba_id *id)
> > > > {
> > > > int ret;
> > > > @@ -1141,6 +1382,10 @@ static int etm4_probe(struct amba_device *adev, const struct amba_id *id)
> > > > etm4_init_trace_id(drvdata);
> > > > etm4_set_default(&drvdata->config);
> > > >
> > > > + ret = etm4_cpu_pm_register(drvdata);
> > > > + if (ret)
> > > > + goto err_arch_supported;
> > > > +
> > > > desc.type = CORESIGHT_DEV_TYPE_SOURCE;
> > > > desc.subtype.source_subtype = CORESIGHT_DEV_SUBTYPE_SOURCE_PROC;
> > > > desc.ops = &etm4_cs_ops;
> > > > diff --git a/drivers/hwtracing/coresight/coresight-etm4x.h b/drivers/hwtracing/coresight/coresight-etm4x.h
> > > > index 52786e9d8926..f4cff447c8a1 100644
> > > > --- a/drivers/hwtracing/coresight/coresight-etm4x.h
> > > > +++ b/drivers/hwtracing/coresight/coresight-etm4x.h
> > > > @@ -174,7 +174,8 @@
> > > > ETM_MODE_EXCL_KERN | \
> > > > ETM_MODE_EXCL_USER)
> > > >
> > > > -#define TRCSTATR_IDLE_BIT 0
> > > > +#define TRCSTATR_IDLE_BIT BIT(0)
> > > > +#define TRCSTATR_PMSTABLE_BIT BIT(1)
> > > > #define ETM_DEFAULT_ADDR_COMP 0
> > > >
> > > > /* PowerDown Control Register bits */
> > > > @@ -281,6 +282,65 @@ struct etmv4_config {
> > > > u32 ext_inp;
> > > > };
> > > >
> > > > +/**
> > > > + * struct etm4_save_state - state to be preserved when ETM is without power
> > > > + */
> > > > +struct etmv4_save_state {
> > > > + u32 trcprgctlr;
> > > > + u32 trcprocselr;
> > > > + u32 trcconfigr;
> > > > + u32 trcauxctlr;
> > > > + u32 trceventctl0r;
> > > > + u32 trceventctl1r;
> > > > + u32 trcstallctlr;
> > > > + u32 trctsctlr;
> > > > + u32 trcsyncpr;
> > > > + u32 trcccctlr;
> > > > + u32 trcbbctlr;
> > > > + u32 trctraceidr;
> > > > + u32 trcqctlr;
> > > > +
> > > > + u32 trcvictlr;
> > > > + u32 trcviiectlr;
> > > > + u32 trcvissctlr;
> > > > + u32 trcvipcssctlr;
> > > > + u32 trcvdctlr;
> > > > + u32 trcvdsacctlr;
> > > > + u32 trcvdarcctlr;
> > > > +
> > > > + u32 trcseqevr[ETM_MAX_SEQ_STATES];
> > > > + u32 trcseqrstevr;
> > > > + u32 trcseqstr;
> > > > + u32 trcextinselr;
> > > > + u32 trccntrldvr[ETMv4_MAX_CNTR];
> > > > + u32 trccntctlr[ETMv4_MAX_CNTR];
> > > > + u32 trccntvr[ETMv4_MAX_CNTR];
> > > > +
> > > > + u32 trcrsctlr[ETM_MAX_RES_SEL * 2];
> > > > +
> > > > + u32 trcssccr[ETM_MAX_SS_CMP];
> > > > + u32 trcsscsr[ETM_MAX_SS_CMP];
> > > > + u32 trcsspcicr[ETM_MAX_SS_CMP];
> > > > +
> > > > + u64 trcacvr[ETM_MAX_SINGLE_ADDR_CMP];
> > > > + u64 trcacatr[ETM_MAX_SINGLE_ADDR_CMP];
> > > > + u64 trcdvcvr[ETM_MAX_DATA_VAL_CMP];
> > > > + u64 trcdvcmr[ETM_MAX_DATA_VAL_CMP];
> > > > + u64 trccidcvr[ETMv4_MAX_CTXID_CMP];
> > > > + u32 trcvmidcvr[ETM_MAX_VMID_CMP];
> > > > + u32 trccidcctlr0;
> > > > + u32 trccidcctlr1;
> > > > + u32 trcvmidcctlr0;
> > > > + u32 trcvmidcctlr1;
> > > > +
> > > > + u32 trcclaimset;
> > > > +
> > > > + u32 cntr_val[ETMv4_MAX_CNTR];
> > > > + u32 seq_state;
> > > > + u32 vinst_ctrl;
> > > > + u32 ss_status[ETM_MAX_SS_CMP];
> > > > +};
> > > > +
> > > > /**
> > > > * struct etm4_drvdata - specifics associated to an ETM component
> > > > * @base: Memory mapped base address for this component.
> > > > @@ -337,6 +397,8 @@ struct etmv4_config {
> > > > * @atbtrig: If the implementation can support ATB triggers
> > > > * @lpoverride: If the implementation can support low-power state over.
> > > > * @config: structure holding configuration parameters.
> > > > + * @save_state: State to be preserved across power loss
> > > > + * @nb: CPU PM notifier
> > > > */
> > > > struct etmv4_drvdata {
> > > > void __iomem *base;
> > > > @@ -383,6 +445,8 @@ struct etmv4_drvdata {
> > > > bool atbtrig;
> > > > bool lpoverride;
> > > > struct etmv4_config config;
> > > > + struct etmv4_save_state save_state;
> > > > + struct notifier_block nb;
> > > > };
> > > >
> > > > /* Address comparator access types */
> > > > diff --git a/drivers/hwtracing/coresight/coresight.c b/drivers/hwtracing/coresight/coresight.c
> > > > index 4b130281236a..e85d09e597a0 100644
> > > > --- a/drivers/hwtracing/coresight/coresight.c
> > > > +++ b/drivers/hwtracing/coresight/coresight.c
> > > > @@ -140,7 +140,7 @@ static inline bool coresight_is_claimed_self_hosted(void __iomem *base)
> > > > return coresight_read_claim_tags(base) == CORESIGHT_CLAIM_SELF_HOSTED;
> > > > }
> > > >
> > > > -static inline bool coresight_is_claimed_any(void __iomem *base)
> > > > +bool coresight_is_claimed_any(void __iomem *base)
> > > > {
> > > > return coresight_read_claim_tags(base) != 0;
> > > > }
> > > > diff --git a/include/linux/coresight.h b/include/linux/coresight.h
> > > > index 62a520df8add..4f7ba923ffc4 100644
> > > > --- a/include/linux/coresight.h
> > > > +++ b/include/linux/coresight.h
> > > > @@ -268,6 +268,8 @@ extern int coresight_claim_device_unlocked(void __iomem *base);
> > > > extern void coresight_disclaim_device(void __iomem *base);
> > > > extern void coresight_disclaim_device_unlocked(void __iomem *base);
> > > >
> > > > +extern bool coresight_is_claimed_any(void __iomem *base);
> > > > +
> > > > #else
> > > > static inline struct coresight_device *
> > > > coresight_register(struct coresight_desc *desc) { return NULL; }
> > > > @@ -290,6 +292,11 @@ static inline int coresight_claim_device(void __iomem *base)
> > > > static inline void coresight_disclaim_device(void __iomem *base) {}
> > > > static inline void coresight_disclaim_device_unlocked(void __iomem *base) {}
> > > >
> > > > +static inline bool coresight_is_claimed_any(void __iomem *base)
> > > > +{
> > > > + return false;
> > > > +}
> > > > +
> > >
> > > I wanted to test your code but it doesn't apply on the CS next branch:
> > >
> > > https://git.linaro.org/kernel/coresight.git/log/?h=next
> >
> > Oh sorry about that, this was ontop of v5.2-rc5, I'll rebase to the CS branch
> > on the next iteration.
> >
> > Thanks for the responsive feedback.
> >
> > Andrew Murray
> >
> > >
> > > Thanks,
> > > Mathieu
> > >
> > > > #endif
> > > >
> > > > #ifdef CONFIG_OF
> > > > --
> > > > 2.21.0
> > > >
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [Qemu-devel] [PATCH v4 02/13] vfio: Add function to unmap VFIO region
From: Kirti Wankhede @ 2019-06-20 14:37 UTC (permalink / raw)
To: alex.williamson, cjia
Cc: Kirti Wankhede, Zhengxiao.zx, kevin.tian, yi.l.liu, yan.y.zhao,
eskultet, ziye.yang, qemu-devel, cohuck, shuangtai.tst, dgilbert,
zhi.a.wang, mlevitsk, pasic, aik, yulei.zhang, eauger, felipe,
jonathan.davies, changpeng.liu, Ken.Xue
In-Reply-To: <1561041461-22326-1-git-send-email-kwankhede@nvidia.com>
This function is used in follwing patch in this series.
Migration region is mmaped when migration starts and will be unmapped when
migration is complete.
Signed-off-by: Kirti Wankhede <kwankhede@nvidia.com>
Reviewed-by: Neo Jia <cjia@nvidia.com>
---
hw/vfio/common.c | 20 ++++++++++++++++++++
hw/vfio/trace-events | 1 +
include/hw/vfio/vfio-common.h | 1 +
3 files changed, 22 insertions(+)
diff --git a/hw/vfio/common.c b/hw/vfio/common.c
index a859298fdad9..de74dae8d6a6 100644
--- a/hw/vfio/common.c
+++ b/hw/vfio/common.c
@@ -964,6 +964,26 @@ int vfio_region_mmap(VFIORegion *region)
return 0;
}
+void vfio_region_unmap(VFIORegion *region)
+{
+ int i;
+
+ if (!region->mem) {
+ return;
+ }
+
+ for (i = 0; i < region->nr_mmaps; i++) {
+ trace_vfio_region_unmap(memory_region_name(®ion->mmaps[i].mem),
+ region->mmaps[i].offset,
+ region->mmaps[i].offset +
+ region->mmaps[i].size - 1);
+ memory_region_del_subregion(region->mem, ®ion->mmaps[i].mem);
+ munmap(region->mmaps[i].mmap, region->mmaps[i].size);
+ object_unparent(OBJECT(®ion->mmaps[i].mem));
+ region->mmaps[i].mmap = NULL;
+ }
+}
+
void vfio_region_exit(VFIORegion *region)
{
int i;
diff --git a/hw/vfio/trace-events b/hw/vfio/trace-events
index b1ef55a33ffd..8cdc27946cb8 100644
--- a/hw/vfio/trace-events
+++ b/hw/vfio/trace-events
@@ -111,6 +111,7 @@ vfio_region_mmap(const char *name, unsigned long offset, unsigned long end) "Reg
vfio_region_exit(const char *name, int index) "Device %s, region %d"
vfio_region_finalize(const char *name, int index) "Device %s, region %d"
vfio_region_mmaps_set_enabled(const char *name, bool enabled) "Region %s mmaps enabled: %d"
+vfio_region_unmap(const char *name, unsigned long offset, unsigned long end) "Region %s unmap [0x%lx - 0x%lx]"
vfio_region_sparse_mmap_header(const char *name, int index, int nr_areas) "Device %s region %d: %d sparse mmap entries"
vfio_region_sparse_mmap_entry(int i, unsigned long start, unsigned long end) "sparse entry %d [0x%lx - 0x%lx]"
vfio_get_dev_region(const char *name, int index, uint32_t type, uint32_t subtype) "%s index %d, %08x/%0x8"
diff --git a/include/hw/vfio/vfio-common.h b/include/hw/vfio/vfio-common.h
index a88b69b6750e..ef078cf60ef9 100644
--- a/include/hw/vfio/vfio-common.h
+++ b/include/hw/vfio/vfio-common.h
@@ -176,6 +176,7 @@ int vfio_region_setup(Object *obj, VFIODevice *vbasedev, VFIORegion *region,
int index, const char *name);
int vfio_region_mmap(VFIORegion *region);
void vfio_region_mmaps_set_enabled(VFIORegion *region, bool enabled);
+void vfio_region_unmap(VFIORegion *region);
void vfio_region_exit(VFIORegion *region);
void vfio_region_finalize(VFIORegion *region);
void vfio_reset_handler(void *opaque);
--
2.7.0
^ permalink raw reply related
* [Intel-wired-lan] [jkirsher-next-queue:dev-queue] BUILD SUCCESS 15bf1c7414b1772b87f534ce5287fd47ec077ddc
From: kbuild test robot @ 2019-06-20 15:11 UTC (permalink / raw)
To: intel-wired-lan
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue.git dev-queue
branch HEAD: 15bf1c7414b1772b87f534ce5287fd47ec077ddc e1000e: Make watchdog use delayed work
elapsed time: 439m
configs tested: 184
The following configs have been built successfully.
More configs may be tested in the coming days.
x86_64 randconfig-x012-201924
x86_64 randconfig-x014-201924
x86_64 randconfig-x011-201924
x86_64 randconfig-x013-201924
x86_64 randconfig-x019-201924
x86_64 randconfig-x015-201924
x86_64 randconfig-x010-201924
x86_64 randconfig-x017-201924
x86_64 randconfig-x016-201924
x86_64 randconfig-x018-201924
openrisc or1ksim_defconfig
um i386_defconfig
um x86_64_defconfig
m68k allmodconfig
m68k m5475evb_defconfig
m68k multi_defconfig
m68k sun3_defconfig
arm allmodconfig
arm64 allmodconfig
arm allnoconfig
arm at91_dt_defconfig
arm efm32_defconfig
arm exynos_defconfig
arm multi_v5_defconfig
arm multi_v7_defconfig
arm shmobile_defconfig
arm sunxi_defconfig
arm64 allnoconfig
arm64 allyesconfig
arm64 defconfig
powerpc allnoconfig
powerpc defconfig
powerpc ppc64_defconfig
s390 debug_defconfig
sh allmodconfig
sh titan_defconfig
sh rsk7269_defconfig
sh sh7785lcr_32bit_defconfig
sh allnoconfig
x86_64 allmodconfig
x86_64 allyesconfig
i386 alldefconfig
nds32 allnoconfig
nds32 defconfig
sparc defconfig
sparc64 allmodconfig
sparc64 allnoconfig
sparc64 defconfig
x86_64 acpi-redef
x86_64 allyesdebian
x86_64 lkp
x86_64 nfsroot
x86_64 rhel
x86_64 rhel-7.6
c6x evmc6678_defconfig
xtensa common_defconfig
xtensa iss_defconfig
nios2 10m50_defconfig
h8300 h8300h-sim_defconfig
x86_64 fedora-25
x86_64 kexec
mips 32r2_defconfig
mips 64r6el_defconfig
mips allmodconfig
mips allnoconfig
mips fuloong2e_defconfig
mips jz4740
mips malta_kvm_defconfig
mips txx9
i386 randconfig-n004-201924
x86_64 randconfig-n023-201924
i386 randconfig-n005-201924
x86_64 randconfig-n022-201924
i386 randconfig-n025-201924
x86_64 randconfig-n006-201924
x86_64 randconfig-n014-201924
x86_64 randconfig-n012-201924
x86_64 randconfig-n032-201924
x86_64 randconfig-n013-201924
i386 randconfig-n008-201924
x86_64 randconfig-n016-201924
i386 randconfig-n028-201924
i386 randconfig-n011-201924
i386 randconfig-n023-201924
i386 randconfig-n031-201924
x86_64 randconfig-n030-201924
i386 randconfig-n029-201924
i386 randconfig-n010-201924
i386 randconfig-n024-201924
x86_64 randconfig-n007-201924
i386 randconfig-n030-201924
x86_64 randconfig-n031-201924
i386 randconfig-n013-201924
x86_64 randconfig-n009-201924
x86_64 randconfig-n028-201924
x86_64 randconfig-n011-201924
i386 randconfig-n021-201924
i386 randconfig-n018-201924
x86_64 randconfig-n002-201924
i386 randconfig-n014-201924
i386 randconfig-n002-201924
x86_64 randconfig-n025-201924
i386 randconfig-n009-201924
x86_64 randconfig-n017-201924
i386 randconfig-n003-201924
x86_64 randconfig-n024-201924
x86_64 randconfig-n029-201924
x86_64 randconfig-n010-201924
x86_64 randconfig-n027-201924
i386 randconfig-n012-201924
x86_64 randconfig-n008-201924
x86_64 randconfig-n015-201924
i386 randconfig-n015-201924
i386 randconfig-n007-201924
x86_64 randconfig-n020-201924
x86_64 randconfig-n019-201924
i386 randconfig-n017-201924
i386 randconfig-n016-201924
i386 randconfig-n020-201924
i386 randconfig-n019-201924
x86_64 randconfig-n003-201924
i386 randconfig-n001-201924
x86_64 randconfig-n026-201924
i386 randconfig-n026-201924
x86_64 randconfig-n005-201924
i386 randconfig-n006-201924
x86_64 randconfig-n021-201924
x86_64 randconfig-n018-201924
i386 randconfig-n027-201924
x86_64 randconfig-n004-201924
i386 randconfig-n022-201924
x86_64 randconfig-n001-201924
i386 randconfig-n032-201924
riscv allnoconfig
riscv defconfig
parisc c3000_defconfig
um defconfig
parisc b180_defconfig
parisc defconfig
alpha defconfig
parisc allnoconfig
alpha allyesconfig
riscv tinyconfig
i386 tinyconfig
sparc64 allyesconfig
i386 allmodconfig
microblaze mmu_defconfig
microblaze nommu_defconfig
x86_64 randconfig-x000-201924
x86_64 randconfig-x001-201924
x86_64 randconfig-x002-201924
x86_64 randconfig-x003-201924
x86_64 randconfig-x004-201924
x86_64 randconfig-x005-201924
x86_64 randconfig-x006-201924
x86_64 randconfig-x007-201924
x86_64 randconfig-x008-201924
x86_64 randconfig-x009-201924
ia64 alldefconfig
ia64 allmodconfig
ia64 allnoconfig
ia64 defconfig
i386 randconfig-x009-201924
i386 randconfig-x004-201924
i386 randconfig-x005-201924
i386 randconfig-x008-201924
i386 randconfig-x006-201924
i386 randconfig-x001-201924
i386 randconfig-x007-201924
i386 randconfig-x000-201924
i386 randconfig-x002-201924
i386 randconfig-x003-201924
i386 randconfig-x071-201924
i386 randconfig-x070-201924
i386 randconfig-x073-201924
i386 randconfig-x078-201924
i386 randconfig-x074-201924
i386 randconfig-x072-201924
i386 randconfig-x075-201924
i386 randconfig-x077-201924
i386 randconfig-x076-201924
i386 randconfig-x079-201924
i386 allnoconfig
i386 defconfig
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
^ permalink raw reply
* Re: drm connectors, tegra, and the web they weave (was Re: [PATCH 58/59] drm/todo: Add new debugfs todo)
From: Thierry Reding @ 2019-06-20 15:11 UTC (permalink / raw)
To: Daniel Vetter
Cc: Greg Kroah-Hartman, Intel Graphics Development, DRI Development,
Jonathan Hunter, linux-tegra, Daniel Vetter
In-Reply-To: <CAKMK7uEd0sZ81RMjDsz6cnkW+krPuvoqUcEY4U3ofB9W_qeFvA@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 10888 bytes --]
On Tue, Jun 18, 2019 at 07:32:20PM +0200, Daniel Vetter wrote:
> On Tue, Jun 18, 2019 at 5:25 PM Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> > On Tue, Jun 18, 2019 at 05:19:38PM +0200, Greg Kroah-Hartman wrote:
> > > On Fri, Jun 14, 2019 at 10:36:14PM +0200, Daniel Vetter wrote:
> > > > Greg is busy already, but maybe he won't do everything ...
> > > >
> > > > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > > > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> > > > ---
> > > > Documentation/gpu/todo.rst | 3 +++
> > > > 1 file changed, 3 insertions(+)
> > > >
> > > > diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
> > > > index 9717540ee28f..026e55c517e1 100644
> > > > --- a/Documentation/gpu/todo.rst
> > > > +++ b/Documentation/gpu/todo.rst
> > > > @@ -375,6 +375,9 @@ There's a bunch of issues with it:
> > > > this (together with the drm_minor->drm_device move) would allow us to remove
> > > > debugfs_init.
> > > >
> > > > +- Drop the return code and error checking from all debugfs functions. Greg KH is
> > > > + working on this already.
> > >
> > >
> > > Part of this work was to try to delete drm_debugfs_remove_files().
> > >
> > > There are only 4 files that currently still call this function:
> > > drivers/gpu/drm/tegra/dc.c
> > > drivers/gpu/drm/tegra/dsi.c
> > > drivers/gpu/drm/tegra/hdmi.c
> > > drivers/gpu/drm/tegra/sor.c
> > >
> > > For dc.c, the driver wants to add debugfs files to the struct drm_crtc
> > > debugfs directory. Which is fine, but it has to do some special memory
> > > allocation to get the debugfs callback to point not to the struct
> > > drm_minor pointer, but rather the drm_crtc structure.
>
> There's already a todo to switch the drm_minor debugfs stuff over to
> drm_device. drm_minor is essentially different uapi flavours (/dev/
> minor nodes, hence the name) sitting on top of the same drm_device.
> Last time I checked all the debugfs files want the drm_device, not the
> minor. I think we even discussed to only register the debugfs files
> for the first minor, and create the other ones as symlinks to the
> first one. But haven't yet gotten around to typing that.
>
> drm_crtc/connector are parts of drm_device with modesetting support,
> so the drm_minor is even worse choice really.
For the connector drivers we already sit on top of the per-connector
debugfs directories. I think the only reason why we don't do that for
the display controller is because drm_crtc didn't have built-in debugfs
support like the connectors have. It looks like that's no longer true,
though it's been there for a while. I think it'd be good to just move
those over as well.
As for passing struct drm_minor, I think that's mostly unnecessary. As
far as I can tell, we only use drm_minor to get at drm_device, which in
turn we only use to check some features flags, and drm_minor itself is
only used to track the list of files that are being added so that they
can later be removed again. Given that we can just tear down everything
debugfs recursively, I don't think we need any of that.
>
> Not exactly sure why we went with this, but probably dates back to the
> *bsd compat layer and a lot of these files hanging out in procfs too
> (we've fixed those mistakes a few years ago, yay!).
>
> > > So, to remove this call, I need to remove this special memory allocation
> > > and to do that, I need to somehow be able to cast from drm_minor back to
> > > the drm_crtc structure being used in this driver. And I can't figure
> > > how they are related at all.
> > >
> > > Any pointers here (pun intended) would be appreciated.
> > >
> > > For the other 3 files, the situation is much the same, but I need to get
> > > from a 'struct drm_minor' pointer to a 'struct drm_connector' pointer.
>
> Ditch the drm_minor, there's no no way to get from that to something
> like drm_connector/crtc, since it's a n:m relationship.
Yeah. That too.
> > > I could just "open code" a bunch of calls to debugfs_create_file() for
> > > these drivers, which would solve this issue, but in a more "non-drm"
> > > way. Is it worth to just do that instead of overthinking the whole
> > > thing and trying to squish it into the drm "model" of drm debugfs calls?
> >
> > An example of "open coding" this is the patch below for the sor.c
> > driver.
>
> I think open-coding is the way to go here. One of the todos is to
> extend debugfs support for crtc/connectors, but looking at the
> open-coded version we really don't need a drm-flavoured midlayer here.
Exactly my thoughts. It'd be nice to have some sort of macro to help
bring the boilerplate down a bit.
Thierry
> > Totally untested, not even built, but you should get the idea here.
> >
> > thanks,
> >
> > greg k-h
> >
> > ---------------
> >
> > diff --git a/drivers/gpu/drm/tegra/sor.c b/drivers/gpu/drm/tegra/sor.c
> > index 5be5a0817dfe..3216221c77c4 100644
> > --- a/drivers/gpu/drm/tegra/sor.c
> > +++ b/drivers/gpu/drm/tegra/sor.c
> > @@ -414,7 +414,8 @@ struct tegra_sor {
> >
> > struct drm_dp_aux *aux;
> >
> > - struct drm_info_list *debugfs_files;
> > + struct dentry *debugfs_root;
> > + struct drm_device *drm;
> >
> > const struct tegra_sor_ops *ops;
> > enum tegra_io_pad pad;
> > @@ -1262,10 +1263,9 @@ static int tegra_sor_crc_wait(struct tegra_sor *sor, unsigned long timeout)
> >
> > static int tegra_sor_show_crc(struct seq_file *s, void *data)
> > {
> > - struct drm_info_node *node = s->private;
> > - struct tegra_sor *sor = node->info_ent->data;
> > + struct tegra_sor *sor = s->private;
> > struct drm_crtc *crtc = sor->output.encoder.crtc;
> > - struct drm_device *drm = node->minor->dev;
> > + struct drm_device *drm = sor->drm;
> > int err = 0;
> > u32 value;
> >
> > @@ -1302,6 +1302,20 @@ static int tegra_sor_show_crc(struct seq_file *s, void *data)
> > return err;
> > }
> >
> > +static int crc_open(struct inode *inode, struct file *file)
> > +{
> > + struct tegra_sor *sor = inode->i_private;
> > + return single_open(file, tegra_sor_show_crc, sor);
> > +}
> > +
> > +static const struct file_operations crc_fops = {
> > + .owner = THIS_MODULE,
> > + .open = crc_open,
> > + .read = seq_read,
> > + .llseek = seq_lseek,
> > + .release = single_release,
> > +};
>
> Hm, is there not a macro to create such simple files with read/write
> ops? At least for sysfs this is a bit less boilerplate iirc.
>
> > +
> > #define DEBUGFS_REG32(_name) { .name = #_name, .offset = _name }
> >
> > static const struct debugfs_reg32 tegra_sor_regs[] = {
> > @@ -1424,10 +1438,9 @@ static const struct debugfs_reg32 tegra_sor_regs[] = {
> >
> > static int tegra_sor_show_regs(struct seq_file *s, void *data)
> > {
> > - struct drm_info_node *node = s->private;
> > - struct tegra_sor *sor = node->info_ent->data;
> > + struct tegra_sor *sor = s->private;
> > struct drm_crtc *crtc = sor->output.encoder.crtc;
> > - struct drm_device *drm = node->minor->dev;
> > + struct drm_device *drm = sor->drm;
>
> sor->output.connector.dev should give you this already. And I think
> getting at the drm_device is the only reason we needed the drm_minor
> here at all.
>
> > unsigned int i;
> > int err = 0;
> >
> > @@ -1450,51 +1463,44 @@ static int tegra_sor_show_regs(struct seq_file *s, void *data)
> > return err;
> > }
> >
> > -static const struct drm_info_list debugfs_files[] = {
> > - { "crc", tegra_sor_show_crc, 0, NULL },
> > - { "regs", tegra_sor_show_regs, 0, NULL },
> > +static int regs_open(struct inode *inode, struct file *file)
> > +{
> > + struct tegra_sor *sor = inode->i_private;
> > + return single_open(file, tegra_sor_show_regs, sor);
> > +}
> > +
> > +static const struct file_operations crc_fops = {
> > + .owner = THIS_MODULE,
> > + .open = crc_open,
> > + .read = seq_read,
> > + .llseek = seq_lseek,
> > + .release = single_release,
> > };
> >
> > static int tegra_sor_late_register(struct drm_connector *connector)
> > {
> > - struct tegra_output *output = connector_to_output(connector);
> > - unsigned int i, count = ARRAY_SIZE(debugfs_files);
> > struct drm_minor *minor = connector->dev->primary;
> > - struct dentry *root = connector->debugfs_entry;
> > + struct tegra_output *output = connector_to_output(connector);
> > struct tegra_sor *sor = to_sor(output);
> > - int err;
> > + struct dentry *root;
> >
> > - sor->debugfs_files = kmemdup(debugfs_files, sizeof(debugfs_files),
> > - GFP_KERNEL);
> > - if (!sor->debugfs_files)
> > - return -ENOMEM;
> > + sor->drm = minor->dev;
> >
> > - for (i = 0; i < count; i++)
> > - sor->debugfs_files[i].data = sor;
> > + root = debugfs_create_dir("sor", connector->debugfs_entry);
>
> Hm I think the old files got created right in the
> drm_connector->debugfs_entry directory?
>
> > + sor->debugfs_root = root;
> >
> > - err = drm_debugfs_create_files(sor->debugfs_files, count, root, minor);
> > - if (err < 0)
> > - goto free;
> > + debugfs_create_file("crc", S_IFREG | S_IRUGO, root, sor, &crc_fops);
> > + debugfs_create_file("regs", S_IFREG | S_IRUGO, root, sor, ®s_fops);
> >
> > return 0;
> > -
> > -free:
> > - kfree(sor->debugfs_files);
> > - sor->debugfs_files = NULL;
> > -
> > - return err;
> > }
>
> I think if you can create a debugfs-simple-file macro, this here would
> win hands-down from a boilerplate pov. I like.
I fully agree with this and all of your points above.
> > static void tegra_sor_early_unregister(struct drm_connector *connector)
> > {
> > struct tegra_output *output = connector_to_output(connector);
> > - unsigned int count = ARRAY_SIZE(debugfs_files);
> > struct tegra_sor *sor = to_sor(output);
> >
> > - drm_debugfs_remove_files(sor->debugfs_files, count,
> > - connector->dev->primary);
> > - kfree(sor->debugfs_files);
> > - sor->debugfs_files = NULL;
> > + debugfs_remove_recursive(sor->debugfs_root);
>
> Not needed, we tear down everything as part of drm_dev_unregister
> anyway. So you can ditch this.
And this. Greg, let me know if you need a hand with the patches or if
you want any of these to be build/runtime tested.
Thierry
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH v5 2/7] i2c: acpi: Use available IRQ helper functions
From: Charles Keepax @ 2019-06-20 15:11 UTC (permalink / raw)
To: Andy Shevchenko
Cc: wsa, mika.westerberg, jarkko.nikula, linux-i2c, linux-acpi,
linux-kernel, benjamin.tissoires, jbroadus, patches
In-Reply-To: <20190620145221.GC9224@smile.fi.intel.com>
On Thu, Jun 20, 2019 at 05:52:21PM +0300, Andy Shevchenko wrote:
> On Thu, Jun 20, 2019 at 02:34:15PM +0100, Charles Keepax wrote:
> > Use the available IRQ helper functions, most of the functions have
> > additional helpful side affects like configuring the trigger type of the
> > IRQ.
> >
> > Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
> > Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> > Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
>
> Some last minute observations / questions.
>
> > + struct resource r;
> > +
> > + if (*irq <= 0 && acpi_dev_resource_interrupt(ares, 0, &r))
> > + *irq = i2c_dev_irq_from_resources(&r, 1);
> > +
> > + return 1; /* No need to add resource to the list */
>
> If we don't add it to the list, do we still need to manage the empty
> resource_list below?
>
I think you are right looking closely I think we can skip this. I
might update the comment here to make it clear the list needs
freed if this is changed though.
> > /* Then fill IRQ number if any */
> > INIT_LIST_HEAD(&resource_list);
> > - ret = acpi_dev_get_resources(adev, &resource_list, NULL, NULL);
> > + ret = acpi_dev_get_resources(adev, &resource_list,
> > + i2c_acpi_add_resource, &irq);
> > if (ret < 0)
> > return -EINVAL;
> >
> > - resource_list_for_each_entry(entry, &resource_list) {
> > - if (resource_type(entry->res) == IORESOURCE_IRQ) {
> > - info->irq = entry->res->start;
> > - break;
> > - }
> > - }
>
> > + if (irq > 0)
> > + info->irq = irq;
>
> Hmm... can't we just assign it directly inside the _add_resource() call back as
> original code did?
>
Again I think you are correct here, my thinking had been to
preserve the original functionality of only overwriting the value
in info->irq if we found one. But it looks like all callers don't
pass anything meaningful in this field so changing that behaviour
shouldn't matter.
Thanks,
Charles
^ permalink raw reply
* [Qemu-devel] [PATCH v4 07/13] vfio: Register SaveVMHandlers for VFIO device
From: Kirti Wankhede @ 2019-06-20 14:37 UTC (permalink / raw)
To: alex.williamson, cjia
Cc: Kirti Wankhede, Zhengxiao.zx, kevin.tian, yi.l.liu, yan.y.zhao,
eskultet, ziye.yang, qemu-devel, cohuck, shuangtai.tst, dgilbert,
zhi.a.wang, mlevitsk, pasic, aik, yulei.zhang, eauger, felipe,
jonathan.davies, changpeng.liu, Ken.Xue
In-Reply-To: <1561041461-22326-1-git-send-email-kwankhede@nvidia.com>
Define flags to be used as delimeter in migration file stream.
Added .save_setup and .save_cleanup functions. Mapped & unmapped migration
region from these functions at source during saving or pre-copy phase.
Set VFIO device state depending on VM's state. During live migration, VM is
running when .save_setup is called, _SAVING | _RUNNING state is set for VFIO
device. During save-restore, VM is paused, _SAVING state is set for VFIO device.
Signed-off-by: Kirti Wankhede <kwankhede@nvidia.com>
Reviewed-by: Neo Jia <cjia@nvidia.com>
---
hw/vfio/migration.c | 76 ++++++++++++++++++++++++++++++++++++++++++++++++++++-
1 file changed, 75 insertions(+), 1 deletion(-)
diff --git a/hw/vfio/migration.c b/hw/vfio/migration.c
index 7f9858e6c995..fe0887c27664 100644
--- a/hw/vfio/migration.c
+++ b/hw/vfio/migration.c
@@ -22,6 +22,17 @@
#include "exec/ram_addr.h"
#include "pci.h"
+/*
+ * Flags used as delimiter:
+ * 0xffffffff => MSB 32-bit all 1s
+ * 0xef10 => emulated (virtual) function IO
+ * 0x0000 => 16-bits reserved for flags
+ */
+#define VFIO_MIG_FLAG_END_OF_STATE (0xffffffffef100001ULL)
+#define VFIO_MIG_FLAG_DEV_CONFIG_STATE (0xffffffffef100002ULL)
+#define VFIO_MIG_FLAG_DEV_SETUP_STATE (0xffffffffef100003ULL)
+#define VFIO_MIG_FLAG_DEV_DATA_STATE (0xffffffffef100004ULL)
+
static void vfio_migration_region_exit(VFIODevice *vbasedev)
{
VFIOMigration *migration = vbasedev->migration;
@@ -96,6 +107,69 @@ static int vfio_migration_set_state(VFIODevice *vbasedev, uint32_t state)
return 0;
}
+/* ---------------------------------------------------------------------- */
+
+static int vfio_save_setup(QEMUFile *f, void *opaque)
+{
+ VFIODevice *vbasedev = opaque;
+ VFIOMigration *migration = vbasedev->migration;
+ int ret;
+
+ qemu_put_be64(f, VFIO_MIG_FLAG_DEV_SETUP_STATE);
+
+ if (migration->region.buffer.mmaps) {
+ qemu_mutex_lock_iothread();
+ ret = vfio_region_mmap(&migration->region.buffer);
+ qemu_mutex_unlock_iothread();
+ if (ret) {
+ error_report("Failed to mmap VFIO migration region %d: %s",
+ migration->region.index, strerror(-ret));
+ return ret;
+ }
+ }
+
+ if (vbasedev->vm_running) {
+ ret = vfio_migration_set_state(vbasedev,
+ VFIO_DEVICE_STATE_RUNNING | VFIO_DEVICE_STATE_SAVING);
+ if (ret) {
+ error_report("Failed to set state RUNNING and SAVING");
+ return ret;
+ }
+ } else {
+ ret = vfio_migration_set_state(vbasedev, VFIO_DEVICE_STATE_SAVING);
+ if (ret) {
+ error_report("Failed to set state STOP and SAVING");
+ return ret;
+ }
+ }
+
+ qemu_put_be64(f, VFIO_MIG_FLAG_END_OF_STATE);
+
+ ret = qemu_file_get_error(f);
+ if (ret) {
+ return ret;
+ }
+
+ return 0;
+}
+
+static void vfio_save_cleanup(void *opaque)
+{
+ VFIODevice *vbasedev = opaque;
+ VFIOMigration *migration = vbasedev->migration;
+
+ if (migration->region.buffer.mmaps) {
+ vfio_region_unmap(&migration->region.buffer);
+ }
+}
+
+static SaveVMHandlers savevm_vfio_handlers = {
+ .save_setup = vfio_save_setup,
+ .save_cleanup = vfio_save_cleanup,
+};
+
+/* ---------------------------------------------------------------------- */
+
static void vfio_vmstate_change(void *opaque, int running, RunState state)
{
VFIODevice *vbasedev = opaque;
@@ -169,7 +243,7 @@ static int vfio_migration_init(VFIODevice *vbasedev,
}
qemu_mutex_init(&vbasedev->migration->lock);
-
+ register_savevm_live(NULL, "vfio", -1, 1, &savevm_vfio_handlers, vbasedev);
vbasedev->vm_state = qemu_add_vm_change_state_handler(vfio_vmstate_change,
vbasedev);
--
2.7.0
^ permalink raw reply related
* [Qemu-devel] [PATCH v4 08/13] vfio: Add save state functions to SaveVMHandlers
From: Kirti Wankhede @ 2019-06-20 14:37 UTC (permalink / raw)
To: alex.williamson, cjia
Cc: Kirti Wankhede, Zhengxiao.zx, kevin.tian, yi.l.liu, yan.y.zhao,
eskultet, ziye.yang, qemu-devel, cohuck, shuangtai.tst, dgilbert,
zhi.a.wang, mlevitsk, pasic, aik, yulei.zhang, eauger, felipe,
jonathan.davies, changpeng.liu, Ken.Xue
In-Reply-To: <1561041461-22326-1-git-send-email-kwankhede@nvidia.com>
Added .save_live_pending, .save_live_iterate and .save_live_complete_precopy
functions. These functions handles pre-copy and stop-and-copy phase.
In _SAVING|_RUNNING device state or pre-copy phase:
- read pending_bytes
- read data_offset - indicates kernel driver to write data to staging
buffer which is mmapped.
- read data_size - amount of data in bytes written by vendor driver in migration
region.
- if data section is trapped, pread() number of bytes in data_size, from
data_offset.
- if data section is mmaped, read mmaped buffer of size data_size.
- Write data packet to file stream as below:
{VFIO_MIG_FLAG_DEV_DATA_STATE, data_size, actual data,
VFIO_MIG_FLAG_END_OF_STATE }
In _SAVING device state or stop-and-copy phase
a. read config space of device and save to migration file stream. This
doesn't need to be from vendor driver. Any other special config state
from driver can be saved as data in following iteration.
b. read pending_bytes - indicates kernel driver to write data to staging
buffer which is mmapped.
c. read data_size - amount of data in bytes written by vendor driver in
migration region.
d. if data section is trapped, pread() from data_offset of size data_size.
e. if data section is mmaped, read mmaped buffer of size data_size.
f. Write data packet as below:
{VFIO_MIG_FLAG_DEV_DATA_STATE, data_size, actual data}
g. iterate through steps b to f until (pending_bytes > 0)
h. Write {VFIO_MIG_FLAG_END_OF_STATE}
.save_live_iterate runs outside the iothread lock in the migration case, which
could race with asynchronous call to get dirty page list causing data corruption
in mapped migration region. Mutex added here to serial migration buffer read
operation.
Signed-off-by: Kirti Wankhede <kwankhede@nvidia.com>
Reviewed-by: Neo Jia <cjia@nvidia.com>
---
hw/vfio/migration.c | 212 ++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 212 insertions(+)
diff --git a/hw/vfio/migration.c b/hw/vfio/migration.c
index fe0887c27664..0a2f30872316 100644
--- a/hw/vfio/migration.c
+++ b/hw/vfio/migration.c
@@ -107,6 +107,111 @@ static int vfio_migration_set_state(VFIODevice *vbasedev, uint32_t state)
return 0;
}
+static int vfio_save_buffer(QEMUFile *f, VFIODevice *vbasedev)
+{
+ VFIOMigration *migration = vbasedev->migration;
+ VFIORegion *region = &migration->region.buffer;
+ uint64_t data_offset = 0, data_size = 0;
+ int ret;
+
+ ret = pread(vbasedev->fd, &data_offset, sizeof(data_offset),
+ region->fd_offset + offsetof(struct vfio_device_migration_info,
+ data_offset));
+ if (ret != sizeof(data_offset)) {
+ error_report("Failed to get migration buffer data offset %d",
+ ret);
+ return -EINVAL;
+ }
+
+ ret = pread(vbasedev->fd, &data_size, sizeof(data_size),
+ region->fd_offset + offsetof(struct vfio_device_migration_info,
+ data_size));
+ if (ret != sizeof(data_size)) {
+ error_report("Failed to get migration buffer data size %d",
+ ret);
+ return -EINVAL;
+ }
+
+ if (data_size > 0) {
+ void *buf = NULL;
+ bool buffer_mmaped = false;
+
+ if (region->mmaps) {
+ int i;
+
+ for (i = 0; i < region->nr_mmaps; i++) {
+ if ((data_offset >= region->mmaps[i].offset) &&
+ (data_offset < region->mmaps[i].offset +
+ region->mmaps[i].size)) {
+ buf = region->mmaps[i].mmap + (data_offset -
+ region->mmaps[i].offset);
+ buffer_mmaped = true;
+ break;
+ }
+ }
+ }
+
+ if (!buffer_mmaped) {
+ buf = g_malloc0(data_size);
+ ret = pread(vbasedev->fd, buf, data_size,
+ region->fd_offset + data_offset);
+ if (ret != data_size) {
+ error_report("Failed to get migration data %d", ret);
+ g_free(buf);
+ return -EINVAL;
+ }
+ }
+
+ qemu_put_be64(f, data_size);
+ qemu_put_buffer(f, buf, data_size);
+
+ if (!buffer_mmaped) {
+ g_free(buf);
+ }
+ migration->pending_bytes -= data_size;
+ } else {
+ qemu_put_be64(f, data_size);
+ }
+
+ ret = qemu_file_get_error(f);
+
+ return data_size;
+}
+
+static int vfio_update_pending(VFIODevice *vbasedev)
+{
+ VFIOMigration *migration = vbasedev->migration;
+ VFIORegion *region = &migration->region.buffer;
+ uint64_t pending_bytes = 0;
+ int ret;
+
+ ret = pread(vbasedev->fd, &pending_bytes, sizeof(pending_bytes),
+ region->fd_offset + offsetof(struct vfio_device_migration_info,
+ pending_bytes));
+ if ((ret < 0) || (ret != sizeof(pending_bytes))) {
+ error_report("Failed to get pending bytes %d", ret);
+ migration->pending_bytes = 0;
+ return (ret < 0) ? ret : -EINVAL;
+ }
+
+ migration->pending_bytes = pending_bytes;
+ return 0;
+}
+
+static int vfio_save_device_config_state(QEMUFile *f, void *opaque)
+{
+ VFIODevice *vbasedev = opaque;
+
+ qemu_put_be64(f, VFIO_MIG_FLAG_DEV_CONFIG_STATE);
+
+ if (vbasedev->type == VFIO_DEVICE_TYPE_PCI) {
+ vfio_pci_save_config(vbasedev, f);
+ }
+ qemu_put_be64(f, VFIO_MIG_FLAG_END_OF_STATE);
+
+ return qemu_file_get_error(f);
+}
+
/* ---------------------------------------------------------------------- */
static int vfio_save_setup(QEMUFile *f, void *opaque)
@@ -163,9 +268,116 @@ static void vfio_save_cleanup(void *opaque)
}
}
+static void vfio_save_pending(QEMUFile *f, void *opaque,
+ uint64_t threshold_size,
+ uint64_t *res_precopy_only,
+ uint64_t *res_compatible,
+ uint64_t *res_postcopy_only)
+{
+ VFIODevice *vbasedev = opaque;
+ VFIOMigration *migration = vbasedev->migration;
+ int ret;
+
+ ret = vfio_update_pending(vbasedev);
+ if (ret) {
+ return;
+ }
+
+ if (vbasedev->device_state & VFIO_DEVICE_STATE_RUNNING) {
+ *res_precopy_only += migration->pending_bytes;
+ } else {
+ *res_postcopy_only += migration->pending_bytes;
+ }
+ *res_compatible += 0;
+}
+
+static int vfio_save_iterate(QEMUFile *f, void *opaque)
+{
+ VFIODevice *vbasedev = opaque;
+ VFIOMigration *migration = vbasedev->migration;
+ int ret;
+
+ qemu_put_be64(f, VFIO_MIG_FLAG_DEV_DATA_STATE);
+
+ qemu_mutex_lock(&migration->lock);
+ ret = vfio_save_buffer(f, vbasedev);
+ qemu_mutex_unlock(&migration->lock);
+
+ if (ret < 0) {
+ error_report("vfio_save_buffer failed %s",
+ strerror(errno));
+ return ret;
+ }
+
+ qemu_put_be64(f, VFIO_MIG_FLAG_END_OF_STATE);
+
+ ret = qemu_file_get_error(f);
+ if (ret) {
+ return ret;
+ }
+
+ return ret;
+}
+
+static int vfio_save_complete_precopy(QEMUFile *f, void *opaque)
+{
+ VFIODevice *vbasedev = opaque;
+ VFIOMigration *migration = vbasedev->migration;
+ int ret;
+
+ ret = vfio_migration_set_state(vbasedev, VFIO_DEVICE_STATE_SAVING);
+ if (ret) {
+ error_report("Failed to set state STOP and SAVING");
+ return ret;
+ }
+
+ ret = vfio_save_device_config_state(f, opaque);
+ if (ret) {
+ return ret;
+ }
+
+ ret = vfio_update_pending(vbasedev);
+ if (ret) {
+ return ret;
+ }
+
+ while (migration->pending_bytes > 0) {
+ qemu_put_be64(f, VFIO_MIG_FLAG_DEV_DATA_STATE);
+ ret = vfio_save_buffer(f, vbasedev);
+ if (ret < 0) {
+ error_report("Failed to save buffer");
+ return ret;
+ } else if (ret == 0) {
+ break;
+ }
+
+ ret = vfio_update_pending(vbasedev);
+ if (ret) {
+ return ret;
+ }
+ }
+
+ qemu_put_be64(f, VFIO_MIG_FLAG_END_OF_STATE);
+
+ ret = qemu_file_get_error(f);
+ if (ret) {
+ return ret;
+ }
+
+ ret = vfio_migration_set_state(vbasedev, VFIO_DEVICE_STATE_STOPPED);
+ if (ret) {
+ error_report("Failed to set state STOPPED");
+ return ret;
+ }
+ return ret;
+}
+
static SaveVMHandlers savevm_vfio_handlers = {
.save_setup = vfio_save_setup,
.save_cleanup = vfio_save_cleanup,
+ .save_live_pending = vfio_save_pending,
+ .save_live_iterate = vfio_save_iterate,
+ .save_live_complete_precopy = vfio_save_complete_precopy,
};
/* ---------------------------------------------------------------------- */
--
2.7.0
^ permalink raw reply related
* [Buildroot] [git commit] toolchain: introduce BR2_TOOLCHAIN_HAS_GCC_BUG_90620
From: Thomas Petazzoni @ 2019-06-20 15:10 UTC (permalink / raw)
To: buildroot
commit: https://git.buildroot.net/buildroot/commit/?id=efc53530cb30c97f849e5bfae5dca711a263199c
branch: https://git.buildroot.net/buildroot/commit/?id=refs/heads/master
GCC fails building the haproxy package for the Microblaze architecture:
http://autobuild.buildroot.org/results/64706f96db793777de9d3ec63b0a47d776cf33fd/
The gcc bug was originally reported gpsd:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90620
This gcc bug no longer appeared with gcc 8.x but reappeared in gcc
9.x, so we introduce a config symbol so that packages can work it
around by disabling optimization.
Signed-off-by: Giulio Benetti <giulio.benetti@micronovasrl.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
---
toolchain/Config.in | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/toolchain/Config.in b/toolchain/Config.in
index 2da537e7d4..7cdcb0e514 100644
--- a/toolchain/Config.in
+++ b/toolchain/Config.in
@@ -145,6 +145,14 @@ config BR2_TOOLCHAIN_HAS_GCC_BUG_85862
default y if BR2_microblaze
depends on !BR2_TOOLCHAIN_GCC_AT_LEAST_7
+# https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90620
+# ICE: in do_output_reload, at reload1.c:7978 on microblaze.
+# It's been fixed on Gcc 8.x but reappeared on Gcc 9.x
+config BR2_TOOLCHAIN_HAS_GCC_BUG_90620
+ bool
+ default y if BR2_microblaze
+ depends on !BR2_TOOLCHAIN_GCC_AT_LEAST_8 || BR2_TOOLCHAIN_GCC_AT_LEAST_9
+
config BR2_TOOLCHAIN_HAS_NATIVE_RPC
bool
^ permalink raw reply related
* Re: [PATCH RFC] kvm: x86: Expose AVX512_BF16 feature to guest
From: Liu, Jing2 @ 2019-06-20 15:09 UTC (permalink / raw)
To: Paolo Bonzini, kvm; +Cc: linux-kernel, jing2.liu
In-Reply-To: <fd861e94-3ea5-3976-9855-05375f869f00@redhat.com>
Hi Paolo,
On 6/20/2019 8:16 PM, Paolo Bonzini wrote:
> On 20/06/19 13:21, Jing Liu wrote:
>> + for (i = 1; i <= times; i++) {
>> + if (*nent >= maxnent)
>> + goto out;
>> + do_cpuid_1_ent(&entry[i], function, i);
>> + entry[i].eax &= F(AVX512_BF16);
>> + entry[i].ebx = 0;
>> + entry[i].ecx = 0;
>> + entry[i].edx = 0;
>> + entry[i].flags |= KVM_CPUID_FLAG_SIGNIFCANT_INDEX;
>> + ++*nent;
>
> This woud be wrong for i > 1, so instead make this
>
> if (entry->eax >= 1)
>
I am confused about the @index parameter. @index seems not used for
every case except 0x07. Since the caller function only has @index=0, so
all other cases except 0x07 put cpuid info from subleaf=0 to max subleaf.
What do you think about @index in current function? Does it mean, we
need put cpuid from index to max subleaf to @entry[i]? If so, the logic
seems as follows,
if (index == 0) {
// Put subleaf 0 into @entry
// Put subleaf 1 into @entry[1]
} else if (index < entry->eax) {
// Put subleaf 1 into @entry
} else {
// Put all zero into @entry
}
But this seems not identical with other cases, for current caller
function. Or we can simply ignore @index in 0x07 and just put all possible
subleaf info back?
> and define F(AVX512_BF16) as a new constant kvm_cpuid_7_1_eax_features.
>
Got it.
Thanks,
Jing
> Paolo
>
^ permalink raw reply
* Re: [Qemu-devel] [PATCH v17 02/10] ACPI: add some GHES structures and macros definition
From: Igor Mammedov @ 2019-06-20 15:09 UTC (permalink / raw)
To: gengdongjiu
Cc: pbonzini, mst, shannon.zhaosl, peter.maydell, lersek, james.morse,
mtosatti, rth, ehabkost, zhengxiang9, jonathan.cameron, xuwei5,
kvm, qemu-devel, qemu-arm, linuxarm
In-Reply-To: <f4f94ecb-200c-3e18-1a09-5fb6bc761834@huawei.com>
On Thu, 20 Jun 2019 22:04:01 +0800
gengdongjiu <gengdongjiu@huawei.com> wrote:
> Hi Igor,
> Thanks for your review.
>
> On 2019/6/20 20:10, Igor Mammedov wrote:
> >> + */
> >> +struct AcpiGenericErrorStatus {
> >> + /* It is a bitmask composed of ACPI_GEBS_xxx macros */
> >> + uint32_t block_status;
> >> + uint32_t raw_data_offset;
> >> + uint32_t raw_data_length;
> >> + uint32_t data_length;
> >> + uint32_t error_severity;
> >> +} QEMU_PACKED;
> >> +typedef struct AcpiGenericErrorStatus AcpiGenericErrorStatus;
> > there shouldn't be packed structures,
> > is it a leftover from previous version?
>
> I remember some people suggest to add QEMU_PACKED before, anyway I will remove it in my next version patch.
Question is why it's there and where it is used?
BTW:
series doesn't apply to master anymore.
Do you have a repo somewhere available for testing?
>
> >
> >> +
> >> +/*
> >> + * Masks for block_status flags above
> >> + */
> >> +#define ACPI_GEBS_UNCORRECTABLE 1
> >> +
> >> +/*
>
^ permalink raw reply
* [Qemu-devel] [PATCH v4 04/13] vfio: Add migration region initialization and finalize function
From: Kirti Wankhede @ 2019-06-20 14:37 UTC (permalink / raw)
To: alex.williamson, cjia
Cc: Kirti Wankhede, Zhengxiao.zx, kevin.tian, yi.l.liu, yan.y.zhao,
eskultet, ziye.yang, qemu-devel, cohuck, shuangtai.tst, dgilbert,
zhi.a.wang, mlevitsk, pasic, aik, yulei.zhang, eauger, felipe,
jonathan.davies, changpeng.liu, Ken.Xue
In-Reply-To: <1561041461-22326-1-git-send-email-kwankhede@nvidia.com>
- Migration functions are implemented for VFIO_DEVICE_TYPE_PCI device in this
patch series.
- VFIO device supports migration or not is decided based of migration region
query. If migration region query is successful then migration is supported
else migration is blocked.
Signed-off-by: Kirti Wankhede <kwankhede@nvidia.com>
Reviewed-by: Neo Jia <cjia@nvidia.com>
---
hw/vfio/Makefile.objs | 2 +-
hw/vfio/migration.c | 137 ++++++++++++++++++++++++++++++++++++++++++
include/hw/vfio/vfio-common.h | 14 +++++
3 files changed, 152 insertions(+), 1 deletion(-)
create mode 100644 hw/vfio/migration.c
diff --git a/hw/vfio/Makefile.objs b/hw/vfio/Makefile.objs
index abad8b818c9b..36033d1437c5 100644
--- a/hw/vfio/Makefile.objs
+++ b/hw/vfio/Makefile.objs
@@ -1,4 +1,4 @@
-obj-y += common.o spapr.o
+obj-y += common.o spapr.o migration.o
obj-$(CONFIG_VFIO_PCI) += pci.o pci-quirks.o display.o
obj-$(CONFIG_VFIO_CCW) += ccw.o
obj-$(CONFIG_VFIO_PLATFORM) += platform.o
diff --git a/hw/vfio/migration.c b/hw/vfio/migration.c
new file mode 100644
index 000000000000..ba58d9253d26
--- /dev/null
+++ b/hw/vfio/migration.c
@@ -0,0 +1,137 @@
+/*
+ * Migration support for VFIO devices
+ *
+ * Copyright NVIDIA, Inc. 2019
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2. See
+ * the COPYING file in the top-level directory.
+ */
+
+#include "qemu/osdep.h"
+#include <linux/vfio.h>
+
+#include "hw/vfio/vfio-common.h"
+#include "cpu.h"
+#include "migration/migration.h"
+#include "migration/qemu-file.h"
+#include "migration/register.h"
+#include "migration/blocker.h"
+#include "migration/misc.h"
+#include "qapi/error.h"
+#include "exec/ramlist.h"
+#include "exec/ram_addr.h"
+#include "pci.h"
+
+static void vfio_migration_region_exit(VFIODevice *vbasedev)
+{
+ VFIOMigration *migration = vbasedev->migration;
+
+ if (!migration) {
+ return;
+ }
+
+ if (migration->region.buffer.size) {
+ vfio_region_exit(&migration->region.buffer);
+ vfio_region_finalize(&migration->region.buffer);
+ }
+}
+
+static int vfio_migration_region_init(VFIODevice *vbasedev)
+{
+ VFIOMigration *migration = vbasedev->migration;
+ Object *obj = NULL;
+ int ret = -EINVAL;
+
+ if (!migration) {
+ return ret;
+ }
+
+ /* Migration support added for PCI device only */
+ if (vbasedev->type == VFIO_DEVICE_TYPE_PCI) {
+ obj = vfio_pci_get_object(vbasedev);
+ }
+
+ if (!obj) {
+ return ret;
+ }
+
+ ret = vfio_region_setup(obj, vbasedev, &migration->region.buffer,
+ migration->region.index, "migration");
+ if (ret) {
+ error_report("Failed to setup VFIO migration region %d: %s",
+ migration->region.index, strerror(-ret));
+ goto err;
+ }
+
+ if (!migration->region.buffer.size) {
+ ret = -EINVAL;
+ error_report("Invalid region size of VFIO migration region %d: %s",
+ migration->region.index, strerror(-ret));
+ goto err;
+ }
+
+ return 0;
+
+err:
+ vfio_migration_region_exit(vbasedev);
+ return ret;
+}
+
+static int vfio_migration_init(VFIODevice *vbasedev,
+ struct vfio_region_info *info)
+{
+ int ret;
+
+ vbasedev->migration = g_new0(VFIOMigration, 1);
+ vbasedev->migration->region.index = info->index;
+
+ ret = vfio_migration_region_init(vbasedev);
+ if (ret) {
+ error_report("Failed to initialise migration region");
+ return ret;
+ }
+
+ return 0;
+}
+
+/* ---------------------------------------------------------------------- */
+
+int vfio_migration_probe(VFIODevice *vbasedev, Error **errp)
+{
+ struct vfio_region_info *info;
+ int ret;
+
+ ret = vfio_get_dev_region_info(vbasedev, VFIO_REGION_TYPE_MIGRATION,
+ VFIO_REGION_SUBTYPE_MIGRATION, &info);
+ if (ret) {
+ Error *local_err = NULL;
+
+ error_setg(&vbasedev->migration_blocker,
+ "VFIO device doesn't support migration");
+ ret = migrate_add_blocker(vbasedev->migration_blocker, &local_err);
+ if (local_err) {
+ error_propagate(errp, local_err);
+ error_free(vbasedev->migration_blocker);
+ return ret;
+ }
+ } else {
+ return vfio_migration_init(vbasedev, info);
+ }
+
+ return 0;
+}
+
+void vfio_migration_finalize(VFIODevice *vbasedev)
+{
+ if (!vbasedev->migration) {
+ return;
+ }
+
+ if (vbasedev->migration_blocker) {
+ migrate_del_blocker(vbasedev->migration_blocker);
+ error_free(vbasedev->migration_blocker);
+ }
+
+ vfio_migration_region_exit(vbasedev);
+ g_free(vbasedev->migration);
+}
diff --git a/include/hw/vfio/vfio-common.h b/include/hw/vfio/vfio-common.h
index ef078cf60ef9..1374a03470d8 100644
--- a/include/hw/vfio/vfio-common.h
+++ b/include/hw/vfio/vfio-common.h
@@ -57,6 +57,15 @@ typedef struct VFIORegion {
uint8_t nr; /* cache the region number for debug */
} VFIORegion;
+typedef struct VFIOMigration {
+ struct {
+ VFIORegion buffer;
+ uint32_t index;
+ } region;
+ uint64_t pending_bytes;
+ QemuMutex lock;
+} VFIOMigration;
+
typedef struct VFIOAddressSpace {
AddressSpace *as;
QLIST_HEAD(, VFIOContainer) containers;
@@ -118,6 +127,8 @@ typedef struct VFIODevice {
unsigned int num_irqs;
unsigned int num_regions;
unsigned int flags;
+ VFIOMigration *migration;
+ Error *migration_blocker;
} VFIODevice;
struct VFIODeviceOps {
@@ -206,4 +217,7 @@ int vfio_spapr_create_window(VFIOContainer *container,
int vfio_spapr_remove_window(VFIOContainer *container,
hwaddr offset_within_address_space);
+int vfio_migration_probe(VFIODevice *vbasedev, Error **errp);
+void vfio_migration_finalize(VFIODevice *vbasedev);
+
#endif /* HW_VFIO_VFIO_COMMON_H */
--
2.7.0
^ permalink raw reply related
* [PATCH 5/5] ARM: dts: mmp2: specify reg-shift for the UARTs
From: Lubomir Rintel @ 2019-06-20 15:07 UTC (permalink / raw)
To: Olof Johansson
Cc: Mark Rutland, devicetree, linux-kernel, Lubomir Rintel,
Rob Herring, linux-arm-kernel
In-Reply-To: <20190620150724.1406757-1-lkundrak@v3.sk>
This makes the 8250_of driver happy. There are two more drivers in the
tree that bind to mrvl,mmp-uart compatibles: pxa and 8250_pxa and
neither of them requires the reg-shift property, assuming it's always 2.
Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
---
arch/arm/boot/dts/mmp2.dtsi | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/mmp2.dtsi b/arch/arm/boot/dts/mmp2.dtsi
index 68b547077323..6a2f072c1d0a 100644
--- a/arch/arm/boot/dts/mmp2.dtsi
+++ b/arch/arm/boot/dts/mmp2.dtsi
@@ -214,6 +214,7 @@
interrupts = <27>;
clocks = <&soc_clocks MMP2_CLK_UART0>;
resets = <&soc_clocks MMP2_CLK_UART0>;
+ reg-shift = <2>;
status = "disabled";
};
@@ -223,6 +224,7 @@
interrupts = <28>;
clocks = <&soc_clocks MMP2_CLK_UART1>;
resets = <&soc_clocks MMP2_CLK_UART1>;
+ reg-shift = <2>;
status = "disabled";
};
@@ -232,6 +234,7 @@
interrupts = <24>;
clocks = <&soc_clocks MMP2_CLK_UART2>;
resets = <&soc_clocks MMP2_CLK_UART2>;
+ reg-shift = <2>;
status = "disabled";
};
@@ -241,6 +244,7 @@
interrupts = <46>;
clocks = <&soc_clocks MMP2_CLK_UART3>;
resets = <&soc_clocks MMP2_CLK_UART3>;
+ reg-shift = <2>;
status = "disabled";
};
--
2.21.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH 2/3] jbd2: introduce jbd2_inode dirty range scoping
From: Ross Zwisler @ 2019-06-20 15:09 UTC (permalink / raw)
To: Jan Kara
Cc: Ross Zwisler, linux-kernel, Theodore Ts'o, Alexander Viro,
Andreas Dilger, Jan Kara, linux-ext4, linux-fsdevel, linux-mm,
Fletcher Woodruff, Justin TerAvest
In-Reply-To: <20190620110454.GL13630@quack2.suse.cz>
On Thu, Jun 20, 2019 at 01:04:54PM +0200, Jan Kara wrote:
> On Wed 19-06-19 11:21:55, Ross Zwisler wrote:
> > Currently both journal_submit_inode_data_buffers() and
> > journal_finish_inode_data_buffers() operate on the entire address space
> > of each of the inodes associated with a given journal entry. The
> > consequence of this is that if we have an inode where we are constantly
> > appending dirty pages we can end up waiting for an indefinite amount of
> > time in journal_finish_inode_data_buffers() while we wait for all the
> > pages under writeback to be written out.
> >
> > The easiest way to cause this type of workload is do just dd from
> > /dev/zero to a file until it fills the entire filesystem. This can
> > cause journal_finish_inode_data_buffers() to wait for the duration of
> > the entire dd operation.
> >
> > We can improve this situation by scoping each of the inode dirty ranges
> > associated with a given transaction. We do this via the jbd2_inode
> > structure so that the scoping is contained within jbd2 and so that it
> > follows the lifetime and locking rules for that structure.
> >
> > This allows us to limit the writeback & wait in
> > journal_submit_inode_data_buffers() and
> > journal_finish_inode_data_buffers() respectively to the dirty range for
> > a given struct jdb2_inode, keeping us from waiting forever if the inode
> > in question is still being appended to.
> >
> > Signed-off-by: Ross Zwisler <zwisler@google.com>
>
> The patch looks good to me. I was thinking whether we should not have
> separate ranges for current and the next transaction but I guess it is not
> worth it at least for now. So just one nit below. With that applied feel free
> to add:
>
> Reviewed-by: Jan Kara <jack@suse.cz>
We could definitely keep separate dirty ranges for each of the current and
next transaction. I think the case where you would see a difference would be
if you had multiple transactions in a row which grew the dirty range for a
given jbd2_inode, and then had a random I/O workload which kept dirtying pages
inside that enlarged dirty range.
I'm not sure how often this type of workload would be a problem. For the
workloads I've been testing which purely append to the inode, having a single
dirty range per jbd2_inode is sufficient.
I guess for now this single range seems simpler, but if later we find that
someone would benefit from separate tracking for each of the current and next
transactions, I'll take a shot at adding it.
Thank you for the review!
> > @@ -257,15 +262,24 @@ static int journal_finish_inode_data_buffers(journal_t *journal,
> > /* For locking, see the comment in journal_submit_data_buffers() */
> > spin_lock(&journal->j_list_lock);
> > list_for_each_entry(jinode, &commit_transaction->t_inode_list, i_list) {
> > + loff_t dirty_start = jinode->i_dirty_start;
> > + loff_t dirty_end = jinode->i_dirty_end;
> > +
> > if (!(jinode->i_flags & JI_WAIT_DATA))
> > continue;
> > jinode->i_flags |= JI_COMMIT_RUNNING;
> > spin_unlock(&journal->j_list_lock);
> > - err = filemap_fdatawait_keep_errors(
> > - jinode->i_vfs_inode->i_mapping);
> > + err = filemap_fdatawait_range_keep_errors(
> > + jinode->i_vfs_inode->i_mapping, dirty_start,
> > + dirty_end);
> > if (!ret)
> > ret = err;
> > spin_lock(&journal->j_list_lock);
> > +
> > + if (!jinode->i_next_transaction) {
> > + jinode->i_dirty_start = 0;
> > + jinode->i_dirty_end = 0;
> > + }
>
> This would be more logical in the next loop that moves jinode into the next
> transaction.
Yep, agreed, this is much better. Fixed in v2.
^ permalink raw reply
* Re: [PATCH v1] ASoC: Intel: Skylake: Switch to modern UUID API
From: Andy Shevchenko @ 2019-06-20 15:09 UTC (permalink / raw)
To: Pierre-Louis Bossart
Cc: alsa-devel, Liam Girdwood, Jie Yang, Takashi Iwai, Liam Girdwood,
Vinod Koul, Mark Brown
In-Reply-To: <a987bd54-5364-f046-a928-44a97ed0307f@linux.intel.com>
On Wed, Jun 19, 2019 at 05:46:34PM +0200, Pierre-Louis Bossart wrote:
> On 6/19/19 5:02 PM, Andy Shevchenko wrote:
> > Switch the driver to use modern UUID API, i.e. guid_t type and
> > accompanying functions, such as guid_equal().
> >
> > Cc: Liam Girdwood <lgirdwood@gmail.com>
> > Cc: Mark Brown <broonie@kernel.org>
> > Cc: Vinod Koul <vkoul@kernel.org>
> > Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
>
> Looks good to me - couple of nit-picks below on unrelated indentation
> changes.
>
> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Thanks for review!
> > char mod_name[64]; /* guid str = 32 chars + 4 hyphens */
> > - uuid_le *uuid_mod;
> > - uuid_mod = (uuid_le *)guid;
> > snprintf(mod_name, sizeof(mod_name), "%s%pUL%s",
> > - "intel/dsp_fw_", uuid_mod, ".bin");
> > + "intel/dsp_fw_", guid, ".bin");
>
> indentation looks off, not sure if this is a diff effect.
Ah, this can be modified to the below (by a separate patch, since Mark applied
this one already):
snprintf(mod_name, sizeof(mod_name), "intel/dsp_fw_%pUL.bin", guid);
What do you think?
P.S. And it will take only one line.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH 4/5] ARM: dts: mmp2: add camera interfaces
From: Lubomir Rintel @ 2019-06-20 15:07 UTC (permalink / raw)
To: Olof Johansson
Cc: Mark Rutland, devicetree, linux-kernel, Lubomir Rintel,
Rob Herring, linux-arm-kernel
In-Reply-To: <20190620150724.1406757-1-lkundrak@v3.sk>
Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
---
arch/arm/boot/dts/mmp2.dtsi | 22 ++++++++++++++++++++++
1 file changed, 22 insertions(+)
diff --git a/arch/arm/boot/dts/mmp2.dtsi b/arch/arm/boot/dts/mmp2.dtsi
index 21432cb9143f..68b547077323 100644
--- a/arch/arm/boot/dts/mmp2.dtsi
+++ b/arch/arm/boot/dts/mmp2.dtsi
@@ -170,6 +170,28 @@
interrupts = <54>;
status = "disabled";
};
+
+ camera0: camera@d420a000 {
+ compatible = "marvell,mmp2-ccic";
+ reg = <0xd420a000 0x800>;
+ interrupts = <42>;
+ clocks = <&soc_clocks MMP2_CLK_CCIC0>;
+ clock-names = "axi";
+ #clock-cells = <0>;
+ clock-output-names = "mclk";
+ status = "disabled";
+ };
+
+ camera1: camera@d420a800 {
+ compatible = "marvell,mmp2-ccic";
+ reg = <0xd420a800 0x800>;
+ interrupts = <30>;
+ clocks = <&soc_clocks MMP2_CLK_CCIC1>;
+ clock-names = "axi";
+ #clock-cells = <0>;
+ clock-output-names = "mclk";
+ status = "disabled";
+ };
};
apb@d4000000 { /* APB */
--
2.21.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* ✓ Fi.CI.IGT: success for series starting with [v2,1/2] drm/i915/ehl/dsi: Set lane latency optimization for DW1
From: Patchwork @ 2019-06-20 15:08 UTC (permalink / raw)
To: Souza, Jose; +Cc: intel-gfx
In-Reply-To: <20190619233134.20009-1-jose.souza@intel.com>
== Series Details ==
Series: series starting with [v2,1/2] drm/i915/ehl/dsi: Set lane latency optimization for DW1
URL : https://patchwork.freedesktop.org/series/62417/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6312_full -> Patchwork_13356_full
====================================================
Summary
-------
**SUCCESS**
No regressions found.
Known issues
------------
Here are the changes found in Patchwork_13356_full that come from known issues:
### IGT changes ###
#### Issues hit ####
* igt@gem_eio@in-flight-contexts-1us:
- shard-kbl: [PASS][1] -> [DMESG-WARN][2] ([fdo#110913 ]) +2 similar issues
[1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-kbl6/igt@gem_eio@in-flight-contexts-1us.html
[2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13356/shard-kbl6/igt@gem_eio@in-flight-contexts-1us.html
* igt@gem_workarounds@suspend-resume-context:
- shard-apl: [PASS][3] -> [DMESG-WARN][4] ([fdo#108566]) +2 similar issues
[3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-apl4/igt@gem_workarounds@suspend-resume-context.html
[4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13356/shard-apl5/igt@gem_workarounds@suspend-resume-context.html
* igt@i915_pm_rc6_residency@rc6-accuracy:
- shard-snb: [PASS][5] -> [SKIP][6] ([fdo#109271])
[5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-snb1/igt@i915_pm_rc6_residency@rc6-accuracy.html
[6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13356/shard-snb5/igt@i915_pm_rc6_residency@rc6-accuracy.html
* igt@kms_flip@flip-vs-suspend:
- shard-skl: [PASS][7] -> [INCOMPLETE][8] ([fdo#109507])
[7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-skl8/igt@kms_flip@flip-vs-suspend.html
[8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13356/shard-skl5/igt@kms_flip@flip-vs-suspend.html
- shard-glk: [PASS][9] -> [INCOMPLETE][10] ([fdo#103359] / [k.org#198133])
[9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-glk9/igt@kms_flip@flip-vs-suspend.html
[10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13356/shard-glk6/igt@kms_flip@flip-vs-suspend.html
* igt@kms_frontbuffer_tracking@fbc-2p-primscrn-cur-indfb-draw-pwrite:
- shard-hsw: [PASS][11] -> [SKIP][12] ([fdo#109271]) +19 similar issues
[11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-hsw8/igt@kms_frontbuffer_tracking@fbc-2p-primscrn-cur-indfb-draw-pwrite.html
[12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13356/shard-hsw1/igt@kms_frontbuffer_tracking@fbc-2p-primscrn-cur-indfb-draw-pwrite.html
* igt@kms_plane@plane-panning-bottom-right-suspend-pipe-c-planes:
- shard-skl: [PASS][13] -> [INCOMPLETE][14] ([fdo#104108])
[13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-skl5/igt@kms_plane@plane-panning-bottom-right-suspend-pipe-c-planes.html
[14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13356/shard-skl10/igt@kms_plane@plane-panning-bottom-right-suspend-pipe-c-planes.html
* igt@kms_plane_alpha_blend@pipe-b-constant-alpha-min:
- shard-skl: [PASS][15] -> [FAIL][16] ([fdo#108145])
[15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-skl6/igt@kms_plane_alpha_blend@pipe-b-constant-alpha-min.html
[16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13356/shard-skl1/igt@kms_plane_alpha_blend@pipe-b-constant-alpha-min.html
* igt@kms_rotation_crc@multiplane-rotation-cropping-bottom:
- shard-kbl: [PASS][17] -> [DMESG-FAIL][18] ([fdo#105763])
[17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-kbl1/igt@kms_rotation_crc@multiplane-rotation-cropping-bottom.html
[18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13356/shard-kbl3/igt@kms_rotation_crc@multiplane-rotation-cropping-bottom.html
* igt@perf_pmu@rc6:
- shard-kbl: [PASS][19] -> [SKIP][20] ([fdo#109271])
[19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-kbl7/igt@perf_pmu@rc6.html
[20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13356/shard-kbl2/igt@perf_pmu@rc6.html
#### Possible fixes ####
* igt@gem_eio@wait-10ms:
- shard-apl: [DMESG-WARN][21] ([fdo#110913 ]) -> [PASS][22] +1 similar issue
[21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-apl8/igt@gem_eio@wait-10ms.html
[22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13356/shard-apl5/igt@gem_eio@wait-10ms.html
* igt@gem_persistent_relocs@forked-interruptible-faulting-reloc-thrashing:
- shard-kbl: [DMESG-WARN][23] ([fdo#110913 ]) -> [PASS][24]
[23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-kbl7/igt@gem_persistent_relocs@forked-interruptible-faulting-reloc-thrashing.html
[24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13356/shard-kbl6/igt@gem_persistent_relocs@forked-interruptible-faulting-reloc-thrashing.html
* igt@kms_cursor_edge_walk@pipe-b-128x128-top-edge:
- shard-snb: [SKIP][25] ([fdo#109271] / [fdo#109278]) -> [PASS][26]
[25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-snb2/igt@kms_cursor_edge_walk@pipe-b-128x128-top-edge.html
[26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13356/shard-snb2/igt@kms_cursor_edge_walk@pipe-b-128x128-top-edge.html
* igt@kms_cursor_legacy@2x-long-flip-vs-cursor-atomic:
- shard-glk: [FAIL][27] ([fdo#104873]) -> [PASS][28]
[27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-glk8/igt@kms_cursor_legacy@2x-long-flip-vs-cursor-atomic.html
[28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13356/shard-glk1/igt@kms_cursor_legacy@2x-long-flip-vs-cursor-atomic.html
* igt@kms_flip@2x-flip-vs-expired-vblank-interruptible:
- shard-hsw: [SKIP][29] ([fdo#109271]) -> [PASS][30] +23 similar issues
[29]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-hsw1/igt@kms_flip@2x-flip-vs-expired-vblank-interruptible.html
[30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13356/shard-hsw6/igt@kms_flip@2x-flip-vs-expired-vblank-interruptible.html
* igt@kms_frontbuffer_tracking@fbc-suspend:
- shard-apl: [DMESG-WARN][31] ([fdo#108566]) -> [PASS][32]
[31]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-apl3/igt@kms_frontbuffer_tracking@fbc-suspend.html
[32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13356/shard-apl1/igt@kms_frontbuffer_tracking@fbc-suspend.html
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c:
- shard-skl: [INCOMPLETE][33] ([fdo#104108]) -> [PASS][34]
[33]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-skl4/igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c.html
[34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13356/shard-skl10/igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c.html
* igt@kms_plane@plane-panning-bottom-right-pipe-b-planes:
- shard-snb: [SKIP][35] ([fdo#109271]) -> [PASS][36] +1 similar issue
[35]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6312/shard-snb2/igt@kms_plane@plane-panning-bottom-right-pipe-b-planes.html
[36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13356/shard-snb2/igt@kms_plane@plane-panning-bottom-right-pipe-b-planes.html
[fdo#103359]: https://bugs.freedesktop.org/show_bug.cgi?id=103359
[fdo#104108]: https://bugs.freedesktop.org/show_bug.cgi?id=104108
[fdo#104873]: https://bugs.freedesktop.org/show_bug.cgi?id=104873
[fdo#105763]: https://bugs.freedesktop.org/show_bug.cgi?id=105763
[fdo#108145]: https://bugs.freedesktop.org/show_bug.cgi?id=108145
[fdo#108566]: https://bugs.freedesktop.org/show_bug.cgi?id=108566
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
[fdo#109507]: https://bugs.freedesktop.org/show_bug.cgi?id=109507
[fdo#110913 ]: https://bugs.freedesktop.org/show_bug.cgi?id=110913
[k.org#198133]: https://bugzilla.kernel.org/show_bug.cgi?id=198133
Participating hosts (10 -> 9)
------------------------------
Missing (1): shard-iclb
Build changes
-------------
* Linux: CI_DRM_6312 -> Patchwork_13356
CI_DRM_6312: 034e3ac6a2d180d188da927388b60c7e62c5655b @ git://anongit.freedesktop.org/gfx-ci/linux
IGT_5061: c88ced79a7b71aec58f1d9c5c599ac2f431bcf7a @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_13356: 691b808bac74a60337583445f6bbbf087c734e63 @ git://anongit.freedesktop.org/gfx-ci/linux
piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13356/
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* [PATCH 2/5] ARM: dts: mmp2: fix the SPI nodes
From: Lubomir Rintel @ 2019-06-20 15:07 UTC (permalink / raw)
To: Olof Johansson
Cc: Mark Rutland, devicetree, linux-kernel, Lubomir Rintel,
Rob Herring, linux-arm-kernel
In-Reply-To: <20190620150724.1406757-1-lkundrak@v3.sk>
The SPI bus has a single address cell and not size cells.
Also, dtc thinks the SPI nodes are preferrably called "spi" and it is
right to think so.
Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
---
arch/arm/boot/dts/mmp2.dtsi | 16 ++++++++++++----
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/mmp2.dtsi b/arch/arm/boot/dts/mmp2.dtsi
index 50b6c38b39cc..e64639ce57a9 100644
--- a/arch/arm/boot/dts/mmp2.dtsi
+++ b/arch/arm/boot/dts/mmp2.dtsi
@@ -346,35 +346,43 @@
status = "disabled";
};
- ssp1: ssp@d4035000 {
+ ssp1: spi@d4035000 {
compatible = "marvell,mmp2-ssp";
reg = <0xd4035000 0x1000>;
clocks = <&soc_clocks MMP2_CLK_SSP0>;
interrupts = <0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
status = "disabled";
};
- ssp2: ssp@d4036000 {
+ ssp2: spi@d4036000 {
compatible = "marvell,mmp2-ssp";
reg = <0xd4036000 0x1000>;
clocks = <&soc_clocks MMP2_CLK_SSP1>;
interrupts = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
status = "disabled";
};
- ssp3: ssp@d4037000 {
+ ssp3: spi@d4037000 {
compatible = "marvell,mmp2-ssp";
reg = <0xd4037000 0x1000>;
clocks = <&soc_clocks MMP2_CLK_SSP2>;
interrupts = <20>;
+ #address-cells = <1>;
+ #size-cells = <0>;
status = "disabled";
};
- ssp4: ssp@d4039000 {
+ ssp4: spi@d4039000 {
compatible = "marvell,mmp2-ssp";
reg = <0xd4039000 0x1000>;
clocks = <&soc_clocks MMP2_CLK_SSP3>;
interrupts = <21>;
+ #address-cells = <1>;
+ #size-cells = <0>;
status = "disabled";
};
};
--
2.21.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [Bug 110949] Continuious warnings from agd5f 5.3-wip branch
From: bugzilla-daemon @ 2019-06-20 15:08 UTC (permalink / raw)
To: dri-devel
In-Reply-To: <bug-110949-502@http.bugs.freedesktop.org/>
[-- Attachment #1.1: Type: text/plain, Size: 261 bytes --]
https://bugs.freedesktop.org/show_bug.cgi?id=110949
--- Comment #4 from Mike Lothian <mike@fireburn.co.uk> ---
If there's anything you'd like me to test for you, please do shout
--
You are receiving this mail because:
You are the assignee for the bug.
[-- Attachment #1.2: Type: text/html, Size: 1038 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH 29/59] drm/sti: Drop drm_gem_prime_export/import
From: Benjamin Gaignard @ 2019-06-20 15:08 UTC (permalink / raw)
To: Daniel Vetter
Cc: Daniel Vetter, Intel Graphics Development, Vincent Abriou,
DRI Development
In-Reply-To: <20190614203615.12639-30-daniel.vetter@ffwll.ch>
Le ven. 14 juin 2019 à 22:36, Daniel Vetter <daniel.vetter@ffwll.ch> a écrit :
>
> They're the default.
>
> Aside: Would be really nice to switch the others over to
> drm_gem_object_funcs.
>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Benjamin Gaignard <benjamin.gaignard@linaro.org>
> Cc: Vincent Abriou <vincent.abriou@st.com>
Thanks,
Reviewed-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>
> ---
> drivers/gpu/drm/sti/sti_drv.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/sti/sti_drv.c b/drivers/gpu/drm/sti/sti_drv.c
> index d9f63c9f287b..faea4dcb21b1 100644
> --- a/drivers/gpu/drm/sti/sti_drv.c
> +++ b/drivers/gpu/drm/sti/sti_drv.c
> @@ -152,8 +152,6 @@ static struct drm_driver sti_driver = {
>
> .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
> .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
> - .gem_prime_export = drm_gem_prime_export,
> - .gem_prime_import = drm_gem_prime_import,
> .gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
> .gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table,
> .gem_prime_vmap = drm_gem_cma_prime_vmap,
> --
> 2.20.1
>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.