svn commit: r320844 - in head: etc/mtree include lib/libcam sys/amd64/conf sys/arm/broadcom/bcm2835 sys/arm/conf sys/arm/ti sys/cam sys/cam/mmc sys/cam/scsi sys/conf sys/dev/mmc sys/dev/sdhci sys/m...
Warner Losh
imp at bsdimp.com
Sun Jul 9 20:49:58 UTC 2017
On Sun, Jul 9, 2017 at 2:40 PM, Warner Losh <imp at bsdimp.com> wrote:
>
>
> On Sun, Jul 9, 2017 at 12:42 PM, Marius Strobl <marius at freebsd.org> wrote:
>
>> On Sun, Jul 09, 2017 at 04:57:24PM +0000, Warner Losh wrote:
>> > Author: imp
>> > Date: Sun Jul 9 16:57:24 2017
>> > New Revision: 320844
>> > URL: https://svnweb.freebsd.org/changeset/base/320844
>> >
>> > Log:
>> > An MMC/SD/SDIO stack using CAM
>> >
>> > Implement the MMC/SD/SDIO protocol within a CAM framework. CAM's
>> > flexible queueing will make it easier to write non-storage drivers
>> > than the legacy stack. SDIO drivers from both the kernel and as
>> > userland daemons are possible, though much of that functionality will
>> > come later.
>>
>> At least with a non-MMCCAM kernel, with this revision in place I get
>> an endless storm of "unexpected" SDHCI_INT_CARD_INT interrupts during
>> boot. Apparently this is due to the fact that sdhci(4) now enables
>> these interrupts, but sdhci_generic_intr() neither actually handles
>> them nor clears them from intmask.
>>
>
> OK. I'll look into it. Since I don't have an SDHCI card in the system I
> tested it in, I never saw these...
>
Looking at the code, the problem is obvious. It looks like it came in on a
late commit to the mmccam integration branch. I'll revert which should
solve your problem. Looking at my notes and test systems, I did test this
on a NUC, but it was an older version w/o the patch I just reverted. Sorry
for the hassle. r320850
> Btw., were mmc.ko and mmcsd.ko disconnected on purpose with this commit?
>
>
> No, I'll reconnect.
>
This has been done. r320849
Warner
More information about the svn-src-all
mailing list