linux-kernel - Re: [PATCH v3 10/12] gpu: ipu-v3: Add FSU channel linking support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 1 Aug 2016 13:35:10 -0700
From:	Steve Longerbeam <steve_longerbeam@...tor.com>
To:	Philipp Zabel <p.zabel@...gutronix.de>,
	Steve Longerbeam <slongerbeam@...il.com>
CC:	<plagnioj@...osoft.com>, <tomi.valkeinen@...com>,
	<dri-devel@...ts.freedesktop.org>, <linux-kernel@...r.kernel.org>,
	<linux-fbdev@...r.kernel.org>
Subject: Re: [PATCH v3 10/12] gpu: ipu-v3: Add FSU channel linking support

On 08/01/2016 02:13 AM, Philipp Zabel wrote:
> Am Sonntag, den 31.07.2016, 12:42 -0700 schrieb Steve Longerbeam:
>> Adds functions to link and unlink source channels to sink
>> channels in the FSU:
>>
>> int ipu_fsu_link(struct ipu_soc *ipu, int src_ch, int sink_ch);
>> int ipu_fsu_unlink(struct ipu_soc *ipu, int src_ch, int sink_ch);
>>
>> The channels numbers are usually IDMAC channels, but they can also be
>> channels that do not transfer data to or from memory. The following
>> convenience functions can be used in place of ipu_fsu_link/unlink()
>> when both source and sink channels are IDMAC channels:
>>
>> int ipu_idmac_link(struct ipuv3_channel *src, struct ipuv3_channel *sink);
>> int ipu_idmac_unlink(struct ipuv3_channel *src, struct ipuv3_channel *sink);
>>
>> So far the following links are supported:
>>
>> IPUV3_CHANNEL_IC_PRP_ENC_MEM -> IPUV3_CHANNEL_MEM_ROT_ENC
>> PUV3_CHANNEL_IC_PRP_VF_MEM   -> IPUV3_CHANNEL_MEM_ROT_VF
>> IPUV3_CHANNEL_IC_PP_MEM      -> IPUV3_CHANNEL_MEM_ROT_PP
>> IPUV3_CHANNEL_CSI_DIRECT     -> IPUV3_CHANNEL_CSI_VDI_PREV
> Looks good to me, thanks. Are you sure though that the target of the CSI
> direct channel is VDI_PREV? I would have assumed the CSI input is fed
> into VDI_NEXT, while CUR and PREV are read from memory.

Reprinting from the TRM:

37.4.11.4 Real Time Mode
In Real Time Mode the F(n-1) are coming from CSI. The CSI write to FIFO1. The DI
sub-block read F(n-1) from processing. In addition IDMAC read the field from FIFO1
and store in external memory. Then stored frames are used as F(n) and F(n+1).


Steve