All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jerome Brunet <jbrunet@baylibre.com>
To: Vyacheslav Bocharov <adeep@lexina.in>,
	linux-mmc@vger.kernel.org, devicetree@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-amlogic@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/4] arm64: amlogic: mmc: meson-gx: Add core, tx, rx
Date: Sun, 13 Nov 2022 21:06:44 +0100	[thread overview]
Message-ID: <1jk03y37vs.fsf@starbuckisacylon.baylibre.com> (raw)
In-Reply-To: <20221110150035.2824580-1-adeep@lexina.in>


On Thu 10 Nov 2022 at 18:00, Vyacheslav Bocharov <adeep@lexina.in> wrote:

> The mmc driver use the same phase values (core - 180, tx/rx - 0) for all
> meson64 platforms. However, some platforms (and even some boards) require
> different values

Where does it stops ? Trying to solve the instabilities of this
IP/driver by tweaking the phase has proven to be dead-end.

Soon, you'll end up tweaking these settings depending on the on
particular version of the device because it ships with a different eMMC
manufacturer. Then comes multi sourcing, sdio modules, sdcards ...

> (axg for example use 270 degree for core clock).

Where ? Upstream linux does not

u-boot does something of the sort for sm1 and I'm not entirely sure this
appropriate either.

IMO, this setting has more to do with the mode the mmc device is
operating at - not the platform or board.

We had some discussions with the HW designers at AML and they recommended
to keep a phase shift of 180 between the Core and Tx. They also
recommended to leave Rx alone (actually, starting from the v3, the Rx
field has no effect. It is not even wired to actual HW)

Funnily, that is not what the vendor driver does. It also does A LOT of
extremely complex and 'debatable' things, which mostly mask how much the
driver is unstable.

With the upstream drivers, modes up to SDR50 and HS200 have been stable
lately. SDR104 and DDR modes (DDR52 or HS400) remains problematic.

Changing the settings further would require more discussion with AML.
Blindly poking these value until you get something stablish for 1
particular use case is a recipe for disaster.

> This patch
> transfers the values from the code to the variables in the device-tree files.
> If not set in dts, use old default values.

I think going that way is opening a big can of worms. 
I don't think this should be applied

>
> Vyacheslav Bocharov (4):
>   arm64: amlogic: mmc: meson-gx: Add core, tx, rx eMMC/SD/SDIO phase
>     clock settings from devicetree data
>   arm64: amlogic: mmc: meson-gx: Add dts binding include for core, tx,
>     rx eMMC/SD/SDIO phase clock settings from devicetree data
>   arm64: amlogic: dts: meson: update meson-axg device-tree for new core,
>     tx, rx phase clock settings.
>   arm64: dts: docs: Update mmc meson-gx documentation for new config
>     option amlogic,mmc-phase
>
>  .../bindings/mmc/amlogic,meson-gx.txt         |  7 ++++
>  arch/arm64/boot/dts/amlogic/meson-axg.dtsi    |  3 ++
>  drivers/mmc/host/meson-gx-mmc.c               | 18 +++++++---
>  include/dt-bindings/mmc/meson-gx-mmc.h        | 35 +++++++++++++++++++
>  4 files changed, 58 insertions(+), 5 deletions(-)
>  create mode 100644 include/dt-bindings/mmc/meson-gx-mmc.h


WARNING: multiple messages have this Message-ID (diff)
From: Jerome Brunet <jbrunet@baylibre.com>
To: Vyacheslav Bocharov <adeep@lexina.in>,
	linux-mmc@vger.kernel.org, devicetree@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-amlogic@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/4] arm64: amlogic: mmc: meson-gx: Add core, tx, rx
Date: Sun, 13 Nov 2022 21:06:44 +0100	[thread overview]
Message-ID: <1jk03y37vs.fsf@starbuckisacylon.baylibre.com> (raw)
In-Reply-To: <20221110150035.2824580-1-adeep@lexina.in>


On Thu 10 Nov 2022 at 18:00, Vyacheslav Bocharov <adeep@lexina.in> wrote:

> The mmc driver use the same phase values (core - 180, tx/rx - 0) for all
> meson64 platforms. However, some platforms (and even some boards) require
> different values

Where does it stops ? Trying to solve the instabilities of this
IP/driver by tweaking the phase has proven to be dead-end.

Soon, you'll end up tweaking these settings depending on the on
particular version of the device because it ships with a different eMMC
manufacturer. Then comes multi sourcing, sdio modules, sdcards ...

