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 X-Spam-Level: X-Spam-Status: No, score=-2.0 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0F275C47404 for ; Fri, 4 Oct 2019 14:54:58 +0000 (UTC) Received: from shelob.surriel.com (shelob.surriel.com [96.67.55.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 60CC42084D for ; Fri, 4 Oct 2019 14:54:57 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=kroah.com header.i=@kroah.com header.b="qRBEteCy"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="JhvBNlgW" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 60CC42084D Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=kroah.com Authentication-Results: mail.kernel.org; spf=fail smtp.mailfrom=kernelnewbies-bounces@kernelnewbies.org Received: from localhost ([::1] helo=shelob.surriel.com) by shelob.surriel.com with esmtp (Exim 4.92.2) (envelope-from ) id 1iGOyj-0001EJ-5q; Fri, 04 Oct 2019 10:54:45 -0400 Received: from out4-smtp.messagingengine.com ([66.111.4.28]) by shelob.surriel.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.2) (envelope-from ) id 1iGOyg-0001EC-62 for kernelnewbies@kernelnewbies.org; Fri, 04 Oct 2019 10:54:42 -0400 Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id B4D0D21FC1; Fri, 4 Oct 2019 10:54:39 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute6.internal (MEProxy); Fri, 04 Oct 2019 10:54:39 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kroah.com; h= date:from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=fm2; bh=R6Cskml7taKtg8Re5/8PQR3f2C5 vwEPlw9scIdlF8X4=; b=qRBEteCytUAhcPOpVxS8hL7aq6AJWL+RJzC0y4uMzq9 TYeMIH1XZnsEZWm4rtfLKPoZSOXwh2O3yz8tZ87CmIPc9eyfyUwZ+AcnL3KwjWXn Dpeoa7PycVDGmz8x+DXF6VIZQMq+OiE0ffQ/8za47Us5HR9fT1WgtnbV54+qbaiy wbb3z0t4vZ5MBtg1dYnJ9h80iBJdrJSwY9ciyxijuTRpB4JHreZZCS37yq/KWnga 5a7rjEseZhlPhHaWe27B/wI2DbvxdjwdvyYIZ5Vh1hKl9hYbGX3Sx2mwDfgHcHxP K4Zm3pgoRVuS9pIJqMHqYYzS2h/ZtIb/PcnPU7YBRvg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=R6Cskm l7taKtg8Re5/8PQR3f2C5vwEPlw9scIdlF8X4=; b=JhvBNlgWf2CQGxnkpXYuBQ G/EGMsS0JBO4Nqc3HAqwubV8DxUM8VOQkPT32uPtdDv4CgKSBAYowLrKnx3E8Swr Id0ux9aT3t42DAs0BWpOFmskW3kfz7bwjsbfxK1xwrjut6W1TX7l+vjkfOugK1rL BHfpcw8w31fX/lfhF3uu2tXNJDcUZCYDkjkDgbXGZKVb08ZeZpr0f+YgabeMfO8U +jPm0yXHvef7FwDgrc8zjbDDpoya4UzkzMVU3v5N43Oy7oJB6yLqpUq7GtWNk452 MZ0eKwX03fKeyi4Y87kfgfhICNUZSK62uUJTTR/2S12SZCgMJMUU4V1tutRx7dZw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrhedugdejiecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpeffhffvuffkfhggtggujggfsehttdertddtredvnecuhfhrohhmpefirhgvghcu mffjuceoghhrvghgsehkrhhorghhrdgtohhmqeenucfkphepkeefrdekiedrkeelrddutd ejnecurfgrrhgrmhepmhgrihhlfhhrohhmpehgrhgvgheskhhrohgrhhdrtghomhenucev lhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) by mail.messagingengine.com (Postfix) with ESMTPA id 9E7BF80062; Fri, 4 Oct 2019 10:54:38 -0400 (EDT) Date: Fri, 4 Oct 2019 16:54:35 +0200 From: Greg KH To: Luca Ceresoli Subject: Re: Remote I/O bus Message-ID: <20191004145435.GA758347@kroah.com> References: <20191004132210.GA714804@kroah.com> <9f619831-f27e-447e-42ea-69227f7a31d0@lucaceresoli.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <9f619831-f27e-447e-42ea-69227f7a31d0@lucaceresoli.net> User-Agent: Mutt/1.12.2 (2019-09-21) Cc: kernelnewbies@kernelnewbies.org X-BeenThere: kernelnewbies@kernelnewbies.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Learn about the Linux kernel List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: kernelnewbies-bounces@kernelnewbies.org On Fri, Oct 04, 2019 at 04:08:06PM +0200, Luca Ceresoli wrote: > Hi Greg, > > On 04/10/19 15:22, Greg KH wrote: > > On Fri, Oct 04, 2019 at 01:04:56PM +0200, Luca Ceresoli wrote: > >> Hi, > >> > >> on an embedded system I currently have a standard platform device: > >> > >> .-----. data .--------. > >> | CPU |--------| DEVICE | > >> '-----' bus '--------' > >> > >> The driver is a standard platform driver that uses ioread32() and > >> iowrite32() to access registers. > >> > >> So far, so good. > >> > >> Now in a new design I have the same device in an FPGA, external to the > >> SoC. The external FPGA is not reachable via an I/O bus, but via SPI (or > >> I2C). A microprocessor in the FPGA acts as a bridge: as an SPI client it > >> receives register read/write requests from the CPU, forwards them to the > >> devices on the in-FPGA data bus as a master, then sends back the replies > >> over SPI. > >> > >> SoC <- | -> FPGA > >> > >> .-----. data .---------. .--------. data .--------. > >> | CPU |---------| SPI CTL |-------| BRIDGE |---------| DEVICE | > >> '-----' bus A '---------' SPI '--------' bus B '--------' > >> > >> > >> What would be a proper way to model this in the Linux kernel? > >> > >> Of course I can hack the drivers to hijack them on SPI, but I'm trying > >> to solve the problem in a better way. IMO "a proper way" implies that > >> the platform driver does not need to be aware of the existence of the > >> bridge. > >> > >> Note: in the real case there is more than one device to handle. > >> > >> At first sight I think this should be modeled with a "bridge" device that: > >> > >> * is a SPI device > >> * implements a "platform bus" where regular platform devices can be > >> instantiated, similar to a "simple-bus" > > > > Yes, make your own "bus", and have the SPI device be your "host > > controller" in that it bridges the SPI bus to your "FPGA bus". > > > > The driver model is set up for this, it should be not that complex to do > > so. If you have specific questions, just let me know. "Clean" examples > > of what to do is the greybus code as that's probably one of the newest > > busses to be added to the kernel. > > > >> In device tree terms: > >> > >> &amba { /* data bus A in picture */ > >> > >> spi0: spi@42000000 { > >> reg = <0x42000000 0x1000>; > >> #address-cells = <1>; > >> > >> io-over-spi-bridge@1 { /* data bus B */ > >> reg = <1>; /* slave select pin 1 */ > >> compatible = "linux,io-over-spi-bridge"; > >> #address-cells = <1>; > >> #size-cells = <1>; > >> > >> mydevice@4000 { > >> /* 1 kB I/O space at 0x4000 on bus B */ > >> reg = <0x4000 0x1000>; > >> }; > >> }; > >> }; > >> }; > >> > >> The io-over-spi driver is supposed to request allocation of a virtual > >> memory area that: > >> 1. is as large as the address space on bus B > >> 2. is __iomem (non cached, etc) > >> 3. is not mapped on the physical CPU address space (bus A) > >> 4. page faults at every read/write access, triggering a callback > >> that starts an SPI transaction, waits for the result and returns > > > > I don't think you can map memory to be "on an SPI bus", unless you have > > support for that in your hardware controller itself. Trying to map > > memory in this way is odd, just treat the devices out off the bus as > > "devices that need messages sent to them", and you should be fine. It's > > not memory-mapped iomemory, so don't think of it that way. > > If I got you correctly, this means I cannot reuse the existing device > drivers unmodified as I was hoping to. You are switching from a "ioread/write" to "all data goes across an SPI link". No, you can't reuse the existing drivers, but you can modify them to abstract out the "read/write data" functions to be transport agnositic. > They won't be 'struct platform_device' instances anymore, they will > become 'struct mybus_device' instances. And as such they won't be > allowed to call ioread32() / iowrite32(), but will have to call > mybus_ioread32() and mybus_iowrite32(). Correct? Yes. But, if you do it right, the majority of your driver is the logic to control the hardware, and interact with whatever other subsystem those devices talk to. Read/Write data and the bus the device talks to should just be a tiny shim that you can split out into a separate module/file. Do you have a pointer to your existing code anywhere? thanks, greg k-h _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies