* RE: [PATCH] drm/amdgpu: refine cz uvd clock gate logic.
From: Deucher, Alexander @ 2016-11-14 16:56 UTC (permalink / raw)
To: amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org; +Cc: Zhu, Rex
In-Reply-To: <1478841892-30332-1-git-send-email-Rex.Zhu-5C7GfCeVMHo@public.gmane.org>
> -----Original Message-----
> From: amd-gfx [mailto:amd-gfx-bounces@lists.freedesktop.org] On Behalf
> Of Rex Zhu
> Sent: Friday, November 11, 2016 12:25 AM
> To: amd-gfx@lists.freedesktop.org
> Cc: Zhu, Rex
> Subject: [PATCH] drm/amdgpu: refine cz uvd clock gate logic.
>
> sw clockgate was used on uvd6.0.
> when uvd is idle, we gate the uvd clock.
> when decode, we ungate the uvd clock.
>
> Change-Id: I79ecdc5d0f48e97919386a08acca994f1fa05484
> Signed-off-by: Rex Zhu <Rex.Zhu@amd.com>
Assuming clockgating still works properly:
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
> ---
> drivers/gpu/drm/amd/amdgpu/cz_dpm.c | 6 ++----
> drivers/gpu/drm/amd/powerplay/hwmgr/cz_clockpowergating.c | 4 ++--
> 2 files changed, 4 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/cz_dpm.c
> b/drivers/gpu/drm/amd/amdgpu/cz_dpm.c
> index 41fa351..ba2b66b 100644
> --- a/drivers/gpu/drm/amd/amdgpu/cz_dpm.c
> +++ b/drivers/gpu/drm/amd/amdgpu/cz_dpm.c
> @@ -2111,9 +2111,8 @@ static void cz_dpm_powergate_uvd(struct
> amdgpu_device *adev, bool gate)
>
> if (gate) {
> if (pi->caps_uvd_pg) {
> - /* disable clockgating so we can properly shut down
> the block */
> ret = amdgpu_set_clockgating_state(adev,
> AMD_IP_BLOCK_TYPE_UVD,
> -
> AMD_CG_STATE_UNGATE);
> +
> AMD_CG_STATE_GATE);
> if (ret) {
> DRM_ERROR("UVD DPM Power Gating failed
> to set clockgating state\n");
> return;
> @@ -2159,9 +2158,8 @@ static void cz_dpm_powergate_uvd(struct
> amdgpu_device *adev, bool gate)
> return;
> }
>
> - /* enable clockgating. hw will dynamically
> gate/ungate clocks on the fly */
> ret = amdgpu_set_clockgating_state(adev,
> AMD_IP_BLOCK_TYPE_UVD,
> -
> AMD_CG_STATE_GATE);
> +
> AMD_CG_STATE_UNGATE);
> if (ret) {
> DRM_ERROR("UVD DPM Power Gating Failed
> to set clockgating state\n");
> return;
> diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/cz_clockpowergating.c
> b/drivers/gpu/drm/amd/powerplay/hwmgr/cz_clockpowergating.c
> index 2028980..b0c63c5 100644
> --- a/drivers/gpu/drm/amd/powerplay/hwmgr/cz_clockpowergating.c
> +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/cz_clockpowergating.c
> @@ -169,7 +169,7 @@ int cz_dpm_powergate_uvd(struct pp_hwmgr
> *hwmgr, bool bgate)
> if (bgate) {
> cgs_set_clockgating_state(hwmgr->device,
> AMD_IP_BLOCK_TYPE_UVD,
> - AMD_CG_STATE_UNGATE);
> + AMD_CG_STATE_GATE);
> cgs_set_powergating_state(hwmgr->device,
> AMD_IP_BLOCK_TYPE_UVD,
> AMD_PG_STATE_GATE);
> @@ -182,7 +182,7 @@ int cz_dpm_powergate_uvd(struct pp_hwmgr
> *hwmgr, bool bgate)
> AMD_CG_STATE_UNGATE);
> cgs_set_clockgating_state(hwmgr->device,
> AMD_IP_BLOCK_TYPE_UVD,
> - AMD_PG_STATE_GATE);
> + AMD_PG_STATE_UNGATE);
> cz_dpm_update_uvd_dpm(hwmgr, false);
> }
>
> --
> 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 1/2] Revert "drm: Add and handle new aspect ratios in DRM layer"
From: Sharma, Shashank @ 2016-11-14 16:56 UTC (permalink / raw)
To: Ville Syrjälä
Cc: Jose Abreu, Jia, Lin A, Akashdeep Sharma, Emil Velikov, dri-devel,
Daniel Vetter, Jim Bride
In-Reply-To: <20161114164518.GA31595@intel.com>
On 11/14/2016 10:15 PM, Ville Syrjälä wrote:
> On Mon, Nov 14, 2016 at 10:12:04PM +0530, Sharma, Shashank wrote:
>> Regards
>>
>> Shashank
>>
>>
>> On 11/14/2016 9:50 PM, Ville Syrjälä wrote:
>>> On Mon, Nov 14, 2016 at 09:37:18PM +0530, Sharma, Shashank wrote:
>>>> Regards
>>>>
>>>> Shashank
>>>>
>>>>
>>>> On 11/14/2016 9:19 PM, Ville Syrjälä wrote:
>>>>> On Mon, Nov 14, 2016 at 08:14:34PM +0530, Sharma, Shashank wrote:
>>>>>> Regards
>>>>>> Shashank
>>>>>>> the revert:
>>>>>>>
>>>>>>> HDMI2 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 700mm x 390mm
>>>>>>> - 1920x1080 60.00*+
>>>>>>> - 1920x1080i 60.00 50.00
>>>>>>> + 1920x1080 60.00*+ 50.00 59.94 30.00 25.00 24.00 29.97 23.98
>>>>>>> + 1920x1080i 60.00 50.00 59.94
>>>>>>> 1600x1200 60.00
>>>>>>> 1680x1050 59.88
>>>>>>> 1280x1024 75.02 60.02
>>>>>>> @@ -13,30 +13,29 @@
>>>>>>> 1360x768 60.02
>>>>>>> 1280x800 59.91
>>>>>>> 1152x864 75.00
>>>>>>> - 1280x720 60.00 50.00
>>>>>>> + 1280x720 60.00 50.00 59.94
>>>>>>> 1024x768 75.03 70.07 60.00
>>>>>>> 832x624 74.55
>>>>>>> 800x600 72.19 75.00 60.32
>>>>>>> - 640x480 75.00 72.81 66.67 59.94
>>>>>>> + 720x576 50.00
>>>>>>> + 720x480 60.00 59.94
>>>>>>> + 640x480 75.00 72.81 66.67 60.00 59.94
>>>>>>> 720x400 70.08
>>>>>> None of these aspect ratios are new modes / new aspect ratios from HDMI
>>>>>> 2.0/CEA-861-F
>>>>>> These are the existing modes, and should be independent of reverted
>>>>>> patches.
>>>>> They're affected because your patches changed them by adding the aspect
>>>>> ratio flags to them.
>>>> Yes, But they are independent of reverted patch, which adds aspect ratio
>>>> for HDMI 2.0 ratios (64:27 and 256:135)
>>> The second patch had to be reverted so that the first patch would revert
>>> cleanly.
>>>
>>>>>>> This was with sna, which does this:
>>>>>>> #define KNOWN_MODE_FLAGS ((1<<14)-1)
>>>>>>> if (mode->status == MODE_OK && kmode->flags & ~KNOWN_MODE_FLAGS)
>>>>>>> mode->status = MODE_BAD; /* unknown flags => unhandled */
>>>>>>> so all the modes with an aspect ratio just vanished.
>>>>>>>
>>>>>>> -modesetting and -ati on the other hand just copy over the unknown
>>>>>>> bits into the xrandr mode structure, which sounds dubious at best:
>>>>>>> mode->Flags = kmode->flags; //& FLAG_BITS;
>>>>>>> I've not checked what damage it can actually cause.
>>>>>>>
>>>>>>>
>>>>>>> It looks like a few modes disappeared from the kernel's mode list
>>>>>>> as well, presumably because some cea modes in the list originated from
>>>>>>> DTDs and whanot so they don't have an aspect ratio and that causes
>>>>>>> add_alternate_cea_modes() to ignore them. So not populating an aspect
>>>>>>> ratio for cea modes originating from a source other than
>>>>>>> edid_cea_modes[] looks like another bug to me as well.
>>>>>> I am writing a patch series to cap the aspect ratio implementation under
>>>>>> a drm_cap_hdmi2_aspect_ratios
>>>>>> This is how its going to work (inspired from the 2D/stereo series from
>>>>>> damien L)
>>>>>>
>>>>>> - Add a new capability hdmi2_ar
>>>>> It should be just a generic "expose aspect ratio flags to userspace?"
>>>> Makes sense, in this way we can even revert the aspect_ratio property
>>>> for HDMI connector, as discussed during
>>>> the code review sessions of this patch series. In this way, when kernel
>>>> will expose the aspect ratios, it will either
>>>> do the aspect ratios as per EDID, or wont.
>>>>>> - by default parsing the new hdmi 2.0 aspect ratio will be disabled
>>>>>> under check of this cap
>>>>>> - during bootup time, while initializing the display, a userspace can
>>>>>> get_cap on the hdmi2_aspect_ratio
>>>>>> - If it wants HDMI 2.0 aspect ratio support, it will set the cap, and
>>>>>> kernel will expose these aspect ratios
>>>>>>> Another bug I think might be the ordering of the modes with aspect ratio
>>>>>>> specified. IIRC the spec says that the preferred aspect ratio should be
>>>>>>> listed first in the EDID, but I don't think we preserve that ordering
>>>>>>> in the final mode list. I guess we could fix that by somehow noting
>>>>>>> which aspect ratio is preferred and sort based on that, or we try to
>>>>>>> preserve the order from the EDID until we're ready to sort, and then do
>>>>>>> the sorting with a stable algorithm.
>>>>>> AFAIK The mode order and priority is decided and arranged in userspace,
>>>>>> based on various factors like
>>>>>> - preferred mode.
>>>>>> - previously applied mode in previous sessions (like for android tvs)
>>>>>> - Bigger h/w vs better refresh rate ?
>>>>>> - Xserver applies its own algorithms to decide which mode should be
>>>>>> shown first.
>>>>> Xorg does sort on its own. But since it doesn't know anything about
>>>>> aspect ratios and whatnot I wouldn't rely on that for anything. I
>>>>> also wouldn't expect eg. wayland compositors to do their own sorting.
>>>>> And yeah, looks like weston at least doesn't do any sorting whatsoever.
>>>>>
>>>>>> I dont think kernel needs to bother about it.
>>>>> So I'm going to say that we in fact do need to bother.
>>>>>
>>>> IMHO, making policies for UI is not a part of kernel design, a UI
>>>> manager (Hardware composed, X or Wayland) should take care of it, as
>>>> they have access to much information (Like previously applied mode, user
>>>> preference etc). When it comes to sorting of modes, the only general rule
>>>> across drivers like FB, V4L2, I have seen is the first mode in the list
>>>> should be preferred mode, which we are still keeping. And after that our
>>>> probed_modes were
>>>> anyways not sorted now, so it doesn't matter further.
>>> Having userspace be responsible for sorting the aspect ratios would
>>> perhaps require that userspace parses the EDID, which is pretty crazy.
>> Why ?
>> userspace has to just set cap for aspect ratio, and kernel can read
>> EDID, parse the CEA block, populate the aspect ratios flags
>> and add the modes (Just what this patch was doing, except the cap part)
>> Once userspace has the getResources/getConnector call filled, it can
>> access all the modes (with and without aspect) and do the sorting
>> in any way it wants.
>>> I guess it could try to deduce something from the physical aspect ratio
>>> of the display, but I'm not sure that's quite what we want either.
>>>
>>> Also we already sort the modes in the kernel anyway, so it's not like
>>> we'd be doing something new by also considering the aspect ratios.
>>> I would at the very least want to avoid a totally random order between
>>> modes that differ only by the aspect ratio.
>> Path: get_connector -> probe_single_connector_mode -> drm_add_edid_modes
>> Again, IMHO, we don't sort the modes in kernel, we populate modes in a
>> particular order, which is:
>> (From drm_edid.c::drm_add_edid_modes)
>> ##############################################################
>> /*
>> * EDID spec says modes should be preferred in this order:
>> * - preferred detailed mode
>> * - other detailed modes from base block
>> * - detailed modes from extension blocks
>> * - CVT 3-byte code modes
>> * - standard timing codes
>> * - established timing codes
>> * - modes inferred from GTF or CVT range information
>> *
>> * We get this pretty much right.
>> *
>> * XXX order for additional mode types in extension blocks?
>> */
>> num_modes += add_detailed_modes(connector, edid, quirks);
>> num_modes += add_cvt_modes(connector, edid);
>> num_modes += add_standard_modes(connector, edid);
>> num_modes += add_established_modes(connector, edid);
>> num_modes += add_cea_modes(connector, edid);
>> num_modes += add_alternate_cea_modes(connector, edid);
>> num_modes += add_displayid_detailed_modes(connector, edid);
>> ###############################################################
>>
>> Here the modes are added in the connector, in the same order they are
>> arranged into their respective blocks in EDID.
>> But the order to read the block is a preferred order (no sorting).
>>
>> Now, in this patch series, we are adding aspect ratio information in
>> edid_cea_modes db, which is going to affect only
>> add_cea/alternate_cea_modes() call, and the modes accordingly.
>> Please let me know if I misunderstood something here.
> We explicitly sort the modes after this.
>
In any case, I guess addition of a cap for aspect ratio should fix the
current objections for this implementation.
And I will keep it 0 by default, so that no aspect ratio information is
added until userspace sets the cap to 1 on its own.
Regards
Shashank
>> Regards
>> Shashank
>>>> If X server doesn't know what to do with aspect ratio flags, it can
>>>> chose not to set the cap, and if HWC knows, it can chose to set. This is
>>>> the same situation as 2D stereo modes
>>>> which are existing already.
>>>>
>>>> Regards
>>>> Shashank
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: BUG: KASAN: use-after-free in snd_usb_audio_free
From: Shuah Khan @ 2016-11-14 16:55 UTC (permalink / raw)
To: Takashi Iwai, Shuah Khan; +Cc: alsa-devel, LKML, Shuah Khan
In-Reply-To: <s5hr36e2waq.wl-tiwai@suse.de>
On 11/14/2016 03:25 AM, Takashi Iwai wrote:
> On Sat, 12 Nov 2016 00:34:38 +0100,
> Shuah Khan wrote:
>>
>> Hi Takashi,
>>
>> I am seeing the following use-after-free error when I disconnect an
>> USB speaker. I saw this on 4.9-rc4 and 4.8.7. There might be race
>> condition between the disconnect and pcm close perhaps.
>
> Thanks, this looks like a new discovery.
> Could you check whether the patch below works?
>
>
> Takashi
>
> ---
> diff --git a/sound/usb/card.c b/sound/usb/card.c
> index 9e5276d6dda0..2ddc034673a8 100644
> --- a/sound/usb/card.c
> +++ b/sound/usb/card.c
> @@ -315,7 +315,8 @@ static int snd_usb_audio_free(struct snd_usb_audio *chip)
> snd_usb_endpoint_free(ep);
>
> mutex_destroy(&chip->mutex);
> - dev_set_drvdata(&chip->dev->dev, NULL);
> + if (!atomic_read(&chip->shutdown))
> + dev_set_drvdata(&chip->dev->dev, NULL);
> kfree(chip);
> return 0;
> }
>
Hi Takashi,
The patch fixed the problem on 4.9-rc4. Didn't get a chance
to test it on 4.8.7.
thanks,
-- Shuah
^ 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
* 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] 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
* [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
* [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 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
* 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 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
* [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 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 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
* 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 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: [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
* 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: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: [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: [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
* [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
* [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
* 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
* 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
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.