* Re: [PATCH v3 06/17] s390x: protvirt: Add migration blocker
From: Janosch Frank @ 2020-02-20 11:24 UTC (permalink / raw)
To: Cornelia Huck; +Cc: qemu-s390x, mihajlov, qemu-devel, david
In-Reply-To: <20200220114815.01634a4c.cohuck@redhat.com>
[-- Attachment #1.1: Type: text/plain, Size: 2672 bytes --]
On 2/20/20 11:48 AM, Cornelia Huck wrote:
> On Fri, 14 Feb 2020 10:16:25 -0500
> Janosch Frank <frankja@linux.ibm.com> wrote:
>
>> Migration is not yet supported.
>>
>> Signed-off-by: Janosch Frank <frankja@linux.ibm.com>
>> ---
>> hw/s390x/s390-virtio-ccw.c | 16 ++++++++++++++++
>> 1 file changed, 16 insertions(+)
>>
>> diff --git a/hw/s390x/s390-virtio-ccw.c b/hw/s390x/s390-virtio-ccw.c
>> index 5fa4372083..d64724af91 100644
>> --- a/hw/s390x/s390-virtio-ccw.c
>> +++ b/hw/s390x/s390-virtio-ccw.c
>> @@ -42,6 +42,9 @@
>> #include "hw/s390x/tod.h"
>> #include "sysemu/sysemu.h"
>> #include "hw/s390x/pv.h"
>> +#include "migration/blocker.h"
>> +
>> +static Error *pv_mig_blocker;
>>
>> S390CPU *s390_cpu_addr2state(uint16_t cpu_addr)
>> {
>> @@ -373,6 +376,7 @@ static void s390_machine_reset(MachineState *machine)
>> CPUState *cs, *t;
>> S390CPU *cpu;
>> S390CcwMachineState *ms = S390_CCW_MACHINE(machine);
>> + static Error *local_err;
>>
>> /* get the reset parameters, reset them once done */
>> s390_ipl_get_reset_request(&cs, &reset_type);
>> @@ -422,6 +426,17 @@ static void s390_machine_reset(MachineState *machine)
>> }
>> run_on_cpu(cs, s390_do_cpu_reset, RUN_ON_CPU_NULL);
>>
>> + if (!pv_mig_blocker) {
>> + error_setg(&pv_mig_blocker,
>> + "protected VMs are currently not migrateable.");
>> + }
>> + migrate_add_blocker(pv_mig_blocker, &local_err);
>
> If I'm not lost in the context, that's during PV_RESET. I'm a bit
> confused why you'd add the blocker here?
Where would you want me to add it?
It's here where we switch into secure mode and I need to block before
switching and unblock if it fails.
When having the blocker in diag.c, I'd have a hard time unblocking on a
PV switch fail.
>
>> + if (local_err) {
>> + error_report_err(local_err);
>> + error_free(pv_mig_blocker);
>> + exit(1);
>
> Why the exit()? Can't you fail the call?
Well, if that fails and we go protected, I wouldn't be protected agains
migrations, right?
>
>> + }
>> +
>> if (s390_machine_pv_secure(ms)) {
>> CPU_FOREACH(t) {
>> s390_pv_vcpu_destroy(t);
>> @@ -430,6 +445,7 @@ static void s390_machine_reset(MachineState *machine)
>> ms->pv = false;
>>
>> s390_machine_inject_pv_error(cs);
>> + migrate_del_blocker(pv_mig_blocker);
>> s390_cpu_set_state(S390_CPU_STATE_OPERATING, cpu);
>> return;
>> }
>
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* [dpdk-dev] DPDK Release Status Meeting 20/02/2020
From: Ferruh Yigit @ 2020-02-20 11:25 UTC (permalink / raw)
To: dpdk-dev; +Cc: Thomas Monjalon
Minutes 20 February 2020
------------------------
Agenda:
* Release Dates
* -rc3 status
* Subtrees
* OvS
* Opens
Participants:
* Arm
* Debian/Microsoft
* Intel
* Marvell
* Mellanox
* NXP
* Red Hat
Release Dates
-------------
* v20.02 dates:
* -rc3 is released on 16 February
* https://mails.dpdk.org/archives/dev/2020-February/157922.html
* -rc4 Friday 21 February 2020
* Release pushed to *Friday 25 February 2020*
* Release date may postponed if any critical issue found in -rc4 testing
* v20.05 *updated* proposal, please comment:
* Proposal/V1: Wednesday 18 March 2020
* Integration/Merge/RC1: Friday 17 April 2020
* Release: Wednesday 20 May 2020
* The update request is based on delays in 20.02
* Release date postponed more taking into PRC holiday on 1-5 May into account
-rc3 Status
-----------
* Intel and Red Hat sent test results, thank you.
* https://mails.dpdk.org/archives/dev/2020-February/158184.html
* https://mails.dpdk.org/archives/dev/2020-February/158285.html
Subtrees
--------
* main
* For pure experimental libraries, there is an library versioning problem
This is critical to be solved for the -rc4, Intel will try to find resource
to work on it.
* https://mails.dpdk.org/archives/dev/2020-February/158012.html
* Devtools will be merged
* Doc/deprecation notices are in the queue
* Requested an early merge from next-net, since some fixes accumulated
* John will start on working release notes review
* next-net
* Bug fixes merged for -rc4, pulled sub-trees
* next-net-crypto
* There are some fixes, Akhil will merge in next a few hours
* examples/fips_validation patch will be merged to main repo by David
* next-net-eventdev
* No update
* next-net-virtio
* Bug fixes merged for -rc4
* next-net-intel
* Bug fixes merged for -rc4
* LTS
* 17.11.10-rc1 released, please test and report results
* https://mails.dpdk.org/archives/dev/2020-January/154915.html
* Waiting for QAT issue
* Release will be postponed one more week
OvS
---
* 2.13 is ready, waiting for announcement
Opens
-----
* Lots of coverity issues fixed, thanks.
* There is a coverity sticker in patchwork now
* https://patches.dpdk.org/project/dpdk/list/
Which reports 14 new defects as of now
* Plan is to trigger coverity scan from the travis
DPDK Release Status Meetings
============================
The DPDK Release Status Meeting is intended for DPDK Committers to discuss
the status of the master tree and sub-trees, and for project managers to
track progress or milestone dates.
The meeting occurs on Thursdays at 8:30 UTC. If you wish to attend just
send an email to "John McNamara <john.mcnamara@intel.com>" for the invite.
^ permalink raw reply
* Re: [alsa-devel] Implicit feedback solution for Boss GT-1 and maybe other devices
From: Keith A. Milner @ 2020-02-20 11:24 UTC (permalink / raw)
To: alsa-devel; +Cc: Mike Oliphant
In-Reply-To: <CAHXb3bcrSnAnwS+-HY8jh4eoBdt+tBoZTHSr-5jsGomN156fFw@mail.gmail.com>
On Thursday, 23 January 2020 10:06:58 GMT Mike Oliphant wrote:
> I received a very helpful email response to my previous thread about trying
> to get the Boss GT-1 pedalboard working reliably, and as a result I now
> have a working solution.
>
> The issue seems to be that the GT-1 does not send any capture data until it
> gets some playback data first.
Hi Mike,
In my original investigations (which you referenced) this was the conclusion I
was starting to reach, but real-world events meant I didn't have the time to
follow up on it, so I'm grateful that you have.
In the kernel.org bugzilla report you also mention that you have a potential
fix. I would be willing to test this, subject to time constraints (in other
words it may or may not take me some time to get around to testing this).
Feel free to contact me directly to send me a patch (best email address is
user kamilner on the same domain used to send this email).
For reference, I have a GT-1, a GT-001, and a 1st gen Katana I can test with.
Regards,
Keith
^ permalink raw reply
* Re: [PATCH net-next v3 5/9] device: add device_change_owner()
From: Greg Kroah-Hartman @ 2020-02-20 11:25 UTC (permalink / raw)
To: Christian Brauner
Cc: David S. Miller, linux-kernel, netdev, Rafael J. Wysocki,
Pavel Machek, Jakub Kicinski, Eric Dumazet, Stephen Hemminger,
linux-pm
In-Reply-To: <20200218162943.2488012-6-christian.brauner@ubuntu.com>
On Tue, Feb 18, 2020 at 05:29:39PM +0100, Christian Brauner wrote:
> Add a helper to change the owner of a device's sysfs entries. This
> needs to happen when the ownership of a device is changed, e.g. when
> moving network devices between network namespaces.
> This function will be used to correctly account for ownership changes,
> e.g. when moving network devices between network namespaces.
>
> Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
> ---
> /* v2 */
> unchanged
>
> /* v3 */
> - Greg Kroah-Hartman <gregkh@linuxfoundation.org>:
> - Add explicit uid/gid parameters.
> ---
> drivers/base/core.c | 80 ++++++++++++++++++++++++++++++++++++++++++
> include/linux/device.h | 1 +
> 2 files changed, 81 insertions(+)
>
> diff --git a/drivers/base/core.c b/drivers/base/core.c
> index 42a672456432..ec0d5e8cfd0f 100644
> --- a/drivers/base/core.c
> +++ b/drivers/base/core.c
> @@ -3458,6 +3458,86 @@ int device_move(struct device *dev, struct device *new_parent,
> }
> EXPORT_SYMBOL_GPL(device_move);
>
> +static int device_attrs_change_owner(struct device *dev, kuid_t kuid,
> + kgid_t kgid)
> +{
> + struct kobject *kobj = &dev->kobj;
> + struct class *class = dev->class;
> + const struct device_type *type = dev->type;
> + int error;
> +
> + if (class) {
> + error = sysfs_groups_change_owner(kobj, class->dev_groups, kuid,
> + kgid);
> + if (error)
> + return error;
> + }
> +
> + if (type) {
> + error = sysfs_groups_change_owner(kobj, type->groups, kuid,
> + kgid);
> + if (error)
> + return error;
> + }
> +
> + error = sysfs_groups_change_owner(kobj, dev->groups, kuid, kgid);
> + if (error)
> + return error;
> +
> + if (device_supports_offline(dev) && !dev->offline_disabled) {
> + error = sysfs_file_change_owner_by_name(
> + kobj, dev_attr_online.attr.name, kuid, kgid);
> + if (error)
> + return error;
> + }
> +
> + return 0;
> +}
> +
> +/**
> + * device_change_owner - change the owner of an existing device.
The "owner" and what else gets changed here? Please document this
better.
> + * @dev: device.
> + * @kuid: new owner's kuid
> + * @kgid: new owner's kgid
> + */
> +int device_change_owner(struct device *dev, kuid_t kuid, kgid_t kgid)
> +{
> + int error;
> + struct kobject *kobj = &dev->kobj;
> +
> + dev = get_device(dev);
> + if (!dev)
> + return -EINVAL;
> +
> + error = sysfs_change_owner(kobj, kuid, kgid);
the kobject of the device is changed, good.
> + if (error)
> + goto out;
> +
> + error = sysfs_file_change_owner_by_name(kobj, dev_attr_uevent.attr.name,
> + kuid, kgid);
Why call out the uevent file explicitly here?
> + if (error)
> + goto out;
> +
> + error = device_attrs_change_owner(dev, kuid, kgid);
> + if (error)
> + goto out;
Doesn't this also change the uevent file?
> +
> +#ifdef CONFIG_BLOCK
> + if (sysfs_deprecated && dev->class == &block_class)
> + goto out;
> +#endif
Ugh, we still need this?
> +
> + error = sysfs_link_change_owner(&dev->class->p->subsys.kobj, &dev->kobj,
> + dev_name(dev), kuid, kgid);
Now what is this changing?
Again, more documentation please as to exactly what is being changed in
this function is needed.
thanks,
greg k-h
^ permalink raw reply
* Re: [Intel-gfx] [PATCH 05/12] drm/msm/dpu: Stop copying around mode->private_flags
From: Emil Velikov @ 2020-02-20 11:24 UTC (permalink / raw)
To: Ville Syrjala
Cc: linux-arm-msm, Intel Graphics Development, freedreno,
ML dri-devel
In-Reply-To: <20200219203544.31013-6-ville.syrjala@linux.intel.com>
On Wed, 19 Feb 2020 at 20:36, Ville Syrjala
<ville.syrjala@linux.intel.com> wrote:
>
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>
> The driver never sets mode->private_flags so copying
> it back and forth is entirely pointless. Stop doing it.
>
> Also drop private_flags from the tracepoint.
>
> Cc: Rob Clark <robdclark@gmail.com>
> Cc: Sean Paul <sean@poorly.run>
> Cc: linux-arm-msm@vger.kernel.org
> Cc: freedreno@lists.freedesktop.org
> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Perhaps the msm team has a WIP which makes use of it ?
Otherwise:
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
-Emil
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [PATCH 05/12] drm/msm/dpu: Stop copying around mode->private_flags
From: Emil Velikov @ 2020-02-20 11:24 UTC (permalink / raw)
To: Ville Syrjala
Cc: ML dri-devel, linux-arm-msm, Intel Graphics Development,
freedreno, Sean Paul
In-Reply-To: <20200219203544.31013-6-ville.syrjala@linux.intel.com>
On Wed, 19 Feb 2020 at 20:36, Ville Syrjala
<ville.syrjala@linux.intel.com> wrote:
>
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>
> The driver never sets mode->private_flags so copying
> it back and forth is entirely pointless. Stop doing it.
>
> Also drop private_flags from the tracepoint.
>
> Cc: Rob Clark <robdclark@gmail.com>
> Cc: Sean Paul <sean@poorly.run>
> Cc: linux-arm-msm@vger.kernel.org
> Cc: freedreno@lists.freedesktop.org
> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Perhaps the msm team has a WIP which makes use of it ?
Otherwise:
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
-Emil
^ permalink raw reply
* Re: [PATCH 05/12] drm/msm/dpu: Stop copying around mode->private_flags
From: Emil Velikov @ 2020-02-20 11:24 UTC (permalink / raw)
To: Ville Syrjala
Cc: Sean Paul, linux-arm-msm, Intel Graphics Development, freedreno,
ML dri-devel
In-Reply-To: <20200219203544.31013-6-ville.syrjala@linux.intel.com>
On Wed, 19 Feb 2020 at 20:36, Ville Syrjala
<ville.syrjala@linux.intel.com> wrote:
>
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>
> The driver never sets mode->private_flags so copying
> it back and forth is entirely pointless. Stop doing it.
>
> Also drop private_flags from the tracepoint.
>
> Cc: Rob Clark <robdclark@gmail.com>
> Cc: Sean Paul <sean@poorly.run>
> Cc: linux-arm-msm@vger.kernel.org
> Cc: freedreno@lists.freedesktop.org
> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Perhaps the msm team has a WIP which makes use of it ?
Otherwise:
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
-Emil
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCHv5 33/34] drm/rockchip: Use helper for common task
From: Boris Brezillon @ 2020-02-20 11:24 UTC (permalink / raw)
To: Andrzej Pietrasiewicz
Cc: kernel, Mihail Atanassov, David Airlie, Liviu Dudau, Sandy Huang,
dri-devel, James Wang, Ayan Halder, Sean Paul
In-Reply-To: <20191217145020.14645-34-andrzej.p@collabora.com>
On Tue, 17 Dec 2019 15:50:19 +0100
Andrzej Pietrasiewicz <andrzej.p@collabora.com> wrote:
> Use generic helper code.
>
> Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@collabora.com>
> ---
> drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 12 ++----------
> 1 file changed, 2 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> index 221e72e71432..5806f908aa53 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> @@ -18,6 +18,7 @@
> #include "rockchip_drm_fb.h"
> #include "rockchip_drm_gem.h"
>
> +
You can drop this blank line. Looks good otherwise, but I'll wait for v6
(with the new ->check_size() maybe) before giving my R-b.
> static const struct drm_framebuffer_funcs rockchip_drm_fb_funcs = {
> .destroy = drm_gem_fb_destroy,
> .create_handle = drm_gem_fb_create_handle,
> @@ -30,22 +31,13 @@ rockchip_fb_alloc(struct drm_device *dev, const struct drm_mode_fb_cmd2 *mode_cm
> {
> struct drm_framebuffer *fb;
> int ret;
> - int i;
>
> fb = kzalloc(sizeof(*fb), GFP_KERNEL);
> if (!fb)
> return ERR_PTR(-ENOMEM);
>
> - drm_helper_mode_fill_fb_struct(dev, fb, mode_cmd);
> -
> - for (i = 0; i < num_planes; i++)
> - fb->obj[i] = obj[i];
> -
> - ret = drm_framebuffer_init(dev, fb, &rockchip_drm_fb_funcs);
> + ret = drm_gem_fb_init_with_funcs(fb, dev, mode_cmd, obj, num_planes, &rockchip_drm_fb_funcs);
> if (ret) {
> - DRM_DEV_ERROR(dev->dev,
> - "Failed to initialize framebuffer: %d\n",
> - ret);
> kfree(fb);
> return ERR_PTR(ret);
> }
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH 2/2] MAINTAINERS: Set MIPS status to Odd Fixes
From: Thomas Bogendoerfer @ 2020-02-20 11:23 UTC (permalink / raw)
To: Paul Burton; +Cc: linux-mips, linux-kernel
In-Reply-To: <20200219191730.1277800-3-paulburton@kernel.org>
On Wed, Feb 19, 2020 at 11:17:30AM -0800, Paul Burton wrote:
> My time with MIPS the company has reached its end, and so at best I'll
> have little time spend on maintaining arch/mips/. Reflect that in
> MAINTAINERS by changing status to Odd Fixes. Hopefully this might spur
> the involvement of someone with more time, but even if not it should
> help serve to avoid unrealistic expectations.
I'd like to jump in as MIPS maintainer. I'm doing Linux MIPS kernel
development since ages (started with an Olivetti M700 and kernel version
2.x) and right now time for doing the jobs isn't issue:-)
Thomas.
--
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea. [ RFC1925, 2.3 ]
^ permalink raw reply
* Re: [PATCH net-next v3 4/9] sysfs: add sysfs_change_owner()
From: Greg Kroah-Hartman @ 2020-02-20 11:23 UTC (permalink / raw)
To: Christian Brauner
Cc: David S. Miller, linux-kernel, netdev, Rafael J. Wysocki,
Pavel Machek, Jakub Kicinski, Eric Dumazet, Stephen Hemminger,
linux-pm
In-Reply-To: <20200218162943.2488012-5-christian.brauner@ubuntu.com>
On Tue, Feb 18, 2020 at 05:29:38PM +0100, Christian Brauner wrote:
> Add a helper to change the owner of sysfs objects.
> This function will be used to correctly account for kobject ownership
> changes, e.g. when moving network devices between network namespaces.
>
> Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
> ---
> /* v2 */
> - Greg Kroah-Hartman <gregkh@linuxfoundation.org>:
> - Add comment how ownership of sysfs object is changed.
>
> /* v3 */
> - Greg Kroah-Hartman <gregkh@linuxfoundation.org>:
> - Add explicit uid/gid parameters.
> ---
> fs/sysfs/file.c | 39 +++++++++++++++++++++++++++++++++++++++
> include/linux/sysfs.h | 6 ++++++
> 2 files changed, 45 insertions(+)
>
> diff --git a/fs/sysfs/file.c b/fs/sysfs/file.c
> index df5107d7b3fd..02f7e852aad4 100644
> --- a/fs/sysfs/file.c
> +++ b/fs/sysfs/file.c
> @@ -665,3 +665,42 @@ int sysfs_file_change_owner(struct kobject *kobj, kuid_t kuid, kgid_t kgid)
> return error;
> }
> EXPORT_SYMBOL_GPL(sysfs_file_change_owner);
> +
> +/**
> + * sysfs_change_owner - change owner of the given object.
"and all of the files associated with this kobject", right?
> + * @kobj: object.
> + * @kuid: new owner's kuid
> + * @kgid: new owner's kgid
> + */
> +int sysfs_change_owner(struct kobject *kobj, kuid_t kuid, kgid_t kgid)
> +{
> + int error;
> + const struct kobj_type *ktype;
> +
> + if (!kobj->state_in_sysfs)
> + return -EINVAL;
> +
> + error = sysfs_file_change_owner(kobj, kuid, kgid);
Ok, this changes the attributes of the sysfs directory for the kobject
itself.
> + if (error)
> + return error;
> +
> + ktype = get_ktype(kobj);
> + if (ktype) {
> + struct attribute **kattr;
> +
> + for (kattr = ktype->default_attrs; kattr && *kattr; kattr++) {
> + error = sysfs_file_change_owner_by_name(
> + kobj, (*kattr)->name, kuid, kgid);
> + if (error)
> + return error;
> + }
And here you change all of the files of the kobject.
But what about files that have a subdir? Does that also happen here?
> +
> + error = sysfs_groups_change_owner(kobj, ktype->default_groups,
> + kuid, kgid);
Then what are you changing here?
I think the kerneldoc needs a lot more explaination as to what is going
on in this function and why you would call it, and not some of the other
functions you are adding.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH] KVM: Suppress warning in __kvm_gfn_to_hva_cache_init
From: Paolo Bonzini @ 2020-02-20 11:22 UTC (permalink / raw)
To: Sean Christopherson, Oliver Upton; +Cc: kvm
In-Reply-To: <20200218190729.GD28156@linux.intel.com>
On 18/02/20 20:07, Sean Christopherson wrote:
> On Tue, Feb 18, 2020 at 10:47:56AM -0800, Oliver Upton wrote:
>> Particularly draconian compilers warn of a possible uninitialized use of
>> the nr_pages_avail variable. Silence this warning by initializing it to
>> zero.
> Can you check if the warning still exists with commit 6ad1e29fe0ab ("KVM:
> Clean up __kvm_gfn_to_hva_cache_init() and its callers")? I'm guessing
> (hoping?) the suppression is no longer necessary.
What if __gfn_to_hva_many and gfn_to_hva_many are marked __always_inline?
Thanks,
Paolo
^ permalink raw reply
* Re: [PATCH v3 05/17] s390x: protvirt: Support unpack facility
From: Janosch Frank @ 2020-02-20 11:21 UTC (permalink / raw)
To: Cornelia Huck; +Cc: qemu-s390x, mihajlov, qemu-devel, david
In-Reply-To: <20200220113950.015984bf.cohuck@redhat.com>
[-- Attachment #1.1: Type: text/plain, Size: 8830 bytes --]
On 2/20/20 11:39 AM, Cornelia Huck wrote:
> On Fri, 14 Feb 2020 10:16:24 -0500
> Janosch Frank <frankja@linux.ibm.com> wrote:
>
>> When a guest has saved a ipib of type 5 and call diagnose308 with
>
> s/call/calls/
>
>> subcode 10, we have to setup the protected processing environment via
>> Ultravisor calls. The calls are done by KVM and are exposed via an API.
>>
>> The following steps are necessary:
>> 1. Create a VM (register it with the Ultravisor)
>> 2. Create secure CPUs for all of our current cpus
>> 3. Forward the secure header to the Ultravisor (has all information on
>> how to decrypt the image and VM information)
>> 4. Protect image pages from the host and decrypt them
>> 5. Verify the image integrity
>>
>> Only after step 5 a protected VM is allowed to run.
>>
>> Signed-off-by: Janosch Frank <frankja@linux.ibm.com>
>> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com> [Changes
>> to machine]
>> ---
>> hw/s390x/Makefile.objs | 1 +
>> hw/s390x/ipl.c | 32 ++++++
>> hw/s390x/ipl.h | 2 +
>> hw/s390x/pv.c | 154 ++++++++++++++++++++++++++++
>> hw/s390x/pv.h | 38 +++++++
>> hw/s390x/s390-virtio-ccw.c | 79 ++++++++++++++
>> include/hw/s390x/s390-virtio-ccw.h | 1 +
>> target/s390x/cpu.c | 4 +
>> target/s390x/cpu.h | 1 +
>> target/s390x/cpu_features_def.inc.h | 1 +
>> 10 files changed, 313 insertions(+)
>> create mode 100644 hw/s390x/pv.c
>> create mode 100644 hw/s390x/pv.h
>
> (...)
>
>> diff --git a/hw/s390x/pv.c b/hw/s390x/pv.c
>> new file mode 100644
>> index 0000000000..5b6a26cba9
>> --- /dev/null
>> +++ b/hw/s390x/pv.c
>> @@ -0,0 +1,154 @@
>> +/*
>> + * Secure execution functions
>> + *
>> + * Copyright IBM Corp. 2019
>
> Update the year?
ack.
>
>> + * Author(s):
>> + * Janosch Frank <frankja@linux.ibm.com>
>> + *
>> + * This work is licensed under the terms of the GNU GPL, version 2 or (at
>> + * your option) any later version. See the COPYING file in the top-level
>> + * directory.
>> + */
>
> (...)
>
>> +void s390_pv_vm_destroy(void)
>> +{
>> + s390_pv_cmd_exit(KVM_PV_VM_DESTROY, NULL);
>
> Why does this exit()? Should Never Happen?
Yes, and we can't recover from this.
>
>> +}
>> +
>> +int s390_pv_vcpu_create(CPUState *cs)
>> +{
>> + int rc;
>> +
>> + rc = s390_pv_cmd_vcpu(cs, KVM_PV_VCPU_CREATE, NULL);
>> + if (!rc) {
>> + S390_CPU(cs)->env.pv = true;
>> + }
>> +
>> + return rc;
>> +}
>> +
>> +void s390_pv_vcpu_destroy(CPUState *cs)
>> +{
>> + s390_pv_cmd_vcpu_exit(cs, KVM_PV_VCPU_DESTROY, NULL);
>
> dito
>
>> + S390_CPU(cs)->env.pv = false;
>> +}
>
> (...)
>
>> +void s390_pv_perf_clear_reset(void)
>> +{
>> + s390_pv_cmd_exit(KVM_PV_VM_PREP_RESET, NULL);
>
> And here. Or is that because the machine should not be left around in
> an undefined state?
If it failed, we could only try again, there's no fixing the problem.
So I chose to rather exit instead of looping around something which most
likely will never recover after the first error.
>
>> +}
>> +
>> +int s390_pv_verify(void)
>> +{
>> + return s390_pv_cmd(KVM_PV_VM_VERIFY, NULL);
>> +}
>> +
>> +void s390_pv_unshare(void)
>> +{
>> + s390_pv_cmd_exit(KVM_PV_VM_UNSHARE_ALL, NULL);
>> +}
>> diff --git a/hw/s390x/pv.h b/hw/s390x/pv.h
>> new file mode 100644
>> index 0000000000..7d20bdd12e
>> --- /dev/null
>> +++ b/hw/s390x/pv.h
>> @@ -0,0 +1,38 @@
>> +/*
>> + * Protected Virtualization header
>> + *
>> + * Copyright IBM Corp. 2019
>
> Year++
>
>> + * Author(s):
>> + * Janosch Frank <frankja@linux.ibm.com>
>> + *
>> + * This work is licensed under the terms of the GNU GPL, version 2 or (at
>> + * your option) any later version. See the COPYING file in the top-level
>> + * directory.
>> + */
>> +
>> +#ifndef HW_S390_PV_H
>> +#define HW_S390_PV_H
>> +
>> +#ifdef CONFIG_KVM
>> +int s390_pv_vm_create(void);
>> +void s390_pv_vm_destroy(void);
>> +void s390_pv_vcpu_destroy(CPUState *cs);
>> +int s390_pv_vcpu_create(CPUState *cs);
>> +int s390_pv_set_sec_parms(uint64_t origin, uint64_t length);
>> +int s390_pv_unpack(uint64_t addr, uint64_t size, uint64_t tweak);
>> +void s390_pv_perf_clear_reset(void);
>> +int s390_pv_verify(void);
>> +void s390_pv_unshare(void);
>> +#else
>> +int s390_pv_vm_create(void) { return 0; }
>
> I'm wondering why you return 0 here (and below). These function should
> not be called for !KVM, but just to help catch logic error, use -EINVAL
> or so?
>
>> +void s390_pv_vm_destroy(void) {}
>> +void s390_pv_vcpu_destroy(CPUState *cs) {}
>> +int s390_pv_vcpu_create(CPUState *cs) { return 0; }
>> +int s390_pv_set_sec_parms(uint64_t origin, uint64_t length) { return 0; }
>> +int s390_pv_unpack(uint64_t addr, uint64_t size, uint64_t tweak) { return 0: }
>> +void s390_pv_perf_clear_reset(void) {}
>> +int s390_pv_verify(void) { return 0; }
>> +void s390_pv_unshare(void) {}
>> +#endif
>> +
>> +#endif /* HW_S390_PV_H */
>> diff --git a/hw/s390x/s390-virtio-ccw.c b/hw/s390x/s390-virtio-ccw.c
>> index e759eb5f83..5fa4372083 100644
>> --- a/hw/s390x/s390-virtio-ccw.c
>> +++ b/hw/s390x/s390-virtio-ccw.c
>> @@ -41,6 +41,7 @@
>> #include "hw/qdev-properties.h"
>> #include "hw/s390x/tod.h"
>> #include "sysemu/sysemu.h"
>> +#include "hw/s390x/pv.h"
>>
>> S390CPU *s390_cpu_addr2state(uint16_t cpu_addr)
>> {
>> @@ -240,9 +241,11 @@ static void s390_create_sclpconsole(const char *type, Chardev *chardev)
>> static void ccw_init(MachineState *machine)
>> {
>> int ret;
>> + S390CcwMachineState *ms = S390_CCW_MACHINE(machine);
>> VirtualCssBus *css_bus;
>> DeviceState *dev;
>>
>> + ms->pv = false;
>
> I'm wondering why you need to init this to false - isn't it already
> zeroed out?
>
>> s390_sclp_init();
>> /* init memory + setup max page size. Required for the CPU model */
>> s390_memory_init(machine->ram_size);
>> @@ -318,10 +321,58 @@ static inline void s390_do_cpu_ipl(CPUState *cs, run_on_cpu_data arg)
>> s390_cpu_set_state(S390_CPU_STATE_OPERATING, cpu);
>> }
>>
>> +static int s390_machine_pv_secure(S390CcwMachineState *ms)
>> +{
>> + CPUState *t;
>> + int rc;
>> +
>> + /* Create SE VM */
>> + rc = s390_pv_vm_create();
>> + if (rc) {
>> + return rc;
>> + }
>> +
>> + CPU_FOREACH(t) {
>> + rc = s390_pv_vcpu_create(t);
>> + if (rc) {
>> + return rc;
>
> No need to undo something on error?
There have been changes in this area anyway, since Christian switched to
one create/destroy instead of separate for vm and vcpu.
I'll update the error handling in the new state and send out the patches
ssonish.
>
>> + }
>> + }
>> +
>> + ms->pv = true;
>> +
>> + /* Set SE header and unpack */
>> + rc = s390_ipl_prepare_pv_header();
>> + if (rc) {
>> + return rc;
>
> Also here.
>
>> + }
>> +
>> + /* Decrypt image */
>> + rc = s390_ipl_pv_unpack();
>> + if (rc) {
>> + return rc;
>
> And here.
>
>> + }
>> +
>> + /* Verify integrity */
>> + rc = s390_pv_verify();
>> + return rc;
>
> And here.
>
>> +}
>
> (...)
>
>> diff --git a/target/s390x/cpu.c b/target/s390x/cpu.c
>> index 8da1905485..1dbd84b9d7 100644
>> --- a/target/s390x/cpu.c
>> +++ b/target/s390x/cpu.c
>> @@ -37,6 +37,8 @@
>> #include "sysemu/hw_accel.h"
>> #include "hw/qdev-properties.h"
>> #ifndef CONFIG_USER_ONLY
>> +#include "hw/s390x/s390-virtio-ccw.h"
>> +#include "hw/s390x/pv.h"
>> #include "hw/boards.h"
>> #include "sysemu/arch_init.h"
>> #include "sysemu/sysemu.h"
>> @@ -191,6 +193,7 @@ static void s390_cpu_realizefn(DeviceState *dev, Error **errp)
>>
>> #if !defined(CONFIG_USER_ONLY)
>> MachineState *ms = MACHINE(qdev_get_machine());
>> + S390CcwMachineState *ccw = S390_CCW_MACHINE(ms);
>
> I find the variable name a bit confusing... maybe ccw_ms?
>
>> unsigned int max_cpus = ms->smp.max_cpus;
>> if (cpu->env.core_id >= max_cpus) {
>> error_setg(&err, "Unable to add CPU with core-id: %" PRIu32
>> @@ -205,6 +208,7 @@ static void s390_cpu_realizefn(DeviceState *dev, Error **errp)
>> goto out;
>> }
>>
>> + cpu->env.pv = ccw->pv;
>
> So, if you add a cpu, it will inherit the pv state of the machine...
> doesn't it need any setup?
>
>> /* sync cs->cpu_index and env->core_id. The latter is needed for TCG. */
>> cs->cpu_index = cpu->env.core_id;
>> #endif
>
> (...)
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: mmc: sdhci-am654: Update Output tap delay binding
From: Faiz Abbas @ 2020-02-20 11:24 UTC (permalink / raw)
To: Rob Herring
Cc: linux-kernel, linux-mmc, devicetree, ulf.hansson, adrian.hunter
In-Reply-To: <24e6ac71-00c7-f140-86d8-fa5ec0dcaff0@ti.com>
Rob,
On 14/02/20 4:28 pm, Faiz Abbas wrote:
> Rob,
>
> On 07/02/20 3:07 pm, Faiz Abbas wrote:
>> Rob,
>>
>> On 20/01/20 11:00 am, Faiz Abbas wrote:
>>> Hi Rob,
>>>
>>> On 15/01/20 7:20 am, Rob Herring wrote:
>>>> On Wed, Jan 08, 2020 at 08:39:18PM +0530, Faiz Abbas wrote:
>>>>> According to latest AM65x Data Manual[1], a different output tap delay
>>>>> value is recommended for all speed modes. Therefore, replace the
>>>>> ti,otap-del-sel binding with one ti,otap-del-sel- for each MMC/SD speed
>>>>> mode.
>>>>>
>>>>> [1] http://www.ti.com/lit/gpn/am6526
>>>>>
>>>>> Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
>>>>> ---
>>>>> .../devicetree/bindings/mmc/sdhci-am654.txt | 21 +++++++++++++++++--
>>>>> 1 file changed, 19 insertions(+), 2 deletions(-)
>>>>>
>>>>> diff --git a/Documentation/devicetree/bindings/mmc/sdhci-am654.txt b/Documentation/devicetree/bindings/mmc/sdhci-am654.txt
>>>>> index 50e87df47971..c6ccecb9ae5a 100644
>>>>> --- a/Documentation/devicetree/bindings/mmc/sdhci-am654.txt
>>>>> +++ b/Documentation/devicetree/bindings/mmc/sdhci-am654.txt
>>>>> @@ -18,7 +18,20 @@ Required Properties:
>>>>> - clocks: Handles to the clock inputs.
>>>>> - clock-names: Tuple including "clk_xin" and "clk_ahb"
>>>>> - interrupts: Interrupt specifiers
>>>>> - - ti,otap-del-sel: Output Tap Delay select
>>>>> + Output tap delay for each speed mode:
>>>>> + - ti,otap-del-sel-legacy
>>>>> + - ti,otap-del-sel-mmc-hs
>>>>> + - ti,otap-del-sel-sd-hs
>>>>> + - ti,otap-del-sel-sdr12
>>>>> + - ti,otap-del-sel-sdr25
>>>>> + - ti,otap-del-sel-sdr50
>>>>> + - ti,otap-del-sel-sdr104
>>>>> + - ti,otap-del-sel-ddr50
>>>>> + - ti,otap-del-sel-ddr52
>>>>> + - ti,otap-del-sel-hs200
>>>>> + - ti,otap-del-sel-hs400
>>>>> + These bindings must be provided otherwise the driver will disable the
>>>>> + corresponding speed mode (i.e. all nodes must provide at least -legacy)
>>>>
>>>> Why not just extend the existing property to be an array. We already
>>>> have properties to enable/disable speed modes.
>>>>
>>>
>>> Its hard to keep track of which modes have values and which don't when
>>> you add an array. This scheme is just easier on anyone adding new values
>>> or updating old values.
>>>
>>> We already disable speed modes based on platform specific properties in
>>> other drivers. In sdhci-omap.c, the driver disables the corresponding
>>> speed mode if the corresponding pinmux and iodelay values are not populated.
>>>
>>
>> Do you agree on above?
>>
>
> Gentle ping.
>
Ping.
Thanks,
Faiz
^ permalink raw reply
* Re: Hard Disk consumes lots of power in s2idle
From: Kai-Heng Feng @ 2020-02-20 11:21 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Srinivas Pandruvada, Linux PM,
open list:LIBATA SUBSYSTEM (Serial and Parallel ATA drivers),
open list, Kent Lin, Tejun Heo
In-Reply-To: <CAJZ5v0in-v9iu88Wj0gAg_th-E-QWDSHZ_XvgyoOuqE=CZPtqQ@mail.gmail.com>
> On Feb 20, 2020, at 18:34, Rafael J. Wysocki <rafael@kernel.org> wrote:
>
> On Thu, Feb 20, 2020 at 11:25 AM Kai-Heng Feng
> <kai.heng.feng@canonical.com> wrote:
>>
>>
>>
>>> On Feb 20, 2020, at 18:12, Rafael J. Wysocki <rafael@kernel.org> wrote:
>>>
>>> On Thu, Feb 20, 2020 at 9:08 AM Kai-Heng Feng
>>> <kai.heng.feng@canonical.com> wrote:
>>>>
>>>> Hi Srinivas,
>>>>
>>>>> On Feb 20, 2020, at 02:36, Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> wrote:
>>>>>
>>>>> Hi Kai,
>>>>>
>>>>> On Wed, 2020-02-19 at 22:22 +0800, Kai-Heng Feng wrote:
>>>>>> Hi Srinivas,
>>>>>>
>>>>>> Your previous work to support DEVSLP works well on SATA SSDs, so I am
>>>>>> asking you the issue I am facing:
>>>>>> Once a laptop has a HDD installed, the power consumption during
>>>>>> S2Idle increases ~0.4W, which is quite a lot.
>>>>>> However, HDDs don't seem to support DEVSLP, so I wonder if you know
>>>>>> to do proper power management for HDDs?
>>>>> What is the default here
>>>>> cat /sys/power/mem_sleep
>>>>> s2idle or deep?
>>>>
>>>> It defaults to s2idle.
>>>>
>>>>>
>>>>> Please follow debug steps here:
>>>>> https://01.org/blogs/qwang59/2018/how-achieve-s0ix-states-linux
>>>>>
>>>>> We need to check whether you get any PC10 residency or not.
>>>>
>>>> Yes it reaches PC10. It doesn't reach SLP_S0 though.
>>>> The real number on S2Idle power consumption:
>>>> No HDD: ~1.4W
>>>> One HDD: ~1.8W
>>>>
>>>> If the SoC doesn't hit PC10 the number should be significantly higher.
>>>> That's why I think the issue is the power management on HDD itself.
>>>
>>> I'm assuming that you mean a non-SSD device here.
>>
>> Yes, it's spinning rust here.
>>
>>>
>>> That would be handled via ata_port_suspend() I gather and whatever
>>> that does should do the right thing.
>>>
>>> Do you think that the disk doesn't spin down or it spins down, but the
>>> logic stays on?
>>
>> The spin sound is audible, so I am certain the HDD spins down during S2Idle.
>
> OK
>
>> How do I know if the logic is on or off?
>
> Well, if it were off, it would not draw power. :-)
>
> So IMO it is reasonable to assume that the logic on the drive stays
> on. I'm not aware of anything that can be done to turn it off,
> however.
Okay, thanks for the info.
I'll ask vendors the possibility to handle it at system firmware level.
Kai-Heng
^ permalink raw reply
* Re: [PATCH net-next v3 1/9] sysfs: add sysfs_file_change_owner{_by_name}()
From: Greg Kroah-Hartman @ 2020-02-20 11:20 UTC (permalink / raw)
To: Christian Brauner
Cc: David S. Miller, linux-kernel, netdev, Rafael J. Wysocki,
Pavel Machek, Jakub Kicinski, Eric Dumazet, Stephen Hemminger,
linux-pm
In-Reply-To: <20200218162943.2488012-2-christian.brauner@ubuntu.com>
On Tue, Feb 18, 2020 at 05:29:35PM +0100, Christian Brauner wrote:
> +/**
> + * sysfs_file_change_owner - change owner of a file.
> + * @kobj: object.
> + * @kuid: new owner's kuid
> + * @kgid: new owner's kgid
> + */
> +int sysfs_file_change_owner(struct kobject *kobj, kuid_t kuid, kgid_t kgid)
> +{
> + struct kernfs_node *kn;
> + int error;
> +
> + if (!kobj->state_in_sysfs)
> + return -EINVAL;
> +
> + kernfs_get(kobj->sd);
> +
> + kn = kobj->sd;
> + error = internal_change_owner(kn, kobj, kuid, kgid);
> +
> + kernfs_put(kn);
> +
> + return error;
> +}
> +EXPORT_SYMBOL_GPL(sysfs_file_change_owner);
Oops, wait, what "file" are you changing here? You aren't changing the
kobject's attributes, but rather a file in the kobject's directory,
right? But kobj->sd is the directory of the kobject itself, so why
isn't this function just the same thing as sysfs_change_owner()?
Why would you call this function at all?
confused,
greg k-h
^ permalink raw reply
* Re: [PATCHv5 34/34] drm/rockchip: Add support for afbc
From: Boris Brezillon @ 2020-02-20 11:20 UTC (permalink / raw)
To: Andrzej Pietrasiewicz
Cc: kernel, Mihail Atanassov, David Airlie, Liviu Dudau, Sandy Huang,
dri-devel, James Wang, Ayan Halder, Sean Paul
In-Reply-To: <20191217145020.14645-35-andrzej.p@collabora.com>
On Tue, 17 Dec 2019 15:50:20 +0100
Andrzej Pietrasiewicz <andrzej.p@collabora.com> wrote:
> static const struct drm_mode_config_funcs rockchip_drm_mode_config_funcs = {
> - .fb_create = drm_gem_fb_create_with_dirty,
> + .fb_create = rockchip_fb_create,
> .output_poll_changed = drm_fb_helper_output_poll_changed,
> .atomic_check = drm_atomic_helper_check,
> .atomic_commit = drm_atomic_helper_commit,
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> index d04b3492bdac..ffe1e4b9a9ca 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> @@ -91,9 +91,21 @@
> #define VOP_WIN_TO_INDEX(vop_win) \
> ((vop_win) - (vop_win)->vop->win)
>
> +#define VOP_AFBC_SET(vop, name, v) \
> + do { \
> + if ((vop)->data->afbc) \
> + vop_reg_set((vop), &(vop)->data->afbc->name, 0, ~0, v, #name); \
> + } while (0)
> +
> #define to_vop(x) container_of(x, struct vop, crtc)
> #define to_vop_win(x) container_of(x, struct vop_win, base)
>
> +#define AFBC_FMT_RGB565 0x0
> +#define AFBC_FMT_U8U8U8U8 0x5
> +#define AFBC_FMT_U8U8U8 0x4
> +
> +#define AFBC_TILE_16x16 BIT(4)
> +
> /*
> * The coefficients of the following matrix are all fixed points.
> * The format is S2.10 for the 3x3 part of the matrix, and S9.12 for the offsets.
> @@ -166,6 +178,7 @@ struct vop {
> /* optional internal rgb encoder */
> struct rockchip_rgb *rgb;
>
> + struct vop_win *afbc_win;
Looks like something that should be in the VOP specialized crtc_state.
Also, do we really need a vop_win pointer or can it be replaced by an
index directly?
> struct vop_win win[];
> };
>
> @@ -274,6 +287,29 @@ static enum vop_data_format vop_convert_format(uint32_t format)
> }
> }
>
> +static int vop_convert_afbc_format(uint32_t format)
> +{
> + switch (format) {
> + case DRM_FORMAT_XRGB8888:
> + case DRM_FORMAT_ARGB8888:
> + case DRM_FORMAT_XBGR8888:
> + case DRM_FORMAT_ABGR8888:
> + return AFBC_FMT_U8U8U8U8;
> + case DRM_FORMAT_RGB888:
> + case DRM_FORMAT_BGR888:
> + return AFBC_FMT_U8U8U8;
> + case DRM_FORMAT_RGB565:
> + case DRM_FORMAT_BGR565:
> + return AFBC_FMT_RGB565;
> + /* either of the below should not be reachable */
> + default:
> + DRM_WARN_ONCE("unsupported AFBC format[%08x]\n", format);
> + return -EINVAL;
> + }
> +
> + return -EINVAL;
> +}
> +
> static uint16_t scl_vop_cal_scale(enum scale_mode mode, uint32_t src,
> uint32_t dst, bool is_horizontal,
> int vsu_mode, int *vskiplines)
> @@ -598,6 +634,15 @@ static int vop_enable(struct drm_crtc *crtc, struct drm_crtc_state *old_state)
> vop_win_disable(vop, vop_win);
> }
> }
> +
> + if (vop->data->afbc) {
> + /*
> + * Disable AFBC and forget there was a vop window with AFBC
> + */
> + VOP_AFBC_SET(vop, enable, 0);
> + vop->afbc_win = NULL;
> + }
> +
> spin_unlock(&vop->reg_lock);
>
> vop_cfg_done(vop);
> @@ -710,6 +755,37 @@ static void vop_plane_destroy(struct drm_plane *plane)
> drm_plane_cleanup(plane);
> }
>
> +static bool rockchip_afbc(u64 modifier)
> +{
> + return modifier == DRM_FORMAT_MOD_ARM_AFBC(AFBC_FORMAT_MOD_BLOCK_SIZE_16x16 | AFBC_FORMAT_MOD_SPARSE);
> +}
> +
> +static bool rockchip_mod_supported(struct drm_plane *plane,
> + u32 format, u64 modifier)
> +{
> + const struct drm_format_info *info;
> +
> + if (WARN_ON(modifier == DRM_FORMAT_MOD_INVALID))
> + return false;
> +
> + if (modifier == DRM_FORMAT_MOD_LINEAR)
> + return true;
> +
> + if (!rockchip_afbc(modifier)) {
> + DRM_DEBUG_KMS("Unsupported format modifer 0x%llx\n", modifier);
> +
> + return false;
> + }
> +
> + info = drm_format_info(format);
> + if (info->num_planes != 1) {
> + DRM_DEBUG_KMS("AFBC buffers expect one plane\n");
> + return false;
> + }
Should we have a call to vop_convert_afbc_format() to make sure AFBC
can be applied to this specific format?
> +
> + return true;
> +}
> +
> static int vop_plane_atomic_check(struct drm_plane *plane,
> struct drm_plane_state *state)
> {
> @@ -719,10 +795,8 @@ static int vop_plane_atomic_check(struct drm_plane *plane,
> struct vop_win *vop_win = to_vop_win(plane);
> const struct vop_win_data *win = vop_win->data;
> int ret;
> - int min_scale = win->phy->scl ? FRAC_16_16(1, 8) :
> - DRM_PLANE_HELPER_NO_SCALING;
> - int max_scale = win->phy->scl ? FRAC_16_16(8, 1) :
> - DRM_PLANE_HELPER_NO_SCALING;
> + int min_scale = win->phy->scl ? FRAC_16_16(1, 8) : DRM_PLANE_HELPER_NO_SCALING;
> + int max_scale = win->phy->scl ? FRAC_16_16(8, 1) : DRM_PLANE_HELPER_NO_SCALING;
Looks like those coding-style fixes have nothing to do in this patch :).
>
> if (!crtc || !fb)
> return 0;
> @@ -731,9 +805,7 @@ static int vop_plane_atomic_check(struct drm_plane *plane,
> if (WARN_ON(!crtc_state))
> return -EINVAL;
>
> - ret = drm_atomic_helper_check_plane_state(state, crtc_state,
> - min_scale, max_scale,
> - true, true);
> + ret = drm_atomic_helper_check_plane_state(state, crtc_state, min_scale, max_scale, true, true);
Same here, plus, following the 80 char rule when it doesn't hurt
readability is a good thing I think.
> if (ret)
> return ret;
>
> @@ -758,6 +830,31 @@ static int vop_plane_atomic_check(struct drm_plane *plane,
> return -EINVAL;
> }
>
> + if (rockchip_afbc(fb->modifier)) {
> + struct vop *vop = to_vop(crtc);
> +
> + if (!vop->data->afbc) {
> + DRM_ERROR("vop does not support AFBC\n");
> + return -EINVAL;
> + }
> +
> + ret = vop_convert_afbc_format(fb->format->format);
> + if (ret < 0)
> + return ret;
> +
> + if (state->src.x1 || state->src.y1) {
> + DRM_ERROR("afbc does not support offset display\n");
> + DRM_ERROR("xpos=%d, ypos=%d, offset=%d\n", state->src.x1, state->src.y1, fb->offsets[0]);
Why splitting that in 2 error messages?
> + return -EINVAL;
> + }
> +
> + if (state->rotation && state->rotation != DRM_MODE_ROTATE_0) {
> + DRM_ERROR("afbc does not support rotation\n");
> + DRM_ERROR("rotation=%d\n", state->rotation);
Ditto.
> + return -EINVAL;
> + }
> + }
> +
> return 0;
> }
>
> @@ -773,6 +870,11 @@ static void vop_plane_atomic_disable(struct drm_plane *plane,
> spin_lock(&vop->reg_lock);
>
> vop_win_disable(vop, vop_win);
> + /*
> + * Forget about the AFBC window if it is being disabled
> + */
> + if (vop_win == vop->afbc_win)
> + vop->afbc_win = NULL;
>
> spin_unlock(&vop->reg_lock);
> }
> @@ -812,6 +914,13 @@ static void vop_plane_atomic_update(struct drm_plane *plane,
> if (WARN_ON(!vop->is_enabled))
> return;
>
> + /*
> + * If updating the AFBC window then assume that
> + * after the update there will be no AFBC window.
> + */
> + if (vop_win == vop->afbc_win)
> + vop->afbc_win = NULL;
> +
> if (!state->visible) {
> vop_plane_atomic_disable(plane, old_state);
> return;
> @@ -846,6 +955,21 @@ static void vop_plane_atomic_update(struct drm_plane *plane,
>
> spin_lock(&vop->reg_lock);
>
> + if (rockchip_afbc(fb->modifier)) {
> + int afbc_format = vop_convert_afbc_format(fb->format->format);
> +
> + VOP_AFBC_SET(vop, format, afbc_format | AFBC_TILE_16x16);
> + VOP_AFBC_SET(vop, hreg_block_split, 0);
> + VOP_AFBC_SET(vop, win_sel, VOP_WIN_TO_INDEX(vop_win));
IIUC, only one plane can use AFBC at a given time, but you don't seem
to check the value of vop->afbc_win in your atomic_check. What happens
if the user tries to enable this modifier on 2+ planes?
> + VOP_AFBC_SET(vop, hdr_ptr, dma_addr);
> + VOP_AFBC_SET(vop, pic_size, act_info);
> +
> + /*
> + * The window being udated becomes the AFBC window
> + */
> + vop->afbc_win = vop_win;
> + }
> +
> VOP_WIN_SET(vop, win, format, format);
> VOP_WIN_SET(vop, win, yrgb_vir, DIV_ROUND_UP(fb->pitches[0], 4));
> VOP_WIN_SET(vop, win, yrgb_mst, dma_addr);
> @@ -1001,6 +1125,7 @@ static const struct drm_plane_funcs vop_plane_funcs = {
> .reset = drm_atomic_helper_plane_reset,
> .atomic_duplicate_state = drm_atomic_helper_plane_duplicate_state,
> .atomic_destroy_state = drm_atomic_helper_plane_destroy_state,
> + .format_mod_supported = rockchip_mod_supported,
> };
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [cip-dev] [PATCH 4.19.y-cip 15/23] usb: typec: driver for TI HD3SS3220 USB Type-C DRP port controller
From: Marian-Cristian Rotariu @ 2020-02-20 11:20 UTC (permalink / raw)
To: Pavel Machek; +Cc: cip-dev@lists.cip-project.org
In-Reply-To: <20200219081234.GD31996@amd>
Hi!
> -----Original Message-----
> From: Pavel Machek <pavel@denx.de>
> Sent: 19 February 2020 08:13
> To: Marian-Cristian Rotariu <marian-cristian.rotariu.rb@bp.renesas.com>
> Cc: cip-dev@lists.cip-project.org
> Subject: Re: [cip-dev] [PATCH 4.19.y-cip 15/23] usb: typec: driver for TI
> HD3SS3220 USB Type-C DRP port controller
>
> Hi!
>
> > From: Biju Das <biju.das@bp.renesas.com>
> >
> > commit 1c48c759ef4bb9031b3347277f04484e07e27d97 upstream.
> >
> > Driver for TI HD3SS3220 USB Type-C DRP port controller.
> >
> > The driver currently registers the port and supports data role
> > swapping.
>
> Ok, so this has few problems that are fixed by subsequent patches, but I
> believe I see some more:
>
> > +static enum usb_role hd3ss3220_get_attached_state(struct hd3ss3220
> > +*hd3ss3220) {
> > + unsigned int reg_val;
> > + enum usb_role attached_state;
> > + int ret;
> > +
> > + ret = regmap_read(hd3ss3220->regmap,
> HD3SS3220_REG_CN_STAT_CTRL,
> > + ®_val);
> > + if (ret < 0)
> > + return ret;
>
> This function claims to return "enum usb_role", but here it returns errno
> from regmap_read.
>
> > +static int hd3ss3220_dr_set(const struct typec_capability *cap,
> > + enum typec_data_role role)
> > +{
> ...
> > + ret = hd3ss3220_set_source_pref(hd3ss3220, pref);
> > + usleep_range(10, 100);
>
> Would udelay() make more sense here? Are your CPUs / timer subsystem so
> fast that sleeping for 10usec is possible and reasonable to do?
I think Biju followed the overall indications from:
Documentation/timers-howto.txt (.rst)
According to the documentation the inflection point is at 10us, so this is kind
of a grey area. Just to put it in context, the RZ/G2E has 2x1.2Ghz ARM Cortex A53.
Therefore this is kind of a high-performance embedded platform. At least, we
like to advertise it like that 😊
So, I am inclined to keep this as it is if you agree.
Cheers,
Marian.
_______________________________________________
cip-dev mailing list
cip-dev@lists.cip-project.org
https://lists.cip-project.org/mailman/listinfo/cip-dev
^ permalink raw reply
* Re: [Intel-gfx] [PATCH 04/12] drm/i915: Add i9xx_lut_8()
From: Emil Velikov @ 2020-02-20 11:20 UTC (permalink / raw)
To: Ville Syrjala; +Cc: Intel Graphics Development, ML dri-devel
In-Reply-To: <20191107151725.10507-5-ville.syrjala@linux.intel.com>
On Thu, 7 Nov 2019 at 15:17, Ville Syrjala
<ville.syrjala@linux.intel.com> wrote:
>
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>
> We have a nice little helper to compute a single LUT entry
> for everything except the 8bpc legacy gamma mode. Let's
> complete the set.
>
At a later stage one could rename this & the 10bit one, moving them to
include/drm/.
There are other drivers doing the same thing... not sure if that's
worth it though.
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
-Emil
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [Intel-gfx] [PATCH 04/12] drm/i915: Add i9xx_lut_8()
From: Emil Velikov @ 2020-02-20 11:20 UTC (permalink / raw)
To: Ville Syrjala; +Cc: Intel Graphics Development, ML dri-devel
In-Reply-To: <20191107151725.10507-5-ville.syrjala@linux.intel.com>
On Thu, 7 Nov 2019 at 15:17, Ville Syrjala
<ville.syrjala@linux.intel.com> wrote:
>
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>
> We have a nice little helper to compute a single LUT entry
> for everything except the 8bpc legacy gamma mode. Let's
> complete the set.
>
At a later stage one could rename this & the 10bit one, moving them to
include/drm/.
There are other drivers doing the same thing... not sure if that's
worth it though.
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
-Emil
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [PATCH] aio-posix: avoid reacquiring rcu_read_lock() when polling
From: Paolo Bonzini @ 2020-02-20 11:19 UTC (permalink / raw)
To: Stefan Hajnoczi, qemu-devel; +Cc: Fam Zheng, qemu-block
In-Reply-To: <20200218182708.914552-1-stefanha@redhat.com>
On 18/02/20 19:27, Stefan Hajnoczi wrote:
> The first rcu_read_lock/unlock() is expensive. Nested calls are cheap.
>
> This optimization increases IOPS from 73k to 162k with a Linux guest
> that has 2 virtio-blk,num-queues=1 and 99 virtio-blk,num-queues=32
> devices.
>
> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
> ---
> util/aio-posix.c | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> diff --git a/util/aio-posix.c b/util/aio-posix.c
> index a4977f538e..f67f5b34e9 100644
> --- a/util/aio-posix.c
> +++ b/util/aio-posix.c
> @@ -15,6 +15,7 @@
>
> #include "qemu/osdep.h"
> #include "block/block.h"
> +#include "qemu/rcu.h"
> #include "qemu/rcu_queue.h"
> #include "qemu/sockets.h"
> #include "qemu/cutils.h"
> @@ -514,6 +515,16 @@ static bool run_poll_handlers_once(AioContext *ctx, int64_t *timeout)
> bool progress = false;
> AioHandler *node;
>
> + /*
> + * Optimization: ->io_poll() handlers often contain RCU read critical
> + * sections and we therefore see many rcu_read_lock() -> rcu_read_unlock()
> + * -> rcu_read_lock() -> ... sequences with expensive memory
> + * synchronization primitives. Make the entire polling loop an RCU
> + * critical section because nested rcu_read_lock()/rcu_read_unlock() calls
> + * are cheap.
> + */
> + RCU_READ_LOCK_GUARD();
> +
> QLIST_FOREACH_RCU(node, &ctx->aio_handlers, node) {
> if (!node->deleted && node->io_poll &&
> aio_node_check(ctx, node->is_external) &&
>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
^ permalink raw reply
* Re: [PATCH v6 0/5] Reftable support git-core
From: Jeff King @ 2020-02-20 11:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Han-Wen Nienhuys, Han-Wen Nienhuys via GitGitGadget, git
In-Reply-To: <xmqq8skyfnxm.fsf@gitster-ct.c.googlers.com>
On Wed, Feb 19, 2020 at 10:10:29AM -0800, Junio C Hamano wrote:
> Han-Wen Nienhuys <hanwenn@gmail.com> writes:
>
> > On Wed, Feb 19, 2020 at 6:02 PM Junio C Hamano <gitster@pobox.com> wrote:
> >
> >> > your checker is tripping over code imported from zlib. I added a /*
> >> > clang-format off */ comment to avoid reformatting this code. What do
> >> > you suggest?
> >>
> >> Use zlib from the system instead?
> >
> > uncompress2 is a 2016 addition to zlib. It doesn't pass on
> > gitgitgadget's CI, because it is using an older version of zlib.
>
> Ahh.
>
> It is OK (and indeed you're right that you cannot avoid it) to ship
> a reasonably new snapshot as a fallback in such a case, but it still
> is far more preferrable to avoid linking with the fallback snapshot
> copy when a working one is available on the system, especially for a
> widely used and established library like zlib, because we have one
> less thing to keep up-to-date with the security patches made to the
> upstream.
If this were substantial code, I'd agree. But this is really just a thin
wrapper around the usual loop zlib inflate() loop that we already do in
a dozen places in our code (e.g., unpack_loose_rest(), which even does
the "did we consume all the bytes" check that uncompress2 allows).
I'm not sure it is worth the mental energy of adding a Makefile knob to
use the zlib version if we can just open-code it ourselves (or provide
our own custom helper that we always use).
And if it _is_ worth taking the zlib version because we're concerned
that it may contain or gain bugfixes[1], then possibly we should
be using it in lots more places (though probably not everywhere, as we
do sometimes need the streaming behavior of the loop).
[1] I'll admit we've hit some subtleties with that loop in the past,
especially around corrupted or bogus inputs, but I think we've
shaken them all out these days.
-Peff
^ permalink raw reply
* Re: [PATCH v4 3/5] dt-bindings: clock: Add YAML schemas for the QCOM MSS clock bindings
From: Sibi Sankar @ 2020-02-20 11:18 UTC (permalink / raw)
To: Taniya Das
Cc: Rob Herring, Stephen Boyd, Michael Turquette, David Brown,
Rajendra Nayak, linux-arm-msm, linux-soc, linux-clk, linux-kernel,
Andy Gross, devicetree, robh+dt, linux-soc-owner
In-Reply-To: <6298769e-09bc-eb69-bf72-5aedd0e87f16@codeaurora.org>
Hey Taniya,
+ <&gcc GCC_MSS_NAV_AXIS_CLK>,
error is because of ^^ typo
it should be GCC_MSS_NAV_AXI_CLK
instead, with that dt_bindings
check will go though.
On 2020-02-19 09:35, Taniya Das wrote:
> Hi Rob,
>
> On 2/19/2020 4:30 AM, Rob Herring wrote:
>> On Tue, 18 Feb 2020 23:45:31 +0530, Taniya Das wrote:
>>> The Modem Subsystem clock provider have a bunch of generic properties
>>> that are needed in a device tree. Add a YAML schemas for those.
>>>
>>> Signed-off-by: Taniya Das <tdas@codeaurora.org>
>>> ---
>>> .../devicetree/bindings/clock/qcom,sc7180-mss.yaml | 62
>>> ++++++++++++++++++++++
>>> 1 file changed, 62 insertions(+)
>>> create mode 100644
>>> Documentation/devicetree/bindings/clock/qcom,sc7180-mss.yaml
>>>
>>
>> My bot found errors running 'make dt_binding_check' on your patch:
>>
>> Error:
>> Documentation/devicetree/bindings/clock/qcom,sc7180-mss.example.dts:21.26-27
>> syntax error
>> FATAL ERROR: Unable to parse input tree
>> scripts/Makefile.lib:300: recipe for target
>> 'Documentation/devicetree/bindings/clock/qcom,sc7180-mss.example.dt.yaml'
>> failed
>> make[1]: ***
>> [Documentation/devicetree/bindings/clock/qcom,sc7180-mss.example.dt.yaml]
>> Error 1
>> Makefile:1263: recipe for target 'dt_binding_check' failed
>> make: *** [dt_binding_check] Error 2
>>
>> See https://patchwork.ozlabs.org/patch/1240251
>> Please check and re-submit.
>>
>
> I did see the same issue and then when I re-ordered by patches
> dt-bindings: clock: Add support for Modem clocks in GCC (dependent) on
> this binding patch, I no longer encountered the issue.
> https://patchwork.kernel.org/patch/11389243/
>
> Please let me know.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project.
^ permalink raw reply
* Re: [PATCH net-next v3 3/9] sysfs: add sysfs_group{s}_change_owner()
From: Greg Kroah-Hartman @ 2020-02-20 11:15 UTC (permalink / raw)
To: Christian Brauner
Cc: David S. Miller, linux-kernel, netdev, Rafael J. Wysocki,
Pavel Machek, Jakub Kicinski, Eric Dumazet, Stephen Hemminger,
linux-pm
In-Reply-To: <20200218162943.2488012-4-christian.brauner@ubuntu.com>
On Tue, Feb 18, 2020 at 05:29:37PM +0100, Christian Brauner wrote:
> Add helpers to change the owner of sysfs groups.
> This function will be used to correctly account for kobject ownership
> changes, e.g. when moving network devices between network namespaces.
>
> Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
> ---
> /* v2 */
> - Greg Kroah-Hartman <gregkh@linuxfoundation.org>:
> - Add comment how ownership of sysfs object is changed.
>
> /* v3 */
> - Greg Kroah-Hartman <gregkh@linuxfoundation.org>:
> - Add explicit uid/gid parameters.
> - Christian Brauner <christian.brauner@ubuntu.com>:
> - Collapse groups ownership helper patches into a single patch.
> ---
> fs/sysfs/group.c | 117 ++++++++++++++++++++++++++++++++++++++++++
> include/linux/sysfs.h | 20 ++++++++
> 2 files changed, 137 insertions(+)
>
> diff --git a/fs/sysfs/group.c b/fs/sysfs/group.c
> index c4ab045926b7..bae562d3cba1 100644
> --- a/fs/sysfs/group.c
> +++ b/fs/sysfs/group.c
> @@ -13,6 +13,7 @@
> #include <linux/dcache.h>
> #include <linux/namei.h>
> #include <linux/err.h>
> +#include <linux/fs.h>
> #include "sysfs.h"
>
>
> @@ -457,3 +458,119 @@ int __compat_only_sysfs_link_entry_to_kobj(struct kobject *kobj,
> return PTR_ERR_OR_ZERO(link);
> }
> EXPORT_SYMBOL_GPL(__compat_only_sysfs_link_entry_to_kobj);
> +
> +static int sysfs_group_attrs_change_owner(struct kernfs_node *grp_kn,
> + const struct attribute_group *grp,
> + struct iattr *newattrs)
> +{
> + struct kernfs_node *kn;
> + int error;
> +
> + if (grp->attrs) {
> + struct attribute *const *attr;
> +
> + for (attr = grp->attrs; *attr; attr++) {
> + kn = kernfs_find_and_get(grp_kn, (*attr)->name);
> + if (!kn)
> + return -ENOENT;
> +
> + error = kernfs_setattr(kn, newattrs);
> + kernfs_put(kn);
> + if (error)
> + return error;
> + }
> + }
> +
> + if (grp->bin_attrs) {
> + struct bin_attribute *const *bin_attr;
> +
> + for (bin_attr = grp->bin_attrs; *bin_attr; bin_attr++) {
> + kn = kernfs_find_and_get(grp_kn, (*bin_attr)->attr.name);
> + if (!kn)
> + return -ENOENT;
> +
> + error = kernfs_setattr(kn, newattrs);
> + kernfs_put(kn);
> + if (error)
> + return error;
> + }
> + }
> +
> + return 0;
> +}
> +
> +/**
> + * sysfs_group_change_owner - change owner of an attribute group.
> + * @kobj: The kobject containing the group.
> + * @grp: The attribute group.
> + * @kuid: new owner's kuid
> + * @kgid: new owner's kgid
> + *
> + * Returns 0 on success or error code on failure.
This is fine to document, just funny it's the only one documented about
the return value so far in this series.
Anyway, looks good to me:
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
^ permalink raw reply
* [Intel-gfx] [PULL] drm-intel-fixes
From: Jani Nikula @ 2020-02-20 11:14 UTC (permalink / raw)
To: Dave Airlie, Daniel Vetter; +Cc: dim-tools, dri-devel, Maxime Ripard, intel-gfx
Hi Dave & Daniel -
Due to issues in s2idle in v5.6-rc2, I've gotten CI results on these
with two hack reverts on top, and I threw them out just before making
the pull request. I had to revert:
fdde0ff8590b ("ACPI: PM: s2idle: Prevent spurious SCIs from waking up the system")
e3728b50cd9b ("ACPI: PM: s2idle: Avoid possible race related to the EC GPE")
I've been told the issues have been reported, hopefully we'll get the
fixes in Linus' upstream soon too.
drm-intel-fixes-2020-02-20:
drm/i915 fixes for v5.6-rc3:
- Workaround missing Display Stream Compression (DSC) state readout by
forcing modeset when its enabled at probe
- Fix EHL port clock voltage level requirements
- Fix queuing retire workers on the virtual engine
- Fix use of partially initialized waiters
- Stop using drm_pci_alloc/drm_pci/free
- Fix rewind of RING_TAIL by forcing a context reload
- Fix locking on resetting ring->head
- Propagate our bug filing URL change to stable kernels
BR,
Jani.
The following changes since commit 11a48a5a18c63fd7621bb050228cebf13566e4d8:
Linux 5.6-rc2 (2020-02-16 13:16:59 -0800)
are available in the Git repository at:
git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2020-02-20
for you to fetch changes up to 15de9cb5c9c83a23be92b8f7a1178cead1486587:
drm/i915/gt: Avoid resetting ring->head outside of its timeline mutex (2020-02-18 09:53:18 +0200)
----------------------------------------------------------------
drm/i915 fixes for v5.6-rc3:
- Workaround missing Display Stream Compression (DSC) state readout by
forcing modeset when its enabled at probe
- Fix EHL port clock voltage level requirements
- Fix queuing retire workers on the virtual engine
- Fix use of partially initialized waiters
- Stop using drm_pci_alloc/drm_pci/free
- Fix rewind of RING_TAIL by forcing a context reload
- Fix locking on resetting ring->head
- Propagate our bug filing URL change to stable kernels
----------------------------------------------------------------
Chris Wilson (7):
drm/i915/gem: Require per-engine reset support for non-persistent contexts
drm/i915: Initialise basic fence before acquiring seqno
drm/i915/gt: Prevent queuing retire workers on the virtual engine
drm/i915/gt: Protect defer_request() from new waiters
drm/i915: Wean off drm_pci_alloc/drm_pci_free
drm/i915/execlists: Always force a context reload when rewinding RING_TAIL
drm/i915/gt: Avoid resetting ring->head outside of its timeline mutex
Jani Nikula (3):
MAINTAINERS: Update drm/i915 bug filing URL
drm/i915: Update drm/i915 bug filing URL
drm/i915/dsc: force full modeset whenever DSC is enabled at probe
Matt Roper (1):
drm/i915/ehl: Update port clock voltage level requirements
MAINTAINERS | 2 +-
drivers/gpu/drm/i915/Kconfig | 5 +-
drivers/gpu/drm/i915/display/intel_ddi.c | 4 +-
drivers/gpu/drm/i915/display/intel_display.c | 20 ++++-
drivers/gpu/drm/i915/gem/i915_gem_context.c | 16 ++++
drivers/gpu/drm/i915/gem/i915_gem_object_types.h | 3 -
drivers/gpu/drm/i915/gem/i915_gem_phys.c | 98 ++++++++++++------------
drivers/gpu/drm/i915/gt/intel_breadcrumbs.c | 3 +
drivers/gpu/drm/i915/gt/intel_gt_requests.c | 3 +
drivers/gpu/drm/i915/gt/intel_lrc.c | 61 +++++++--------
drivers/gpu/drm/i915/gt/intel_ring.c | 1 +
drivers/gpu/drm/i915/gt/intel_ring.h | 8 ++
drivers/gpu/drm/i915/gt/intel_ring_types.h | 7 +-
drivers/gpu/drm/i915/gt/selftest_lrc.c | 2 +-
drivers/gpu/drm/i915/i915_gem.c | 8 +-
drivers/gpu/drm/i915/i915_gpu_error.c | 3 +-
drivers/gpu/drm/i915/i915_request.c | 21 +++--
drivers/gpu/drm/i915/i915_scheduler.c | 6 +-
drivers/gpu/drm/i915/i915_utils.c | 5 +-
19 files changed, 168 insertions(+), 108 deletions(-)
--
Jani Nikula, Intel Open Source Graphics Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* [PULL] drm-intel-fixes
From: Jani Nikula @ 2020-02-20 11:14 UTC (permalink / raw)
To: Dave Airlie, Daniel Vetter
Cc: dim-tools, dri-devel, Rodrigo Vivi, Sean Paul, intel-gfx
Hi Dave & Daniel -
Due to issues in s2idle in v5.6-rc2, I've gotten CI results on these
with two hack reverts on top, and I threw them out just before making
the pull request. I had to revert:
fdde0ff8590b ("ACPI: PM: s2idle: Prevent spurious SCIs from waking up the system")
e3728b50cd9b ("ACPI: PM: s2idle: Avoid possible race related to the EC GPE")
I've been told the issues have been reported, hopefully we'll get the
fixes in Linus' upstream soon too.
drm-intel-fixes-2020-02-20:
drm/i915 fixes for v5.6-rc3:
- Workaround missing Display Stream Compression (DSC) state readout by
forcing modeset when its enabled at probe
- Fix EHL port clock voltage level requirements
- Fix queuing retire workers on the virtual engine
- Fix use of partially initialized waiters
- Stop using drm_pci_alloc/drm_pci/free
- Fix rewind of RING_TAIL by forcing a context reload
- Fix locking on resetting ring->head
- Propagate our bug filing URL change to stable kernels
BR,
Jani.
The following changes since commit 11a48a5a18c63fd7621bb050228cebf13566e4d8:
Linux 5.6-rc2 (2020-02-16 13:16:59 -0800)
are available in the Git repository at:
git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2020-02-20
for you to fetch changes up to 15de9cb5c9c83a23be92b8f7a1178cead1486587:
drm/i915/gt: Avoid resetting ring->head outside of its timeline mutex (2020-02-18 09:53:18 +0200)
----------------------------------------------------------------
drm/i915 fixes for v5.6-rc3:
- Workaround missing Display Stream Compression (DSC) state readout by
forcing modeset when its enabled at probe
- Fix EHL port clock voltage level requirements
- Fix queuing retire workers on the virtual engine
- Fix use of partially initialized waiters
- Stop using drm_pci_alloc/drm_pci/free
- Fix rewind of RING_TAIL by forcing a context reload
- Fix locking on resetting ring->head
- Propagate our bug filing URL change to stable kernels
----------------------------------------------------------------
Chris Wilson (7):
drm/i915/gem: Require per-engine reset support for non-persistent contexts
drm/i915: Initialise basic fence before acquiring seqno
drm/i915/gt: Prevent queuing retire workers on the virtual engine
drm/i915/gt: Protect defer_request() from new waiters
drm/i915: Wean off drm_pci_alloc/drm_pci_free
drm/i915/execlists: Always force a context reload when rewinding RING_TAIL
drm/i915/gt: Avoid resetting ring->head outside of its timeline mutex
Jani Nikula (3):
MAINTAINERS: Update drm/i915 bug filing URL
drm/i915: Update drm/i915 bug filing URL
drm/i915/dsc: force full modeset whenever DSC is enabled at probe
Matt Roper (1):
drm/i915/ehl: Update port clock voltage level requirements
MAINTAINERS | 2 +-
drivers/gpu/drm/i915/Kconfig | 5 +-
drivers/gpu/drm/i915/display/intel_ddi.c | 4 +-
drivers/gpu/drm/i915/display/intel_display.c | 20 ++++-
drivers/gpu/drm/i915/gem/i915_gem_context.c | 16 ++++
drivers/gpu/drm/i915/gem/i915_gem_object_types.h | 3 -
drivers/gpu/drm/i915/gem/i915_gem_phys.c | 98 ++++++++++++------------
drivers/gpu/drm/i915/gt/intel_breadcrumbs.c | 3 +
drivers/gpu/drm/i915/gt/intel_gt_requests.c | 3 +
drivers/gpu/drm/i915/gt/intel_lrc.c | 61 +++++++--------
drivers/gpu/drm/i915/gt/intel_ring.c | 1 +
drivers/gpu/drm/i915/gt/intel_ring.h | 8 ++
drivers/gpu/drm/i915/gt/intel_ring_types.h | 7 +-
drivers/gpu/drm/i915/gt/selftest_lrc.c | 2 +-
drivers/gpu/drm/i915/i915_gem.c | 8 +-
drivers/gpu/drm/i915/i915_gpu_error.c | 3 +-
drivers/gpu/drm/i915/i915_request.c | 21 +++--
drivers/gpu/drm/i915/i915_scheduler.c | 6 +-
drivers/gpu/drm/i915/i915_utils.c | 5 +-
19 files changed, 168 insertions(+), 108 deletions(-)
--
Jani Nikula, Intel Open Source Graphics Center
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ 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.