Received: by 2002:a05:6a10:87d6:0:0:0:0 with SMTP id g22csp996285pxr; Mon, 11 Apr 2022 12:18:08 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzY7l74Sj9KZ6Wv15vhQuNtGT0Lz4TB0YJvGQOe159SEwxomfclFR35iWuUNE8s7Kx2e/bv X-Received: by 2002:a63:3d4:0:b0:39d:8edf:35b2 with SMTP id 203-20020a6303d4000000b0039d8edf35b2mr333471pgd.359.1649704688575; Mon, 11 Apr 2022 12:18:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1649704688; cv=none; d=google.com; s=arc-20160816; b=H+9z0qBurkPe1c49+frRKzOHnCZPmdXK957oSvgdqFvaTdW7R2QBIQoSw7giYQHMLs bRqCoIYcKZ2zELLEw//OSESabWHFNcX/U0Np3wXxK8z/Evw1JMHIBkLrkWa8CtXNWEJd qAx7nN+hEmDhqBhkZoZ8IL5nc+zY82w3DQDztzs/7DEER9VGWKum6tyYKYVUXCZIYo9E Z2sSguTEgkTDs8pSgQq61H/+WHQpYcM5orkuYQlu6feZdFkuxegoYEdmA7jUzaibLlxi Ezmi9wv6Rcl/FIWc/grbKHxBMhCTqq/8y4G4JGK98ZgjEfikNJA+OyiVETGer5RoU+BB V/Fw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=pcayEkSC0N5yxvPOx3kyjuoGO3R9o8JzDcPwOx8d5Kg=; b=O8qabNEt/dlKSy60Kw1TJS0+MMaEE/JqFumInWMqjliMSLAfSRnwPXMTmZ4LwwMQGa yN92zLW4R4y4NsujXvWjoCDiXj5DbyjrT1LFf4yljT0aA0v6tOVUJu1DuMDqjoNVFhcW f2qpESSl3hbZInCg0IpMXsa6RQVn/OANjU077VBSvY6DpKqa627iTtesPSYFQmtt9Fdh nnaW0iHxeyehJG+wA4/U+jhzBqi5n6gmAA4dIniaaw4it711yMusUzl28de8kVztwJP/ 0rsHZ0kxrg4uAxoFr6x+xvkeg1qO51OXTlrzW3G1j9a5gH1j4Ui+HFmtMyAZSVU4RHTO nguw== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@metrotek.ru header.s=mail header.b=CEI2hXzS; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id v22-20020a636116000000b0038160e4a2edsi538334pgb.821.2022.04.11.12.17.52; Mon, 11 Apr 2022 12:18:08 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=fail header.i=@metrotek.ru header.s=mail header.b=CEI2hXzS; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241791AbiDINBa (ORCPT + 99 others); Sat, 9 Apr 2022 09:01:30 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55858 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229641AbiDINB2 (ORCPT ); Sat, 9 Apr 2022 09:01:28 -0400 Received: from mail.pr-group.ru (mail.pr-group.ru [178.18.215.3]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0CF9455BC; Sat, 9 Apr 2022 05:59:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=metrotek.ru; s=mail; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to: references; bh=MmsrU07PgLUD8XKlGAlPmaXdI+yyXvNNcYAukLrx62Y=; b=CEI2hXzSPqnIcufESjduzwbYlCeHlDyPUTHL3FWC7B1OvItyXEclcgmIXLx9vpVt+N1DhLe2vbRWE KPv2Cv2gWs58Uacjv8iDViXf9vtOgLwpHGBXnuF6OY2I2wZv91aU+5balZe5ZuLHBL3DBUJGdNBfwn p4ltj6MAQDWVko0oCiW48L8cDvlPv5LMISSymSyt7OBxfmWnmLd9cZwVNstJ4Vc8U9bunmwHWU4MjN L2e3KD5WdNE4kPdVNn4g9aPQoxT7MvLwwAXFDt18PMzYDn9niG9w35jF78hfQKrlai009Eo9n30lZY WmRGeNmJrWKryzxvk9Rcd5g2uw4X54w== X-Kerio-Anti-Spam: Build: [Engines: 2.16.2.1410, Stamp: 3], Multi: [Enabled, t: (0.000008,0.008582)], BW: [Enabled, t: (0.000013,0.000001)], RTDA: [Enabled, t: (0.063684), Hit: No, Details: v2.34.0; Id: 15.52k78o.1g076fs5a.4ace; mclb], total: 0(700) X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Level: X-Footer: bWV0cm90ZWsucnU= Received: from x260 ([178.70.66.234]) (authenticated user i.bornyakov@metrotek.ru) by mail.pr-group.ru with ESMTPSA (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256 bits)); Sat, 9 Apr 2022 15:58:51 +0300 Date: Sat, 9 Apr 2022 15:38:51 +0300 From: Ivan Bornyakov To: Xu Yilun Cc: mdf@kernel.org, hao.wu@intel.com, trix@redhat.com, conor.dooley@microchip.com, robh+dt@kernel.org, krzysztof.kozlowski+dt@linaro.org, system@metrotek.ru, linux-kernel@vger.kernel.org, linux-fpga@vger.kernel.org, devicetree@vger.kernel.org Subject: Re: [PATCH v9 1/3] fpga: fpga-mgr: support bitstream offset in image buffer Message-ID: <20220409123851.tcjflctnuurag2yb@x260> References: <20220407133658.15699-1-i.bornyakov@metrotek.ru> <20220407133658.15699-2-i.bornyakov@metrotek.ru> <20220409050423.GA265355@yilunxu-OptiPlex-7050> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220409050423.GA265355@yilunxu-OptiPlex-7050> X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Apr 09, 2022 at 01:04:23PM +0800, Xu Yilun wrote: > On Thu, Apr 07, 2022 at 04:36:56PM +0300, Ivan Bornyakov wrote: > > > > ... snip ... > > > > @@ -148,12 +149,10 @@ static int fpga_mgr_write_init_buf(struct fpga_manager *mgr, > > int ret; > > > > mgr->state = FPGA_MGR_STATE_WRITE_INIT; > > - if (!mgr->mops->initial_header_size) > > - ret = fpga_mgr_write_init(mgr, info, NULL, 0); > > - else > > - ret = fpga_mgr_write_init( > > - mgr, info, buf, min(mgr->mops->initial_header_size, count)); > > + if (mgr->mops->initial_header_size) > > + count = min(mgr->mops->initial_header_size, count); > > > > + ret = fpga_mgr_write_init(mgr, info, buf, count); > > Here we pass the whole buffer for write_init(). Maybe it works for mapped buf, > but still doesn't work for sg buf. > > It is also inefficient if we change to map and copy all sg buffers just for > write_init(). > > We could discuss on the solution. > > My quick mind is we introduce an optional fpga_manager_ops.parse_header() > callback, and a header_size (dynamic header size) field in > fpga_image_info. FPGA core starts with mapping a buf of initial_header_size > for parse_header(), let the drivers decide the dynamic header_size. > > The parse_header() could be called several times with updated dynamic > header_size, if drivers doesn't get enough buffer for final decision and > return -EAGAIN. > > Then write_init() be called with the final dynamic header size. > > For mapped buffer, just passing the whole buffer for write_init() is > fine. > Ok, that's sounds reasonable. Should we pass PAGE_SIZE of a buffer to the parse_header() if initial_header_size is not set? The other option would be to make initial_header_size to be mandatory for usage of parse_header(). > > > > ... snip ... > > > > @@ -98,6 +101,8 @@ struct fpga_image_info { > > struct sg_table *sgt; > > const char *buf; > > size_t count; > > + size_t bitstream_start; > > How about we name it header_size? > > > + size_t bitstream_size; > > And how about data_size? > Sure, I don't mind.