> (axg for example use 270 degree for core clock).

Where ? Upstream linux does not

u-boot does something of the sort for sm1 and I'm not entirely sure this
appropriate either.

IMO, this setting has more to do with the mode the mmc device is
operating at - not the platform or board.

We had some discussions with the HW designers at AML and they recommended
to keep a phase shift of 180 between the Core and Tx. They also
recommended to leave Rx alone (actually, starting from the v3, the Rx
field has no effect. It is not even wired to actual HW)

Funnily, that is not what the vendor driver does. It also does A LOT of
extremely complex and 'debatable' things, which mostly mask how much the
driver is unstable.

With the upstream drivers, modes up to SDR50 and HS200 have been stable
lately. SDR104 and DDR modes (DDR52 or HS400) remains problematic.

Changing the settings further would require more discussion with AML.
Blindly poking these value until you get something stablish for 1
particular use case is a recipe for disaster.

> This patch
> transfers the values from the code to the variables in the device-tree files.
> If not set in dts, use old default values.

I think going that way is opening a big can of worms. 
I don't think this should be applied

>
> Vyacheslav Bocharov (4):
>   arm64: amlogic: mmc: meson-gx: Add core, tx, rx eMMC/SD/SDIO phase
>     clock settings from devicetree data
>   arm64: amlogic: mmc: meson-gx: Add dts binding include for core, tx,
>     rx eMMC/SD/SDIO phase clock settings from devicetree data
>   arm64: amlogic: dts: meson: update meson-axg device-tree for new core,
>     tx, rx phase clock settings.
>   arm64: dts: docs: Update mmc meson-gx documentation for new config
>     option amlogic,mmc-phase
>
>  .../bindings/mmc/amlogic,meson-gx.txt         |  7 ++++
>  arch/arm64/boot/dts/amlogic/meson-axg.dtsi    |  3 ++
>  drivers/mmc/host/meson-gx-mmc.c               | 18 +++++++---
>  include/dt-bindings/mmc/meson-gx-mmc.h        | 35 +++++++++++++++++++
>  4 files changed, 58 insertions(+), 5 deletions(-)
>  create mode 100644 include/dt-bindings/mmc/meson-gx-mmc.h


_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic

WARNING: multiple messages have this Message-ID (diff)
From: Jerome Brunet <jbrunet@baylibre.com>
To: Vyacheslav Bocharov <adeep@lexina.in>,
	linux-mmc@vger.kernel.org, devicetree@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-amlogic@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/4] arm64: amlogic: mmc: meson-gx: Add core, tx, rx
Date: Sun, 13 Nov 2022 21:06:44 +0100	[thread overview]
Message-ID: <1jk03y37vs.fsf@starbuckisacylon.baylibre.com> (raw)
In-Reply-To: <20221110150035.2824580-1-adeep@lexina.in>


On Thu 10 Nov 2022 at 18:00, Vyacheslav Bocharov <adeep@lexina.in> wrote:

> The mmc driver use the same phase values (core - 180, tx/rx - 0) for all
> meson64 platforms. However, some platforms (and even some boards) require
> different values

Where does it stops ? Trying to solve the instabilities of this
IP/driver by tweaking the phase has proven to be dead-end.

Soon, you'll end up tweaking these settings depending on the on
particular version of the device because it ships with a different eMMC
manufacturer. Then comes multi sourcing, sdio modules, sdcards ...

> (axg for example use 270 degree for core clock).

Where ? Upstream linux does not

u-boot does something of the sort for sm1 and I'm not entirely sure this
appropriate either.

IMO, this setting has more to do with the mode the mmc device is
operating at - not the platform or board.

We had some discussions with the HW designers at AML and they recommended
to keep a phase shift of 180 between the Core and Tx. They also
recommended to leave Rx alone (actually, starting from the v3, the Rx
field has no effect. It is not even wired to actual HW)

Funnily, that is not what the vendor driver does. It also does A LOT of
extremely complex and 'debatable' things, which mostly mask how much the
driver is unstable.

With the upstream drivers, modes up to SDR50 and HS200 have been stable
lately. SDR104 and DDR modes (DDR52 or HS400) remains problematic.

Changing the settings further would require more discussion with AML.
Blindly poking these value until you get something stablish for 1
particular use case is a recipe for disaster.

> This patch
> transfers the values from the code to the variables in the device-tree files.
> If not set in dts, use old default values.

