From owner-freebsd-current@freebsd.org Mon Dec 10 20:20:04 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 AB0DB13326BF for ; Mon, 10 Dec 2018 20:20:04 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound2m.ore.mailhop.org (outbound2m.ore.mailhop.org [54.149.155.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0FA166D338 for ; Mon, 10 Dec 2018 20:20:03 +0000 (UTC) (envelope-from ian@freebsd.org) ARC-Seal: i=1; a=rsa-sha256; t=1544473178; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=cKvpfFl0l/OT0wf4qIYBmpiI/EfvS/gdGlft+KhUfUVXFN2QB68wVnwuE/4s0jMrlDkBtQdPggXxZ iY9jtE8bQoHRWGEvQ5+EwhNiPOOBhp7jhqA5x4D/Bo2ylJ1w8xj3W35KE0jG5cRR5CjeGq+y4vUAuk Lh9GLGnXGQwSjdDfqloTlO0o/TVQiFLunE+BNPSllZILV61P+dgmKzKUEFmVf3gnP2P0m1h6WX4aLQ xnDK+7sTbfCVkk7Kzh+8vp9I1pa326PROBKPrk0CWGbbDFEtDrIDjzk09ftQQsj2f+JF9wvZKRnwkr NmSTxI9Yz29XwQT6koRvsH2cQhmBjUg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:cc:to:from:subject:message-id:dkim-signature:from; bh=UDjn2m1vV076ah38h3mYEfCyEaaVehZcdNm70DbKQUc=; b=qRPQbos5ByykELsHaL8uCWhkqCZpQPlEtE+R0NZFaEAH85M+eY77hwc9Hit4ozOUJV3H63VmoSdvD k11SBbpKfwJXgi/EybLBdS2h9r0MABun4p83hkBtihAH2KcH7b4nvsy0qriOJRkYcoAG2fFZT0uJUj Hl1GiBrsndyDlfRy5PYIgR+0OFVYQlPkVDBBe26hDnH2jmSbHmUc9GzNerwXeYNix+kHppHp4S2q2Y 3n2WiwiO/SZ65/W8y7ZpxQa+rouvJp5iycWmGHbtwnfZmskQOJ/xnssyIIZ2ntjWgrqq1Pv7Kl7LyP S10IB7cMWkg1AOUVczgOszBR3v5btMw== ARC-Authentication-Results: i=1; outbound4.ore.mailhop.org; spf=softfail smtp.mailfrom=freebsd.org smtp.remote-ip=67.177.211.60; dmarc=none header.from=freebsd.org; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:cc:to:from:subject:message-id:from; bh=UDjn2m1vV076ah38h3mYEfCyEaaVehZcdNm70DbKQUc=; b=w47A8TciuoWxK01rLOIkKOsa/un0j12TTKherJ1tZTIKkAdQ01SxUE/R4uJjbj7kwGsmmxvYZExM2 sijn7YEwH2Q0BAsyuwFruPD2L6PRCUxGdHRrCRzzjz9ha+A+80548yb4OBtl0AAey5H3tl1VyGHkxD eZ+EcLds7LOW8vTryg5Hfj1nNDOpqsAlK+IQ0ec+wk+pIbtd0NmGCAR56/5hwiaOoG2mXDVAjm9QFx eDxZEJRuAGb2hZ7NYg+zx8e+XEwDCHL93umngifA25BZcMmNxwaZMgSjxJhdUYgci/9cHs1m+jMYre +EHrtR8thcYlwfZvbU6qCmcRMPqEK7g== X-MHO-RoutePath: aGlwcGll X-MHO-User: e9cf6def-fcb8-11e8-befd-af03bedce89f X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound4.ore.mailhop.org (Halon) with ESMTPSA id e9cf6def-fcb8-11e8-befd-af03bedce89f; Mon, 10 Dec 2018 20:19:36 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id wBAKJsm6072764; Mon, 10 Dec 2018 13:19:54 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1544473194.1860.340.camel@freebsd.org> Subject: Re: Composite PCI devices in FreeBSD (mfd in Linux) From: Ian Lepore To: Anthony Jenkins , John Baldwin , FreeBSD CURRENT Cc: Gleb Popov <6yearold@gmail.com> Date: Mon, 10 Dec 2018 13:19:54 -0700 In-Reply-To: References: Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 0FA166D338 X-Spamd-Result: default: False [-2.99 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; NEURAL_HAM_LONG(-1.00)[-0.999,0]; NEURAL_HAM_SHORT(-0.99)[-0.987,0]; ASN(0.00)[asn:16509, ipnet:54.148.0.0/15, country:US] 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 20:20:04 -0000 On Mon, 2018-12-10 at 14:42 -0500, Anthony Jenkins wrote: > 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. > If this is just another "bus" an ig4 instance can attach to, I'd think the recipe would be to add another DRIVER_MODULE() to ig4_iic.c naming ig4_lpss as the parent. Then add a new ig4_lpss.c modeled after the existing pci and acpi attachment code, its DRIVER_MODULE() would name lpss as parent, and its probe routine would return BUS_PROBE_NOWILDCARD (attach only if specifically added by the parent). Then there would be a new lpss driver that does the resource managment stuff mentioned above, and if it detects configuration for I2C it would do a device_add_child(lpssdev, "ig4_lpss", -1) followed by bus_generic_attach(). There'd be no need for identify() in the child in that case, I think. But take jhb's word over mine on any of this stuff, he's been around since the days when these mechanisms were all invented, whereas I tend to cut and paste that bus and driver attachment stuff in semi-ignorance when I'm working on drivers. -- Ian > > 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 > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd > .org" >