public inbox for linux-mediatek@lists.infradead.org
 help / color / mirror / Atom feed
From: "Axe Yang (杨磊)" <Axe.Yang@mediatek.com>
To: "Wenbin Mei (梅文彬)" <Wenbin.Mei@mediatek.com>,
	"conor+dt@kernel.org" <conor+dt@kernel.org>,
	"Chaotian Jing (井朝天)" <Chaotian.Jing@mediatek.com>,
	"robh@kernel.org" <robh@kernel.org>,
	"matthias.bgg@gmail.com" <matthias.bgg@gmail.com>,
	"ulf.hansson@linaro.org" <ulf.hansson@linaro.org>,
	"krzk+dt@kernel.org" <krzk+dt@kernel.org>,
	"AngeloGioacchino Del Regno"
	<angelogioacchino.delregno@collabora.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-mediatek@lists.infradead.org"
	<linux-mediatek@lists.infradead.org>,
	"linux-mmc@vger.kernel.org" <linux-mmc@vger.kernel.org>,
	"Andy-ld Lu (卢东)" <Andy-ld.Lu@mediatek.com>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"Yong Mao (毛勇)" <yong.mao@mediatek.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"Qingliang Li (黎晴亮)" <Qingliang.Li@mediatek.com>
Subject: Re: [PATCH 1/2] dt-bindings: mmc: mtk-sd: add single burst switch
Date: Thu, 27 Mar 2025 02:48:37 +0000	[thread overview]
Message-ID: <8958413b4138d815d582927f7702b35ffc20f122.camel@mediatek.com> (raw)
In-Reply-To: <3572d6e2-8950-4937-bed5-624bf5bde7f3@collabora.com>

