Shaunak Datar commented on a discussion on freebsd/sys/arm/broadcom/bcm2835/bcm2835_sdhci.c: https://gitlab.rtems.org/rtems/pkg/rtems-libbsd/-/merge_requests/158#note_157697 > + * interrupts (or SDHCI error interrupts) until the IO is done. > + */ > + if (idx == 0) { > + bus_dmamap_sync(sc->sc_dma_tag, sc->sc_dma_map, sync_op); > + > + slot->intmask &= ~DATA_XFER_MASK; > + bcm_sdhci_write_4(sc->sc_dev, slot, SDHCI_SIGNAL_ENABLE, > + slot->intmask); > + } > + > + /* > + * Start the DMA transfer. Only programming errors (like failing to > + * allocate a channel) cause a non-zero return from bcm_dma_start(). > + */ > + err = bcm_dma_start(sc->sc_dma_ch, psrc, pdst, len); > + KASSERT((err == 0), ("bcm2835_sdhci: failed DMA start")); We have set the `static int bcm2835_sdhci_pio_mode = 1;` hence in the attach function the `SDHCI_PLATFORM_TRANSFER` is not set and the dma route is never used. The `freebsd/sys/dev/sdhci/sdhci.c` does not call `SDHCI_PLATFORM_START_TRANSFER`, here the function registered in `bcm_sdhci_methods` is the `bcm_sdhci_start_transfer()` so `bcm_sdhci_start_transfer` and in turn `bcm_sdhci_start_dma` is never called. -- View it on GitLab: https://gitlab.rtems.org/rtems/pkg/rtems-libbsd/-/merge_requests/158#note_157697 You're receiving this email because of your account on gitlab.rtems.org. Unsubscribe from this thread: https://gitlab.rtems.org/-/sent_notifications/5-9lu39lmdswi07knm96kv6ppnh-k/unsubscribe | Manage all notifications: https://gitlab.rtems.org/-/profile/notifications | Help: https://gitlab.rtems.org/help
_______________________________________________ bugs mailing list [email protected] http://lists.rtems.org/mailman/listinfo/bugs
