All of lore.kernel.org
 help / color / mirror / Atom feed
From: Maxime Ripard <maxime.ripard-LDxbnhwyfcJBDgjK7y7TUQ@public.gmane.org>
To: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
Cc: Ulf Hansson <ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
	linux-mmc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-arm-kernel
	<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>,
	linux-sunxi <linux-sunxi-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org>
Subject: Re: [PATCH] mmc: sunxi: Use new timing mode for A64 eMMC controller
Date: Wed, 18 Jul 2018 17:22:03 +0200	[thread overview]
Message-ID: <20180718152203.svrt6wmr2vwh4rb5@flea> (raw)
In-Reply-To: <CAGb2v64NRVaWpbDqiX0JX7_6uvypUpNEecPUj-sSjaK5X-hdQA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

[-- Attachment #1: Type: text/plain, Size: 2479 bytes --]

On Tue, Jul 17, 2018 at 11:43:03PM +0800, Chen-Yu Tsai wrote:
> On Tue, Jul 17, 2018 at 11:15 PM, Maxime Ripard
> <maxime.ripard-LDxbnhwyfcJBDgjK7y7TUQ@public.gmane.org> wrote:
> > On Thu, Jul 12, 2018 at 06:17:23PM +0800, Chen-Yu Tsai wrote:
> >> On Thu, Jul 12, 2018 at 3:19 PM, Maxime Ripard
> >> <maxime.ripard-LDxbnhwyfcJBDgjK7y7TUQ@public.gmane.org> wrote:
> >> > Hi,
> >> >
> >> > On Thu, Jul 12, 2018 at 11:02:25AM +0800, Chen-Yu Tsai wrote:
> >> >> The eMMC controller is also a new timing mode controller, but it doesn't
> >> >> have the timing mode switch. It does however have signal delay and
> >> >> calibration controls, typical of Allwinner MMC controllers that support
> >> >> the new timing mode.
> >> >>
> >> >> Enable the new timing mode setting for the A64 eMMC controller. This
> >> >> also enables MMC HS-DDR modes, which gives higher throughput for eMMC
> >> >> chips that support it, and can deliver such throughput.
> >> >>
> >> >> Signed-off-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
> >> >
> >> > That doesn't look right. The datasheet explicitly mentions that this
> >> > bit doesn't apply to the eMMC controller, and the BSP is doing the same:
> >> > https://github.com/longsleep/linux-pine64/blob/lichee-dev-v3.10.65/drivers/mmc/host/sunxi-mmc-sun50iw1p1-1.c
> >> >
> >> > vs
> >> > https://github.com/longsleep/linux-pine64/blob/lichee-dev-v3.10.65/drivers/mmc/host/sunxi-mmc-sun50iw1p1-2.c
> >>
> >> You mean the bit in SDXC_REG_SD_NTSR? Yes I know that doesn't exist
> >> for the eMMC controller. I mentioned this in the commit message. It
> >> doesn't exist, and writes to it become a no-op.
> >>
> >> Would a comment, or comments, help with making this clear?
> >
> > Ah right. Maybe we should move the calibration under can_calibrate
> > though, or create another boolean for this?
> >
> > Putting it under has_new_timings while the SoC doesn't use it looks
> > very confusing.
> 
> IIRC we don't support calibration anyway. This boolean simply signals
> the usage of the new timing mode, whether by choice, or because it is
> the only mode the controller supports.

This is not the semantic I had in mind when I introduced it. The
original intent was to set the new timing bit all the time for
SoCs. If we want to change that semantic, then we also need to make
sure what this bit means is documented properly.

Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com

WARNING: multiple messages have this Message-ID (diff)
From: maxime.ripard@bootlin.com (Maxime Ripard)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] mmc: sunxi: Use new timing mode for A64 eMMC controller
Date: Wed, 18 Jul 2018 17:22:03 +0200	[thread overview]
Message-ID: <20180718152203.svrt6wmr2vwh4rb5@flea> (raw)
In-Reply-To: <CAGb2v64NRVaWpbDqiX0JX7_6uvypUpNEecPUj-sSjaK5X-hdQA@mail.gmail.com>

On Tue, Jul 17, 2018 at 11:43:03PM +0800, Chen-Yu Tsai wrote:
> On Tue, Jul 17, 2018 at 11:15 PM, Maxime Ripard
> <maxime.ripard@bootlin.com> wrote:
> > On Thu, Jul 12, 2018 at 06:17:23PM +0800, Chen-Yu Tsai wrote:
> >> On Thu, Jul 12, 2018 at 3:19 PM, Maxime Ripard
> >> <maxime.ripard@bootlin.com> wrote:
> >> > Hi,
> >> >
> >> > On Thu, Jul 12, 2018 at 11:02:25AM +0800, Chen-Yu Tsai wrote:
> >> >> The eMMC controller is also a new timing mode controller, but it doesn't
> >> >> have the timing mode switch. It does however have signal delay and
> >> >> calibration controls, typical of Allwinner MMC controllers that support
> >> >> the new timing mode.
> >> >>
> >> >> Enable the new timing mode setting for the A64 eMMC controller. This
> >> >> also enables MMC HS-DDR modes, which gives higher throughput for eMMC
> >> >> chips that support it, and can deliver such throughput.
> >> >>
> >> >> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
> >> >
> >> > That doesn't look right. The datasheet explicitly mentions that this
> >> > bit doesn't apply to the eMMC controller, and the BSP is doing the same:
> >> > https://github.com/longsleep/linux-pine64/blob/lichee-dev-v3.10.65/drivers/mmc/host/sunxi-mmc-sun50iw1p1-1.c
> >> >
> >> > vs
> >> > https://github.com/longsleep/linux-pine64/blob/lichee-dev-v3.10.65/drivers/mmc/host/sunxi-mmc-sun50iw1p1-2.c
> >>
> >> You mean the bit in SDXC_REG_SD_NTSR? Yes I know that doesn't exist
> >> for the eMMC controller. I mentioned this in the commit message. It
> >> doesn't exist, and writes to it become a no-op.
> >>
> >> Would a comment, or comments, help with making this clear?
> >
> > Ah right. Maybe we should move the calibration under can_calibrate
> > though, or create another boolean for this?
> >
> > Putting it under has_new_timings while the SoC doesn't use it looks
> > very confusing.
> 
> IIRC we don't support calibration anyway. This boolean simply signals
> the usage of the new timing mode, whether by choice, or because it is
> the only mode the controller supports.

This is not the semantic I had in mind when I introduced it. The
original intent was to set the new timing bit all the time for
SoCs. If we want to change that semantic, then we also need to make
sure what this bit means is documented properly.

Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180718/a0d51ed7/attachment.sig>

  parent reply	other threads:[~2018-07-18 15:22 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-12  3:02 [PATCH] mmc: sunxi: Use new timing mode for A64 eMMC controller Chen-Yu Tsai
2018-07-12  3:02 ` Chen-Yu Tsai
     [not found] ` <20180712030225.15681-1-wens-jdAy2FN1RRM@public.gmane.org>
2018-07-12  7:19   ` Maxime Ripard
2018-07-12  7:19     ` Maxime Ripard
2018-07-12 10:17     ` Chen-Yu Tsai
2018-07-12 10:17       ` Chen-Yu Tsai
     [not found]       ` <CAGb2v65rE2nQbyeiSPAyTzw-n-EQsUwQABx3nrvXTu4JogFPBQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2018-07-17 15:15         ` Maxime Ripard
2018-07-17 15:15           ` Maxime Ripard
2018-07-17 15:43           ` Chen-Yu Tsai
2018-07-17 15:43             ` Chen-Yu Tsai
     [not found]             ` <CAGb2v64NRVaWpbDqiX0JX7_6uvypUpNEecPUj-sSjaK5X-hdQA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2018-07-18 15:22               ` Maxime Ripard [this message]
2018-07-18 15:22                 ` Maxime Ripard
2018-07-30  9:27                 ` Chen-Yu Tsai
2018-07-30  9:27                   ` Chen-Yu Tsai
     [not found]                   ` <CAGb2v67XaWoBGX2Tn_J8LfBJiJja0yfRbM+QyHPLnXvQtBuGGw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2018-07-31 14:19                     ` Maxime Ripard
2018-07-31 14:19                       ` Maxime Ripard

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=20180718152203.svrt6wmr2vwh4rb5@flea \
    --to=maxime.ripard-ldxbnhwyfcjbdgjk7y7tuq@public.gmane.org \
    --cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
    --cc=linux-mmc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-sunxi-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org \
    --cc=ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
    --cc=wens-jdAy2FN1RRM@public.gmane.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.