On Tue, 2025-03-25 at 11:20 +0100, AngeloGioacchino Del Regno wrote:
> External email : Please do not click links or open attachments until
> you have verified the sender or the content.
> 
> 
> Il 25/03/25 03:41, Axe Yang (杨磊) ha scritto:
> > Hi Angelo,
> > 
> > Any comment on this :D
> > 
> 
> Check inline reply below....
> 
> > Regards,
> > Axe
> > 
> > On Wed, 2025-03-12 at 14:30 +0800, axe.yang wrote:
> > > On Tue, 2025-03-11 at 10:47 +0100, AngeloGioacchino Del Regno
> > > wrote:
> > > > External email : Please do not click links or open attachments
> > > > until
> > > > you have verified the sender or the content.
> > > > 
> > > > 
> > > > Il 07/03/25 07:59, Axe Yang (杨磊) ha scritto:
> > > > > On Thu, 2025-03-06 at 10:19 +0100, AngeloGioacchino Del Regno
> > > > > wrote:
> > > > > > External email : Please do not click links or open
> > > > > > attachments
> > > > > > until
> > > > > > you have verified the sender or the content.
> > > > > > 
> > > > > > 
> > > > > > Il 06/03/25 09:48, Axe Yang ha scritto:
> > > > > > > Add 'mediatek,disable-single-burst' setting. This
> > > > > > > property
> > > > > > > can
> > > > > > > be
> > > > > > > used to switch bus burst type, from single burst to INCR,
> > > > > > > which
> > > > > > > is
> > > > > > > determined by the bus type within the IP. Some versions
> > > > > > > of
> > > > > > > the
> > > > > > > IP
> > > > > > > are using AXI bus, thus this switch is necessary as
> > > > > > > 'single'
> > > > > > > is
> > > > > > > not
> > > > > > > the burst type supported by the bus.
> > > > > > > 
> > > > > > > Signed-off-by: Axe Yang <axe.yang@mediatek.com>
> > > > > > 
> > > > > > I am mostly sure that this is not something to put in
> > > > > > devicetree,
> > > > > > but
> > > > > > as
> > > > > > platform data for specific SoC(s), as much as I'm mostly
> > > > > > sure
> > > > > > that
> > > > > > all of
> > > > > > the instances of the MSDC IP in one SoC will be *all* using
> > > > > > either
> > > > > > single
> > > > > > or INCR.
> > > > > 
> > > > > No, actually MSDC IPs in one SoC are using different
> > > > > versions.
> > > > > Usually MSDC1 (index from 1) is used as eMMC host, the left
> > > > > hosts
> > > > > are
> > > > > used as SD/SDIO hosts. They have similar designs, but there
> > > > > are
> > > > > still
> > > > > difference.
> > > > > 
> > > > > > 
> > > > > > So, I think I know the answer but I'll still ask just to be
> > > > > > extremely
> > > > > > sure:
> > > > > > 
> > > > > > is there any MediaTek SoC that has different IP versions
> > > > > > for
> > > > > > different MSDC
> > > > > > instances, and that hence require single burst on one
> > > > > > instance
> > > > > > and
> > > > > > INCR on
> > > > > > another instance?
> > > > > 
> > > > > Yes. Actually every SoC has different IP versions for eMMC
> > > > > and
> > > > > SD/SDIO
> > > > > host as I said.
> > > > > e.g. For MT8168, signel burst bit should be set to 1 for eMMC
> > > > > Host,
> > > > > but
> > > > > 0 for SD/SDIO Host.
> > > > > 
> > > > > > 
> > > > > > And if there is - is there a pattern? Is it always SDIO
> > > > > > requiring
> > > > > > INCR or
> > > > > > always eMMC/SD requiring it?
> > > > > > 
> > > > > > 
> > > > > 
> > > > > No, there is no pattern. Both eMMC and SD/SDIO hosts need to
> > > > > be
> > > > > configured base on IP version. There is no binding
> > > > > relationship
> > > > > between
> > > > > eMMC/SD/SDIO and the burst type. eMMC burst type might be
> > > > > INCR or
> > > > > single, same as SD/SDIO.
> > > > > 
> > > > 
> > > > Okay but if there are different IP versions, and AXI/AHB is
> > > > determined
> > > > by the IP version, why aren't you parsing the MAIN_VER/ECO_VER
> > > > registers of
> > > > the MSDC IP to check whether to use INCR or SINGLE?
> > > 
> > > 
> > > To address your concerns, I had further discussions with the
> > > designer.
> > > Their response was that the bus type and IP version are not bound
> > > together. This contradicts my previous statements, and I
> > > apologize
> > > for
> > > that.
> > > According to the designer's feedback, I must say that the single
> > > burst
> > > setting is indeed tied to the IC, but the granularity is such
> > > that it
> > > needs to be set individually for each host.
> > > Given the large number of ICs Mediatek currently has, adding
> > > burst
> > > type
> > > information for each host to the driver's compatible structure
> > > would
> > > mean adding hundreds(maybe thousands :() of lines to the driver
> > > for
> > > the
> > > compatible structures for *all previous SoCs* (currently there
> > > are
> > > only
> > > 13 compatible structures, and they can be reuse by new SoC). This
> > > approach seems very cumbersome.
> > > 
> > > So I still believe that placing this setting in the DTS is a more
> > > appropriate approach.
> > > 
> 
> Hello Axe,
> 
> sorry for the wait - this email fell through the cracks and I didn't
> see
> it at all, so thank you for the ping.
> 
> Unfortunately, I don't think that this would be acceptable from a
> devicetree and/or
> bindings standpoint, but then you don't really need to modify the
> pdata for all of
> the currently supported SoCs to declare false, as false==0, which is
> the default.
> 
> But maybe there's another way out of this.
> 
> You said that this modification is done because some controllers are
> under AXI and
> some others are under AHB... I was doing some cleanups to this driver
> and doing so
> made me check a couple of things....
> 
> When a MSDC controller is under AXI, there will be configuration for
> that in other
> registers - specifically, I'm wondering if the EMMC50_CFG2 register
> can be used to
> check if we are under an AHB to AXI wrapper or not.
> 
> The idea is to read this register (offset 0x21c), [27:24] AXI_SET_LEN
> contains the
> number of beats per burst (from 1 to 16), and also [23:19]
> AXI_RX_OUTSTANDING_NUM
> contains the number of outstanding transfers (1 to 13).
> 
> If a controller does not have an AXI2AHB Wrapper, or if it does not
> use the AXI bus
> this register should read zero I think?
> 
> Especially the two fields that I mentioned before, those should read
> zero.
> 
> That, especially because the hwaddr for the controllers is anyway and
> always long
> 0x1000 - and I think that the extra registers space, on controllers
> that don't have
> the EMMC50 registers (msdc1 and msdc2) should be still reserved to
> those and never
> used for anything else.
> 
> Would that detection way work?

Confirmed that this approach will work for all Soc and IP version. Thx.

Will send v2 after your register cleanup series accepted.

Regards,
Axe

> 
> If it would, we'd be again autodetecting whether to set or not the
> AXI single burst
> option in the patch bits...without relying on specifying anything
> manually, not in
> the devicetree, and not in the platform data :-)
> 
> Cheers,
> Angelo
> 
> > > Regards,
> > > Axe
> > > 
> > > > 
> > > > Cheers,
> > > > Angelo
> > > > 
> > > > > 
> > > > > Regards,
> > > > > Axe
> > > > > 
> > > > > 
> > > > > > 
> > > > > > > ---
> > > > > > >     Documentation/devicetree/bindings/mmc/mtk-sd.yaml | 8
> > > > > > > ++++++++
> > > > > > >     1 file changed, 8 insertions(+)
> > > > > > > 
> > > > > > > diff --git a/Documentation/devicetree/bindings/mmc/mtk-
> > > > > > > sd.yaml
> > > > > > > b/Documentation/devicetree/bindings/mmc/mtk-sd.yaml
> > > > > > > index 0debccbd6519..6076aff0a689 100644
> > > > > > > --- a/Documentation/devicetree/bindings/mmc/mtk-sd.yaml
> > > > > > > +++ b/Documentation/devicetree/bindings/mmc/mtk-sd.yaml
> > > > > > > @@ -100,6 +100,14 @@ properties:
> > > > > > >         minimum: 0
> > > > > > >         maximum: 0xffffffff
> > > > > > > 
> > > > > > > +  mediatek,disable-single-burst:
> > > > > > > +    $ref: /schemas/types.yaml#/definitions/flag
> > > > > > > +    description:
> > > > > > > +      Burst type setting. For some versions of the IP
> > > > > > > that
> > > > > > > do
> > > > > > > not
> > > > > > > use
> > > > > > > +      AHB bus, the burst type need to be switched to
> > > > > > > INCR.
> > > > > > > +      If present, use INCR burst type.
> > > > > > > +      If not present, use single burst type.
> > > > > > > +
> > > > > > >       mediatek,hs200-cmd-int-delay:
> > > > > > >         $ref: /schemas/types.yaml#/definitions/uint32
> > > > > > >         description:
> > > > > > 
> > > > > > 
> > > > > > 
> > > > 
> > > > 
> 
> 

  reply	other threads:[~2025-03-27  2:50 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-06  8:48 [PATCH 0/2] mmc: mtk-sd: add support for burst type switch Axe Yang
2025-03-06  8:48 ` [PATCH 1/2] dt-bindings: mmc: mtk-sd: add single burst switch Axe Yang
2025-03-06  9:19   ` AngeloGioacchino Del Regno
2025-03-07  6:59     ` Axe Yang (杨磊)
2025-03-07 15:48       ` Conor Dooley
2025-03-10  3:31         ` Axe Yang (杨磊)
2025-03-11  9:47       ` AngeloGioacchino Del Regno
2025-03-12  6:30         ` Axe Yang (杨磊)
2025-03-25  2:41           ` Axe Yang (杨磊)
2025-03-25 10:20             ` AngeloGioacchino Del Regno
2025-03-27  2:48               ` Axe Yang (杨磊) [this message]
2025-04-03 10:57                 ` AngeloGioacchino Del Regno
2025-03-06  8:48 ` [PATCH 2/2] mmc: mtk-sd: add support to disable single burst Axe Yang

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=8958413b4138d815d582927f7702b35ffc20f122.camel@mediatek.com \
    --to=axe.yang@mediatek.com \
    --cc=Andy-ld.Lu@mediatek.com \
    --cc=Chaotian.Jing@mediatek.com \
    --cc=Qingliang.Li@mediatek.com \
    --cc=Wenbin.Mei@mediatek.com \
    --cc=angelogioacchino.delregno@collabora.com \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=krzk+dt@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=linux-mmc@vger.kernel.org \
    --cc=matthias.bgg@gmail.com \
    --cc=robh@kernel.org \
    --cc=ulf.hansson@linaro.org \
    --cc=yong.mao@mediatek.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox