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=-7.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=ham 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 D0151C47404 for ; Fri, 4 Oct 2019 15:10:22 +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 80DDD207FF for ; Fri, 4 Oct 2019 15:10:22 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 80DDD207FF Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=lucaceresoli.net Authentication-Results: mail.kernel.org; spf=fail smtp.mailfrom=kernelnewbies-bounces+kernelnewbies=archiver.kernel.org@kernelnewbies.org Received: from localhost ([::1] helo=shelob.surriel.com) by shelob.surriel.com with esmtp (Exim 4.92.2) (envelope-from ) id 1iGPDp-0003uG-GZ for kernelnewbies@archiver.kernel.org; Fri, 04 Oct 2019 11:10:21 -0400 Received: from hostingweb31-40.netsons.net ([89.40.174.40]) by shelob.surriel.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.2) (envelope-from ) id 1iGPC5-0001k0-G1 for kernelnewbies@kernelnewbies.org; Fri, 04 Oct 2019 11:08:33 -0400 Received: from [109.168.11.45] (port=54254 helo=[192.168.101.73]) by hostingweb31.netsons.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1iGPC3-006PxN-1A; Fri, 04 Oct 2019 17:08:31 +0200 Subject: Re: Remote I/O bus To: Greg KH References: <20191004132210.GA714804@kroah.com> <9f619831-f27e-447e-42ea-69227f7a31d0@lucaceresoli.net> <20191004145435.GA758347@kroah.com> From: Luca Ceresoli Message-ID: <442abb4b-3812-713c-67e9-9e76c45205e8@lucaceresoli.net> Date: Fri, 4 Oct 2019 17:08:30 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <20191004145435.GA758347@kroah.com> Content-Language: en-US X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - hostingweb31.netsons.net X-AntiAbuse: Original Domain - kernelnewbies.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - lucaceresoli.net X-Get-Message-Sender-Via: hostingweb31.netsons.net: authenticated_id: luca+lucaceresoli.net/only user confirmed/virtual account not confirmed X-Authenticated-Sender: hostingweb31.netsons.net: luca@lucaceresoli.net X-Source: X-Source-Args: X-Source-Dir: 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=archiver.kernel.org@kernelnewbies.org Hi Greg, On 04/10/19 16:54, Greg KH wrote: > 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. Sure, the driver logic wouldn't be touched. Only the read/write helpers and the entry point (I think I'd need two different probe functions, but again sharing most of their code). > Do you have a pointer to your existing code anywhere? One of the drivers I'm looking at is: https://github.com/Xilinx/linux-xlnx/blob/xilinx-v2019.1/drivers/media/platform/xilinx/xilinx-csi2rxss.c Yes, the read/write helpers are nicely isolated. However this sits in a vendor kernel that tends to change a lot from one release to another, so most changes on these drivers need to be re-done each time I upgrade the kernel. That's one of the reasons I would have preferred to not touch the driver at all. Thanks a lot, -- Luca _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies