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...

[Marius Strobl]

On Sun, Jul 09, 2017 at 02:49:56PM -0600, Warner Losh wrote:
> 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.

Thanks, I can confirm that r320850 allows booting again. Compared to
pre-r320844, sdhci(4) now still is incredibly noisy in the non-MMCCAM
path, though. Can we get this removed again or at least put under
sdhci_debug, along with removing the memory overhead for the non-MMCCAM
case and some of the style(9) violations/inconsistencies (re-)introduced,
using something like the attached patch?

> 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

Well, I might have given a different impression, but I don't actually
care about NUCs as such; they are just a relatively cheap way of
obtaining various combinations of Intel MMC/SDXC controllers and eMMC
chips and are an acceptable loss should I ever manage to kill an eMMC
chip during development.

Marius

-------------- next part --------------
A non-text attachment was scrubbed...
Name: sdhci.diff
Type: text/x-diff
Size: 5377 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/svn-src-head/attachments/20170710/69966fb3/attachment.diff>