All of lore.kernel.org
 help / color / mirror / Atom feed
From: Judith Mendez <jm@ti.com>
To: Andrew Davis <afd@ti.com>, Anshul Dalal <anshuld@ti.com>,
	Tom Rini <trini@konsulko.com>
Cc: Manorit Chawdhry <m-chawdhry@ti.com>,
	Vignesh Raghavendra <vigneshr@ti.com>, Bryan Brattlof <bb@ti.com>,
	Jayesh Choudhary <j-choudhary@ti.com>,
	Moteen Shah <m-shah@ti.com>, Udit Kumar <u-kumar1@ti.com>,
	<u-boot@lists.denx.de>
Subject: Re: [PATCH 1/4] arm: mach-k3: Fix MMC macros
Date: Tue, 16 Sep 2025 12:11:53 -0500	[thread overview]
Message-ID: <ec4eaab6-2903-4d4f-932c-8bad6d06fd39@ti.com> (raw)
In-Reply-To: <9c1b1344-b6fb-4ad4-aaec-1b187e1cd27d@ti.com>

Hi Andrew,

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@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.


If more than one person says it then it must be true. (:
Will send out v2 with that change.

~ Judith

  reply	other threads:[~2025-09-16 17:12 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-10 21:45 [PATCH 0/4] General MMC fixes for K3 Judith Mendez
2025-09-10 21:45 ` [PATCH 1/4] arm: mach-k3: Fix MMC macros Judith Mendez
2025-09-11  4:38   ` Kumar, Udit
2025-09-11 14:48     ` Judith Mendez
2025-09-15 11:35       ` Moteen Shah
2025-09-15 18:31         ` Judith Mendez
2025-09-11  5:11   ` Anshul Dalal
2025-09-11 14:59     ` Judith Mendez
2025-09-16 16:22       ` Andrew Davis
2025-09-16 17:11         ` Judith Mendez [this message]
2025-09-16 22:35         ` Judith Mendez
2025-09-17  3:41           ` Anshul Dalal
2025-09-17 16:06             ` Judith Mendez
2025-09-17 16:48               ` Andrew Davis
2025-09-18 18:00                 ` Judith Mendez
2025-09-15 11:40   ` Moteen Shah
2025-09-15 18:02     ` Judith Mendez
2025-09-15 14:22   ` Wadim Egorov
2025-09-15 18:09     ` Judith Mendez
2025-09-10 21:45 ` [PATCH 2/4] configs: am62px_evm_r5_defconfig: Add support eMMC boot config Judith Mendez
2025-09-10 21:45 ` [PATCH 3/4] configs: am62px/j722s: Remove non-spl HS400 support at r5 stage Judith Mendez
2025-09-11 10:32   ` Moteen Shah
2025-09-10 21:45 ` [PATCH 4/4] configs: j722s_evm_a53_defconfig: Disable eMMC HS400 Judith Mendez
2025-09-11  4:15   ` Kumar, Udit
2025-09-11 14:30     ` Judith Mendez
2025-09-11 14:45       ` Kumar, Udit
2025-09-11 15:14         ` Judith Mendez
2025-09-11 10:33   ` Moteen Shah

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ec4eaab6-2903-4d4f-932c-8bad6d06fd39@ti.com \
    --to=jm@ti.com \
    --cc=afd@ti.com \
    --cc=anshuld@ti.com \
    --cc=bb@ti.com \
    --cc=j-choudhary@ti.com \
    --cc=m-chawdhry@ti.com \
    --cc=m-shah@ti.com \
    --cc=trini@konsulko.com \
    --cc=u-boot@lists.denx.de \
    --cc=u-kumar1@ti.com \
    --cc=vigneshr@ti.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.