From owner-freebsd-current@freebsd.org Mon Dec 10 19:52:44 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8860E1331D84 for ; Mon, 10 Dec 2018 19:52:44 +0000 (UTC) (envelope-from Scoobi_doo@yahoo.com) Received: from sonic314-20.consmr.mail.gq1.yahoo.com (sonic314-20.consmr.mail.gq1.yahoo.com [98.137.69.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D4F2B6C5C2 for ; Mon, 10 Dec 2018 19:52:43 +0000 (UTC) (envelope-from Scoobi_doo@yahoo.com) X-YMail-OSG: CHutdGkVM1laVhZFaDF5XRxJmtdLnVaSYr0GgqJ90cfBLO75a6JoW1T3rUNn.zH QE4f1SnkGmKyYCIdhpZ1R80QDYK8IJI9XYRZ0qp6PrxA_tg3ncpleqTTFYZarv5px9eJDQEnASE7 2OgA54Mj4MfeKhDk4PivXFqDCqRN.IBSRP9BZzfs1Dc.6o1snFgwPRvZEuT.uE3mzQI82LnN7kvZ tqfKLOmzN72En1wNTNBX9eMsJXj.M3zb4xqoDnFLmGO1reZRHzmgCBOxsPK9ZEkX6JPAeetQcFIw A20fb.g51bfDkHESqCYZq6jmyI5.F4pQlPhPnvEHz5YfnjZZKwGrFOLozUUqORNOFXJFopWknEMj IkYD_dxGVkgXqVd2Am2mB_gFKm2RhxXsGPbxA6oBM5sesLsvvJ8TLRaNCjHrIrY.kpOHkRKTNR.s rMbJsQQ1yIPRLu.m7pUgiHZx5.6lZvSRKhPdmo9ZHFs8XgqnwZ1GjuVtYQACnx_B_Y4KDozpoI8P 7I3n9LALFBDprXyd9OIhAo7dP9rzysrc7lBjR0QhGjvLcjrlQ71rz80hO5Dbp9MlSe_swEfg.Nyq cvjls4eoGZf.Akb0UX.RP.IJHoO.6HTsEoxJsOLzwePTMW.PBPlNsM6hFz5SYEGDRe17AttyqJw3 p3FEb8OSx7vlxXQAktGnHDw3htglfpkgq8X_kra6auKj6gVdwlh4a4vXyCREeG4xsiozkrJzFkXj skxePCyjr_7YNdxLRNNaCN1xuTKuDYQmtrYVdkDyhK6BX7xptuIEowiW1dJEun2xg43d1JeB3zac SjQa9.66V56Vq_Kto1q0iucbxOKdamepzB32fDzoPTCx2z0PHv5YiktHmUIoD5JTEbXHwkdFhYSe rfagJscWT_j2QU0lNMblnYtlmmdWU_osJR1TtgYkj3k9eBgOak95R0vI_5.Vn.8YwqGDAfZljgHY 6_UTtTS9uCnyaay6xcRK1alihqB6kFtTVgnIO7DBgOSwsQ0n.MPtOGfzpykbQ4T2sM2HyTFAaQfr Gp1vz3qNbnyKe82FF0Al9uXRF6oj8bqE- Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.gq1.yahoo.com with HTTP; Mon, 10 Dec 2018 19:52:36 +0000 Received: from 172.58.7.39 (EHLO [192.168.43.50]) ([172.58.7.39]) by smtp423.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 0db2cea477405d2b7ee786c7a18f438c; Mon, 10 Dec 2018 19:42:26 +0000 (UTC) Subject: Re: Composite PCI devices in FreeBSD (mfd in Linux) To: John Baldwin , FreeBSD CURRENT Cc: Gleb Popov <6yearold@gmail.com> References: From: Anthony Jenkins Message-ID: Date: Mon, 10 Dec 2018 14:42:24 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Rspamd-Queue-Id: D4F2B6C5C2 X-Spamd-Result: default: False [2.87 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; FREEMAIL_FROM(0.00)[yahoo.com]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(1.41)[ip: (5.93), ipnet: 98.137.64.0/21(0.67), asn: 36647(0.53), country: US(-0.09)]; NEURAL_SPAM_MEDIUM(0.89)[0.889,0]; NEURAL_SPAM_SHORT(0.97)[0.972,0]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MX_GOOD(-0.01)[cached: mta6.am0.yahoodns.net]; RCVD_IN_DNSWL_NONE(0.00)[83.69.137.98.list.dnswl.org : 127.0.5.0]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_SPAM_LONG(0.61)[0.614,0]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/21, country:US]; FREEMAIL_CC(0.00)[gmail.com]; MID_RHS_MATCH_FROM(0.00)[] X-Rspamd-Server: mx1.freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2018 19:52:44 -0000 On 12/10/18 1:26 PM, John Baldwin wrote: > On 12/10/18 9:00 AM, Anthony Jenkins wrote: >> Hi all, >> >> I'm trying to port an Intel PCI I2C controller from Linux to FreeBSD. >> Linux represents this device as an MFD (multi-function device), meaning >> it has these "sub-devices" that can be handed off to other drivers to >> actually attach devices to the system.  The Linux "super" PCI device is >> the intel-lpss-pci.c, and the "sub" device is i2c-designware-platdrv.c, >> which represents the DesignWare driver's "platform" attachment to the >> Linux system.  FreeBSD also has a DesignWare I2C controller driver, >> ig4(4), but it only has PCI and ACPI bus attachment implementations. >> >> I have a port of the Linux intel-lpss driver to FreeBSD, but now I'm >> trying to figure out the best way to give FreeBSD's ig4(4) driver access >> to my lpss(4) device.  I'm thinking I could add an ig4_lpss.c describing >> the "attachment" of an ig4(4) to an lpss(4).  Its probe() method would >> scan the "lpss" devclass for devices, and its attach() method would >> attach itself as a child to the lpss device and "grab" the portion of >> PCI memory and the IRQ that the lpss PCI device got. >> >> Is this the "FreeBSD Way (TM)" of handling this type of device?  If not, >> can you recommend an existing FreeBSD driver I can model my code after? >> If my approach is acceptable, how do I fully describe the ig4(4) >> device's attachment to the system?  Is simply making it a child of >> lpss(4) sufficient?  It's "kind of" a PCI device (it is controlled via >> access to a PCI memory region and an IRQ), but it's a sub-device of an >> actual PCI device (lpss(4)) attached to PCI. >> How would my ig4_lpss attachment get information from the lpss(4) driver >> about what it probed? > There are some existing PCI drivers that act as "virtual" busses that attach > child devices. For example, vga_pci.c can have drm, agp, and acpi_video > child devices. There are also some SMBus drivers that are also PCI-ISA > bridges and thus create separate child devices. Yeah I was hoping to avoid using video PCI devices as a model, as complex as they've gotten recently.  I'll check out its bus glue logic. > For a virtual bus like this, you need to figure out how your child devices > will be enumerated. A simple way is to let child devices use an identify > routine that looks at each parent device and decides if a child device > for that driver makes sense. It can then add a child device in the > identify routine. Really an lpss parent PCI parent device can only have the following: * one of {I2C, UART, SPI} controller * optionally an IDMA64 controller so I was thinking a child ig4(4) device would attach to lpss iff * the lpss device detected an I2C controller * no other ig4 device is already attached I haven't fiddled with identify() yet, will look at that tonight. > To handle things like resources, you want to have > bus_*_resource methods that let your child device use the normal bus_* > functions to allocate resources. At the simplest end you don't need to > permit any sharing of BARs among multiple children so you can just proxy > the requests in the "real" PCI driver. (vga_pci.c does this) If you need > the BARs to be shared you have a couple of options such as just using a > refcount on the BAR resource but letting multiple devices allocate the same > BAR. If you want to enforce exclusivity (once a device allocates part of > a BAR then other children shouldn't be permitted to do so), then you will > need a more complicated solution. Another homework assignment for me - bus_*_resource methods. There are 2 or 3 mutually-exclusive sub-regions in the single memory BAR: * 0x000 - 0x200 : I2C sub-device registers * 0x200 - 0x300 : lpss and I2C sub-device registers * 0x800 - 0x1000 : IDMA sub-device registers (optional) The only child (ig4(4)) of a given parent lpss device would at most need to share access to the middle region, if at all. > Hopefully that gives you a starting point? Oh definitely, thanks!  If successful, and the effort to support I2C HID devices also comes in, it should enable a bunch of laptops to use more stuff like touchscreens and touchpads that are currently broken in FreeBSD (I'm pretty sure one of my laptop's 2 lpss devices is a touchscreen I2C device). Anthony