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
Mon Jul 10 01:37:32 UTC 2017


On Sun, Jul 9, 2017 at 4:37 PM, Marius Strobl <marius at freebsd.org> wrote:

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


Sure. The patch failed 100% to apply, so I applied it by hand (there's on >
80 character line that I left that way on purpose because (a) the way you
chunked it up was worse than before and (b) most of it should be changed to
use other macros so it isn't so ugly and I left the CAM related comments in
for easiler grepping). That should get rid of the worst of the
re-introduced offenders. That's what happens when work collides...

I'll commit in a few, after I fix the module compilation errors...

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

Yea, I have one laying around for other reasons as well... Mine don't have
eMMC in them, but do have a SD slot...

Warner


More information about the svn-src-all mailing list