From: Kartik Rajput <kkartik@nvidia.com>
To: "thierry.reding@gmail.com" <thierry.reding@gmail.com>
Cc: Laxman Dewangan <ldewangan@nvidia.com>,
Jon Hunter <jonathanh@nvidia.com>,
Akhil R <akhilrajeev@nvidia.com>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"robh@kernel.org" <robh@kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"krzk+dt@kernel.org" <krzk+dt@kernel.org>,
"andi.shyti@kernel.org" <andi.shyti@kernel.org>,
"conor+dt@kernel.org" <conor+dt@kernel.org>,
"linux-i2c@vger.kernel.org" <linux-i2c@vger.kernel.org>,
"digetx@gmail.com" <digetx@gmail.com>,
"linux-tegra@vger.kernel.org" <linux-tegra@vger.kernel.org>
Subject: Re: [PATCH 1/5] i2c: tegra: Add HS mode support
Date: Wed, 15 Jan 2025 11:40:49 +0000 [thread overview]
Message-ID: <a40329ad49dcc0efe1a468046a0a1ab19e3ff53a.camel@nvidia.com> (raw)
In-Reply-To: <vdllsl3rbt5xjaew4wzovpo3aoqrn4wvezcvuqfyr3mer6n7on@pkq5q2g43r3n>
On Wed, 2025-01-08 at 17:45 +0100, Thierry Reding wrote:
> On Wed, Jan 08, 2025 at 04:36:16PM +0530, Kartik Rajput wrote:
> > From: Akhil R <akhilrajeev@nvidia.com>
> >
> > Add support for HS (High Speed) mode tranfers, which is supported
> > by
> > Tegra194 onwards.
> >
> > Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
> > Signed-off-by: Kartik Rajput <kkartik@nvidia.com>
> > ---
> > drivers/i2c/busses/i2c-tegra.c | 22 ++++++++++++++++++++++
> > 1 file changed, 22 insertions(+)
> >
> > diff --git a/drivers/i2c/busses/i2c-tegra.c
> > b/drivers/i2c/busses/i2c-tegra.c
> > index 87976e99e6d0..7b97c6d347ee 100644
> > --- a/drivers/i2c/busses/i2c-tegra.c
> > +++ b/drivers/i2c/busses/i2c-tegra.c
> > @@ -91,6 +91,7 @@
> > #define I2C_HEADER_IE_ENABLE BIT(17)
> > #define I2C_HEADER_REPEAT_START BIT(16)
> > #define I2C_HEADER_CONTINUE_XFER BIT(15)
> > +#define I2C_HEADER_HS_MODE BIT(22)
> > #define I2C_HEADER_SLAVE_ADDR_SHIFT 1
> >
> > #define I2C_BUS_CLEAR_CNFG 0x084
> > @@ -220,10 +221,13 @@ struct tegra_i2c_hw_feature {
> > u32 thigh_std_mode;
> > u32 tlow_fast_fastplus_mode;
> > u32 thigh_fast_fastplus_mode;
> > + u32 tlow_hs_mode;
> > + u32 thigh_hs_mode;
> > u32 setup_hold_time_std_mode;
> > u32 setup_hold_time_fast_fast_plus_mode;
> > u32 setup_hold_time_hs_mode;
> > bool has_interface_timing_reg;
> > + bool has_hs_mode_support;
> > };
> >
> > /**
> > @@ -681,6 +685,18 @@ static int tegra_i2c_init(struct tegra_i2c_dev
> > *i2c_dev)
> > if (i2c_dev->hw->has_interface_timing_reg && tsu_thd)
> > i2c_writel(i2c_dev, tsu_thd,
> > I2C_INTERFACE_TIMING_1);
> >
> > + /* Write HS mode registers. These will get used only for HS
> > mode*/
> > + if (i2c_dev->hw->has_hs_mode_support) {
> > + tlow = i2c_dev->hw->tlow_hs_mode;
> > + thigh = i2c_dev->hw->thigh_hs_mode;
> > + tsu_thd = i2c_dev->hw->setup_hold_time_hs_mode;
> > +
> > + val = FIELD_PREP(I2C_HS_INTERFACE_TIMING_THIGH,
> > thigh) |
> > + FIELD_PREP(I2C_HS_INTERFACE_TIMING_TLOW,
> > tlow);
> > + i2c_writel(i2c_dev, val,
> > I2C_HS_INTERFACE_TIMING_0);
> > + i2c_writel(i2c_dev, tsu_thd,
> > I2C_HS_INTERFACE_TIMING_1);
> > + }
> > +
> > clk_multiplier = (tlow + thigh + 2) * (non_hs_mode + 1);
> >
> > err = clk_set_rate(i2c_dev->div_clk,
> > @@ -1178,6 +1194,9 @@ static void
> > tegra_i2c_push_packet_header(struct tegra_i2c_dev *i2c_dev,
> > if (msg->flags & I2C_M_RD)
> > packet_header |= I2C_HEADER_READ;
> >
> > + if (i2c_dev->timings.bus_freq_hz >
> > I2C_MAX_FAST_MODE_PLUS_FREQ)
> > + packet_header |= I2C_HEADER_HS_MODE;
> > +
>
> Do we need any kind of checking here? What happens if the requested
> frequency is higher than fastmode+ but the device doesn't support the
> new high-speed mode? I guess maybe we don't have to care because such
> cases won't ever show up because, well, they won't work.
>
> Still, it might be a good idea to be explicit about it and have an
> extra
> check in place (or perhaps a little higher up in the call chain) and
> return an error if we're trying to use a frequency that isn't
> supported
> on the chip.
>
> Thierry
ACK. I will add a check for this.
>
> > if (i2c_dev->dma_mode && !i2c_dev->msg_read)
> > *dma_buf++ = packet_header;
> > else
> > @@ -1618,10 +1637,13 @@ static const struct tegra_i2c_hw_feature
> > tegra194_i2c_hw = {
> > .thigh_std_mode = 0x7,
> > .tlow_fast_fastplus_mode = 0x2,
> > .thigh_fast_fastplus_mode = 0x2,
> > + .tlow_hs_mode = 0x8,
> > + .thigh_hs_mode = 0x3,
> > .setup_hold_time_std_mode = 0x08080808,
> > .setup_hold_time_fast_fast_plus_mode = 0x02020202,
> > .setup_hold_time_hs_mode = 0x090909,
> > .has_interface_timing_reg = true,
> > + .has_hs_mode_support = true,
> > };
> >
> > static const struct of_device_id tegra_i2c_of_match[] = {
> > --
> > 2.43.0
> >
next prev parent reply other threads:[~2025-01-15 11:40 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-08 11:06 [PATCH 0/5] Add I2C support for Tegra264 Kartik Rajput
2025-01-08 11:06 ` [PATCH 1/5] i2c: tegra: Add HS mode support Kartik Rajput
2025-01-08 16:45 ` Thierry Reding
2025-01-15 11:40 ` Kartik Rajput [this message]
2025-01-09 12:18 ` kernel test robot
2025-01-08 11:06 ` [PATCH 2/5] dt-bindings: i2c: nvidia,tegra20-i2c: Document Tegra264 I2C Kartik Rajput
2025-01-08 16:47 ` Thierry Reding
2025-01-15 11:41 ` Kartik Rajput
2025-01-10 15:55 ` Rob Herring
2025-01-15 11:46 ` Kartik Rajput
2025-01-08 11:06 ` [PATCH 3/5] i2c: tegra: Add Tegra264 support Kartik Rajput
2025-01-09 4:43 ` Mukesh Kumar Savaliya
2025-01-09 10:24 ` Thierry Reding
2025-01-09 12:37 ` Mukesh Kumar Savaliya
2025-01-08 11:06 ` [PATCH 4/5] i2c: tegra: Add support for SW Mutex register Kartik Rajput
2025-01-08 17:01 ` Thierry Reding
2025-01-15 11:39 ` Kartik Rajput
2025-01-08 11:06 ` [PATCH 5/5] i2c: tegra: Do not configure DMA if not supported Kartik Rajput
2025-01-09 10:33 ` Thierry Reding
2025-01-15 11:42 ` Kartik Rajput
2025-01-09 10:37 ` [PATCH 0/5] Add I2C support for Tegra264 Thierry Reding
2025-01-15 11:44 ` Kartik Rajput
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=a40329ad49dcc0efe1a468046a0a1ab19e3ff53a.camel@nvidia.com \
--to=kkartik@nvidia.com \
--cc=akhilrajeev@nvidia.com \
--cc=andi.shyti@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=digetx@gmail.com \
--cc=jonathanh@nvidia.com \
--cc=krzk+dt@kernel.org \
--cc=ldewangan@nvidia.com \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
--cc=robh@kernel.org \
--cc=thierry.reding@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox