From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752208AbcHAVR7 (ORCPT ); Mon, 1 Aug 2016 17:17:59 -0400 Received: from relay1.mentorg.com ([192.94.38.131]:47459 "EHLO relay1.mentorg.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751877AbcHAVRx (ORCPT ); Mon, 1 Aug 2016 17:17:53 -0400 Subject: Re: [PATCH v3 10/12] gpu: ipu-v3: Add FSU channel linking support To: Philipp Zabel , Steve Longerbeam References: <1469994147-17549-1-git-send-email-steve_longerbeam@mentor.com> <1469994147-17549-11-git-send-email-steve_longerbeam@mentor.com> <1470042801.3025.17.camel@pengutronix.de> CC: , , , , From: Steve Longerbeam Message-ID: <580072d5-b70b-8ca3-94aa-b3199997206b@mentor.com> Date: Mon, 1 Aug 2016 13:35:10 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <1470042801.3025.17.camel@pengutronix.de> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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