public inbox for linux-i2c@vger.kernel.org
 help / color / mirror / Atom feed
From: Jean Delvare <khali-PUYAD+kWke1g9hUCZPvPmw@public.gmane.org>
To: Trent Piepho <xyzzy-zY4eFNvK5D+xbKUeIHjxjQ@public.gmane.org>
Cc: Linux I2C <i2c-GZX6beZjE8VD60Wz+7aTrA@public.gmane.org>
Subject: Re: [PATCH] More DDR2 data for decode-dimms.pl
Date: Thu, 20 Mar 2008 12:13:36 +0100	[thread overview]
Message-ID: <20080320121336.2109d6d3@hyperion.delvare> (raw)
In-Reply-To: <Pine.LNX.4.58.0803191731500.16142-nuiHJn5p267P3RPoUHIrnuTW4wlIGRCZ@public.gmane.org>

Hi Trent,

On Wed, 19 Mar 2008 18:36:32 -0700 (PDT), Trent Piepho wrote:
> On Wed, 19 Mar 2008, Jean Delvare wrote:
> > As far as I can see, the masking isn't needed, as you do it again in
> > ddrx_sdram_rtime(). That being said, it would probably make sense to do
> > all the shifting and masking on the caller's side. Doing half of the
> > shifting outside and the other half inside the function is pretty
> > confusing.
> 
> This is better?
> 
>         printl "Minimum Active to Auto-refresh Delay (tRC)",
>                tns(ddr2_sdram_rtime($bytes->[41], ($bytes->[40] >> 4) & 7));
>         printl "Minimum Recovery Delay (tRFC)",
>                tns(ddr2_sdram_rtime($bytes->[42] + ($bytes->[40] & 1) * 256,
> 	                            ($bytes->[40] >> 1) & 7));
> 
> I was trying to do as much as possible on the callee's side.

Yes I think it is better. I understand that putting more on the
callee's side performs better and makes the code look better on the
caller's side, but the problem is that the helper function then has an
interface that is obscure and difficult to understand and validate. I
prefer something a bit slower but with a clean interface.

If you want to move some more code in the callee, I propose the
following:

sub ddr2_sdram_rtime($$)
{
	my ($rtime, $ext1, $ext2) = @_;
	my @table = (0, .25, .33, .50, .66, .75);

	return $time + ext1 * 256 + $table[$ext2];
}

(...)
	printl "Minimum Active to Auto-refresh Delay (tRC)",
	       tns(ddr2_sdram_rtime($bytes->[41], 0, ($bytes->[40] >> 4) & 7));
	printl "Minimum Recovery Delay (tRFC)",
	       tns(ddr2_sdram_rtime($bytes->[42], $bytes->[40] & 1,
				    ($bytes->[40] >> 1) & 7));

That's probably the best trade-off you can get.

I'm fine with the rest, with one question though:

> +	my @burst;
> +	push @burst, 4 if ($bytes->[16] & 4);
> +	push @burst, 8 if ($bytes->[16] & 8);
> +	printl "Supported Burst Lengths", join(', ', @burst);

Do DDR2 modules have to support burst at all? The SDR code assumes that
the module might not support any burst length and prints "None" in this
case. I suspect that we should do the same for DDR2.

Thanks,
-- 
Jean Delvare

_______________________________________________
i2c mailing list
i2c-GZX6beZjE8VD60Wz+7aTrA@public.gmane.org
http://lists.lm-sensors.org/mailman/listinfo/i2c

  parent reply	other threads:[~2008-03-20 11:13 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <Pine.LNX.4.58.0802281401020.14140@shell4.speakeasy.net>
     [not found] ` <Pine.LNX.4.58.0802281401020.14140-13q4cmjDBaTP3RPoUHIrnuTW4wlIGRCZ@public.gmane.org>
2008-03-19 13:16   ` [PATCH] More DDR2 data for decode-dimms.pl Jean Delvare
     [not found]     ` <20080319141609.338c19b1-ig7AzVSIIG7kN2dkZ6Wm7A@public.gmane.org>
2008-03-20  1:36       ` Trent Piepho
     [not found]         ` <Pine.LNX.4.58.0803191731500.16142-nuiHJn5p267P3RPoUHIrnuTW4wlIGRCZ@public.gmane.org>
2008-03-20 11:13           ` Jean Delvare [this message]
     [not found]             ` <20080320121336.2109d6d3-ig7AzVSIIG7kN2dkZ6Wm7A@public.gmane.org>
2008-03-20 15:47               ` Trent Piepho
     [not found]                 ` <Pine.LNX.4.58.0803200822100.16142-nuiHJn5p267P3RPoUHIrnuTW4wlIGRCZ@public.gmane.org>
2008-03-21 17:47                   ` Jean Delvare
2008-02-28 22:19 Trent Piepho

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=20080320121336.2109d6d3@hyperion.delvare \
    --to=khali-puyad+kwke1g9huczpvpmw@public.gmane.org \
    --cc=i2c-GZX6beZjE8VD60Wz+7aTrA@public.gmane.org \
    --cc=xyzzy-zY4eFNvK5D+xbKUeIHjxjQ@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox