Realtek RTS525A SD card reader

[Warner Losh]

On Sat, Mar 31, 2018 at 9:45 PM, <raul.becker at iki.fi> 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 at 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 at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"
>