[PATCH 1/4] arm: mach-k3: Fix MMC macros

[Judith Mendez]

Hi Andrew, Anshul,

On 9/16/25 11:22 AM, Andrew Davis wrote:
> On 9/11/25 9:59 AM, Judith Mendez wrote:
>> Hi Anshul,
>>
>> On 9/11/25 12:11 AM, Anshul Dalal wrote:
>>> On Thu Sep 11, 2025 at 3:15 AM IST, Judith Mendez wrote:
>>>> For all K3 SoC's eMMC boot and MMCSD boot modes are supported. The 
>>>> macros
>>>> however, mix MMC device with the two bootmodes. Decouple the two types
>>>> of macros so that bootmodes can be identified with:
>>>> - BOOT_DEVICE_MMCSD
>>>> - BOOT_DEVICE_EMMC
>>>> according to devstat parsed boot mode values and on-board devices 
>>>> can be
>>>> identified with:
>>>> - BOOT_DEVICE_MMC1
>>>> - BOOT_DEVICE_MMC2
>>>> - BOOT_DEVICE_MMC2_2
>>>> according to arbitrary numbers mainly used to differentiate between 
>>>> eMMC
>>>> and SD card.
>>>>
>>>> Signed-off-by: Judith Mendez <jm at ti.com>
>>>> ---
>>>
>>> I guess the confusion here is how we are calling boot modes from devstat
>>> as well as the boot device as BOOT_DEVICE_*. Perhaps we should rename
>>> the former to DEVSTAT_BOOT_MODE_* or something along those lines.
>>>
>>> That would make the difference between a boot *mode* and a boot *device*
>>> more clear, DEVSTAT_BOOT_MODE_MMCSD or DEVSTATE_BOOT_MODE_EMMC would
>>> distinguish between SD or EMMC boot modes with BOOT_DEVICE_MMC*
>>> indicating the MMC port used.
>>>
>>> This would also allow use to only have the respective
>>> DEVSTAT_BOOT_MODE_* defined in each soc's headers with BOOT_DEVICE_*
>>> coming from arch/arm/include/asm/spl.h.
>>
>>
>> Right, I guess if
>>
>> BOOT_DEVICE_MMCSD
>> BOOT_DEVICE_EMMC
>>
>> Is still not clear enough, it would be a good idea to use:
>> DEVSTAT_BOOT_MODE_MMCSD
>> DEVSTAT_BOOT_MODE_EMMC
>>
>> Its only a real problem for MMC since we have the confusion with eMMC
>> boot and MMCSD boot and we mix the two as a result in
>> spl_mmc_boot_mode() and spl_boot_device().
>>
>>
>> Its not really an issue for other boot modes to warrant renaming all the
>> bootmodes, but I would like to make these macros as clear as possible in
>> this series since I plan to refactor spl_mmc_boot_mode() next.
>>
>> So lets hear if any one else has a strong opinion on this before
>> deciding on:
>>
>> DEVSTAT_BOOT_MODE_MMCSD
>> DEVSTAT_BOOT_MODE_EMMC
> 
> This looks like the correct way to label these as they are the content
> of the DEVSTAT register, this would also keep them from being confused
> with the U-Boot internal definitions for BOOT_MODE_* and BOOT_DEVICE_*.
> 
> But you should do it for all the DEVSTAT register defines, not just
> MMC and not just for Sitara, do it for all our K3 boards. It should
> be a simple rename patch to start. Then you can work to detangle
> "mode" from "device" for the MMC case as you are doing here.

I take it back, seems like this cannot be done, u-boot source requires
all the macros:
BOOT_DEVICE_SPI
BOOT_DEVICE_RAM
BOOT_DEVICE_UART
etc...

in order to even build.

Simply renaming the macros to style:
DEVSTAT_BOOT_MODE_SPI
DEVSTAT_BOOT_MODE_RAM
DEVSTAT_BOOT_MODE_UART

will not work without creating a duplicate:
#define BOOT_DEVICE_SPI		DEVSTAT_BOOT_MODE_SPI
#define BOOT_DEVICE_RAM		DEVSTAT_BOOT_MODE_RAM
#define BOOT_DEVICE_UART	DEVSTAT_BOOT_MODE_UART
or similar logic

So basically we would be doubling the size of all spl.h files.

In reality there is only confusion with MMC device/bootmodes,
we do not to rename every single boot modes/boot device since
there is no real confusion there.

~ Judith


-