Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

drivers: sdhc: add driver support for emmc host controller #61108

Merged
merged 3 commits into from Sep 29, 2023

Conversation

najumon1980
Copy link
Collaborator

@najumon1980 najumon1980 commented Aug 3, 2023

add driver support for emmc host controller (eMMC 5.1 compliant ). Following are some of the key supported features:

  • Supported Mode: HS400, HS200, DDR50, SDR104, SDR50, SDR25 and SDR12
  • DMA support: Both SDMA and ADMA supported
  • Data Width: 1bit, 4bit and 8Bit
  • Support Interrupt driven as well as polled mode

@najumon1980 najumon1980 marked this pull request as ready for review August 4, 2023 04:14
@zephyrbot zephyrbot added area: Devicetree Binding PR modifies or adds a Device Tree binding area: Disk Access labels Aug 4, 2023
@jhedberg jhedberg self-requested a review August 4, 2023 06:09
}
#endif

static int emmc_reset(const struct device *dev)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not familiar with this hardware, but it seems like emmc_reset is being used to reset the state of the emmc card itself. Currently the SD subsystem toggles power to the SD card at init to reset it. For emmc, would it be useful to also call sdhc_hw_reset during the SD init sequence, so the emmc card state state is reset even during a soft reset?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe power cycle of card is expected to be invoke via mmc stack using sdhc_set_io() as part of boot time or as part of error recovery and driver shall provide only low level interface for them.

The Zephyr mmc.h mentioned following comments as well.
"sdhc_hw_reset() Used when the SDHC has encountered an error. Resetting the SDHC controller should clear all errors on the SDHC, but does not necessarily reset I/O settings to boot (this can be done with ref sdhc_set_io)"

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is correct- sdhc_set_io is intended to reset I/O settings to boot by toggling card power. However, perhaps we need to reevalute when sdhc_rw_reset is called in the SD subsystem, since eMMC cards may not have independent power control

What I'm wondering here is if you feel adding a call to sdhc_hw_reset during the SD initialization phase would be useful for eMMC cards- since they cannot always toggle power.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am really worried about adding it since it seems to be WA for me. My suggestion is that let the stack do such error handling scenario.

drivers/sdhc/emmc_host.c Outdated Show resolved Hide resolved
drivers/sdhc/emmc_host.c Outdated Show resolved Hide resolved
drivers/sdhc/emmc_host.c Outdated Show resolved Hide resolved
drivers/sdhc/emmc_host.c Outdated Show resolved Hide resolved
drivers/sdhc/emmc_host.c Outdated Show resolved Hide resolved
drivers/sdhc/Kconfig.emmc Outdated Show resolved Hide resolved
@@ -59,3 +59,13 @@ properties:
type: boolean
description: |
The host controller supports HS400 at 1.8V

mmc-dw-8bit:
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This commit needs to be first in the PR, since the emmc driver depends on these properties.

Also, please use a title similar to the following:

dts: bindings: sdhc: add dts entry for sdhc bus width

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This commit is before driver commit.

subsys/sd/sd.c Outdated Show resolved Hide resolved
subsys/sd/sd.c Outdated Show resolved Hide resolved
decsny
decsny previously requested changes Aug 18, 2023
Copy link
Member

@decsny decsny left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

requesting change to compatible string

subsys/sd/sd.c Show resolved Hide resolved
dts/bindings/sdhc/sdhc.yaml Outdated Show resolved Hide resolved
dts/bindings/sdhc/emmc-host.yaml Outdated Show resolved Hide resolved
Copy link
Collaborator

@jfischer-no jfischer-no left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is not really clear what "native driver" means in this context.

drivers/sdhc/emmc_host.c Outdated Show resolved Hide resolved
@najumon1980 najumon1980 changed the title drivers: sdhc: add native driver support for emmc host controller drivers: sdhc: add driver support for emmc host controller Sep 12, 2023
@danieldegrasse
Copy link
Collaborator

Currently our scope limited eMMC and my suggestion is as someone start port this driver on their platform and test on SD card as well then then can enhance the features/scope.

Understood- if the scope is limited to eMMC on the alder lake platform, then I would like to see file and Kconfig names reflect this. We can leave the C function names untouched, as those aren't really user facing, but I want it to be clear that this driver may implement the SD host controller specification, but it is only designed to function with the eMMC controller on the alder lake platform.

If we want to keep Kconfig and file names generic, then I would like this driver to be generic enough to (at a minimum) support the SD and eMMC stack. Ideally we would validate this driver on additional host controllers, but I am not aware of another one that complies fully with the SDHC spec.

@najumon1980
Copy link
Collaborator Author

Currently our scope limited eMMC and my suggestion is as someone start port this driver on their platform and test on SD card as well then then can enhance the features/scope.

Understood- if the scope is limited to eMMC on the alder lake platform, then I would like to see file and Kconfig names reflect this. We can leave the C function names untouched, as those aren't really user facing, but I want it to be clear that this driver may implement the SD host controller specification, but it is only designed to function with the eMMC controller on the alder lake platform.

If we want to keep Kconfig and file names generic, then I would like this driver to be generic enough to (at a minimum) support the SD and eMMC stack. Ideally we would validate this driver on additional host controllers, but I am not aware of another one that complies fully with the SDHC spec.

Agree and updated file name and Kconfig to intel specific

subsys/sd/sd.c Outdated
}

/* Set to maximum voltage support by Host controller */
card->card_voltage = voltage;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, just noticed this- you don't need to assign to card->card_voltage here, since you already do below

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was existing logic and I updated to maximum HC supported voltage instead of pre-defined SD_VOL_3_3_V. It seems the initial logic assume card->card_voltage will get update after reset

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure I follow- The issue I am highlighting is that card->card_voltage is being set twice in this function, and it only needs to be set once (on line 163). The initial logic here set card_voltage once on line 163, and your changes introduce a second assignment to it on line 144. Is there a reason we need this assignment?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

removed the duplicate code

drivers/sdhc/Kconfig.intel Outdated Show resolved Hide resolved
drivers/sdhc/Kconfig.intel Outdated Show resolved Hide resolved

config INTEL_EMMC_HOST_ADMA_DESC_SIZE
int "EMMC host controller ADMA Descriptor size"
default 32
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this be dependent on INTEL_EMMC_HOST_ADMA?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since we use IS_ENABLED this might cause build error during compile time

Copy link
Member

@jhedberg jhedberg Sep 27, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since we use IS_ENABLED this might cause build error during compile time

It seems you're then also waisting memory, since struct emmc_data will always contain the desc_table even if ADMA is not enabled. It might be worth looking into different ways of fixing this. Some options come to mind:

  • Stop using IS_ENABLED
  • Refactor the code so the memory is allocated in a separate struct
  • Use something like this:
#ifdef CONFIG_INTEL_EMMC_HOST_ADMA_DESC_SIZE
#define ADMA_DESC_SIZE CONFIG_INTEL_EMMC_HOST_ADMA_DESC_SIZE
#else
#define ADMA_DESC_SIZE 0
#endif

For the record, the current code works fine, so this could also be done as a follow-up PR (especially considering that time is running low on getting a new driver merged before the feature freeze)

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

updated as per your suggestion


mmc-dw-4bit:
type: boolean
bus-width:
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You introduce these properties in a prior commit, then modify them here. Please instead add the final version of this property (the bus width prop) in the initial commit where you modify the SDHC yaml

Also, is this property part of the IP, or determined by how the eMMC is connected? What I'm asking here is does the IP always support 8 bit bus width, but if only 4 data pins are routed than the user would be expected to set bus-width=4? Or do some instances of the IP only support 4 data pins?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Moved to original commit. Also regarding the bus width, Intel IP support both 4 and 8 bit and if someone design their board with only 4bit interface then they can update dts accordingly to limit driver settings.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, then can't we use the bus-width property on the MMC node itself, rather than setting this at the IP level? https://github.com/zephyrproject-rtos/zephyr/blob/main/dts/bindings/sd/zephyr%2Cmmc-disk.yaml#L12

If so, we should drop this change from the PR

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

agree and updated the code

@najumon1980
Copy link
Collaborator Author

@danieldegrasse I updated/respond to your comments, could you please have a look ? I would like this PR to be merged before code freeze which is this Friday

@najumon1980 najumon1980 added this to the v3.5.0 milestone Sep 26, 2023
@najumon1980
Copy link
Collaborator Author

@danieldegrasse @jhedberg updated as per you review comment, please have a look

@najumon1980
Copy link
Collaborator Author

@decsny I update the PR as per you comments, please have a look

jhedberg
jhedberg previously approved these changes Sep 28, 2023
@decsny
Copy link
Member

decsny commented Sep 28, 2023

@najumon1980

please see #59886 about bus width property, your PR conflicts conceptually with what is in tree currently

@danieldegrasse danieldegrasse dismissed decsny’s stale review September 28, 2023 18:26

Dismissing review on behalf of @decsny, as they are out of town and request has been addressed

@danieldegrasse
Copy link
Collaborator

@najumon1980- just to be clear- please address my comment about the duplicate assignment to card->card_voltage as well as the bus-width DT property. Other than that I am ok to merge this PR.

add check for maximum voltage supported by hc before apply card voltage.

Signed-off-by: Najumon B.A <najumon.ba@intel.com>
add host controller driver support for emmc version 5.1.
The driver expose zephyr sdhc api interface for emmc host controller.

Signed-off-by: Najumon B.A <najumon.ba@intel.com>
add DTS entry for enable eMMC support on Intel Alder lake platforms

Signed-off-by: Najumon B.A <najumon.ba@intel.com>
@najumon1980
Copy link
Collaborator Author

@najumon1980- just to be clear- please address my comment about the duplicate assignment to card->card_voltage as well as the bus-width DT property. Other than that I am ok to merge this PR.

@danieldegrasse I updated the PR and pls have a look

@carlescufi carlescufi merged commit dfec79c into zephyrproject-rtos:main Sep 29, 2023
20 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: Devicetree Binding PR modifies or adds a Device Tree binding area: Disk Access platform: X86 x86 and x86-64
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

7 participants