From: Jon Hunter <jonathanh@nvidia.com>
To: Laxman Dewangan <ldewangan@nvidia.com>,
thierry.reding@gmail.com, airlied@linux.ie,
swarren@wwwdotorg.org
Cc: linux-tegra@vger.kernel.org, gnurou@gmail.com,
linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org
Subject: Re: [PATCH V5 3/3] soc/tegra: pmc: Add support for IO pads power state and voltage
Date: Fri, 20 May 2016 11:02:51 +0100 [thread overview]
Message-ID: <573EE0CB.7000807@nvidia.com> (raw)
In-Reply-To: <1463055706-17744-4-git-send-email-ldewangan@nvidia.com>
On 12/05/16 13:21, Laxman Dewangan wrote:
> The IO pins of Tegra SoCs are grouped for common control of IO
> interface like setting voltage signal levels and power state of
> the interface. The group is generally referred as IO pads. The
> power state and voltage control of IO pins can be done at IO pads
> level.
>
> Tegra generation SoC supports the power down of IO pads when it
> is not used even in the active state of system. This saves power
> from that IO interface. Also it supports multiple voltage level
> in IO pins for interfacing on some of pads. The IO pad voltage is
> automatically detected till T124, hence SW need not to configure
> this. But from T210, the automatically detection logic has been
> removed, hence SW need to explicitly set the IO pad voltage into
> IO pad configuration registers.
>
> Add support to set the power states and voltage level of the IO pads
> from client driver. The implementation for the APIs are in generic
> which is applicable for all generation os Tegra SoC.
>
> IO pads ID and information of bit field for power state and voltage
> level controls are added for Tegra124, Tegra132 and Tegra210. The SOR
> driver is modified to use the new APIs.
>
> Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
>
> ---
> Changes from V1:
> This is reworked on earlier path to have separation between IO rails and
> io pads and add power state and voltage control APIs in single call.
>
> Changes from V2:
> - Remove the tegra_io_rail_power_off/on() apis and change client (sor) driver
> to use the new APIs for IO pad power.
> - Remove the TEGRA_IO_RAIL_ macros.
>
> Changes from V3:
> - Make all pad_id/io_pad_id to id.
> - tegra_io_pad_ -> tegra_io_pads
> - dpd_bit -> bit, pwr_mask/bit to mask/bit.
> - Rename function to tegra_io_pads_{set,get}_voltage_config
> - Make the io pad tables common for all SoC.
> - Make io_pads enums.
> - Add enums for voltage.
>
> Changes from V4:
> - IO_PAD->IO_PADS
> - TEGRA_IO_PADS_POWER_SOURCE_ -> TEGRA_IO_PADS_VCONF_
> ---
> drivers/gpu/drm/tegra/sor.c | 8 +-
> drivers/soc/tegra/pmc.c | 221 ++++++++++++++++++++++++++++++++++++++------
> include/soc/tegra/pmc.h | 132 ++++++++++++++++++--------
> 3 files changed, 294 insertions(+), 67 deletions(-)
...
> +/* Define the IO_PADS SOC for SOC mask to find out that IO pads supported
Per coding-style this should be ...
/*
* Define the IO_PADS SOC ...
> + * or not in given SoC.
> + */
> +#define TEGRA_IO_PADS_T124 0x1
> +#define TEGRA_IO_PADS_T210 0x2
> +#define TEGRA_IO_PADS_T124_T210 (TEGRA_IO_PADS_T124 | \
> + TEGRA_IO_PADS_T210)
> +
What about T30 and T114? The TRM includes the DPD REQ/STATUS registers
for these?
> struct tegra_powergate {
> struct generic_pm_domain genpd;
> struct tegra_pmc *pmc;
> @@ -115,12 +127,23 @@ struct tegra_powergate {
> unsigned int num_resets;
> };
>
> +/* tegra_io_pads_config_info: Tegra IO pads bit config info.
> + * @dpd_config_bit: DPD configuration bit position. -1 if not supported.
> + * @voltage_config_bit: Voltage configuration bit position. -1 if not supported.
> + * @soc_mask: Bitwise OR of SoC masks if IO pads supported on that SoC.
> + */
> +struct tegra_io_pads_config_info {
> + int dpd_config_bit;
> + int voltage_config_bit;
> + int soc_mask;
> +};
> +
> struct tegra_pmc_soc {
> unsigned int num_powergates;
> const char *const *powergates;
> unsigned int num_cpu_powergates;
> const u8 *cpu_powergates;
> -
> + int io_pads_soc_mask;
> bool has_tsense_reset;
> bool has_gpu_clamps;
> };
> @@ -196,6 +219,14 @@ static void tegra_pmc_writel(u32 value, unsigned long offset)
> writel(value, pmc->base + offset);
> }
>
> +static void tegra_pmc_rmw(unsigned long offset, u32 mask, u32 val)
> +{
> + u32 pmc_reg = tegra_pmc_readl(offset);
> +
> + pmc_reg = (pmc_reg & ~mask) | (val & mask);
> + tegra_pmc_writel(pmc_reg, offset);
> +}
> +
> static inline bool tegra_powergate_state(int id)
> {
> if (id == TEGRA_POWERGATE_3D && pmc->soc->has_gpu_clamps)
> @@ -841,21 +872,99 @@ static void tegra_powergate_init(struct tegra_pmc *pmc)
> of_node_put(np);
> }
>
> -static int tegra_io_rail_prepare(unsigned int id, unsigned long *request,
> - unsigned long *status, unsigned int *bit)
> +#define TEGRA_IO_PADS_CONFIG(_id, _dpd, _volt, _soc) \
> +[TEGRA_IO_PADS_##_id] = { \
> + .dpd_config_bit = (_dpd), \
> + .voltage_config_bit = (_volt), \
> + .soc_mask = (_soc), \
> +}
> +
> +struct tegra_io_pads_config_info tegra_io_pads_configs[TEGRA_IO_PADS_MAX] = {
> + TEGRA_IO_PADS_CONFIG(CSIA, 0, -1, TEGRA_IO_PADS_T124_T210),
> + TEGRA_IO_PADS_CONFIG(CSIB, 1, -1, TEGRA_IO_PADS_T124_T210),
> + TEGRA_IO_PADS_CONFIG(DSI, 2, -1, TEGRA_IO_PADS_T124_T210),
> + TEGRA_IO_PADS_CONFIG(MIPI_BIAS, 3, -1, TEGRA_IO_PADS_T124_T210),
> + TEGRA_IO_PADS_CONFIG(PEX_BIAS, 4, -1, TEGRA_IO_PADS_T124_T210),
> + TEGRA_IO_PADS_CONFIG(PEX_CLK1, 5, -1, TEGRA_IO_PADS_T124_T210),
> + TEGRA_IO_PADS_CONFIG(PEX_CLK2, 6, -1, TEGRA_IO_PADS_T124_T210),
> + TEGRA_IO_PADS_CONFIG(USB0, 9, -1, TEGRA_IO_PADS_T124_T210),
> + TEGRA_IO_PADS_CONFIG(USB1, 10, -1, TEGRA_IO_PADS_T124_T210),
> + TEGRA_IO_PADS_CONFIG(USB2, 11, -1, TEGRA_IO_PADS_T124_T210),
> + TEGRA_IO_PADS_CONFIG(USB_BIAS, 12, -1, TEGRA_IO_PADS_T124_T210),
> + TEGRA_IO_PADS_CONFIG(NAND, 13, -1, TEGRA_IO_PADS_T124),
> + TEGRA_IO_PADS_CONFIG(UART, 14, -1, TEGRA_IO_PADS_T124_T210),
> + TEGRA_IO_PADS_CONFIG(BB, 15, -1, TEGRA_IO_PADS_T124),
> + TEGRA_IO_PADS_CONFIG(AUDIO, 17, -1, TEGRA_IO_PADS_T124_T210),
> + TEGRA_IO_PADS_CONFIG(USB3, 18, -1, TEGRA_IO_PADS_T210),
> + TEGRA_IO_PADS_CONFIG(HSIC, 19, -1, TEGRA_IO_PADS_T124_T210),
> + TEGRA_IO_PADS_CONFIG(COMP, 22, -1, TEGRA_IO_PADS_T124),
> + TEGRA_IO_PADS_CONFIG(DBG, 25, -1, TEGRA_IO_PADS_T210),
> + TEGRA_IO_PADS_CONFIG(DEBUG_NONAO, 26, -1, TEGRA_IO_PADS_T210),
> + TEGRA_IO_PADS_CONFIG(GPIO, 27, 21, TEGRA_IO_PADS_T210),
> + TEGRA_IO_PADS_CONFIG(HDMI, 28, -1, TEGRA_IO_PADS_T124_T210),
> + TEGRA_IO_PADS_CONFIG(PEX_CNTRL, 32, -1, TEGRA_IO_PADS_T124),
> + TEGRA_IO_PADS_CONFIG(SDMMC1, 33, 12, TEGRA_IO_PADS_T124_T210),
> + TEGRA_IO_PADS_CONFIG(SDMMC3, 34, 13, TEGRA_IO_PADS_T124_T210),
> + TEGRA_IO_PADS_CONFIG(SDMMC4, 35, -1, TEGRA_IO_PADS_T124),
> + TEGRA_IO_PADS_CONFIG(EMMC, 35, -1, TEGRA_IO_PADS_T210),
> + TEGRA_IO_PADS_CONFIG(CAM, 36, -1, TEGRA_IO_PADS_T124_T210),
> + TEGRA_IO_PADS_CONFIG(EMMC2, 37, -1, TEGRA_IO_PADS_T210),
> + TEGRA_IO_PADS_CONFIG(HV, 38, -1, TEGRA_IO_PADS_T124),
> + TEGRA_IO_PADS_CONFIG(DSIB, 39, -1, TEGRA_IO_PADS_T124_T210),
> + TEGRA_IO_PADS_CONFIG(DSIC, 40, -1, TEGRA_IO_PADS_T124_T210),
> + TEGRA_IO_PADS_CONFIG(DSID, 41, -1, TEGRA_IO_PADS_T124_T210),
> + TEGRA_IO_PADS_CONFIG(CSIC, 42, -1, TEGRA_IO_PADS_T210),
> + TEGRA_IO_PADS_CONFIG(CSID, 43, -1, TEGRA_IO_PADS_T210),
> + TEGRA_IO_PADS_CONFIG(CSIE, 44, -1, TEGRA_IO_PADS_T124_T210),
> + TEGRA_IO_PADS_CONFIG(CSIF, 45, -1, TEGRA_IO_PADS_T210),
> + TEGRA_IO_PADS_CONFIG(SPI, 46, -1, TEGRA_IO_PADS_T210),
> + TEGRA_IO_PADS_CONFIG(SPI_HV, 47, 23, TEGRA_IO_PADS_T210),
> + TEGRA_IO_PADS_CONFIG(DMIC, 50, -1, TEGRA_IO_PADS_T210),
> + TEGRA_IO_PADS_CONFIG(DP, 51, -1, TEGRA_IO_PADS_T210),
> + TEGRA_IO_PADS_CONFIG(LVDS, 57, -1, TEGRA_IO_PADS_T124_T210),
> + TEGRA_IO_PADS_CONFIG(SYS_DDC, 58, -1, TEGRA_IO_PADS_T124),
> + TEGRA_IO_PADS_CONFIG(AUDIO_HV, 61, 18, TEGRA_IO_PADS_T210),
> +};
> +
> +static inline int tegra_io_pads_to_dpd_bit(const struct tegra_pmc_soc *soc,
> + enum tegra_io_pads id)
> {
> - unsigned long rate, value;
> + if (!(tegra_io_pads_configs[id].soc_mask & soc->io_pads_soc_mask) ||
> + (tegra_io_pads_configs[id].dpd_config_bit < 0))
> + return -EINVAL;
Seems that you may as well store -ENODEV/-ENOTSUPP in the table and then
you can get rid of this test.
Cheers
Jon
--
nvpublic
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2016-05-20 10:02 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-12 12:21 [PATCH V5 0/3] soc/tegra: Add support for IO pads power and voltage control Laxman Dewangan
2016-05-12 12:21 ` [PATCH V5 1/3] soc/tegra: pmc: Use BIT macro for register field definition Laxman Dewangan
[not found] ` <1463055706-17744-1-git-send-email-ldewangan-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2016-05-12 12:21 ` [PATCH V5 2/3] soc/tegra: pmc: Correct type of variable for tegra_pmc_readl() Laxman Dewangan
2016-05-12 12:21 ` [PATCH V5 3/3] soc/tegra: pmc: Add support for IO pads power state and voltage Laxman Dewangan
2016-05-19 15:54 ` Jon Hunter
[not found] ` <573DE19C.8090704-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2016-05-19 16:13 ` Laxman Dewangan
[not found] ` <573DE61D.6080203-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2016-05-20 8:58 ` Jon Hunter
2016-05-20 9:34 ` Jon Hunter
2016-05-20 10:02 ` Jon Hunter [this message]
[not found] ` <573EE0CB.7000807-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2016-05-20 9:59 ` Laxman Dewangan
[not found] ` <573EE015.6050600-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2016-05-20 10:28 ` Jon Hunter
2016-05-19 7:53 ` [PATCH V5 0/3] soc/tegra: Add support for IO pads power and voltage control Laxman Dewangan
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=573EE0CB.7000807@nvidia.com \
--to=jonathanh@nvidia.com \
--cc=airlied@linux.ie \
--cc=dri-devel@lists.freedesktop.org \
--cc=gnurou@gmail.com \
--cc=ldewangan@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
--cc=swarren@wwwdotorg.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;
as well as URLs for NNTP newsgroup(s).