* Re: [PATCH 4/8] PCI: Add quirk to disable MSI support for Amazon's Annapurna Labs host bridge
From: Benjamin Herrenschmidt @ 2019-07-14 22:54 UTC (permalink / raw)
To: Chocron, Jonathan, helgaas@kernel.org
Cc: linux-kernel@vger.kernel.org, robh+dt@kernel.org,
jingoohan1@gmail.com, Woodhouse, David, Hanoch, Uri,
devicetree@vger.kernel.org, lorenzo.pieralisi@arm.com,
gustavo.pimentel@synopsys.com, Wasserstrom, Barak, Saidi, Ali,
mark.rutland@arm.com, Hawa, Hanna, Shenhar, Talel, Krupnik, Ronen,
linux-pci@vger.kernel.org
In-Reply-To: <2cac43401f0cf76acb645b98c6543204f12d5c05.camel@amazon.com>
On Sun, 2019-07-14 at 15:09 +0000, Chocron, Jonathan wrote:
> > s/host bridge/Root Port/, if I understand correctly.
> >
>
> Ack.
>
> BTW, what is the main difference between the 2 terms, since they seem
> to be (mistakenly?) used interchangeably?
The host bridge is the parent of the root port. You can have several
root ports under a host bridge in fact. They tend to be part of the
same silicon and somewhat intimately linked but they are distinct
logical entities. The root port appears as a PCIe p2p bridge sitting on
the top level bus provided by the host bridge. The Host Bridge doesn't
have to have a representation in config space (it sometimes does
historically, but as a sibling of the devices on that top level bus. In
PCIe land, these are chipset built-in devices).
Ben.
^ permalink raw reply
* Re: [PATCH V5 02/18] pinctrl: tegra: Add suspend and resume support
From: Dmitry Osipenko @ 2019-07-14 21:41 UTC (permalink / raw)
To: Sowjanya Komatineni, Linus Walleij
Cc: thierry.reding@gmail.com, Jon Hunter, Thomas Gleixner,
Jason Cooper, Marc Zyngier, Stefan Agner, Mark Rutland,
Peter De Schrijver, Prashant Gaikwad, Stephen Boyd, linux-clk,
open list:GPIO SUBSYSTEM, jckuo, Joseph Lo, talho, linux-tegra,
linux-kernel@vger.kernel.org, Mikko Perttunen, spatra,
Rob Herring, OPEN
In-Reply-To: <db7ac8e6-bfad-bc60-b46e-d886025872e4@nvidia.com>
13.07.2019 8:31, Sowjanya Komatineni пишет:
>
> On 7/4/19 3:40 AM, Dmitry Osipenko wrote:
>> 04.07.2019 10:31, Linus Walleij пишет:
>>> On Sat, Jun 29, 2019 at 5:58 PM Dmitry Osipenko <digetx@gmail.com>
>>> wrote:
>>>
>>>> Oh, also what about GPIO-pinctrl suspend resume ordering .. is it
>>>> okay that pinctrl
>>>> will be resumed after GPIO? Shouldn't a proper pin-muxing be
>>>> selected at first?
>>> Thierry sent some initial patches about this I think. We need to use
>>> device links for this to work properly so he adds support for
>>> linking the pinctrl and GPIO devices through the ranges.
>>>
>>> For links between pin control handles and their consumers, see also:
>>> 036f394dd77f pinctrl: Enable device link creation for pin control
>>> c6045b4e3cad pinctrl: stmfx: enable links creations
>>> 489b64d66325 pinctrl: stm32: Add links to consumers
>>>
>>> I am using STM32 as guinea pig for this, consider adding links also
>>> from the Tegra pinctrl. I might simply make these pinctrl consumer
>>> to producer links default because I think it makes a lot sense.
>> IIUC, currently the plan is to resume pinctrl *after* GPIO for
>> Tegra210 [1]. But this
>> contradicts to what was traditionally done for older Tegras where
>> pinctrl was always
>> resumed first and apparently it won't work well for the GPIO ranges as
>> well. I think this
>> and the other patchsets related to suspend-resume still need some more
>> thought.
>>
>> [1] https://patchwork.kernel.org/patch/11012077/
>
> Park bit was introduced from Tegra210 onwards and during suspend/resume,
> requirement of gpio restore prior to pinctrl restore is not required for
> prior Tegra210.
>
> Also currently pinctrl suspend/resume implementation for prior Tegra210
> is not yet upstreamed but having gpio restore prior to pinmux during
> suspend/resume should not cause any issue for prior tegra's as well as
> gpio resume restores pins back to same gpio config as they were during
> suspend entry.
>
Okay!
^ permalink raw reply
* Re: [PATCH V5 11/18] clk: tegra210: Add support for Tegra210 clocks
From: Dmitry Osipenko @ 2019-07-14 21:41 UTC (permalink / raw)
To: Sowjanya Komatineni, thierry.reding, jonathanh, tglx, jason,
marc.zyngier, linus.walleij, stefan, mark.rutland
Cc: pdeschrijver, pgaikwad, sboyd, linux-clk, linux-gpio, jckuo,
josephl, talho, linux-tegra, linux-kernel, mperttunen, spatra,
robh+dt, devicetree
In-Reply-To: <a9b5c364-52b4-bee1-5881-47197f043950@nvidia.com>
13.07.2019 8:54, Sowjanya Komatineni пишет:
>
> On 6/29/19 8:10 AM, Dmitry Osipenko wrote:
>> 28.06.2019 5:12, Sowjanya Komatineni пишет:
>>> This patch adds system suspend and resume support for Tegra210
>>> clocks.
>>>
>>> All the CAR controller settings are lost on suspend when core power
>>> goes off.
>>>
>>> This patch has implementation for saving and restoring all the PLLs
>>> and clocks context during system suspend and resume to have the
>>> clocks back to same state for normal operation.
>>>
>>> Acked-by: Thierry Reding <treding@nvidia.com>
>>> Signed-off-by: Sowjanya Komatineni <skomatineni@nvidia.com>
>>> ---
>>> drivers/clk/tegra/clk-tegra210.c | 115
>>> ++++++++++++++++++++++++++++++++++++++-
>>> drivers/clk/tegra/clk.c | 14 +++++
>>> drivers/clk/tegra/clk.h | 1 +
>>> 3 files changed, 127 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/clk/tegra/clk-tegra210.c
>>> b/drivers/clk/tegra/clk-tegra210.c
>>> index 1c08c53482a5..1b839544e086 100644
>>> --- a/drivers/clk/tegra/clk-tegra210.c
>>> +++ b/drivers/clk/tegra/clk-tegra210.c
>>> @@ -9,10 +9,12 @@
>>> #include <linux/clkdev.h>
>>> #include <linux/of.h>
>>> #include <linux/of_address.h>
>>> +#include <linux/of_platform.h>
>>> #include <linux/delay.h>
>>> #include <linux/export.h>
>>> #include <linux/mutex.h>
>>> #include <linux/clk/tegra.h>
>>> +#include <linux/syscore_ops.h>
>>> #include <dt-bindings/clock/tegra210-car.h>
>>> #include <dt-bindings/reset/tegra210-car.h>
>>> #include <linux/iopoll.h>
>>> @@ -20,6 +22,7 @@
>>> #include <soc/tegra/pmc.h>
>>> #include "clk.h"
>>> +#include "clk-dfll.h"
>>> #include "clk-id.h"
>>> /*
>>> @@ -225,6 +228,7 @@
>>> #define CLK_RST_CONTROLLER_RST_DEV_Y_SET 0x2a8
>>> #define CLK_RST_CONTROLLER_RST_DEV_Y_CLR 0x2ac
>>> +#define CPU_SOFTRST_CTRL 0x380
>>> #define LVL2_CLK_GATE_OVRA 0xf8
>>> #define LVL2_CLK_GATE_OVRC 0x3a0
>>> @@ -2820,6 +2824,7 @@ static int tegra210_enable_pllu(void)
>>> struct tegra_clk_pll_freq_table *fentry;
>>> struct tegra_clk_pll pllu;
>>> u32 reg;
>>> + int ret;
>>> for (fentry = pll_u_freq_table; fentry->input_rate; fentry++) {
>>> if (fentry->input_rate == pll_ref_freq)
>>> @@ -2847,10 +2852,10 @@ static int tegra210_enable_pllu(void)
>>> fence_udelay(1, clk_base);
>>> reg |= PLL_ENABLE;
>>> writel(reg, clk_base + PLLU_BASE);
>>> + fence_udelay(1, clk_base);
>>> - readl_relaxed_poll_timeout_atomic(clk_base + PLLU_BASE, reg,
>>> - reg & PLL_BASE_LOCK, 2, 1000);
>>> - if (!(reg & PLL_BASE_LOCK)) {
>>> + ret = tegra210_wait_for_mask(&pllu, PLLU_BASE, PLL_BASE_LOCK);
>>> + if (ret) {
>>> pr_err("Timed out waiting for PLL_U to lock\n");
>>> return -ETIMEDOUT;
>>> }
>>> @@ -3283,6 +3288,103 @@ static void tegra210_disable_cpu_clock(u32 cpu)
>>> }
>>> #ifdef CONFIG_PM_SLEEP
>>> +static u32 cpu_softrst_ctx[3];
>>> +static struct platform_device *dfll_pdev;
>>> +#define car_readl(_base, _off) readl_relaxed(clk_base + (_base) +
>>> ((_off) * 4))
>>> +#define car_writel(_val, _base, _off) \
>>> + writel_relaxed(_val, clk_base + (_base) + ((_off) * 4))
>>> +
>>> +static int tegra210_clk_suspend(void)
>>> +{
>>> + unsigned int i;
>>> + struct device_node *node;
>>> +
>>> + tegra_cclkg_burst_policy_save_context();
>>> +
>>> + if (!dfll_pdev) {
>>> + node = of_find_compatible_node(NULL, NULL,
>>> + "nvidia,tegra210-dfll");
>>> + if (node)
>>> + dfll_pdev = of_find_device_by_node(node);
>>> +
>>> + of_node_put(node);
>>> + if (!dfll_pdev)
>>> + pr_err("dfll node not found. no suspend for dfll\n");
>>> + }
>>> +
>>> + if (dfll_pdev)
>>> + tegra_dfll_suspend(dfll_pdev);
>>> +
>>> + /* Enable PLLP_OUT_CPU after dfll suspend */
>>> + tegra_clk_set_pllp_out_cpu(true);
>>> +
>>> + tegra_sclk_cclklp_burst_policy_save_context();
>>> +
>>> + clk_save_context();
>>> +
>>> + for (i = 0; i < ARRAY_SIZE(cpu_softrst_ctx); i++)
>>> + cpu_softrst_ctx[i] = car_readl(CPU_SOFTRST_CTRL, i);
>>> +
>>> + return 0;
>>> +}
>>> +
>>> +static void tegra210_clk_resume(void)
>>> +{
>>> + unsigned int i;
>>> + struct clk_hw *parent;
>>> + struct clk *clk;
>>> +
>>> + /*
>>> + * clk_restore_context restores clocks as per the clock tree.
>>> + *
>>> + * dfllCPU_out is first in the clock tree to get restored and it
>>> + * involves programming DFLL controller along with restoring CPUG
>>> + * clock burst policy.
>>> + *
>>> + * DFLL programming needs dfll_ref and dfll_soc peripheral clocks
>>> + * to be restores which are part ofthe peripheral clocks.
^ white-space
Please use spellchecker to avoid typos.
>>> + * So, peripheral clocks restore should happen prior to dfll clock
>>> + * restore.
>>> + */
>>> +
>>> + tegra_clk_osc_resume(clk_base);
>>> + for (i = 0; i < ARRAY_SIZE(cpu_softrst_ctx); i++)
>>> + car_writel(cpu_softrst_ctx[i], CPU_SOFTRST_CTRL, i);
>>> +
>>> + /* restore all plls and peripheral clocks */
>>> + tegra210_init_pllu();
>>> + clk_restore_context();
>>> +
>>> + fence_udelay(5, clk_base);
>>> +
>>> + /* resume SCLK and CPULP clocks */
>>> + tegra_sclk_cpulp_burst_policy_restore_context();
>>> +
>>> + /*
>>> + * restore CPUG clocks:
>>> + * - enable DFLL in open loop mode
>>> + * - switch CPUG to DFLL clock source
>>> + * - close DFLL loop
>>> + * - sync PLLX state
>>> + */
>>> + if (dfll_pdev)
>>> + tegra_dfll_resume(dfll_pdev, false);
>>> +
>>> + tegra_cclkg_burst_policy_restore_context();
>>> + fence_udelay(2, clk_base);
>>> +
>>> + if (dfll_pdev)
>>> + tegra_dfll_resume(dfll_pdev, true);
>>> +
>>> + parent =
>>> clk_hw_get_parent(__clk_get_hw(clks[TEGRA210_CLK_CCLK_G]));
>>> + clk = clks[TEGRA210_CLK_PLL_X];
>>> + if (parent != __clk_get_hw(clk))
>>> + tegra_clk_sync_state_pll(__clk_get_hw(clk));
>>> +
>>> + /* Disable PLL_OUT_CPU after DFLL resume */
>>> + tegra_clk_set_pllp_out_cpu(false);
>>> +}
>>> +
>>> static void tegra210_cpu_clock_suspend(void)
>>> {
>>> /* switch coresite to clk_m, save off original source */
>>> @@ -3298,6 +3400,11 @@ static void tegra210_cpu_clock_resume(void)
>>> }
>>> #endif
>>> +static struct syscore_ops tegra_clk_syscore_ops = {
>>> + .suspend = tegra210_clk_suspend,
>>> + .resume = tegra210_clk_resume,
>>> +};
>>> +
>>> static struct tegra_cpu_car_ops tegra210_cpu_car_ops = {
>>> .wait_for_reset = tegra210_wait_cpu_in_reset,
>>> .disable_clock = tegra210_disable_cpu_clock,
>>> @@ -3583,5 +3690,7 @@ static void __init tegra210_clock_init(struct
>>> device_node *np)
>>> tegra210_mbist_clk_init();
>>> tegra_cpu_car_ops = &tegra210_cpu_car_ops;
>>> +
>>> + register_syscore_ops(&tegra_clk_syscore_ops);
>>> }
>> Is it really worthwhile to use syscore_ops for suspend/resume given
>> that drivers for
>> won't resume before the CLK driver anyway? Are there any other options
>> for CLK
>> suspend/resume?
>>
>> I'm also not sure whether PM runtime API could be used at all in the
>> context of
>> syscore_ops ..
>>
>> Secondly, what about to use generic clk_save_context() /
>> clk_restore_context()
>> helpers for the suspend-resume? It looks to me that some other
>> essential (and proper)
>> platform driver (soc/tegra/? PMC?) should suspend-resume the clocks
>> using the generic
>> CLK Framework API.
>
> Clock resume should happen very early to restore peripheral and cpu
> clocks very early than peripheral drivers resume happens.
If all peripheral drivers properly requested all of the necessary clocks
and CLK driver was a platform driver, then I guess the probe should have
been naturally ordered. But that's not very achievable with the
currently available infrastructure in the kernel, so I'm not arguing
that the clocks should be explicitly resumed before the users.
> this patch series uses clk_save_context and clk_restore_context for
> corresponding divider, pll, pllout.. save and restore context.
Now I see that indeed this API is utilized in this patch, thank you for
the clarification.
> But as there is dependency on dfll resume and cpu and pllx clocks
> restore, couldnt use clk_save_context and clk_restore_context for dfll.
>
> So implemented recommended dfll resume sequence in main Tegra210 clock
> driver along with invoking clk_save_context/clk_restore_context where
> all other clocks save/restore happens as per clock tree traversal.
Could you please clarify what part of peripherals clocks is required for
DFLL's restore? Couldn't DFLL driver be changed to avoid that quirkness
and thus to make DFLL driver suspend/resume the clock?
^ permalink raw reply
* Re: [PATCH v2 2/2] iio: light: noa1305: Add support for NOA1305
From: Jonathan Cameron @ 2019-07-14 17:14 UTC (permalink / raw)
To: Martyn Welch
Cc: Rob Herring, Mark Rutland, Hartmut Knaack, Lars-Peter Clausen,
Peter Meerwald-Stadler, linux-iio, linux-kernel, kernel,
devicetree, Sergei M
In-Reply-To: <20190628175713.14831-2-martyn.welch@collabora.com>
On Fri, 28 Jun 2019 18:57:13 +0100
Martyn Welch <martyn.welch@collabora.com> wrote:
> This driver adds the initial support for the ON Semiconductor
> NOA1305 Ambient Light Sensor.
>
> Originally written by Sergei Miroshnichenko. Found here:
> https://github.com/EmcraftSystems/linux-upstream/commit/196d6cf897e632d2cb82d45484bd7a1bfdd5b6d9
>
> Signed-off-by: Sergei M <fizik1@yandex.com>
> Signed-off-by: Martyn Welch <martyn.welch@collabora.com>
A few minor things inline.
Thanks,
Jonathan
> ---
>
> Changes:
> v2: Correcting authorship and SOB.
>
> drivers/iio/light/Kconfig | 10 ++
> drivers/iio/light/Makefile | 1 +
> drivers/iio/light/noa1305.c | 247 ++++++++++++++++++++++++++++++++++++
> 3 files changed, 258 insertions(+)
> create mode 100644 drivers/iio/light/noa1305.c
>
> diff --git a/drivers/iio/light/Kconfig b/drivers/iio/light/Kconfig
> index 954c958cfc43..d1db0ec0d0f5 100644
> --- a/drivers/iio/light/Kconfig
> +++ b/drivers/iio/light/Kconfig
> @@ -309,6 +309,16 @@ config MAX44009
> To compile this driver as a module, choose M here:
> the module will be called max44009.
>
> +config NOA1305
> + tristate "ON Semiconductor NOA1305 ambient light sensor"
> + depends on I2C
> + help
> + Say Y here if you want to build support for the ON Semiconductor
> + NOA1305 ambient light sensor.
> +
> + To compile this driver as a module, choose M here:
> + The module will be called noa1305.
> +
> config OPT3001
> tristate "Texas Instruments OPT3001 Light Sensor"
> depends on I2C
> diff --git a/drivers/iio/light/Makefile b/drivers/iio/light/Makefile
> index e40794fbb435..00d1f9b98f39 100644
> --- a/drivers/iio/light/Makefile
> +++ b/drivers/iio/light/Makefile
> @@ -29,6 +29,7 @@ obj-$(CONFIG_LTR501) += ltr501.o
> obj-$(CONFIG_LV0104CS) += lv0104cs.o
> obj-$(CONFIG_MAX44000) += max44000.o
> obj-$(CONFIG_MAX44009) += max44009.o
> +obj-$(CONFIG_NOA1305) += noa1305.o
> obj-$(CONFIG_OPT3001) += opt3001.o
> obj-$(CONFIG_PA12203001) += pa12203001.o
> obj-$(CONFIG_RPR0521) += rpr0521.o
> diff --git a/drivers/iio/light/noa1305.c b/drivers/iio/light/noa1305.c
> new file mode 100644
> index 000000000000..2c65c5c2e09a
> --- /dev/null
> +++ b/drivers/iio/light/noa1305.c
> @@ -0,0 +1,247 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Support for ON Semiconductor NOA1305 ambient light sensor
> + *
> + * Copyright (C) 2016 Emcraft Systems
> + * Copyright (C) 2019 Collabora Ltd.
> + */
> +
> +#include <linux/delay.h>
> +#include <linux/err.h>
> +#include <linux/i2c.h>
> +#include <linux/iio/iio.h>
> +#include <linux/iio/sysfs.h>
> +#include <linux/module.h>
> +#include <linux/regmap.h>
> +#include <linux/regulator/consumer.h>
> +
> +#define NOA1305_REG_POWER_CONTROL 0x0
> +#define NOA1305_REG_RESET 0x1
> +#define NOA1305_REG_INTEGRATION_TIME 0x2
> +#define NOA1305_REG_INT_SELECT 0x3
> +#define NOA1305_REG_INT_THRESH_LSB 0x4
> +#define NOA1305_REG_INT_THRESH_MSB 0x5
> +#define NOA1305_REG_ALS_DATA_LSB 0x6
> +#define NOA1305_REG_ALS_DATA_MSB 0x7
> +#define NOA1305_REG_DEVICE_ID_LSB 0x8
> +#define NOA1305_REG_DEVICE_ID_MSB 0x9
> +
> +#define NOA1305_DEVICE_ID 0x0519
> +
> +#define NOA1305_POWER_ON 0x08
> +#define NOA1305_POWER_DOWN 0x00
> +#define NOA1305_RESET 0x10
It would be good to name these in a fashion that made it
obvious they were values to write to the power control register.
NOA1305_POWER_CONTROL_ON
NOA1305_POWER_CONTROL_DOWN
NOA1305_POWER_CONTROL_RESET
perhaps?
There are other conventions we tend to use in IIO such as
#define NOA1305_POWER_CONTROL_REG 0x0
#define NOA1305_POWER_CONTROL_POWER_ON 0x08
etc..
> +
> +#define NOA1305_INT_ACTIVE_HIGH 0x01
> +#define NOA1305_INT_ACTIVE_LOW 0x02
> +#define NOA1305_INT_INACTIVE 0x03
> +
> +#define NOA1305_INTEGR_TIME_800MS 0x00
> +#define NOA1305_INTEGR_TIME_400MS 0x01
> +#define NOA1305_INTEGR_TIME_200MS 0x02
> +#define NOA1305_INTEGR_TIME_100MS 0x03
> +#define NOA1305_INTEGR_TIME_50MS 0x04
> +#define NOA1305_INTEGR_TIME_25MS 0x05
> +#define NOA1305_INTEGR_TIME_12_5MS 0x06
> +#define NOA1305_INTEGR_TIME_6_25MS 0x07
> +
> +#define NOA1305_DRIVER_NAME "noa1305"
> +
> +struct noa1305_priv {
> + struct i2c_client *client;
> + struct regmap *regmap;
> + struct regulator *vin_reg;
> +};
> +
> +static int noa1305_measure(struct noa1305_priv *priv)
> +{
> + u8 data[2];
> + int ret;
> +
> + ret = regmap_bulk_read(priv->regmap, NOA1305_REG_ALS_DATA_LSB, data,
> + 2);
> + if (ret < 0)
> + return ret;
> +
> + return (data[1] << 8) | data[0];
Make data an explicit __le16 and use an endian swap here as on
little endian platforms it'll be free.
> +}
> +
> +static const struct iio_chan_spec noa1305_channels[] = {
> + {
> + .type = IIO_LIGHT,
> + .info_mask_separate = BIT(IIO_CHAN_INFO_RAW),
> + }
> +};
> +
> +static int noa1305_read_raw(struct iio_dev *indio_dev,
> + struct iio_chan_spec const *chan,
> + int *val, int *val2, long mask)
> +{
> + int ret = -EINVAL;
> + struct noa1305_priv *priv = iio_priv(indio_dev);
> +
> + switch (mask) {
> + case IIO_CHAN_INFO_RAW:
> + switch (chan->type) {
> + case IIO_LIGHT:
> + ret = noa1305_measure(priv);
Hmm. So no information at all available on how this maps to
illuminance? If the mapping is something you were thinking
of adding later we would end up having to support this old
ABI as well as the _PROCESSED version and, whilst it's happened occasionally,
it isn't something we encourage.
Of course, if there is no documented conversion function then we
can live with this interface!
From figure 6 in the datasheet it seems linear (unusual for a
light sensor) so should be easy enough to do with offset and scale,
in which case this is fine as it is.
> + if (ret < 0)
> + return ret;
> + *val = ret;
> + ret = IIO_VAL_INT;
> + break;
> + default:
> + break;
> + }
> + break;
> + default:
> + break;
> + }
> +
> + return ret;
> +}
> +
> +static const struct iio_info noa1305_info = {
> + .read_raw = noa1305_read_raw,
> +};
> +
> +static bool noa1305_writable_reg(struct device *dev, unsigned int reg)
> +{
> + switch (reg) {
> + case NOA1305_REG_POWER_CONTROL:
> + case NOA1305_REG_RESET:
> + case NOA1305_REG_INTEGRATION_TIME:
> + case NOA1305_REG_INT_SELECT:
> + case NOA1305_REG_INT_THRESH_LSB:
> + case NOA1305_REG_INT_THRESH_MSB:
> + return true;
> + default:
> + return false;
> + }
> +}
> +
> +static const struct regmap_config noa1305_regmap_config = {
> + .name = NOA1305_DRIVER_NAME,
> + .reg_bits = 8,
> + .val_bits = 8,
> + .max_register = NOA1305_REG_DEVICE_ID_MSB,
> + .writeable_reg = noa1305_writable_reg,
> +};
> +
> +static int noa1305_probe(struct i2c_client *client,
> + const struct i2c_device_id *id)
> +{
> + struct noa1305_priv *priv;
> + struct iio_dev *indio_dev;
> + struct regmap *regmap;
> + u8 data[2];
> + unsigned int dev_id = 0;
Always set in any path where it is used, so don't do it here.
> + int ret;
> +
> + indio_dev = devm_iio_device_alloc(&client->dev, sizeof(*priv));
> + if (!indio_dev)
> + return -ENOMEM;
> +
> + regmap = devm_regmap_init_i2c(client, &noa1305_regmap_config);
> + if (IS_ERR(regmap)) {
> + dev_err(&client->dev, "Regmap initialization failed.\n");
> + return PTR_ERR(regmap);
> + }
> +
> + priv = iio_priv(indio_dev);
> +
> + priv->vin_reg = devm_regulator_get(&client->dev, "vin");
> + if (IS_ERR(priv->vin_reg)) {
> + dev_err(&client->dev, "get regulator vin failed\n");
> + return PTR_ERR(priv->vin_reg);
> + }
> +
> + ret = regulator_enable(priv->vin_reg);
> + if (ret) {
> + dev_err(&client->dev, "enable regulator vin failed\n");
> + return ret;
> + }
> +
> + i2c_set_clientdata(client, indio_dev);
> + priv->client = client;
> + priv->regmap = regmap;
> +
> + ret = regmap_bulk_read(regmap, NOA1305_REG_DEVICE_ID_LSB, data, 2);
> + if (ret < 0) {
> + dev_err(&client->dev, "ID reading failed: %d\n", ret);
> + goto error_disable_reg;
> + }
> +
> + dev_id = (data[1] << 8) | data[0];
This is just unwinding endianness, use the __*e16_to_cpu function
and an appropriate type instead of u8[2] for this.
> + if (dev_id != NOA1305_DEVICE_ID) {
> + dev_err(&client->dev, "Unknown device ID: 0x%x\n", dev_id);
> + ret = -ENODEV;
> + goto error_disable_reg;
> + }
> +
> + regmap_write(regmap, NOA1305_REG_POWER_CONTROL, NOA1305_POWER_ON);
I2C buses aren't exactly the most reliable things out there, so I'd expect
to see error handling on all these writes.
> + regmap_write(regmap, NOA1305_REG_RESET, NOA1305_RESET);
> + regmap_write(regmap, NOA1305_REG_INTEGRATION_TIME,
> + NOA1305_INTEGR_TIME_800MS);
> + regmap_write(regmap, NOA1305_REG_INT_SELECT, NOA1305_INT_INACTIVE);
> +
> + indio_dev->dev.parent = &client->dev;
> + indio_dev->info = &noa1305_info;
> + indio_dev->channels = noa1305_channels;
> + indio_dev->num_channels = ARRAY_SIZE(noa1305_channels);
> + indio_dev->name = NOA1305_DRIVER_NAME;
> + indio_dev->modes = INDIO_DIRECT_MODE;
> +
> + ret = devm_iio_device_register(&client->dev, indio_dev);
There is a race here because the regulator disable will happen in remove
before we remove the userspace interfaces. Hence it is possible
to try to read from the device whilst it has no power.
Two options. Either stop using devm for everything after the
regulator enable, or use a devm_add_action_or_reset to make
the regulator disable occur in the devm managed sequence rather than
in the manual remove funciton.
> + if (ret) {
> + dev_err(&client->dev, "registering device failed\n");
> + goto error_disable_reg;
> + }
> +
> + return ret;
> +
> +error_disable_reg:
> + regulator_disable(priv->vin_reg);
> +
> + return ret;
> +}
> +
> +static int noa1305_remove(struct i2c_client *client)
> +{
> + struct iio_dev *indio_dev = i2c_get_clientdata(client);
> + struct noa1305_priv *priv = iio_priv(indio_dev);
> +
> + regulator_disable(priv->vin_reg);
> +
> + return 0;
> +}
> +
> +static const struct of_device_id noa1305_of_match[] = {
> + { .compatible = "onnn,noa1305" },
> + { }
> +};
> +MODULE_DEVICE_TABLE(of, noa1305_of_match);
> +
> +static const struct i2c_device_id noa1305_ids[] = {
> + { "noa1305", 0 },
> + { }
> +};
> +MODULE_DEVICE_TABLE(i2c, noa1305_id);
> +
nitpick: One line is plenty.
> +
> +static struct i2c_driver noa1305_driver = {
> + .driver = {
> + .name = NOA1305_DRIVER_NAME,
> + .of_match_table = noa1305_of_match,
> + },
> + .probe = noa1305_probe,
> + .remove = noa1305_remove,
> + .id_table = noa1305_ids,
> +};
> +
> +module_i2c_driver(noa1305_driver);
> +
> +MODULE_AUTHOR("Sergei Miroshnichenko <sergeimir@emcraft.com>");
> +MODULE_AUTHOR("Martyn Welch <martyn.welch@collabora.com");
> +MODULE_DESCRIPTION("ON Semiconductor NOA1305 ambient light sensor");
> +MODULE_LICENSE("GPL");
^ permalink raw reply
* Re: [PATCH 1/2] iio: imu: st_lsm6dsx: add support to LSM6DS3TR-C
From: Jonathan Cameron @ 2019-07-14 16:27 UTC (permalink / raw)
To: Lorenzo Bianconi; +Cc: linux-iio, devicetree, lorenzo.bianconi
In-Reply-To: <c0cf032e04524d20f646993e61d5b8696b9d2fa8.1561802767.git.lorenzo@kernel.org>
On Sat, 29 Jun 2019 12:13:53 +0200
Lorenzo Bianconi <lorenzo@kernel.org> wrote:
> Add support to STM LSM6DS3TR-C 6-axis (acc + gyro) Mems sensor
> https://www.st.com/resource/en/datasheet/lsm6ds3tr-c.pdf
>
> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Applied to the togreg branch of iio.git and pushed out as testing for the
autobuilders to poke at it.
Thanks,
Jonathan
> ---
> drivers/iio/imu/st_lsm6dsx/Kconfig | 2 +-
> drivers/iio/imu/st_lsm6dsx/st_lsm6dsx.h | 2 ++
> drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_buffer.c | 8 ++++----
> drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_core.c | 5 ++++-
> drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_i2c.c | 5 +++++
> drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_spi.c | 5 +++++
> 6 files changed, 21 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/iio/imu/st_lsm6dsx/Kconfig b/drivers/iio/imu/st_lsm6dsx/Kconfig
> index 9e592973a8a6..b254d03e2043 100644
> --- a/drivers/iio/imu/st_lsm6dsx/Kconfig
> +++ b/drivers/iio/imu/st_lsm6dsx/Kconfig
> @@ -9,7 +9,7 @@ config IIO_ST_LSM6DSX
> help
> Say yes here to build support for STMicroelectronics LSM6DSx imu
> sensor. Supported devices: lsm6ds3, lsm6ds3h, lsm6dsl, lsm6dsm,
> - ism330dlc, lsm6dso, lsm6dsox, asm330lhh, lsm6dsr
> + ism330dlc, lsm6dso, lsm6dsox, asm330lhh, lsm6dsr, lsm6ds3tr-c
>
> To compile this driver as a module, choose M here: the module
> will be called st_lsm6dsx.
> diff --git a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx.h b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx.h
> index cd1642bb4ec0..ffa8402763c5 100644
> --- a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx.h
> +++ b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx.h
> @@ -23,6 +23,7 @@
> #define ST_ASM330LHH_DEV_NAME "asm330lhh"
> #define ST_LSM6DSOX_DEV_NAME "lsm6dsox"
> #define ST_LSM6DSR_DEV_NAME "lsm6dsr"
> +#define ST_LSM6DS3TRC_DEV_NAME "lsm6ds3tr-c"
>
> enum st_lsm6dsx_hw_id {
> ST_LSM6DS3_ID,
> @@ -34,6 +35,7 @@ enum st_lsm6dsx_hw_id {
> ST_ASM330LHH_ID,
> ST_LSM6DSOX_ID,
> ST_LSM6DSR_ID,
> + ST_LSM6DS3TRC_ID,
> ST_LSM6DSX_MAX_ID,
> };
>
> diff --git a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_buffer.c b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_buffer.c
> index 793598ee960a..61b20fa64108 100644
> --- a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_buffer.c
> +++ b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_buffer.c
> @@ -1,10 +1,10 @@
> /*
> * STMicroelectronics st_lsm6dsx FIFO buffer library driver
> *
> - * LSM6DS3/LSM6DS3H/LSM6DSL/LSM6DSM/ISM330DLC: The FIFO buffer can be
> - * configured to store data from gyroscope and accelerometer. Samples are
> - * queued without any tag according to a specific pattern based on
> - * 'FIFO data sets' (6 bytes each):
> + * LSM6DS3/LSM6DS3H/LSM6DSL/LSM6DSM/ISM330DLC/LSM6DS3TR-C:
> + * The FIFO buffer can be configured to store data from gyroscope and
> + * accelerometer. Samples are queued without any tag according to a
> + * specific pattern based on 'FIFO data sets' (6 bytes each):
> * - 1st data set is reserved for gyroscope data
> * - 2nd data set is reserved for accelerometer data
> * The FIFO pattern changes depending on the ODRs and decimation factors
> diff --git a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_core.c b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_core.c
> index 04233928d23e..dc479e139cfc 100644
> --- a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_core.c
> +++ b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_core.c
> @@ -17,7 +17,7 @@
> * - Gyroscope supported full-scale [dps]: +-125/+-245/+-500/+-1000/+-2000
> * - FIFO size: 8KB
> *
> - * - LSM6DS3H/LSM6DSL/LSM6DSM/ISM330DLC:
> + * - LSM6DS3H/LSM6DSL/LSM6DSM/ISM330DLC/LSM6DS3TR-C:
> * - Accelerometer/Gyroscope supported ODR [Hz]: 13, 26, 52, 104, 208, 416
> * - Accelerometer supported full-scale [g]: +-2/+-4/+-8/+-16
> * - Gyroscope supported full-scale [dps]: +-125/+-245/+-500/+-1000/+-2000
> @@ -234,6 +234,9 @@ static const struct st_lsm6dsx_settings st_lsm6dsx_sensor_settings[] = {
> }, {
> .hw_id = ST_ISM330DLC_ID,
> .name = ST_ISM330DLC_DEV_NAME,
> + }, {
> + .hw_id = ST_LSM6DS3TRC_ID,
> + .name = ST_LSM6DS3TRC_DEV_NAME,
> },
> },
> .decimator = {
> diff --git a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_i2c.c b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_i2c.c
> index 47581a4e456e..0542f64fb673 100644
> --- a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_i2c.c
> +++ b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_i2c.c
> @@ -76,6 +76,10 @@ static const struct of_device_id st_lsm6dsx_i2c_of_match[] = {
> .compatible = "st,lsm6dsr",
> .data = (void *)ST_LSM6DSR_ID,
> },
> + {
> + .compatible = "st,lsm6ds3tr-c",
> + .data = (void *)ST_LSM6DS3TRC_ID,
> + },
> {},
> };
> MODULE_DEVICE_TABLE(of, st_lsm6dsx_i2c_of_match);
> @@ -90,6 +94,7 @@ static const struct i2c_device_id st_lsm6dsx_i2c_id_table[] = {
> { ST_ASM330LHH_DEV_NAME, ST_ASM330LHH_ID },
> { ST_LSM6DSOX_DEV_NAME, ST_LSM6DSOX_ID },
> { ST_LSM6DSR_DEV_NAME, ST_LSM6DSR_ID },
> + { ST_LSM6DS3TRC_DEV_NAME, ST_LSM6DS3TRC_ID },
> {},
> };
> MODULE_DEVICE_TABLE(i2c, st_lsm6dsx_i2c_id_table);
> diff --git a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_spi.c b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_spi.c
> index facf66978a4b..4e160dcb0d7d 100644
> --- a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_spi.c
> +++ b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_spi.c
> @@ -76,6 +76,10 @@ static const struct of_device_id st_lsm6dsx_spi_of_match[] = {
> .compatible = "st,lsm6dsr",
> .data = (void *)ST_LSM6DSR_ID,
> },
> + {
> + .compatible = "st,lsm6ds3tr-c",
> + .data = (void *)ST_LSM6DS3TRC_ID,
> + },
> {},
> };
> MODULE_DEVICE_TABLE(of, st_lsm6dsx_spi_of_match);
> @@ -90,6 +94,7 @@ static const struct spi_device_id st_lsm6dsx_spi_id_table[] = {
> { ST_ASM330LHH_DEV_NAME, ST_ASM330LHH_ID },
> { ST_LSM6DSOX_DEV_NAME, ST_LSM6DSOX_ID },
> { ST_LSM6DSR_DEV_NAME, ST_LSM6DSR_ID },
> + { ST_LSM6DS3TRC_DEV_NAME, ST_LSM6DS3TRC_ID },
> {},
> };
> MODULE_DEVICE_TABLE(spi, st_lsm6dsx_spi_id_table);
^ permalink raw reply
* Re: [PATCH 2/2] dt-bindings: iio: imu: st_lsm6dsx: add lsm6ds3tr-c device bindings
From: Jonathan Cameron @ 2019-07-14 16:28 UTC (permalink / raw)
To: Lorenzo Bianconi; +Cc: linux-iio, devicetree, lorenzo.bianconi
In-Reply-To: <89edf867d6abb738527889040f030036173fd5b8.1561802767.git.lorenzo@kernel.org>
On Sat, 29 Jun 2019 12:13:54 +0200
Lorenzo Bianconi <lorenzo@kernel.org> wrote:
> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
applied.
Thanks,
Jonathan
> ---
> Documentation/devicetree/bindings/iio/imu/st_lsm6dsx.txt | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/iio/imu/st_lsm6dsx.txt b/Documentation/devicetree/bindings/iio/imu/st_lsm6dsx.txt
> index efec9ece034a..92b48f242356 100644
> --- a/Documentation/devicetree/bindings/iio/imu/st_lsm6dsx.txt
> +++ b/Documentation/devicetree/bindings/iio/imu/st_lsm6dsx.txt
> @@ -11,6 +11,7 @@ Required properties:
> "st,asm330lhh"
> "st,lsm6dsox"
> "st,lsm6dsr"
> + "st,lsm6ds3tr-c"
> - reg: i2c address of the sensor / spi cs line
>
> Optional properties:
^ permalink raw reply
* Re: [PATCH 3/5] docs: i2c: convert to ReST and add to driver-api bookset
From: Jonathan Cameron @ 2019-07-14 16:23 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Linux Doc Mailing List, Mauro Carvalho Chehab, linux-kernel,
Jonathan Corbet, Peter Rosin, Rob Herring, Mark Rutland,
Jean Delvare, Guenter Roeck, Andreas Werner, Wolfram Sang,
Rudolf Marek, Seth Heasley, Neil Horman, Vadim Pasternak,
Michael Shych, Ajay Gupta, Peter Korsgaard, Andrew Lunn,
Jim Cromie
In-Reply-To: <3997b54a2e73887b96ec665573f08ded78b71421.1561756511.git.mchehab+samsung@kernel.org>
On Fri, 28 Jun 2019 18:23:14 -0300
Mauro Carvalho Chehab <mchehab+samsung@kernel.org> wrote:
> Convert each file at I2C subsystem, renaming them to .rst and
> adding to the driver-api book.
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
For the minimal touch on iio,
Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Jonathan
> ---
> Documentation/IPMB.txt | 2 +-
> .../devicetree/bindings/i2c/i2c-mux-gpmux.txt | 2 +-
> Documentation/hwmon/adm1021.rst | 2 +-
> Documentation/hwmon/adm1275.rst | 2 +-
> Documentation/hwmon/hih6130.rst | 2 +-
> Documentation/hwmon/ibm-cffps.rst | 2 +-
> Documentation/hwmon/lm25066.rst | 2 +-
> Documentation/hwmon/max16064.rst | 2 +-
> Documentation/hwmon/max16065.rst | 2 +-
> Documentation/hwmon/max20751.rst | 2 +-
> Documentation/hwmon/max34440.rst | 2 +-
> Documentation/hwmon/max6650.rst | 2 +-
> Documentation/hwmon/max8688.rst | 2 +-
> Documentation/hwmon/menf21bmc.rst | 2 +-
> Documentation/hwmon/pcf8591.rst | 2 +-
> Documentation/hwmon/sht3x.rst | 2 +-
> Documentation/hwmon/shtc1.rst | 2 +-
> Documentation/hwmon/tmp103.rst | 2 +-
> Documentation/hwmon/tps40422.rst | 2 +-
> Documentation/hwmon/ucd9000.rst | 2 +-
> Documentation/hwmon/ucd9200.rst | 2 +-
> Documentation/hwmon/via686a.rst | 2 +-
> Documentation/hwmon/zl6100.rst | 2 +-
> .../busses/{i2c-ali1535 => i2c-ali1535.rst} | 13 +-
> .../busses/{i2c-ali1563 => i2c-ali1563.rst} | 3 +
> .../busses/{i2c-ali15x3 => i2c-ali15x3.rst} | 63 +++---
> Documentation/i2c/busses/i2c-amd-mp2 | 23 ---
> Documentation/i2c/busses/i2c-amd-mp2.rst | 25 +++
> .../i2c/busses/{i2c-amd756 => i2c-amd756.rst} | 8 +-
> .../busses/{i2c-amd8111 => i2c-amd8111.rst} | 14 +-
> .../{i2c-diolan-u2c => i2c-diolan-u2c.rst} | 3 +
> .../i2c/busses/{i2c-i801 => i2c-i801.rst} | 31 ++-
> .../i2c/busses/{i2c-ismt => i2c-ismt.rst} | 20 +-
> .../busses/{i2c-mlxcpld => i2c-mlxcpld.rst} | 6 +
> .../busses/{i2c-nforce2 => i2c-nforce2.rst} | 23 ++-
> .../{i2c-nvidia-gpu => i2c-nvidia-gpu.rst} | 6 +-
> .../i2c/busses/{i2c-ocores => i2c-ocores.rst} | 22 +-
> Documentation/i2c/busses/i2c-parport | 178 ----------------
> ...2c-parport-light => i2c-parport-light.rst} | 2 +
> Documentation/i2c/busses/i2c-parport.rst | 190 +++++++++++++++++
> .../busses/{i2c-pca-isa => i2c-pca-isa.rst} | 9 +-
> .../i2c/busses/{i2c-piix4 => i2c-piix4.rst} | 14 +-
> .../busses/{i2c-sis5595 => i2c-sis5595.rst} | 18 +-
> Documentation/i2c/busses/i2c-sis630 | 58 ------
> Documentation/i2c/busses/i2c-sis630.rst | 64 ++++++
> .../i2c/busses/{i2c-sis96x => i2c-sis96x.rst} | 28 ++-
> .../busses/{i2c-taos-evm => i2c-taos-evm.rst} | 8 +-
> .../i2c/busses/{i2c-via => i2c-via.rst} | 20 +-
> .../i2c/busses/{i2c-viapro => i2c-viapro.rst} | 12 +-
> Documentation/i2c/busses/index.rst | 33 +++
> .../i2c/busses/{scx200_acb => scx200_acb.rst} | 9 +-
> .../i2c/{dev-interface => dev-interface.rst} | 94 +++++----
> ...-considerations => dma-considerations.rst} | 0
> .../i2c/{fault-codes => fault-codes.rst} | 4 +
> .../i2c/{functionality => functionality.rst} | 18 +-
> ...ult-injection => gpio-fault-injection.rst} | 12 +-
> .../i2c/{i2c-protocol => i2c-protocol.rst} | 28 ++-
> Documentation/i2c/{i2c-stub => i2c-stub.rst} | 19 +-
> .../i2c/{i2c-topology => i2c-topology.rst} | 68 +++---
> Documentation/i2c/index.rst | 38 ++++
> ...ting-devices => instantiating-devices.rst} | 45 ++--
> .../muxes/{i2c-mux-gpio => i2c-mux-gpio.rst} | 26 +--
> ...e-parameters => old-module-parameters.rst} | 27 ++-
> ...eprom-backend => slave-eeprom-backend.rst} | 3 +-
> .../{slave-interface => slave-interface.rst} | 32 +--
> .../{smbus-protocol => smbus-protocol.rst} | 74 ++++---
> Documentation/i2c/{summary => summary.rst} | 4 +-
> ...en-bit-addresses => ten-bit-addresses.rst} | 5 +
> ...pgrading-clients => upgrading-clients.rst} | 194 +++++++++---------
> .../{writing-clients => writing-clients.rst} | 94 +++++----
> Documentation/index.rst | 1 +
> Documentation/spi/spi-sc18is602 | 2 +-
> MAINTAINERS | 48 ++---
> Next/merge.log | 6 +-
> drivers/hwmon/atxp1.c | 2 +-
> drivers/hwmon/smm665.c | 2 +-
> drivers/i2c/Kconfig | 4 +-
> drivers/i2c/busses/Kconfig | 2 +-
> drivers/i2c/busses/i2c-i801.c | 2 +-
> drivers/i2c/busses/i2c-taos-evm.c | 2 +-
> drivers/i2c/i2c-core-base.c | 4 +-
> drivers/iio/dummy/iio_simple_dummy.c | 2 +-
> drivers/rtc/rtc-ds1374.c | 2 +-
> include/linux/i2c.h | 2 +-
> 84 files changed, 1065 insertions(+), 750 deletions(-)
> rename Documentation/i2c/busses/{i2c-ali1535 => i2c-ali1535.rst} (82%)
> rename Documentation/i2c/busses/{i2c-ali1563 => i2c-ali1563.rst} (93%)
> rename Documentation/i2c/busses/{i2c-ali15x3 => i2c-ali15x3.rst} (72%)
> delete mode 100644 Documentation/i2c/busses/i2c-amd-mp2
> create mode 100644 Documentation/i2c/busses/i2c-amd-mp2.rst
> rename Documentation/i2c/busses/{i2c-amd756 => i2c-amd756.rst} (79%)
> rename Documentation/i2c/busses/{i2c-amd8111 => i2c-amd8111.rst} (66%)
> rename Documentation/i2c/busses/{i2c-diolan-u2c => i2c-diolan-u2c.rst} (91%)
> rename Documentation/i2c/busses/{i2c-i801 => i2c-i801.rst} (89%)
> rename Documentation/i2c/busses/{i2c-ismt => i2c-ismt.rst} (81%)
> rename Documentation/i2c/busses/{i2c-mlxcpld => i2c-mlxcpld.rst} (88%)
> rename Documentation/i2c/busses/{i2c-nforce2 => i2c-nforce2.rst} (68%)
> rename Documentation/i2c/busses/{i2c-nvidia-gpu => i2c-nvidia-gpu.rst} (63%)
> rename Documentation/i2c/busses/{i2c-ocores => i2c-ocores.rst} (82%)
> delete mode 100644 Documentation/i2c/busses/i2c-parport
> rename Documentation/i2c/busses/{i2c-parport-light => i2c-parport-light.rst} (92%)
> create mode 100644 Documentation/i2c/busses/i2c-parport.rst
> rename Documentation/i2c/busses/{i2c-pca-isa => i2c-pca-isa.rst} (72%)
> rename Documentation/i2c/busses/{i2c-piix4 => i2c-piix4.rst} (92%)
> rename Documentation/i2c/busses/{i2c-sis5595 => i2c-sis5595.rst} (74%)
> delete mode 100644 Documentation/i2c/busses/i2c-sis630
> create mode 100644 Documentation/i2c/busses/i2c-sis630.rst
> rename Documentation/i2c/busses/{i2c-sis96x => i2c-sis96x.rst} (75%)
> rename Documentation/i2c/busses/{i2c-taos-evm => i2c-taos-evm.rst} (91%)
> rename Documentation/i2c/busses/{i2c-via => i2c-via.rst} (61%)
> rename Documentation/i2c/busses/{i2c-viapro => i2c-viapro.rst} (87%)
> create mode 100644 Documentation/i2c/busses/index.rst
> rename Documentation/i2c/busses/{scx200_acb => scx200_acb.rst} (86%)
> rename Documentation/i2c/{dev-interface => dev-interface.rst} (71%)
> rename Documentation/i2c/{DMA-considerations => dma-considerations.rst} (100%)
> rename Documentation/i2c/{fault-codes => fault-codes.rst} (98%)
> rename Documentation/i2c/{functionality => functionality.rst} (91%)
> rename Documentation/i2c/{gpio-fault-injection => gpio-fault-injection.rst} (97%)
> rename Documentation/i2c/{i2c-protocol => i2c-protocol.rst} (83%)
> rename Documentation/i2c/{i2c-stub => i2c-stub.rst} (93%)
> rename Documentation/i2c/{i2c-topology => i2c-topology.rst} (89%)
> create mode 100644 Documentation/i2c/index.rst
> rename Documentation/i2c/{instantiating-devices => instantiating-devices.rst} (93%)
> rename Documentation/i2c/muxes/{i2c-mux-gpio => i2c-mux-gpio.rst} (85%)
> rename Documentation/i2c/{old-module-parameters => old-module-parameters.rst} (75%)
> rename Documentation/i2c/{slave-eeprom-backend => slave-eeprom-backend.rst} (90%)
> rename Documentation/i2c/{slave-interface => slave-interface.rst} (94%)
> rename Documentation/i2c/{smbus-protocol => smbus-protocol.rst} (84%)
> rename Documentation/i2c/{summary => summary.rst} (96%)
> rename Documentation/i2c/{ten-bit-addresses => ten-bit-addresses.rst} (95%)
> rename Documentation/i2c/{upgrading-clients => upgrading-clients.rst} (56%)
> rename Documentation/i2c/{writing-clients => writing-clients.rst} (91%)
>
> diff --git a/Documentation/IPMB.txt b/Documentation/IPMB.txt
> index a6ed8b68bd0f..cd20c9764705 100644
> --- a/Documentation/IPMB.txt
> +++ b/Documentation/IPMB.txt
> @@ -82,7 +82,7 @@ Instantiate the device
> ----------------------
>
> After loading the driver, you can instantiate the device as
> -described in 'Documentation/i2c/instantiating-devices'.
> +described in 'Documentation/i2c/instantiating-devices.rst'.
> If you have multiple BMCs, each connected to your Satellite MC via
> a different I2C bus, you can instantiate a device for each of
> those BMCs.
> diff --git a/Documentation/devicetree/bindings/i2c/i2c-mux-gpmux.txt b/Documentation/devicetree/bindings/i2c/i2c-mux-gpmux.txt
> index 2907dab56298..8b444b94e92f 100644
> --- a/Documentation/devicetree/bindings/i2c/i2c-mux-gpmux.txt
> +++ b/Documentation/devicetree/bindings/i2c/i2c-mux-gpmux.txt
> @@ -42,7 +42,7 @@ Optional properties:
> This means that no unrelated I2C transactions are allowed on the parent I2C
> adapter for the complete multiplexed I2C transaction.
> The properties of mux-locked and parent-locked multiplexers are discussed
> - in more detail in Documentation/i2c/i2c-topology.
> + in more detail in Documentation/i2c/i2c-topology.rst.
>
> For each i2c child node, an I2C child bus will be created. They will
> be numbered based on their order in the device tree.
> diff --git a/Documentation/hwmon/adm1021.rst b/Documentation/hwmon/adm1021.rst
> index 6cbb0f75fe00..116fb2019956 100644
> --- a/Documentation/hwmon/adm1021.rst
> +++ b/Documentation/hwmon/adm1021.rst
> @@ -142,7 +142,7 @@ loading the adm1021 module, then things are good.
> If nothing happens when loading the adm1021 module, and you are certain
> that your specific Xeon processor model includes compatible sensors, you
> will have to explicitly instantiate the sensor chips from user-space. See
> -method 4 in Documentation/i2c/instantiating-devices. Possible slave
> +method 4 in Documentation/i2c/instantiating-devices.rst. Possible slave
> addresses are 0x18, 0x1a, 0x29, 0x2b, 0x4c, or 0x4e. It is likely that
> only temp2 will be correct and temp1 will have to be ignored.
>
> diff --git a/Documentation/hwmon/adm1275.rst b/Documentation/hwmon/adm1275.rst
> index 9a1913e5b4d9..49966ed70ec6 100644
> --- a/Documentation/hwmon/adm1275.rst
> +++ b/Documentation/hwmon/adm1275.rst
> @@ -75,7 +75,7 @@ Usage Notes
> -----------
>
> This driver does not auto-detect devices. You will have to instantiate the
> -devices explicitly. Please see Documentation/i2c/instantiating-devices for
> +devices explicitly. Please see Documentation/i2c/instantiating-devices.rst for
> details.
>
> The ADM1075, unlike many other PMBus devices, does not support internal voltage
> diff --git a/Documentation/hwmon/hih6130.rst b/Documentation/hwmon/hih6130.rst
> index 649bd4be4fc2..e95d373eb693 100644
> --- a/Documentation/hwmon/hih6130.rst
> +++ b/Documentation/hwmon/hih6130.rst
> @@ -27,7 +27,7 @@ The devices communicate with the I2C protocol. All sensors are set to the same
> I2C address 0x27 by default, so an entry with I2C_BOARD_INFO("hih6130", 0x27)
> can be used in the board setup code.
>
> -Please see Documentation/i2c/instantiating-devices for details on how to
> +Please see Documentation/i2c/instantiating-devices.rst for details on how to
> instantiate I2C devices.
>
> sysfs-Interface
> diff --git a/Documentation/hwmon/ibm-cffps.rst b/Documentation/hwmon/ibm-cffps.rst
> index 52e74e39463a..ef8f3f806968 100644
> --- a/Documentation/hwmon/ibm-cffps.rst
> +++ b/Documentation/hwmon/ibm-cffps.rst
> @@ -17,7 +17,7 @@ Usage Notes
> -----------
>
> This driver does not auto-detect devices. You will have to instantiate the
> -devices explicitly. Please see Documentation/i2c/instantiating-devices for
> +devices explicitly. Please see Documentation/i2c/instantiating-devices.rst for
> details.
>
> Sysfs entries
> diff --git a/Documentation/hwmon/lm25066.rst b/Documentation/hwmon/lm25066.rst
> index da15e3094c8c..30e6e77fb3c8 100644
> --- a/Documentation/hwmon/lm25066.rst
> +++ b/Documentation/hwmon/lm25066.rst
> @@ -76,7 +76,7 @@ Usage Notes
> -----------
>
> This driver does not auto-detect devices. You will have to instantiate the
> -devices explicitly. Please see Documentation/i2c/instantiating-devices for
> +devices explicitly. Please see Documentation/i2c/instantiating-devices.rst for
> details.
>
>
> diff --git a/Documentation/hwmon/max16064.rst b/Documentation/hwmon/max16064.rst
> index 6d5e9538991f..c06249292557 100644
> --- a/Documentation/hwmon/max16064.rst
> +++ b/Documentation/hwmon/max16064.rst
> @@ -28,7 +28,7 @@ Usage Notes
> -----------
>
> This driver does not auto-detect devices. You will have to instantiate the
> -devices explicitly. Please see Documentation/i2c/instantiating-devices for
> +devices explicitly. Please see Documentation/i2c/instantiating-devices.rst for
> details.
>
>
> diff --git a/Documentation/hwmon/max16065.rst b/Documentation/hwmon/max16065.rst
> index fa5c852a178c..45f69f334f25 100644
> --- a/Documentation/hwmon/max16065.rst
> +++ b/Documentation/hwmon/max16065.rst
> @@ -79,7 +79,7 @@ Usage Notes
>
> This driver does not probe for devices, since there is no register which
> can be safely used to identify the chip. You will have to instantiate
> -the devices explicitly. Please see Documentation/i2c/instantiating-devices for
> +the devices explicitly. Please see Documentation/i2c/instantiating-devices.rst for
> details.
>
> WARNING: Do not access chip registers using the i2cdump command, and do not use
> diff --git a/Documentation/hwmon/max20751.rst b/Documentation/hwmon/max20751.rst
> index aa4469be6674..fe701e07eaf5 100644
> --- a/Documentation/hwmon/max20751.rst
> +++ b/Documentation/hwmon/max20751.rst
> @@ -30,7 +30,7 @@ Usage Notes
> -----------
>
> This driver does not auto-detect devices. You will have to instantiate the
> -devices explicitly. Please see Documentation/i2c/instantiating-devices for
> +devices explicitly. Please see Documentation/i2c/instantiating-devices.rst for
> details.
>
>
> diff --git a/Documentation/hwmon/max34440.rst b/Documentation/hwmon/max34440.rst
> index 939138e12b02..5744df100a5d 100644
> --- a/Documentation/hwmon/max34440.rst
> +++ b/Documentation/hwmon/max34440.rst
> @@ -83,7 +83,7 @@ Usage Notes
> -----------
>
> This driver does not auto-detect devices. You will have to instantiate the
> -devices explicitly. Please see Documentation/i2c/instantiating-devices for
> +devices explicitly. Please see Documentation/i2c/instantiating-devices.rst for
> details.
>
> For MAX34446, the value of the currX_crit attribute determines if current or
> diff --git a/Documentation/hwmon/max6650.rst b/Documentation/hwmon/max6650.rst
> index 253482add082..7952b6ecaa2d 100644
> --- a/Documentation/hwmon/max6650.rst
> +++ b/Documentation/hwmon/max6650.rst
> @@ -55,7 +55,7 @@ Usage notes
> -----------
>
> This driver does not auto-detect devices. You will have to instantiate the
> -devices explicitly. Please see Documentation/i2c/instantiating-devices for
> +devices explicitly. Please see Documentation/i2c/instantiating-devices.rst for
> details.
>
> Module parameters
> diff --git a/Documentation/hwmon/max8688.rst b/Documentation/hwmon/max8688.rst
> index 009487759c61..71e7f2cbe2e2 100644
> --- a/Documentation/hwmon/max8688.rst
> +++ b/Documentation/hwmon/max8688.rst
> @@ -28,7 +28,7 @@ Usage Notes
> -----------
>
> This driver does not auto-detect devices. You will have to instantiate the
> -devices explicitly. Please see Documentation/i2c/instantiating-devices for
> +devices explicitly. Please see Documentation/i2c/instantiating-devices.rst for
> details.
>
>
> diff --git a/Documentation/hwmon/menf21bmc.rst b/Documentation/hwmon/menf21bmc.rst
> index 1f0c6b2235ab..978691d5956d 100644
> --- a/Documentation/hwmon/menf21bmc.rst
> +++ b/Documentation/hwmon/menf21bmc.rst
> @@ -28,7 +28,7 @@ Usage Notes
> This driver is part of the MFD driver named "menf21bmc" and does
> not auto-detect devices.
> You will have to instantiate the MFD driver explicitly.
> -Please see Documentation/i2c/instantiating-devices for
> +Please see Documentation/i2c/instantiating-devices.rst for
> details.
>
> Sysfs entries
> diff --git a/Documentation/hwmon/pcf8591.rst b/Documentation/hwmon/pcf8591.rst
> index e98bd542a441..5c4e85f53177 100644
> --- a/Documentation/hwmon/pcf8591.rst
> +++ b/Documentation/hwmon/pcf8591.rst
> @@ -68,7 +68,7 @@ Accessing PCF8591 via /sys interface
> The PCF8591 is plainly impossible to detect! Thus the driver won't even
> try. You have to explicitly instantiate the device at the relevant
> address (in the interval [0x48..0x4f]) either through platform data, or
> -using the sysfs interface. See Documentation/i2c/instantiating-devices
> +using the sysfs interface. See Documentation/i2c/instantiating-devices.rst
> for details.
>
> Directories are being created for each instantiated PCF8591:
> diff --git a/Documentation/hwmon/sht3x.rst b/Documentation/hwmon/sht3x.rst
> index 978a7117e4b2..95a850d5b2c1 100644
> --- a/Documentation/hwmon/sht3x.rst
> +++ b/Documentation/hwmon/sht3x.rst
> @@ -26,7 +26,7 @@ scaled by 1000, i.e. the value for 31.5 degrees celsius is 31500.
>
> The device communicates with the I2C protocol. Sensors can have the I2C
> addresses 0x44 or 0x45, depending on the wiring. See
> -Documentation/i2c/instantiating-devices for methods to instantiate the device.
> +Documentation/i2c/instantiating-devices.rst for methods to instantiate the device.
>
> There are two options configurable by means of sht3x_platform_data:
>
> diff --git a/Documentation/hwmon/shtc1.rst b/Documentation/hwmon/shtc1.rst
> index aa116332ba26..70c1192bbd8c 100644
> --- a/Documentation/hwmon/shtc1.rst
> +++ b/Documentation/hwmon/shtc1.rst
> @@ -36,7 +36,7 @@ humidity is expressed as a percentage. Driver can be used as well for SHTW1
> chip, which has the same electrical interface.
>
> The device communicates with the I2C protocol. All sensors are set to I2C
> -address 0x70. See Documentation/i2c/instantiating-devices for methods to
> +address 0x70. See Documentation/i2c/instantiating-devices.rst for methods to
> instantiate the device.
>
> There are two options configurable by means of shtc1_platform_data:
> diff --git a/Documentation/hwmon/tmp103.rst b/Documentation/hwmon/tmp103.rst
> index 15d25806d585..205de6148fcb 100644
> --- a/Documentation/hwmon/tmp103.rst
> +++ b/Documentation/hwmon/tmp103.rst
> @@ -30,4 +30,4 @@ The driver provides the common sysfs-interface for temperatures (see
> Documentation/hwmon/sysfs-interface.rst under Temperatures).
>
> Please refer how to instantiate this driver:
> -Documentation/i2c/instantiating-devices
> +Documentation/i2c/instantiating-devices.rst
> diff --git a/Documentation/hwmon/tps40422.rst b/Documentation/hwmon/tps40422.rst
> index b691e30479dd..8fe3e1c3572e 100644
> --- a/Documentation/hwmon/tps40422.rst
> +++ b/Documentation/hwmon/tps40422.rst
> @@ -28,7 +28,7 @@ Usage Notes
> -----------
>
> This driver does not auto-detect devices. You will have to instantiate the
> -devices explicitly. Please see Documentation/i2c/instantiating-devices for
> +devices explicitly. Please see Documentation/i2c/instantiating-devices.rst for
> details.
>
>
> diff --git a/Documentation/hwmon/ucd9000.rst b/Documentation/hwmon/ucd9000.rst
> index ebc4f2b3bfea..746f21fcb48c 100644
> --- a/Documentation/hwmon/ucd9000.rst
> +++ b/Documentation/hwmon/ucd9000.rst
> @@ -64,7 +64,7 @@ Usage Notes
> -----------
>
> This driver does not auto-detect devices. You will have to instantiate the
> -devices explicitly. Please see Documentation/i2c/instantiating-devices for
> +devices explicitly. Please see Documentation/i2c/instantiating-devices.rst for
> details.
>
>
> diff --git a/Documentation/hwmon/ucd9200.rst b/Documentation/hwmon/ucd9200.rst
> index b819dfd75f71..4f0e7c3ca6f4 100644
> --- a/Documentation/hwmon/ucd9200.rst
> +++ b/Documentation/hwmon/ucd9200.rst
> @@ -40,7 +40,7 @@ Usage Notes
> -----------
>
> This driver does not auto-detect devices. You will have to instantiate the
> -devices explicitly. Please see Documentation/i2c/instantiating-devices for
> +devices explicitly. Please see Documentation/i2c/instantiating-devices.rst for
> details.
>
>
> diff --git a/Documentation/hwmon/via686a.rst b/Documentation/hwmon/via686a.rst
> index a343c35df740..7ab9ddebcf79 100644
> --- a/Documentation/hwmon/via686a.rst
> +++ b/Documentation/hwmon/via686a.rst
> @@ -40,7 +40,7 @@ all as a 686A.
>
> The Via 686a southbridge has integrated hardware monitor functionality.
> It also has an I2C bus, but this driver only supports the hardware monitor.
> -For the I2C bus driver, see <file:Documentation/i2c/busses/i2c-viapro>
> +For the I2C bus driver, see <file:Documentation/i2c/busses/i2c-viapro.rst>
>
> The Via 686a implements three temperature sensors, two fan rotation speed
> sensors, five voltage sensors and alarms.
> diff --git a/Documentation/hwmon/zl6100.rst b/Documentation/hwmon/zl6100.rst
> index 41513bb7fe51..968aff10ce0a 100644
> --- a/Documentation/hwmon/zl6100.rst
> +++ b/Documentation/hwmon/zl6100.rst
> @@ -121,7 +121,7 @@ Usage Notes
> -----------
>
> This driver does not auto-detect devices. You will have to instantiate the
> -devices explicitly. Please see Documentation/i2c/instantiating-devices for
> +devices explicitly. Please see Documentation/i2c/instantiating-devices.rst for
> details.
>
> .. warning::
> diff --git a/Documentation/i2c/busses/i2c-ali1535 b/Documentation/i2c/busses/i2c-ali1535.rst
> similarity index 82%
> rename from Documentation/i2c/busses/i2c-ali1535
> rename to Documentation/i2c/busses/i2c-ali1535.rst
> index 5d46342e486a..6941064730dc 100644
> --- a/Documentation/i2c/busses/i2c-ali1535
> +++ b/Documentation/i2c/busses/i2c-ali1535.rst
> @@ -1,16 +1,19 @@
> +=========================
> Kernel driver i2c-ali1535
> +=========================
>
> Supported adapters:
> * Acer Labs, Inc. ALI 1535 (south bridge)
> +
> Datasheet: Now under NDA
> http://www.ali.com.tw/
>
> Authors:
> - Frodo Looijaard <frodol@dds.nl>,
> - Philip Edelbrock <phil@netroedge.com>,
> - Mark D. Studebaker <mdsxyz123@yahoo.com>,
> - Dan Eaton <dan.eaton@rocketlogix.com>,
> - Stephen Rousset<stephen.rousset@rocketlogix.com>
> + - Frodo Looijaard <frodol@dds.nl>,
> + - Philip Edelbrock <phil@netroedge.com>,
> + - Mark D. Studebaker <mdsxyz123@yahoo.com>,
> + - Dan Eaton <dan.eaton@rocketlogix.com>,
> + - Stephen Rousset<stephen.rousset@rocketlogix.com>
>
> Description
> -----------
> diff --git a/Documentation/i2c/busses/i2c-ali1563 b/Documentation/i2c/busses/i2c-ali1563.rst
> similarity index 93%
> rename from Documentation/i2c/busses/i2c-ali1563
> rename to Documentation/i2c/busses/i2c-ali1563.rst
> index 41b1a077e4c7..eec32c3ba92a 100644
> --- a/Documentation/i2c/busses/i2c-ali1563
> +++ b/Documentation/i2c/busses/i2c-ali1563.rst
> @@ -1,7 +1,10 @@
> +=========================
> Kernel driver i2c-ali1563
> +=========================
>
> Supported adapters:
> * Acer Labs, Inc. ALI 1563 (south bridge)
> +
> Datasheet: Now under NDA
> http://www.ali.com.tw/
>
> diff --git a/Documentation/i2c/busses/i2c-ali15x3 b/Documentation/i2c/busses/i2c-ali15x3.rst
> similarity index 72%
> rename from Documentation/i2c/busses/i2c-ali15x3
> rename to Documentation/i2c/busses/i2c-ali15x3.rst
> index 42888d8ac124..c70f7c66db51 100644
> --- a/Documentation/i2c/busses/i2c-ali15x3
> +++ b/Documentation/i2c/busses/i2c-ali15x3.rst
> @@ -1,20 +1,23 @@
> +=========================
> Kernel driver i2c-ali15x3
> +=========================
>
> Supported adapters:
> * Acer Labs, Inc. ALI 1533 and 1543C (south bridge)
> +
> Datasheet: Now under NDA
> http://www.ali.com.tw/
>
> Authors:
> - Frodo Looijaard <frodol@dds.nl>,
> - Philip Edelbrock <phil@netroedge.com>,
> - Mark D. Studebaker <mdsxyz123@yahoo.com>
> + - Frodo Looijaard <frodol@dds.nl>,
> + - Philip Edelbrock <phil@netroedge.com>,
> + - Mark D. Studebaker <mdsxyz123@yahoo.com>
>
> Module Parameters
> -----------------
>
> * force_addr: int
> - Initialize the base address of the i2c controller
> + Initialize the base address of the i2c controller
>
>
> Notes
> @@ -25,7 +28,9 @@ the BIOS. Does not do a PCI force; the device must still be present in
> lspci. Don't use this unless the driver complains that the base address is
> not set.
>
> -Example: 'modprobe i2c-ali15x3 force_addr=0xe800'
> +Example::
> +
> + modprobe i2c-ali15x3 force_addr=0xe800
>
> SMBus periodically hangs on ASUS P5A motherboards and can only be cleared
> by a power cycle. Cause unknown (see Issues below).
> @@ -38,47 +43,53 @@ This is the driver for the SMB Host controller on Acer Labs Inc. (ALI)
> M1541 and M1543C South Bridges.
>
> The M1543C is a South bridge for desktop systems.
> +
> The M1541 is a South bridge for portable systems.
> +
> They are part of the following ALI chipsets:
>
> * "Aladdin Pro 2" includes the M1621 Slot 1 North bridge with AGP and
> - 100MHz CPU Front Side bus
> + 100MHz CPU Front Side bus
> * "Aladdin V" includes the M1541 Socket 7 North bridge with AGP and 100MHz
> - CPU Front Side bus
> + CPU Front Side bus
> +
> Some Aladdin V motherboards:
> - Asus P5A
> - Atrend ATC-5220
> - BCM/GVC VP1541
> - Biostar M5ALA
> - Gigabyte GA-5AX (** Generally doesn't work because the BIOS doesn't
> - enable the 7101 device! **)
> - Iwill XA100 Plus
> - Micronics C200
> - Microstar (MSI) MS-5169
> + - Asus P5A
> + - Atrend ATC-5220
> + - BCM/GVC VP1541
> + - Biostar M5ALA
> + - Gigabyte GA-5AX (Generally doesn't work because the BIOS doesn't
> + enable the 7101 device!)
> + - Iwill XA100 Plus
> + - Micronics C200
> + - Microstar (MSI) MS-5169
>
> * "Aladdin IV" includes the M1541 Socket 7 North bridge
> - with host bus up to 83.3 MHz.
> + with host bus up to 83.3 MHz.
>
> For an overview of these chips see http://www.acerlabs.com. At this time the
> full data sheets on the web site are password protected, however if you
> contact the ALI office in San Jose they may give you the password.
>
> The M1533/M1543C devices appear as FOUR separate devices on the PCI bus. An
> -output of lspci will show something similar to the following:
> +output of lspci will show something similar to the following::
>
> 00:02.0 USB Controller: Acer Laboratories Inc. M5237 (rev 03)
> 00:03.0 Bridge: Acer Laboratories Inc. M7101 <= THIS IS THE ONE WE NEED
> 00:07.0 ISA bridge: Acer Laboratories Inc. M1533 (rev c3)
> 00:0f.0 IDE interface: Acer Laboratories Inc. M5229 (rev c1)
>
> -** IMPORTANT **
> -** If you have a M1533 or M1543C on the board and you get
> -** "ali15x3: Error: Can't detect ali15x3!"
> -** then run lspci.
> -** If you see the 1533 and 5229 devices but NOT the 7101 device,
> -** then you must enable ACPI, the PMU, SMB, or something similar
> -** in the BIOS.
> -** The driver won't work if it can't find the M7101 device.
> +.. important::
> +
> + If you have a M1533 or M1543C on the board and you get
> + "ali15x3: Error: Can't detect ali15x3!"
> + then run lspci.
> +
> + If you see the 1533 and 5229 devices but NOT the 7101 device,
> + then you must enable ACPI, the PMU, SMB, or something similar
> + in the BIOS.
> +
> + The driver won't work if it can't find the M7101 device.
>
> The SMB controller is part of the M7101 device, which is an ACPI-compliant
> Power Management Unit (PMU).
> diff --git a/Documentation/i2c/busses/i2c-amd-mp2 b/Documentation/i2c/busses/i2c-amd-mp2
> deleted file mode 100644
> index 6571487171f4..000000000000
> --- a/Documentation/i2c/busses/i2c-amd-mp2
> +++ /dev/null
> @@ -1,23 +0,0 @@
> -Kernel driver i2c-amd-mp2
> -
> -Supported adapters:
> - * AMD MP2 PCIe interface
> -
> -Datasheet: not publicly available.
> -
> -Authors:
> - Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
> - Nehal Shah <nehal-bakulchandra.shah@amd.com>
> - Elie Morisse <syniurge@gmail.com>
> -
> -Description
> ------------
> -
> -The MP2 is an ARM processor programmed as an I2C controller and communicating
> -with the x86 host through PCI.
> -
> -If you see something like this:
> -
> -03:00.7 MP2 I2C controller: Advanced Micro Devices, Inc. [AMD] Device 15e6
> -
> -in your 'lspci -v', then this driver is for your device.
> diff --git a/Documentation/i2c/busses/i2c-amd-mp2.rst b/Documentation/i2c/busses/i2c-amd-mp2.rst
> new file mode 100644
> index 000000000000..ebc2fa899325
> --- /dev/null
> +++ b/Documentation/i2c/busses/i2c-amd-mp2.rst
> @@ -0,0 +1,25 @@
> +=========================
> +Kernel driver i2c-amd-mp2
> +=========================
> +
> +Supported adapters:
> + * AMD MP2 PCIe interface
> +
> +Datasheet: not publicly available.
> +
> +Authors:
> + - Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
> + - Nehal Shah <nehal-bakulchandra.shah@amd.com>
> + - Elie Morisse <syniurge@gmail.com>
> +
> +Description
> +-----------
> +
> +The MP2 is an ARM processor programmed as an I2C controller and communicating
> +with the x86 host through PCI.
> +
> +If you see something like this::
> +
> + 03:00.7 MP2 I2C controller: Advanced Micro Devices, Inc. [AMD] Device 15e6
> +
> +in your ``lspci -v``, then this driver is for your device.
> diff --git a/Documentation/i2c/busses/i2c-amd756 b/Documentation/i2c/busses/i2c-amd756.rst
> similarity index 79%
> rename from Documentation/i2c/busses/i2c-amd756
> rename to Documentation/i2c/busses/i2c-amd756.rst
> index 67f30874d0bf..bc93f392a4fc 100644
> --- a/Documentation/i2c/busses/i2c-amd756
> +++ b/Documentation/i2c/busses/i2c-amd756.rst
> @@ -1,18 +1,22 @@
> +========================
> Kernel driver i2c-amd756
> +========================
>
> Supported adapters:
> * AMD 756
> * AMD 766
> * AMD 768
> * AMD 8111
> +
> Datasheets: Publicly available on AMD website
>
> * nVidia nForce
> +
> Datasheet: Unavailable
>
> Authors:
> - Frodo Looijaard <frodol@dds.nl>,
> - Philip Edelbrock <phil@netroedge.com>
> + - Frodo Looijaard <frodol@dds.nl>,
> + - Philip Edelbrock <phil@netroedge.com>
>
> Description
> -----------
> diff --git a/Documentation/i2c/busses/i2c-amd8111 b/Documentation/i2c/busses/i2c-amd8111.rst
> similarity index 66%
> rename from Documentation/i2c/busses/i2c-amd8111
> rename to Documentation/i2c/busses/i2c-amd8111.rst
> index 460dd6635fd2..d08bf0a7f0ac 100644
> --- a/Documentation/i2c/busses/i2c-amd8111
> +++ b/Documentation/i2c/busses/i2c-amd8111.rst
> @@ -1,4 +1,6 @@
> +=========================
> Kernel driver i2c-adm8111
> +=========================
>
> Supported adapters:
> * AMD-8111 SMBus 2.0 PCI interface
> @@ -13,14 +15,14 @@ Author: Vojtech Pavlik <vojtech@suse.cz>
> Description
> -----------
>
> -If you see something like this:
> +If you see something like this::
>
> -00:07.2 SMBus: Advanced Micro Devices [AMD] AMD-8111 SMBus 2.0 (rev 02)
> - Subsystem: Advanced Micro Devices [AMD] AMD-8111 SMBus 2.0
> - Flags: medium devsel, IRQ 19
> - I/O ports at d400 [size=32]
> + 00:07.2 SMBus: Advanced Micro Devices [AMD] AMD-8111 SMBus 2.0 (rev 02)
> + Subsystem: Advanced Micro Devices [AMD] AMD-8111 SMBus 2.0
> + Flags: medium devsel, IRQ 19
> + I/O ports at d400 [size=32]
>
> -in your 'lspci -v', then this driver is for your chipset.
> +in your ``lspci -v``, then this driver is for your chipset.
>
> Process Call Support
> --------------------
> diff --git a/Documentation/i2c/busses/i2c-diolan-u2c b/Documentation/i2c/busses/i2c-diolan-u2c.rst
> similarity index 91%
> rename from Documentation/i2c/busses/i2c-diolan-u2c
> rename to Documentation/i2c/busses/i2c-diolan-u2c.rst
> index 0d6018c316c7..c18cbdcdf73c 100644
> --- a/Documentation/i2c/busses/i2c-diolan-u2c
> +++ b/Documentation/i2c/busses/i2c-diolan-u2c.rst
> @@ -1,7 +1,10 @@
> +============================
> Kernel driver i2c-diolan-u2c
> +============================
>
> Supported adapters:
> * Diolan U2C-12 I2C-USB adapter
> +
> Documentation:
> http://www.diolan.com/i2c/u2c12.html
>
> diff --git a/Documentation/i2c/busses/i2c-i801 b/Documentation/i2c/busses/i2c-i801.rst
> similarity index 89%
> rename from Documentation/i2c/busses/i2c-i801
> rename to Documentation/i2c/busses/i2c-i801.rst
> index d247edcb0f99..976b42a15129 100644
> --- a/Documentation/i2c/busses/i2c-i801
> +++ b/Documentation/i2c/busses/i2c-i801.rst
> @@ -1,4 +1,7 @@
> +======================
> Kernel driver i2c-i801
> +======================
> +
>
> Supported adapters:
> * Intel 82801AA and 82801AB (ICH and ICH0 - part of the
> @@ -38,27 +41,32 @@ Supported adapters:
> * Intel Ice Lake (PCH)
> * Intel Comet Lake (PCH)
> * Intel Elkhart Lake (PCH)
> +
> Datasheets: Publicly available at the Intel website
>
> On Intel Patsburg and later chipsets, both the normal host SMBus controller
> and the additional 'Integrated Device Function' controllers are supported.
>
> Authors:
> - Mark Studebaker <mdsxyz123@yahoo.com>
> - Jean Delvare <jdelvare@suse.de>
> + - Mark Studebaker <mdsxyz123@yahoo.com>
> + - Jean Delvare <jdelvare@suse.de>
>
>
> Module Parameters
> -----------------
>
> * disable_features (bit vector)
> +
> Disable selected features normally supported by the device. This makes it
> possible to work around possible driver or hardware bugs if the feature in
> question doesn't work as intended for whatever reason. Bit values:
> +
> + ==== =========================================
> 0x01 disable SMBus PEC
> 0x02 disable the block buffer
> 0x08 disable the I2C block read functionality
> 0x10 don't use interrupts
> + ==== =========================================
>
>
> Description
> @@ -71,7 +79,7 @@ Pentium-based PCs, '815E' chipset, and others.
>
> The ICH chips contain at least SEVEN separate PCI functions in TWO logical
> PCI devices. An output of lspci will show something similar to the
> -following:
> +following::
>
> 00:1e.0 PCI bridge: Intel Corporation: Unknown device 2418 (rev 01)
> 00:1f.0 ISA bridge: Intel Corporation: Unknown device 2410 (rev 01)
> @@ -138,14 +146,14 @@ and you think there's something interesting on the SMBus (e.g. a
> hardware monitoring chip), you need to add your board to the list.
>
> The motherboard is identified using the subvendor and subdevice IDs of the
> -host bridge PCI device. Get yours with "lspci -n -v -s 00:00.0":
> +host bridge PCI device. Get yours with ``lspci -n -v -s 00:00.0``::
>
> -00:00.0 Class 0600: 8086:2570 (rev 02)
> - Subsystem: 1043:80f2
> - Flags: bus master, fast devsel, latency 0
> - Memory at fc000000 (32-bit, prefetchable) [size=32M]
> - Capabilities: [e4] #09 [2106]
> - Capabilities: [a0] AGP version 3.0
> + 00:00.0 Class 0600: 8086:2570 (rev 02)
> + Subsystem: 1043:80f2
> + Flags: bus master, fast devsel, latency 0
> + Memory at fc000000 (32-bit, prefetchable) [size=32M]
> + Capabilities: [e4] #09 [2106]
> + Capabilities: [a0] AGP version 3.0
>
> Here the host bridge ID is 2570 (82865G/PE/P), the subvendor ID is 1043
> (Asus) and the subdevice ID is 80f2 (P4P800-X). You can find the symbolic
> @@ -164,7 +172,8 @@ kernel. It's very convenient if you just want to check if there's
> anything interesting on your hidden ICH SMBus.
>
>
> -**********************
> +----------------------------------------------------------------------------
> +
> The lm_sensors project gratefully acknowledges the support of Texas
> Instruments in the initial development of this driver.
>
> diff --git a/Documentation/i2c/busses/i2c-ismt b/Documentation/i2c/busses/i2c-ismt.rst
> similarity index 81%
> rename from Documentation/i2c/busses/i2c-ismt
> rename to Documentation/i2c/busses/i2c-ismt.rst
> index 737355822c0b..8e74919a3fdf 100644
> --- a/Documentation/i2c/busses/i2c-ismt
> +++ b/Documentation/i2c/busses/i2c-ismt.rst
> @@ -1,4 +1,7 @@
> +======================
> Kernel driver i2c-ismt
> +======================
> +
>
> Supported adapters:
> * Intel S12xx series SOCs
> @@ -11,16 +14,21 @@ Module Parameters
> -----------------
>
> * bus_speed (unsigned int)
> +
> Allows changing of the bus speed. Normally, the bus speed is set by the BIOS
> and never needs to be changed. However, some SMBus analyzers are too slow for
> monitoring the bus during debug, thus the need for this module parameter.
> Specify the bus speed in kHz.
> +
> Available bus frequency settings:
> - 0 no change
> - 80 kHz
> - 100 kHz
> - 400 kHz
> - 1000 kHz
> +
> + ==== =========
> + 0 no change
> + 80 kHz
> + 100 kHz
> + 400 kHz
> + 1000 kHz
> + ==== =========
>
>
> Description
> @@ -30,7 +38,7 @@ The S12xx series of SOCs have a pair of integrated SMBus 2.0 controllers
> targeted primarily at the microserver and storage markets.
>
> The S12xx series contain a pair of PCI functions. An output of lspci will show
> -something similar to the following:
> +something similar to the following::
>
> 00:13.0 System peripheral: Intel Corporation Centerton SMBus 2.0 Controller 0
> 00:13.1 System peripheral: Intel Corporation Centerton SMBus 2.0 Controller 1
> diff --git a/Documentation/i2c/busses/i2c-mlxcpld b/Documentation/i2c/busses/i2c-mlxcpld.rst
> similarity index 88%
> rename from Documentation/i2c/busses/i2c-mlxcpld
> rename to Documentation/i2c/busses/i2c-mlxcpld.rst
> index 925904aa9b57..9a0b2916aa71 100644
> --- a/Documentation/i2c/busses/i2c-mlxcpld
> +++ b/Documentation/i2c/busses/i2c-mlxcpld.rst
> @@ -1,9 +1,12 @@
> +==================
> Driver i2c-mlxcpld
> +==================
>
> Author: Michael Shych <michaelsh@mellanox.com>
>
> This is the Mellanox I2C controller logic, implemented in Lattice CPLD
> device.
> +
> Device supports:
> - Master mode.
> - One physical bus.
> @@ -20,6 +23,8 @@ The next transaction types are supported:
> - Write Byte/Block.
>
> Registers:
> +
> +=============== === =======================================================================
> CPBLTY 0x0 - capability reg.
> Bits [6:5] - transaction length. b01 - 72B is supported,
> 36B in other case.
> @@ -49,3 +54,4 @@ DATAx 0xa - 0x54 - 68 bytes data buffer regs.
> For read transactions address is sent in a separate transaction and
> specified in the four first bytes (DATA0 - DATA3). Data is read
> starting from DATA0.
> +=============== === =======================================================================
> diff --git a/Documentation/i2c/busses/i2c-nforce2 b/Documentation/i2c/busses/i2c-nforce2.rst
> similarity index 68%
> rename from Documentation/i2c/busses/i2c-nforce2
> rename to Documentation/i2c/busses/i2c-nforce2.rst
> index 9698c396b830..f5c57ea31cd3 100644
> --- a/Documentation/i2c/busses/i2c-nforce2
> +++ b/Documentation/i2c/busses/i2c-nforce2.rst
> @@ -1,4 +1,6 @@
> +=========================
> Kernel driver i2c-nforce2
> +=========================
>
> Supported adapters:
> * nForce2 MCP 10de:0064
> @@ -16,26 +18,27 @@ Supported adapters:
> * nForce MCP78S 10de:0752
> * nForce MCP79 10de:0AA2
>
> -Datasheet: not publicly available, but seems to be similar to the
> +Datasheet:
> + not publicly available, but seems to be similar to the
> AMD-8111 SMBus 2.0 adapter.
>
> Authors:
> - Hans-Frieder Vogt <hfvogt@gmx.net>,
> - Thomas Leibold <thomas@plx.com>,
> - Patrick Dreker <patrick@dreker.de>
> + - Hans-Frieder Vogt <hfvogt@gmx.net>,
> + - Thomas Leibold <thomas@plx.com>,
> + - Patrick Dreker <patrick@dreker.de>
>
> Description
> -----------
>
> i2c-nforce2 is a driver for the SMBuses included in the nVidia nForce2 MCP.
>
> -If your 'lspci -v' listing shows something like the following,
> +If your ``lspci -v`` listing shows something like the following::
>
> -00:01.1 SMBus: nVidia Corporation: Unknown device 0064 (rev a2)
> - Subsystem: Asustek Computer, Inc.: Unknown device 0c11
> - Flags: 66Mhz, fast devsel, IRQ 5
> - I/O ports at c000 [size=32]
> - Capabilities: <available only to root>
> + 00:01.1 SMBus: nVidia Corporation: Unknown device 0064 (rev a2)
> + Subsystem: Asustek Computer, Inc.: Unknown device 0c11
> + Flags: 66Mhz, fast devsel, IRQ 5
> + I/O ports at c000 [size=32]
> + Capabilities: <available only to root>
>
> then this driver should support the SMBuses of your motherboard.
>
> diff --git a/Documentation/i2c/busses/i2c-nvidia-gpu b/Documentation/i2c/busses/i2c-nvidia-gpu.rst
> similarity index 63%
> rename from Documentation/i2c/busses/i2c-nvidia-gpu
> rename to Documentation/i2c/busses/i2c-nvidia-gpu.rst
> index 31884d2b2eb5..38fb8a4c8756 100644
> --- a/Documentation/i2c/busses/i2c-nvidia-gpu
> +++ b/Documentation/i2c/busses/i2c-nvidia-gpu.rst
> @@ -1,4 +1,6 @@
> +============================
> Kernel driver i2c-nvidia-gpu
> +============================
>
> Datasheet: not publicly available.
>
> @@ -11,8 +13,8 @@ Description
> i2c-nvidia-gpu is a driver for I2C controller included in NVIDIA Turing
> and later GPUs and it is used to communicate with Type-C controller on GPUs.
>
> -If your 'lspci -v' listing shows something like the following,
> +If your ``lspci -v`` listing shows something like the following::
>
> -01:00.3 Serial bus controller [0c80]: NVIDIA Corporation Device 1ad9 (rev a1)
> + 01:00.3 Serial bus controller [0c80]: NVIDIA Corporation Device 1ad9 (rev a1)
>
> then this driver should support the I2C controller of your GPU.
> diff --git a/Documentation/i2c/busses/i2c-ocores b/Documentation/i2c/busses/i2c-ocores.rst
> similarity index 82%
> rename from Documentation/i2c/busses/i2c-ocores
> rename to Documentation/i2c/busses/i2c-ocores.rst
> index 9caaf7df1b2f..f5e175f2a2a6 100644
> --- a/Documentation/i2c/busses/i2c-ocores
> +++ b/Documentation/i2c/busses/i2c-ocores.rst
> @@ -1,4 +1,6 @@
> +========================
> Kernel driver i2c-ocores
> +========================
>
> Supported adapters:
> * OpenCores.org I2C controller by Richard Herveille (see datasheet link)
> @@ -23,9 +25,9 @@ distance between registers and the input clock speed.
> There is also a possibility to attach a list of i2c_board_info which
> the i2c-ocores driver will add to the bus upon creation.
>
> -E.G. something like:
> +E.G. something like::
>
> -static struct resource ocores_resources[] = {
> + static struct resource ocores_resources[] = {
> [0] = {
> .start = MYI2C_BASEADDR,
> .end = MYI2C_BASEADDR + 8,
> @@ -36,10 +38,10 @@ static struct resource ocores_resources[] = {
> .end = MYI2C_IRQ,
> .flags = IORESOURCE_IRQ,
> },
> -};
> + };
>
> -/* optional board info */
> -struct i2c_board_info ocores_i2c_board_info[] = {
> + /* optional board info */
> + struct i2c_board_info ocores_i2c_board_info[] = {
> {
> I2C_BOARD_INFO("tsc2003", 0x48),
> .platform_data = &tsc2003_platform_data,
> @@ -49,20 +51,20 @@ struct i2c_board_info ocores_i2c_board_info[] = {
> I2C_BOARD_INFO("adv7180", 0x42 >> 1),
> .irq = ADV_IRQ
> }
> -};
> + };
>
> -static struct ocores_i2c_platform_data myi2c_data = {
> + static struct ocores_i2c_platform_data myi2c_data = {
> .regstep = 2, /* two bytes between registers */
> .clock_khz = 50000, /* input clock of 50MHz */
> .devices = ocores_i2c_board_info, /* optional table of devices */
> .num_devices = ARRAY_SIZE(ocores_i2c_board_info), /* table size */
> -};
> + };
>
> -static struct platform_device myi2c = {
> + static struct platform_device myi2c = {
> .name = "ocores-i2c",
> .dev = {
> .platform_data = &myi2c_data,
> },
> .num_resources = ARRAY_SIZE(ocores_resources),
> .resource = ocores_resources,
> -};
> + };
> diff --git a/Documentation/i2c/busses/i2c-parport b/Documentation/i2c/busses/i2c-parport
> deleted file mode 100644
> index c3dbb3bfd814..000000000000
> --- a/Documentation/i2c/busses/i2c-parport
> +++ /dev/null
> @@ -1,178 +0,0 @@
> -Kernel driver i2c-parport
> -
> -Author: Jean Delvare <jdelvare@suse.de>
> -
> -This is a unified driver for several i2c-over-parallel-port adapters,
> -such as the ones made by Philips, Velleman or ELV. This driver is
> -meant as a replacement for the older, individual drivers:
> - * i2c-philips-par
> - * i2c-elv
> - * i2c-velleman
> - * video/i2c-parport (NOT the same as this one, dedicated to home brew
> - teletext adapters)
> -
> -It currently supports the following devices:
> - * (type=0) Philips adapter
> - * (type=1) home brew teletext adapter
> - * (type=2) Velleman K8000 adapter
> - * (type=3) ELV adapter
> - * (type=4) Analog Devices ADM1032 evaluation board
> - * (type=5) Analog Devices evaluation boards: ADM1025, ADM1030, ADM1031
> - * (type=6) Barco LPT->DVI (K5800236) adapter
> - * (type=7) One For All JP1 parallel port adapter
> - * (type=8) VCT-jig
> -
> -These devices use different pinout configurations, so you have to tell
> -the driver what you have, using the type module parameter. There is no
> -way to autodetect the devices. Support for different pinout configurations
> -can be easily added when needed.
> -
> -Earlier kernels defaulted to type=0 (Philips). But now, if the type
> -parameter is missing, the driver will simply fail to initialize.
> -
> -SMBus alert support is available on adapters which have this line properly
> -connected to the parallel port's interrupt pin.
> -
> -
> -Building your own adapter
> --------------------------
> -
> -If you want to build you own i2c-over-parallel-port adapter, here is
> -a sample electronics schema (credits go to Sylvain Munaut):
> -
> -Device PC
> -Side ___________________Vdd (+) Side
> - | | |
> - --- --- ---
> - | | | | | |
> - |R| |R| |R|
> - | | | | | |
> - --- --- ---
> - | | |
> - | | /| |
> -SCL ----------x--------o |-----------x------------------- pin 2
> - | \| | |
> - | | |
> - | |\ | |
> -SDA ----------x----x---| o---x--------------------------- pin 13
> - | |/ |
> - | |
> - | /| |
> - ---------o |----------------x-------------- pin 3
> - \| | |
> - | |
> - --- ---
> - | | | |
> - |R| |R|
> - | | | |
> - --- ---
> - | |
> - ### ###
> - GND GND
> -
> -Remarks:
> - - This is the exact pinout and electronics used on the Analog Devices
> - evaluation boards.
> - /|
> - - All inverters -o |- must be 74HC05, they must be open collector output.
> - \|
> - - All resitors are 10k.
> - - Pins 18-25 of the parallel port connected to GND.
> - - Pins 4-9 (D2-D7) could be used as VDD is the driver drives them high.
> - The ADM1032 evaluation board uses D4-D7. Beware that the amount of
> - current you can draw from the parallel port is limited. Also note that
> - all connected lines MUST BE driven at the same state, else you'll short
> - circuit the output buffers! So plugging the I2C adapter after loading
> - the i2c-parport module might be a good safety since data line state
> - prior to init may be unknown.
> - - This is 5V!
> - - Obviously you cannot read SCL (so it's not really standard-compliant).
> - Pretty easy to add, just copy the SDA part and use another input pin.
> - That would give (ELV compatible pinout):
> -
> -
> -Device PC
> -Side ______________________________Vdd (+) Side
> - | | | |
> - --- --- --- ---
> - | | | | | | | |
> - |R| |R| |R| |R|
> - | | | | | | | |
> - --- --- --- ---
> - | | | |
> - | | |\ | |
> -SCL ----------x--------x--| o---x------------------------ pin 15
> - | | |/ |
> - | | |
> - | | /| |
> - | ---o |-------------x-------------- pin 2
> - | \| | |
> - | | |
> - | | |
> - | |\ | |
> -SDA ---------------x---x--| o--------x------------------- pin 10
> - | |/ |
> - | |
> - | /| |
> - ---o |------------------x--------- pin 3
> - \| | |
> - | |
> - --- ---
> - | | | |
> - |R| |R|
> - | | | |
> - --- ---
> - | |
> - ### ###
> - GND GND
> -
> -
> -If possible, you should use the same pinout configuration as existing
> -adapters do, so you won't even have to change the code.
> -
> -
> -Similar (but different) drivers
> --------------------------------
> -
> -This driver is NOT the same as the i2c-pport driver found in the i2c
> -package. The i2c-pport driver makes use of modern parallel port features so
> -that you don't need additional electronics. It has other restrictions
> -however, and was not ported to Linux 2.6 (yet).
> -
> -This driver is also NOT the same as the i2c-pcf-epp driver found in the
> -lm_sensors package. The i2c-pcf-epp driver doesn't use the parallel port as
> -an I2C bus directly. Instead, it uses it to control an external I2C bus
> -master. That driver was not ported to Linux 2.6 (yet) either.
> -
> -
> -Legacy documentation for Velleman adapter
> ------------------------------------------
> -
> -Useful links:
> -Velleman http://www.velleman.be/
> -Velleman K8000 Howto http://howto.htlw16.ac.at/k8000-howto.html
> -
> -The project has lead to new libs for the Velleman K8000 and K8005:
> - LIBK8000 v1.99.1 and LIBK8005 v0.21
> -With these libs, you can control the K8000 interface card and the K8005
> -stepper motor card with the simple commands which are in the original
> -Velleman software, like SetIOchannel, ReadADchannel, SendStepCCWFull and
> -many more, using /dev/velleman.
> - http://home.wanadoo.nl/hihihi/libk8000.htm
> - http://home.wanadoo.nl/hihihi/libk8005.htm
> - http://struyve.mine.nu:8080/index.php?block=k8000
> - http://sourceforge.net/projects/libk8005/
> -
> -
> -One For All JP1 parallel port adapter
> --------------------------------------
> -
> -The JP1 project revolves around a set of remote controls which expose
> -the I2C bus their internal configuration EEPROM lives on via a 6 pin
> -jumper in the battery compartment. More details can be found at:
> -
> -http://www.hifi-remote.com/jp1/
> -
> -Details of the simple parallel port hardware can be found at:
> -
> -http://www.hifi-remote.com/jp1/hardware.shtml
> diff --git a/Documentation/i2c/busses/i2c-parport-light b/Documentation/i2c/busses/i2c-parport-light.rst
> similarity index 92%
> rename from Documentation/i2c/busses/i2c-parport-light
> rename to Documentation/i2c/busses/i2c-parport-light.rst
> index 7071b8ba0af4..af85c8dfcd1a 100644
> --- a/Documentation/i2c/busses/i2c-parport-light
> +++ b/Documentation/i2c/busses/i2c-parport-light.rst
> @@ -1,4 +1,6 @@
> +===============================
> Kernel driver i2c-parport-light
> +===============================
>
> Author: Jean Delvare <jdelvare@suse.de>
>
> diff --git a/Documentation/i2c/busses/i2c-parport.rst b/Documentation/i2c/busses/i2c-parport.rst
> new file mode 100644
> index 000000000000..fae7c7ba9bd1
> --- /dev/null
> +++ b/Documentation/i2c/busses/i2c-parport.rst
> @@ -0,0 +1,190 @@
> +=========================
> +Kernel driver i2c-parport
> +=========================
> +
> +Author: Jean Delvare <jdelvare@suse.de>
> +
> +This is a unified driver for several i2c-over-parallel-port adapters,
> +such as the ones made by Philips, Velleman or ELV. This driver is
> +meant as a replacement for the older, individual drivers:
> +
> + * i2c-philips-par
> + * i2c-elv
> + * i2c-velleman
> + * video/i2c-parport
> + (NOT the same as this one, dedicated to home brew teletext adapters)
> +
> +It currently supports the following devices:
> +
> + * (type=0) Philips adapter
> + * (type=1) home brew teletext adapter
> + * (type=2) Velleman K8000 adapter
> + * (type=3) ELV adapter
> + * (type=4) Analog Devices ADM1032 evaluation board
> + * (type=5) Analog Devices evaluation boards: ADM1025, ADM1030, ADM1031
> + * (type=6) Barco LPT->DVI (K5800236) adapter
> + * (type=7) One For All JP1 parallel port adapter
> + * (type=8) VCT-jig
> +
> +These devices use different pinout configurations, so you have to tell
> +the driver what you have, using the type module parameter. There is no
> +way to autodetect the devices. Support for different pinout configurations
> +can be easily added when needed.
> +
> +Earlier kernels defaulted to type=0 (Philips). But now, if the type
> +parameter is missing, the driver will simply fail to initialize.
> +
> +SMBus alert support is available on adapters which have this line properly
> +connected to the parallel port's interrupt pin.
> +
> +
> +Building your own adapter
> +-------------------------
> +
> +If you want to build you own i2c-over-parallel-port adapter, here is
> +a sample electronics schema (credits go to Sylvain Munaut)::
> +
> + Device PC
> + Side ___________________Vdd (+) Side
> + | | |
> + --- --- ---
> + | | | | | |
> + |R| |R| |R|
> + | | | | | |
> + --- --- ---
> + | | |
> + | | /| |
> + SCL ----------x--------o |-----------x------------------- pin 2
> + | \| | |
> + | | |
> + | |\ | |
> + SDA ----------x----x---| o---x--------------------------- pin 13
> + | |/ |
> + | |
> + | /| |
> + ---------o |----------------x-------------- pin 3
> + \| | |
> + | |
> + --- ---
> + | | | |
> + |R| |R|
> + | | | |
> + --- ---
> + | |
> + ### ###
> + GND GND
> +
> +Remarks:
> + - This is the exact pinout and electronics used on the Analog Devices
> + evaluation boards.
> + - All inverters::
> +
> + /|
> + -o |-
> + \|
> +
> + must be 74HC05, they must be open collector output.
> + - All resitors are 10k.
> + - Pins 18-25 of the parallel port connected to GND.
> + - Pins 4-9 (D2-D7) could be used as VDD is the driver drives them high.
> + The ADM1032 evaluation board uses D4-D7. Beware that the amount of
> + current you can draw from the parallel port is limited. Also note that
> + all connected lines MUST BE driven at the same state, else you'll short
> + circuit the output buffers! So plugging the I2C adapter after loading
> + the i2c-parport module might be a good safety since data line state
> + prior to init may be unknown.
> + - This is 5V!
> + - Obviously you cannot read SCL (so it's not really standard-compliant).
> + Pretty easy to add, just copy the SDA part and use another input pin.
> + That would give (ELV compatible pinout)::
> +
> +
> + Device PC
> + Side ______________________________Vdd (+) Side
> + | | | |
> + --- --- --- ---
> + | | | | | | | |
> + |R| |R| |R| |R|
> + | | | | | | | |
> + --- --- --- ---
> + | | | |
> + | | |\ | |
> + SCL ----------x--------x--| o---x------------------------ pin 15
> + | | |/ |
> + | | |
> + | | /| |
> + | ---o |-------------x-------------- pin 2
> + | \| | |
> + | | |
> + | | |
> + | |\ | |
> + SDA ---------------x---x--| o--------x------------------- pin 10
> + | |/ |
> + | |
> + | /| |
> + ---o |------------------x--------- pin 3
> + \| | |
> + | |
> + --- ---
> + | | | |
> + |R| |R|
> + | | | |
> + --- ---
> + | |
> + ### ###
> + GND GND
> +
> +
> +If possible, you should use the same pinout configuration as existing
> +adapters do, so you won't even have to change the code.
> +
> +
> +Similar (but different) drivers
> +-------------------------------
> +
> +This driver is NOT the same as the i2c-pport driver found in the i2c
> +package. The i2c-pport driver makes use of modern parallel port features so
> +that you don't need additional electronics. It has other restrictions
> +however, and was not ported to Linux 2.6 (yet).
> +
> +This driver is also NOT the same as the i2c-pcf-epp driver found in the
> +lm_sensors package. The i2c-pcf-epp driver doesn't use the parallel port as
> +an I2C bus directly. Instead, it uses it to control an external I2C bus
> +master. That driver was not ported to Linux 2.6 (yet) either.
> +
> +
> +Legacy documentation for Velleman adapter
> +-----------------------------------------
> +
> +Useful links:
> +
> +- Velleman http://www.velleman.be/
> +- Velleman K8000 Howto http://howto.htlw16.ac.at/k8000-howto.html
> +
> +The project has lead to new libs for the Velleman K8000 and K8005:
> +
> + LIBK8000 v1.99.1 and LIBK8005 v0.21
> +
> +With these libs, you can control the K8000 interface card and the K8005
> +stepper motor card with the simple commands which are in the original
> +Velleman software, like SetIOchannel, ReadADchannel, SendStepCCWFull and
> +many more, using /dev/velleman.
> +
> + - http://home.wanadoo.nl/hihihi/libk8000.htm
> + - http://home.wanadoo.nl/hihihi/libk8005.htm
> + - http://struyve.mine.nu:8080/index.php?block=k8000
> + - http://sourceforge.net/projects/libk8005/
> +
> +
> +One For All JP1 parallel port adapter
> +-------------------------------------
> +
> +The JP1 project revolves around a set of remote controls which expose
> +the I2C bus their internal configuration EEPROM lives on via a 6 pin
> +jumper in the battery compartment. More details can be found at:
> +
> +http://www.hifi-remote.com/jp1/
> +
> +Details of the simple parallel port hardware can be found at:
> +
> +http://www.hifi-remote.com/jp1/hardware.shtml
> diff --git a/Documentation/i2c/busses/i2c-pca-isa b/Documentation/i2c/busses/i2c-pca-isa.rst
> similarity index 72%
> rename from Documentation/i2c/busses/i2c-pca-isa
> rename to Documentation/i2c/busses/i2c-pca-isa.rst
> index b044e5265488..a254010c8055 100644
> --- a/Documentation/i2c/busses/i2c-pca-isa
> +++ b/Documentation/i2c/busses/i2c-pca-isa.rst
> @@ -1,6 +1,9 @@
> +=========================
> Kernel driver i2c-pca-isa
> +=========================
>
> Supported adapters:
> +
> This driver supports ISA boards using the Philips PCA 9564
> Parallel bus to I2C bus controller
>
> @@ -10,11 +13,11 @@ Module Parameters
> -----------------
>
> * base int
> - I/O base address
> + I/O base address
> * irq int
> - IRQ interrupt
> + IRQ interrupt
> * clock int
> - Clock rate as described in table 1 of PCA9564 datasheet
> + Clock rate as described in table 1 of PCA9564 datasheet
>
> Description
> -----------
> diff --git a/Documentation/i2c/busses/i2c-piix4 b/Documentation/i2c/busses/i2c-piix4.rst
> similarity index 92%
> rename from Documentation/i2c/busses/i2c-piix4
> rename to Documentation/i2c/busses/i2c-piix4.rst
> index 2703bc3acad0..5d4744842b41 100644
> --- a/Documentation/i2c/busses/i2c-piix4
> +++ b/Documentation/i2c/busses/i2c-piix4.rst
> @@ -1,4 +1,6 @@
> +=======================
> Kernel driver i2c-piix4
> +=======================
>
> Supported adapters:
> * Intel 82371AB PIIX4 and PIIX4E
> @@ -21,8 +23,8 @@ Supported adapters:
> Datasheet: Publicly available at the SMSC website http://www.smsc.com
>
> Authors:
> - Frodo Looijaard <frodol@dds.nl>
> - Philip Edelbrock <phil@netroedge.com>
> + - Frodo Looijaard <frodol@dds.nl>
> + - Philip Edelbrock <phil@netroedge.com>
>
>
> Module Parameters
> @@ -45,10 +47,10 @@ natively understands SMBus commands and you do not have to worry about
> timing problems. The bad news is that non-SMBus devices connected to it can
> confuse it mightily. Yes, this is known to happen...
>
> -Do 'lspci -v' and see whether it contains an entry like this:
> +Do ``lspci -v`` and see whether it contains an entry like this::
>
> -0000:00:02.3 Bridge: Intel Corp. 82371AB/EB/MB PIIX4 ACPI (rev 02)
> - Flags: medium devsel, IRQ 9
> + 0000:00:02.3 Bridge: Intel Corp. 82371AB/EB/MB PIIX4 ACPI (rev 02)
> + Flags: medium devsel, IRQ 9
>
> Bus and device numbers may differ, but the function number must be
> identical (like many PCI devices, the PIIX4 incorporates a number of
> @@ -91,7 +93,7 @@ the SMI mode.
> device is located at 00:0f.0.
> 2) Now you just need to change the value in 0xD2 register. Get it first with
> command: lspci -xxx -s 00:0f.0
> - If the value is 0x3 then you need to change it to 0x1
> + If the value is 0x3 then you need to change it to 0x1:
> setpci -s 00:0f.0 d2.b=1
>
> Please note that you don't need to do that in all cases, just when the SMBus is
> diff --git a/Documentation/i2c/busses/i2c-sis5595 b/Documentation/i2c/busses/i2c-sis5595.rst
> similarity index 74%
> rename from Documentation/i2c/busses/i2c-sis5595
> rename to Documentation/i2c/busses/i2c-sis5595.rst
> index ecd21fb49a8f..5614afe35e79 100644
> --- a/Documentation/i2c/busses/i2c-sis5595
> +++ b/Documentation/i2c/busses/i2c-sis5595.rst
> @@ -1,9 +1,11 @@
> +=========================
> Kernel driver i2c-sis5595
> +=========================
>
> Authors:
> - Frodo Looijaard <frodol@dds.nl>,
> - Mark D. Studebaker <mdsxyz123@yahoo.com>,
> - Philip Edelbrock <phil@netroedge.com>
> + - Frodo Looijaard <frodol@dds.nl>,
> + - Mark D. Studebaker <mdsxyz123@yahoo.com>,
> + - Philip Edelbrock <phil@netroedge.com>
>
> Supported adapters:
> * Silicon Integrated Systems Corp. SiS5595 Southbridge
> @@ -11,14 +13,19 @@ Supported adapters:
>
> Note: all have mfr. ID 0x1039.
>
> + ========= ======
> SUPPORTED PCI ID
> + ========= ======
> 5595 0008
> + ========= ======
>
> Note: these chips contain a 0008 device which is incompatible with the
> 5595. We recognize these by the presence of the listed
> "blacklist" PCI ID and refuse to load.
>
> + ============= ====== ================
> NOT SUPPORTED PCI ID BLACKLIST PCI ID
> + ============= ====== ================
> 540 0008 0540
> 550 0008 0550
> 5513 0008 5511
> @@ -36,15 +43,18 @@ Note: all have mfr. ID 0x1039.
> 735 0008 0735
> 745 0008 0745
> 746 0008 0746
> + ============= ====== ================
>
> Module Parameters
> -----------------
>
> -* force_addr=0xaddr Set the I/O base address. Useful for boards
> +================== =====================================================
> +force_addr=0xaddr Set the I/O base address. Useful for boards
> that don't set the address in the BIOS. Does not do a
> PCI force; the device must still be present in lspci.
> Don't use this unless the driver complains that the
> base address is not set.
> +================== =====================================================
>
> Description
> -----------
> diff --git a/Documentation/i2c/busses/i2c-sis630 b/Documentation/i2c/busses/i2c-sis630
> deleted file mode 100644
> index ee7943631074..000000000000
> --- a/Documentation/i2c/busses/i2c-sis630
> +++ /dev/null
> @@ -1,58 +0,0 @@
> -Kernel driver i2c-sis630
> -
> -Supported adapters:
> - * Silicon Integrated Systems Corp (SiS)
> - 630 chipset (Datasheet: available at http://www.sfr-fresh.com/linux)
> - 730 chipset
> - 964 chipset
> - * Possible other SiS chipsets ?
> -
> -Author: Alexander Malysh <amalysh@web.de>
> - Amaury Decrême <amaury.decreme@gmail.com> - SiS964 support
> -
> -Module Parameters
> ------------------
> -
> -* force = [1|0] Forcibly enable the SIS630. DANGEROUS!
> - This can be interesting for chipsets not named
> - above to check if it works for you chipset, but DANGEROUS!
> -
> -* high_clock = [1|0] Forcibly set Host Master Clock to 56KHz (default,
> - what your BIOS use). DANGEROUS! This should be a bit
> - faster, but freeze some systems (i.e. my Laptop).
> - SIS630/730 chip only.
> -
> -
> -Description
> ------------
> -
> -This SMBus only driver is known to work on motherboards with the above
> -named chipsets.
> -
> -If you see something like this:
> -
> -00:00.0 Host bridge: Silicon Integrated Systems [SiS] 630 Host (rev 31)
> -00:01.0 ISA bridge: Silicon Integrated Systems [SiS] 85C503/5513
> -
> -or like this:
> -
> -00:00.0 Host bridge: Silicon Integrated Systems [SiS] 730 Host (rev 02)
> -00:01.0 ISA bridge: Silicon Integrated Systems [SiS] 85C503/5513
> -
> -or like this:
> -
> -00:00.0 Host bridge: Silicon Integrated Systems [SiS] 760/M760 Host (rev 02)
> -00:02.0 ISA bridge: Silicon Integrated Systems [SiS] SiS964 [MuTIOL Media IO]
> - LPC Controller (rev 36)
> -
> -in your 'lspci' output , then this driver is for your chipset.
> -
> -Thank You
> ----------
> -Philip Edelbrock <phil@netroedge.com>
> -- testing SiS730 support
> -Mark M. Hoffman <mhoffman@lightlink.com>
> -- bug fixes
> -
> -To anyone else which I forgot here ;), thanks!
> -
> diff --git a/Documentation/i2c/busses/i2c-sis630.rst b/Documentation/i2c/busses/i2c-sis630.rst
> new file mode 100644
> index 000000000000..f37700e885f2
> --- /dev/null
> +++ b/Documentation/i2c/busses/i2c-sis630.rst
> @@ -0,0 +1,64 @@
> +========================
> +Kernel driver i2c-sis630
> +========================
> +
> +Supported adapters:
> + * Silicon Integrated Systems Corp (SiS)
> + 630 chipset (Datasheet: available at http://www.sfr-fresh.com/linux)
> + 730 chipset
> + 964 chipset
> + * Possible other SiS chipsets ?
> +
> +Author:
> + - Alexander Malysh <amalysh@web.de>
> + - Amaury Decrême <amaury.decreme@gmail.com> - SiS964 support
> +
> +Module Parameters
> +-----------------
> +
> +================== =====================================================
> +force = [1|0] Forcibly enable the SIS630. DANGEROUS!
> + This can be interesting for chipsets not named
> + above to check if it works for you chipset,
> + but DANGEROUS!
> +
> +high_clock = [1|0] Forcibly set Host Master Clock to 56KHz (default,
> + what your BIOS use). DANGEROUS! This should be a bit
> + faster, but freeze some systems (i.e. my Laptop).
> + SIS630/730 chip only.
> +================== =====================================================
> +
> +
> +Description
> +-----------
> +
> +This SMBus only driver is known to work on motherboards with the above
> +named chipsets.
> +
> +If you see something like this::
> +
> + 00:00.0 Host bridge: Silicon Integrated Systems [SiS] 630 Host (rev 31)
> + 00:01.0 ISA bridge: Silicon Integrated Systems [SiS] 85C503/5513
> +
> +or like this::
> +
> + 00:00.0 Host bridge: Silicon Integrated Systems [SiS] 730 Host (rev 02)
> + 00:01.0 ISA bridge: Silicon Integrated Systems [SiS] 85C503/5513
> +
> +or like this::
> +
> + 00:00.0 Host bridge: Silicon Integrated Systems [SiS] 760/M760 Host (rev 02)
> + 00:02.0 ISA bridge: Silicon Integrated Systems [SiS] SiS964 [MuTIOL Media IO]
> + LPC Controller (rev 36)
> +
> +in your ``lspci`` output , then this driver is for your chipset.
> +
> +Thank You
> +---------
> +Philip Edelbrock <phil@netroedge.com>
> +- testing SiS730 support
> +Mark M. Hoffman <mhoffman@lightlink.com>
> +- bug fixes
> +
> +To anyone else which I forgot here ;), thanks!
> +
> diff --git a/Documentation/i2c/busses/i2c-sis96x b/Documentation/i2c/busses/i2c-sis96x.rst
> similarity index 75%
> rename from Documentation/i2c/busses/i2c-sis96x
> rename to Documentation/i2c/busses/i2c-sis96x.rst
> index 0b979f3252a4..b84581ade213 100644
> --- a/Documentation/i2c/busses/i2c-sis96x
> +++ b/Documentation/i2c/busses/i2c-sis96x.rst
> @@ -1,11 +1,16 @@
> +========================
> Kernel driver i2c-sis96x
> +========================
>
> Replaces 2.4.x i2c-sis645
>
> Supported adapters:
> +
> * Silicon Integrated Systems Corp (SiS)
> +
> Any combination of these host bridges:
> 645, 645DX (aka 646), 648, 650, 651, 655, 735, 745, 746
> +
> and these south bridges:
> 961, 962, 963(L)
>
> @@ -21,17 +26,17 @@ those of the SiS630, although they are located in a completely different
> place. Thanks to Alexander Malysh <amalysh@web.de> for providing the
> SiS630 datasheet (and driver).
>
> -The command "lspci" as root should produce something like these lines:
> +The command ``lspci`` as root should produce something like these lines::
>
> -00:00.0 Host bridge: Silicon Integrated Systems [SiS]: Unknown device 0645
> -00:02.0 ISA bridge: Silicon Integrated Systems [SiS] 85C503/5513
> -00:02.1 SMBus: Silicon Integrated Systems [SiS]: Unknown device 0016
> + 00:00.0 Host bridge: Silicon Integrated Systems [SiS]: Unknown device 0645
> + 00:02.0 ISA bridge: Silicon Integrated Systems [SiS] 85C503/5513
> + 00:02.1 SMBus: Silicon Integrated Systems [SiS]: Unknown device 0016
>
> -or perhaps this...
> +or perhaps this::
>
> -00:00.0 Host bridge: Silicon Integrated Systems [SiS]: Unknown device 0645
> -00:02.0 ISA bridge: Silicon Integrated Systems [SiS]: Unknown device 0961
> -00:02.1 SMBus: Silicon Integrated Systems [SiS]: Unknown device 0016
> + 00:00.0 Host bridge: Silicon Integrated Systems [SiS]: Unknown device 0645
> + 00:02.0 ISA bridge: Silicon Integrated Systems [SiS]: Unknown device 0961
> + 00:02.1 SMBus: Silicon Integrated Systems [SiS]: Unknown device 0016
>
> (kernel versions later than 2.4.18 may fill in the "Unknown"s)
>
> @@ -50,7 +55,7 @@ TO DOs
> ------
>
> * The driver does not support SMBus block reads/writes; I may add them if a
> -scenario is found where they're needed.
> + scenario is found where they're needed.
>
>
> Thank You
> @@ -58,14 +63,19 @@ Thank You
>
> Mark D. Studebaker <mdsxyz123@yahoo.com>
> - design hints and bug fixes
> +
> Alexander Maylsh <amalysh@web.de>
> - ditto, plus an important datasheet... almost the one I really wanted
> +
> Hans-Günter Lütke Uphues <hg_lu@t-online.de>
> - patch for SiS735
> +
> Robert Zwerus <arzie@dds.nl>
> - testing for SiS645DX
> +
> Kianusch Sayah Karadji <kianusch@sk-tech.net>
> - patch for SiS645DX/962
> +
> Ken Healy
> - patch for SiS655
>
> diff --git a/Documentation/i2c/busses/i2c-taos-evm b/Documentation/i2c/busses/i2c-taos-evm.rst
> similarity index 91%
> rename from Documentation/i2c/busses/i2c-taos-evm
> rename to Documentation/i2c/busses/i2c-taos-evm.rst
> index 60299555dcf0..f342e313ee3d 100644
> --- a/Documentation/i2c/busses/i2c-taos-evm
> +++ b/Documentation/i2c/busses/i2c-taos-evm.rst
> @@ -1,4 +1,6 @@
> +==========================
> Kernel driver i2c-taos-evm
> +==========================
>
> Author: Jean Delvare <jdelvare@suse.de>
>
> @@ -23,10 +25,10 @@ Using this driver
> In order to use this driver, you'll need the serport driver, and the
> inputattach tool, which is part of the input-utils package. The following
> commands will tell the kernel that you have a TAOS EVM on the first
> -serial port:
> +serial port::
>
> -# modprobe serport
> -# inputattach --taos-evm /dev/ttyS0
> + # modprobe serport
> + # inputattach --taos-evm /dev/ttyS0
>
>
> Technical details
> diff --git a/Documentation/i2c/busses/i2c-via b/Documentation/i2c/busses/i2c-via.rst
> similarity index 61%
> rename from Documentation/i2c/busses/i2c-via
> rename to Documentation/i2c/busses/i2c-via.rst
> index 343870661ac3..df1df5adff7b 100644
> --- a/Documentation/i2c/busses/i2c-via
> +++ b/Documentation/i2c/busses/i2c-via.rst
> @@ -1,4 +1,6 @@
> +=====================
> Kernel driver i2c-via
> +=====================
>
> Supported adapters:
> * VIA Technologies, InC. VT82C586B
> @@ -15,20 +17,24 @@ The following VIA pci chipsets are supported:
> - MVP3, VP3, VP2/97, VPX/97
> - others with South bridge VT82C586B
>
> -Your lspci listing must show this :
> +Your ``lspci`` listing must show this ::
>
> Bridge: VIA Technologies, Inc. VT82C586B ACPI (rev 10)
>
> - Problems?
> +Problems?
> +---------
>
> - Q: You have VT82C586B on the motherboard, but not in the listing.
> + Q:
> + You have VT82C586B on the motherboard, but not in the listing.
>
> - A: Go to your BIOS setup, section PCI devices or similar.
> + A:
> + Go to your BIOS setup, section PCI devices or similar.
> Turn USB support on, and try again.
>
> - Q: No error messages, but still i2c doesn't seem to work.
> + Q:
> + No error messages, but still i2c doesn't seem to work.
>
> - A: This can happen. This driver uses the pins VIA recommends in their
> + A:
> + This can happen. This driver uses the pins VIA recommends in their
> datasheets, but there are several ways the motherboard manufacturer
> can actually wire the lines.
> -
> diff --git a/Documentation/i2c/busses/i2c-viapro b/Documentation/i2c/busses/i2c-viapro.rst
> similarity index 87%
> rename from Documentation/i2c/busses/i2c-viapro
> rename to Documentation/i2c/busses/i2c-viapro.rst
> index ab64ce21c254..1762f0cf93d0 100644
> --- a/Documentation/i2c/busses/i2c-viapro
> +++ b/Documentation/i2c/busses/i2c-viapro.rst
> @@ -1,4 +1,6 @@
> +========================
> Kernel driver i2c-viapro
> +========================
>
> Supported adapters:
> * VIA Technologies, Inc. VT82C596A/B
> @@ -26,9 +28,9 @@ Supported adapters:
> Datasheet: available on http://linux.via.com.tw
>
> Authors:
> - Kyösti Mälkki <kmalkki@cc.hut.fi>,
> - Mark D. Studebaker <mdsxyz123@yahoo.com>,
> - Jean Delvare <jdelvare@suse.de>
> + - Kyösti Mälkki <kmalkki@cc.hut.fi>,
> + - Mark D. Studebaker <mdsxyz123@yahoo.com>,
> + - Jean Delvare <jdelvare@suse.de>
>
> Module Parameters
> -----------------
> @@ -44,8 +46,9 @@ Description
> i2c-viapro is a true SMBus host driver for motherboards with one of the
> supported VIA south bridges.
>
> -Your lspci -n listing must show one of these :
> +Your ``lspci -n`` listing must show one of these :
>
> + ================ ======================
> device 1106:3050 (VT82C596A function 3)
> device 1106:3051 (VT82C596B function 3)
> device 1106:3057 (VT82C686 function 4)
> @@ -61,6 +64,7 @@ Your lspci -n listing must show one of these :
> device 1106:8353 (VX800/VX820)
> device 1106:8409 (VX855/VX875)
> device 1106:8410 (VX900)
> + ================ ======================
>
> If none of these show up, you should look in the BIOS for settings like
> enable ACPI / SMBus or even USB.
> diff --git a/Documentation/i2c/busses/index.rst b/Documentation/i2c/busses/index.rst
> new file mode 100644
> index 000000000000..97ca4d510816
> --- /dev/null
> +++ b/Documentation/i2c/busses/index.rst
> @@ -0,0 +1,33 @@
> +. SPDX-License-Identifier: GPL-2.0
> +
> +===============
> +I2C Bus Drivers
> +===============
> +
> +.. toctree::
> + :maxdepth: 1
> +
> + i2c-ali1535
> + i2c-ali1563
> + i2c-ali15x3
> + i2c-amd756
> + i2c-amd8111
> + i2c-amd-mp2
> + i2c-diolan-u2c
> + i2c-i801
> + i2c-ismt
> + i2c-mlxcpld
> + i2c-nforce2
> + i2c-nvidia-gpu
> + i2c-ocores
> + i2c-parport-light
> + i2c-parport
> + i2c-pca-isa
> + i2c-piix4
> + i2c-sis5595
> + i2c-sis630
> + i2c-sis96x
> + i2c-taos-evm
> + i2c-viapro
> + i2c-via
> + scx200_acb
> diff --git a/Documentation/i2c/busses/scx200_acb b/Documentation/i2c/busses/scx200_acb.rst
> similarity index 86%
> rename from Documentation/i2c/busses/scx200_acb
> rename to Documentation/i2c/busses/scx200_acb.rst
> index ce83c871fe95..8dc7c352508c 100644
> --- a/Documentation/i2c/busses/scx200_acb
> +++ b/Documentation/i2c/busses/scx200_acb.rst
> @@ -1,4 +1,6 @@
> +========================
> Kernel driver scx200_acb
> +========================
>
> Author: Christer Weinigel <wingel@nano-system.com>
>
> @@ -25,8 +27,11 @@ Device-specific notes
>
> The SC1100 WRAP boards are known to use base addresses 0x810 and 0x820.
> If the scx200_acb driver is built into the kernel, add the following
> -parameter to your boot command line:
> +parameter to your boot command line::
> +
> scx200_acb.base=0x810,0x820
> +
> If the scx200_acb driver is built as a module, add the following line to
> -a configuration file in /etc/modprobe.d/ instead:
> +a configuration file in /etc/modprobe.d/ instead::
> +
> options scx200_acb base=0x810,0x820
> diff --git a/Documentation/i2c/dev-interface b/Documentation/i2c/dev-interface.rst
> similarity index 71%
> rename from Documentation/i2c/dev-interface
> rename to Documentation/i2c/dev-interface.rst
> index fbed645ccd75..69c23a3c2b1b 100644
> --- a/Documentation/i2c/dev-interface
> +++ b/Documentation/i2c/dev-interface.rst
> @@ -1,3 +1,7 @@
> +====================
> +I2C Device Interface
> +====================
> +
> Usually, i2c devices are controlled by a kernel driver. But it is also
> possible to access all devices on an adapter from userspace, through
> the /dev interface. You need to load module i2c-dev for this.
> @@ -18,7 +22,7 @@ C example
> =========
>
> So let's say you want to access an i2c adapter from a C program.
> -First, you need to include these two headers:
> +First, you need to include these two headers::
>
> #include <linux/i2c-dev.h>
> #include <i2c/smbus.h>
> @@ -28,7 +32,7 @@ inspect /sys/class/i2c-dev/ or run "i2cdetect -l" to decide this.
> Adapter numbers are assigned somewhat dynamically, so you can not
> assume much about them. They can even change from one boot to the next.
>
> -Next thing, open the device file, as follows:
> +Next thing, open the device file, as follows::
>
> int file;
> int adapter_nr = 2; /* probably dynamically determined */
> @@ -42,7 +46,7 @@ Next thing, open the device file, as follows:
> }
>
> When you have opened the device, you must specify with what device
> -address you want to communicate:
> +address you want to communicate::
>
> int addr = 0x40; /* The I2C address */
>
> @@ -53,7 +57,7 @@ address you want to communicate:
>
> Well, you are all set up now. You can now use SMBus commands or plain
> I2C to communicate with your device. SMBus commands are preferred if
> -the device supports them. Both are illustrated below.
> +the device supports them. Both are illustrated below::
>
> __u8 reg = 0x10; /* Device register to access */
> __s32 res;
> @@ -100,35 +104,35 @@ Full interface description
>
> The following IOCTLs are defined:
>
> -ioctl(file, I2C_SLAVE, long addr)
> +``ioctl(file, I2C_SLAVE, long addr)``
> Change slave address. The address is passed in the 7 lower bits of the
> argument (except for 10 bit addresses, passed in the 10 lower bits in this
> case).
>
> -ioctl(file, I2C_TENBIT, long select)
> +``ioctl(file, I2C_TENBIT, long select)``
> Selects ten bit addresses if select not equals 0, selects normal 7 bit
> addresses if select equals 0. Default 0. This request is only valid
> if the adapter has I2C_FUNC_10BIT_ADDR.
>
> -ioctl(file, I2C_PEC, long select)
> +``ioctl(file, I2C_PEC, long select)``
> Selects SMBus PEC (packet error checking) generation and verification
> if select not equals 0, disables if select equals 0. Default 0.
> Used only for SMBus transactions. This request only has an effect if the
> the adapter has I2C_FUNC_SMBUS_PEC; it is still safe if not, it just
> doesn't have any effect.
>
> -ioctl(file, I2C_FUNCS, unsigned long *funcs)
> - Gets the adapter functionality and puts it in *funcs.
> +``ioctl(file, I2C_FUNCS, unsigned long *funcs)``
> + Gets the adapter functionality and puts it in ``*funcs``.
>
> -ioctl(file, I2C_RDWR, struct i2c_rdwr_ioctl_data *msgset)
> +``ioctl(file, I2C_RDWR, struct i2c_rdwr_ioctl_data *msgset)``
> Do combined read/write transaction without stop in between.
> Only valid if the adapter has I2C_FUNC_I2C. The argument is
> - a pointer to a
> + a pointer to a::
>
> - struct i2c_rdwr_ioctl_data {
> + struct i2c_rdwr_ioctl_data {
> struct i2c_msg *msgs; /* ptr to array of simple messages */
> int nmsgs; /* number of messages to exchange */
> - }
> + }
>
> The msgs[] themselves contain further pointers into data buffers.
> The function will write or read data to or from that buffers depending
> @@ -136,8 +140,8 @@ ioctl(file, I2C_RDWR, struct i2c_rdwr_ioctl_data *msgset)
> The slave address and whether to use ten bit address mode has to be
> set in each message, overriding the values set with the above ioctl's.
>
> -ioctl(file, I2C_SMBUS, struct i2c_smbus_ioctl_data *args)
> - If possible, use the provided i2c_smbus_* methods described below instead
> +``ioctl(file, I2C_SMBUS, struct i2c_smbus_ioctl_data *args)``
> + If possible, use the provided ``i2c_smbus_*`` methods described below instead
> of issuing direct ioctls.
>
> You can do plain i2c transactions by using read(2) and write(2) calls.
> @@ -145,7 +149,8 @@ You do not need to pass the address byte; instead, set it through
> ioctl I2C_SLAVE before you try to access the device.
>
> You can do SMBus level transactions (see documentation file smbus-protocol
> -for details) through the following functions:
> +for details) through the following functions::
> +
> __s32 i2c_smbus_write_quick(int file, __u8 value);
> __s32 i2c_smbus_read_byte(int file);
> __s32 i2c_smbus_write_byte(int file, __u8 value);
> @@ -157,6 +162,7 @@ for details) through the following functions:
> __s32 i2c_smbus_read_block_data(int file, __u8 command, __u8 *values);
> __s32 i2c_smbus_write_block_data(int file, __u8 command, __u8 length,
> __u8 *values);
> +
> All these transactions return -1 on failure; you can read errno to see
> what happened. The 'write' transactions return 0 on success; the
> 'read' transactions return the read value, except for read_block, which
> @@ -174,39 +180,39 @@ Implementation details
> For the interested, here's the code flow which happens inside the kernel
> when you use the /dev interface to I2C:
>
> -1* Your program opens /dev/i2c-N and calls ioctl() on it, as described in
> -section "C example" above.
> +1) Your program opens /dev/i2c-N and calls ioctl() on it, as described in
> + section "C example" above.
>
> -2* These open() and ioctl() calls are handled by the i2c-dev kernel
> -driver: see i2c-dev.c:i2cdev_open() and i2c-dev.c:i2cdev_ioctl(),
> -respectively. You can think of i2c-dev as a generic I2C chip driver
> -that can be programmed from user-space.
> +2) These open() and ioctl() calls are handled by the i2c-dev kernel
> + driver: see i2c-dev.c:i2cdev_open() and i2c-dev.c:i2cdev_ioctl(),
> + respectively. You can think of i2c-dev as a generic I2C chip driver
> + that can be programmed from user-space.
>
> -3* Some ioctl() calls are for administrative tasks and are handled by
> -i2c-dev directly. Examples include I2C_SLAVE (set the address of the
> -device you want to access) and I2C_PEC (enable or disable SMBus error
> -checking on future transactions.)
> +3) Some ioctl() calls are for administrative tasks and are handled by
> + i2c-dev directly. Examples include I2C_SLAVE (set the address of the
> + device you want to access) and I2C_PEC (enable or disable SMBus error
> + checking on future transactions.)
>
> -4* Other ioctl() calls are converted to in-kernel function calls by
> -i2c-dev. Examples include I2C_FUNCS, which queries the I2C adapter
> -functionality using i2c.h:i2c_get_functionality(), and I2C_SMBUS, which
> -performs an SMBus transaction using i2c-core-smbus.c:i2c_smbus_xfer().
> +4) Other ioctl() calls are converted to in-kernel function calls by
> + i2c-dev. Examples include I2C_FUNCS, which queries the I2C adapter
> + functionality using i2c.h:i2c_get_functionality(), and I2C_SMBUS, which
> + performs an SMBus transaction using i2c-core-smbus.c:i2c_smbus_xfer().
>
> -The i2c-dev driver is responsible for checking all the parameters that
> -come from user-space for validity. After this point, there is no
> -difference between these calls that came from user-space through i2c-dev
> -and calls that would have been performed by kernel I2C chip drivers
> -directly. This means that I2C bus drivers don't need to implement
> -anything special to support access from user-space.
> + The i2c-dev driver is responsible for checking all the parameters that
> + come from user-space for validity. After this point, there is no
> + difference between these calls that came from user-space through i2c-dev
> + and calls that would have been performed by kernel I2C chip drivers
> + directly. This means that I2C bus drivers don't need to implement
> + anything special to support access from user-space.
>
> -5* These i2c.h functions are wrappers to the actual implementation of
> -your I2C bus driver. Each adapter must declare callback functions
> -implementing these standard calls. i2c.h:i2c_get_functionality() calls
> -i2c_adapter.algo->functionality(), while
> -i2c-core-smbus.c:i2c_smbus_xfer() calls either
> -adapter.algo->smbus_xfer() if it is implemented, or if not,
> -i2c-core-smbus.c:i2c_smbus_xfer_emulated() which in turn calls
> -i2c_adapter.algo->master_xfer().
> +5) These i2c.h functions are wrappers to the actual implementation of
> + your I2C bus driver. Each adapter must declare callback functions
> + implementing these standard calls. i2c.h:i2c_get_functionality() calls
> + i2c_adapter.algo->functionality(), while
> + i2c-core-smbus.c:i2c_smbus_xfer() calls either
> + adapter.algo->smbus_xfer() if it is implemented, or if not,
> + i2c-core-smbus.c:i2c_smbus_xfer_emulated() which in turn calls
> + i2c_adapter.algo->master_xfer().
>
> After your I2C bus driver has processed these requests, execution runs
> up the call chain, with almost no processing done, except by i2c-dev to
> diff --git a/Documentation/i2c/DMA-considerations b/Documentation/i2c/dma-considerations.rst
> similarity index 100%
> rename from Documentation/i2c/DMA-considerations
> rename to Documentation/i2c/dma-considerations.rst
> diff --git a/Documentation/i2c/fault-codes b/Documentation/i2c/fault-codes.rst
> similarity index 98%
> rename from Documentation/i2c/fault-codes
> rename to Documentation/i2c/fault-codes.rst
> index 0cee0fc545b4..a09797588849 100644
> --- a/Documentation/i2c/fault-codes
> +++ b/Documentation/i2c/fault-codes.rst
> @@ -1,3 +1,7 @@
> +=====================
> +I2C/SMBUS Fault Codes
> +=====================
> +
> This is a summary of the most important conventions for use of fault
> codes in the I2C/SMBus stack.
>
> diff --git a/Documentation/i2c/functionality b/Documentation/i2c/functionality.rst
> similarity index 91%
> rename from Documentation/i2c/functionality
> rename to Documentation/i2c/functionality.rst
> index 4aae8ed15873..7528c1ffd6ca 100644
> --- a/Documentation/i2c/functionality
> +++ b/Documentation/i2c/functionality.rst
> @@ -1,3 +1,7 @@
> +=======================
> +I2C/SMBus Functionality
> +=======================
> +
> INTRODUCTION
> ------------
>
> @@ -14,6 +18,7 @@ FUNCTIONALITY CONSTANTS
> For the most up-to-date list of functionality constants, please check
> <uapi/linux/i2c.h>!
>
> + =============================== ==============================================
> I2C_FUNC_I2C Plain i2c-level commands (Pure SMBus
> adapters typically can not do these)
> I2C_FUNC_10BIT_ADDR Handles the 10-bit address extensions
> @@ -33,9 +38,11 @@ For the most up-to-date list of functionality constants, please check
> I2C_FUNC_SMBUS_WRITE_BLOCK_DATA Handles the SMBus write_block_data command
> I2C_FUNC_SMBUS_READ_I2C_BLOCK Handles the SMBus read_i2c_block_data command
> I2C_FUNC_SMBUS_WRITE_I2C_BLOCK Handles the SMBus write_i2c_block_data command
> + =============================== ==============================================
>
> A few combinations of the above flags are also defined for your convenience:
>
> + ========================= ======================================
> I2C_FUNC_SMBUS_BYTE Handles the SMBus read_byte
> and write_byte commands
> I2C_FUNC_SMBUS_BYTE_DATA Handles the SMBus read_byte_data
> @@ -49,6 +56,7 @@ A few combinations of the above flags are also defined for your convenience:
> I2C_FUNC_SMBUS_EMUL Handles all SMBus commands that can be
> emulated by a real I2C adapter (using
> the transparent emulation layer)
> + ========================= ======================================
>
> In kernel versions prior to 3.5 I2C_FUNC_NOSTART was implemented as
> part of I2C_FUNC_PROTOCOL_MANGLING.
> @@ -58,11 +66,11 @@ ADAPTER IMPLEMENTATION
> ----------------------
>
> When you write a new adapter driver, you will have to implement a
> -function callback `functionality'. Typical implementations are given
> +function callback ``functionality``. Typical implementations are given
> below.
>
> A typical SMBus-only adapter would list all the SMBus transactions it
> -supports. This example comes from the i2c-piix4 driver:
> +supports. This example comes from the i2c-piix4 driver::
>
> static u32 piix4_func(struct i2c_adapter *adapter)
> {
> @@ -72,7 +80,7 @@ supports. This example comes from the i2c-piix4 driver:
> }
>
> A typical full-I2C adapter would use the following (from the i2c-pxa
> -driver):
> +driver)::
>
> static u32 i2c_pxa_functionality(struct i2c_adapter *adap)
> {
> @@ -94,7 +102,7 @@ CLIENT CHECKING
> Before a client tries to attach to an adapter, or even do tests to check
> whether one of the devices it supports is present on an adapter, it should
> check whether the needed functionality is present. The typical way to do
> -this is (from the lm75 driver):
> +this is (from the lm75 driver)::
>
> static int lm75_detect(...)
> {
> @@ -129,7 +137,7 @@ If you try to access an adapter from a userspace program, you will have
> to use the /dev interface. You will still have to check whether the
> functionality you need is supported, of course. This is done using
> the I2C_FUNCS ioctl. An example, adapted from the i2cdetect program, is
> -below:
> +below::
>
> int file;
> if (file = open("/dev/i2c-0", O_RDWR) < 0) {
> diff --git a/Documentation/i2c/gpio-fault-injection b/Documentation/i2c/gpio-fault-injection.rst
> similarity index 97%
> rename from Documentation/i2c/gpio-fault-injection
> rename to Documentation/i2c/gpio-fault-injection.rst
> index c87f416d53dd..9dca6ec7d266 100644
> --- a/Documentation/i2c/gpio-fault-injection
> +++ b/Documentation/i2c/gpio-fault-injection.rst
> @@ -104,10 +104,10 @@ There doesn't need to be a device at this address because arbitration lost
> should be detected beforehand. Also note, that SCL going down is monitored
> using interrupts, so the interrupt latency might cause the first bits to be not
> corrupted. A good starting point for using this fault injector on an otherwise
> -idle bus is:
> +idle bus is::
>
> -# echo 200 > lose_arbitration &
> -# i2cget -y <bus_to_test> 0x3f
> + # echo 200 > lose_arbitration &
> + # i2cget -y <bus_to_test> 0x3f
>
> Panic during transfer
> =====================
> @@ -127,10 +127,10 @@ The calling process will then sleep and wait for the next bus clock. The
> process is interruptible, though.
>
> Start of a transfer is detected by waiting for SCL going down by the master
> -under test. A good starting point for using this fault injector is:
> +under test. A good starting point for using this fault injector is::
>
> -# echo 0 > inject_panic &
> -# i2cget -y <bus_to_test> <some_address>
> + # echo 0 > inject_panic &
> + # i2cget -y <bus_to_test> <some_address>
>
> Note that there doesn't need to be a device listening to the address you are
> using. Results may vary depending on that, though.
> diff --git a/Documentation/i2c/i2c-protocol b/Documentation/i2c/i2c-protocol.rst
> similarity index 83%
> rename from Documentation/i2c/i2c-protocol
> rename to Documentation/i2c/i2c-protocol.rst
> index ff6d6cee6c7e..2f8fcf671b2e 100644
> --- a/Documentation/i2c/i2c-protocol
> +++ b/Documentation/i2c/i2c-protocol.rst
> @@ -1,8 +1,13 @@
> +============
> +I2C Protocol
> +============
> +
> This document describes the i2c protocol. Or will, when it is finished :-)
>
> Key to symbols
> ==============
>
> +=============== =============================================================
> S (1 bit) : Start bit
> P (1 bit) : Stop bit
> Rd/Wr (1 bit) : Read/Write bit. Rd equals 1, Wr equals 0.
> @@ -15,33 +20,35 @@ Data (8 bits): A plain data byte. Sometimes, I write DataLow, DataHigh
> for 16 bit data.
> Count (8 bits): A data byte containing the length of a block operation.
>
> -[..]: Data sent by I2C device, as opposed to data sent by the host adapter.
> +[..]: Data sent by I2C device, as opposed to data sent by the
> + host adapter.
> +=============== =============================================================
>
>
> Simple send transaction
> -======================
> +=======================
>
> -This corresponds to i2c_master_send.
> +This corresponds to i2c_master_send::
>
> S Addr Wr [A] Data [A] Data [A] ... [A] Data [A] P
>
>
> Simple receive transaction
> -===========================
> +==========================
>
> -This corresponds to i2c_master_recv
> +This corresponds to i2c_master_recv::
>
> S Addr Rd [A] [Data] A [Data] A ... A [Data] NA P
>
>
> Combined transactions
> -====================
> +=====================
>
> This corresponds to i2c_transfer
>
> They are just like the above transactions, but instead of a stop bit P
> a start bit S is sent and the transaction continues. An example of
> -a byte read, followed by a byte write:
> +a byte read, followed by a byte write::
>
> S Addr Rd [A] [Data] NA S Addr Wr [A] Data [A] P
>
> @@ -65,8 +72,10 @@ I2C_M_NO_RD_ACK:
> I2C_M_NOSTART:
> In a combined transaction, no 'S Addr Wr/Rd [A]' is generated at some
> point. For example, setting I2C_M_NOSTART on the second partial message
> - generates something like:
> + generates something like::
> +
> S Addr Rd [A] [Data] NA Data [A] P
> +
> If you set the I2C_M_NOSTART variable for the first partial message,
> we do not generate Addr, but we do generate the startbit S. This will
> probably confuse all other clients on your bus, so don't try this.
> @@ -79,7 +88,8 @@ I2C_M_NOSTART:
> I2C_M_REV_DIR_ADDR:
> This toggles the Rd/Wr flag. That is, if you want to do a write, but
> need to emit an Rd instead of a Wr, or vice versa, you set this
> - flag. For example:
> + flag. For example::
> +
> S Addr Rd [A] Data [A] Data [A] ... [A] Data [A] P
>
> I2C_M_STOP:
> diff --git a/Documentation/i2c/i2c-stub b/Documentation/i2c/i2c-stub.rst
> similarity index 93%
> rename from Documentation/i2c/i2c-stub
> rename to Documentation/i2c/i2c-stub.rst
> index a16924fbd289..f8f194dfd379 100644
> --- a/Documentation/i2c/i2c-stub
> +++ b/Documentation/i2c/i2c-stub.rst
> @@ -1,6 +1,9 @@
> -MODULE: i2c-stub
> +========
> +i2c-stub
> +========
>
> -DESCRIPTION:
> +Description
> +===========
>
> This module is a very simple fake I2C/SMBus driver. It implements six
> types of SMBus commands: write quick, (r/w) byte, (r/w) byte data, (r/w)
> @@ -28,6 +31,7 @@ SMBus block operations. Writes can be partial. Block read commands always
> return the number of bytes selected with the largest write so far.
>
> The typical use-case is like this:
> +
> 1. load this module
> 2. use i2cset (from the i2c-tools project) to pre-load some data
> 3. load the target chip driver module
> @@ -36,7 +40,8 @@ The typical use-case is like this:
> There's a script named i2c-stub-from-dump in the i2c-tools package which
> can load register values automatically from a chip dump.
>
> -PARAMETERS:
> +Parameters
> +==========
>
> int chip_addr[10]:
> The SMBus addresses to emulate chips at.
> @@ -47,14 +52,12 @@ unsigned long functionality:
> value 0x1f0000 would only enable the quick, byte and byte data
> commands.
>
> -u8 bank_reg[10]
> -u8 bank_mask[10]
> -u8 bank_start[10]
> -u8 bank_end[10]:
> +u8 bank_reg[10], u8 bank_mask[10], u8 bank_start[10], u8 bank_end[10]:
> Optional bank settings. They tell which bits in which register
> select the active bank, as well as the range of banked registers.
>
> -CAVEATS:
> +Caveats
> +=======
>
> If your target driver polls some byte or word waiting for it to change, the
> stub could lock it up. Use i2cset to unlock it.
> diff --git a/Documentation/i2c/i2c-topology b/Documentation/i2c/i2c-topology.rst
> similarity index 89%
> rename from Documentation/i2c/i2c-topology
> rename to Documentation/i2c/i2c-topology.rst
> index f74d78b53d4d..0c1ae95f6a97 100644
> --- a/Documentation/i2c/i2c-topology
> +++ b/Documentation/i2c/i2c-topology.rst
> @@ -1,3 +1,4 @@
> +============
> I2C topology
> ============
>
> @@ -14,6 +15,7 @@ than a straight-forward i2c bus with one adapter and one or more devices.
> that has to be operated before the device can be accessed.
>
> Etc
> +===
>
> These constructs are represented as i2c adapter trees by Linux, where
> each adapter has a parent adapter (except the root adapter) and zero or
> @@ -37,7 +39,9 @@ mux-locked or parent-locked muxes. As is evident from below, it can be
> useful to know if a mux is mux-locked or if it is parent-locked. The
> following list was correct at the time of writing:
>
> -In drivers/i2c/muxes/
> +In drivers/i2c/muxes/:
> +
> +====================== =============================================
> i2c-arb-gpio-challenge Parent-locked
> i2c-mux-gpio Normally parent-locked, mux-locked iff
> all involved gpio pins are controlled by the
> @@ -52,18 +56,25 @@ i2c-mux-pinctrl Normally parent-locked, mux-locked iff
> all involved pinctrl devices are controlled
> by the same i2c root adapter that they mux.
> i2c-mux-reg Parent-locked
> +====================== =============================================
>
> -In drivers/iio/
> +In drivers/iio/:
> +
> +====================== =============================================
> gyro/mpu3050 Mux-locked
> imu/inv_mpu6050/ Mux-locked
> +====================== =============================================
>
> -In drivers/media/
> +In drivers/media/:
> +
> +======================= =============================================
> dvb-frontends/lgdt3306a Mux-locked
> dvb-frontends/m88ds3103 Parent-locked
> dvb-frontends/rtl2830 Parent-locked
> dvb-frontends/rtl2832 Mux-locked
> dvb-frontends/si2168 Mux-locked
> usb/cx231xx/ Parent-locked
> +======================= =============================================
>
>
> Mux-locked muxes
> @@ -78,6 +89,7 @@ full transaction, unrelated i2c transfers may interleave the different
> stages of the transaction. This has the benefit that the mux driver
> may be easier and cleaner to implement, but it has some caveats.
>
> +==== =====================================================================
> ML1. If you build a topology with a mux-locked mux being the parent
> of a parent-locked mux, this might break the expectation from the
> parent-locked mux that the root adapter is locked during the
> @@ -105,11 +117,15 @@ ML4. If any non-i2c operation in the mux driver changes the i2c mux state,
> Otherwise garbage may appear on the bus as seen from devices
> behind the mux, when an unrelated i2c transfer is in flight during
> the non-i2c mux-changing operation.
> +==== =====================================================================
>
>
> Mux-locked Example
> ------------------
>
> +
> +::
> +
> .----------. .--------.
> .--------. | mux- |-----| dev D1 |
> | root |--+--| locked | '--------'
> @@ -148,6 +164,7 @@ adapter during the transaction are unlocked i2c transfers (using e.g.
> __i2c_transfer), or a deadlock will follow. There are a couple of
> caveats.
>
> +==== ====================================================================
> PL1. If you build a topology with a parent-locked mux being the child
> of another mux, this might break a possible assumption from the
> child mux that the root adapter is unused between its select op
> @@ -161,11 +178,14 @@ PL2. If select/deselect calls out to other subsystems such as gpio,
> caused by these subsystems are unlocked. This can be convoluted to
> accomplish, maybe even impossible if an acceptably clean solution
> is sought.
> +==== ====================================================================
>
>
> Parent-locked Example
> ---------------------
>
> +::
> +
> .----------. .--------.
> .--------. | parent- |-----| dev D1 |
> | root |--+--| locked | '--------'
> @@ -177,20 +197,20 @@ Parent-locked Example
>
> When there is an access to D1, this happens:
>
> - 1. Someone issues an i2c-transfer to D1.
> - 2. M1 locks muxes on its parent (the root adapter in this case).
> - 3. M1 locks its parent adapter.
> - 4. M1 calls ->select to ready the mux.
> - 5. If M1 does any i2c-transfers (on this root adapter) as part of
> - its select, those transfers must be unlocked i2c-transfers so
> - that they do not deadlock the root adapter.
> - 6. M1 feeds the i2c-transfer from step 1 to the root adapter as an
> - unlocked i2c-transfer, so that it does not deadlock the parent
> - adapter.
> - 7. M1 calls ->deselect, if it has one.
> - 8. Same rules as in step 5, but for ->deselect.
> - 9. M1 unlocks its parent adapter.
> -10. M1 unlocks muxes on its parent.
> + 1. Someone issues an i2c-transfer to D1.
> + 2. M1 locks muxes on its parent (the root adapter in this case).
> + 3. M1 locks its parent adapter.
> + 4. M1 calls ->select to ready the mux.
> + 5. If M1 does any i2c-transfers (on this root adapter) as part of
> + its select, those transfers must be unlocked i2c-transfers so
> + that they do not deadlock the root adapter.
> + 6. M1 feeds the i2c-transfer from step 1 to the root adapter as an
> + unlocked i2c-transfer, so that it does not deadlock the parent
> + adapter.
> + 7. M1 calls ->deselect, if it has one.
> + 8. Same rules as in step 5, but for ->deselect.
> + 9. M1 unlocks its parent adapter.
> + 10. M1 unlocks muxes on its parent.
>
>
> This means that accesses to both D2 and D3 are locked out for the full
> @@ -203,7 +223,7 @@ Complex Examples
> Parent-locked mux as parent of parent-locked mux
> ------------------------------------------------
>
> -This is a useful topology, but it can be bad.
> +This is a useful topology, but it can be bad::
>
> .----------. .----------. .--------.
> .--------. | parent- |-----| parent- |-----| dev D1 |
> @@ -227,7 +247,7 @@ through and be seen by the M2 adapter, thus closing M2 prematurely.
> Mux-locked mux as parent of mux-locked mux
> ------------------------------------------
>
> -This is a good topology.
> +This is a good topology::
>
> .----------. .----------. .--------.
> .--------. | mux- |-----| mux- |-----| dev D1 |
> @@ -248,7 +268,7 @@ are still possibly interleaved.
> Mux-locked mux as parent of parent-locked mux
> ---------------------------------------------
>
> -This is probably a bad topology.
> +This is probably a bad topology::
>
> .----------. .----------. .--------.
> .--------. | mux- |-----| parent- |-----| dev D1 |
> @@ -282,7 +302,7 @@ auto-closing, the topology is fine.
> Parent-locked mux as parent of mux-locked mux
> ---------------------------------------------
>
> -This is a good topology.
> +This is a good topology::
>
> .----------. .----------. .--------.
> .--------. | parent- |-----| mux- |-----| dev D1 |
> @@ -306,7 +326,7 @@ adapter is locked directly.
> Two mux-locked sibling muxes
> ----------------------------
>
> -This is a good topology.
> +This is a good topology::
>
> .--------.
> .----------. .--| dev D1 |
> @@ -330,7 +350,7 @@ accesses to D5 may be interleaved at any time.
> Two parent-locked sibling muxes
> -------------------------------
>
> -This is a good topology.
> +This is a good topology::
>
> .--------.
> .----------. .--| dev D1 |
> @@ -354,7 +374,7 @@ out.
> Mux-locked and parent-locked sibling muxes
> ------------------------------------------
>
> -This is a good topology.
> +This is a good topology::
>
> .--------.
> .----------. .--| dev D1 |
> diff --git a/Documentation/i2c/index.rst b/Documentation/i2c/index.rst
> new file mode 100644
> index 000000000000..d4ba671d0b55
> --- /dev/null
> +++ b/Documentation/i2c/index.rst
> @@ -0,0 +1,38 @@
> +. SPDX-License-Identifier: GPL-2.0
> +
> +===================
> +I2C/SMBus Subsystem
> +===================
> +
> +.. toctree::
> + :maxdepth: 1
> +
> + dev-interface
> + dma-considerations
> + fault-codes
> + functionality
> + gpio-fault-injection
> + i2c-protocol
> + i2c-stub
> + i2c-topology
> + instantiating-devices
> + old-module-parameters
> + slave-eeprom-backend
> + slave-interface
> + smbus-protocol
> + summary
> + ten-bit-addresses
> + upgrading-clients
> + writing-clients
> +
> + muxes/i2c-mux-gpio
> +
> + busses/index
> +
> +.. only:: subproject and html
> +
> + Indices
> + =======
> +
> + * :ref:`genindex`
> +
> diff --git a/Documentation/i2c/instantiating-devices b/Documentation/i2c/instantiating-devices.rst
> similarity index 93%
> rename from Documentation/i2c/instantiating-devices
> rename to Documentation/i2c/instantiating-devices.rst
> index 345e9ea8281a..1238f1fa3382 100644
> --- a/Documentation/i2c/instantiating-devices
> +++ b/Documentation/i2c/instantiating-devices.rst
> @@ -1,3 +1,4 @@
> +==============================
> How to instantiate I2C devices
> ==============================
>
> @@ -17,9 +18,9 @@ which is known in advance. It is thus possible to pre-declare the I2C
> devices which live on this bus. This is done with an array of struct
> i2c_board_info which is registered by calling i2c_register_board_info().
>
> -Example (from omap2 h4):
> +Example (from omap2 h4)::
>
> -static struct i2c_board_info h4_i2c_board_info[] __initdata = {
> + static struct i2c_board_info h4_i2c_board_info[] __initdata = {
> {
> I2C_BOARD_INFO("isp1301_omap", 0x2d),
> .irq = OMAP_GPIO_IRQ(125),
> @@ -32,15 +33,15 @@ static struct i2c_board_info h4_i2c_board_info[] __initdata = {
> I2C_BOARD_INFO("24c01", 0x57),
> .platform_data = &m24c01,
> },
> -};
> + };
>
> -static void __init omap_h4_init(void)
> -{
> + static void __init omap_h4_init(void)
> + {
> (...)
> i2c_register_board_info(1, h4_i2c_board_info,
> ARRAY_SIZE(h4_i2c_board_info));
> (...)
> -}
> + }
>
> The above code declares 3 devices on I2C bus 1, including their respective
> addresses and custom data needed by their drivers. When the I2C bus in
> @@ -57,7 +58,7 @@ Method 1b: Declare the I2C devices via devicetree
> This method has the same implications as method 1a. The declaration of I2C
> devices is here done via devicetree as subnodes of the master controller.
>
> -Example:
> +Example::
>
> i2c1: i2c@400a0000 {
> /* ... master properties skipped ... */
> @@ -99,20 +100,20 @@ bus in advance, so the method 1 described above can't be used. Instead,
> you can instantiate your I2C devices explicitly. This is done by filling
> a struct i2c_board_info and calling i2c_new_device().
>
> -Example (from the sfe4001 network driver):
> +Example (from the sfe4001 network driver)::
>
> -static struct i2c_board_info sfe4001_hwmon_info = {
> + static struct i2c_board_info sfe4001_hwmon_info = {
> I2C_BOARD_INFO("max6647", 0x4e),
> -};
> + };
>
> -int sfe4001_init(struct efx_nic *efx)
> -{
> + int sfe4001_init(struct efx_nic *efx)
> + {
> (...)
> efx->board_info.hwmon_client =
> i2c_new_device(&efx->i2c_adap, &sfe4001_hwmon_info);
>
> (...)
> -}
> + }
>
> The above code instantiates 1 I2C device on the I2C bus which is on the
> network adapter in question.
> @@ -124,12 +125,12 @@ it may have different addresses from one board to the next (manufacturer
> changing its design without notice). In this case, you can call
> i2c_new_probed_device() instead of i2c_new_device().
>
> -Example (from the nxp OHCI driver):
> +Example (from the nxp OHCI driver)::
>
> -static const unsigned short normal_i2c[] = { 0x2c, 0x2d, I2C_CLIENT_END };
> + static const unsigned short normal_i2c[] = { 0x2c, 0x2d, I2C_CLIENT_END };
>
> -static int usb_hcd_nxp_probe(struct platform_device *pdev)
> -{
> + static int usb_hcd_nxp_probe(struct platform_device *pdev)
> + {
> (...)
> struct i2c_adapter *i2c_adap;
> struct i2c_board_info i2c_info;
> @@ -142,7 +143,7 @@ static int usb_hcd_nxp_probe(struct platform_device *pdev)
> normal_i2c, NULL);
> i2c_put_adapter(i2c_adap);
> (...)
> -}
> + }
>
> The above code instantiates up to 1 I2C device on the I2C bus which is on
> the OHCI adapter in question. It first tries at address 0x2c, if nothing
> @@ -172,6 +173,7 @@ explicitly. Instead, i2c-core will probe for such devices as soon as their
> drivers are loaded, and if any is found, an I2C device will be
> instantiated automatically. In order to prevent any misbehavior of this
> mechanism, the following restrictions apply:
> +
> * The I2C device driver must implement the detect() method, which
> identifies a supported device by reading from arbitrary registers.
> * Only buses which are likely to have a supported device and agree to be
> @@ -189,6 +191,7 @@ first.
> Those of you familiar with the i2c subsystem of 2.4 kernels and early 2.6
> kernels will find out that this method 3 is essentially similar to what
> was done there. Two significant differences are:
> +
> * Probing is only one way to instantiate I2C devices now, while it was the
> only way back then. Where possible, methods 1 and 2 should be preferred.
> Method 3 should only be used when there is no other way, as it can have
> @@ -224,11 +227,13 @@ device. As no two devices can live at the same address on a given I2C
> segment, the address is sufficient to uniquely identify the device to be
> deleted.
>
> -Example:
> -# echo eeprom 0x50 > /sys/bus/i2c/devices/i2c-3/new_device
> +Example::
> +
> + # echo eeprom 0x50 > /sys/bus/i2c/devices/i2c-3/new_device
>
> While this interface should only be used when in-kernel device declaration
> can't be done, there is a variety of cases where it can be helpful:
> +
> * The I2C driver usually detects devices (method 3 above) but the bus
> segment your device lives on doesn't have the proper class bit set and
> thus detection doesn't trigger.
> diff --git a/Documentation/i2c/muxes/i2c-mux-gpio b/Documentation/i2c/muxes/i2c-mux-gpio.rst
> similarity index 85%
> rename from Documentation/i2c/muxes/i2c-mux-gpio
> rename to Documentation/i2c/muxes/i2c-mux-gpio.rst
> index 893ecdfe6e43..7d27444035c3 100644
> --- a/Documentation/i2c/muxes/i2c-mux-gpio
> +++ b/Documentation/i2c/muxes/i2c-mux-gpio.rst
> @@ -1,4 +1,6 @@
> +==========================
> Kernel driver i2c-mux-gpio
> +==========================
>
> Author: Peter Korsgaard <peter.korsgaard@barco.com>
>
> @@ -8,7 +10,7 @@ Description
> i2c-mux-gpio is an i2c mux driver providing access to I2C bus segments
> from a master I2C bus and a hardware MUX controlled through GPIO pins.
>
> -E.G.:
> +E.G.::
>
> ---------- ---------- Bus segment 1 - - - - -
> | | SCL/SDA | |-------------- | |
> @@ -33,20 +35,20 @@ bus, the number of bus segments to create and the GPIO pins used
> to control it. See include/linux/platform_data/i2c-mux-gpio.h for details.
>
> E.G. something like this for a MUX providing 4 bus segments
> -controlled through 3 GPIO pins:
> +controlled through 3 GPIO pins::
>
> -#include <linux/platform_data/i2c-mux-gpio.h>
> -#include <linux/platform_device.h>
> + #include <linux/platform_data/i2c-mux-gpio.h>
> + #include <linux/platform_device.h>
>
> -static const unsigned myboard_gpiomux_gpios[] = {
> + static const unsigned myboard_gpiomux_gpios[] = {
> AT91_PIN_PC26, AT91_PIN_PC25, AT91_PIN_PC24
> -};
> + };
>
> -static const unsigned myboard_gpiomux_values[] = {
> + static const unsigned myboard_gpiomux_values[] = {
> 0, 1, 2, 3
> -};
> + };
>
> -static struct i2c_mux_gpio_platform_data myboard_i2cmux_data = {
> + static struct i2c_mux_gpio_platform_data myboard_i2cmux_data = {
> .parent = 1,
> .base_nr = 2, /* optional */
> .values = myboard_gpiomux_values,
> @@ -54,15 +56,15 @@ static struct i2c_mux_gpio_platform_data myboard_i2cmux_data = {
> .gpios = myboard_gpiomux_gpios,
> .n_gpios = ARRAY_SIZE(myboard_gpiomux_gpios),
> .idle = 4, /* optional */
> -};
> + };
>
> -static struct platform_device myboard_i2cmux = {
> + static struct platform_device myboard_i2cmux = {
> .name = "i2c-mux-gpio",
> .id = 0,
> .dev = {
> .platform_data = &myboard_i2cmux_data,
> },
> -};
> + };
>
> If you don't know the absolute GPIO pin numbers at registration time,
> you can instead provide a chip name (.chip_name) and relative GPIO pin
> diff --git a/Documentation/i2c/old-module-parameters b/Documentation/i2c/old-module-parameters.rst
> similarity index 75%
> rename from Documentation/i2c/old-module-parameters
> rename to Documentation/i2c/old-module-parameters.rst
> index 8e2b629d533c..a1939512ad66 100644
> --- a/Documentation/i2c/old-module-parameters
> +++ b/Documentation/i2c/old-module-parameters.rst
> @@ -1,3 +1,4 @@
> +=================================================
> I2C device driver binding control from user-space
> =================================================
>
> @@ -19,23 +20,27 @@ Below is a mapping from the old module parameters to the new interface.
> Attaching a driver to an I2C device
> -----------------------------------
>
> -Old method (module parameters):
> -# modprobe <driver> probe=1,0x2d
> -# modprobe <driver> force=1,0x2d
> -# modprobe <driver> force_<device>=1,0x2d
> +Old method (module parameters)::
>
> -New method (sysfs interface):
> -# echo <device> 0x2d > /sys/bus/i2c/devices/i2c-1/new_device
> + # modprobe <driver> probe=1,0x2d
> + # modprobe <driver> force=1,0x2d
> + # modprobe <driver> force_<device>=1,0x2d
> +
> +New method (sysfs interface)::
> +
> + # echo <device> 0x2d > /sys/bus/i2c/devices/i2c-1/new_device
>
> Preventing a driver from attaching to an I2C device
> ---------------------------------------------------
>
> -Old method (module parameters):
> -# modprobe <driver> ignore=1,0x2f
> +Old method (module parameters)::
>
> -New method (sysfs interface):
> -# echo dummy 0x2f > /sys/bus/i2c/devices/i2c-1/new_device
> -# modprobe <driver>
> + # modprobe <driver> ignore=1,0x2f
> +
> +New method (sysfs interface)::
> +
> + # echo dummy 0x2f > /sys/bus/i2c/devices/i2c-1/new_device
> + # modprobe <driver>
>
> Of course, it is important to instantiate the "dummy" device before loading
> the driver. The dummy device will be handled by i2c-core itself, preventing
> diff --git a/Documentation/i2c/slave-eeprom-backend b/Documentation/i2c/slave-eeprom-backend.rst
> similarity index 90%
> rename from Documentation/i2c/slave-eeprom-backend
> rename to Documentation/i2c/slave-eeprom-backend.rst
> index 04f8d8a9b817..2018fa74c6f3 100644
> --- a/Documentation/i2c/slave-eeprom-backend
> +++ b/Documentation/i2c/slave-eeprom-backend.rst
> @@ -1,3 +1,4 @@
> +==============================
> Linux I2C slave eeprom backend
> ==============================
>
> @@ -5,7 +6,7 @@ by Wolfram Sang <wsa@sang-engineering.com> in 2014-15
>
> This is a proof-of-concept backend which acts like an EEPROM on the connected
> I2C bus. The memory contents can be modified from userspace via this file
> -located in sysfs:
> +located in sysfs::
>
> /sys/bus/i2c/devices/<device-directory>/slave-eeprom
>
> diff --git a/Documentation/i2c/slave-interface b/Documentation/i2c/slave-interface.rst
> similarity index 94%
> rename from Documentation/i2c/slave-interface
> rename to Documentation/i2c/slave-interface.rst
> index 7e2a228f21bc..9ac5f110a4ec 100644
> --- a/Documentation/i2c/slave-interface
> +++ b/Documentation/i2c/slave-interface.rst
> @@ -1,3 +1,4 @@
> +=====================================
> Linux I2C slave interface description
> =====================================
>
> @@ -12,7 +13,7 @@ EEPROM, the Linux I2C slave can access the content via sysfs and handle data as
> needed. The backend driver and the I2C bus driver communicate via events. Here
> is a small graph visualizing the data flow and the means by which data is
> transported. The dotted line marks only one example. The backend could also
> -use a character device, be in-kernel only, or something completely different:
> +use a character device, be in-kernel only, or something completely different::
>
>
> e.g. sysfs I2C slave events I/O registers
> @@ -35,7 +36,7 @@ them as described in the document 'instantiating-devices'. The only difference
> is that i2c slave backends have their own address space. So, you have to add
> 0x1000 to the address you would originally request. An example for
> instantiating the slave-eeprom driver from userspace at the 7 bit address 0x64
> -on bus 1:
> +on bus 1::
>
> # echo slave-24c02 0x1064 > /sys/bus/i2c/devices/i2c-1/new_device
>
> @@ -54,7 +55,7 @@ drivers and writing backends will be given.
> I2C slave events
> ----------------
>
> -The bus driver sends an event to the backend using the following function:
> +The bus driver sends an event to the backend using the following function::
>
> ret = i2c_slave_event(client, event, &val)
>
> @@ -69,8 +70,9 @@ Event types:
>
> * I2C_SLAVE_WRITE_REQUESTED (mandatory)
>
> -'val': unused
> -'ret': always 0
> + 'val': unused
> +
> + 'ret': always 0
>
> Another I2C master wants to write data to us. This event should be sent once
> our own address and the write bit was detected. The data did not arrive yet, so
> @@ -79,8 +81,9 @@ to be done, though.
>
> * I2C_SLAVE_READ_REQUESTED (mandatory)
>
> -'val': backend returns first byte to be sent
> -'ret': always 0
> + 'val': backend returns first byte to be sent
> +
> + 'ret': always 0
>
> Another I2C master wants to read data from us. This event should be sent once
> our own address and the read bit was detected. After returning, the bus driver
> @@ -88,8 +91,9 @@ should transmit the first byte.
>
> * I2C_SLAVE_WRITE_RECEIVED (mandatory)
>
> -'val': bus driver delivers received byte
> -'ret': 0 if the byte should be acked, some errno if the byte should be nacked
> + 'val': bus driver delivers received byte
> +
> + 'ret': 0 if the byte should be acked, some errno if the byte should be nacked
>
> Another I2C master has sent a byte to us which needs to be set in 'val'. If 'ret'
> is zero, the bus driver should ack this byte. If 'ret' is an errno, then the byte
> @@ -97,8 +101,9 @@ should be nacked.
>
> * I2C_SLAVE_READ_PROCESSED (mandatory)
>
> -'val': backend returns next byte to be sent
> -'ret': always 0
> + 'val': backend returns next byte to be sent
> +
> + 'ret': always 0
>
> The bus driver requests the next byte to be sent to another I2C master in
> 'val'. Important: This does not mean that the previous byte has been acked, it
> @@ -111,8 +116,9 @@ your backend, though.
>
> * I2C_SLAVE_STOP (mandatory)
>
> -'val': unused
> -'ret': always 0
> + 'val': unused
> +
> + 'ret': always 0
>
> A stop condition was received. This can happen anytime and the backend should
> reset its state machine for I2C transfers to be able to receive new requests.
> diff --git a/Documentation/i2c/smbus-protocol b/Documentation/i2c/smbus-protocol.rst
> similarity index 84%
> rename from Documentation/i2c/smbus-protocol
> rename to Documentation/i2c/smbus-protocol.rst
> index 092d474f5843..c6f189bfe1c7 100644
> --- a/Documentation/i2c/smbus-protocol
> +++ b/Documentation/i2c/smbus-protocol.rst
> @@ -1,3 +1,4 @@
> +======================
> SMBus Protocol Summary
> ======================
>
> @@ -27,12 +28,13 @@ Each transaction type corresponds to a functionality flag. Before calling a
> transaction function, a device driver should always check (just once) for
> the corresponding functionality flag to ensure that the underlying I2C
> adapter supports the transaction in question. See
> -<file:Documentation/i2c/functionality> for the details.
> +<file:Documentation/i2c/functionality.rst> for the details.
>
>
> Key to symbols
> ==============
>
> +=============== =============================================================
> S (1 bit) : Start bit
> P (1 bit) : Stop bit
> Rd/Wr (1 bit) : Read/Write bit. Rd equals 1, Wr equals 0.
> @@ -45,15 +47,17 @@ Data (8 bits): A plain data byte. Sometimes, I write DataLow, DataHigh
> for 16 bit data.
> Count (8 bits): A data byte containing the length of a block operation.
>
> -[..]: Data sent by I2C device, as opposed to data sent by the host adapter.
> +[..]: Data sent by I2C device, as opposed to data sent by the host
> + adapter.
> +=============== =============================================================
>
>
> SMBus Quick Command
> ===================
>
> -This sends a single bit to the device, at the place of the Rd/Wr bit.
> +This sends a single bit to the device, at the place of the Rd/Wr bit::
>
> -A Addr Rd/Wr [A] P
> + A Addr Rd/Wr [A] P
>
> Functionality flag: I2C_FUNC_SMBUS_QUICK
>
> @@ -64,9 +68,9 @@ SMBus Receive Byte: i2c_smbus_read_byte()
> This reads a single byte from a device, without specifying a device
> register. Some devices are so simple that this interface is enough; for
> others, it is a shorthand if you want to read the same register as in
> -the previous SMBus command.
> +the previous SMBus command::
>
> -S Addr Rd [A] [Data] NA P
> + S Addr Rd [A] [Data] NA P
>
> Functionality flag: I2C_FUNC_SMBUS_READ_BYTE
>
> @@ -77,7 +81,9 @@ SMBus Send Byte: i2c_smbus_write_byte()
> This operation is the reverse of Receive Byte: it sends a single byte
> to a device. See Receive Byte for more information.
>
> -S Addr Wr [A] Data [A] P
> +::
> +
> + S Addr Wr [A] Data [A] P
>
> Functionality flag: I2C_FUNC_SMBUS_WRITE_BYTE
>
> @@ -86,9 +92,9 @@ SMBus Read Byte: i2c_smbus_read_byte_data()
> ============================================
>
> This reads a single byte from a device, from a designated register.
> -The register is specified through the Comm byte.
> +The register is specified through the Comm byte::
>
> -S Addr Wr [A] Comm [A] S Addr Rd [A] [Data] NA P
> + S Addr Wr [A] Comm [A] S Addr Rd [A] [Data] NA P
>
> Functionality flag: I2C_FUNC_SMBUS_READ_BYTE_DATA
>
> @@ -98,9 +104,9 @@ SMBus Read Word: i2c_smbus_read_word_data()
>
> This operation is very like Read Byte; again, data is read from a
> device, from a designated register that is specified through the Comm
> -byte. But this time, the data is a complete word (16 bits).
> +byte. But this time, the data is a complete word (16 bits)::
>
> -S Addr Wr [A] Comm [A] S Addr Rd [A] [DataLow] A [DataHigh] NA P
> + S Addr Wr [A] Comm [A] S Addr Rd [A] [DataLow] A [DataHigh] NA P
>
> Functionality flag: I2C_FUNC_SMBUS_READ_WORD_DATA
>
> @@ -116,7 +122,9 @@ This writes a single byte to a device, to a designated register. The
> register is specified through the Comm byte. This is the opposite of
> the Read Byte operation.
>
> -S Addr Wr [A] Comm [A] Data [A] P
> +::
> +
> + S Addr Wr [A] Comm [A] Data [A] P
>
> Functionality flag: I2C_FUNC_SMBUS_WRITE_BYTE_DATA
>
> @@ -126,9 +134,9 @@ SMBus Write Word: i2c_smbus_write_word_data()
>
> This is the opposite of the Read Word operation. 16 bits
> of data is written to a device, to the designated register that is
> -specified through the Comm byte.
> +specified through the Comm byte.::
>
> -S Addr Wr [A] Comm [A] DataLow [A] DataHigh [A] P
> + S Addr Wr [A] Comm [A] DataLow [A] DataHigh [A] P
>
> Functionality flag: I2C_FUNC_SMBUS_WRITE_WORD_DATA
>
> @@ -141,10 +149,10 @@ SMBus Process Call:
> ===================
>
> This command selects a device register (through the Comm byte), sends
> -16 bits of data to it, and reads 16 bits of data in return.
> +16 bits of data to it, and reads 16 bits of data in return::
>
> -S Addr Wr [A] Comm [A] DataLow [A] DataHigh [A]
> - S Addr Rd [A] [DataLow] A [DataHigh] NA P
> + S Addr Wr [A] Comm [A] DataLow [A] DataHigh [A]
> + S Addr Rd [A] [DataLow] A [DataHigh] NA P
>
> Functionality flag: I2C_FUNC_SMBUS_PROC_CALL
>
> @@ -156,8 +164,10 @@ This command reads a block of up to 32 bytes from a device, from a
> designated register that is specified through the Comm byte. The amount
> of data is specified by the device in the Count byte.
>
> -S Addr Wr [A] Comm [A]
> - S Addr Rd [A] [Count] A [Data] A [Data] A ... A [Data] NA P
> +::
> +
> + S Addr Wr [A] Comm [A]
> + S Addr Rd [A] [Count] A [Data] A [Data] A ... A [Data] NA P
>
> Functionality flag: I2C_FUNC_SMBUS_READ_BLOCK_DATA
>
> @@ -169,7 +179,9 @@ The opposite of the Block Read command, this writes up to 32 bytes to
> a device, to a designated register that is specified through the
> Comm byte. The amount of data is specified in the Count byte.
>
> -S Addr Wr [A] Comm [A] Count [A] Data [A] Data [A] ... [A] Data [A] P
> +::
> +
> + S Addr Wr [A] Comm [A] Count [A] Data [A] Data [A] ... [A] Data [A] P
>
> Functionality flag: I2C_FUNC_SMBUS_WRITE_BLOCK_DATA
>
> @@ -181,10 +193,10 @@ SMBus Block Write - Block Read Process Call was introduced in
> Revision 2.0 of the specification.
>
> This command selects a device register (through the Comm byte), sends
> -1 to 31 bytes of data to it, and reads 1 to 31 bytes of data in return.
> +1 to 31 bytes of data to it, and reads 1 to 31 bytes of data in return::
>
> -S Addr Wr [A] Comm [A] Count [A] Data [A] ...
> - S Addr Rd [A] [Count] A [Data] ... A P
> + S Addr Wr [A] Comm [A] Count [A] Data [A] ...
> + S Addr Rd [A] [Count] A [Data] ... A P
>
> Functionality flag: I2C_FUNC_SMBUS_BLOCK_PROC_CALL
>
> @@ -197,9 +209,12 @@ SMBus host acting as a slave.
> It is the same form as Write Word, with the command code replaced by the
> alerting device's address.
>
> -[S] [HostAddr] [Wr] A [DevAddr] A [DataLow] A [DataHigh] A [P]
> +::
> +
> + [S] [HostAddr] [Wr] A [DevAddr] A [DataLow] A [DataHigh] A [P]
>
> This is implemented in the following way in the Linux kernel:
> +
> * I2C bus drivers which support SMBus Host Notify should report
> I2C_FUNC_SMBUS_HOST_NOTIFY.
> * I2C bus drivers trigger SMBus Host Notify by a call to
> @@ -241,6 +256,7 @@ single interrupt pin on the SMBus master, while still allowing the master
> to know which slave triggered the interrupt.
>
> This is implemented the following way in the Linux kernel:
> +
> * I2C bus drivers which support SMBus alert should call
> i2c_setup_smbus_alert() to setup SMBus alert support.
> * I2C drivers for devices which can trigger SMBus alerts should implement
> @@ -262,10 +278,10 @@ I2C Block Read: i2c_smbus_read_i2c_block_data()
> ================================================
>
> This command reads a block of bytes from a device, from a
> -designated register that is specified through the Comm byte.
> +designated register that is specified through the Comm byte::
>
> -S Addr Wr [A] Comm [A]
> - S Addr Rd [A] [Data] A [Data] A ... A [Data] NA P
> + S Addr Wr [A] Comm [A]
> + S Addr Rd [A] [Data] A [Data] A ... A [Data] NA P
>
> Functionality flag: I2C_FUNC_SMBUS_READ_I2C_BLOCK
>
> @@ -278,6 +294,8 @@ a device, to a designated register that is specified through the
> Comm byte. Note that command lengths of 0, 2, or more bytes are
> supported as they are indistinguishable from data.
>
> -S Addr Wr [A] Comm [A] Data [A] Data [A] ... [A] Data [A] P
> +::
> +
> + S Addr Wr [A] Comm [A] Data [A] Data [A] ... [A] Data [A] P
>
> Functionality flag: I2C_FUNC_SMBUS_WRITE_I2C_BLOCK
> diff --git a/Documentation/i2c/summary b/Documentation/i2c/summary.rst
> similarity index 96%
> rename from Documentation/i2c/summary
> rename to Documentation/i2c/summary.rst
> index 809541ab352f..8c08fa727f4e 100644
> --- a/Documentation/i2c/summary
> +++ b/Documentation/i2c/summary.rst
> @@ -1,3 +1,4 @@
> +=============
> I2C and SMBus
> =============
>
> @@ -24,7 +25,8 @@ implement all the common SMBus protocol semantics or messages.
> Terminology
> ===========
>
> -When we talk about I2C, we use the following terms:
> +When we talk about I2C, we use the following terms::
> +
> Bus -> Algorithm
> Adapter
> Device -> Driver
> diff --git a/Documentation/i2c/ten-bit-addresses b/Documentation/i2c/ten-bit-addresses.rst
> similarity index 95%
> rename from Documentation/i2c/ten-bit-addresses
> rename to Documentation/i2c/ten-bit-addresses.rst
> index 7b2d11e53a49..5c765aff16d5 100644
> --- a/Documentation/i2c/ten-bit-addresses
> +++ b/Documentation/i2c/ten-bit-addresses.rst
> @@ -1,3 +1,7 @@
> +=====================
> +I2C Ten-bit Addresses
> +=====================
> +
> The I2C protocol knows about two kinds of device addresses: normal 7 bit
> addresses, and an extended set of 10 bit addresses. The sets of addresses
> do not intersect: the 7 bit address 0x10 is not the same as the 10 bit
> @@ -12,6 +16,7 @@ See the I2C specification for the details.
>
> The current 10 bit address support is minimal. It should work, however
> you can expect some problems along the way:
> +
> * Not all bus drivers support 10-bit addresses. Some don't because the
> hardware doesn't support them (SMBus doesn't require 10-bit address
> support for example), some don't because nobody bothered adding the
> diff --git a/Documentation/i2c/upgrading-clients b/Documentation/i2c/upgrading-clients.rst
> similarity index 56%
> rename from Documentation/i2c/upgrading-clients
> rename to Documentation/i2c/upgrading-clients.rst
> index 96392cc5b5c7..4a575e607ff8 100644
> --- a/Documentation/i2c/upgrading-clients
> +++ b/Documentation/i2c/upgrading-clients.rst
> @@ -1,3 +1,4 @@
> +=================================================
> Upgrading I2C Drivers to the new 2.6 Driver Model
> =================================================
>
> @@ -13,21 +14,22 @@ the old to the new new binding methods.
> Example old-style driver
> ------------------------
>
> +::
>
> -struct example_state {
> + struct example_state {
> struct i2c_client client;
> ....
> -};
> + };
>
> -static struct i2c_driver example_driver;
> + static struct i2c_driver example_driver;
>
> -static unsigned short ignore[] = { I2C_CLIENT_END };
> -static unsigned short normal_addr[] = { OUR_ADDR, I2C_CLIENT_END };
> + static unsigned short ignore[] = { I2C_CLIENT_END };
> + static unsigned short normal_addr[] = { OUR_ADDR, I2C_CLIENT_END };
>
> -I2C_CLIENT_INSMOD;
> + I2C_CLIENT_INSMOD;
>
> -static int example_attach(struct i2c_adapter *adap, int addr, int kind)
> -{
> + static int example_attach(struct i2c_adapter *adap, int addr, int kind)
> + {
> struct example_state *state;
> struct device *dev = &adap->dev; /* to use for dev_ reports */
> int ret;
> @@ -59,23 +61,23 @@ static int example_attach(struct i2c_adapter *adap, int addr, int kind)
> dev_info(dev, "example client created\n");
>
> return 0;
> -}
> + }
>
> -static int example_detach(struct i2c_client *client)
> -{
> + static int example_detach(struct i2c_client *client)
> + {
> struct example_state *state = i2c_get_clientdata(client);
>
> i2c_detach_client(client);
> kfree(state);
> return 0;
> -}
> + }
>
> -static int example_attach_adapter(struct i2c_adapter *adap)
> -{
> + static int example_attach_adapter(struct i2c_adapter *adap)
> + {
> return i2c_probe(adap, &addr_data, example_attach);
> -}
> + }
>
> -static struct i2c_driver example_driver = {
> + static struct i2c_driver example_driver = {
> .driver = {
> .owner = THIS_MODULE,
> .name = "example",
> @@ -83,7 +85,7 @@ static struct i2c_driver example_driver = {
> },
> .attach_adapter = example_attach_adapter,
> .detach_client = example_detach,
> -};
> + };
>
>
> Updating the client
> @@ -93,38 +95,38 @@ The new style binding model will check against a list of supported
> devices and their associated address supplied by the code registering
> the busses. This means that the driver .attach_adapter and
> .detach_client methods can be removed, along with the addr_data,
> -as follows:
> +as follows::
>
> -- static struct i2c_driver example_driver;
> + - static struct i2c_driver example_driver;
>
> -- static unsigned short ignore[] = { I2C_CLIENT_END };
> -- static unsigned short normal_addr[] = { OUR_ADDR, I2C_CLIENT_END };
> + - static unsigned short ignore[] = { I2C_CLIENT_END };
> + - static unsigned short normal_addr[] = { OUR_ADDR, I2C_CLIENT_END };
>
> -- I2C_CLIENT_INSMOD;
> + - I2C_CLIENT_INSMOD;
>
> -- static int example_attach_adapter(struct i2c_adapter *adap)
> -- {
> -- return i2c_probe(adap, &addr_data, example_attach);
> -- }
> + - static int example_attach_adapter(struct i2c_adapter *adap)
> + - {
> + - return i2c_probe(adap, &addr_data, example_attach);
> + - }
>
> - static struct i2c_driver example_driver = {
> -- .attach_adapter = example_attach_adapter,
> -- .detach_client = example_detach,
> - }
> + static struct i2c_driver example_driver = {
> + - .attach_adapter = example_attach_adapter,
> + - .detach_client = example_detach,
> + }
>
> -Add the probe and remove methods to the i2c_driver, as so:
> +Add the probe and remove methods to the i2c_driver, as so::
>
> - static struct i2c_driver example_driver = {
> -+ .probe = example_probe,
> -+ .remove = example_remove,
> - }
> + static struct i2c_driver example_driver = {
> + + .probe = example_probe,
> + + .remove = example_remove,
> + }
>
> Change the example_attach method to accept the new parameters
> -which include the i2c_client that it will be working with:
> +which include the i2c_client that it will be working with::
>
> -- static int example_attach(struct i2c_adapter *adap, int addr, int kind)
> -+ static int example_probe(struct i2c_client *client,
> -+ const struct i2c_device_id *id)
> + - static int example_attach(struct i2c_adapter *adap, int addr, int kind)
> + + static int example_probe(struct i2c_client *client,
> + + const struct i2c_device_id *id)
>
> Change the name of example_attach to example_probe to align it with the
> i2c_driver entry names. The rest of the probe routine will now need to be
> @@ -132,55 +134,57 @@ changed as the i2c_client has already been setup for use.
>
> The necessary client fields have already been setup before
> the probe function is called, so the following client setup
> -can be removed:
> +can be removed::
>
> -- example->client.addr = addr;
> -- example->client.flags = 0;
> -- example->client.adapter = adap;
> --
> -- strscpy(client->i2c_client.name, "example", sizeof(client->i2c_client.name));
> + - example->client.addr = addr;
> + - example->client.flags = 0;
> + - example->client.adapter = adap;
> + -
> + - strscpy(client->i2c_client.name, "example", sizeof(client->i2c_client.name));
>
> -The i2c_set_clientdata is now:
> +The i2c_set_clientdata is now::
>
> -- i2c_set_clientdata(&state->client, state);
> -+ i2c_set_clientdata(client, state);
> + - i2c_set_clientdata(&state->client, state);
> + + i2c_set_clientdata(client, state);
>
> The call to i2c_attach_client is no longer needed, if the probe
> routine exits successfully, then the driver will be automatically
> -attached by the core. Change the probe routine as so:
> +attached by the core. Change the probe routine as so::
>
> -- ret = i2c_attach_client(&state->i2c_client);
> -- if (ret < 0) {
> -- dev_err(dev, "failed to attach client\n");
> -- kfree(state);
> -- return ret;
> -- }
> + - ret = i2c_attach_client(&state->i2c_client);
> + - if (ret < 0) {
> + - dev_err(dev, "failed to attach client\n");
> + - kfree(state);
> + - return ret;
> + - }
>
>
> Remove the storage of 'struct i2c_client' from the 'struct example_state'
> as we are provided with the i2c_client in our example_probe. Instead we
> store a pointer to it for when it is needed.
>
> -struct example_state {
> -- struct i2c_client client;
> -+ struct i2c_client *client;
> +::
>
> -the new i2c client as so:
> + struct example_state {
> + - struct i2c_client client;
> + + struct i2c_client *client;
>
> -- struct device *dev = &adap->dev; /* to use for dev_ reports */
> -+ struct device *dev = &i2c_client->dev; /* to use for dev_ reports */
> +the new i2c client as so::
> +
> + - struct device *dev = &adap->dev; /* to use for dev_ reports */
> + + struct device *dev = &i2c_client->dev; /* to use for dev_ reports */
>
> And remove the change after our client is attached, as the driver no
> -longer needs to register a new client structure with the core:
> +longer needs to register a new client structure with the core::
>
> -- dev = &state->i2c_client.dev;
> + - dev = &state->i2c_client.dev;
>
> In the probe routine, ensure that the new state has the client stored
> -in it:
> +in it::
>
> -static int example_probe(struct i2c_client *i2c_client,
> + static int example_probe(struct i2c_client *i2c_client,
> const struct i2c_device_id *id)
> -{
> + {
> struct example_state *state;
> struct device *dev = &i2c_client->dev;
> int ret;
> @@ -191,48 +195,50 @@ static int example_probe(struct i2c_client *i2c_client,
> return -ENOMEM;
> }
>
> -+ state->client = i2c_client;
> + + state->client = i2c_client;
>
> Update the detach method, by changing the name to _remove and
> to delete the i2c_detach_client call. It is possible that you
> can also remove the ret variable as it is not needed for any
> of the core functions.
>
> -- static int example_detach(struct i2c_client *client)
> -+ static int example_remove(struct i2c_client *client)
> -{
> +::
> +
> + - static int example_detach(struct i2c_client *client)
> + + static int example_remove(struct i2c_client *client)
> + {
> struct example_state *state = i2c_get_clientdata(client);
>
> -- i2c_detach_client(client);
> + - i2c_detach_client(client);
>
> And finally ensure that we have the correct ID table for the i2c-core
> -and other utilities:
> +and other utilities::
>
> -+ struct i2c_device_id example_idtable[] = {
> -+ { "example", 0 },
> -+ { }
> -+};
> -+
> -+MODULE_DEVICE_TABLE(i2c, example_idtable);
> + + struct i2c_device_id example_idtable[] = {
> + + { "example", 0 },
> + + { }
> + +};
> + +
> + +MODULE_DEVICE_TABLE(i2c, example_idtable);
>
> -static struct i2c_driver example_driver = {
> + static struct i2c_driver example_driver = {
> .driver = {
> .owner = THIS_MODULE,
> .name = "example",
> },
> -+ .id_table = example_ids,
> + + .id_table = example_ids,
>
>
> -Our driver should now look like this:
> +Our driver should now look like this::
>
> -struct example_state {
> + struct example_state {
> struct i2c_client *client;
> ....
> -};
> + };
>
> -static int example_probe(struct i2c_client *client,
> + static int example_probe(struct i2c_client *client,
> const struct i2c_device_id *id)
> -{
> + {
> struct example_state *state;
> struct device *dev = &client->dev;
>
> @@ -250,24 +256,24 @@ static int example_probe(struct i2c_client *client,
> dev_info(dev, "example client created\n");
>
> return 0;
> -}
> + }
>
> -static int example_remove(struct i2c_client *client)
> -{
> + static int example_remove(struct i2c_client *client)
> + {
> struct example_state *state = i2c_get_clientdata(client);
>
> kfree(state);
> return 0;
> -}
> + }
>
> -static struct i2c_device_id example_idtable[] = {
> + static struct i2c_device_id example_idtable[] = {
> { "example", 0 },
> { }
> -};
> + };
>
> -MODULE_DEVICE_TABLE(i2c, example_idtable);
> + MODULE_DEVICE_TABLE(i2c, example_idtable);
>
> -static struct i2c_driver example_driver = {
> + static struct i2c_driver example_driver = {
> .driver = {
> .owner = THIS_MODULE,
> .name = "example",
> @@ -276,4 +282,4 @@ static struct i2c_driver example_driver = {
> .id_table = example_idtable,
> .probe = example_probe,
> .remove = example_remove,
> -};
> + };
> diff --git a/Documentation/i2c/writing-clients b/Documentation/i2c/writing-clients.rst
> similarity index 91%
> rename from Documentation/i2c/writing-clients
> rename to Documentation/i2c/writing-clients.rst
> index a755b141fa4a..dddf0a14ab7c 100644
> --- a/Documentation/i2c/writing-clients
> +++ b/Documentation/i2c/writing-clients.rst
> @@ -1,3 +1,7 @@
> +===================
> +Writing I2C Clients
> +===================
> +
> This is a small guide for those who want to write kernel drivers for I2C
> or SMBus devices, using Linux as the protocol host/master (not slave).
>
> @@ -12,7 +16,7 @@ General remarks
> Try to keep the kernel namespace as clean as possible. The best way to
> do this is to use a unique prefix for all global symbols. This is
> especially important for exported symbols, but it is a good idea to do
> -it for non-exported symbols too. We will use the prefix `foo_' in this
> +it for non-exported symbols too. We will use the prefix ``foo_`` in this
> tutorial.
>
>
> @@ -25,15 +29,17 @@ routines, and should be zero-initialized except for fields with data you
> provide. A client structure holds device-specific information like the
> driver model device node, and its I2C address.
>
> -static struct i2c_device_id foo_idtable[] = {
> +::
> +
> + static struct i2c_device_id foo_idtable[] = {
> { "foo", my_id_for_foo },
> { "bar", my_id_for_bar },
> { }
> -};
> + };
>
> -MODULE_DEVICE_TABLE(i2c, foo_idtable);
> + MODULE_DEVICE_TABLE(i2c, foo_idtable);
>
> -static struct i2c_driver foo_driver = {
> + static struct i2c_driver foo_driver = {
> .driver = {
> .name = "foo",
> .pm = &foo_pm_ops, /* optional */
> @@ -49,7 +55,7 @@ static struct i2c_driver foo_driver = {
>
> .shutdown = foo_shutdown, /* optional */
> .command = foo_command, /* optional, deprecated */
> -}
> + }
>
> The name field is the driver name, and must not contain spaces. It
> should match the module name (if the driver can be compiled as a module),
> @@ -64,16 +70,18 @@ below.
> Extra client data
> =================
>
> -Each client structure has a special `data' field that can point to any
> +Each client structure has a special ``data`` field that can point to any
> structure at all. You should use this to keep device-specific data.
>
> +::
> +
> /* store the value */
> void i2c_set_clientdata(struct i2c_client *client, void *data);
>
> /* retrieve the value */
> void *i2c_get_clientdata(const struct i2c_client *client);
>
> -Note that starting with kernel 2.6.34, you don't have to set the `data' field
> +Note that starting with kernel 2.6.34, you don't have to set the ``data`` field
> to NULL in remove() or if probe() failed anymore. The i2c-core does this
> automatically on these occasions. Those are also the only times the core will
> touch this field.
> @@ -92,25 +100,25 @@ but many chips have some kind of register-value idea that can easily
> be encapsulated.
>
> The below functions are simple examples, and should not be copied
> -literally.
> +literally::
>
> -int foo_read_value(struct i2c_client *client, u8 reg)
> -{
> + int foo_read_value(struct i2c_client *client, u8 reg)
> + {
> if (reg < 0x10) /* byte-sized register */
> return i2c_smbus_read_byte_data(client, reg);
> else /* word-sized register */
> return i2c_smbus_read_word_data(client, reg);
> -}
> + }
>
> -int foo_write_value(struct i2c_client *client, u8 reg, u16 value)
> -{
> + int foo_write_value(struct i2c_client *client, u8 reg, u16 value)
> + {
> if (reg == 0x10) /* Impossible to write - driver error! */
> return -EINVAL;
> else if (reg < 0x10) /* byte-sized register */
> return i2c_smbus_write_byte_data(client, reg, value);
> else /* word-sized register */
> return i2c_smbus_write_word_data(client, reg, value);
> -}
> + }
>
>
> Probing and attaching
> @@ -145,6 +153,8 @@ I2C device drivers using this binding model work just like any other
> kind of driver in Linux: they provide a probe() method to bind to
> those devices, and a remove() method to unbind.
>
> +::
> +
> static int foo_probe(struct i2c_client *client,
> const struct i2c_device_id *id);
> static int foo_remove(struct i2c_client *client);
> @@ -240,37 +250,41 @@ When the kernel is booted, or when your foo driver module is inserted,
> you have to do some initializing. Fortunately, just registering the
> driver module is usually enough.
>
> -static int __init foo_init(void)
> -{
> +::
> +
> + static int __init foo_init(void)
> + {
> return i2c_add_driver(&foo_driver);
> -}
> -module_init(foo_init);
> + }
> + module_init(foo_init);
>
> -static void __exit foo_cleanup(void)
> -{
> + static void __exit foo_cleanup(void)
> + {
> i2c_del_driver(&foo_driver);
> -}
> -module_exit(foo_cleanup);
> + }
> + module_exit(foo_cleanup);
>
> -The module_i2c_driver() macro can be used to reduce above code.
> + The module_i2c_driver() macro can be used to reduce above code.
>
> -module_i2c_driver(foo_driver);
> + module_i2c_driver(foo_driver);
>
> -Note that some functions are marked by `__init'. These functions can
> +Note that some functions are marked by ``__init``. These functions can
> be removed after kernel booting (or module loading) is completed.
> -Likewise, functions marked by `__exit' are dropped by the compiler when
> +Likewise, functions marked by ``__exit`` are dropped by the compiler when
> the code is built into the kernel, as they would never be called.
>
>
> Driver Information
> ==================
>
> -/* Substitute your own name and email address */
> -MODULE_AUTHOR("Frodo Looijaard <frodol@dds.nl>"
> -MODULE_DESCRIPTION("Driver for Barf Inc. Foo I2C devices");
> +::
>
> -/* a few non-GPL license types are also allowed */
> -MODULE_LICENSE("GPL");
> + /* Substitute your own name and email address */
> + MODULE_AUTHOR("Frodo Looijaard <frodol@dds.nl>"
> + MODULE_DESCRIPTION("Driver for Barf Inc. Foo I2C devices");
> +
> + /* a few non-GPL license types are also allowed */
> + MODULE_LICENSE("GPL");
>
>
> Power Management
> @@ -323,6 +337,8 @@ commands, but only some of them understand plain I2C!
> Plain I2C communication
> -----------------------
>
> +::
> +
> int i2c_master_send(struct i2c_client *client, const char *buf,
> int count);
> int i2c_master_recv(struct i2c_client *client, char *buf, int count);
> @@ -334,6 +350,8 @@ to read/write (must be less than the length of the buffer, also should be
> less than 64k since msg.len is u16.) Returned is the actual number of bytes
> read/written.
>
> +::
> +
> int i2c_transfer(struct i2c_adapter *adap, struct i2c_msg *msg,
> int num);
>
> @@ -343,13 +361,15 @@ stop bit is sent between transaction. The i2c_msg structure contains
> for each message the client address, the number of bytes of the message
> and the message data itself.
>
> -You can read the file `i2c-protocol' for more information about the
> +You can read the file ``i2c-protocol`` for more information about the
> actual I2C protocol.
>
>
> SMBus communication
> -------------------
>
> +::
> +
> s32 i2c_smbus_xfer(struct i2c_adapter *adapter, u16 addr,
> unsigned short flags, char read_write, u8 command,
> int size, union i2c_smbus_data *data);
> @@ -357,6 +377,8 @@ SMBus communication
> This is the generic SMBus function. All functions below are implemented
> in terms of it. Never use this function directly!
>
> +::
> +
> s32 i2c_smbus_read_byte(struct i2c_client *client);
> s32 i2c_smbus_write_byte(struct i2c_client *client, u8 value);
> s32 i2c_smbus_read_byte_data(struct i2c_client *client, u8 command);
> @@ -376,7 +398,7 @@ in terms of it. Never use this function directly!
> const u8 *values);
>
> These ones were removed from i2c-core because they had no users, but could
> -be added back later if needed:
> +be added back later if needed::
>
> s32 i2c_smbus_write_quick(struct i2c_client *client, u8 value);
> s32 i2c_smbus_process_call(struct i2c_client *client,
> @@ -389,7 +411,7 @@ transactions return 0 on success; the 'read' transactions return the read
> value, except for block transactions, which return the number of values
> read. The block buffers need not be longer than 32 bytes.
>
> -You can read the file `smbus-protocol' for more information about the
> +You can read the file ``smbus-protocol`` for more information about the
> actual SMBus protocol.
>
>
> @@ -397,7 +419,7 @@ General purpose routines
> ========================
>
> Below all general purpose routines are listed, that were not mentioned
> -before.
> +before::
>
> /* Return the adapter number for a specific adapter */
> int i2c_adapter_id(struct i2c_adapter *adap);
> diff --git a/Documentation/index.rst b/Documentation/index.rst
> index 13c3188f6a68..ded1081e8d5f 100644
> --- a/Documentation/index.rst
> +++ b/Documentation/index.rst
> @@ -104,6 +104,7 @@ needed).
> fb/index
> fpga/index
> hid/index
> + i2c/index
> iio/index
> infiniband/index
> leds/index
> diff --git a/Documentation/spi/spi-sc18is602 b/Documentation/spi/spi-sc18is602
> index a45702865a38..0feffd5af411 100644
> --- a/Documentation/spi/spi-sc18is602
> +++ b/Documentation/spi/spi-sc18is602
> @@ -17,7 +17,7 @@ kernel's SPI core subsystem.
>
> The driver does not probe for supported chips, since the SI18IS602/603 does not
> support Chip ID registers. You will have to instantiate the devices explicitly.
> -Please see Documentation/i2c/instantiating-devices for details.
> +Please see Documentation/i2c/instantiating-devices.rst for details.
>
>
> Usage Notes
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 5d4da1035a03..ce925b6e3bcc 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -666,7 +666,7 @@ ALI1563 I2C DRIVER
> M: Rudolf Marek <r.marek@assembler.cz>
> L: linux-i2c@vger.kernel.org
> S: Maintained
> -F: Documentation/i2c/busses/i2c-ali1563
> +F: Documentation/i2c/busses/i2c-ali1563.rst
> F: drivers/i2c/busses/i2c-ali1563.c
>
> ALLEGRO DVT VIDEO IP CORE DRIVER
> @@ -6657,7 +6657,7 @@ L: linux-i2c@vger.kernel.org
> S: Supported
> F: drivers/i2c/muxes/i2c-mux-gpio.c
> F: include/linux/platform_data/i2c-mux-gpio.h
> -F: Documentation/i2c/muxes/i2c-mux-gpio
> +F: Documentation/i2c/muxes/i2c-mux-gpio.rst
>
> GENERIC HDLC (WAN) DRIVERS
> M: Krzysztof Halasa <khc@pm.waw.pl>
> @@ -7393,14 +7393,14 @@ I2C CONTROLLER DRIVER FOR NVIDIA GPU
> M: Ajay Gupta <ajayg@nvidia.com>
> L: linux-i2c@vger.kernel.org
> S: Maintained
> -F: Documentation/i2c/busses/i2c-nvidia-gpu
> +F: Documentation/i2c/busses/i2c-nvidia-gpu.rst
> F: drivers/i2c/busses/i2c-nvidia-gpu.c
>
> I2C MUXES
> M: Peter Rosin <peda@axentia.se>
> L: linux-i2c@vger.kernel.org
> S: Maintained
> -F: Documentation/i2c/i2c-topology
> +F: Documentation/i2c/i2c-topology.rst
> F: Documentation/i2c/muxes/
> F: Documentation/devicetree/bindings/i2c/i2c-mux*
> F: Documentation/devicetree/bindings/i2c/i2c-arb*
> @@ -7420,8 +7420,8 @@ I2C OVER PARALLEL PORT
> M: Jean Delvare <jdelvare@suse.com>
> L: linux-i2c@vger.kernel.org
> S: Maintained
> -F: Documentation/i2c/busses/i2c-parport
> -F: Documentation/i2c/busses/i2c-parport-light
> +F: Documentation/i2c/busses/i2c-parport.rst
> +F: Documentation/i2c/busses/i2c-parport-light.rst
> F: drivers/i2c/busses/i2c-parport.c
> F: drivers/i2c/busses/i2c-parport-light.c
>
> @@ -7455,7 +7455,7 @@ I2C-TAOS-EVM DRIVER
> M: Jean Delvare <jdelvare@suse.com>
> L: linux-i2c@vger.kernel.org
> S: Maintained
> -F: Documentation/i2c/busses/i2c-taos-evm
> +F: Documentation/i2c/busses/i2c-taos-evm.rst
> F: drivers/i2c/busses/i2c-taos-evm.c
>
> I2C-TINY-USB DRIVER
> @@ -7469,19 +7469,19 @@ I2C/SMBUS CONTROLLER DRIVERS FOR PC
> M: Jean Delvare <jdelvare@suse.com>
> L: linux-i2c@vger.kernel.org
> S: Maintained
> -F: Documentation/i2c/busses/i2c-ali1535
> -F: Documentation/i2c/busses/i2c-ali1563
> -F: Documentation/i2c/busses/i2c-ali15x3
> -F: Documentation/i2c/busses/i2c-amd756
> -F: Documentation/i2c/busses/i2c-amd8111
> -F: Documentation/i2c/busses/i2c-i801
> -F: Documentation/i2c/busses/i2c-nforce2
> -F: Documentation/i2c/busses/i2c-piix4
> -F: Documentation/i2c/busses/i2c-sis5595
> -F: Documentation/i2c/busses/i2c-sis630
> -F: Documentation/i2c/busses/i2c-sis96x
> -F: Documentation/i2c/busses/i2c-via
> -F: Documentation/i2c/busses/i2c-viapro
> +F: Documentation/i2c/busses/i2c-ali1535.rst
> +F: Documentation/i2c/busses/i2c-ali1563.rst
> +F: Documentation/i2c/busses/i2c-ali15x3.rst
> +F: Documentation/i2c/busses/i2c-amd756.rst
> +F: Documentation/i2c/busses/i2c-amd8111.rst
> +F: Documentation/i2c/busses/i2c-i801.rst
> +F: Documentation/i2c/busses/i2c-nforce2.rst
> +F: Documentation/i2c/busses/i2c-piix4.rst
> +F: Documentation/i2c/busses/i2c-sis5595.rst
> +F: Documentation/i2c/busses/i2c-sis630.rst
> +F: Documentation/i2c/busses/i2c-sis96x.rst
> +F: Documentation/i2c/busses/i2c-via.rst
> +F: Documentation/i2c/busses/i2c-viapro.rst
> F: drivers/i2c/busses/i2c-ali1535.c
> F: drivers/i2c/busses/i2c-ali1563.c
> F: drivers/i2c/busses/i2c-ali15x3.c
> @@ -7510,7 +7510,7 @@ M: Seth Heasley <seth.heasley@intel.com>
> M: Neil Horman <nhorman@tuxdriver.com>
> L: linux-i2c@vger.kernel.org
> F: drivers/i2c/busses/i2c-ismt.c
> -F: Documentation/i2c/busses/i2c-ismt
> +F: Documentation/i2c/busses/i2c-ismt.rst
>
> I2C/SMBUS STUB DRIVER
> M: Jean Delvare <jdelvare@suse.com>
> @@ -10236,7 +10236,7 @@ L: linux-i2c@vger.kernel.org
> S: Supported
> F: drivers/i2c/busses/i2c-mlxcpld.c
> F: drivers/i2c/muxes/i2c-mux-mlxcpld.c
> -F: Documentation/i2c/busses/i2c-mlxcpld
> +F: Documentation/i2c/busses/i2c-mlxcpld.rst
>
> MELLANOX MLXCPLD LED DRIVER
> M: Vadim Pasternak <vadimp@mellanox.com>
> @@ -11857,7 +11857,7 @@ M: Andrew Lunn <andrew@lunn.ch>
> L: linux-i2c@vger.kernel.org
> S: Maintained
> F: Documentation/devicetree/bindings/i2c/i2c-ocores.txt
> -F: Documentation/i2c/busses/i2c-ocores
> +F: Documentation/i2c/busses/i2c-ocores.rst
> F: drivers/i2c/busses/i2c-ocores.c
> F: include/linux/platform_data/i2c-ocores.h
>
> @@ -14141,7 +14141,7 @@ F: net/sctp/
> SCx200 CPU SUPPORT
> M: Jim Cromie <jim.cromie@gmail.com>
> S: Odd Fixes
> -F: Documentation/i2c/busses/scx200_acb
> +F: Documentation/i2c/busses/scx200_acb.rst
> F: arch/x86/platform/scx200/
> F: drivers/watchdog/scx200_wdt.c
> F: drivers/i2c/busses/scx200*
> diff --git a/Next/merge.log b/Next/merge.log
> index e9f5123f59ca..b45b3201b1d6 100644
> --- a/Next/merge.log
> +++ b/Next/merge.log
> @@ -2954,7 +2954,7 @@ $ git diff -M --stat --summary HEAD^..
> Documentation/devicetree/bindings/i2c/i2c-omap.txt | 1 +
> .../devicetree/bindings/i2c/i2c-sun6i-p2wi.txt | 41 ---
> .../bindings/i2c/marvell,mv64xxx-i2c.yaml | 124 +++++++
> - Documentation/i2c/busses/i2c-i801 | 3 +-
> + Documentation/i2c/busses/i2c-i801.rst | 3 +-
> MAINTAINERS | 7 +
> arch/arm/include/asm/hardware/iop3xx.h | 2 +
> arch/arm/mach-iop32x/em7210.c | 3 +
> @@ -3251,8 +3251,8 @@ $ git diff -M --stat --summary HEAD^..
> Documentation/fpga/index.rst | 17 +
> Documentation/gpu/msm-crash-dump.rst | 2 +
> Documentation/hid/hid-transport.txt | 6 +-
> - Documentation/i2c/instantiating-devices | 4 +-
> - Documentation/i2c/upgrading-clients | 4 +-
> + Documentation/i2c/instantiating-devices.rst | 4 +-
> + Documentation/i2c/upgrading-clients.rst | 4 +-
> Documentation/ide/changelogs.rst | 17 +
> Documentation/ide/{ide-tape.txt => ide-tape.rst} | 23 +-
> Documentation/ide/{ide.txt => ide.rst} | 147 +-
> diff --git a/drivers/hwmon/atxp1.c b/drivers/hwmon/atxp1.c
> index e232fa948833..79b8df258371 100644
> --- a/drivers/hwmon/atxp1.c
> +++ b/drivers/hwmon/atxp1.c
> @@ -5,7 +5,7 @@
> *
> * The ATXP1 can reside on I2C addresses 0x37 or 0x4e. The chip is
> * not auto-detected by the driver and must be instantiated explicitly.
> - * See Documentation/i2c/instantiating-devices for more information.
> + * See Documentation/i2c/instantiating-devices.rst for more information.
> */
>
> #include <linux/kernel.h>
> diff --git a/drivers/hwmon/smm665.c b/drivers/hwmon/smm665.c
> index d8c91c2cb8cf..9ae0dc28b9cf 100644
> --- a/drivers/hwmon/smm665.c
> +++ b/drivers/hwmon/smm665.c
> @@ -197,7 +197,7 @@ static int smm665_read_adc(struct smm665_data *data, int adc)
> if (rv != -ENXIO) {
> /*
> * We expect ENXIO to reflect NACK
> - * (per Documentation/i2c/fault-codes).
> + * (per Documentation/i2c/fault-codes.rst).
> * Everything else is an error.
> */
> dev_dbg(&client->dev,
> diff --git a/drivers/i2c/Kconfig b/drivers/i2c/Kconfig
> index abedd55a1264..1474e57ecafc 100644
> --- a/drivers/i2c/Kconfig
> +++ b/drivers/i2c/Kconfig
> @@ -54,7 +54,7 @@ config I2C_CHARDEV
> Say Y here to use i2c-* device files, usually found in the /dev
> directory on your system. They make it possible to have user-space
> programs use the I2C bus. Information on how to do this is
> - contained in the file <file:Documentation/i2c/dev-interface>.
> + contained in the file <file:Documentation/i2c/dev-interface.rst>.
>
> This support is also available as a module. If so, the module
> will be called i2c-dev.
> @@ -107,7 +107,7 @@ config I2C_STUB
> especially for certain kinds of sensor chips.
>
> If you do build this module, be sure to read the notes and warnings
> - in <file:Documentation/i2c/i2c-stub>.
> + in <file:Documentation/i2c/i2c-stub.rst>.
>
> If you don't know what to do here, definitely say N.
>
> diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
> index 68b677be1fa4..e4be46644e8b 100644
> --- a/drivers/i2c/busses/Kconfig
> +++ b/drivers/i2c/busses/Kconfig
> @@ -1205,7 +1205,7 @@ config I2C_PARPORT
> and makes it easier to add support for new devices.
>
> An adapter type parameter is now mandatory. Please read the file
> - Documentation/i2c/busses/i2c-parport for details.
> + Documentation/i2c/busses/i2c-parport.rst for details.
>
> Another driver exists, named i2c-parport-light, which doesn't depend
> on the parport driver. This is meant for embedded systems. Don't say
> diff --git a/drivers/i2c/busses/i2c-i801.c b/drivers/i2c/busses/i2c-i801.c
> index 1e7f6ae62b4c..a215b336bf5c 100644
> --- a/drivers/i2c/busses/i2c-i801.c
> +++ b/drivers/i2c/busses/i2c-i801.c
> @@ -76,7 +76,7 @@
> * SMBus Host Notify yes
> * Interrupt processing yes
> *
> - * See the file Documentation/i2c/busses/i2c-i801 for details.
> + * See the file Documentation/i2c/busses/i2c-i801.rst for details.
> */
>
> #include <linux/interrupt.h>
> diff --git a/drivers/i2c/busses/i2c-taos-evm.c b/drivers/i2c/busses/i2c-taos-evm.c
> index c82e78f57386..37347c93e8e0 100644
> --- a/drivers/i2c/busses/i2c-taos-evm.c
> +++ b/drivers/i2c/busses/i2c-taos-evm.c
> @@ -125,7 +125,7 @@ static int taos_smbus_xfer(struct i2c_adapter *adapter, u16 addr,
> /*
> * Voluntarily dropping error code of kstrtou8 since all
> * error code that it could return are invalid according
> - * to Documentation/i2c/fault-codes.
> + * to Documentation/i2c/fault-codes.rst.
> */
> if (kstrtou8(p + 1, 16, &data->byte))
> return -EPROTO;
> diff --git a/drivers/i2c/i2c-core-base.c b/drivers/i2c/i2c-core-base.c
> index e77bab2fb467..56b42558575e 100644
> --- a/drivers/i2c/i2c-core-base.c
> +++ b/drivers/i2c/i2c-core-base.c
> @@ -2205,7 +2205,7 @@ static int i2c_detect_address(struct i2c_client *temp_client,
> dev_warn(&adapter->dev,
> "This adapter will soon drop class based instantiation of devices. "
> "Please make sure client 0x%02x gets instantiated by other means. "
> - "Check 'Documentation/i2c/instantiating-devices' for details.\n",
> + "Check 'Documentation/i2c/instantiating-devices.rst' for details.\n",
> info.addr);
>
> dev_dbg(&adapter->dev, "Creating %s at 0x%02x\n",
> @@ -2235,7 +2235,7 @@ static int i2c_detect(struct i2c_adapter *adapter, struct i2c_driver *driver)
> if (adapter->class == I2C_CLASS_DEPRECATED) {
> dev_dbg(&adapter->dev,
> "This adapter dropped support for I2C classes and won't auto-detect %s devices anymore. "
> - "If you need it, check 'Documentation/i2c/instantiating-devices' for alternatives.\n",
> + "If you need it, check 'Documentation/i2c/instantiating-devices.rst' for alternatives.\n",
> driver->driver.name);
> return 0;
> }
> diff --git a/drivers/iio/dummy/iio_simple_dummy.c b/drivers/iio/dummy/iio_simple_dummy.c
> index 8f99c005458a..d28974ad9e0e 100644
> --- a/drivers/iio/dummy/iio_simple_dummy.c
> +++ b/drivers/iio/dummy/iio_simple_dummy.c
> @@ -693,7 +693,7 @@ static int iio_dummy_remove(struct iio_sw_device *swd)
> * Varies depending on bus type of the device. As there is no device
> * here, call probe directly. For information on device registration
> * i2c:
> - * Documentation/i2c/writing-clients
> + * Documentation/i2c/writing-clients.rst
> * spi:
> * Documentation/spi/spi-summary
> */
> diff --git a/drivers/rtc/rtc-ds1374.c b/drivers/rtc/rtc-ds1374.c
> index 225a8df1d4e9..1803f3cab39f 100644
> --- a/drivers/rtc/rtc-ds1374.c
> +++ b/drivers/rtc/rtc-ds1374.c
> @@ -14,7 +14,7 @@
> */
> /*
> * It would be more efficient to use i2c msgs/i2c_transfer directly but, as
> - * recommened in .../Documentation/i2c/writing-clients section
> + * recommened in .../Documentation/i2c/writing-clients.rst section
> * "Sending and receiving", using SMBus level communication is preferred.
> */
>
> diff --git a/include/linux/i2c.h b/include/linux/i2c.h
> index fa5552c2307b..c0a78c069117 100644
> --- a/include/linux/i2c.h
> +++ b/include/linux/i2c.h
> @@ -521,7 +521,7 @@ i2c_register_board_info(int busnum, struct i2c_board_info const *info,
> *
> * The return codes from the @master_xfer{_atomic} fields should indicate the
> * type of error code that occurred during the transfer, as documented in the
> - * Kernel Documentation file Documentation/i2c/fault-codes.
> + * Kernel Documentation file Documentation/i2c/fault-codes.rst.
> */
> struct i2c_algorithm {
> /*
^ permalink raw reply
* Re: [PATCH] hwmon: Remove ads1015 driver
From: Jonathan Cameron @ 2019-07-14 16:16 UTC (permalink / raw)
To: Guenter Roeck
Cc: devicetree, linux-hwmon, linux-kernel, linux-iio, Dirk Eibach
In-Reply-To: <1562004758-13025-1-git-send-email-linux@roeck-us.net>
On Mon, 1 Jul 2019 11:12:38 -0700
Guenter Roeck <linux@roeck-us.net> wrote:
> A driver for ADS1015 with more functionality is available in the iio
> subsystem.
>
> Remove the hwmon driver as duplicate. If the chip is used for hardware
> monitoring, the iio->hwmon bridge should be used.
>
> Cc: Dirk Eibach <eibach@gdsys.de>
> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
On the basis I agree with the concept of dropping this driver:
Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Thanks for tidying this up.
Jonathan
> ---
> Current plan is to queue this removal for v5.4 (not v5.3) in the hwmon
> tree.
>
> .../devicetree/bindings/hwmon/ads1015.txt | 73 -----
> .../devicetree/bindings/iio/adc/ads1015.txt | 73 +++++
> Documentation/hwmon/ads1015.rst | 90 ------
> Documentation/hwmon/index.rst | 1 -
> MAINTAINERS | 8 -
> drivers/hwmon/Kconfig | 10 -
> drivers/hwmon/Makefile | 1 -
> drivers/hwmon/ads1015.c | 324 ---------------------
> drivers/iio/adc/Kconfig | 2 +-
> 9 files changed, 74 insertions(+), 508 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/hwmon/ads1015.txt
> create mode 100644 Documentation/devicetree/bindings/iio/adc/ads1015.txt
> delete mode 100644 Documentation/hwmon/ads1015.rst
> delete mode 100644 drivers/hwmon/ads1015.c
>
> diff --git a/Documentation/devicetree/bindings/hwmon/ads1015.txt b/Documentation/devicetree/bindings/hwmon/ads1015.txt
> deleted file mode 100644
> index 918a507d1159..000000000000
> --- a/Documentation/devicetree/bindings/hwmon/ads1015.txt
> +++ /dev/null
> @@ -1,73 +0,0 @@
> -ADS1015 (I2C)
> -
> -This device is a 12-bit A-D converter with 4 inputs.
> -
> -The inputs can be used single ended or in certain differential combinations.
> -
> -For configuration all possible combinations are mapped to 8 channels:
> - 0: Voltage over AIN0 and AIN1.
> - 1: Voltage over AIN0 and AIN3.
> - 2: Voltage over AIN1 and AIN3.
> - 3: Voltage over AIN2 and AIN3.
> - 4: Voltage over AIN0 and GND.
> - 5: Voltage over AIN1 and GND.
> - 6: Voltage over AIN2 and GND.
> - 7: Voltage over AIN3 and GND.
> -
> -Each channel can be configured individually:
> - - pga is the programmable gain amplifier (values are full scale)
> - 0: +/- 6.144 V
> - 1: +/- 4.096 V
> - 2: +/- 2.048 V (default)
> - 3: +/- 1.024 V
> - 4: +/- 0.512 V
> - 5: +/- 0.256 V
> - - data_rate in samples per second
> - 0: 128
> - 1: 250
> - 2: 490
> - 3: 920
> - 4: 1600 (default)
> - 5: 2400
> - 6: 3300
> -
> -1) The /ads1015 node
> -
> - Required properties:
> -
> - - compatible : must be "ti,ads1015"
> - - reg : I2C bus address of the device
> - - #address-cells : must be <1>
> - - #size-cells : must be <0>
> -
> - The node contains child nodes for each channel that the platform uses.
> -
> - Example ADS1015 node:
> -
> - ads1015@49 {
> - compatible = "ti,ads1015";
> - reg = <0x49>;
> - #address-cells = <1>;
> - #size-cells = <0>;
> -
> - [ child node definitions... ]
> - }
> -
> -2) channel nodes
> -
> - Required properties:
> -
> - - reg : the channel number
> -
> - Optional properties:
> -
> - - ti,gain : the programmable gain amplifier setting
> - - ti,datarate : the converter data rate
> -
> - Example ADS1015 channel node:
> -
> - channel@4 {
> - reg = <4>;
> - ti,gain = <3>;
> - ti,datarate = <5>;
> - };
> diff --git a/Documentation/devicetree/bindings/iio/adc/ads1015.txt b/Documentation/devicetree/bindings/iio/adc/ads1015.txt
> new file mode 100644
> index 000000000000..918a507d1159
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/adc/ads1015.txt
> @@ -0,0 +1,73 @@
> +ADS1015 (I2C)
> +
> +This device is a 12-bit A-D converter with 4 inputs.
> +
> +The inputs can be used single ended or in certain differential combinations.
> +
> +For configuration all possible combinations are mapped to 8 channels:
> + 0: Voltage over AIN0 and AIN1.
> + 1: Voltage over AIN0 and AIN3.
> + 2: Voltage over AIN1 and AIN3.
> + 3: Voltage over AIN2 and AIN3.
> + 4: Voltage over AIN0 and GND.
> + 5: Voltage over AIN1 and GND.
> + 6: Voltage over AIN2 and GND.
> + 7: Voltage over AIN3 and GND.
> +
> +Each channel can be configured individually:
> + - pga is the programmable gain amplifier (values are full scale)
> + 0: +/- 6.144 V
> + 1: +/- 4.096 V
> + 2: +/- 2.048 V (default)
> + 3: +/- 1.024 V
> + 4: +/- 0.512 V
> + 5: +/- 0.256 V
> + - data_rate in samples per second
> + 0: 128
> + 1: 250
> + 2: 490
> + 3: 920
> + 4: 1600 (default)
> + 5: 2400
> + 6: 3300
> +
> +1) The /ads1015 node
> +
> + Required properties:
> +
> + - compatible : must be "ti,ads1015"
> + - reg : I2C bus address of the device
> + - #address-cells : must be <1>
> + - #size-cells : must be <0>
> +
> + The node contains child nodes for each channel that the platform uses.
> +
> + Example ADS1015 node:
> +
> + ads1015@49 {
> + compatible = "ti,ads1015";
> + reg = <0x49>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + [ child node definitions... ]
> + }
> +
> +2) channel nodes
> +
> + Required properties:
> +
> + - reg : the channel number
> +
> + Optional properties:
> +
> + - ti,gain : the programmable gain amplifier setting
> + - ti,datarate : the converter data rate
> +
> + Example ADS1015 channel node:
> +
> + channel@4 {
> + reg = <4>;
> + ti,gain = <3>;
> + ti,datarate = <5>;
> + };
> diff --git a/Documentation/hwmon/ads1015.rst b/Documentation/hwmon/ads1015.rst
> deleted file mode 100644
> index e0951c4e57bb..000000000000
> --- a/Documentation/hwmon/ads1015.rst
> +++ /dev/null
> @@ -1,90 +0,0 @@
> -Kernel driver ads1015
> -=====================
> -
> -Supported chips:
> -
> - * Texas Instruments ADS1015
> -
> - Prefix: 'ads1015'
> -
> - Datasheet: Publicly available at the Texas Instruments website:
> -
> - http://focus.ti.com/lit/ds/symlink/ads1015.pdf
> -
> - * Texas Instruments ADS1115
> -
> - Prefix: 'ads1115'
> -
> - Datasheet: Publicly available at the Texas Instruments website:
> -
> - http://focus.ti.com/lit/ds/symlink/ads1115.pdf
> -
> -Authors:
> - Dirk Eibach, Guntermann & Drunck GmbH <eibach@gdsys.de>
> -
> -Description
> ------------
> -
> -This driver implements support for the Texas Instruments ADS1015/ADS1115.
> -
> -This device is a 12/16-bit A-D converter with 4 inputs.
> -
> -The inputs can be used single ended or in certain differential combinations.
> -
> -The inputs can be made available by 8 sysfs input files in0_input - in7_input:
> -
> - - in0: Voltage over AIN0 and AIN1.
> - - in1: Voltage over AIN0 and AIN3.
> - - in2: Voltage over AIN1 and AIN3.
> - - in3: Voltage over AIN2 and AIN3.
> - - in4: Voltage over AIN0 and GND.
> - - in5: Voltage over AIN1 and GND.
> - - in6: Voltage over AIN2 and GND.
> - - in7: Voltage over AIN3 and GND.
> -
> -Which inputs are available can be configured using platform data or devicetree.
> -
> -By default all inputs are exported.
> -
> -Platform Data
> --------------
> -
> -In linux/platform_data/ads1015.h platform data is defined, channel_data contains
> -configuration data for the used input combinations:
> -
> -- pga is the programmable gain amplifier (values are full scale)
> -
> - - 0: +/- 6.144 V
> - - 1: +/- 4.096 V
> - - 2: +/- 2.048 V
> - - 3: +/- 1.024 V
> - - 4: +/- 0.512 V
> - - 5: +/- 0.256 V
> -
> -- data_rate in samples per second
> -
> - - 0: 128
> - - 1: 250
> - - 2: 490
> - - 3: 920
> - - 4: 1600
> - - 5: 2400
> - - 6: 3300
> -
> -Example::
> -
> - struct ads1015_platform_data data = {
> - .channel_data = {
> - [2] = { .enabled = true, .pga = 1, .data_rate = 0 },
> - [4] = { .enabled = true, .pga = 4, .data_rate = 5 },
> - }
> - };
> -
> -In this case only in2_input (FS +/- 4.096 V, 128 SPS) and in4_input
> -(FS +/- 0.512 V, 2400 SPS) would be created.
> -
> -Devicetree
> -----------
> -
> -Configuration is also possible via devicetree:
> -Documentation/devicetree/bindings/hwmon/ads1015.txt
> diff --git a/Documentation/hwmon/index.rst b/Documentation/hwmon/index.rst
> index ee090e51653a..1d301d0e6f4d 100644
> --- a/Documentation/hwmon/index.rst
> +++ b/Documentation/hwmon/index.rst
> @@ -30,7 +30,6 @@ Hardware Monitoring Kernel Drivers
> adm1031
> adm1275
> adm9240
> - ads1015
> ads7828
> adt7410
> adt7411
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 01a52fc964da..11744a3735f0 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -517,14 +517,6 @@ W: http://ez.analog.com/community/linux-device-drivers
> S: Supported
> F: drivers/video/backlight/adp8860_bl.c
>
> -ADS1015 HARDWARE MONITOR DRIVER
> -M: Dirk Eibach <eibach@gdsys.de>
> -L: linux-hwmon@vger.kernel.org
> -S: Maintained
> -F: Documentation/hwmon/ads1015.rst
> -F: drivers/hwmon/ads1015.c
> -F: include/linux/platform_data/ads1015.h
> -
> ADT746X FAN DRIVER
> M: Colin Leroy <colin@colino.net>
> S: Maintained
> diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
> index 650dd71f9724..76cd0647ee2c 100644
> --- a/drivers/hwmon/Kconfig
> +++ b/drivers/hwmon/Kconfig
> @@ -1570,16 +1570,6 @@ config SENSORS_ADC128D818
> This driver can also be built as a module. If so, the module
> will be called adc128d818.
>
> -config SENSORS_ADS1015
> - tristate "Texas Instruments ADS1015"
> - depends on I2C
> - help
> - If you say yes here you get support for Texas Instruments
> - ADS1015/ADS1115 12/16-bit 4-input ADC device.
> -
> - This driver can also be built as a module. If so, the module
> - will be called ads1015.
> -
> config SENSORS_ADS7828
> tristate "Texas Instruments ADS7828 and compatibles"
> depends on I2C
> diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
> index 8db472ea04f0..6a52a964038b 100644
> --- a/drivers/hwmon/Makefile
> +++ b/drivers/hwmon/Makefile
> @@ -35,7 +35,6 @@ obj-$(CONFIG_SENSORS_ADM1026) += adm1026.o
> obj-$(CONFIG_SENSORS_ADM1029) += adm1029.o
> obj-$(CONFIG_SENSORS_ADM1031) += adm1031.o
> obj-$(CONFIG_SENSORS_ADM9240) += adm9240.o
> -obj-$(CONFIG_SENSORS_ADS1015) += ads1015.o
> obj-$(CONFIG_SENSORS_ADS7828) += ads7828.o
> obj-$(CONFIG_SENSORS_ADS7871) += ads7871.o
> obj-$(CONFIG_SENSORS_ADT7X10) += adt7x10.o
> diff --git a/drivers/hwmon/ads1015.c b/drivers/hwmon/ads1015.c
> deleted file mode 100644
> index 3727a3762eb8..000000000000
> --- a/drivers/hwmon/ads1015.c
> +++ /dev/null
> @@ -1,324 +0,0 @@
> -// SPDX-License-Identifier: GPL-2.0-or-later
> -/*
> - * ads1015.c - lm_sensors driver for ads1015 12-bit 4-input ADC
> - * (C) Copyright 2010
> - * Dirk Eibach, Guntermann & Drunck GmbH <eibach@gdsys.de>
> - *
> - * Based on the ads7828 driver by Steve Hardy.
> - *
> - * Datasheet available at: http://focus.ti.com/lit/ds/symlink/ads1015.pdf
> - */
> -
> -#include <linux/module.h>
> -#include <linux/init.h>
> -#include <linux/slab.h>
> -#include <linux/delay.h>
> -#include <linux/i2c.h>
> -#include <linux/hwmon.h>
> -#include <linux/hwmon-sysfs.h>
> -#include <linux/err.h>
> -#include <linux/mutex.h>
> -#include <linux/of_device.h>
> -#include <linux/of.h>
> -
> -#include <linux/platform_data/ads1015.h>
> -
> -/* ADS1015 registers */
> -enum {
> - ADS1015_CONVERSION = 0,
> - ADS1015_CONFIG = 1,
> -};
> -
> -/* PGA fullscale voltages in mV */
> -static const unsigned int fullscale_table[8] = {
> - 6144, 4096, 2048, 1024, 512, 256, 256, 256 };
> -
> -/* Data rates in samples per second */
> -static const unsigned int data_rate_table_1015[8] = {
> - 128, 250, 490, 920, 1600, 2400, 3300, 3300
> -};
> -
> -static const unsigned int data_rate_table_1115[8] = {
> - 8, 16, 32, 64, 128, 250, 475, 860
> -};
> -
> -#define ADS1015_DEFAULT_CHANNELS 0xff
> -#define ADS1015_DEFAULT_PGA 2
> -#define ADS1015_DEFAULT_DATA_RATE 4
> -
> -enum ads1015_chips {
> - ads1015,
> - ads1115,
> -};
> -
> -struct ads1015_data {
> - struct device *hwmon_dev;
> - struct mutex update_lock; /* mutex protect updates */
> - struct ads1015_channel_data channel_data[ADS1015_CHANNELS];
> - enum ads1015_chips id;
> -};
> -
> -static int ads1015_read_adc(struct i2c_client *client, unsigned int channel)
> -{
> - u16 config;
> - struct ads1015_data *data = i2c_get_clientdata(client);
> - unsigned int pga = data->channel_data[channel].pga;
> - unsigned int data_rate = data->channel_data[channel].data_rate;
> - unsigned int conversion_time_ms;
> - const unsigned int * const rate_table = data->id == ads1115 ?
> - data_rate_table_1115 : data_rate_table_1015;
> - int res;
> -
> - mutex_lock(&data->update_lock);
> -
> - /* get channel parameters */
> - res = i2c_smbus_read_word_swapped(client, ADS1015_CONFIG);
> - if (res < 0)
> - goto err_unlock;
> - config = res;
> - conversion_time_ms = DIV_ROUND_UP(1000, rate_table[data_rate]);
> -
> - /* setup and start single conversion */
> - config &= 0x001f;
> - config |= (1 << 15) | (1 << 8);
> - config |= (channel & 0x0007) << 12;
> - config |= (pga & 0x0007) << 9;
> - config |= (data_rate & 0x0007) << 5;
> -
> - res = i2c_smbus_write_word_swapped(client, ADS1015_CONFIG, config);
> - if (res < 0)
> - goto err_unlock;
> -
> - /* wait until conversion finished */
> - msleep(conversion_time_ms);
> - res = i2c_smbus_read_word_swapped(client, ADS1015_CONFIG);
> - if (res < 0)
> - goto err_unlock;
> - config = res;
> - if (!(config & (1 << 15))) {
> - /* conversion not finished in time */
> - res = -EIO;
> - goto err_unlock;
> - }
> -
> - res = i2c_smbus_read_word_swapped(client, ADS1015_CONVERSION);
> -
> -err_unlock:
> - mutex_unlock(&data->update_lock);
> - return res;
> -}
> -
> -static int ads1015_reg_to_mv(struct i2c_client *client, unsigned int channel,
> - s16 reg)
> -{
> - struct ads1015_data *data = i2c_get_clientdata(client);
> - unsigned int pga = data->channel_data[channel].pga;
> - int fullscale = fullscale_table[pga];
> - const int mask = data->id == ads1115 ? 0x7fff : 0x7ff0;
> -
> - return DIV_ROUND_CLOSEST(reg * fullscale, mask);
> -}
> -
> -/* sysfs callback function */
> -static ssize_t in_show(struct device *dev, struct device_attribute *da,
> - char *buf)
> -{
> - struct sensor_device_attribute *attr = to_sensor_dev_attr(da);
> - struct i2c_client *client = to_i2c_client(dev);
> - int res;
> - int index = attr->index;
> -
> - res = ads1015_read_adc(client, index);
> - if (res < 0)
> - return res;
> -
> - return sprintf(buf, "%d\n", ads1015_reg_to_mv(client, index, res));
> -}
> -
> -static const struct sensor_device_attribute ads1015_in[] = {
> - SENSOR_ATTR_RO(in0_input, in, 0),
> - SENSOR_ATTR_RO(in1_input, in, 1),
> - SENSOR_ATTR_RO(in2_input, in, 2),
> - SENSOR_ATTR_RO(in3_input, in, 3),
> - SENSOR_ATTR_RO(in4_input, in, 4),
> - SENSOR_ATTR_RO(in5_input, in, 5),
> - SENSOR_ATTR_RO(in6_input, in, 6),
> - SENSOR_ATTR_RO(in7_input, in, 7),
> -};
> -
> -/*
> - * Driver interface
> - */
> -
> -static int ads1015_remove(struct i2c_client *client)
> -{
> - struct ads1015_data *data = i2c_get_clientdata(client);
> - int k;
> -
> - hwmon_device_unregister(data->hwmon_dev);
> - for (k = 0; k < ADS1015_CHANNELS; ++k)
> - device_remove_file(&client->dev, &ads1015_in[k].dev_attr);
> - return 0;
> -}
> -
> -#ifdef CONFIG_OF
> -static int ads1015_get_channels_config_of(struct i2c_client *client)
> -{
> - struct ads1015_data *data = i2c_get_clientdata(client);
> - struct device_node *node;
> -
> - if (!client->dev.of_node
> - || !of_get_next_child(client->dev.of_node, NULL))
> - return -EINVAL;
> -
> - for_each_child_of_node(client->dev.of_node, node) {
> - u32 pval;
> - unsigned int channel;
> - unsigned int pga = ADS1015_DEFAULT_PGA;
> - unsigned int data_rate = ADS1015_DEFAULT_DATA_RATE;
> -
> - if (of_property_read_u32(node, "reg", &pval)) {
> - dev_err(&client->dev, "invalid reg on %pOF\n", node);
> - continue;
> - }
> -
> - channel = pval;
> - if (channel >= ADS1015_CHANNELS) {
> - dev_err(&client->dev,
> - "invalid channel index %d on %pOF\n",
> - channel, node);
> - continue;
> - }
> -
> - if (!of_property_read_u32(node, "ti,gain", &pval)) {
> - pga = pval;
> - if (pga > 6) {
> - dev_err(&client->dev, "invalid gain on %pOF\n",
> - node);
> - return -EINVAL;
> - }
> - }
> -
> - if (!of_property_read_u32(node, "ti,datarate", &pval)) {
> - data_rate = pval;
> - if (data_rate > 7) {
> - dev_err(&client->dev,
> - "invalid data_rate on %pOF\n", node);
> - return -EINVAL;
> - }
> - }
> -
> - data->channel_data[channel].enabled = true;
> - data->channel_data[channel].pga = pga;
> - data->channel_data[channel].data_rate = data_rate;
> - }
> -
> - return 0;
> -}
> -#endif
> -
> -static void ads1015_get_channels_config(struct i2c_client *client)
> -{
> - unsigned int k;
> - struct ads1015_data *data = i2c_get_clientdata(client);
> - struct ads1015_platform_data *pdata = dev_get_platdata(&client->dev);
> -
> - /* prefer platform data */
> - if (pdata) {
> - memcpy(data->channel_data, pdata->channel_data,
> - sizeof(data->channel_data));
> - return;
> - }
> -
> -#ifdef CONFIG_OF
> - if (!ads1015_get_channels_config_of(client))
> - return;
> -#endif
> -
> - /* fallback on default configuration */
> - for (k = 0; k < ADS1015_CHANNELS; ++k) {
> - data->channel_data[k].enabled = true;
> - data->channel_data[k].pga = ADS1015_DEFAULT_PGA;
> - data->channel_data[k].data_rate = ADS1015_DEFAULT_DATA_RATE;
> - }
> -}
> -
> -static int ads1015_probe(struct i2c_client *client,
> - const struct i2c_device_id *id)
> -{
> - struct ads1015_data *data;
> - int err;
> - unsigned int k;
> -
> - data = devm_kzalloc(&client->dev, sizeof(struct ads1015_data),
> - GFP_KERNEL);
> - if (!data)
> - return -ENOMEM;
> -
> - if (client->dev.of_node)
> - data->id = (enum ads1015_chips)
> - of_device_get_match_data(&client->dev);
> - else
> - data->id = id->driver_data;
> - i2c_set_clientdata(client, data);
> - mutex_init(&data->update_lock);
> -
> - /* build sysfs attribute group */
> - ads1015_get_channels_config(client);
> - for (k = 0; k < ADS1015_CHANNELS; ++k) {
> - if (!data->channel_data[k].enabled)
> - continue;
> - err = device_create_file(&client->dev, &ads1015_in[k].dev_attr);
> - if (err)
> - goto exit_remove;
> - }
> -
> - data->hwmon_dev = hwmon_device_register(&client->dev);
> - if (IS_ERR(data->hwmon_dev)) {
> - err = PTR_ERR(data->hwmon_dev);
> - goto exit_remove;
> - }
> -
> - return 0;
> -
> -exit_remove:
> - for (k = 0; k < ADS1015_CHANNELS; ++k)
> - device_remove_file(&client->dev, &ads1015_in[k].dev_attr);
> - return err;
> -}
> -
> -static const struct i2c_device_id ads1015_id[] = {
> - { "ads1015", ads1015},
> - { "ads1115", ads1115},
> - { }
> -};
> -MODULE_DEVICE_TABLE(i2c, ads1015_id);
> -
> -static const struct of_device_id __maybe_unused ads1015_of_match[] = {
> - {
> - .compatible = "ti,ads1015",
> - .data = (void *)ads1015
> - },
> - {
> - .compatible = "ti,ads1115",
> - .data = (void *)ads1115
> - },
> - { },
> -};
> -MODULE_DEVICE_TABLE(of, ads1015_of_match);
> -
> -static struct i2c_driver ads1015_driver = {
> - .driver = {
> - .name = "ads1015",
> - .of_match_table = of_match_ptr(ads1015_of_match),
> - },
> - .probe = ads1015_probe,
> - .remove = ads1015_remove,
> - .id_table = ads1015_id,
> -};
> -
> -module_i2c_driver(ads1015_driver);
> -
> -MODULE_AUTHOR("Dirk Eibach <eibach@gdsys.de>");
> -MODULE_DESCRIPTION("ADS1015 driver");
> -MODULE_LICENSE("GPL");
> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
> index f96a7702b020..47d073006a13 100644
> --- a/drivers/iio/adc/Kconfig
> +++ b/drivers/iio/adc/Kconfig
> @@ -958,7 +958,7 @@ config TI_ADC161S626
>
> config TI_ADS1015
> tristate "Texas Instruments ADS1015 ADC"
> - depends on I2C && !SENSORS_ADS1015
> + depends on I2C
> select REGMAP_I2C
> select IIO_BUFFER
> select IIO_TRIGGERED_BUFFER
^ permalink raw reply
* Re: [PATCH v2 3/3] ARM: dts: stm32: add syscfg to ADC on stm32mp157c
From: Jonathan Cameron @ 2019-07-14 16:13 UTC (permalink / raw)
To: Fabrice Gasnier
Cc: robh+dt, alexandre.torgue, mark.rutland, mcoquelin.stm32, lars,
knaack.h, pmeerw, linux-iio, devicetree, linux-stm32,
linux-arm-kernel, linux-kernel
In-Reply-To: <1562148496-26789-4-git-send-email-fabrice.gasnier@st.com>
On Wed, 3 Jul 2019 12:08:16 +0200
Fabrice Gasnier <fabrice.gasnier@st.com> wrote:
> On stm32mp157c, the ADC inputs are multiplexed with analog switches which
> have reduced performances when their supply is below 2.7V (vdda by
> default).
> Add syscfg registers that can be used on stm32mp157c, to get full ADC
> analog performances.
>
> Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com>
I've applied the patches using this on the assumption this will go via
the usual SoC route.
Thanks,
Jonathan
> ---
> arch/arm/boot/dts/stm32mp157c.dtsi | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/boot/dts/stm32mp157c.dtsi b/arch/arm/boot/dts/stm32mp157c.dtsi
> index 2dd5162..b9a5b58 100644
> --- a/arch/arm/boot/dts/stm32mp157c.dtsi
> +++ b/arch/arm/boot/dts/stm32mp157c.dtsi
> @@ -862,6 +862,7 @@
> clocks = <&rcc ADC12>, <&rcc ADC12_K>;
> clock-names = "bus", "adc";
> interrupt-controller;
> + st,syscfg = <&syscfg>;
> #interrupt-cells = <1>;
> #address-cells = <1>;
> #size-cells = <0>;
^ permalink raw reply
* Re: [PATCH v2 2/3] iio: adc: stm32-adc: add analog switches supply control
From: Jonathan Cameron @ 2019-07-14 16:12 UTC (permalink / raw)
To: Fabrice Gasnier
Cc: robh+dt, alexandre.torgue, mark.rutland, mcoquelin.stm32, lars,
knaack.h, pmeerw, linux-iio, devicetree, linux-stm32,
linux-arm-kernel, linux-kernel
In-Reply-To: <1562148496-26789-3-git-send-email-fabrice.gasnier@st.com>
On Wed, 3 Jul 2019 12:08:15 +0200
Fabrice Gasnier <fabrice.gasnier@st.com> wrote:
> On stm32h7 and stm32mp1, the ADC inputs are multiplexed with analog
> switches which have reduced performances when their supply is below 2.7V
> (vdda by default):
> - 3.3V embedded booster can be used, to get full ADC performances
> (increases power consumption).
> - vdd supply can be selected if above 2.7V by setting ANASWVDD syscfg bit,
> on STM32MP1 only.
>
> Make this optional, since this is a trade-off between analog performance
> and power consumption.
>
> Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com>
Looks good to me.
Applied to the togreg branch of iio.git and pushed out as testing.
Thanks,
Jonathan
> ---
> Changes in v2:
> - Only enable vdd regulator when needed.
> - Rework vdda enabling since: "Add missing vdda-supply to STM32 ADC".
> - Booster has been added to the regulator framework. This helps also when
> there are several ADC instances like on stm32h7 (e.g. ADC12 and ADC3), to
> benefit from the use count.
> ---
> drivers/iio/adc/stm32-adc-core.c | 193 ++++++++++++++++++++++++++++++++++++++-
> 1 file changed, 192 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/iio/adc/stm32-adc-core.c b/drivers/iio/adc/stm32-adc-core.c
> index 1f7ce51..4299cef 100644
> --- a/drivers/iio/adc/stm32-adc-core.c
> +++ b/drivers/iio/adc/stm32-adc-core.c
> @@ -14,9 +14,11 @@
> #include <linux/irqchip/chained_irq.h>
> #include <linux/irqdesc.h>
> #include <linux/irqdomain.h>
> +#include <linux/mfd/syscon.h>
> #include <linux/module.h>
> #include <linux/of_device.h>
> #include <linux/pm_runtime.h>
> +#include <linux/regmap.h>
> #include <linux/regulator/consumer.h>
> #include <linux/slab.h>
>
> @@ -51,6 +53,17 @@
>
> #define STM32_ADC_CORE_SLEEP_DELAY_MS 2000
>
> +/* SYSCFG registers */
> +#define STM32MP1_SYSCFG_PMCSETR 0x04
> +#define STM32MP1_SYSCFG_PMCCLRR 0x44
> +
> +/* SYSCFG bit fields */
> +#define STM32MP1_SYSCFG_ANASWVDD_MASK BIT(9)
> +
> +/* SYSCFG capability flags */
> +#define HAS_VBOOSTER BIT(0)
> +#define HAS_ANASWVDD BIT(1)
> +
> /**
> * stm32_adc_common_regs - stm32 common registers, compatible dependent data
> * @csr: common status register offset
> @@ -74,11 +87,13 @@ struct stm32_adc_priv;
> * @regs: common registers for all instances
> * @clk_sel: clock selection routine
> * @max_clk_rate_hz: maximum analog clock rate (Hz, from datasheet)
> + * @has_syscfg: SYSCFG capability flags
> */
> struct stm32_adc_priv_cfg {
> const struct stm32_adc_common_regs *regs;
> int (*clk_sel)(struct platform_device *, struct stm32_adc_priv *);
> u32 max_clk_rate_hz;
> + unsigned int has_syscfg;
> };
>
> /**
> @@ -87,22 +102,32 @@ struct stm32_adc_priv_cfg {
> * @domain: irq domain reference
> * @aclk: clock reference for the analog circuitry
> * @bclk: bus clock common for all ADCs, depends on part used
> + * @booster: booster supply reference
> + * @vdd: vdd supply reference
> * @vdda: vdda analog supply reference
> * @vref: regulator reference
> + * @vdd_uv: vdd supply voltage (microvolts)
> + * @vdda_uv: vdda supply voltage (microvolts)
> * @cfg: compatible configuration data
> * @common: common data for all ADC instances
> * @ccr_bak: backup CCR in low power mode
> + * @syscfg: reference to syscon, system control registers
> */
> struct stm32_adc_priv {
> int irq[STM32_ADC_MAX_ADCS];
> struct irq_domain *domain;
> struct clk *aclk;
> struct clk *bclk;
> + struct regulator *booster;
> + struct regulator *vdd;
> struct regulator *vdda;
> struct regulator *vref;
> + int vdd_uv;
> + int vdda_uv;
> const struct stm32_adc_priv_cfg *cfg;
> struct stm32_adc_common common;
> u32 ccr_bak;
> + struct regmap *syscfg;
> };
>
> static struct stm32_adc_priv *to_stm32_adc_priv(struct stm32_adc_common *com)
> @@ -390,6 +415,82 @@ static void stm32_adc_irq_remove(struct platform_device *pdev,
> }
> }
>
> +static int stm32_adc_core_switches_supply_en(struct stm32_adc_priv *priv,
> + struct device *dev)
> +{
> + int ret;
> +
> + /*
> + * On STM32H7 and STM32MP1, the ADC inputs are multiplexed with analog
> + * switches (via PCSEL) which have reduced performances when their
> + * supply is below 2.7V (vdda by default):
> + * - Voltage booster can be used, to get full ADC performances
> + * (increases power consumption).
> + * - Vdd can be used to supply them, if above 2.7V (STM32MP1 only).
> + *
> + * Recommended settings for ANASWVDD and EN_BOOSTER:
> + * - vdda < 2.7V but vdd > 2.7V: ANASWVDD = 1, EN_BOOSTER = 0 (stm32mp1)
> + * - vdda < 2.7V and vdd < 2.7V: ANASWVDD = 0, EN_BOOSTER = 1
> + * - vdda >= 2.7V: ANASWVDD = 0, EN_BOOSTER = 0 (default)
> + */
> + if (priv->vdda_uv < 2700000) {
> + if (priv->syscfg && priv->vdd_uv > 2700000) {
> + ret = regulator_enable(priv->vdd);
> + if (ret < 0) {
> + dev_err(dev, "vdd enable failed %d\n", ret);
> + return ret;
> + }
> +
> + ret = regmap_write(priv->syscfg,
> + STM32MP1_SYSCFG_PMCSETR,
> + STM32MP1_SYSCFG_ANASWVDD_MASK);
> + if (ret < 0) {
> + regulator_disable(priv->vdd);
> + dev_err(dev, "vdd select failed, %d\n", ret);
> + return ret;
> + }
> + dev_dbg(dev, "analog switches supplied by vdd\n");
> +
> + return 0;
> + }
> +
> + if (priv->booster) {
> + /*
> + * This is optional, as this is a trade-off between
> + * analog performance and power consumption.
> + */
> + ret = regulator_enable(priv->booster);
> + if (ret < 0) {
> + dev_err(dev, "booster enable failed %d\n", ret);
> + return ret;
> + }
> + dev_dbg(dev, "analog switches supplied by booster\n");
> +
> + return 0;
> + }
> + }
> +
> + /* Fallback using vdda (default), nothing to do */
> + dev_dbg(dev, "analog switches supplied by vdda (%d uV)\n",
> + priv->vdda_uv);
> +
> + return 0;
> +}
> +
> +static void stm32_adc_core_switches_supply_dis(struct stm32_adc_priv *priv)
> +{
> + if (priv->vdda_uv < 2700000) {
> + if (priv->syscfg && priv->vdd_uv > 2700000) {
> + regmap_write(priv->syscfg, STM32MP1_SYSCFG_PMCCLRR,
> + STM32MP1_SYSCFG_ANASWVDD_MASK);
> + regulator_disable(priv->vdd);
> + return;
> + }
> + if (priv->booster)
> + regulator_disable(priv->booster);
> + }
> +}
> +
> static int stm32_adc_core_hw_start(struct device *dev)
> {
> struct stm32_adc_common *common = dev_get_drvdata(dev);
> @@ -402,10 +503,21 @@ static int stm32_adc_core_hw_start(struct device *dev)
> return ret;
> }
>
> + ret = regulator_get_voltage(priv->vdda);
> + if (ret < 0) {
> + dev_err(dev, "vdda get voltage failed, %d\n", ret);
> + goto err_vdda_disable;
> + }
> + priv->vdda_uv = ret;
> +
> + ret = stm32_adc_core_switches_supply_en(priv, dev);
> + if (ret < 0)
> + goto err_vdda_disable;
> +
> ret = regulator_enable(priv->vref);
> if (ret < 0) {
> dev_err(dev, "vref enable failed\n");
> - goto err_vdda_disable;
> + goto err_switches_dis;
> }
>
> if (priv->bclk) {
> @@ -433,6 +545,8 @@ static int stm32_adc_core_hw_start(struct device *dev)
> clk_disable_unprepare(priv->bclk);
> err_regulator_disable:
> regulator_disable(priv->vref);
> +err_switches_dis:
> + stm32_adc_core_switches_supply_dis(priv);
> err_vdda_disable:
> regulator_disable(priv->vdda);
>
> @@ -451,9 +565,80 @@ static void stm32_adc_core_hw_stop(struct device *dev)
> if (priv->bclk)
> clk_disable_unprepare(priv->bclk);
> regulator_disable(priv->vref);
> + stm32_adc_core_switches_supply_dis(priv);
> regulator_disable(priv->vdda);
> }
>
> +static int stm32_adc_core_switches_probe(struct device *dev,
> + struct stm32_adc_priv *priv)
> +{
> + struct device_node *np = dev->of_node;
> + int ret;
> +
> + /* Analog switches supply can be controlled by syscfg (optional) */
> + priv->syscfg = syscon_regmap_lookup_by_phandle(np, "st,syscfg");
> + if (IS_ERR(priv->syscfg)) {
> + ret = PTR_ERR(priv->syscfg);
> + if (ret != -ENODEV) {
> + if (ret != -EPROBE_DEFER)
> + dev_err(dev, "Can't probe syscfg: %d\n", ret);
> + return ret;
> + }
> + priv->syscfg = NULL;
> + }
> +
> + /* Booster can be used to supply analog switches (optional) */
> + if (priv->cfg->has_syscfg & HAS_VBOOSTER &&
> + of_property_read_bool(np, "booster-supply")) {
> + priv->booster = devm_regulator_get_optional(dev, "booster");
> + if (IS_ERR(priv->booster)) {
> + ret = PTR_ERR(priv->booster);
> + if (ret != -ENODEV) {
> + if (ret != -EPROBE_DEFER)
> + dev_err(dev, "can't get booster %d\n",
> + ret);
> + return ret;
> + }
> + priv->booster = NULL;
> + }
> + }
> +
> + /* Vdd can be used to supply analog switches (optional) */
> + if (priv->cfg->has_syscfg & HAS_ANASWVDD &&
> + of_property_read_bool(np, "vdd-supply")) {
> + priv->vdd = devm_regulator_get_optional(dev, "vdd");
> + if (IS_ERR(priv->vdd)) {
> + ret = PTR_ERR(priv->vdd);
> + if (ret != -ENODEV) {
> + if (ret != -EPROBE_DEFER)
> + dev_err(dev, "can't get vdd %d\n", ret);
> + return ret;
> + }
> + priv->vdd = NULL;
> + }
> + }
> +
> + if (priv->vdd) {
> + ret = regulator_enable(priv->vdd);
> + if (ret < 0) {
> + dev_err(dev, "vdd enable failed %d\n", ret);
> + return ret;
> + }
> +
> + ret = regulator_get_voltage(priv->vdd);
> + if (ret < 0) {
> + dev_err(dev, "vdd get voltage failed %d\n", ret);
> + regulator_disable(priv->vdd);
> + return ret;
> + }
> + priv->vdd_uv = ret;
> +
> + regulator_disable(priv->vdd);
> + }
> +
> + return 0;
> +}
> +
> static int stm32_adc_probe(struct platform_device *pdev)
> {
> struct stm32_adc_priv *priv;
> @@ -514,6 +699,10 @@ static int stm32_adc_probe(struct platform_device *pdev)
> priv->bclk = NULL;
> }
>
> + ret = stm32_adc_core_switches_probe(dev, priv);
> + if (ret)
> + return ret;
> +
> pm_runtime_get_noresume(dev);
> pm_runtime_set_active(dev);
> pm_runtime_set_autosuspend_delay(dev, STM32_ADC_CORE_SLEEP_DELAY_MS);
> @@ -611,12 +800,14 @@ static const struct stm32_adc_priv_cfg stm32h7_adc_priv_cfg = {
> .regs = &stm32h7_adc_common_regs,
> .clk_sel = stm32h7_adc_clk_sel,
> .max_clk_rate_hz = 36000000,
> + .has_syscfg = HAS_VBOOSTER,
> };
>
> static const struct stm32_adc_priv_cfg stm32mp1_adc_priv_cfg = {
> .regs = &stm32h7_adc_common_regs,
> .clk_sel = stm32h7_adc_clk_sel,
> .max_clk_rate_hz = 40000000,
> + .has_syscfg = HAS_VBOOSTER | HAS_ANASWVDD,
> };
>
> static const struct of_device_id stm32_adc_of_match[] = {
^ permalink raw reply
* Re: [PATCH v2 1/3] dt-bindings: iio: adc: stm32: add analog switches supply control
From: Jonathan Cameron @ 2019-07-14 16:11 UTC (permalink / raw)
To: Fabrice Gasnier
Cc: robh+dt, alexandre.torgue, mark.rutland, mcoquelin.stm32, lars,
knaack.h, pmeerw, linux-iio, devicetree, linux-stm32,
linux-arm-kernel, linux-kernel
In-Reply-To: <1562148496-26789-2-git-send-email-fabrice.gasnier@st.com>
On Wed, 3 Jul 2019 12:08:14 +0200
Fabrice Gasnier <fabrice.gasnier@st.com> wrote:
> On stm32h7 and stm32mp1, the ADC inputs are multiplexed with analog
> switches which have reduced performances when their supply is below 2.7V
> (vdda by default). Booster or vdd can be used, to get full ADC
> performances.
>
> Add documentation for:
> - optional booster-supply that can be used on stm32h7 and stm32mp1.
> - optional vdd-supply that can be used on stm32mp1 to supply analog
> circuitry, selected by syscfg.
> Mark these as optional, since this is a trade-off between analog
> performance and power consumption.
>
> Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com>
Seems fine to me. Applied to the togreg branch of iio.git and pushed out
as testing for the autobuilders to play with it.
Thanks,
Jonathan
> ---
> Changes in v2:
> - Rework since: "Add missing vdda-supply to STM32 ADC" series.
> - Add booster-supply regulator description
> - typo: input switches
> ---
> Documentation/devicetree/bindings/iio/adc/st,stm32-adc.txt | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/iio/adc/st,stm32-adc.txt b/Documentation/devicetree/bindings/iio/adc/st,stm32-adc.txt
> index 93a0bd2..4c0da8c 100644
> --- a/Documentation/devicetree/bindings/iio/adc/st,stm32-adc.txt
> +++ b/Documentation/devicetree/bindings/iio/adc/st,stm32-adc.txt
> @@ -47,6 +47,12 @@ Required properties:
> Optional properties:
> - A pinctrl state named "default" for each ADC channel may be defined to set
> inX ADC pins in mode of operation for analog input on external pin.
> +- booster-supply: Phandle to the embedded booster regulator that can be used
> + to supply ADC analog input switches on stm32h7 and stm32mp1.
> +- vdd-supply: Phandle to the vdd input voltage. It can be used to supply ADC
> + analog input switches on stm32mp1.
> +- st,syscfg: Phandle to system configuration controller. It can be used to
> + control the analog circuitry on stm32mp1.
>
> Contents of a stm32 adc child node:
> -----------------------------------
^ permalink raw reply
* Re: [PATCH 3/3] iio: light: stk3310: Add device tree support
From: Jonathan Cameron @ 2019-07-14 15:23 UTC (permalink / raw)
To: Luca Weiss
Cc: linux-iio, Hartmut Knaack, Lars-Peter Clausen,
Peter Meerwald-Stadler, Rob Herring, Mark Rutland, Maxime Ripard,
Mauro Carvalho Chehab, Hans Verkuil, Fabrizio Castro,
Angus Ainslie (Purism), Vivek Unune, Hannes Schmelzer,
Greg Kroah-Hartman, Thomas Gleixner, Allison Randal,
Martijn Braam, devicetree, linux-kernel, ~marti
In-Reply-To: <20190703180604.9840-3-luca@z3ntu.xyz>
On Wed, 3 Jul 2019 20:05:59 +0200
Luca Weiss <luca@z3ntu.xyz> wrote:
> Add device tree support for the stk33xx family of ambient light sensors.
>
> Tested-by: Martijn Braam <martijn@brixit.nl>
> Signed-off-by: Luca Weiss <luca@z3ntu.xyz>
Applied,
Thanks,
Jonathan
> ---
> drivers/iio/light/stk3310.c | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/drivers/iio/light/stk3310.c b/drivers/iio/light/stk3310.c
> index b955183edfe8..185c24a75ae6 100644
> --- a/drivers/iio/light/stk3310.c
> +++ b/drivers/iio/light/stk3310.c
> @@ -679,9 +679,18 @@ static const struct acpi_device_id stk3310_acpi_id[] = {
>
> MODULE_DEVICE_TABLE(acpi, stk3310_acpi_id);
>
> +static const struct of_device_id stk3310_of_match[] = {
> + { .compatible = "sensortek,stk3310", },
> + { .compatible = "sensortek,stk3311", },
> + { .compatible = "sensortek,stk3335", },
> + {}
> +};
> +MODULE_DEVICE_TABLE(of, stk3310_of_match);
> +
> static struct i2c_driver stk3310_driver = {
> .driver = {
> .name = "stk3310",
> + .of_match_table = stk3310_of_match,
> .pm = STK3310_PM_OPS,
> .acpi_match_table = ACPI_PTR(stk3310_acpi_id),
> },
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: Add vendor prefix for sensortek
From: Jonathan Cameron @ 2019-07-14 15:22 UTC (permalink / raw)
To: Luca Weiss
Cc: linux-iio, Hartmut Knaack, Lars-Peter Clausen,
Peter Meerwald-Stadler, Rob Herring, Mark Rutland, Maxime Ripard,
Mauro Carvalho Chehab, Hans Verkuil, Fabrizio Castro,
Angus Ainslie (Purism), Vivek Unune, Hannes Schmelzer,
Greg Kroah-Hartman, Thomas Gleixner, Allison Randal,
Martijn Braam, devicetree, linux-kernel, ~marti
In-Reply-To: <20190703180604.9840-1-luca@z3ntu.xyz>
On Wed, 3 Jul 2019 20:05:57 +0200
Luca Weiss <luca@z3ntu.xyz> wrote:
> Sensortek Technology Corp. produces Proximity Sensors with ALS and
> Accelerometers.
>
> Signed-off-by: Luca Weiss <luca@z3ntu.xyz>
Applied to the togreg branch of iio.git and pushed out as testing
for the autobuilders to play with it.
Thanks,
Jonathan
> ---
> This patch series depends on "iio: light: stk3310: Add support for
> stk3335", that's curerntly in linux-next.
>
> Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
> index 342bb23e0a73..d197c9609ea7 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
> @@ -813,6 +813,8 @@ patternProperties:
> description: Semtech Corporation
> "^sensirion,.*":
> description: Sensirion AG
> + "^sensortek,.*":
> + description: Sensortek Technology Corporation
> "^sff,.*":
> description: Small Form Factor Committee
> "^sgd,.*":
^ permalink raw reply
* Re: [PATCH 2/3] dt-bindings: iio: light: add stk33xx
From: Jonathan Cameron @ 2019-07-14 15:21 UTC (permalink / raw)
To: Rob Herring
Cc: Luca Weiss, open list:IIO SUBSYSTEM AND DRIVERS, Hartmut Knaack,
Lars-Peter Clausen, Peter Meerwald-Stadler, Mark Rutland,
Maxime Ripard, Mauro Carvalho Chehab, Hans Verkuil,
Fabrizio Castro, Angus Ainslie (Purism), Vivek Unune,
Hannes Schmelzer, Greg Kroah-Hartman, Thomas Gleixner,
Allison Randal, Martijn Braam, devicetree
In-Reply-To: <CAL_JsqJU5nBf+tzudpXVseeb8FMoJUK3ANJs3btb=6gbcG41EA@mail.gmail.com>
On Fri, 5 Jul 2019 10:23:11 -0600
Rob Herring <robh+dt@kernel.org> wrote:
> On Wed, Jul 3, 2019 at 12:06 PM Luca Weiss <luca@z3ntu.xyz> wrote:
> >
> > Add binding documentation for the stk33xx family of ambient light
> > sensors.
> >
> > Signed-off-by: Luca Weiss <luca@z3ntu.xyz>
> > ---
> > .../bindings/iio/light/stk33xx.yaml | 49 +++++++++++++++++++
> > 1 file changed, 49 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/iio/light/stk33xx.yaml
>
> Reviewed-by: Rob Herring <robh@kernel.org>
Hmm. Not totally sure it makes sense to list me as the maintainer,
but I don't suppose it really matters as I think the author has moved
onto other things and it'll fall back on me.
Anyone who wants to pick up this one is most welcome!
Applied to the togreg branch of iio.git and pushed out as testing for the
autobuilders to play with it.
Thanks,
Jonathan
^ permalink raw reply
* Re: [PATCH 4/8] PCI: Add quirk to disable MSI support for Amazon's Annapurna Labs host bridge
From: Chocron, Jonathan @ 2019-07-14 15:09 UTC (permalink / raw)
To: helgaas@kernel.org
Cc: linux-kernel@vger.kernel.org, robh+dt@kernel.org,
jingoohan1@gmail.com, Woodhouse, David, Hanoch, Uri,
devicetree@vger.kernel.org, lorenzo.pieralisi@arm.com,
gustavo.pimentel@synopsys.com, Wasserstrom, Barak, Saidi, Ali,
mark.rutland@arm.com, Hawa, Hanna, Shenhar, Talel, Krupnik, Ronen,
linux-pci@vger.kernel.org, benh@kernel.crashing.org
In-Reply-To: <20190712130419.GA46935@google.com>
On Fri, 2019-07-12 at 08:04 -0500, Bjorn Helgaas wrote:
> On Thu, Jul 11, 2019 at 05:56:25PM +0300, Jonathan Chocron wrote:
> > On some platforms, the host bridge exposes an MSI-X capability but
> > doesn't actually support it.
> > This causes a crash during initialization by the pcieport driver,
> > since
> > it tries to configure the MSI-X capability.
>
> Nit: The formatting above is jarring to read because I can't tell
> whether it's one paragraph or two.
>
> Either rewrap it into a single paragraph or add a blank line to make
> two paragraphs. I noticed this elsewhere, too, in a comment, I
> think.
>
Ack.
> s/host bridge/Root Port/, if I understand correctly.
>
Ack.
BTW, what is the main difference between the 2 terms, since they seem
to be (mistakenly?) used interchangeably?
> I don't understand the "on some platforms..." part. Do you mean that
> on *every* platform, this particular host bridge (identified by
> [1c36:0031]) advertises an MSI-X capability that doesn't work?
>
> Or are there some platforms that configure the bridge so it doesn't
> advertise MSI-X at all, while other platforms configure it so it
> *does* advertise MSI-X?
>
The MSI-x capability isn't supported for this specific host bridge
([1c36:0031]). On some platforms, it is configured to not advertise the
capability at all, while on others it (mistakenly) does advertise it.
I've updated the commit message to be more explicit.
> If there's a line or two of diagnostics from the crash you could
> include here, that would help people who encounter the crash find
> the solution.
>
Sure, I'll add a partial stacktrace (a bit more than a couple of lines,
but I feel it will be too ambiguous otherwise).
> > Signed-off-by: Jonathan Chocron <jonnyc@amazon.com>
> > ---
> > drivers/pci/quirks.c | 8 ++++++++
> > 1 file changed, 8 insertions(+)
> >
> > diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
> > index 11850b030637..0fb70d755977 100644
> > --- a/drivers/pci/quirks.c
> > +++ b/drivers/pci/quirks.c
> > @@ -2925,6 +2925,14 @@
> > DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATTANSIC, 0x10a1,
> > quirk_msi_intx_disable_qca_bug);
> > DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATTANSIC, 0xe091,
> > quirk_msi_intx_disable_qca_bug);
> > +
> > +static void quirk_al_msi_disable(struct pci_dev *dev)
> > +{
> > + dev->no_msi = 1;
> > + dev_warn(&dev->dev, "Annapurna Labs pcie quirk - disabling
> > MSI\n");
>
> s/pcie/PCIe/ in English text, comments, printk strings, etc.
>
Ack.
> Actually, I think the whole "Annapurna Labs pcie quirk" part is
> probably unnecessary, since we can identify the device via the
> dev_printk() info.
>
Ack.
> Speaking of which, you can use "pci_warn(dev)" here to be consistent
> with the rest of the file.
>
Ack.
> > +}
> > +DECLARE_PCI_FIXUP_CLASS_FINAL(PCI_VENDOR_ID_AMAZON_ANNAPURNA_LABS,
> > 0x0031,
> > + PCI_CLASS_BRIDGE_PCI, 8,
> > quirk_al_msi_disable);
>
> Why do you use the class fixup here instead of the simpler
> DECLARE_PCI_FIXUP_FINAL()? Requiring the class to match
> PCI_CLASS_BRIDGE_PCI suggests that there may be other [1c36:0031]
> devices that are not Root Ports. If that's the case, please mention
> it so it's clear why we need DECLARE_PCI_FIXUP_CLASS_FINAL(). If
> not,
> just use DECLARE_PCI_FIXUP_FINAL().
>
This is indeed the case. What do you say about adding the following
comment before the function's definition:
/*
* Amazon's Annapurna Labs 1c36:0031 Root Ports don't support MSI-X, so
it
* should be disabled on platforms where the device (mistakenly)
advertises it.
*
* The 0031 device id is reused for other non Root Port device types,
* therefore the quirk is registered for the PCI_CLASS_BRIDGE_PCI class
only.
*/
> #endif /* CONFIG_PCI_MSI */
/*
--
2.17.1
^ permalink raw reply
* Re: [PATCH 3/8] PCI/VPD: Add VPD release quirk for Amazon Annapurna Labs host bridge
From: Chocron, Jonathan @ 2019-07-14 15:08 UTC (permalink / raw)
To: helgaas@kernel.org
Cc: linux-kernel@vger.kernel.org, robh+dt@kernel.org,
jingoohan1@gmail.com, Woodhouse, David, Hanoch, Uri,
devicetree@vger.kernel.org, lorenzo.pieralisi@arm.com,
gustavo.pimentel@synopsys.com, Wasserstrom, Barak, Saidi, Ali,
mark.rutland@arm.com, Hawa, Hanna, Shenhar, Talel, Krupnik, Ronen,
linux-pci@vger.kernel.org, benh@kernel.crashing.org
In-Reply-To: <20190712131008.GC46935@google.com>
On Fri, 2019-07-12 at 08:10 -0500, Bjorn Helgaas wrote:
> On Thu, Jul 11, 2019 at 05:55:56PM +0300, Jonathan Chocron wrote:
> > The Amazon Annapurna Labs pcie host bridge exposes the VPD
> > capability,
> > but there is no actual support for it.
>
> s/pcie/PCIe/
> s/host bridge/Root Port/
Ack.
>
> > The reason for not using the already existing quirk_blacklist_vpd()
> > is that, although this fails pci_vpd_read/write, the 'vpd' sysfs
> > entry still exists. When running lspci -vv, for example, this
> > results in the following error:
> >
> > pcilib: sysfs_read_vpd: read failed: Input/output error
> >
> > This quirk removes the sysfs entry, which avoids the error print.
> >
> > Signed-off-by: Jonathan Chocron <jonnyc@amazon.com>
> > ---
> > drivers/pci/vpd.c | 12 ++++++++++++
> > 1 file changed, 12 insertions(+)
> >
> > diff --git a/drivers/pci/vpd.c b/drivers/pci/vpd.c
> > index 4963c2e2bd4c..b594b2895ffe 100644
> > --- a/drivers/pci/vpd.c
> > +++ b/drivers/pci/vpd.c
> > @@ -644,4 +644,16 @@ static void quirk_chelsio_extend_vpd(struct
> > pci_dev *dev)
> > DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, PCI_ANY_ID,
> > quirk_chelsio_extend_vpd);
> >
> > +static void quirk_al_vpd_release(struct pci_dev *dev)
> > +{
> > + if (dev->vpd) {
> > + pci_vpd_release(dev);
> > + dev->vpd = NULL;
> > + pci_warn(dev, FW_BUG "Annapurna Labs pcie quirk -
> > Releasing VPD capability (No support for VPD read/write
> > transactions)\n");
>
> The "Annapurna Labs pcie quirk" text is superfluous.
>
Ack.
> > + }
> > +}
> > +
> > +DECLARE_PCI_FIXUP_CLASS_FINAL(PCI_VENDOR_ID_AMAZON_ANNAPURNA_LABS,
> > 0x0031,
> > + PCI_CLASS_BRIDGE_PCI, 8,
> > quirk_al_vpd_release);
>
> Why DECLARE_PCI_FIXUP_CLASS_FINAL()? See comments on the MSI-X quirk
> patch.
>
Responded in the MSI-x quirk patch, but in short, indeed the 0x0031
dev-id is re-used for a non-host bridge device :(
> > +
> > #endif
> > --
> > 2.17.1
> >
> >
^ permalink raw reply
* Re: [PATCH v5 04/13] media: rc: sunxi: Add RXSTA bits definition
From: Clément Péron @ 2019-07-14 14:32 UTC (permalink / raw)
To: Sean Young
Cc: Mauro Carvalho Chehab, Maxime Ripard, Rob Herring, Mark Rutland,
Chen-Yu Tsai, devicetree, linux-kernel, linux-sunxi,
linux-arm-kernel, linux-media-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20190610095243.7xwp4xhauds22qzw@flea>
Hi Sean,
You acked the whole v3 series but this patch has been introduced in v5
could you ack this one too?
Thanks,
Clément
On Mon, 10 Jun 2019 at 11:52, Maxime Ripard <maxime.ripard-LDxbnhwyfcJBDgjK7y7TUQ@public.gmane.org> wrote:
>
> On Sat, Jun 08, 2019 at 01:10:51AM +0200, Clément Péron wrote:
> > We are using RXINT bits definition when looking at RXSTA register.
> >
> > These bits are equal but it's not really proper.
> >
> > Introduce the RXSTA bits and use them to have coherency.
> >
> > Signed-off-by: Clément Péron <peron.clem-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>
> Acked-by: Maxime Ripard <maxime.ripard-LDxbnhwyfcJBDgjK7y7TUQ@public.gmane.org>
>
> Maxime
>
> --
> Maxime Ripard, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/CAJiuCcfyjGTBbsjZQYj2p3KD6O-WaXhFe5NZrnKQwJYACmatUw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* Re: [PATCH 2/2] MAINTAINERS: add entry for plantower pms7003 driver
From: Jonathan Cameron @ 2019-07-14 11:36 UTC (permalink / raw)
To: Tomasz Duszynski; +Cc: linux-iio, linux-kernel, devicetree, robh+dt
In-Reply-To: <20190710192155.11489-3-tduszyns@gmail.com>
On Wed, 10 Jul 2019 21:21:55 +0200
Tomasz Duszynski <tduszyns@gmail.com> wrote:
> Add myself as a plantower pms7003 driver maintainer.
>
> Signed-off-by: Tomasz Duszynski <tduszyns@gmail.com>
Applied,
Thanks,
Jonathan
> ---
> MAINTAINERS | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index ad498428b38c..771de33ef737 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -12548,6 +12548,12 @@ F: drivers/i2c/busses/i2c-puv3.c
> F: drivers/video/fbdev/fb-puv3.c
> F: drivers/rtc/rtc-puv3.c
>
> +PLANTOWER PMS7003 AIR POLLUTION SENSOR DRIVER
> +M: Tomasz Duszynski <tduszyns@gmail.com>
> +S: Maintained
> +F: drivers/iio/chemical/pms7003.c
> +F: Documentation/devicetree/bindings/iio/chemical/plantower,pms7003.yaml
> +
> PMBUS HARDWARE MONITORING DRIVERS
> M: Guenter Roeck <linux@roeck-us.net>
> L: linux-hwmon@vger.kernel.org
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: iio: chemical: pms7003: convert bindings to yaml
From: Jonathan Cameron @ 2019-07-14 11:36 UTC (permalink / raw)
To: Rob Herring
Cc: Tomasz Duszynski, open list:IIO SUBSYSTEM AND DRIVERS,
linux-kernel@vger.kernel.org, devicetree
In-Reply-To: <CAL_JsqJ8iLuif-UqVzpgwOLafVYr9aOo38EMeUnmYJ0a9aQ5DQ@mail.gmail.com>
On Wed, 10 Jul 2019 14:12:26 -0600
Rob Herring <robh+dt@kernel.org> wrote:
> On Wed, Jul 10, 2019 at 1:22 PM Tomasz Duszynski <tduszyns@gmail.com> wrote:
> >
> > Convert existing device tree bindings to yaml.
> >
> > Signed-off-by: Tomasz Duszynski <tduszyns@gmail.com>
> > ---
> > .../iio/chemical/plantower,pms7003.txt | 26 ----------
> > .../iio/chemical/plantower,pms7003.yaml | 51 +++++++++++++++++++
> > 2 files changed, 51 insertions(+), 26 deletions(-)
> > delete mode 100644 Documentation/devicetree/bindings/iio/chemical/plantower,pms7003.txt
> > create mode 100644 Documentation/devicetree/bindings/iio/chemical/plantower,pms7003.yaml
>
> Reviewed-by: Rob Herring <robh@kernel.org>
Applied to the togreg branch of iio.git and pushed out as testing for
the autobuilders to play with it.
Thanks,
Jonathan
^ permalink raw reply
* Здравствуйте! Вас интересуют клиентские базы данных?
From: devicetree @ 2019-07-14 8:11 UTC (permalink / raw)
To: rhwEdevicetree
Здравствуйте! Вас интересуют клиентские базы данных?
^ permalink raw reply
* Re: [PATCH v4 2/3] dt-bindings: iio: position: Add docs pat9125
From: Jonathan Cameron @ 2019-07-14 10:57 UTC (permalink / raw)
To: Alexandre Mergnat
Cc: robh+dt, mark.rutland, linux-kernel, linux-iio,
baylibre-upstreaming, dmitry.torokhov, linux-input, devicetree
In-Reply-To: <20190713080455.17513-3-amergnat@baylibre.com>
On Sat, 13 Jul 2019 10:04:54 +0200
Alexandre Mergnat <amergnat@baylibre.com> wrote:
> Add documentation for the optical tracker PAT9125 and
> "position" directory for chip which can provides position data.
>
> Signed-off-by: Alexandre Mergnat <amergnat@baylibre.com>
Whilst this one predates my statement that I wanted all bindings
in YAML going forwards, it will want converting at some stage
and if you have time now it would be great to do so!
Thanks,
Jonathan
> ---
> .../bindings/iio/position/pat9125.txt | 18 ++++++++++++++++++
> 1 file changed, 18 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/iio/position/pat9125.txt
>
> diff --git a/Documentation/devicetree/bindings/iio/position/pat9125.txt b/Documentation/devicetree/bindings/iio/position/pat9125.txt
> new file mode 100644
> index 000000000000..4028aeef9b42
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/position/pat9125.txt
> @@ -0,0 +1,18 @@
> +PixArt Imaging PAT9125 Optical Tracking Miniature Chip device driver
> +
> +Required properties:
> + - compatible: must be "pixart,pat9125"
> + - reg: i2c address where to find the device
> + - interrupts: the sole interrupt generated by the device
> +
> + Refer to interrupt-controller/interrupts.txt for generic
> + interrupt client node bindings.
> +
> +Example:
> +
> +pat9125@75 {
> + compatible = "pixart,pat9125";
> + reg = <0x75>;
> + interrupt-parent = <&gpio3>;
> + interrupts = <12 IRQ_TYPE_EDGE_FALLING>;
> +};
^ permalink raw reply
* Re: [PATCH v4 3/3] iio: Add PAT9125 optical tracker sensor
From: Jonathan Cameron @ 2019-07-14 10:56 UTC (permalink / raw)
To: Alexandre Mergnat
Cc: robh+dt, mark.rutland, linux-kernel, linux-iio,
baylibre-upstreaming, dmitry.torokhov, linux-input, devicetree
In-Reply-To: <20190713080455.17513-4-amergnat@baylibre.com>
On Sat, 13 Jul 2019 10:04:55 +0200
Alexandre Mergnat <amergnat@baylibre.com> wrote:
> This adds support for PixArt Imaging’s miniature low power optical
> navigation chip using LASER light source enabling digital surface tracking.
>
> Features and datasheet: [0]
>
> This IIO driver allows to read relative position from where the system
> started on X and Y axis through two way:
> - Punctual "read_raw" which will issue a read in the device registers to
> get the delta between last/current read and return the addition of all
> the deltas.
> - Buffer read. Data can be retrieved using triggered buffer subscription
> (i.e. iio_readdev). The buffer payload is:
> |32 bits delta X|32 bits delta Y|timestamp|.
>
> The possible I2C addresses are 0x73, 0x75 and 0x79.
>
> X and Y axis CPI resolution can be get/set independently through IIO_SCALE.
> The range value is 0-255 which means:
> - 0 to ~1,275 Counts Per Inch on flat surface.
> - 0 to ~630 Counts Per Rev on 1.0mm diameter STS shaft at 1.0mm distance.
> More details on the datasheet.
>
> The "position" directory is added to contain drivers which can provide
> position data.
>
> [0]: http://www.pixart.com/products-detail/72/PAT9125EL-TKIT___TKMT
>
> Signed-off-by: Alexandre Mergnat <amergnat@baylibre.com>
Hi Alexandre,
Sorry for the lack of reply to the previous version. To much jet
lag and travelling recently so I'm just catching up today.
I still want to get the bottom of why the level interrupt
approach isn't working.
I've played these games with using edge interrupts and
try_reenable tricks in the past and they very rarely work out
in the long term.
The issue with try_reenable calling iio_poll_trigger
looks to be a bug in the IIO core, so a patch to fix
that would be welcome!
A few minor other bits inline.
Jonathan
> ---
> drivers/iio/Kconfig | 1 +
> drivers/iio/Makefile | 1 +
> drivers/iio/position/Kconfig | 18 ++
> drivers/iio/position/Makefile | 6 +
> drivers/iio/position/pat9125.c | 506 +++++++++++++++++++++++++++++++++
> 5 files changed, 532 insertions(+)
> create mode 100644 drivers/iio/position/Kconfig
> create mode 100644 drivers/iio/position/Makefile
> create mode 100644 drivers/iio/position/pat9125.c
>
> diff --git a/drivers/iio/Kconfig b/drivers/iio/Kconfig
> index 5bd51853b15e..aca6fcbceeab 100644
> --- a/drivers/iio/Kconfig
> +++ b/drivers/iio/Kconfig
> @@ -85,6 +85,7 @@ source "drivers/iio/light/Kconfig"
> source "drivers/iio/magnetometer/Kconfig"
> source "drivers/iio/multiplexer/Kconfig"
> source "drivers/iio/orientation/Kconfig"
> +source "drivers/iio/position/Kconfig"
> if IIO_TRIGGER
> source "drivers/iio/trigger/Kconfig"
> endif #IIO_TRIGGER
> diff --git a/drivers/iio/Makefile b/drivers/iio/Makefile
> index bff682ad1cfb..1712011c0f4a 100644
> --- a/drivers/iio/Makefile
> +++ b/drivers/iio/Makefile
> @@ -31,6 +31,7 @@ obj-y += light/
> obj-y += magnetometer/
> obj-y += multiplexer/
> obj-y += orientation/
> +obj-y += position/
> obj-y += potentiometer/
> obj-y += potentiostat/
> obj-y += pressure/
> diff --git a/drivers/iio/position/Kconfig b/drivers/iio/position/Kconfig
> new file mode 100644
> index 000000000000..1cf28896511c
> --- /dev/null
> +++ b/drivers/iio/position/Kconfig
> @@ -0,0 +1,18 @@
> +#
> +# Optical tracker sensors
> +#
> +# When adding new entries keep the list in alphabetical order
> +
> +menu "Optical tracker sensors"
> +
> +config PAT9125
> + tristate "Optical tracker PAT9125 I2C driver"
> + depends on I2C
> + select IIO_BUFFER
> + help
> + Say yes here to build support for PAT9125 optical tracker
> + sensors.
> +
> + To compile this driver as a module, say M here: the module will
> + be called pat9125.
> +endmenu
> diff --git a/drivers/iio/position/Makefile b/drivers/iio/position/Makefile
> new file mode 100644
> index 000000000000..cf294917ae2c
> --- /dev/null
> +++ b/drivers/iio/position/Makefile
> @@ -0,0 +1,6 @@
> +#
> +# Makefile for industrial I/O Optical tracker sensor drivers
> +#
> +
> +# When adding new entries keep the list in alphabetical order
> +obj-$(CONFIG_PAT9125) += pat9125.o
> diff --git a/drivers/iio/position/pat9125.c b/drivers/iio/position/pat9125.c
> new file mode 100644
> index 000000000000..2f04777e0790
> --- /dev/null
> +++ b/drivers/iio/position/pat9125.c
> @@ -0,0 +1,506 @@
> +// SPDX-License-Identifier: (GPL-2.0)
> +/*
> + * Copyright (C) 2019 BayLibre, SAS
> + * Author: Alexandre Mergnat <amergnat@baylibre.com>
> + */
> +
> +#include <linux/bitops.h>
> +#include <linux/delay.h>
> +#include <linux/interrupt.h>
> +#include <linux/i2c.h>
> +#include <linux/iio/iio.h>
> +#include <linux/iio/sysfs.h>
> +#include <linux/iio/events.h>
> +#include <linux/iio/buffer.h>
> +#include <linux/iio/trigger.h>
> +#include <linux/iio/trigger_consumer.h>
> +#include <linux/iio/triggered_buffer.h>
> +#include <linux/iio/kfifo_buf.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/regmap.h>
> +#include <linux/slab.h>
> +
> +/* I2C Address function to ID pin*/
> +#define PAT9125_I2C_ADDR_HI 0x73
> +#define PAT9125_I2C_ADDR_LO 0x75
> +#define PAT9125_I2C_ADDR_NC 0x79
> +
> +/* Registers */
> +#define PAT9125_PRD_ID1_REG 0x00
> +#define PAT9125_PRD_ID2_REG 0x01
> +#define PAT9125_MOTION_STATUS_REG 0x02
> +#define PAT9125_DELTA_X_LO_REG 0x03
> +#define PAT9125_DELTA_Y_LO_REG 0x04
> +#define PAT9125_OP_MODE_REG 0x05
> +#define PAT9125_CONFIG_REG 0x06
> +#define PAT9125_WRITE_PROTEC_REG 0x09
> +#define PAT9125_SLEEP1_REG 0x0A
> +#define PAT9125_SLEEP2_REG 0x0B
> +#define PAT9125_RES_X_REG 0x0D
> +#define PAT9125_RES_Y_REG 0x0E
> +#define PAT9125_DELTA_XY_HI_REG 0x12
> +#define PAT9125_SHUTER_REG 0x14
> +#define PAT9125_FRAME_AVG_REG 0x17
> +#define PAT9125_ORIENTATION_REG 0x19
> +
> +/* Bits */
> +#define PAT9125_VALID_MOTION_DATA_BIT BIT(7)
> +#define PAT9125_RESET_BIT BIT(7)
Please use naming that associates these with which register
they are in.
> +
> +/* Registers' values */
> +#define PAT9125_SENSOR_ID_VAL 0x31
> +#define PAT9125_DISABLE_WRITE_PROTECT_VAL 0x5A
> +#define PAT9125_ENABLE_WRITE_PROTECT_VAL 0x00
> +
> +/* Default Value of sampled value size */
> +#define PAT9125_SAMPLED_VAL_BIT_SIZE 12
> +
> +struct pat9125_data {
> + struct regmap *regmap;
> + struct iio_trigger *indio_trig; /* Motion detection */
> + s32 position_x;
> + s32 position_y;
> + bool sampling;
> +};
> +
> +static const struct iio_chan_spec pat9125_channels[] = {
> + {
> + .type = IIO_DISTANCE,
> + .modified = 1,
> + .channel2 = IIO_MOD_X,
> + .info_mask_separate = BIT(IIO_CHAN_INFO_RAW) |
> + BIT(IIO_CHAN_INFO_SCALE),
> + .scan_index = 0,
> + .scan_type = {
> + .sign = 's',
> + .realbits = 32,
> + .storagebits = 32,
> + .endianness = IIO_CPU,
> + },
> + },
> + {
> + .type = IIO_DISTANCE,
> + .modified = 1,
> + .channel2 = IIO_MOD_Y,
> + .info_mask_separate = BIT(IIO_CHAN_INFO_RAW) |
> + BIT(IIO_CHAN_INFO_SCALE),
> + .scan_index = 1,
> + .scan_type = {
> + .sign = 's',
> + .realbits = 32,
> + .storagebits = 32,
> + .endianness = IIO_CPU,
> + },
> + },
> + IIO_CHAN_SOFT_TIMESTAMP(2),
> +};
> +
> +/**
> + * pat9125_write_pretected_reg() - Write value in protected register.
> + *
> + * @regmap: Pointer to I2C register map.
> + * @reg_addr: Register address.
> + * @reg_value: Value to be write in register.
> + *
> + * A value of zero will be returned on success, a negative errno will
> + * be returned in error cases.
> + */
> +static int pat9125_write_pretected_reg(struct iio_dev *indio_dev,
> + u8 reg_addr, u8 reg_value)
> +{
> + struct pat9125_data *data = iio_priv(indio_dev);
> + int ret;
> +
> + ret = regmap_write(data->regmap,
> + PAT9125_WRITE_PROTEC_REG,
> + PAT9125_DISABLE_WRITE_PROTECT_VAL);
> +
> + if (!ret)
> + ret = regmap_write(data->regmap, reg_addr, reg_value);
> +
> + /* Try to put back write protection everytime */
> + ret |= regmap_write(data->regmap,
> + PAT9125_WRITE_PROTEC_REG,
> + PAT9125_ENABLE_WRITE_PROTECT_VAL);
This ret |= trick leads to scrambled error codes. So don't do it,
use two return variables and return the first one to give an
error if one occurs.
> +
> + return ret;
> +}
> +/**
> + * pat9125_read_delta() - Read delta value, update delta & position data.
> + *
> + * @data: Driver's data structure.
> + *
> + * A value of zero will be returned on success, a negative errno will
> + * be returned in error cases.
> + */
> +static int pat9125_read_delta(struct pat9125_data *data)
> +{
> + struct regmap *regmap = data->regmap;
> + int status = 0;
> + int val_x = 0;
Some of these are assigned anyway in all paths that use them.
> + int val_y = 0;
> + int val_high_nibbles = 0;
> + int ret;
> +
> + ret = regmap_read(regmap, PAT9125_MOTION_STATUS_REG, &status);
> + if (ret < 0)
> + return ret;
> +
> + /* Check if motion is detected */
> + if (status & PAT9125_VALID_MOTION_DATA_BIT) {
> + ret = regmap_read(regmap, PAT9125_DELTA_X_LO_REG, &val_x);
> + if (ret < 0)
> + return ret;
> +
> + ret = regmap_read(regmap, PAT9125_DELTA_Y_LO_REG, &val_y);
> + if (ret < 0)
> + return ret;
> +
> + ret = regmap_read(regmap, PAT9125_DELTA_XY_HI_REG,
> + &val_high_nibbles);
> + if (ret < 0)
> + return ret;
> +
> + val_x |= (val_high_nibbles << 4) & 0xF00;
> + val_y |= (val_high_nibbles << 8) & 0xF00;
> + val_x = sign_extend32(val_x,
> + PAT9125_SAMPLED_VAL_BIT_SIZE - 1);
> + val_y = sign_extend32(val_y,
> + PAT9125_SAMPLED_VAL_BIT_SIZE - 1);
> + data->position_x += val_x;
> + data->position_y += val_y;
> + }
> + return 0;
> +}
> +
> +/**
> + * pat9125_read_raw() - Sample and return the value(s)
> + * function to the associated channel info enum.
> + *
> + * @indio_dev: Industrial I/O device.
> + * @chan: Specification of a single channel.
> + * @val: Contain the elements making up the returned value.
> + * @val2: Not used.
> + * @mask: (enum iio_chan_info_enum) Type of the info attribute.
> + *
> + * Zero will be returned on success, negative value otherwise.
> + **/
> +static int pat9125_read_raw(struct iio_dev *indio_dev,
> + struct iio_chan_spec const *chan,
> + int *val, int *val2, long mask)
> +{
> + struct pat9125_data *data = iio_priv(indio_dev);
> + int ret;
> +
> + switch (mask) {
> + case IIO_CHAN_INFO_RAW:
> + ret = pat9125_read_delta(data);
> + if (ret)
> + return ret;
> + switch (chan->channel2) {
> + case IIO_MOD_X:
> + *val = data->position_x;
> + return IIO_VAL_INT;
> + case IIO_MOD_Y:
> + *val = data->position_y;
> + return IIO_VAL_INT;
> + default:
> + return -EINVAL;
> + }
> + case IIO_CHAN_INFO_SCALE:
> + switch (chan->channel2) {
> + case IIO_MOD_X:
> + ret = regmap_read(data->regmap, PAT9125_RES_X_REG, val);
> + if (ret)
> + return ret;
> + else
These else against an error case are not common kernel idiom for error handling..
if (ret)
return ret;
return IIO_VAL_INT;
> + return IIO_VAL_INT;
> + case IIO_MOD_Y:
> + ret = regmap_read(data->regmap, PAT9125_RES_Y_REG, val);
> + if (ret)
> + return ret;
> + else
> + return IIO_VAL_INT;
> + default:
> + return -EINVAL;
> + }
> + default:
> + return -EINVAL;
> + }
> +}
> +
> +/**
> + * pat9125_write_raw() - Write the value(s)
> + * function to the associated channel info enum.
> + *
> + * @indio_dev: Industrial I/O device.
> + * @chan: Specification of a single channel.
> + * @val: Value write in the channel.
> + * @val2: Not used.
> + * @mask: (enum iio_chan_info_enum) Type of the info attribute.
> + *
> + * Zero will be returned on success, negative value otherwise.
> + **/
Kernel doc style is normally
*/ at end.
> +static int pat9125_write_raw(struct iio_dev *indio_dev,
> + struct iio_chan_spec const *chan, int val,
> + int val2, long mask)
> +{
> + int ret;
> +
> + switch (mask) {
> + case IIO_CHAN_INFO_SCALE:
> + switch (chan->channel2) {
> + case IIO_MOD_X:
> + ret = pat9125_write_pretected_reg(indio_dev,
> + PAT9125_RES_X_REG, val);
> + return ret;
> + case IIO_MOD_Y:
> + ret = pat9125_write_pretected_reg(indio_dev,
> + PAT9125_RES_Y_REG, val);
> + return ret;
> + default:
> + return -EINVAL;
> + }
> + default:
> + return -EINVAL;
> + }
> +}
> +
> +static irqreturn_t pat9125_threaded_trigger_handler(int irq, void *p)
> +{
> + struct iio_poll_func *pf = p;
> + struct iio_dev *indio_dev = pf->indio_dev;
> + struct pat9125_data *data = iio_priv(indio_dev);
> + u8 buf[16]; /* Payload: Pos_X (4) | Pos_Y (4) | Timestamp (8) */
> + int ret;
> + s64 timestamp;
> +
> + data->sampling = true;
> + ret = pat9125_read_delta(data);
> + if (ret) {
> + dev_err(indio_dev->dev.parent, "Read delta failed %d\n", ret);
> + return IRQ_NONE;
> + }
> + timestamp = iio_get_time_ns(indio_dev);
> + *((s32 *)&buf[0]) = data->position_x;
> + *((s32 *)&buf[sizeof(s32)]) = data->position_y;
> + iio_push_to_buffers_with_timestamp(indio_dev, buf, timestamp);
> + iio_trigger_notify_done(indio_dev->trig);
> + return IRQ_HANDLED;
> +}
> +
> +/**
> + * pat9125_threaded_event_handler() - Threaded motion detection event handler
> + * @irq: The irq being handled.
> + * @private: struct iio_device pointer for the device.
> + */
> +static irqreturn_t pat9125_threaded_event_handler(int irq, void *private)
> +{
> + struct iio_dev *indio_dev = private;
> + struct pat9125_data *data = iio_priv(indio_dev);
> +
> + iio_trigger_poll_chained(data->indio_trig);
> + return IRQ_HANDLED;
> +}
> +
> +/**
> + * pat9125_buffer_postenable() - Buffer post enable actions
> + *
> + * @indio_dev: Industrial I/O device.
> + */
> +static int pat9125_buffer_postenable(struct iio_dev *indio_dev)
> +{
> + struct pat9125_data *data = iio_priv(indio_dev);
> + int ret = 0;
Check for any other cases of this.
Doesn't need to be assigned as is assigned in all paths.
> +
> + ret = iio_triggered_buffer_postenable(indio_dev);
> + if (ret)
> + return ret;
> +
> + /* Release interrupt pin on the device */
> + ret = pat9125_read_delta(data);
> +
> + /* iio_trigger_detach_poll_func isn't reachable, so use this function */
Slightly odd comment. We need to unwind iio_triggered_buffer_postenable, so
iio_triggered_buffer_predisable is the right function anyway..
> + if (ret)
> + ret = iio_triggered_buffer_predisable(indio_dev);
> +
> + return ret;
> +}
> +
> +static const struct iio_buffer_setup_ops pat9125_buffer_ops = {
> + .postenable = pat9125_buffer_postenable,
> +};
> +
> +static const struct regmap_config pat9125_regmap_config = {
> + .reg_bits = 8,
> + .val_bits = 8,
> +};
> +
> +static const struct iio_info pat9125_info = {
> + .read_raw = pat9125_read_raw,
> + .write_raw = pat9125_write_raw,
> +};
> +
> +/*
> + * To detect if a new value is available, register status is checked. This
> + * method is safer than using a flag on GPIO IRQ to track event while sampling
> + * because falling edge is missed when device trig just after a read reg value
> + * (that happen for fast motions or high CPI setting).
> + *
> + * Note: To avoid infinite loop in "iio_trigger_notify_done" when it is not in
> + * buffer mode and kernel warning due to nested IRQ thread,
> + * this function must return 0.
Two things here.
For infinite loop prevention it would be cleaner to have an explicit
countdown in here (so let it loop N times).
I would also like to see a warning if it times out.
The point about not calling the iio_trigger_poll that would result from
a failed try reenable looks like a core bug to me.
I don't think try_reenable is ever called from interrupt context.
IIRC The interrupt code used to be a lot laxer on that so it probably
wouldn't have caused a problem originally but does now.
Hence please send a fix patch for the core code to switch to
the chained version.
> + */
> +static int pat9125_trig_try_reenable(struct iio_trigger *trig)
> +{
> + struct pat9125_data *data = iio_trigger_get_drvdata(trig);
> + struct regmap *regmap = data->regmap;
> + int status = 0;
> +
> + if (data->sampling) {
> + regmap_read(regmap, PAT9125_MOTION_STATUS_REG, &status);
> + if (status & PAT9125_VALID_MOTION_DATA_BIT) {
> + data->sampling = false;
> + iio_trigger_poll_chained(data->indio_trig);
> + return 0;
> + }
> + }
> + data->sampling = false;
> + return 0;
> +}
> +
> +static const struct iio_trigger_ops pat9125_trigger_ops = {
> + .try_reenable = pat9125_trig_try_reenable,
> +};
> +
> +static int pat9125_probe(struct i2c_client *client,
> + const struct i2c_device_id *id)
> +{
> + struct pat9125_data *data;
> + struct iio_dev *indio_dev;
> + int ret, sensor_pid;
> +
> + indio_dev = devm_iio_device_alloc(&client->dev, sizeof(*data));
> + if (!indio_dev) {
> + dev_err(&client->dev, "IIO device allocation failed\n");
> + return -ENOMEM;
> + }
> +
> + data = iio_priv(indio_dev);
> + indio_dev->dev.parent = &client->dev;
> + indio_dev->name = id->name;
> + indio_dev->channels = pat9125_channels;
> + indio_dev->num_channels = ARRAY_SIZE(pat9125_channels);
> + indio_dev->info = &pat9125_info;
> + indio_dev->modes = INDIO_DIRECT_MODE;
> +
> + ret = devm_iio_triggered_buffer_setup(&client->dev, indio_dev, NULL,
> + pat9125_threaded_trigger_handler, &pat9125_buffer_ops);
> + if (ret) {
> + dev_err(&client->dev, "unable to setup triggered buffer\n");
> + return ret;
> + }
> +
> + data->indio_trig = devm_iio_trigger_alloc(&client->dev, "%s-dev%d",
> + indio_dev->name, indio_dev->id);
> + if (!data->indio_trig)
> + return -ENOMEM;
> + data->indio_trig->dev.parent = &client->dev;
> + data->indio_trig->ops = &pat9125_trigger_ops;
> + iio_trigger_set_drvdata(data->indio_trig, data);
> + ret = devm_iio_trigger_register(&client->dev, data->indio_trig);
> + if (ret) {
> + dev_err(&client->dev, "unable to register trigger\n");
> + return ret;
> + }
> +
> + data->regmap = devm_regmap_init_i2c(client, &pat9125_regmap_config);
> + if (IS_ERR(data->regmap)) {
> + dev_err(&client->dev, "regmap init failed %ld\n",
> + PTR_ERR(data->regmap));
> + return PTR_ERR(data->regmap);
> + }
> +
> + /* Check device ID */
> + ret = regmap_read(data->regmap, PAT9125_PRD_ID1_REG, &sensor_pid);
> + if (ret < 0) {
> + dev_err(&client->dev, "register 0x%x access failed %d\n",
> + PAT9125_PRD_ID1_REG, ret);
> + return ret;
> + }
> + if (sensor_pid != PAT9125_SENSOR_ID_VAL)
> + return -ENODEV;
> +
> + /* Switch to bank0 (Magic number)*/
> + ret = regmap_write(data->regmap, 0x7F, 0x00);
> + if (ret < 0) {
> + dev_err(indio_dev->dev.parent, "register 0x%x access failed %d\n",
> + 0x7F, ret);
> + return ret;
> + }
> +
> + /* Software reset */
> + ret = regmap_write_bits(data->regmap,
> + PAT9125_CONFIG_REG,
> + PAT9125_RESET_BIT,
> + 1);
> + if (ret < 0) {
> + dev_err(&client->dev, "register 0x%x access failed %d\n",
> + PAT9125_CONFIG_REG, ret);
> + return ret;
> + }
> +
> + msleep(20);
> +
> + /* Init GPIO IRQ */
> + if (client->irq) {
> + ret = devm_request_threaded_irq(&client->dev,
> + client->irq,
> + NULL,
> + pat9125_threaded_event_handler,
> + IRQF_TRIGGER_FALLING | IRQF_ONESHOT,
> + "pat9125",
> + indio_dev);
> + if (ret) {
> + dev_err(&client->dev, "GPIO IRQ init failed\n");
> + return ret;
> + }
> + }
> +
> + ret = devm_iio_device_register(&client->dev, indio_dev);
> + if (ret) {
> + dev_err(&client->dev, "IIO device register failed\n");
> + return ret;
Drop the return ret out of these brackets. One of the static checkers
picks up on this sequence and will moan otherwise (can't recall which).
> + }
> +
> + return 0;
> +}
> +
> +static const struct i2c_device_id pat9125_id[] = {
> + { "pat9125", 0 },
> + {}
> +};
> +MODULE_DEVICE_TABLE(i2c, pat9125_id);
> +
> +static const unsigned short normal_i2c[] = {
> + PAT9125_I2C_ADDR_HI,
> + PAT9125_I2C_ADDR_LO,
> + PAT9125_I2C_ADDR_NC,
> + I2C_CLIENT_END
> +};
> +
> +static struct i2c_driver pat9125_driver = {
> + .driver = {
> + .name = "pat9125",
> + },
> + .probe = pat9125_probe,
> + .address_list = normal_i2c,
> + .id_table = pat9125_id,
> +};
> +
> +module_i2c_driver(pat9125_driver);
> +
> +MODULE_AUTHOR("Alexandre Mergnat <amergnat@baylibre.com>");
> +MODULE_DESCRIPTION("Optical Tracking sensor");
> +MODULE_LICENSE("GPL");
^ permalink raw reply
* Re: [PATCH v8 07/21] iommu/io-pgtable-arm-v7s: Extend MediaTek 4GB Mode
From: Yong Wu @ 2019-07-14 4:41 UTC (permalink / raw)
To: Will Deacon
Cc: youlin.pei, devicetree, Nicolas Boichat, cui.zhang,
srv_heupstream, Tomasz Figa, Joerg Roedel, Will Deacon,
linux-kernel, Evan Green, chao.hao, iommu, Rob Herring,
linux-mediatek, Matthias Brugger, yingjoe.chen, anan.sun,
Robin Murphy, Matthias Kaehlcke, linux-arm-kernel
In-Reply-To: <20190711123129.da4rg35b54u4svfw@willie-the-truck>
On Thu, 2019-07-11 at 13:31 +0100, Will Deacon wrote:
> On Thu, Jul 11, 2019 at 07:53:56PM +0800, Yong Wu wrote:
> > On Wed, 2019-07-10 at 15:36 +0100, Will Deacon wrote:
> > > On Sat, Jun 29, 2019 at 10:09:13AM +0800, Yong Wu wrote:
> > > > MediaTek extend the arm v7s descriptor to support the dram over 4GB.
> > > >
> > > > In the mt2712 and mt8173, it's called "4GB mode", the physical address
> > > > is from 0x4000_0000 to 0x1_3fff_ffff, but from EMI point of view, it
> > > > is remapped to high address from 0x1_0000_0000 to 0x1_ffff_ffff, the
> > > > bit32 is always enabled. thus, in the M4U, we always enable the bit9
> > > > for all PTEs which means to enable bit32 of physical address.
> > > >
> > > > but in mt8183, M4U support the dram from 0x4000_0000 to 0x3_ffff_ffff
> > > > which isn't remaped. We extend the PTEs: the bit9 represent bit32 of
> > > > PA and the bit4 represent bit33 of PA. Meanwhile the iova still is
> > > > 32bits.
> > >
> > > What happens if bit4 is set in the pte for mt2712 or mt8173? Perhaps the
> >
> > bit4 is ignored in mt2712 and mt8173(No effect).
> >
> > > io-pgtable backend should be allowing oas > 32 when
> > > IO_PGTABLE_QUIRK_ARM_MTK_4GB is set, and then enforcing that itself.
> >
> > About oas, It looks the oas doesn't work in current the v7s.
> >
> > How about I add a new simple preparing patch like this(copy from
> > io-pgtable-arm.c)?
>
> This looks like the right sort of idea. Basically, I was thinking that you
> can use the oas in conjunction with the quirk to specify whether or not
> your two magic bits should be set. You could also then cap the oas using
> the size of phys_addr_t to deal with my other comment.
>
> Finally, I was hoping you could drop the |= BIT_ULL(32) and the &=
> ~BIT_ULL(32) bits of the mtk driver if the pgtable code now accepts higher
> addresses. Did that not work out?
After the current patch, the pgtable has accepted the higher address.
the " |= BIT_ULL(32)" and "& = ~ BIT_ULL(32)" is for a special case(we
call it 4GB mode).
Now MediaTek IOMMU support 2 kind memory:
1) normal case: PA is 0x4000_0000 - 0x3_ffff_ffff. the PA won't be
remapped. mt8183 and the non-4GB mode of mt8173/mt2712 use this mode.
2) 4GB Mode: PA is 0x4000_0000 - 0x1_3fff_ffff. But the PA will remapped
to 0x1_0000_0000 to 0x1_ffff_ffff. This is for the 4GB mode of
mt8173/mt2712. This case is so special that we should change the PA
manually(add bit32).
(mt2712 and mt8173 have both mode: 4GB and non-4GB.)
If we try to use oas and our quirk to cover this two case. Then I can
use "oas == 33" only for this 4GB mode. and "oas == 34" for the normal
case even though the PA mayn't reach 34bit. Also I should add some
"workaround" for the 4GB mode(oas==33).
I copy the new patch in the mail below(have dropped the "|= BIT_ULL(32)"
and the "&= ~BIT_ULL(32)) in mtk iommu". please help have a look if it
is ok.
(another thing: Current the PA can support over 4GB. So the quirk name
"MTK_4GB" looks not suitable, I used a new patch rename to "MTK_EXT").
> >
> > ==========================================
> > --- a/drivers/iommu/io-pgtable-arm-v7s.c
> > +++ b/drivers/iommu/io-pgtable-arm-v7s.c
> > @@ -495,7 +495,8 @@ static int arm_v7s_map(struct io_pgtable_ops *ops,
> > unsigned long iova,
> > if (!(prot & (IOMMU_READ | IOMMU_WRITE)))
> > return 0;
> >
> > - if (WARN_ON(upper_32_bits(iova) || upper_32_bits(paddr)))
> > + if (WARN_ON(iova >= (1ULL << data->iop.cfg.ias) ||
> > + paddr >= (1ULL << data->iop.cfg.oas)))
> > return -ERANGE;
> >
> > ===============================================
> >
> > Then, change the oas in MTK 4GB mode, like this:
> >
> > ================================================
> > --- a/drivers/iommu/io-pgtable-arm-v7s.c
> > +++ b/drivers/iommu/io-pgtable-arm-v7s.c
> > @@ -721,7 +721,9 @@ static struct io_pgtable
> > *arm_v7s_alloc_pgtable(struct io_pgtable_cfg *cfg,
> > {
> > struct arm_v7s_io_pgtable *data;
> >
> > - if (cfg->ias > ARM_V7S_ADDR_BITS || cfg->oas >
> > ARM_V7S_ADDR_BITS)
> > + if (cfg->ias > ARM_V7S_ADDR_BITS ||
> > + (cfg->oas > ARM_V7S_ADDR_BITS &&
> > + !(cfg->quirks & IO_PGTABLE_QUIRK_ARM_MTK_4GB)))
>
> This should probably still be capped at 34 bits.
Don't get here. This is only a simple checking (if (oas > 32) return
NULL). I should avoid this checking for our case.
>
> > > > + paddr = pte & mask;
> > > > + if (cfg->quirks & IO_PGTABLE_QUIRK_ARM_MTK_4GB) {
> > > > + if (pte & ARM_V7S_ATTR_MTK_PA_BIT32)
> > > > + paddr |= BIT_ULL(32);
> > > > + if (pte & ARM_V7S_ATTR_MTK_PA_BIT33)
> > > > + paddr |= BIT_ULL(33);
> > > > + }
> > > > + return paddr;
> > >
> > > I think this relies on CONFIG_PHYS_ADDR_T_64BIT, which isn't always set on
> > > 32-bit ARM.
> >
> > This was discussed at [1]. Robin commented that this is not needed and
> > build won't complain about this.
>
> It's not so much the build I was worried about, but more that we'd silently
> be doing the wrong thing and I think we can fix that as I mentioned above.
OK. see below.
>
> Will
>
===================================
-#define ARM_V7S_ATTR_MTK_4GB BIT(9) /* MTK extend it for 4GB mode */
+/* MediaTek extend the two bits for PA 32bit/33bit */
+#define ARM_V7S_ATTR_MTK_PA_BIT32 BIT(9)
+#define ARM_V7S_ATTR_MTK_PA_BIT33 BIT(4)
/* *well, except for TEX on level 2 large pages, of course :( */
#define ARM_V7S_CONT_PAGE_TEX_SHIFT 6
@@ -190,13 +192,22 @@ static dma_addr_t __arm_v7s_dma_addr(void *pages)
static arm_v7s_iopte paddr_to_iopte(phys_addr_t paddr, int lvl,
struct io_pgtable_cfg *cfg)
{
- return paddr & ARM_V7S_LVL_MASK(lvl);
+ arm_v7s_iopte pte = paddr & ARM_V7S_LVL_MASK(lvl);
+
+ if (cfg->quirks & IO_PGTABLE_QUIRK_ARM_MTK_EXT) {
+ if ((paddr & BIT_ULL(32)) || cfg->oas == 33 /* 4GB mode */)
+ pte |= ARM_V7S_ATTR_MTK_PA_BIT32;
+ if (paddr & BIT_ULL(33))
+ pte |= ARM_V7S_ATTR_MTK_PA_BIT33;
+ }
+ return pte;
}
static phys_addr_t iopte_to_paddr(arm_v7s_iopte pte, int lvl,
struct io_pgtable_cfg *cfg)
{
arm_v7s_iopte mask;
+ phys_addr_t paddr;
if (ARM_V7S_PTE_IS_TABLE(pte, lvl))
mask = ARM_V7S_TABLE_MASK;
@@ -205,7 +216,20 @@ static phys_addr_t iopte_to_paddr(arm_v7s_iopte
pte, int lvl,
else
mask = ARM_V7S_LVL_MASK(lvl);
- return pte & mask;
+ paddr = pte & mask;
+ if (IS_ENABLED(CONFIG_PHYS_ADDR_T_64BIT) &&
+ (cfg->quirks & IO_PGTABLE_QUIRK_ARM_MTK_EXT)) {
+ /*
+ * Workaround for MTK 4GB Mode:
+ * Add BIT32 only when PA < 0x4000_0000.
+ */
+ if ((cfg->oas == 33 && paddr < 0x40000000UL) ||
+ (cfg->oas > 33 && (pte & ARM_V7S_ATTR_MTK_PA_BIT32)))
+ paddr |= BIT_ULL(32);
+ if (pte & ARM_V7S_ATTR_MTK_PA_BIT33)
+ paddr |= BIT_ULL(33);
+ }
+ return paddr;
}
static arm_v7s_iopte *iopte_deref(arm_v7s_iopte pte, int lvl,
@@ -326,9 +350,6 @@ static arm_v7s_iopte arm_v7s_prot_to_pte(int prot,
int lvl,
if (lvl == 1 && (cfg->quirks & IO_PGTABLE_QUIRK_ARM_NS))
pte |= ARM_V7S_ATTR_NS_SECTION;
- if (cfg->quirks & IO_PGTABLE_QUIRK_ARM_MTK_EXT)
- pte |= ARM_V7S_ATTR_MTK_4GB;
-
return pte;
}
@@ -742,7 +763,9 @@ static struct io_pgtable
*arm_v7s_alloc_pgtable(struct io_pgtable_cfg *cfg,
{
struct arm_v7s_io_pgtable *data;
- if (cfg->ias > ARM_V7S_ADDR_BITS || cfg->oas > ARM_V7S_ADDR_BITS)
+ if (cfg->ias > ARM_V7S_ADDR_BITS ||
+ (cfg->oas > ARM_V7S_ADDR_BITS &&
+ !(cfg->quirks & IO_PGTABLE_QUIRK_ARM_MTK_EXT)))
return NULL;
if (cfg->quirks & ~(IO_PGTABLE_QUIRK_ARM_NS |
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index 85e71fb..1a141ea 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -271,16 +271,18 @@ static int mtk_iommu_domain_finalise(struct
mtk_iommu_domain *dom)
dom->cfg = (struct io_pgtable_cfg) {
.quirks = IO_PGTABLE_QUIRK_ARM_NS |
IO_PGTABLE_QUIRK_NO_PERMS |
- IO_PGTABLE_QUIRK_TLBI_ON_MAP,
+ IO_PGTABLE_QUIRK_TLBI_ON_MAP |
+ IO_PGTABLE_QUIRK_ARM_MTK_EXT,
.pgsize_bitmap = mtk_iommu_ops.pgsize_bitmap,
.ias = 32,
- .oas = 32,
.tlb = &mtk_iommu_gather_ops,
.iommu_dev = data->dev,
};
if (data->enable_4GB)
- dom->cfg.quirks |= IO_PGTABLE_QUIRK_ARM_MTK_EXT;
+ dom->cfg.oas = 33; /* Only for 4GB mode */
+ else
+ dom->cfg.oas = 34;
dom->iop = alloc_io_pgtable_ops(ARM_V7S, &dom->cfg, data);
if (!dom->iop) {
@@ -371,8 +373,7 @@ static int mtk_iommu_map(struct iommu_domain
*domain, unsigned long iova,
int ret;
spin_lock_irqsave(&dom->pgtlock, flags);
- ret = dom->iop->map(dom->iop, iova, paddr & DMA_BIT_MASK(32),
- size, prot);
+ ret = dom->iop->map(dom->iop, iova, paddr, size, prot);
spin_unlock_irqrestore(&dom->pgtlock, flags);
return ret;
@@ -401,7 +402,6 @@ static phys_addr_t mtk_iommu_iova_to_phys(struct
iommu_domain *domain,
dma_addr_t iova)
{
struct mtk_iommu_domain *dom = to_mtk_domain(domain);
- struct mtk_iommu_data *data = mtk_iommu_get_m4u_data();
unsigned long flags;
phys_addr_t pa;
@@ -409,9 +409,6 @@ static phys_addr_t mtk_iommu_iova_to_phys(struct
iommu_domain *domain,
pa = dom->iop->iova_to_phys(dom->iop, iova);
spin_unlock_irqrestore(&dom->pgtlock, flags);
- if (data->enable_4GB)
- pa |= BIT_ULL(32);
-
return pa;
}
===================================
> _______________________________________________
> Linux-mediatek mailing list
> Linux-mediatek@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply related
* [PATCH 6/6] pinctrl: Ingenic: Add pinctrl driver for X1500.
From: Zhou Yanjie @ 2019-07-14 3:53 UTC (permalink / raw)
To: linux-mips
Cc: linux-kernel, linux-gpio, devicetree, paul.burton, linus.walleij,
robh+dt, mark.rutland
In-Reply-To: <1563076436-5338-1-git-send-email-zhouyanjie@zoho.com>
Add support for probing the pinctrl-ingenic driver on the
X1500 Soc from Ingenic.
Signed-off-by: Zhou Yanjie <zhouyanjie@zoho.com>
---
drivers/pinctrl/pinctrl-ingenic.c | 118 +++++++++++++++++++++++++++++++++++++-
1 file changed, 117 insertions(+), 1 deletion(-)
diff --git a/drivers/pinctrl/pinctrl-ingenic.c b/drivers/pinctrl/pinctrl-ingenic.c
index 5bb4ae5..6e26830 100644
--- a/drivers/pinctrl/pinctrl-ingenic.c
+++ b/drivers/pinctrl/pinctrl-ingenic.c
@@ -3,6 +3,7 @@
* Ingenic SoCs pinctrl driver
*
* Copyright (c) 2017 Paul Cercueil <paul@crapouillou.net>
+ * Copyright (c) 2019 Zhou Yanjie <zhouyanjie@zoho.com>
*/
#include <linux/compiler.h>
@@ -58,6 +59,7 @@ enum jz_version {
ID_JZ4780,
ID_X1000,
ID_X1000E,
+ ID_X1500,
};
struct ingenic_chip_info {
@@ -1218,6 +1220,116 @@ static const struct ingenic_chip_info x1000e_chip_info = {
.pull_downs = x1000_pull_downs,
};
+static int x1500_uart0_data_pins[] = { 0x4a, 0x4b, };
+static int x1500_uart0_hwflow_pins[] = { 0x4c, 0x4d, };
+static int x1500_uart1_data_a_pins[] = { 0x04, 0x05, };
+static int x1500_uart1_data_d_pins[] = { 0x62, 0x63, };
+static int x1500_uart1_hwflow_d_pins[] = { 0x64, 0x65, };
+static int x1500_uart2_data_a_pins[] = { 0x02, 0x03, };
+static int x1500_uart2_data_d_pins[] = { 0x65, 0x64, };
+static int x1500_mmc0_1bit_pins[] = { 0x18, 0x19, 0x17, };
+static int x1500_mmc0_4bit_pins[] = { 0x16, 0x15, 0x14, };
+static int x1500_i2c0_pins[] = { 0x38, 0x37, };
+static int x1500_i2c1_a_pins[] = { 0x01, 0x00, };
+static int x1500_i2c1_c_pins[] = { 0x5b, 0x5a, };
+static int x1500_i2c2_pins[] = { 0x61, 0x60, };
+static int x1500_cim_pins[] = {
+ 0x08, 0x09, 0x0a, 0x0b,
+ 0x13, 0x12, 0x11, 0x10, 0x0f, 0x0e, 0x0d, 0x0c,
+};
+static int x1500_pwm_pwm0_pins[] = { 0x59, };
+static int x1500_pwm_pwm1_pins[] = { 0x5a, };
+static int x1500_pwm_pwm2_pins[] = { 0x5b, };
+static int x1500_pwm_pwm3_pins[] = { 0x26, };
+static int x1500_pwm_pwm4_pins[] = { 0x58, };
+
+static int x1500_uart0_data_funcs[] = { 0, 0, };
+static int x1500_uart0_hwflow_funcs[] = { 0, 0, };
+static int x1500_uart1_data_a_funcs[] = { 2, 2, };
+static int x1500_uart1_data_d_funcs[] = { 1, 1, };
+static int x1500_uart1_hwflow_d_funcs[] = { 1, 1, };
+static int x1500_uart2_data_a_funcs[] = { 2, 2, };
+static int x1500_uart2_data_d_funcs[] = { 0, 0, };
+static int x1500_mmc0_1bit_funcs[] = { 1, 1, 1, };
+static int x1500_mmc0_4bit_funcs[] = { 1, 1, 1, };
+static int x1500_i2c0_funcs[] = { 0, 0, };
+static int x1500_i2c1_a_funcs[] = { 2, 2, };
+static int x1500_i2c1_c_funcs[] = { 0, 0, };
+static int x1500_i2c2_funcs[] = { 1, 1, };
+static int x1500_cim_funcs[] = { 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, };
+static int x1500_pwm_pwm0_funcs[] = { 0, };
+static int x1500_pwm_pwm1_funcs[] = { 1, };
+static int x1500_pwm_pwm2_funcs[] = { 1, };
+static int x1500_pwm_pwm3_funcs[] = { 2, };
+static int x1500_pwm_pwm4_funcs[] = { 0, };
+
+static const struct group_desc x1500_groups[] = {
+ INGENIC_PIN_GROUP("uart0-data", x1500_uart0_data),
+ INGENIC_PIN_GROUP("uart0-hwflow", x1500_uart0_hwflow),
+ INGENIC_PIN_GROUP("uart1-data-a", x1500_uart1_data_a),
+ INGENIC_PIN_GROUP("uart1-data-d", x1500_uart1_data_d),
+ INGENIC_PIN_GROUP("uart1-hwflow-d", x1500_uart1_hwflow_d),
+ INGENIC_PIN_GROUP("uart2-data-a", x1500_uart2_data_a),
+ INGENIC_PIN_GROUP("uart2-data-d", x1500_uart2_data_d),
+ INGENIC_PIN_GROUP("mmc0-1bit", x1500_mmc0_1bit),
+ INGENIC_PIN_GROUP("mmc0-4bit", x1500_mmc0_4bit),
+ INGENIC_PIN_GROUP("i2c0-data", x1500_i2c0),
+ INGENIC_PIN_GROUP("i2c1-data-a", x1500_i2c1_a),
+ INGENIC_PIN_GROUP("i2c1-data-c", x1500_i2c1_c),
+ INGENIC_PIN_GROUP("i2c2-data", x1500_i2c2),
+ INGENIC_PIN_GROUP("cim-data", x1500_cim),
+ { "lcd-no-pins", },
+ INGENIC_PIN_GROUP("pwm0", x1500_pwm_pwm0),
+ INGENIC_PIN_GROUP("pwm1", x1500_pwm_pwm1),
+ INGENIC_PIN_GROUP("pwm2", x1500_pwm_pwm2),
+ INGENIC_PIN_GROUP("pwm3", x1500_pwm_pwm3),
+ INGENIC_PIN_GROUP("pwm4", x1500_pwm_pwm4),
+};
+
+static const char *x1500_uart0_groups[] = { "uart0-data", "uart0-hwflow", };
+static const char *x1500_uart1_groups[] = {
+ "uart1-data-a", "uart1-data-d", "uart1-hwflow-d",
+};
+static const char *x1500_uart2_groups[] = { "uart2-data-a", "uart2-data-d", };
+static const char *x1500_mmc0_groups[] = { "mmc0-1bit", "mmc0-4bit", };
+static const char *x1500_i2c0_groups[] = { "i2c0-data", };
+static const char *x1500_i2c1_groups[] = { "i2c1-data-a", "i2c1-data-c", };
+static const char *x1500_i2c2_groups[] = { "i2c2-data", };
+static const char *x1500_cim_groups[] = { "cim-data", };
+static const char *x1500_lcd_groups[] = { "lcd-no-pins", };
+static const char *x1500_pwm0_groups[] = { "pwm0", };
+static const char *x1500_pwm1_groups[] = { "pwm1", };
+static const char *x1500_pwm2_groups[] = { "pwm2", };
+static const char *x1500_pwm3_groups[] = { "pwm3", };
+static const char *x1500_pwm4_groups[] = { "pwm4", };
+
+static const struct function_desc x1500_functions[] = {
+ { "uart0", x1500_uart0_groups, ARRAY_SIZE(x1500_uart0_groups), },
+ { "uart1", x1500_uart1_groups, ARRAY_SIZE(x1500_uart1_groups), },
+ { "uart2", x1500_uart2_groups, ARRAY_SIZE(x1500_uart2_groups), },
+ { "mmc0", x1500_mmc0_groups, ARRAY_SIZE(x1500_mmc0_groups), },
+ { "i2c0", x1500_i2c0_groups, ARRAY_SIZE(x1500_i2c0_groups), },
+ { "i2c1", x1500_i2c1_groups, ARRAY_SIZE(x1500_i2c1_groups), },
+ { "i2c2", x1500_i2c2_groups, ARRAY_SIZE(x1500_i2c2_groups), },
+ { "cim", x1500_cim_groups, ARRAY_SIZE(x1500_cim_groups), },
+ { "lcd", x1500_lcd_groups, ARRAY_SIZE(x1500_lcd_groups), },
+ { "pwm0", x1500_pwm0_groups, ARRAY_SIZE(x1500_pwm0_groups), },
+ { "pwm1", x1500_pwm1_groups, ARRAY_SIZE(x1500_pwm1_groups), },
+ { "pwm2", x1500_pwm2_groups, ARRAY_SIZE(x1500_pwm2_groups), },
+ { "pwm3", x1500_pwm3_groups, ARRAY_SIZE(x1500_pwm3_groups), },
+ { "pwm4", x1500_pwm4_groups, ARRAY_SIZE(x1500_pwm4_groups), },
+};
+
+static const struct ingenic_chip_info x1500_chip_info = {
+ .num_chips = 4,
+ .groups = x1500_groups,
+ .num_groups = ARRAY_SIZE(x1500_groups),
+ .functions = x1500_functions,
+ .num_functions = ARRAY_SIZE(x1500_functions),
+ .pull_ups = x1000_pull_ups,
+ .pull_downs = x1000_pull_downs,
+};
+
static u32 ingenic_gpio_read_reg(struct ingenic_gpio_chip *jzgc, u8 reg)
{
unsigned int val;
@@ -1810,6 +1922,7 @@ static const struct of_device_id ingenic_pinctrl_of_match[] = {
{ .compatible = "ingenic,jz4780-pinctrl", .data = (void *) ID_JZ4780 },
{ .compatible = "ingenic,x1000-pinctrl", .data = (void *) ID_X1000 },
{ .compatible = "ingenic,x1000e-pinctrl", .data = (void *) ID_X1000E },
+ { .compatible = "ingenic,x1500-pinctrl", .data = (void *) ID_X1500 },
{},
};
@@ -1934,7 +2047,9 @@ static int __init ingenic_pinctrl_probe(struct platform_device *pdev)
else
jzpc->version = (enum jz_version)id->driver_data;
- if (jzpc->version >= ID_X1000E)
+ if (jzpc->version >= ID_X1500)
+ chip_info = &x1500_chip_info;
+ else if (jzpc->version >= ID_X1000E)
chip_info = &x1000e_chip_info;
else if (jzpc->version >= ID_X1000)
chip_info = &x1000_chip_info;
@@ -2028,6 +2143,7 @@ static const struct platform_device_id ingenic_pinctrl_ids[] = {
{ "jz4780-pinctrl", ID_JZ4780 },
{ "x1000-pinctrl", ID_X1000 },
{ "x1000e-pinctrl", ID_X1000E },
+ { "x1500-pinctrl", ID_X1500 },
{},
};
--
2.7.4
^ permalink raw reply related
* [PATCH 5/6] dt-bindings: pinctrl: Add X1500 bindings.
From: Zhou Yanjie @ 2019-07-14 3:53 UTC (permalink / raw)
To: linux-mips
Cc: linux-kernel, linux-gpio, devicetree, paul.burton, linus.walleij,
robh+dt, mark.rutland
In-Reply-To: <1563076436-5338-1-git-send-email-zhouyanjie@zoho.com>
Add the pinctrl bindings for the X1500 Soc from Ingenic.
Signed-off-by: Zhou Yanjie <zhouyanjie@zoho.com>
---
Documentation/devicetree/bindings/pinctrl/ingenic,pinctrl.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/pinctrl/ingenic,pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/ingenic,pinctrl.txt
index 7e2ee46..0014d98 100644
--- a/Documentation/devicetree/bindings/pinctrl/ingenic,pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/ingenic,pinctrl.txt
@@ -27,6 +27,7 @@ Required properties:
- "ingenic,jz4780-pinctrl"
- "ingenic,x1000-pinctrl"
- "ingenic,x1000e-pinctrl"
+ - "ingenic,x1500-pinctrl"
- reg: Address range of the pinctrl registers.
--
2.7.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox