From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 9F7C5C05027 for ; Fri, 20 Jan 2023 06:59:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=UzyaqBnDPLoIjQNRTzmwk4G98TXDflzvXX5XH2UT1zk=; b=juoLiUFyqdMZL8 6IEGri0zejkHNTDZBdU5uJ4s5/zgK0MUgDnao2Xc/FtjKa/r8JPkVQ+Fh30D3/rRT451SUJ9LHpGk trlOf1A+l9sEZyP64abbdIl+CP7wXRimaZVw2doFnKtLDDCHN18uWS5yLtXQTpIo8tiWfq7LfXB2P kxofEK6dctUhewljl2SbZFk4dVxOjfixJWJrj3fbPFd7F0C1A426bskDzeK++/k3pvn5R8GLFHM0k DkEtHSs6iAiFjfHXAt6mXrz5lj4Jzvhi2/XkUST28UTq117jdvs2VPxV3DQvudD7LL0z/fRfrdVtu l+KuBRZlicJO7xfOb5IQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1pIlMX-008hBh-8g; Fri, 20 Jan 2023 06:58:57 +0000 Received: from dfw.source.kernel.org ([2604:1380:4641:c500::1]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1pIlMU-008hAv-6B; Fri, 20 Jan 2023 06:58:55 +0000 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id BD69C61E0D; Fri, 20 Jan 2023 06:58:53 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 75C5DC433EF; Fri, 20 Jan 2023 06:58:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1674197933; bh=1aDhdD8dlQNsJqn7RhlLZ4uUS8ZQrUcBhKch1rmt+VA=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=omrqTdMK+jbcdPsuSg6Qx5WaM+ZdejI7Nd574Iw9bf5zdVTwOqUZ+nT8PE3IKHD68 YeeguDPIItOS3iR1xdZpQqkQgnl+7/+Jn0eolM3bRuQGHwAwpgA7WsPOXPAsiZasPn dZWRJerLTAXR+vHzY1Uff+1Jc7+IYBIGTiZYVAdo= Date: Fri, 20 Jan 2023 07:58:49 +0100 From: Greg Kroah-Hartman To: Laurent Pinchart Cc: Umang Jain , linux-staging@lists.linux.dev, linux-rpi-kernel@lists.infradead.org, linux-arm-kernel@lists.infradead.org, linux-media@vger.kernel.org, linux-kernel@vger.kernel.org, Stefan Wahren , Florian Fainelli , Adrien Thierry , Dan Carpenter , Dave Stevenson , Kieran Bingham , Paul Elder Subject: Re: [PATCH v5 6/6] staging: vc04_services: vchiq: Register devices with a custom bus_type Message-ID: References: <20230119115503.268693-1-umang.jain@ideasonboard.com> <20230119115503.268693-7-umang.jain@ideasonboard.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230119_225854_340975_902DACDA X-CRM114-Status: GOOD ( 34.21 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Fri, Jan 20, 2023 at 03:52:22AM +0200, Laurent Pinchart wrote: > Hi Umang, > > Thank you for the patch. > > On Thu, Jan 19, 2023 at 05:25:03PM +0530, Umang Jain wrote: > > The devices that the vchiq interface registers(bcm2835-audio, > > Missing space before '('. > > > bcm2835-camera) are implemented and exposed by the VC04 firmware. > > The device tree describes the VC04 itself with the resources > > required to communicate with it through a mailbox interface. However, > > the vchiq interface registers these devices as platform devices. This > > also means the specific drivers for these devices are also getting > > Drop one of the two "also". > > > registered as platform drivers. This is not correct and a blatant > > abuse of platform device/driver. > > > > Replace the platform device/driver model with a standard device driver > > model. A custom bus_type, vchiq_bus_type, is created in the vchiq > > interface which matches the devices to their specific device drivers > > thereby, establishing driver binding. A struct vchiq_device wraps the > > struct device for each device being registered on the bus by the vchiq > > interface. > > > > Each device registered will expose a 'name' read-only device attribute > > in sysfs (/sys/bus/vchiq-bus/devices). New devices and drivers can be > > added by registering on vchiq_bus_type and adding a corresponding > > device name entry in the static list of devices, vchiq_devices. There > > is currently no way to enumerate the VCHIQ devices that are available > > from the firmware. > > Greg, I don't know if you've followed the conversation in earlier mail > threads, so I'll try to summarize it here. > > There are two layers involved: the VCHIQ layer, which has two clients > (audio and MMAL), and the MMAL layer, which has multiple clients > (camera, codec, ISP). The reason for this is that audio and mmal are > separate hardware, while camera, codec and ISP share some hardware > blocks. > > The VCHIQ layer provides a mailbox API to its clients to communicate > with the firmware, and the MMAL layer provides another API implemented > on top of the VCHIQ layer. Neither APIs offer a way to discover devices > dynamically (that's not a feature implemented by the firmware). We've > decided that implementing two buses would be overkill, so Umang went for > a single vchiq_bus_type. The only value it provides is to stop abusing > platform_device. That's pretty much it. > > Given the above explanation, do you still think the additional > complexity introduced by the vchiq bus type is worth it (it more or less > duplicates a small subset of the platform bus type implementation), and > are you fine with a single bus type, even if it doesn't exactly match > the firmware layers ? Yes, this is the correct way forward. I didn't review the changes yet, but I see you just gave a good first pass, so I'll wait for the next revision. thanks, greg k-h _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel