Searched hist:343504 (Results 1 - 9 of 9) sorted by relevance
| /freebsd-11-stable/sys/arm/nvidia/ | ||
| H A D | tegra_sdhci.c | diff 343504 Sun Jan 27 19:12:03 MST 2019 marius MFC: r342634 (partial) o Don't allocate resources for SDMA in sdhci(4) if the controller or the front-end doesn't support SDMA or the latter implements a platform- specific transfer method instead. While at it, factor out allocation and freeing of SDMA resources to sdhci_dma_{alloc,free}() in order to keep the code more readable when adding support for ADMA variants. o Base the size of the SDMA bounce buffer on MAXPHYS up to the maximum of 512 KiB instead of using a fixed 4-KiB-buffer. With the default MAXPHYS of 128 KiB and depending on the controller and medium, this reduces the number of SDHCI interrupts by a factor of ~16 to ~32 on sequential reads while an increase of throughput of up to ~84 % was seen. Front-ends for broken controllers that only support an SDMA buffer boundary of a specific size may set SDHCI_QUIRK_BROKEN_SDMA_BOUNDARY and supply a size via struct sdhci_slot. According to Linux, only - unsupported in stable/11 anyway - Qualcomm MSM-type SDHCI controllers are affected by this, though. Requested by: Shreyank Amartya (unconditional bump to 512 KiB) o Introduce a SDHCI_DEPEND macro for specifying the dependency of the front-end modules on the sdhci(4) one and bump the module version of sdhci(4) to 2 via an also newly introduced SDHCI_VERSION in order to ensure that all components are in sync WRT struct sdhci_slot. o In sdhci(4): - Make pointers const were applicable, and - replace a few device_printf(9) calls with slot_printf() for consistency. |
| /freebsd-11-stable/sys/dev/sdhci/ | ||
| H A D | sdhci_fdt.c | diff 343504 Sun Jan 27 19:12:03 MST 2019 marius MFC: r342634 (partial) o Don't allocate resources for SDMA in sdhci(4) if the controller or the front-end doesn't support SDMA or the latter implements a platform- specific transfer method instead. While at it, factor out allocation and freeing of SDMA resources to sdhci_dma_{alloc,free}() in order to keep the code more readable when adding support for ADMA variants. o Base the size of the SDMA bounce buffer on MAXPHYS up to the maximum of 512 KiB instead of using a fixed 4-KiB-buffer. With the default MAXPHYS of 128 KiB and depending on the controller and medium, this reduces the number of SDHCI interrupts by a factor of ~16 to ~32 on sequential reads while an increase of throughput of up to ~84 % was seen. Front-ends for broken controllers that only support an SDMA buffer boundary of a specific size may set SDHCI_QUIRK_BROKEN_SDMA_BOUNDARY and supply a size via struct sdhci_slot. According to Linux, only - unsupported in stable/11 anyway - Qualcomm MSM-type SDHCI controllers are affected by this, though. Requested by: Shreyank Amartya (unconditional bump to 512 KiB) o Introduce a SDHCI_DEPEND macro for specifying the dependency of the front-end modules on the sdhci(4) one and bump the module version of sdhci(4) to 2 via an also newly introduced SDHCI_VERSION in order to ensure that all components are in sync WRT struct sdhci_slot. o In sdhci(4): - Make pointers const were applicable, and - replace a few device_printf(9) calls with slot_printf() for consistency. |
| H A D | fsl_sdhci.c | diff 343504 Sun Jan 27 19:12:03 MST 2019 marius MFC: r342634 (partial) o Don't allocate resources for SDMA in sdhci(4) if the controller or the front-end doesn't support SDMA or the latter implements a platform- specific transfer method instead. While at it, factor out allocation and freeing of SDMA resources to sdhci_dma_{alloc,free}() in order to keep the code more readable when adding support for ADMA variants. o Base the size of the SDMA bounce buffer on MAXPHYS up to the maximum of 512 KiB instead of using a fixed 4-KiB-buffer. With the default MAXPHYS of 128 KiB and depending on the controller and medium, this reduces the number of SDHCI interrupts by a factor of ~16 to ~32 on sequential reads while an increase of throughput of up to ~84 % was seen. Front-ends for broken controllers that only support an SDMA buffer boundary of a specific size may set SDHCI_QUIRK_BROKEN_SDMA_BOUNDARY and supply a size via struct sdhci_slot. According to Linux, only - unsupported in stable/11 anyway - Qualcomm MSM-type SDHCI controllers are affected by this, though. Requested by: Shreyank Amartya (unconditional bump to 512 KiB) o Introduce a SDHCI_DEPEND macro for specifying the dependency of the front-end modules on the sdhci(4) one and bump the module version of sdhci(4) to 2 via an also newly introduced SDHCI_VERSION in order to ensure that all components are in sync WRT struct sdhci_slot. o In sdhci(4): - Make pointers const were applicable, and - replace a few device_printf(9) calls with slot_printf() for consistency. |
| H A D | sdhci_acpi.c | diff 343504 Sun Jan 27 19:12:03 MST 2019 marius MFC: r342634 (partial) o Don't allocate resources for SDMA in sdhci(4) if the controller or the front-end doesn't support SDMA or the latter implements a platform- specific transfer method instead. While at it, factor out allocation and freeing of SDMA resources to sdhci_dma_{alloc,free}() in order to keep the code more readable when adding support for ADMA variants. o Base the size of the SDMA bounce buffer on MAXPHYS up to the maximum of 512 KiB instead of using a fixed 4-KiB-buffer. With the default MAXPHYS of 128 KiB and depending on the controller and medium, this reduces the number of SDHCI interrupts by a factor of ~16 to ~32 on sequential reads while an increase of throughput of up to ~84 % was seen. Front-ends for broken controllers that only support an SDMA buffer boundary of a specific size may set SDHCI_QUIRK_BROKEN_SDMA_BOUNDARY and supply a size via struct sdhci_slot. According to Linux, only - unsupported in stable/11 anyway - Qualcomm MSM-type SDHCI controllers are affected by this, though. Requested by: Shreyank Amartya (unconditional bump to 512 KiB) o Introduce a SDHCI_DEPEND macro for specifying the dependency of the front-end modules on the sdhci(4) one and bump the module version of sdhci(4) to 2 via an also newly introduced SDHCI_VERSION in order to ensure that all components are in sync WRT struct sdhci_slot. o In sdhci(4): - Make pointers const were applicable, and - replace a few device_printf(9) calls with slot_printf() for consistency. |
| H A D | sdhci.h | diff 343504 Sun Jan 27 19:12:03 MST 2019 marius MFC: r342634 (partial) o Don't allocate resources for SDMA in sdhci(4) if the controller or the front-end doesn't support SDMA or the latter implements a platform- specific transfer method instead. While at it, factor out allocation and freeing of SDMA resources to sdhci_dma_{alloc,free}() in order to keep the code more readable when adding support for ADMA variants. o Base the size of the SDMA bounce buffer on MAXPHYS up to the maximum of 512 KiB instead of using a fixed 4-KiB-buffer. With the default MAXPHYS of 128 KiB and depending on the controller and medium, this reduces the number of SDHCI interrupts by a factor of ~16 to ~32 on sequential reads while an increase of throughput of up to ~84 % was seen. Front-ends for broken controllers that only support an SDMA buffer boundary of a specific size may set SDHCI_QUIRK_BROKEN_SDMA_BOUNDARY and supply a size via struct sdhci_slot. According to Linux, only - unsupported in stable/11 anyway - Qualcomm MSM-type SDHCI controllers are affected by this, though. Requested by: Shreyank Amartya (unconditional bump to 512 KiB) o Introduce a SDHCI_DEPEND macro for specifying the dependency of the front-end modules on the sdhci(4) one and bump the module version of sdhci(4) to 2 via an also newly introduced SDHCI_VERSION in order to ensure that all components are in sync WRT struct sdhci_slot. o In sdhci(4): - Make pointers const were applicable, and - replace a few device_printf(9) calls with slot_printf() for consistency. |
| H A D | sdhci_pci.c | diff 343504 Sun Jan 27 19:12:03 MST 2019 marius MFC: r342634 (partial) o Don't allocate resources for SDMA in sdhci(4) if the controller or the front-end doesn't support SDMA or the latter implements a platform- specific transfer method instead. While at it, factor out allocation and freeing of SDMA resources to sdhci_dma_{alloc,free}() in order to keep the code more readable when adding support for ADMA variants. o Base the size of the SDMA bounce buffer on MAXPHYS up to the maximum of 512 KiB instead of using a fixed 4-KiB-buffer. With the default MAXPHYS of 128 KiB and depending on the controller and medium, this reduces the number of SDHCI interrupts by a factor of ~16 to ~32 on sequential reads while an increase of throughput of up to ~84 % was seen. Front-ends for broken controllers that only support an SDMA buffer boundary of a specific size may set SDHCI_QUIRK_BROKEN_SDMA_BOUNDARY and supply a size via struct sdhci_slot. According to Linux, only - unsupported in stable/11 anyway - Qualcomm MSM-type SDHCI controllers are affected by this, though. Requested by: Shreyank Amartya (unconditional bump to 512 KiB) o Introduce a SDHCI_DEPEND macro for specifying the dependency of the front-end modules on the sdhci(4) one and bump the module version of sdhci(4) to 2 via an also newly introduced SDHCI_VERSION in order to ensure that all components are in sync WRT struct sdhci_slot. o In sdhci(4): - Make pointers const were applicable, and - replace a few device_printf(9) calls with slot_printf() for consistency. |
| H A D | sdhci.c | diff 343504 Sun Jan 27 19:12:03 MST 2019 marius MFC: r342634 (partial) o Don't allocate resources for SDMA in sdhci(4) if the controller or the front-end doesn't support SDMA or the latter implements a platform- specific transfer method instead. While at it, factor out allocation and freeing of SDMA resources to sdhci_dma_{alloc,free}() in order to keep the code more readable when adding support for ADMA variants. o Base the size of the SDMA bounce buffer on MAXPHYS up to the maximum of 512 KiB instead of using a fixed 4-KiB-buffer. With the default MAXPHYS of 128 KiB and depending on the controller and medium, this reduces the number of SDHCI interrupts by a factor of ~16 to ~32 on sequential reads while an increase of throughput of up to ~84 % was seen. Front-ends for broken controllers that only support an SDMA buffer boundary of a specific size may set SDHCI_QUIRK_BROKEN_SDMA_BOUNDARY and supply a size via struct sdhci_slot. According to Linux, only - unsupported in stable/11 anyway - Qualcomm MSM-type SDHCI controllers are affected by this, though. Requested by: Shreyank Amartya (unconditional bump to 512 KiB) o Introduce a SDHCI_DEPEND macro for specifying the dependency of the front-end modules on the sdhci(4) one and bump the module version of sdhci(4) to 2 via an also newly introduced SDHCI_VERSION in order to ensure that all components are in sync WRT struct sdhci_slot. o In sdhci(4): - Make pointers const were applicable, and - replace a few device_printf(9) calls with slot_printf() for consistency. |
| /freebsd-11-stable/sys/arm/ti/ | ||
| H A D | ti_sdhci.c | diff 343504 Sun Jan 27 19:12:03 MST 2019 marius MFC: r342634 (partial) o Don't allocate resources for SDMA in sdhci(4) if the controller or the front-end doesn't support SDMA or the latter implements a platform- specific transfer method instead. While at it, factor out allocation and freeing of SDMA resources to sdhci_dma_{alloc,free}() in order to keep the code more readable when adding support for ADMA variants. o Base the size of the SDMA bounce buffer on MAXPHYS up to the maximum of 512 KiB instead of using a fixed 4-KiB-buffer. With the default MAXPHYS of 128 KiB and depending on the controller and medium, this reduces the number of SDHCI interrupts by a factor of ~16 to ~32 on sequential reads while an increase of throughput of up to ~84 % was seen. Front-ends for broken controllers that only support an SDMA buffer boundary of a specific size may set SDHCI_QUIRK_BROKEN_SDMA_BOUNDARY and supply a size via struct sdhci_slot. According to Linux, only - unsupported in stable/11 anyway - Qualcomm MSM-type SDHCI controllers are affected by this, though. Requested by: Shreyank Amartya (unconditional bump to 512 KiB) o Introduce a SDHCI_DEPEND macro for specifying the dependency of the front-end modules on the sdhci(4) one and bump the module version of sdhci(4) to 2 via an also newly introduced SDHCI_VERSION in order to ensure that all components are in sync WRT struct sdhci_slot. o In sdhci(4): - Make pointers const were applicable, and - replace a few device_printf(9) calls with slot_printf() for consistency. |
| /freebsd-11-stable/sys/arm/broadcom/bcm2835/ | ||
| H A D | bcm2835_sdhci.c | diff 343504 Sun Jan 27 19:12:03 MST 2019 marius MFC: r342634 (partial) o Don't allocate resources for SDMA in sdhci(4) if the controller or the front-end doesn't support SDMA or the latter implements a platform- specific transfer method instead. While at it, factor out allocation and freeing of SDMA resources to sdhci_dma_{alloc,free}() in order to keep the code more readable when adding support for ADMA variants. o Base the size of the SDMA bounce buffer on MAXPHYS up to the maximum of 512 KiB instead of using a fixed 4-KiB-buffer. With the default MAXPHYS of 128 KiB and depending on the controller and medium, this reduces the number of SDHCI interrupts by a factor of ~16 to ~32 on sequential reads while an increase of throughput of up to ~84 % was seen. Front-ends for broken controllers that only support an SDMA buffer boundary of a specific size may set SDHCI_QUIRK_BROKEN_SDMA_BOUNDARY and supply a size via struct sdhci_slot. According to Linux, only - unsupported in stable/11 anyway - Qualcomm MSM-type SDHCI controllers are affected by this, though. Requested by: Shreyank Amartya (unconditional bump to 512 KiB) o Introduce a SDHCI_DEPEND macro for specifying the dependency of the front-end modules on the sdhci(4) one and bump the module version of sdhci(4) to 2 via an also newly introduced SDHCI_VERSION in order to ensure that all components are in sync WRT struct sdhci_slot. o In sdhci(4): - Make pointers const were applicable, and - replace a few device_printf(9) calls with slot_printf() for consistency. |
Completed in 140 milliseconds