From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751625AbeFEIpQ (ORCPT ); Tue, 5 Jun 2018 04:45:16 -0400 Received: from mail-wm0-f67.google.com ([74.125.82.67]:36567 "EHLO mail-wm0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751506AbeFEIpM (ORCPT ); Tue, 5 Jun 2018 04:45:12 -0400 X-Google-Smtp-Source: ADUXVKL6JfewyLvE/dXrld+8UKfsEDPvjQGdenJs9Cxc6/et5upYOT+LANp1ZjcoEpN7unUIHYavzA== Subject: Re: [PATCH v2 5/5] venus: register separate driver for firmware device To: Tomasz Figa , Stanimir Varbanov Cc: vgarodia@codeaurora.org, Hans Verkuil , Mauro Carvalho Chehab , Rob Herring , Mark Rutland , andy.gross@linaro.org, bjorn.andersson@linaro.org, Linux Media Mailing List , Linux Kernel Mailing List , linux-arm-msm , linux-soc@vger.kernel.org, devicetree@vger.kernel.org, Alexandre Courbot , Arnd Bergmann References: <1527884768-22392-1-git-send-email-vgarodia@codeaurora.org> <1527884768-22392-6-git-send-email-vgarodia@codeaurora.org> <2cf4f7e8-f9e6-d62b-45a8-2c348af4aafe@linaro.org> From: Stanimir Varbanov Message-ID: Date: Tue, 5 Jun 2018 11:45:08 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Cc: Arnd On 06/05/2018 07:08 AM, Tomasz Figa wrote: > On Mon, Jun 4, 2018 at 10:56 PM Stanimir Varbanov > wrote: >> >> Hi Tomasz, >> >> On 06/04/2018 04:18 PM, Tomasz Figa wrote: >>> Hi Vikash, >>> >>> On Sat, Jun 2, 2018 at 5:27 AM Vikash Garodia wrote: >>>> +static int __init venus_init(void) >>>> +{ >>>> + int ret; >>>> + >>>> + ret = platform_driver_register(&qcom_video_firmware_driver); >>>> + if (ret) >>>> + return ret; >>> >>> Do we really need this firmware driver? As far as I can see, the >>> approach used here should work even without any driver bound to the >>> firmware device. >> >> We need device/driver bind because we need to call dma_configure() which >> internally doing iommus sID parsing. > > I can see some drivers calling of_dma_configure() directly: > https://elixir.bootlin.com/linux/latest/ident/of_dma_configure > > I'm not sure if it's more elegant, but should at least require less code. I think that in this case of non-TZ where we do iommu mapping by hand we can use shared-dma-pool reserved memory see how venus_boot has been implemented in the beginning [1]. Arnd what do you think? Some background, we have a use-case where the memory for firmware needs to be mapped by the venus driver by hand instead of TZ firmware calls. I.e. we want to support both, iommu mapping from the driver and mapping done by TZ firmware. How we will differentiate what mapping (TZ or non-TZ) will be used is a separate issue. > > By the way, can we really assume that probe of firmware platform > device really completes before we call venus_boot()? I'd say we cannot. -- regards, Stan [1] https://lkml.org/lkml/2017/4/28/214