I think going that way is opening a big can of worms. 
I don't think this should be applied

>
> Vyacheslav Bocharov (4):
>   arm64: amlogic: mmc: meson-gx: Add core, tx, rx eMMC/SD/SDIO phase
>     clock settings from devicetree data
>   arm64: amlogic: mmc: meson-gx: Add dts binding include for core, tx,
>     rx eMMC/SD/SDIO phase clock settings from devicetree data
>   arm64: amlogic: dts: meson: update meson-axg device-tree for new core,
>     tx, rx phase clock settings.
>   arm64: dts: docs: Update mmc meson-gx documentation for new config
>     option amlogic,mmc-phase
>
>  .../bindings/mmc/amlogic,meson-gx.txt         |  7 ++++
>  arch/arm64/boot/dts/amlogic/meson-axg.dtsi    |  3 ++
>  drivers/mmc/host/meson-gx-mmc.c               | 18 +++++++---
>  include/dt-bindings/mmc/meson-gx-mmc.h        | 35 +++++++++++++++++++
>  4 files changed, 58 insertions(+), 5 deletions(-)
>  create mode 100644 include/dt-bindings/mmc/meson-gx-mmc.h


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  parent reply	other threads:[~2022-11-13 20:41 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-10 15:00 [PATCH 0/4] arm64: amlogic: mmc: meson-gx: Add core, tx, rx Vyacheslav Bocharov
2022-11-10 15:00 ` Vyacheslav Bocharov
2022-11-10 15:00 ` Vyacheslav Bocharov
2022-11-10 15:00 ` [PATCH 1/4] arm64: amlogic: mmc: meson-gx: Add core, tx, rx eMMC/SD/SDIO phase clock settings from devicetree data Vyacheslav Bocharov
2022-11-10 15:00   ` Vyacheslav Bocharov
2022-11-10 15:00   ` Vyacheslav Bocharov
2022-11-12 22:57   ` Martin Blumenstingl
2022-11-12 22:57     ` Martin Blumenstingl
2022-11-12 22:57     ` Martin Blumenstingl
2022-11-10 15:00 ` [PATCH 2/4] arm64: amlogic: mmc: meson-gx: Add dts binding include for " Vyacheslav Bocharov
2022-11-10 15:00   ` Vyacheslav Bocharov
2022-11-10 15:00   ` Vyacheslav Bocharov
2022-11-12 22:59   ` Martin Blumenstingl
2022-11-12 22:59     ` Martin Blumenstingl
2022-11-12 22:59     ` Martin Blumenstingl
2022-11-10 15:00 ` [PATCH 3/4] arm64: amlogic: dts: meson: update meson-axg device-tree for new core, tx, rx phase clock settings Vyacheslav Bocharov
2022-11-10 15:00   ` Vyacheslav Bocharov
2022-11-10 15:00   ` Vyacheslav Bocharov
2022-11-10 15:00 ` [PATCH 4/4] arm64: dts: docs: Update mmc meson-gx documentation for new config option amlogic,mmc-phase Vyacheslav Bocharov
2022-11-10 15:00   ` Vyacheslav Bocharov
2022-11-10 15:00   ` Vyacheslav Bocharov
2022-11-12 23:01   ` Martin Blumenstingl
2022-11-12 23:01     ` Martin Blumenstingl
2022-11-12 23:01     ` Martin Blumenstingl
2022-11-23 16:23   ` Krzysztof Kozlowski
2022-11-23 16:23     ` Krzysztof Kozlowski
2022-11-23 16:23     ` Krzysztof Kozlowski
2022-11-13 20:06 ` Jerome Brunet [this message]
2022-11-13 20:06   ` [PATCH 0/4] arm64: amlogic: mmc: meson-gx: Add core, tx, rx Jerome Brunet
2022-11-13 20:06   ` Jerome Brunet
2022-11-24  6:22   ` Vyacheslav
2022-11-24  6:22     ` Vyacheslav
2022-11-24  6:22     ` Vyacheslav
2022-11-25 10:28     ` Jerome Brunet
2022-11-25 10:28       ` Jerome Brunet
2022-11-25 10:28       ` Jerome Brunet

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=1jk03y37vs.fsf@starbuckisacylon.baylibre.com \
    --to=jbrunet@baylibre.com \
    --cc=adeep@lexina.in \
    --cc=devicetree@vger.kernel.org \
    --cc=linux-amlogic@lists.infradead.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mmc@vger.kernel.org \
    /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.