Re: Realtek RTS525A SD card reader

[raul....@iki.fi]

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.

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.


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...@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hacke...@freebsd.org"

[Warner Losh]

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

[Eric van Gyzen]

On 04/01/2018 02:06, Warner Losh wrote:
> 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.

This mmc part was helpful, since I know nothing about this interface.
Thanks!

Eric

[Raul Becker]

Hi,

yes, thanks for the quick list on what needs to be done!
This helped me a ton as well as the arch-handbook.
I got the probe to match my device (for now) and attach
that initializes the the device as you suggested with
freebsd bus resources. It even detects on kldload presence
of a sdcard in the slot and reports it in dmesg log. :)
But this is still far from anything usable.

Just wanted ask if there is any risk that I end up destroying my
sd-card device? Like there are some functions in the rtsx driver
where the voltages are being changed and also clock hz too.
I dont haven't included those functions that do voltage and
clock changes yet.

--
Raul Becker