* Re: [Qemu-devel] [PATCH v6 1/2] block/vxhs.c: Add support for a new block device type called "vxhs"
From: Stefan Hajnoczi @ 2016-11-14 16:50 UTC (permalink / raw)
To: Fam Zheng
Cc: Ashish Mittal, qemu-devel, pbonzini, kwolf, armbru, berrange,
jcody, ashish.mittal, Rakesh.Ranjan, Buddhi.Madhav,
Ketan.Nilangekar, Abhijit.Dey, Venkatesha.Mg
In-Reply-To: <20161114154906.GC2373@lemon>
[-- Attachment #1: Type: text/plain, Size: 1360 bytes --]
On Mon, Nov 14, 2016 at 11:49:06PM +0800, Fam Zheng wrote:
> On Mon, 11/14 15:07, Stefan Hajnoczi wrote:
> > On Mon, Nov 07, 2016 at 04:59:44PM -0800, Ashish Mittal wrote:
> > > diff --git a/block/vxhs.c b/block/vxhs.c
> > > new file mode 100644
> > > index 0000000..8913e8f
> > > --- /dev/null
> > > +++ b/block/vxhs.c
> > > @@ -0,0 +1,689 @@
> > > +/*
> > > + * QEMU Block driver for Veritas HyperScale (VxHS)
> > > + *
> > > + * This work is licensed under the terms of the GNU GPL, version 2 or later.
> > > + * See the COPYING file in the top-level directory.
> > > + *
> > > + */
> > > +
> > > +#include "qemu/osdep.h"
> > > +#include "block/block_int.h"
> > > +#include <qnio/qnio_api.h>
> >
> > Please move system headers (<>) above user headers (""). This way you
> > can be sure the system header isn't affected by any macros defined by
> > user headers.
>
> Yes, but still after "qemu/osdep.h", which prepares necessary bits for any other
> headers.
I disagree. qnio_api.h is a third-party library that doesn't need QEMU
headers to fix up the environment for it.
By including osdep.h first you mask bugs in qnio_api.h. Perhaps
qnio_api.h forgot to include a header and we won't notice because
osdep.h happened to bring in those headers first...
Can you explain the rationale for your statement?
Stefan
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
^ permalink raw reply
* Re: [RFC PATCH v3 02/20] x86: Set the write-protect cache mode for full PAT support
From: Tom Lendacky @ 2016-11-14 16:51 UTC (permalink / raw)
To: Kani, Toshimitsu, bp-Gina5bIWoIWzQB+pC5nmwQ@public.gmane.org
Cc: linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
rkrcmar-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org,
kvm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
matt-mF/unelCI9GS6iBeEJttW/XRex20P6io@public.gmane.org,
linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org,
glider-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org,
hpa-YMNOUZJC4hwAvxtiuMwx3w@public.gmane.org,
lwoodman-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org,
linux-arch-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
corbet-T1hC0tSOHrs@public.gmane.org,
x86-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
kasan-dev-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org,
mingo-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org,
aryabinin-5HdwGun5lf+gSpxsJD1C4w@public.gmane.org,
riel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org,
arnd-r2nGTMty4D4@public.gmane.org,
luto-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org,
dvyukov-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org
In-Reply-To: <1478827480.20881.142.camel-ZPxbGqLxI0U@public.gmane.org>
On 11/10/2016 07:26 PM, Kani, Toshimitsu wrote:
> On Thu, 2016-11-10 at 14:14 +0100, Borislav Petkov wrote:
>> + Toshi.
>>
>> On Wed, Nov 09, 2016 at 06:34:48PM -0600, Tom Lendacky wrote:
>>>
>>> For processors that support PAT, set the write-protect cache mode
>>> (_PAGE_CACHE_MODE_WP) entry to the actual write-protect value
>>> (x05).
>
> Using slot 6 may be more cautious (for the same reason slot 7 was used
> for WT), but I do not have a strong opinion for it.
>
> set_page_memtype() cannot track the use of WP type since there is no
> extra-bit available for WP, but WP is only supported by
> early_memremap_xx() interfaces in this series. So, I think we should
> just document that WP is only intended for temporary mappings at boot-
> time until this issue is resolved. Also, we need to make sure that
> this early_memremap for WP is only called after pat_init() is done.
Sounds good, I'll add documentation to cover these points.
>
> A nit - please add WP to the function header comment below.
> "This function initializes PAT MSR and PAT table with an OS-defined
> value to enable additional cache attributes, WC and WT."
Will do.
Thanks,
Tom
>
> Thanks,
> -Toshi
>
^ permalink raw reply
* Re: [RFC PATCH v3 02/20] x86: Set the write-protect cache mode for full PAT support
From: Tom Lendacky @ 2016-11-14 16:51 UTC (permalink / raw)
To: Kani, Toshimitsu, bp-Gina5bIWoIWzQB+pC5nmwQ@public.gmane.org
Cc: linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
rkrcmar-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org,
kvm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
matt-mF/unelCI9GS6iBeEJttW/XRex20P6io@public.gmane.org,
linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org,
glider-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org,
hpa-YMNOUZJC4hwAvxtiuMwx3w@public.gmane.org,
lwoodman-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org,
linux-arch-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
corbet-T1hC0tSOHrs@public.gmane.org,
x86-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
kasan-dev-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org,
mingo-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org,
aryabinin-5HdwGun5lf+gSpxsJD1C4w@public.gmane.org,
riel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org,
arnd-r2nGTMty4D4@public.gmane.org,
luto-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org,
dvyukov-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org
In-Reply-To: <1478827480.20881.142.camel-ZPxbGqLxI0U@public.gmane.org>
On 11/10/2016 07:26 PM, Kani, Toshimitsu wrote:
> On Thu, 2016-11-10 at 14:14 +0100, Borislav Petkov wrote:
>> + Toshi.
>>
>> On Wed, Nov 09, 2016 at 06:34:48PM -0600, Tom Lendacky wrote:
>>>
>>> For processors that support PAT, set the write-protect cache mode
>>> (_PAGE_CACHE_MODE_WP) entry to the actual write-protect value
>>> (x05).
>
> Using slot 6 may be more cautious (for the same reason slot 7 was used
> for WT), but I do not have a strong opinion for it.
>
> set_page_memtype() cannot track the use of WP type since there is no
> extra-bit available for WP, but WP is only supported by
> early_memremap_xx() interfaces in this series. So, I think we should
> just document that WP is only intended for temporary mappings at boot-
> time until this issue is resolved. Also, we need to make sure that
> this early_memremap for WP is only called after pat_init() is done.
Sounds good, I'll add documentation to cover these points.
>
> A nit - please add WP to the function header comment below.
> "This function initializes PAT MSR and PAT table with an OS-defined
> value to enable additional cache attributes, WC and WT."
Will do.
Thanks,
Tom
>
> Thanks,
> -Toshi
>
^ permalink raw reply
* Re: [WireGuard] [PATCH v3] ip6_output: ensure flow saddr actually belongs to device
From: Jason A. Donenfeld @ 2016-11-14 16:54 UTC (permalink / raw)
To: David Ahern, David Miller
Cc: Netdev, Hannes Frederic Sowa, YOSHIFUJI Hideaki,
WireGuard mailing list, LKML
In-Reply-To: <CAHmME9qC4xqGOwJnauXrJBDkAtmmuJ+kJKL6ufuU9_XWKNFdSA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 201 bytes --]
On Nov 14, 2016 17:19, "David Ahern" <dsa@cumulusnetworks.com> wrote:
>
> LGTM
>
> Acked-by: David Ahern <dsa@cumulusnetworks.com>
Great.
@DaveM: can we get this in 4.9 and in stable?
Thanks,
Jason
[-- Attachment #2: Type: text/html, Size: 410 bytes --]
^ permalink raw reply
* Re: [RFC PATCH v3 02/20] x86: Set the write-protect cache mode for full PAT support
From: Tom Lendacky @ 2016-11-14 16:51 UTC (permalink / raw)
To: Kani, Toshimitsu, bp@alien8.de
Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
dvyukov@google.com, corbet@lwn.net, arnd@arndb.de,
matt@codeblueprint.co.uk, linux-mm@kvack.org,
aryabinin@virtuozzo.com, tglx@linutronix.de,
konrad.wilk@oracle.com, kasan-dev@googlegroups.com,
x86@kernel.org, iommu@lists.linux-foundation.org, riel@redhat.com,
lwoodman@redhat.com, mingo@redhat.com, joro@8bytes.org,
linux-efi@vger.kernel.org, pbonzini@redhat.com, hpa@zytor.com,
luto@kernel.org, glider@google.com, linux-arch@vger.kernel.org,
linux-doc@vger.kernel.org, rkrcmar@redhat.com
In-Reply-To: <1478827480.20881.142.camel@hpe.com>
On 11/10/2016 07:26 PM, Kani, Toshimitsu wrote:
> On Thu, 2016-11-10 at 14:14 +0100, Borislav Petkov wrote:
>> + Toshi.
>>
>> On Wed, Nov 09, 2016 at 06:34:48PM -0600, Tom Lendacky wrote:
>>>
>>> For processors that support PAT, set the write-protect cache mode
>>> (_PAGE_CACHE_MODE_WP) entry to the actual write-protect value
>>> (x05).
>
> Using slot 6 may be more cautious (for the same reason slot 7 was used
> for WT), but I do not have a strong opinion for it.
>
> set_page_memtype() cannot track the use of WP type since there is no
> extra-bit available for WP, but WP is only supported by
> early_memremap_xx() interfaces in this series. So, I think we should
> just document that WP is only intended for temporary mappings at boot-
> time until this issue is resolved. Also, we need to make sure that
> this early_memremap for WP is only called after pat_init() is done.
Sounds good, I'll add documentation to cover these points.
>
> A nit - please add WP to the function header comment below.
> "This function initializes PAT MSR and PAT table with an OS-defined
> value to enable additional cache attributes, WC and WT."
Will do.
Thanks,
Tom
>
> Thanks,
> -Toshi
>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* [PATCH] NFSv4.1: Don't allow a lock_state to be freed while checking
From: Benjamin Coddington @ 2016-11-14 16:50 UTC (permalink / raw)
To: Trond Myklebust, Anna Schumaker; +Cc: linux-nfs
While walking the list of lock_states, keep the current nfs4_lock_state
referenced so that it isn't freed while checking.
Signed-off-by: Benjamin Coddington <bcodding@redhat.com>
---
fs/nfs/nfs4proc.c | 12 +++++++++---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/fs/nfs/nfs4proc.c b/fs/nfs/nfs4proc.c
index 7897826d7c51..9a1cb9e8c4fc 100644
--- a/fs/nfs/nfs4proc.c
+++ b/fs/nfs/nfs4proc.c
@@ -2564,12 +2564,15 @@ static void nfs41_check_delegation_stateid(struct nfs4_state *state)
static int nfs41_check_expired_locks(struct nfs4_state *state)
{
int status, ret = NFS_OK;
- struct nfs4_lock_state *lsp;
+ struct nfs4_lock_state *lsp, *tmp;
struct nfs_server *server = NFS_SERVER(state->inode);
if (!test_bit(LK_STATE_IN_USE, &state->flags))
goto out;
- list_for_each_entry(lsp, &state->lock_states, ls_locks) {
+ spin_lock(&state->state_lock);
+ list_for_each_entry_safe(lsp, tmp, &state->lock_states, ls_locks) {
+ atomic_inc(&lsp->ls_count);
+ spin_unlock(&state->state_lock);
if (test_bit(NFS_LOCK_INITIALIZED, &lsp->ls_flags)) {
struct rpc_cred *cred = lsp->ls_state->owner->so_cred;
@@ -2588,7 +2591,10 @@ static int nfs41_check_expired_locks(struct nfs4_state *state)
break;
}
}
- };
+ nfs4_put_lock_state(lsp);
+ spin_lock(&state->state_lock);
+ }
+ spin_unlock(&state->state_lock);
out:
return ret;
}
--
2.5.5
^ permalink raw reply related
* [PATCH] NFSv4.1: Handle NFS4ERR_OLD_STATEID in nfs4_reclaim_open_state
From: Benjamin Coddington @ 2016-11-14 16:51 UTC (permalink / raw)
To: Trond Myklebust, Anna Schumaker; +Cc: linux-nfs
Now that we're doing TEST_STATEID in nfs4_reclaim_open_state(), we can have
a NFS4ERR_OLD_STATEID returned from nfs41_open_expired() . Instead of
marking state recovery as failed, mark the state for recovery again.
Signed-off-by: Benjamin Coddington <bcodding@redhat.com>
---
fs/nfs/nfs4state.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/fs/nfs/nfs4state.c b/fs/nfs/nfs4state.c
index 5f4281ec5f72..0959c9661662 100644
--- a/fs/nfs/nfs4state.c
+++ b/fs/nfs/nfs4state.c
@@ -1547,6 +1547,7 @@ static int nfs4_reclaim_open_state(struct nfs4_state_owner *sp, const struct nfs
ssleep(1);
case -NFS4ERR_ADMIN_REVOKED:
case -NFS4ERR_STALE_STATEID:
+ case -NFS4ERR_OLD_STATEID:
case -NFS4ERR_BAD_STATEID:
case -NFS4ERR_RECLAIM_BAD:
case -NFS4ERR_RECLAIM_CONFLICT:
--
2.5.5
^ permalink raw reply related
* Re: [WireGuard] [PATCH v3] ip6_output: ensure flow saddr actually belongs to device
From: David Ahern @ 2016-11-14 16:55 UTC (permalink / raw)
To: Hannes Frederic Sowa, Jason A. Donenfeld, Netdev,
WireGuard mailing list, LKML, YOSHIFUJI Hideaki
In-Reply-To: <1479141867.3723362.787321689.4A3DCFD6@webmail.messagingengine.com>
On 11/14/16 9:44 AM, Hannes Frederic Sowa wrote:
> On Mon, Nov 14, 2016, at 00:28, Jason A. Donenfeld wrote:
>> This puts the IPv6 routing functions in parity with the IPv4 routing
>> functions. Namely, we now check in v6 that if a flowi6 requests an
>> saddr, the returned dst actually corresponds to a net device that has
>> that saddr. This mirrors the v4 logic with __ip_dev_find in
>> __ip_route_output_key_hash. In the event that the returned dst is not
>> for a dst with a dev that has the saddr, we return -EINVAL, just like
>> v4; this makes it easy to use the same error handlers for both cases.
>>
>> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
>> Cc: David Ahern <dsa@cumulusnetworks.com>
>> ---
>> Changes from v2:
>> It turns out ipv6_chk_addr already has the device enumeration
>> logic that we need by simply passing NULL.
>>
>> net/ipv6/ip6_output.c | 4 ++++
>> 1 file changed, 4 insertions(+)
>>
>> diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
>> index 6001e78..b3b5cb6 100644
>> --- a/net/ipv6/ip6_output.c
>> +++ b/net/ipv6/ip6_output.c
>> @@ -926,6 +926,10 @@ static int ip6_dst_lookup_tail(struct net *net,
>> const struct sock *sk,
>> int err;
>> int flags = 0;
>>
>> + if (!ipv6_addr_any(&fl6->saddr) &&
>> + !ipv6_chk_addr(net, &fl6->saddr, NULL, 1))
>> + return -EINVAL;
>
> Hmm, this check is too permissive, no?
>
> E.g. what happens if you move a link local address from one interface to
> another? In this case this code would still allow the saddr to be used.
This check -- like the ipv4 variant -- only verifies the saddr is locally assigned. If the address moves interfaces it should be fine.
>
> I just also quickly read up on the history (sorry was travelling last
> week) and wonder if you ever saw a user space facing bug or if this is
> basically some difference you saw while writing out of tree code?
I checked the userspace API this morning. bind and cmsg for example check that the address is valid with calls to ipv6_chk_addr.
^ permalink raw reply
* Re: [PATCH 3/5] media: Add new SDR formats SC16, SC18 & SC20
From: Hans Verkuil @ 2016-11-14 16:52 UTC (permalink / raw)
To: Ramesh Shanmugasundaram, robh+dt@kernel.org, mark.rutland@arm.com,
mchehab@kernel.org, sakari.ailus@linux.intel.com, crope@iki.fi
Cc: Chris Paterson, laurent.pinchart@ideasonboard.com,
geert+renesas@glider.be, linux-media@vger.kernel.org,
devicetree@vger.kernel.org, linux-renesas-soc@vger.kernel.org
In-Reply-To: <SG2PR06MB1038A5C7419F6EDE6B880A1BC3BC0@SG2PR06MB1038.apcprd06.prod.outlook.com>
On 11/14/2016 05:20 PM, Ramesh Shanmugasundaram wrote:
> Hi Hans,
>
> Thanks for the review comments.
>
>> Subject: Re: [PATCH 3/5] media: Add new SDR formats SC16, SC18 & SC20
>>
>> On 11/09/2016 04:44 PM, Ramesh Shanmugasundaram wrote:
>>> This patch adds support for the three new SDR formats. These formats
>>> were prefixed with "sliced" indicating I data constitutes the top half
>>> and Q data constitutes the bottom half of the received buffer.
>>
>> The standard terminology for video formats is "planar". I am leaning
>> towards using that here as well.
>>
>> Any opinions on this?
>
> Shall I rename the formats as "PC16", "PC18" & "PC20"?
Sounds reasonable to me!
Hans
> For formats that do IQ IQ IQ... I shall use the regular formats "CUXX" when I introduce them.
>
> Thanks,
> Ramesh
>
>>
>> Hans
>>
>>>
>>> V4L2_SDR_FMT_SCU16BE - 14-bit complex (I & Q) unsigned big-endian
>>> sample inside 16-bit. V4L2 FourCC: SC16
>>>
>>> V4L2_SDR_FMT_SCU18BE - 16-bit complex (I & Q) unsigned big-endian
>>> sample inside 18-bit. V4L2 FourCC: SC18
>>>
>>> V4L2_SDR_FMT_SCU20BE - 18-bit complex (I & Q) unsigned big-endian
>>> sample inside 20-bit. V4L2 FourCC: SC20
>>>
>>> Signed-off-by: Ramesh Shanmugasundaram
>>> <ramesh.shanmugasundaram@bp.renesas.com>
>>> ---
>>> drivers/media/v4l2-core/v4l2-ioctl.c | 3 +++
>>> include/uapi/linux/videodev2.h | 3 +++
>>> 2 files changed, 6 insertions(+)
>>>
>>> diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c
>>> b/drivers/media/v4l2-core/v4l2-ioctl.c
>>> index 181381d..d36b386 100644
>>> --- a/drivers/media/v4l2-core/v4l2-ioctl.c
>>> +++ b/drivers/media/v4l2-core/v4l2-ioctl.c
>>> @@ -1207,6 +1207,9 @@ static void v4l_fill_fmtdesc(struct v4l2_fmtdesc
>> *fmt)
>>> case V4L2_SDR_FMT_CS8: descr = "Complex S8"; break;
>>> case V4L2_SDR_FMT_CS14LE: descr = "Complex S14LE"; break;
>>> case V4L2_SDR_FMT_RU12LE: descr = "Real U12LE"; break;
>>> + case V4L2_SDR_FMT_SCU16BE: descr = "Sliced Complex U16BE"; break;
>>> + case V4L2_SDR_FMT_SCU18BE: descr = "Sliced Complex U18BE"; break;
>>> + case V4L2_SDR_FMT_SCU20BE: descr = "Sliced Complex U20BE"; break;
>>> case V4L2_TCH_FMT_DELTA_TD16: descr = "16-bit signed deltas"; break;
>>> case V4L2_TCH_FMT_DELTA_TD08: descr = "8-bit signed deltas"; break;
>>> case V4L2_TCH_FMT_TU16: descr = "16-bit unsigned touch data";
>> break;
>>> diff --git a/include/uapi/linux/videodev2.h
>>> b/include/uapi/linux/videodev2.h index 4364ce6..34a9c30 100644
>>> --- a/include/uapi/linux/videodev2.h
>>> +++ b/include/uapi/linux/videodev2.h
>>> @@ -666,6 +666,9 @@ struct v4l2_pix_format {
>>> #define V4L2_SDR_FMT_CS8 v4l2_fourcc('C', 'S', '0', '8') /*
>> complex s8 */
>>> #define V4L2_SDR_FMT_CS14LE v4l2_fourcc('C', 'S', '1', '4') /*
>> complex s14le */
>>> #define V4L2_SDR_FMT_RU12LE v4l2_fourcc('R', 'U', '1', '2') /*
>> real u12le */
>>> +#define V4L2_SDR_FMT_SCU16BE v4l2_fourcc('S', 'C', '1', '6') /*
>> sliced complex u16be */
>>> +#define V4L2_SDR_FMT_SCU18BE v4l2_fourcc('S', 'C', '1', '8') /*
>> sliced complex u18be */
>>> +#define V4L2_SDR_FMT_SCU20BE v4l2_fourcc('S', 'C', '2', '0') /*
>> sliced complex u20be */
>>>
>>> /* Touch formats - used for Touch devices */
>>> #define V4L2_TCH_FMT_DELTA_TD16 v4l2_fourcc('T', 'D', '1', '6') /* 16-
>> bit signed deltas */
>>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [Qemu-devel] [RFC 0/3] aio: experimental virtio-blk polling mode
From: Stefan Hajnoczi @ 2016-11-14 16:52 UTC (permalink / raw)
To: Christian Borntraeger
Cc: Stefan Hajnoczi, qemu-devel, Paolo Bonzini, Fam Zheng,
Karl Rister
In-Reply-To: <e48652f5-73b0-ae12-38dc-0dd67ab3e02b@de.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 2168 bytes --]
On Mon, Nov 14, 2016 at 03:59:32PM +0100, Christian Borntraeger wrote:
> On 11/09/2016 06:13 PM, Stefan Hajnoczi wrote:
> > Recent performance investigation work done by Karl Rister shows that the
> > guest->host notification takes around 20 us. This is more than the "overhead"
> > of QEMU itself (e.g. block layer).
> >
> > One way to avoid the costly exit is to use polling instead of notification.
> > The main drawback of polling is that it consumes CPU resources. In order to
> > benefit performance the host must have extra CPU cycles available on physical
> > CPUs that aren't used by the guest.
> >
> > This is an experimental AioContext polling implementation. It adds a polling
> > callback into the event loop. Polling functions are implemented for virtio-blk
> > virtqueue guest->host kick and Linux AIO completion.
> >
> > The QEMU_AIO_POLL_MAX_NS environment variable sets the number of nanoseconds to
> > poll before entering the usual blocking poll(2) syscall. Try setting this
> > variable to the time from old request completion to new virtqueue kick.
> >
> > By default no polling is done. The QEMU_AIO_POLL_MAX_NS must be set to get any
> > polling!
> >
> > Karl: I hope you can try this patch series with several QEMU_AIO_POLL_MAX_NS
> > values. If you don't find a good value we should double-check the tracing data
> > to see if this experimental code can be improved.
> >
> > Stefan Hajnoczi (3):
> > aio-posix: add aio_set_poll_handler()
> > virtio: poll virtqueues for new buffers
> > linux-aio: poll ring for completions
> >
> > aio-posix.c | 133 ++++++++++++++++++++++++++++++++++++++++++++++++++++
> > block/linux-aio.c | 17 +++++++
> > hw/virtio/virtio.c | 19 ++++++++
> > include/block/aio.h | 16 +++++++
> > 4 files changed, 185 insertions(+)
> >
>
> Another observation: With more iothreads than host CPUs the performance drops significantly.
This makes sense although we can eliminate it in common cases by only
polling when we actually need to monitor events.
The current series wastes CPU on Linux AIO polling when no requests are
pending ;).
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
^ permalink raw reply
* Re: [Qemu-devel] [PATCH 0/3] add cleanup operation in handle/proxy backend
From: Greg Kurz @ 2016-11-14 16:53 UTC (permalink / raw)
To: Li Qiang; +Cc: qemu-devel, liqiang6-s
In-Reply-To: <5829af05.84f4420a.a436f.4a62@mx.google.com>
Hi Li,
On Mon, 14 Nov 2016 07:32:55 -0500
Li Qiang <liq3ea@gmail.com> wrote:
> From: Li Qiang <liq3ea@gmail.com>
>
> Currently, the backend of VirtFS doesn't have a cleanup
> function. This will leak some resources in handle and proxy
> backend driver. This patchset addresses this issue.
>
> Li Qiang (3):
> 9pfs: add cleanup operation in FileOperations
> 9pfs: add cleanup operation for handle backend driver
> 9pfs: add cleanup operation for proxy backend driver
>
> fsdev/file-op-9p.h | 1 +
> hw/9pfs/9p-handle.c | 8 ++++++++
> hw/9pfs/9p-proxy.c | 10 ++++++++++
> hw/9pfs/9p.c | 3 +++
> 4 files changed, 22 insertions(+)
>
The series ends up unthreaded again...
This is what we have in the cover (0/3):
Message-ID: <5829af05.84f4420a.a436f.4a62@mx.google.com>
X-Google-Original-Message-ID: <1479126778-125867-1-git-send-email-Qiang(liqiang6-s@360.cn)>
but the patches have:
In-Reply-To: <1479126778-125867-1-git-send-email-Qiang(liqiang6-s@360.cn)>
References: <1479126778-125867-1-git-send-email-Qiang(liqiang6-s@360.cn)>
A quick research seems to indicate that gmail rewrites message-id if it does
not follow the <user@domain> format, which is obviously the case here.
Please fix that before you post again.
Cheers.
--
Greg
^ permalink raw reply
* Re: [Qemu-devel] [RFC 0/3] aio: experimental virtio-blk polling mode
From: Stefan Hajnoczi @ 2016-11-14 16:53 UTC (permalink / raw)
To: Christian Borntraeger
Cc: Stefan Hajnoczi, qemu-devel, Paolo Bonzini, Fam Zheng,
Karl Rister
In-Reply-To: <1bca4a16-5a2c-8de7-b66d-a8ceb3e5a756@de.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 2438 bytes --]
On Mon, Nov 14, 2016 at 03:51:18PM +0100, Christian Borntraeger wrote:
> On 11/09/2016 06:13 PM, Stefan Hajnoczi wrote:
> > Recent performance investigation work done by Karl Rister shows that the
> > guest->host notification takes around 20 us. This is more than the "overhead"
> > of QEMU itself (e.g. block layer).
> >
> > One way to avoid the costly exit is to use polling instead of notification.
> > The main drawback of polling is that it consumes CPU resources. In order to
> > benefit performance the host must have extra CPU cycles available on physical
> > CPUs that aren't used by the guest.
> >
> > This is an experimental AioContext polling implementation. It adds a polling
> > callback into the event loop. Polling functions are implemented for virtio-blk
> > virtqueue guest->host kick and Linux AIO completion.
> >
> > The QEMU_AIO_POLL_MAX_NS environment variable sets the number of nanoseconds to
> > poll before entering the usual blocking poll(2) syscall. Try setting this
> > variable to the time from old request completion to new virtqueue kick.
> >
> > By default no polling is done. The QEMU_AIO_POLL_MAX_NS must be set to get any
> > polling!
> >
> > Karl: I hope you can try this patch series with several QEMU_AIO_POLL_MAX_NS
> > values. If you don't find a good value we should double-check the tracing data
> > to see if this experimental code can be improved.
> >
> > Stefan Hajnoczi (3):
> > aio-posix: add aio_set_poll_handler()
> > virtio: poll virtqueues for new buffers
> > linux-aio: poll ring for completions
> >
> > aio-posix.c | 133 ++++++++++++++++++++++++++++++++++++++++++++++++++++
> > block/linux-aio.c | 17 +++++++
> > hw/virtio/virtio.c | 19 ++++++++
> > include/block/aio.h | 16 +++++++
> > 4 files changed, 185 insertions(+)
>
> Hmm, I see all affected threads using more CPU power, but the performance numbers are
> somewhat inconclusive on s390. I have no proper test setup (only a shared LPAR), but
> all numbers are in the same ballpark of 3-5Gbyte/sec for 5 disks for 4k random reads
> with iodepth=8.
>
> What I find interesting is that the guest still does a huge amount of exits for the
> guest->host notifications. I think if we could combine this with some notification
> suppression, then things could be even more interesting.
Great idea. I'll add that to the next revision.
Stefan
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
^ permalink raw reply
* [PATCH 0/3] drm/i915: Per-plane rotation leftovers
From: ville.syrjala @ 2016-11-14 16:53 UTC (permalink / raw)
To: intel-gfx
From: Ville Syrjälä <ville.syrjala@linux.intel.com>
Just a repost of the remainder of my per-plane rotation series, just so
I get a proper CI run for them.
Ville Syrjälä (3):
drm/i915: Use & instead if == to check for rotations
drm/i915: Clean up rotation DSPCNTR/DVSCNTR/etc. setup
drm/i915: Add horizontal mirroring support for CHV pipe B planes
drivers/gpu/drm/i915/intel_atomic_plane.c | 9 +++++++
drivers/gpu/drm/i915/intel_display.c | 39 ++++++++++++++++++++-----------
drivers/gpu/drm/i915/intel_sprite.c | 39 ++++++++++++++++++++-----------
3 files changed, 59 insertions(+), 28 deletions(-)
--
2.7.4
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [PATCH v3] ip6_output: ensure flow saddr actually belongs to device
From: Jason A. Donenfeld @ 2016-11-14 16:54 UTC (permalink / raw)
To: David Ahern, David Miller
Cc: Netdev, Hannes Frederic Sowa, YOSHIFUJI Hideaki,
WireGuard mailing list, LKML
In-Reply-To: <CAHmME9qC4xqGOwJnauXrJBDkAtmmuJ+kJKL6ufuU9_XWKNFdSA@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 201 bytes --]
On Nov 14, 2016 17:19, "David Ahern" <dsa@cumulusnetworks.com> wrote:
>
> LGTM
>
> Acked-by: David Ahern <dsa@cumulusnetworks.com>
Great.
@DaveM: can we get this in 4.9 and in stable?
Thanks,
Jason
[-- Attachment #1.2: Type: text/html, Size: 410 bytes --]
[-- Attachment #2: Type: text/plain, Size: 147 bytes --]
_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/wireguard
^ permalink raw reply
* [PATCH 1/3] drm/i915: Use & instead if == to check for rotations
From: ville.syrjala @ 2016-11-14 16:53 UTC (permalink / raw)
To: intel-gfx
In-Reply-To: <1479142440-25283-1-git-send-email-ville.syrjala@linux.intel.com>
From: Ville Syrjälä <ville.syrjala@linux.intel.com>
Using == to check for 180 degree rotation only works as long as the
reflection bits aren't set. That will change soon enough for CHV, so
let's stop doing things the wrong way.
v2: Drop the BIT()
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1477077768-4274-5-git-send-email-ville.syrjala@linux.intel.com
---
drivers/gpu/drm/i915/intel_display.c | 8 ++++----
drivers/gpu/drm/i915/intel_sprite.c | 6 +++---
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index 072a0b1bc9da..16b6978662e8 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3078,7 +3078,7 @@ static void i9xx_update_primary_plane(struct drm_plane *primary,
intel_crtc->dspaddr_offset =
intel_compute_tile_offset(&x, &y, plane_state, 0);
- if (rotation == DRM_ROTATE_180) {
+ if (rotation & DRM_ROTATE_180) {
dspcntr |= DISPPLANE_ROTATE_180;
x += (crtc_state->pipe_src_w - 1);
@@ -3182,7 +3182,7 @@ static void ironlake_update_primary_plane(struct drm_plane *primary,
intel_crtc->dspaddr_offset =
intel_compute_tile_offset(&x, &y, plane_state, 0);
- if (rotation == DRM_ROTATE_180) {
+ if (rotation & DRM_ROTATE_180) {
dspcntr |= DISPPLANE_ROTATE_180;
if (!IS_HASWELL(dev_priv) && !IS_BROADWELL(dev_priv)) {
@@ -10875,7 +10875,7 @@ static void i9xx_update_cursor(struct drm_crtc *crtc, u32 base,
if (HAS_DDI(dev_priv))
cntl |= CURSOR_PIPE_CSC_ENABLE;
- if (plane_state->base.rotation == DRM_ROTATE_180)
+ if (plane_state->base.rotation & DRM_ROTATE_180)
cntl |= CURSOR_ROTATE_180;
}
@@ -10921,7 +10921,7 @@ static void intel_crtc_update_cursor(struct drm_crtc *crtc,
/* ILK+ do this automagically */
if (HAS_GMCH_DISPLAY(dev_priv) &&
- plane_state->base.rotation == DRM_ROTATE_180) {
+ plane_state->base.rotation & DRM_ROTATE_180) {
base += (plane_state->base.crtc_h *
plane_state->base.crtc_w - 1) * 4;
}
diff --git a/drivers/gpu/drm/i915/intel_sprite.c b/drivers/gpu/drm/i915/intel_sprite.c
index 04af4393db5c..37ff13b838ce 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -436,7 +436,7 @@ vlv_update_plane(struct drm_plane *dplane,
intel_add_fb_offsets(&x, &y, plane_state, 0);
sprsurf_offset = intel_compute_tile_offset(&x, &y, plane_state, 0);
- if (rotation == DRM_ROTATE_180) {
+ if (rotation & DRM_ROTATE_180) {
sprctl |= SP_ROTATE_180;
x += src_w;
@@ -566,7 +566,7 @@ ivb_update_plane(struct drm_plane *plane,
intel_add_fb_offsets(&x, &y, plane_state, 0);
sprsurf_offset = intel_compute_tile_offset(&x, &y, plane_state, 0);
- if (rotation == DRM_ROTATE_180) {
+ if (rotation & DRM_ROTATE_180) {
sprctl |= SPRITE_ROTATE_180;
/* HSW and BDW does this automagically in hardware */
@@ -700,7 +700,7 @@ ilk_update_plane(struct drm_plane *plane,
intel_add_fb_offsets(&x, &y, plane_state, 0);
dvssurf_offset = intel_compute_tile_offset(&x, &y, plane_state, 0);
- if (rotation == DRM_ROTATE_180) {
+ if (rotation & DRM_ROTATE_180) {
dvscntr |= DVS_ROTATE_180;
x += src_w;
--
2.7.4
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related
* [PATCH 3/3] drm/i915: Add horizontal mirroring support for CHV pipe B planes
From: ville.syrjala @ 2016-11-14 16:54 UTC (permalink / raw)
To: intel-gfx
In-Reply-To: <1479142440-25283-1-git-send-email-ville.syrjala@linux.intel.com>
From: Ville Syrjälä <ville.syrjala@linux.intel.com>
The primary and sprite planes on CHV pipe B support horizontal
mirroring. Expose it to the world.
Sadly the hardware ignores the mirror bit when the rotate bit is
set, so we'll have to reject the 180+X case.
v2: Drop the BIT()
v3: Pass dev_priv instead of dev to IS_CHERRYVIEW()
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1477077768-4274-7-git-send-email-ville.syrjala@linux.intel.com
---
drivers/gpu/drm/i915/intel_atomic_plane.c | 9 +++++++++
drivers/gpu/drm/i915/intel_display.c | 9 +++++++++
drivers/gpu/drm/i915/intel_sprite.c | 9 +++++++++
3 files changed, 27 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c b/drivers/gpu/drm/i915/intel_atomic_plane.c
index 984a6b75c118..ff821649486e 100644
--- a/drivers/gpu/drm/i915/intel_atomic_plane.c
+++ b/drivers/gpu/drm/i915/intel_atomic_plane.c
@@ -106,6 +106,7 @@ intel_plane_destroy_state(struct drm_plane *plane,
static int intel_plane_atomic_check(struct drm_plane *plane,
struct drm_plane_state *state)
{
+ struct drm_i915_private *dev_priv = to_i915(plane->dev);
struct drm_crtc *crtc = state->crtc;
struct intel_crtc *intel_crtc;
struct intel_crtc_state *crtc_state;
@@ -167,6 +168,14 @@ static int intel_plane_atomic_check(struct drm_plane *plane,
}
}
+ /* CHV ignores the mirror bit when the rotate bit is set :( */
+ if (IS_CHERRYVIEW(dev_priv) &&
+ state->rotation & DRM_ROTATE_180 &&
+ state->rotation & DRM_REFLECT_X) {
+ DRM_DEBUG_KMS("Cannot rotate and reflect at the same time\n");
+ return -EINVAL;
+ }
+
intel_state->base.visible = false;
ret = intel_plane->check_plane(plane, crtc_state, intel_state);
if (ret)
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index f16766e27b17..666a0937fed3 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3072,6 +3072,9 @@ static void i9xx_update_primary_plane(struct drm_plane *primary,
if (rotation & DRM_ROTATE_180)
dspcntr |= DISPPLANE_ROTATE_180;
+ if (rotation & DRM_REFLECT_X)
+ dspcntr |= DISPPLANE_MIRROR;
+
if (IS_G4X(dev_priv))
dspcntr |= DISPPLANE_TRICKLE_FEED_DISABLE;
@@ -3084,6 +3087,8 @@ static void i9xx_update_primary_plane(struct drm_plane *primary,
if (rotation & DRM_ROTATE_180) {
x += crtc_state->pipe_src_w - 1;
y += crtc_state->pipe_src_h - 1;
+ } else if (rotation & DRM_REFLECT_X) {
+ x += crtc_state->pipe_src_w - 1;
}
linear_offset = intel_fb_xy_to_linear(x, y, plane_state, 0);
@@ -15056,6 +15061,10 @@ intel_primary_plane_create(struct drm_i915_private *dev_priv, enum pipe pipe)
supported_rotations =
DRM_ROTATE_0 | DRM_ROTATE_90 |
DRM_ROTATE_180 | DRM_ROTATE_270;
+ } else if (IS_CHERRYVIEW(dev_priv) && pipe == PIPE_B) {
+ supported_rotations =
+ DRM_ROTATE_0 | DRM_ROTATE_180 |
+ DRM_REFLECT_X;
} else if (INTEL_GEN(dev_priv) >= 4) {
supported_rotations =
DRM_ROTATE_0 | DRM_ROTATE_180;
diff --git a/drivers/gpu/drm/i915/intel_sprite.c b/drivers/gpu/drm/i915/intel_sprite.c
index ad878ea61640..8b2fc67acbba 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -430,6 +430,9 @@ vlv_update_plane(struct drm_plane *dplane,
if (rotation & DRM_ROTATE_180)
sprctl |= SP_ROTATE_180;
+ if (rotation & DRM_REFLECT_X)
+ sprctl |= SP_MIRROR;
+
/* Sizes are 0 based */
src_w--;
src_h--;
@@ -442,6 +445,8 @@ vlv_update_plane(struct drm_plane *dplane,
if (rotation & DRM_ROTATE_180) {
x += src_w;
y += src_h;
+ } else if (rotation & DRM_REFLECT_X) {
+ x += src_w;
}
linear_offset = intel_fb_xy_to_linear(x, y, plane_state, 0);
@@ -1114,6 +1119,10 @@ intel_sprite_plane_create(struct drm_i915_private *dev_priv,
supported_rotations =
DRM_ROTATE_0 | DRM_ROTATE_90 |
DRM_ROTATE_180 | DRM_ROTATE_270;
+ } else if (IS_CHERRYVIEW(dev_priv) && pipe == PIPE_B) {
+ supported_rotations =
+ DRM_ROTATE_0 | DRM_ROTATE_180 |
+ DRM_REFLECT_X;
} else {
supported_rotations =
DRM_ROTATE_0 | DRM_ROTATE_180;
--
2.7.4
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related
* [PATCH v2 0/3] drm/tilcdc: Add bridge support and sync-lost flood recovery
From: Jyri Sarha @ 2016-11-14 16:54 UTC (permalink / raw)
To: dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: airlied-cv59FeDIM0c, daniel-/w4YWyX8dFk,
tomi.valkeinen-l0cyMroinI0,
laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw,
robdclark-Re5JQEeQqe8AvxtiuMwx3w,
bgolaszewski-rdvid1DuHRBWk0Htik3J/w,
khilman-rdvid1DuHRBWk0Htik3J/w, bcousson-rdvid1DuHRBWk0Htik3J/w,
Jyri Sarha
Changes since first version of the series:
- "drm/tilcdc: Recover from sync lost error flood by resetting the LCDC"
- no change
- "drm/bridge: Add ti-tfp410 DVI transmitter driver"
- HDMI -> DVI
- DT Binding document
- Prepare for tfp410 connected trough i2c by optional reg property
- Require two port nodes
- Implementation
- Implement connector node functionality with in tfp410 bridge
drive, but follow generic connector binding by pulling the
ddc-i2c-bus property from the connector node.
- "drm/tilcdc: Add drm bridge support for attaching drm bridge drivers"
- Remove earlier change in TD binding document. There is no need to
mention DRM implementation details, like bridge support, in DT
binding.
The first patch is an independent on and I've been testing it for
quite a while now.
The tfp410 bridge driver and the tilcdc bridge support are tested with
BeagleBone DVI-D Cape Rev A3. The tfp410 bridge driver is missing a
lot of features, because the DVI-D cape does not have too many wires
connected. The missing features can be added later when they are
needed.
Jyri Sarha (3):
drm/tilcdc: Recover from sync lost error flood by resetting the LCDC
drm/bridge: Add ti-tfp410 DVI transmitter driver
drm/tilcdc: Add drm bridge support for attaching drm bridge drivers
.../bindings/display/bridge/ti,tfp410.txt | 41 ++++
drivers/gpu/drm/bridge/Kconfig | 7 +
drivers/gpu/drm/bridge/Makefile | 1 +
drivers/gpu/drm/bridge/ti-tfp410.c | 223 +++++++++++++++++++++
drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 26 ++-
drivers/gpu/drm/tilcdc/tilcdc_drv.c | 7 +-
drivers/gpu/drm/tilcdc/tilcdc_drv.h | 2 +
drivers/gpu/drm/tilcdc/tilcdc_external.c | 140 +++++++++++--
drivers/gpu/drm/tilcdc/tilcdc_external.h | 1 +
9 files changed, 428 insertions(+), 20 deletions(-)
create mode 100644 Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt
create mode 100644 drivers/gpu/drm/bridge/ti-tfp410.c
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v2 1/3] drm/tilcdc: Recover from sync lost error flood by resetting the LCDC
From: Jyri Sarha @ 2016-11-14 16:54 UTC (permalink / raw)
To: dri-devel, devicetree
Cc: bcousson, khilman, Jyri Sarha, bgolaszewski, tomi.valkeinen,
laurent.pinchart
In-Reply-To: <cover.1479142062.git.jsarha@ti.com>
Recover from sync lost error flood by resetting the LCDC instead of
turning off the SYNC_LOST error IRQ. When LCDC starves on limited
memory bandwidth it may sometimes result an error situation when the
picture may have shifted couple of pixels to right and SYNC_LOST
interrupt is generated on every frame. LCDC main reset recovers from
this situation and causes a brief blanking on the screen.
Signed-off-by: Jyri Sarha <jsarha@ti.com>
---
drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 26 +++++++++++++++++++++++++-
1 file changed, 25 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
index 0d09acc..c787349 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
@@ -55,6 +55,7 @@ struct tilcdc_crtc {
int sync_lost_count;
bool frame_intact;
+ struct work_struct recover_work;
};
#define to_tilcdc_crtc(x) container_of(x, struct tilcdc_crtc, base)
@@ -252,6 +253,25 @@ static bool tilcdc_crtc_is_on(struct drm_crtc *crtc)
return crtc->state && crtc->state->enable && crtc->state->active;
}
+static void tilcdc_crtc_recover_work(struct work_struct *work)
+{
+ struct tilcdc_crtc *tilcdc_crtc =
+ container_of(work, struct tilcdc_crtc, recover_work);
+ struct drm_crtc *crtc = &tilcdc_crtc->base;
+
+ dev_info(crtc->dev->dev, "%s: Reset CRTC", __func__);
+
+ drm_modeset_lock_crtc(crtc, NULL);
+
+ if (!tilcdc_crtc_is_on(crtc))
+ goto out;
+
+ tilcdc_crtc_disable(crtc);
+ tilcdc_crtc_enable(crtc);
+out:
+ drm_modeset_unlock_crtc(crtc);
+}
+
static void tilcdc_crtc_destroy(struct drm_crtc *crtc)
{
struct tilcdc_crtc *tilcdc_crtc = to_tilcdc_crtc(crtc);
@@ -838,9 +858,12 @@ irqreturn_t tilcdc_crtc_irq(struct drm_crtc *crtc)
tilcdc_crtc->frame_intact = false;
if (tilcdc_crtc->sync_lost_count++ >
SYNC_LOST_COUNT_LIMIT) {
- dev_err(dev->dev, "%s(0x%08x): Sync lost flood detected, disabling the interrupt", __func__, stat);
+ dev_err(dev->dev, "%s(0x%08x): Sync lost flood detected, recovering", __func__, stat);
+ queue_work(system_wq,
+ &tilcdc_crtc->recover_work);
tilcdc_write(dev, LCDC_INT_ENABLE_CLR_REG,
LCDC_SYNC_LOST);
+ tilcdc_crtc->sync_lost_count = 0;
}
}
@@ -880,6 +903,7 @@ struct drm_crtc *tilcdc_crtc_create(struct drm_device *dev)
"unref", unref_worker);
spin_lock_init(&tilcdc_crtc->irq_lock);
+ INIT_WORK(&tilcdc_crtc->recover_work, tilcdc_crtc_recover_work);
ret = drm_crtc_init_with_planes(dev, crtc,
&tilcdc_crtc->primary,
--
1.9.1
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related
* Re: [PATCH] x86: re-add stack alignment check
From: Jan Beulich @ 2016-11-14 16:54 UTC (permalink / raw)
To: Andrew Cooper; +Cc: xen-devel, Wei Liu
In-Reply-To: <a919ce76-a53b-bdfe-e02a-2bf5f709e36e@citrix.com>
>>> On 14.11.16 at 17:38, <andrew.cooper3@citrix.com> wrote:
> On 14/11/16 15:02, Jan Beulich wrote:
>>>>> On 14.11.16 at 15:38, <andrew.cooper3@citrix.com> wrote:
>>> On 14/11/16 14:24, Jan Beulich wrote:
>>>>>>> On 14.11.16 at 14:45, <andrew.cooper3@citrix.com> wrote:
>>>>> On 14/11/16 13:25, Jan Beulich wrote:
>>>>>> --- a/xen/arch/x86/cpu/common.c
>>>>>> +++ b/xen/arch/x86/cpu/common.c
>>>>>> @@ -643,6 +643,11 @@ void load_system_tables(void)
>>>>>> .limit = (IDT_ENTRIES * sizeof(idt_entry_t)) - 1,
>>>>>> };
>>>>>>
>>>>>> + /* Bottom-of-stack must be 16-byte aligned! */
>>>>>> + BUILD_BUG_ON((sizeof(struct cpu_info) -
>>>>>> + offsetof(struct cpu_info, guest_cpu_user_regs.es)) & 0xf);
>>>>>> + BUG_ON(system_state != SYS_STATE_early_boot && (stack_bottom & 0xf));
>>>>> This will still triple fault the system if it triggers on an AP.
>>>>> Exceptions aren't hooked up yet.
>>>> Hmm, true. They could be moved to the very end of the function
>>>> though?
>>> That would avoid the triple fault, but doesn't make the BUG_ON() useful.
>> And that's because? (I'm sorry if I'm overlooking the obvious.)
>>
>>>>> The reason I dropped the check was that there was no way it was going to
>>>>> fail on the BSP (because of the alignment of cpu0_stack) or APs (because
>>>>> of the alloc_xenheap_pages(STACK_ORDER, memflags) allocation).
>>>> These being page aligned has nothing to do with the BUG_ON()
>>>> triggering. I found its dropping being questionable in the context of
>>>> the old discussion rooted at this patch of mine
>>>> https://lists.xenproject.org/archives/html/xen-devel/2010-07/msg00642.html
>>>> I'd like to particularly point you to the various dependencies which
>>>> weren't properly spelled out or enforced back then. Specifically
>>>> it (not) triggering depends on the number and type of fields in
>>>> struct cpu_info following the guest_cpu_user_regs field.
>>> get_stack_bottom() takes the stack pointer, or's it up to the 8-page
>>> boundary, overlays a struct cpu_info, then returns the address of es.
>>>
>>> There is no value of %rsp which will ever cause it to fail. The only
>>> think which will cause a failure is the layout of struct cpu_info, but
>>> the BUILD_BUG_ON() will catch that.
>> Yes. Otherwise a BUILD_BUG_ON() wouldn't work in the first place.
>> But please also take into consideration my other reply: Moving the
>> BUILD_BUG_ON() into get_stack_bottom() is inappropriate, and
>> having it here without the BUG_ON() risks someone updating code
>> elsewhere such that the BUILD_BUG_ON() wouldn't trigger, but the
>> BUG_ON() would. That could be avoided only if we could make the
>> expression handed to BUILD_BUG_ON() use get_stack_bottom().
>
> What problems are we actually trying to detect here?
>
> Irrespective of what actually gets written into tss.rsp0, hardware will
> align the stack on entry.
And that's the problem: Everything will break in that case (being off
by 8 bytes). I recall from the time when I did put together the old
patch I did point you to. If you want to try out, just add a single
8-byte field to struct cpu_info and try booting the resulting
hypervisor. IOW the checks being added are to verify the comment
in the struct cpu_info declaration.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply
* [PATCH v2 2/3] drm/bridge: Add ti-tfp410 DVI transmitter driver
From: Jyri Sarha @ 2016-11-14 16:54 UTC (permalink / raw)
To: dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: airlied-cv59FeDIM0c, daniel-/w4YWyX8dFk,
tomi.valkeinen-l0cyMroinI0,
laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw,
robdclark-Re5JQEeQqe8AvxtiuMwx3w,
bgolaszewski-rdvid1DuHRBWk0Htik3J/w,
khilman-rdvid1DuHRBWk0Htik3J/w, bcousson-rdvid1DuHRBWk0Htik3J/w,
Jyri Sarha
In-Reply-To: <cover.1479142062.git.jsarha-l0cyMroinI0@public.gmane.org>
Add very basic ti-ftp410 DVI transmitter driver. The only feature
separating this from a completely dummy bridge is the EDID read
support trough DDC I2C. Even that functionality should be in a
separate generic connector driver. However, because of missing DRM
infrastructure support the connector is implemented within the bridge
driver. Some tfp410 HW specific features may be added later if needed,
because there is a set of registers behind i2c if it is connected.
This implementations is tested against my new tilcdc bridge support
and it works with BeagleBone DVI-D Cape Rev A3. A DT binding document
is also added.
Signed-off-by: Jyri Sarha <jsarha-l0cyMroinI0@public.gmane.org>
---
.../bindings/display/bridge/ti,tfp410.txt | 41 ++++
drivers/gpu/drm/bridge/Kconfig | 7 +
drivers/gpu/drm/bridge/Makefile | 1 +
drivers/gpu/drm/bridge/ti-tfp410.c | 223 +++++++++++++++++++++
4 files changed, 272 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt
create mode 100644 drivers/gpu/drm/bridge/ti-tfp410.c
diff --git a/Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt b/Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt
new file mode 100644
index 0000000..7446b2b
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt
@@ -0,0 +1,41 @@
+TFP410 DVI bridge bindings
+
+Required properties:
+ - compatible: "ti,tfp410"
+
+Optional properties
+ - reg: I2C address. If and only if present the driver node
+ should be placed into the i2c controller node where the
+ tfp410 i2c is connected to (the current implementation does
+ not yet support this).
+
+Required subnodes:
+ - port@0: Video input port node to connect the bridge to a
+ display controller output [1].
+ - port@1: Video output port node to connect the bridge to a
+ connector input [1].
+
+[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
+
+Example:
+ hdmi-bridge {
+ compatible = "ti,tfp410";
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ bridge_in: endpoint {
+ remote-endpoint = <&dc_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ bridge_out: endpoint {
+ remote-endpoint = <&hdmi_in>;
+ };
+ };
+ };
+ };
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index bd6acc8..a424e03 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -81,6 +81,13 @@ config DRM_TOSHIBA_TC358767
---help---
Toshiba TC358767 eDP bridge chip driver.
+config DRM_TI_TFP410
+ tristate "TI TFP410 DVI/HDMI bridge"
+ depends on OF
+ select DRM_KMS_HELPER
+ ---help---
+ Texas Instruments TFP410 DVI/HDMI Transmitter driver
+
source "drivers/gpu/drm/bridge/analogix/Kconfig"
source "drivers/gpu/drm/bridge/adv7511/Kconfig"
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index 97ed1a5..8b065d9 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -11,3 +11,4 @@ obj-$(CONFIG_DRM_SII902X) += sii902x.o
obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o
obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/
+obj-$(CONFIG_DRM_TI_TFP410) += ti-tfp410.o
diff --git a/drivers/gpu/drm/bridge/ti-tfp410.c b/drivers/gpu/drm/bridge/ti-tfp410.c
new file mode 100644
index 0000000..a806cd6
--- /dev/null
+++ b/drivers/gpu/drm/bridge/ti-tfp410.c
@@ -0,0 +1,223 @@
+/*
+ * Copyright (C) 2016 Texas Instruments
+ * Author: Jyri Sarha <jsarha-l0cyMroinI0@public.gmane.org>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ */
+
+#include <linux/module.h>
+#include <linux/of_graph.h>
+
+#include <drm/drmP.h>
+#include <drm/drm_atomic_helper.h>
+#include <drm/drm_crtc.h>
+#include <drm/drm_crtc_helper.h>
+
+struct tfp410 {
+ struct drm_bridge bridge;
+ struct drm_connector connector;
+
+ struct i2c_adapter *ddc;
+
+ struct device *dev;
+};
+
+static inline struct tfp410 *
+drm_bridge_to_tfp410(struct drm_bridge *bridge)
+{
+ return container_of(bridge, struct tfp410, bridge);
+}
+
+static inline struct tfp410 *
+drm_connector_to_tfp410(struct drm_connector *connector)
+{
+ return container_of(connector, struct tfp410, connector);
+}
+
+static int tfp410_get_modes(struct drm_connector *connector)
+{
+ struct tfp410 *dvi = drm_connector_to_tfp410(connector);
+ struct edid *edid;
+ int ret;
+
+ if (!dvi->ddc)
+ goto fallback;
+
+ edid = drm_get_edid(connector, dvi->ddc);
+ if (!edid) {
+ DRM_INFO("EDID read failed. Fallback to standard modes\n");
+ goto fallback;
+ }
+
+ drm_mode_connector_update_edid_property(connector, edid);
+
+ return drm_add_edid_modes(connector, edid);
+fallback:
+ /* No EDID, fallback on the XGA standard modes */
+ ret = drm_add_modes_noedid(connector, 1920, 1200);
+
+ /* And prefer a mode pretty much anything can handle */
+ drm_set_preferred_mode(connector, 1024, 768);
+
+ return ret;
+}
+
+static const struct drm_connector_helper_funcs tfp410_con_helper_funcs = {
+ .get_modes = tfp410_get_modes,
+};
+
+static enum drm_connector_status
+tfp410_connector_detect(struct drm_connector *connector, bool force)
+{
+ struct tfp410 *dvi = drm_connector_to_tfp410(connector);
+
+ if (dvi->ddc) {
+ if (drm_probe_ddc(dvi->ddc))
+ return connector_status_connected;
+ else
+ return connector_status_disconnected;
+ }
+
+ return connector_status_unknown;
+}
+
+static const struct drm_connector_funcs tfp410_con_funcs = {
+ .dpms = drm_atomic_helper_connector_dpms,
+ .detect = tfp410_connector_detect,
+ .fill_modes = drm_helper_probe_single_connector_modes,
+ .destroy = drm_connector_cleanup,
+ .reset = drm_atomic_helper_connector_reset,
+ .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
+ .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
+};
+
+static int tfp410_attach(struct drm_bridge *bridge)
+{
+ struct tfp410 *dvi = drm_bridge_to_tfp410(bridge);
+ int ret;
+
+ if (!bridge->encoder) {
+ dev_err(dvi->dev, "Missing encoder\n");
+ return -ENODEV;
+ }
+
+ drm_connector_helper_add(&dvi->connector,
+ &tfp410_con_helper_funcs);
+ ret = drm_connector_init(bridge->dev, &dvi->connector,
+ &tfp410_con_funcs, DRM_MODE_CONNECTOR_HDMIA);
+ if (ret) {
+ dev_err(dvi->dev, "drm_connector_init() failed: %d\n", ret);
+ return ret;
+ }
+
+ drm_mode_connector_attach_encoder(&dvi->connector,
+ bridge->encoder);
+
+ return 0;
+}
+
+static const struct drm_bridge_funcs tfp410_bridge_funcs = {
+ .attach = tfp410_attach,
+};
+
+static int tfp410_get_connector_ddc(struct tfp410 *dvi)
+{
+ struct device_node *ep = NULL, *connector_node = NULL;
+ struct device_node *ddc_phandle = NULL;
+ int ret = 0;
+
+ /* port@1 is the connector node */
+ ep = of_graph_get_endpoint_by_regs(dvi->dev->of_node, 1, -1);
+ if (!ep)
+ goto fail;
+
+ connector_node = of_graph_get_remote_port_parent(ep);
+ if (!connector_node)
+ goto fail;
+
+ ddc_phandle = of_parse_phandle(connector_node, "ddc-i2c-bus", 0);
+ if (!ddc_phandle)
+ goto fail;
+
+ dvi->ddc = of_get_i2c_adapter_by_node(ddc_phandle);
+ if (dvi->ddc)
+ dev_info(dvi->dev, "Connector's ddc i2c bus found\n");
+ else
+ ret = -EPROBE_DEFER;
+
+fail:
+ of_node_put(ep);
+ of_node_put(connector_node);
+ of_node_put(ddc_phandle);
+ return ret;
+}
+
+static int tfp410_probe(struct platform_device *pdev)
+{
+ struct tfp410 *dvi;
+ int ret;
+
+ if (!pdev->dev.of_node) {
+ dev_err(&pdev->dev, "device-tree data is missing\n");
+ return -ENXIO;
+ }
+
+ dvi = devm_kzalloc(&pdev->dev, sizeof(*dvi), GFP_KERNEL);
+ if (!dvi)
+ return -ENOMEM;
+ platform_set_drvdata(pdev, dvi);
+
+ dvi->bridge.funcs = &tfp410_bridge_funcs;
+ dvi->bridge.of_node = pdev->dev.of_node;
+ dvi->dev = &pdev->dev;
+
+ ret = tfp410_get_connector_ddc(dvi);
+ if (ret)
+ goto fail;
+
+ ret = drm_bridge_add(&dvi->bridge);
+ if (ret) {
+ dev_err(&pdev->dev, "drm_bridge_add() failed: %d\n", ret);
+ goto fail;
+ }
+
+ return 0;
+fail:
+ i2c_put_adapter(dvi->ddc);
+ return ret;
+}
+
+static int tfp410_remove(struct platform_device *pdev)
+{
+ struct tfp410 *dvi = platform_get_drvdata(pdev);
+
+ drm_bridge_remove(&dvi->bridge);
+
+ if (dvi->ddc)
+ i2c_put_adapter(dvi->ddc);
+
+ return 0;
+}
+
+static const struct of_device_id tfp410_match[] = {
+ { .compatible = "ti,tfp410" },
+ {},
+};
+MODULE_DEVICE_TABLE(of, tfp410_match);
+
+struct platform_driver tfp410_driver = {
+ .probe = tfp410_probe,
+ .remove = tfp410_remove,
+ .driver = {
+ .name = "tfp410-bridge",
+ .of_match_table = tfp410_match,
+ },
+};
+module_platform_driver(tfp410_driver);
+
+MODULE_AUTHOR("Jyri Sarha <jsarha-l0cyMroinI0@public.gmane.org>");
+MODULE_DESCRIPTION("TI TFP410 DVI bridge driver");
+MODULE_LICENSE("GPL");
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v2 3/3] drm/tilcdc: Add drm bridge support for attaching drm bridge drivers
From: Jyri Sarha @ 2016-11-14 16:54 UTC (permalink / raw)
To: dri-devel, devicetree
Cc: bcousson, khilman, Jyri Sarha, bgolaszewski, tomi.valkeinen,
laurent.pinchart
In-Reply-To: <cover.1479142062.git.jsarha@ti.com>
Adds drm bride support for attaching drm bridge drivers to tilcdc. The
decision whether a video port leads to an external encoder or bridge
is made simply based on remote device's compatible string. The code
has been tested with BeagleBone-Black with and without BeagleBone
DVI-D Cape Rev A3 using ti-tfp410 driver.
Signed-off-by: Jyri Sarha <jsarha@ti.com>
---
drivers/gpu/drm/tilcdc/tilcdc_drv.c | 7 +-
drivers/gpu/drm/tilcdc/tilcdc_drv.h | 2 +
drivers/gpu/drm/tilcdc/tilcdc_external.c | 140 +++++++++++++++++++++++++++----
drivers/gpu/drm/tilcdc/tilcdc_external.h | 1 +
4 files changed, 131 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
index dcc9621..ec22576 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
@@ -384,9 +384,14 @@ static int tilcdc_init(struct drm_driver *ddrv, struct device *dev)
ret = tilcdc_add_external_encoders(ddev);
if (ret < 0)
goto init_failed;
+ } else {
+ ret = tilcdc_attach_remote_device(ddev);
+ if (ret)
+ goto init_failed;
}
- if ((priv->num_encoders == 0) || (priv->num_connectors == 0)) {
+ if (!priv->remote_encoder &&
+ ((priv->num_encoders == 0) || (priv->num_connectors == 0))) {
dev_err(dev, "no encoders/connectors found\n");
ret = -ENXIO;
goto init_failed;
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.h b/drivers/gpu/drm/tilcdc/tilcdc_drv.h
index d31fe5d..283ff28 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_drv.h
+++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.h
@@ -90,6 +90,8 @@ struct tilcdc_drm_private {
struct drm_connector *connectors[8];
const struct drm_connector_helper_funcs *connector_funcs[8];
+ struct drm_encoder *remote_encoder;
+
bool is_registered;
bool is_componentized;
};
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_external.c b/drivers/gpu/drm/tilcdc/tilcdc_external.c
index 06a4c58..e1576ba 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_external.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_external.c
@@ -28,6 +28,18 @@
.raster_order = 0,
};
+static const struct tilcdc_panel_info panel_info_default = {
+ .ac_bias = 255,
+ .ac_bias_intrpt = 0,
+ .dma_burst_sz = 16,
+ .bpp = 16,
+ .fdd = 0x80,
+ .tft_alt_mode = 0,
+ .sync_edge = 0,
+ .sync_ctrl = 1,
+ .raster_order = 0,
+};
+
static int tilcdc_external_mode_valid(struct drm_connector *connector,
struct drm_display_mode *mode)
{
@@ -130,6 +142,101 @@ void tilcdc_remove_external_encoders(struct drm_device *dev)
priv->connector_funcs[i]);
}
+static const struct drm_encoder_funcs tilcdc_remote_encoder_funcs = {
+ .destroy = drm_encoder_cleanup,
+};
+
+static
+int tilcdc_attach_bridge(struct drm_device *ddev, struct drm_bridge *bridge)
+{
+ struct tilcdc_drm_private *priv = ddev->dev_private;
+ int ret;
+
+ priv->remote_encoder->possible_crtcs = BIT(0);
+ priv->remote_encoder->bridge = bridge;
+ bridge->encoder = priv->remote_encoder;
+
+ ret = drm_bridge_attach(ddev, bridge);
+ if (ret) {
+ dev_err(ddev->dev, "drm_bridge_attach() failed %d\n", ret);
+ return ret;
+ }
+
+ tilcdc_crtc_set_panel_info(priv->crtc, &panel_info_default);
+
+ return 0;
+}
+
+static int tilcdc_node_has_port(struct device_node *dev_node)
+{
+ struct device_node *node;
+
+ node = of_get_child_by_name(dev_node, "ports");
+ if (!node)
+ node = of_get_child_by_name(dev_node, "port");
+ if (!node)
+ return 0;
+ of_node_put(node);
+
+ return 1;
+}
+
+static
+struct device_node *tilcdc_get_remote_node(struct device_node *node)
+{
+ struct device_node *ep;
+ struct device_node *parent;
+
+ if (!tilcdc_node_has_port(node))
+ return NULL;
+
+ ep = of_graph_get_next_endpoint(node, NULL);
+ if (!ep)
+ return NULL;
+
+ parent = of_graph_get_remote_port_parent(ep);
+ of_node_put(ep);
+
+ return parent;
+}
+
+int tilcdc_attach_remote_device(struct drm_device *ddev)
+{
+ struct tilcdc_drm_private *priv = ddev->dev_private;
+ struct device_node *remote_node;
+ struct drm_bridge *bridge;
+ int ret;
+
+ remote_node = tilcdc_get_remote_node(ddev->dev->of_node);
+ if (!remote_node)
+ return 0;
+
+ bridge = of_drm_find_bridge(remote_node);
+ of_node_put(remote_node);
+ if (!bridge)
+ return -EPROBE_DEFER;
+
+ priv->remote_encoder = devm_kzalloc(ddev->dev,
+ sizeof(*priv->remote_encoder),
+ GFP_KERNEL);
+ if (!priv->remote_encoder)
+ return -ENOMEM;
+
+ ret = drm_encoder_init(ddev, priv->remote_encoder,
+ &tilcdc_remote_encoder_funcs,
+ DRM_MODE_ENCODER_NONE, NULL);
+ if (ret) {
+ dev_err(ddev->dev, "drm_encoder_init() failed %d\n", ret);
+ return ret;
+ }
+
+ ret = tilcdc_attach_bridge(ddev, bridge);
+ if (ret)
+ drm_encoder_cleanup(priv->remote_encoder);
+
+ return ret;
+}
+
static int dev_match_of(struct device *dev, void *data)
{
return dev->of_node == data;
@@ -141,16 +248,10 @@ int tilcdc_get_external_components(struct device *dev,
struct device_node *node;
struct device_node *ep = NULL;
int count = 0;
+ int ret = 0;
- /* Avoid error print by of_graph_get_next_endpoint() if there
- * is no ports present.
- */
- node = of_get_child_by_name(dev->of_node, "ports");
- if (!node)
- node = of_get_child_by_name(dev->of_node, "port");
- if (!node)
+ if (!tilcdc_node_has_port(dev->of_node))
return 0;
- of_node_put(node);
while ((ep = of_graph_get_next_endpoint(dev->of_node, ep))) {
node = of_graph_get_remote_port_parent(ep);
@@ -160,17 +261,20 @@ int tilcdc_get_external_components(struct device *dev,
}
dev_dbg(dev, "Subdevice node '%s' found\n", node->name);
- if (match)
- drm_of_component_match_add(dev, match, dev_match_of,
- node);
- of_node_put(node);
- count++;
- }
- if (count > 1) {
- dev_err(dev, "Only one external encoder is supported\n");
- return -EINVAL;
+ if (of_device_is_compatible(node, "nxp,tda998x")) {
+ if (match)
+ drm_of_component_match_add(dev, match,
+ dev_match_of, node);
+ ret = 1;
+ }
+
+ of_node_put(node);
+ if (count++ > 1) {
+ dev_err(dev, "Only one port is supported\n");
+ return -EINVAL;
+ }
}
- return count;
+ return ret;
}
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_external.h b/drivers/gpu/drm/tilcdc/tilcdc_external.h
index c700e0c..a27c365 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_external.h
+++ b/drivers/gpu/drm/tilcdc/tilcdc_external.h
@@ -22,4 +22,5 @@
void tilcdc_remove_external_encoders(struct drm_device *dev);
int tilcdc_get_external_components(struct device *dev,
struct component_match **match);
+int tilcdc_attach_remote_device(struct drm_device *ddev);
#endif /* __TILCDC_SLAVE_H__ */
--
1.9.1
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related
* [PATCH 2/3] drm/i915: Clean up rotation DSPCNTR/DVSCNTR/etc. setup
From: ville.syrjala @ 2016-11-14 16:53 UTC (permalink / raw)
To: intel-gfx
In-Reply-To: <1479142440-25283-1-git-send-email-ville.syrjala@linux.intel.com>
From: Ville Syrjälä <ville.syrjala@linux.intel.com>
Move the plane control register rotation setup away from the
coordinate munging code. This will result in neater looking
code once we add reflection support for CHV.
v2: Drop the BIT(), drop some usless parens,
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1477077768-4274-6-git-send-email-ville.syrjala@linux.intel.com
---
drivers/gpu/drm/i915/intel_display.c | 24 +++++++++++++-----------
drivers/gpu/drm/i915/intel_sprite.c | 26 ++++++++++++++------------
2 files changed, 27 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index 16b6978662e8..f16766e27b17 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3069,6 +3069,9 @@ static void i9xx_update_primary_plane(struct drm_plane *primary,
fb->modifier[0] == I915_FORMAT_MOD_X_TILED)
dspcntr |= DISPPLANE_TILED;
+ if (rotation & DRM_ROTATE_180)
+ dspcntr |= DISPPLANE_ROTATE_180;
+
if (IS_G4X(dev_priv))
dspcntr |= DISPPLANE_TRICKLE_FEED_DISABLE;
@@ -3079,10 +3082,8 @@ static void i9xx_update_primary_plane(struct drm_plane *primary,
intel_compute_tile_offset(&x, &y, plane_state, 0);
if (rotation & DRM_ROTATE_180) {
- dspcntr |= DISPPLANE_ROTATE_180;
-
- x += (crtc_state->pipe_src_w - 1);
- y += (crtc_state->pipe_src_h - 1);
+ x += crtc_state->pipe_src_w - 1;
+ y += crtc_state->pipe_src_h - 1;
}
linear_offset = intel_fb_xy_to_linear(x, y, plane_state, 0);
@@ -3174,6 +3175,9 @@ static void ironlake_update_primary_plane(struct drm_plane *primary,
if (fb->modifier[0] == I915_FORMAT_MOD_X_TILED)
dspcntr |= DISPPLANE_TILED;
+ if (rotation & DRM_ROTATE_180)
+ dspcntr |= DISPPLANE_ROTATE_180;
+
if (!IS_HASWELL(dev_priv) && !IS_BROADWELL(dev_priv))
dspcntr |= DISPPLANE_TRICKLE_FEED_DISABLE;
@@ -3182,13 +3186,11 @@ static void ironlake_update_primary_plane(struct drm_plane *primary,
intel_crtc->dspaddr_offset =
intel_compute_tile_offset(&x, &y, plane_state, 0);
- if (rotation & DRM_ROTATE_180) {
- dspcntr |= DISPPLANE_ROTATE_180;
-
- if (!IS_HASWELL(dev_priv) && !IS_BROADWELL(dev_priv)) {
- x += (crtc_state->pipe_src_w - 1);
- y += (crtc_state->pipe_src_h - 1);
- }
+ /* HSW+ does this automagically in hardware */
+ if (!IS_HASWELL(dev_priv) && !IS_BROADWELL(dev_priv) &&
+ rotation & DRM_ROTATE_180) {
+ x += crtc_state->pipe_src_w - 1;
+ y += crtc_state->pipe_src_h - 1;
}
linear_offset = intel_fb_xy_to_linear(x, y, plane_state, 0);
diff --git a/drivers/gpu/drm/i915/intel_sprite.c b/drivers/gpu/drm/i915/intel_sprite.c
index 37ff13b838ce..ad878ea61640 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -427,6 +427,9 @@ vlv_update_plane(struct drm_plane *dplane,
if (fb->modifier[0] == I915_FORMAT_MOD_X_TILED)
sprctl |= SP_TILED;
+ if (rotation & DRM_ROTATE_180)
+ sprctl |= SP_ROTATE_180;
+
/* Sizes are 0 based */
src_w--;
src_h--;
@@ -437,8 +440,6 @@ vlv_update_plane(struct drm_plane *dplane,
sprsurf_offset = intel_compute_tile_offset(&x, &y, plane_state, 0);
if (rotation & DRM_ROTATE_180) {
- sprctl |= SP_ROTATE_180;
-
x += src_w;
y += src_h;
}
@@ -546,6 +547,9 @@ ivb_update_plane(struct drm_plane *plane,
if (fb->modifier[0] == I915_FORMAT_MOD_X_TILED)
sprctl |= SPRITE_TILED;
+ if (rotation & DRM_ROTATE_180)
+ sprctl |= SPRITE_ROTATE_180;
+
if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv))
sprctl &= ~SPRITE_TRICKLE_FEED_DISABLE;
else
@@ -566,14 +570,11 @@ ivb_update_plane(struct drm_plane *plane,
intel_add_fb_offsets(&x, &y, plane_state, 0);
sprsurf_offset = intel_compute_tile_offset(&x, &y, plane_state, 0);
- if (rotation & DRM_ROTATE_180) {
- sprctl |= SPRITE_ROTATE_180;
-
- /* HSW and BDW does this automagically in hardware */
- if (!IS_HASWELL(dev_priv) && !IS_BROADWELL(dev_priv)) {
- x += src_w;
- y += src_h;
- }
+ /* HSW+ does this automagically in hardware */
+ if (!IS_HASWELL(dev_priv) && !IS_BROADWELL(dev_priv) &&
+ rotation & DRM_ROTATE_180) {
+ x += src_w;
+ y += src_h;
}
linear_offset = intel_fb_xy_to_linear(x, y, plane_state, 0);
@@ -684,6 +685,9 @@ ilk_update_plane(struct drm_plane *plane,
if (fb->modifier[0] == I915_FORMAT_MOD_X_TILED)
dvscntr |= DVS_TILED;
+ if (rotation & DRM_ROTATE_180)
+ dvscntr |= DVS_ROTATE_180;
+
if (IS_GEN6(dev_priv))
dvscntr |= DVS_TRICKLE_FEED_DISABLE; /* must disable */
@@ -701,8 +705,6 @@ ilk_update_plane(struct drm_plane *plane,
dvssurf_offset = intel_compute_tile_offset(&x, &y, plane_state, 0);
if (rotation & DRM_ROTATE_180) {
- dvscntr |= DVS_ROTATE_180;
-
x += src_w;
y += src_h;
}
--
2.7.4
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related
* RE: [PATCH] drm/amdgpu:fix vpost_needed routine
From: Deucher, Alexander @ 2016-11-14 16:54 UTC (permalink / raw)
To: Liu, Monk, amd-gfx-CC+yJ3UmIYqDUpFQwHEjaQ@public.gmane.org
In-Reply-To: <CY4PR12MB13511E2D9B98BF92CCBAFB2E84BC0-rpdhrqHFk04aRV2spazHLQdYzm3356FpvxpqHgZTriW3zl9H0oFU5g@public.gmane.org>
> -----Original Message-----
> From: Liu, Monk
> Sent: Sunday, November 13, 2016 10:17 PM
> To: Deucher, Alexander; amd-gfx@freedesktop.org
> Subject: 答复: [PATCH] drm/amdgpu:fix vpost_needed routine
>
> Alex, the patch is already rebased against staging-4.7 , it just fixed non-FIJI
> pass-through bug, which should use regular rules but without this patch it
> will always do post.
Whoops, sorry, I mixed this up with another change. Patch is:
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
>
> BR Monk
>
> -----邮件原件-----
> 发件人: Deucher, Alexander
> 发送时间: Friday, November 11, 2016 11:05 PM
> 收件人: Liu, Monk; amd-gfx@freedesktop.org
> 抄送: Liu, Monk
> 主题: RE: [PATCH] drm/amdgpu:fix vpost_needed routine
>
> > -----Original Message-----
> > From: amd-gfx [mailto:amd-gfx-bounces@lists.freedesktop.org] On Behalf
> > Of Monk Liu
> > Sent: Friday, November 11, 2016 5:04 AM
> > To: amd-gfx@freedesktop.org
> > Cc: Liu, Monk
> > Subject: [PATCH] drm/amdgpu:fix vpost_needed routine
> >
> > 1,cleanup description/comments
> > 2,for FIJI & passthrough, force post when smc fw version below 22.15
> > 3,for other cases, follow regular rules
> >
> > Change-Id: Iecdeec1801a920c1f4ea9c8fd40be9ac2f1f3c51
> > Signed-off-by: Monk Liu <Monk.Liu@amd.com>
>
> Can you rebase this against amd-staging-4.7? We reworked this code once
> we fixed the firmware version tracking in the firmware itself. The firmware
> prior to that has a fixed version so we can check for that and special case it.
>
> Alex
>
> > ---
> > drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 27
> > +++++++---------------
> > -----
> > 1 file changed, 7 insertions(+), 20 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > index 5970c40..dbfe471 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > @@ -637,12 +637,10 @@ static bool amdgpu_vpost_needed(struct
> > amdgpu_device *adev)
> > return false;
> >
> > if (amdgpu_passthrough(adev)) {
> > - /* for FIJI: In whole GPU pass-through virtualization case
> > - * old smc fw won't clear some registers (e.g. MEM_SIZE,
> > BIOS_SCRATCH)
> > - * so amdgpu_card_posted return false and driver will
> > incorrectly skip vPost.
> > - * but if we force vPost do in pass-through case, the driver
> > reload will hang.
> > - * whether doing vPost depends on amdgpu_card_posted if
> > smc version is above
> > - * 00160e00 for FIJI.
> > + /* for FIJI: In whole GPU pass-through virtualization case,
> > after VM reboot
> > + * some old smc fw still need driver do vPost otherwise gpu
> > hang, while
> > + * those smc fw version above 22.15 doesn't have this flaw,
> > so we force
> > + * vpost executed for smc version below 22.15
> > */
> > if (adev->asic_type == CHIP_FIJI) {
> > int err;
> > @@ -653,22 +651,11 @@ static bool amdgpu_vpost_needed(struct
> > amdgpu_device *adev)
> > return true;
> >
> > fw_ver = *((uint32_t *)adev->pm.fw->data + 69);
> > - if (fw_ver >= 0x00160e00)
> > - return !amdgpu_card_posted(adev);
> > + if (fw_ver < 0x00160e00)
> > + return true;
> > }
> > - } else {
> > - /* in bare-metal case, amdgpu_card_posted return false
> > - * after system reboot/boot, and return true if driver
> > - * reloaded.
> > - * we shouldn't do vPost after driver reload otherwise GPU
> > - * could hang.
> > - */
> > - if (amdgpu_card_posted(adev))
> > - return false;
> > }
> > -
> > - /* we assume vPost is neede for all other cases */
> > - return true;
> > + return !amdgpu_card_posted(adev);
> > }
> >
> > /**
> > --
> > 1.9.1
> >
> > _______________________________________________
> > amd-gfx mailing list
> > amd-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/amd-gfx
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
^ permalink raw reply
* Re: [PATCH v3] ip6_output: ensure flow saddr actually belongs to device
From: David Ahern @ 2016-11-14 16:55 UTC (permalink / raw)
To: Hannes Frederic Sowa, Jason A. Donenfeld, Netdev,
WireGuard mailing list, LKML, YOSHIFUJI Hideaki
In-Reply-To: <1479141867.3723362.787321689.4A3DCFD6@webmail.messagingengine.com>
On 11/14/16 9:44 AM, Hannes Frederic Sowa wrote:
> On Mon, Nov 14, 2016, at 00:28, Jason A. Donenfeld wrote:
>> This puts the IPv6 routing functions in parity with the IPv4 routing
>> functions. Namely, we now check in v6 that if a flowi6 requests an
>> saddr, the returned dst actually corresponds to a net device that has
>> that saddr. This mirrors the v4 logic with __ip_dev_find in
>> __ip_route_output_key_hash. In the event that the returned dst is not
>> for a dst with a dev that has the saddr, we return -EINVAL, just like
>> v4; this makes it easy to use the same error handlers for both cases.
>>
>> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
>> Cc: David Ahern <dsa@cumulusnetworks.com>
>> ---
>> Changes from v2:
>> It turns out ipv6_chk_addr already has the device enumeration
>> logic that we need by simply passing NULL.
>>
>> net/ipv6/ip6_output.c | 4 ++++
>> 1 file changed, 4 insertions(+)
>>
>> diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
>> index 6001e78..b3b5cb6 100644
>> --- a/net/ipv6/ip6_output.c
>> +++ b/net/ipv6/ip6_output.c
>> @@ -926,6 +926,10 @@ static int ip6_dst_lookup_tail(struct net *net,
>> const struct sock *sk,
>> int err;
>> int flags = 0;
>>
>> + if (!ipv6_addr_any(&fl6->saddr) &&
>> + !ipv6_chk_addr(net, &fl6->saddr, NULL, 1))
>> + return -EINVAL;
>
> Hmm, this check is too permissive, no?
>
> E.g. what happens if you move a link local address from one interface to
> another? In this case this code would still allow the saddr to be used.
This check -- like the ipv4 variant -- only verifies the saddr is locally assigned. If the address moves interfaces it should be fine.
>
> I just also quickly read up on the history (sorry was travelling last
> week) and wonder if you ever saw a user space facing bug or if this is
> basically some difference you saw while writing out of tree code?
I checked the userspace API this morning. bind and cmsg for example check that the address is valid with calls to ipv6_chk_addr.
^ permalink raw reply
* Re: [PATCH] bsg: Add sparse annotations to bsg_request_fn()
From: Bart Van Assche @ 2016-11-14 16:55 UTC (permalink / raw)
To: Jens Axboe; +Cc: linux-block@vger.kernel.org
In-Reply-To: <6dfb1793-ca6a-c3b6-b3fc-272e68ca6880@sandisk.com>
On 09/25/2016 07:54 PM, Bart Van Assche wrote:
> Avoid that sparse complains about unbalanced lock actions.
>
> Signed-off-by: Bart Van Assche <bart.vanassche@sandisk.com>
> ---
> block/bsg-lib.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/block/bsg-lib.c b/block/bsg-lib.c
> index 650f427..b2a61e3 100644
> --- a/block/bsg-lib.c
> +++ b/block/bsg-lib.c
> @@ -161,6 +161,8 @@ failjob_rls_job:
> * Drivers/subsys should pass this to the queue init function.
> */
> void bsg_request_fn(struct request_queue *q)
> + __releases(q->queue_lock)
> + __acquires(q->queue_lock)
> {
> struct device *dev = q->queuedata;
> struct request *req;
>
Hi Jens,
Do you agree with this patch? If so, can you queue it for kernel v4.10?
Thanks,
Bart.
^ 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.