All of lore.kernel.org
 help / color / mirror / Atom feed
From: Simon Horman <horms@kernel.org>
To: Min Li <lnimi@hotmail.com>
Cc: richardcochran@gmail.com, lee@kernel.org,
	linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
	Min Li <min.li.xe@renesas.com>
Subject: Re: [PATCH net-next v3 1/1] ptp: clockmatrix: support 32-bit address space
Date: Tue, 14 Nov 2023 19:34:39 +0000	[thread overview]
Message-ID: <20231114193439.GF74656@kernel.org> (raw)
In-Reply-To: <MW5PR03MB69324AE8F4C54FE03BD93A55A0B3A@MW5PR03MB6932.namprd03.prod.outlook.com>

On Mon, Nov 13, 2023 at 10:50:46AM -0500, Min Li wrote:
> From: Min Li <min.li.xe@renesas.com>
> 
> We used to assume 0x2010xxxx address. Now that
> we need to access 0x2011xxxx address, we need
> to support read/write the whole 32-bit address space.
> 
> Signed-off-by: Min Li <min.li.xe@renesas.com>
> ---
> - Drop MAX_ABS_WRITE_PHASE_PICOSECONDS advised by Rahul
> - Apply SCSR_ADDR to scrach register in idtcm_load_firmware advised by Simon

Hi Min Li,

thanks for addressing my earlier feedback.
I have done a more thorough review of this version,
I hope that it is useful.

>  drivers/ptp/ptp_clockmatrix.c    |  59 ++--
>  drivers/ptp/ptp_clockmatrix.h    |  32 +-
>  include/linux/mfd/idt8a340_reg.h | 542 ++++++++++++++++---------------
>  3 files changed, 325 insertions(+), 308 deletions(-)
> 
> diff --git a/drivers/ptp/ptp_clockmatrix.c b/drivers/ptp/ptp_clockmatrix.c
> index f6f9d4adce04..4d7898dc39d5 100644
> --- a/drivers/ptp/ptp_clockmatrix.c
> +++ b/drivers/ptp/ptp_clockmatrix.c
> @@ -41,7 +41,7 @@ module_param(firmware, charp, 0);
>  static int _idtcm_adjfine(struct idtcm_channel *channel, long scaled_ppm);
>  
>  static inline int idtcm_read(struct idtcm *idtcm,
> -			     u16 module,
> +			     u32 module,
>  			     u16 regaddr,
>  			     u8 *buf,
>  			     u16 count)
> @@ -50,7 +50,7 @@ static inline int idtcm_read(struct idtcm *idtcm,
>  }
>  
>  static inline int idtcm_write(struct idtcm *idtcm,
> -			      u16 module,
> +			      u32 module,
>  			      u16 regaddr,
>  			      u8 *buf,
>  			      u16 count)

I see that this patch expands the width of the module parameter of
idtcm_read() and idtcm_write(). And that with this change the module
parameter's leading 16bits are 0x2010. And that this is done to allow the
leading bits to be a different value, which I assume will be utilised in a
follow-up patch. But I am unclear on how the code handles that the
underlying read/write is now to an address 0x2010000 bytes greater than
before, or alternatively, how 0x2010000 was previously taken into account.

Also:

1. idtcm_output_enable() still seems to pass a 16-bit value as the module
   parameter to idtcm_read() and idtcm_write(), which seems inconsistent
   with this patch.

2. Related to 1., get_output_base_addr() returns an int which either
   encodes a negative error value (good) or a 32bit address (maybe not so
   good).

3. Some more of the idtcm_write() calls in _sync_pll_output() seem
   to need updating by inverting the 2nd and 3rd parameters
   so that the 2nd parameter is 32bits. I'm referring to the use
   of sync_ctrl0 and sync_ctrl1 as arguments to idtcm_write().

...

> @@ -1705,7 +1720,7 @@ static s32 idtcm_getmaxphase(struct ptp_clock_info *ptp __always_unused)
>  }
>  
>  /*
> - * Internal function for implementing support for write phase offset
> + * Maximum absolute value for write phase offset in picoseconds
>   *
>   * @channel:  channel
>   * @delta_ns: delta in nanoseconds
> @@ -1717,6 +1732,7 @@ static int _idtcm_adjphase(struct idtcm_channel *channel, s32 delta_ns)
>  	u8 i;
>  	u8 buf[4] = {0};
>  	s32 phase_50ps;
> +	s64 offset_ps;
>  
>  	if (channel->mode != PTP_PLL_MODE_WRITE_PHASE) {
>  		err = channel->configure_write_phase(channel);
> @@ -1724,7 +1740,8 @@ static int _idtcm_adjphase(struct idtcm_channel *channel, s32 delta_ns)
>  			return err;
>  	}
>  
> -	phase_50ps = div_s64((s64)delta_ns * 1000, 50);
> +	offset_ps = (s64)delta_ns * 1000;
> +	phase_50ps = div_s64(offset_ps, 50);
>  
>  	for (i = 0; i < 4; i++) {
>  		buf[i] = phase_50ps & 0xff;

It is unclear to me how the _idtcm_adjphase changes in the above 3 hunks
relate to the patch description. I wonder if this should be a separate patch?

> diff --git a/drivers/ptp/ptp_clockmatrix.h b/drivers/ptp/ptp_clockmatrix.h
> index 7c17c4f7f573..ad39dc6decdf 100644
> --- a/drivers/ptp/ptp_clockmatrix.h
> +++ b/drivers/ptp/ptp_clockmatrix.h
> @@ -54,21 +54,9 @@
>  #define LOCK_TIMEOUT_MS			(2000)
>  #define LOCK_POLL_INTERVAL_MS		(10)
>  
> -#define IDTCM_MAX_WRITE_COUNT		(512)
> -

Removing IDTCM_MAX_WRITE_COUNT seems nice, if it is unused.
But this doesn't seem related to the rest of this patch,
so perhaps it should be a separate patch.

...

> diff --git a/include/linux/mfd/idt8a340_reg.h b/include/linux/mfd/idt8a340_reg.h
> index 0c706085c205..b680a0eb5f68 100644
> --- a/include/linux/mfd/idt8a340_reg.h
> +++ b/include/linux/mfd/idt8a340_reg.h
> @@ -7,20 +7,20 @@
>  #ifndef HAVE_IDT8A340_REG
>  #define HAVE_IDT8A340_REG
>  
> -#define PAGE_ADDR_BASE                    0x0000
> -#define PAGE_ADDR                         0x00fc

Likewise, cleaning up PAGE_ADDR_BASE and PAGE_ADDR doesn't
seem strictly related to this patch. Though perhaps I am missing
something obvious.

...

  reply	other threads:[~2023-11-14 19:34 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-13 15:50 [PATCH net-next v3 1/1] ptp: clockmatrix: support 32-bit address space Min Li
2023-11-14 19:34 ` Simon Horman [this message]
2023-11-15 15:19   ` Min Li
2023-11-15 15:26   ` Min Li

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=20231114193439.GF74656@kernel.org \
    --to=horms@kernel.org \
    --cc=lee@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lnimi@hotmail.com \
    --cc=min.li.xe@renesas.com \
    --cc=netdev@vger.kernel.org \
    --cc=richardcochran@gmail.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.