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 B1A28C47404 for ; Fri, 4 Oct 2019 13:22:36 +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 56B2B207FF for ; Fri, 4 Oct 2019 13:22:36 +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="Se0jZQdB"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="u1lHSxU+" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 56B2B207FF 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 1iGNXI-0007ZT-65; Fri, 04 Oct 2019 09:22:20 -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 1iGNXF-0007ZL-LM for kernelnewbies@kernelnewbies.org; Fri, 04 Oct 2019 09:22:18 -0400 Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 3159F21D51; Fri, 4 Oct 2019 09:22:14 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute6.internal (MEProxy); Fri, 04 Oct 2019 09:22:14 -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=et1jiypIvoRIn6VGbwW4P3qasdv 0G1Vo4jIc7E9vC/4=; b=Se0jZQdBKUEJ2k6RyaaKsrTAex4Wj0XlVR0LZXy8p82 /KnC8kgHwgENuVQsNADsFOiPSDVkbk946ZMVYj4/TNzWyLnwe0JBqyogC9iwFXH0 glODTemteNFvtDjG4Nmm6fNE5I9A7KEoPGWClEOzC/kvmJLySewJiLERdh66jTe6 CfnB87VAn7OYpkhv+e4cQO4tWYBLwqAPACzfG5TvMK1YuYfN9TMN667ByPfI2Buq KcAz329hOAVgeIBWZdzjmyUFs5GKOwUqEo8SyeWALL1bi1C+NU8DH7L1/Z71no9d pBSpve8N+rs1qvNcxpZlgPGNXkLc5WETCEOYEsRSvsw== 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=et1jiy pIvoRIn6VGbwW4P3qasdv0G1Vo4jIc7E9vC/4=; b=u1lHSxU+Jeebbsf23u7KVV 1Q4Icwh6xwX7SMCxO9Splv1YJAVgPAPRvtWR9pXSLCllP8HjW+X96hO6FKk/ax/U I+zr3az2scTFpHPRuKfRNftbRVOrTCLRvJbGuqQpjjO4OIHNaehxZdZCkuT1guhV yolQ+R1XoTG29SxCxinoHa/Kh8DNeWSIrThielafE+ILyOJxU5qyVTSNp8c53ZoS /MnqVpjakFBq59kM67wdMZaMcPIlFWwvbd5k55Jq9RrVe/SrZAErs1S7ORNfjsQx 5LPoVzQTBkl1gdK1W+dpm/9heVfd0pFQOUnkl589lfFGtUzzbGXuQWDzyB9imhhg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrhedugdehiecutefuodetggdotefrodftvf 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 33A6FD6005D; Fri, 4 Oct 2019 09:22:13 -0400 (EDT) Date: Fri, 4 Oct 2019 15:22:10 +0200 From: Greg KH To: Luca Ceresoli Subject: Re: Remote I/O bus Message-ID: <20191004132210.GA714804@kroah.com> References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: 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 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. good luck! greg k-h _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies