From owner-freebsd-hackers@freebsd.org Sun Apr 1 07:06:26 2018 Return-Path: Delivered-To: freebsd-hackers@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 601CEF54DC1 for ; Sun, 1 Apr 2018 07:06:26 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F118A77EF2 for ; Sun, 1 Apr 2018 07:06:25 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x233.google.com with SMTP id d5so14959602iob.9 for ; Sun, 01 Apr 2018 00:06:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=DqoZ2ULNHu7P004Bg0QBQLuTu5RWlKxQ1b9qpJe3P7M=; b=KKec1KV24LhN/O7JnGwId0q115pJPSD5Lu906uUdtW7hq6VtkkGQsHG9zkIMqPGqZm 2Ah+Xii+1OcDhsgSpKjYLh3E0m/1nOBXLQ7+7Yp8JWWXCGzdVpJMf9qb0jjPe8SDA126 eXxf+fLbLf6p3rDXx8/aWXArVoDgLfYwg2uLzW9o4LStOIbQoM9eXxpWaU6sEkC1Ptbx pvWmMZzu4C9QP0/GAcIkHtmaK1Wbx5dGmW1QV+rlThZh8yrzzXFnsWOJm3U3fjJPlHn7 b9IjCT9XZJl6zeZaqb9MnTSjW4HNC4WXhWTyREirAKeSNOSw1oRe9raZpEEBu3kz0sto 3XZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=DqoZ2ULNHu7P004Bg0QBQLuTu5RWlKxQ1b9qpJe3P7M=; b=Oq5XKBazEWk4JDBgPpEmiCfZi045CQVbc98KLspfA/lJvcFOS8kkFz0BkS9T1T1/FS pvKDQa3vW+LVLoVBkfidwHnP+fQRVrjP5ty253Dl186wXIqBL3dIC/dKdlaK5UT1/aqn U94JRNEHARSIUWFmhMA9jRHvh9laFJ6wpWrs8Qq1wFng+EJzvyZG7FymX2CrUAPRLoyx 8cRGJVD+pEMb3jUioykmzDrUn9hGL+9Pn113pb7UwEzfRkzso6mKqml4221sJ/Cbn6/c gcx+M3p4Vp+kB4LBh7wFBcDesqjNxnzsJ29ogvNZthGmuTnhAb7g9KbCImskhQCioAde t8ag== X-Gm-Message-State: AElRT7Frn4z8Z9KDL0eUlq7QOiVltoyNEEc/mqpPvqtf0gGx3VAjexdW xJ0e1youl/HBjbQ17G8v6E721kQX0YcUD7v5QoeDWQ== X-Google-Smtp-Source: AIpwx48mdnZe0dfY1yo/PsVVBTewBiDKIil1BhrFsm2y1hS3MGDqVfpYNIUY2e0n6RBaDquWKWNssXkA2xlDwuylUfQ= X-Received: by 10.107.58.134 with SMTP id h128mr4449700ioa.299.1522566384992; Sun, 01 Apr 2018 00:06:24 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.203.196 with HTTP; Sun, 1 Apr 2018 00:06:23 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: <20180401034514.t4idseuyg53gap7g@tardis> References: <20180401034514.t4idseuyg53gap7g@tardis> From: Warner Losh Date: Sun, 1 Apr 2018 01:06:23 -0600 X-Google-Sender-Auth: O1hrrkoEztxQQVen5CkTl61pCGM Message-ID: Subject: Re: Realtek RTS525A SD card reader To: raul.becker@iki.fi Cc: "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Apr 2018 07:06:26 -0000 On Sat, Mar 31, 2018 at 9:45 PM, wrote: > Hi, > > I somehow got the same idea just recently that it would be a fun learning > experi > ence to try to port rtsx from OpenBSD to FreeBSD and getting at the same > time mo > re familiar with C. I practically have zero experience in writing drivers. > > But I think that the relevant OpenBSD driver files are rtsx.c rtsxvar.h > and rtsx > reg.h. Browsing through the FreeBSD src/sys/dev directories for any of the > curre > ct drivers to see how the drivers are meant to be implemented in FreeBSD I > found > src/sys/dev/sdhci as a possible candidate. There are already driver > modules for > the sdhci.c which are atleast sdhci_pci.c, sdhci_fdt.c and sdhci_acpi.c. > They a > ll follow same organization where in the end they map the DEVMETHODs what > the sd > hci expects to get I believe. The sdhci_pci.c was abit overwhelming with > all the > quirks so I thought that maybe rtsx driver could be instead a separate > driver m > odule like sdhci_rtsx.c for example. This separation I think would be > helpful es > pecially when not too familiar with C and because it looks of like the > task does > not seem to be that straight forward to do either. The other mmc drivers > are mo > stly spread out and many are for arm boards. > You don't want a sdhci_rtsz.c. sdhci is the name of a protocol to talk to a device. PCI is the bus attachment. rtsz is a different protocol to talk to a device, so it should be it's own driver. > It would be sweet if someone could confirm that src/sys/dev/sdhci is a > good loca > tion where to try to implement a driver module and/or point at the > right(er) dir > ection. > sdhci is a good, full function driver. However, it handles a lot of odd-ball exceptions and edge cases common in a popular interface that's chasing an evolving standard, so it may be a bit overwhelming. Here's a quick outline. You'll need a rtsz_pci.c that handles claiming the device (probe) and initializing it (attach). Most of the initialization will be the same as OpenBSD, though the glue into the system is somewhat different between OpenBSD and FreeBSD (which is why I'm suggesting rtsz_pci.c to help keep that walled off). busdma is similar, but the details are different between the systems. They've evolved from a common ancestor, though, so that's good. Bus_space is the same, but the resource allocations will be different (see bus_alloc_resource). Interrupt handling will be different. The interface you want to look for is the mmcbr_if.m inteface. In sdhci, these routines implement the mmc interface: sdhci_pci.c: DEVMETHOD(mmcbr_update_ios, sdhci_generic_update_ios), sdhci_pci.c: DEVMETHOD(mmcbr_switch_vccq, sdhci_generic_switch_vccq), sdhci_pci.c: DEVMETHOD(mmcbr_tune, sdhci_generic_tune), sdhci_pci.c: DEVMETHOD(mmcbr_retune, sdhci_generic_retune), sdhci_pci.c: DEVMETHOD(mmcbr_request, sdhci_generic_request), sdhci_pci.c: DEVMETHOD(mmcbr_get_ro, sdhci_generic_get_ro), sdhci_pci.c: DEVMETHOD(mmcbr_acquire_host, sdhci_generic_acquire_host), sdhci_pci.c: DEVMETHOD(mmcbr_release_host, sdhci_generic_release_host), rtsz will almost certainly need it's own versions of these routines (which is why I suggest having your own driver will be simpler: otherwise each of these routines would be if (rtsz) do_rtsz_stuff(); else do_sdhci_stuff(); which won't end well and would be uncomittable to FreeBSD. You can see how other chips implement these methods by grepping for them in the tree. You may not need a tune/retune if rtsz doesn't support the latest, fastest cards, for example. Switch vccq may not be needed either. update_ios will be needed, and request is needed. Acquire and release host may be able to be done as a dummy routine if there's only one slot. I know this is a super-quick gloss of what needs to be done. Warner > My device: > > none2@pci0:2:0:0: class=0xff0000 card=0x221417aa chip=0x522710ec > rev=0x01 > hdr=0x00 > vendor = 'Realtek Semiconductor Co., Ltd.' > device = 'RTS5227 PCI Express Card Reader' > > -- > Raul Becker > > p.s. I hope this time I got the In-Reply-To header right. > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" >