Re: sdhc(4): no 0V one some Intel
On Tue, Nov 19, 2019 at 10:44:54AM +0100, Patrick Wildt wrote: > > Hi, Hi Patrick, > on some GPD Pocket mlarkin@ has the eMMC doesn't come up. One issue > is that we shouldn't go to 0V on some/most(?) Intel controllers. This > only adds it for his machine, but I know that the Appollo Lake versions > might also work if added to this check. But unless verified I'll not > add it. This makes mlarkin@'s machine work, even though it's utterly > slow. That would be the next thing to fix... probably low clocks or > doesn't use 8-bit. James Hastings has a similar diff for Intel Apollo Lake and Gemini Lake: https://www.mail-archive.com/tech@openbsd.org/msg51024.html It did work on my Apollo Lake box. > ok? > > Patrick > > diff --git a/sys/dev/pci/sdhc_pci.c b/sys/dev/pci/sdhc_pci.c > index d1b6688f573..dd6bc79c29c 100644 > --- a/sys/dev/pci/sdhc_pci.c > +++ b/sys/dev/pci/sdhc_pci.c > @@ -127,6 +127,11 @@ sdhc_pci_attach(struct device *parent, struct device > *self, void *aux) > PCI_PRODUCT(pa->pa_id) == PCI_PRODUCT_ENE_SDCARD) > sc->sc.sc_flags |= SDHC_F_NOPWR0; > > + /* Some Intel controllers break if set to 0V bus power. */ > + if (PCI_VENDOR(pa->pa_id) == PCI_VENDOR_INTEL && > + PCI_PRODUCT(pa->pa_id) == PCI_PRODUCT_INTEL_100SERIES_LP_EMMC) > + sc->sc.sc_flags |= SDHC_F_NOPWR0; > + > /* Some RICOH controllers need to be bumped into the right mode. */ > if (PCI_VENDOR(pa->pa_id) == PCI_VENDOR_RICOH && > (PCI_PRODUCT(pa->pa_id) == PCI_PRODUCT_RICOH_R5U822 || >
Re: sdhc(4): no 0V one some Intel
On Tue, Nov 19, 2019 at 10:44:54AM +0100, Patrick Wildt wrote: > Hi, > > on some GPD Pocket mlarkin@ has the eMMC doesn't come up. One issue > is that we shouldn't go to 0V on some/most(?) Intel controllers. This > only adds it for his machine, but I know that the Appollo Lake versions > might also work if added to this check. But unless verified I'll not > add it. This makes mlarkin@'s machine work, even though it's utterly > slow. That would be the next thing to fix... probably low clocks or > doesn't use 8-bit. > > ok? > Sure. And you get the handoff to fix the rest :) -ml > Patrick > > diff --git a/sys/dev/pci/sdhc_pci.c b/sys/dev/pci/sdhc_pci.c > index d1b6688f573..dd6bc79c29c 100644 > --- a/sys/dev/pci/sdhc_pci.c > +++ b/sys/dev/pci/sdhc_pci.c > @@ -127,6 +127,11 @@ sdhc_pci_attach(struct device *parent, struct device > *self, void *aux) > PCI_PRODUCT(pa->pa_id) == PCI_PRODUCT_ENE_SDCARD) > sc->sc.sc_flags |= SDHC_F_NOPWR0; > > + /* Some Intel controllers break if set to 0V bus power. */ > + if (PCI_VENDOR(pa->pa_id) == PCI_VENDOR_INTEL && > + PCI_PRODUCT(pa->pa_id) == PCI_PRODUCT_INTEL_100SERIES_LP_EMMC) > + sc->sc.sc_flags |= SDHC_F_NOPWR0; > + > /* Some RICOH controllers need to be bumped into the right mode. */ > if (PCI_VENDOR(pa->pa_id) == PCI_VENDOR_RICOH && > (PCI_PRODUCT(pa->pa_id) == PCI_PRODUCT_RICOH_R5U822 || >
sdhc(4): no 0V one some Intel
Hi, on some GPD Pocket mlarkin@ has the eMMC doesn't come up. One issue is that we shouldn't go to 0V on some/most(?) Intel controllers. This only adds it for his machine, but I know that the Appollo Lake versions might also work if added to this check. But unless verified I'll not add it. This makes mlarkin@'s machine work, even though it's utterly slow. That would be the next thing to fix... probably low clocks or doesn't use 8-bit. ok? Patrick diff --git a/sys/dev/pci/sdhc_pci.c b/sys/dev/pci/sdhc_pci.c index d1b6688f573..dd6bc79c29c 100644 --- a/sys/dev/pci/sdhc_pci.c +++ b/sys/dev/pci/sdhc_pci.c @@ -127,6 +127,11 @@ sdhc_pci_attach(struct device *parent, struct device *self, void *aux) PCI_PRODUCT(pa->pa_id) == PCI_PRODUCT_ENE_SDCARD) sc->sc.sc_flags |= SDHC_F_NOPWR0; + /* Some Intel controllers break if set to 0V bus power. */ + if (PCI_VENDOR(pa->pa_id) == PCI_VENDOR_INTEL && + PCI_PRODUCT(pa->pa_id) == PCI_PRODUCT_INTEL_100SERIES_LP_EMMC) + sc->sc.sc_flags |= SDHC_F_NOPWR0; + /* Some RICOH controllers need to be bumped into the right mode. */ if (PCI_VENDOR(pa->pa_id) == PCI_VENDOR_RICOH && (PCI_PRODUCT(pa->pa_id) == PCI_PRODUCT_RICOH_R5U822 ||
