RE: [PATCH v5 2/2] clk: x86: Add Atom PMC platform clocks
On 2016-12-09 02:25, Stephen Boyd wrote: > On 12/07, Irina Tirdea wrote: >> The BayTrail and CherryTrail platforms provide platform clocks >> through their Power Management Controller (PMC). >> >> The SoC supports up to 6 clocks (PMC_PLT_CLK[5:0]) with a >> frequency of either 19.2 MHz (PLL) or 25 MHz (XTAL) for BayTrail >> an a frequency of 19.2 MHz (XTAL) for CherryTrail. These clocks >> are available for general system use, where appropriate, and each >> have Control & Frequency register fields associated with them. >> >> For example, the usage for platform clocks suggested in the datasheet >> is the following: >> PLT_CLK[2:0] - Camera >> PLT_CLK[3] - Audio Codec >> PLT_CLK[4] - >> PLT_CLK[5] - COMMs >> Signed-off-by: Irina Tirdea Signed-off-by: >> Pierre-Louis Bossart --- >> drivers/clk/x86/Makefile | 1 + >> drivers/clk/x86/clk-byt-plt.c | 380 > ++ > > Is it possible to split the clk part from the platform part? I'd > like to merge just the clk part if possible into the clk tree. > It would be great to have the clk part merged. I'll put the code in a separate patch. Thanks, Irina
RE: [RESEND PATCH v4] clk: x86: Add Atom PMC platform clocks
Darren Hart wrote: > On Wed, Oct 26, 2016 at 11:43:24PM +0200, Thomas Gleixner wrote: > > On Wed, 26 Oct 2016, Darren Hart wrote: > > > On Mon, Oct 24, 2016 at 01:38:54PM +0000, Tirdea, Irina wrote: > > > > intel_pmc_* drivers or is it enough to move it as a standalone > > > > driver for now? > > > > > > If the functionality is substantially different, then I don't see a > > > compelling, and certainly not an immediate, need to merge them. > > > Assume for now they are to remain as separate drivers. I suggest > > > keeping the existing name for now as well. Let's just complete the > > > move with as little user-visible changes as possible. > > > > > > The placement of the header file is a bit tricky as it is being used > > > in drivers/clk/x86 in addition to the pmc_atom driver in > > > drivers/platform/x86. > > > > > > The best existing location would appear to be include/platform_data/ > > > > > > Thomas, is that acceptable to you? > > > > Yes > > > > > arch/x86/platform/atom/pmc_atom.c -> drivers/platform/x86 > > > arch/x86/include/asm/pmc_atom.h -> include/platform_data/ > > > > > > If there are enough of these, it might make sense to create: > > > > > > include/platform/x86/ > > > > > > but I suggest we start with minimal change. > > > > No. Make that x86 directory right away. include/platform_data is > > already a maze of 224 files. Start structuring it now. > > OK, that's fine with me too. > > (but I typo'd, should have been: include/linux/platform_data/x86) > > Irina, does this give you enough to go on? > Yes, everything is clear now. I will make the change and send a patch in a few days. Thanks, Irina
RE: [RESEND PATCH v4] clk: x86: Add Atom PMC platform clocks
> -Original Message- > From: Darren Hart [mailto:dvh...@infradead.org] > Sent: 21 October, 2016 8:00 > To: Thomas Gleixner > Cc: Tirdea, Irina; linux-...@vger.kernel.org; x...@kernel.org; Stephen Boyd; > Ingo Molnar; Michael Turquette; H. Peter Anvin; alsa- > de...@alsa-project.org; Mark Brown; Takashi Iwai; Bossart, Pierre-louis; > LKML; Pierre-Louis Bossart > Subject: Re: [RESEND PATCH v4] clk: x86: Add Atom PMC platform clocks > > On Thu, Oct 20, 2016 at 11:52:38PM +0200, Thomas Gleixner wrote: > > On Mon, 17 Oct 2016, Irina Tirdea wrote: > > > The patch has already been reviewed by Stephen Boyd [1]. > > > The only remaining question is the one pointed out by Stephen: > > > "Will there be problems if this merges through clk tree? If so we > > > could take the clk driver part and the platform data include part > > > could be duplicated into both trees. Or clk tree could be pulled > > > into x86?" [1] > > > > The proper thing to do is: > > > > Move all that cruft including arch/x86/platform/atom/pmc_atom.c into > > drivers/platform/x86. There is nothing architecture specific in these > > files. It's pure peripheral driver enablement. So drivers/platform/x86 is > > the proper location for this. Please discuss this with Darren Hart (cc'ed). > Thanks for pointing me in the right direction, Thomas! > We've been adding more of the pmc and punit drivers to drivers/platform/x86. > This makes more sense than being under "arch". Thomas and I have discussed > moving more of the non architectural stuff in arch/x86/platform to my tree > under > platform/drivers/x86. > Thanks for the reply, Darren. I could move the arch/x86/platform/atom/pmc_atom.c into drivers/platform/x86, but I'm not sure what the process is in this case. I took a look at your tree and noticed some intel_pmc_* drivers, but they are quite different from pmc_atom.c in terms of HW registers and capabilities. Should the code from pmc_atom.c be integrated in the intel_pmc_* drivers or is it enough to move it as a standalone driver for now? > Irina, please point me at the relevant context if it's more than just this > particular patch. This patch comes from a set of patches that enable sound for Baytrail CR devices (especially Asus T100TAF) [1]. The rest of the patches have been already merged in Mark's sound tree. This is the only change remaining for enabling sound on these platforms, so there are no additional changes to the x86 platform code. Thanks, Irina [1] http://mailman.alsa-project.org/pipermail/alsa-devel/2016-August/111704.html
RE: [PATCH v2 1/5] iio: accel: bmc150: use regmap to retrieve struct device
> -Original Message- > From: Jonathan Cameron [mailto:ji...@kernel.org] > Sent: 16 April, 2016 22:20 > To: Alison Schofield > Cc: knaac...@gmx.de; l...@metafoo.de; pme...@pmeerw.net; kg...@kernel.org; > k.kozlow...@samsung.com; linux- > i...@vger.kernel.org; linux-kernel@vger.kernel.org; > linux-arm-ker...@lists.infradead.org; linux-samsung-...@vger.kernel.org; > Srinivas Pandruvada; Tirdea, Irina > Subject: Re: [PATCH v2 1/5] iio: accel: bmc150: use regmap to retrieve struct > device > > On 10/04/16 20:05, Alison Schofield wrote: > > Driver includes struct regmap and struct device in its global data. > > Remove the struct device and use regmap API to retrieve device info. > > > > Patch created using Coccinelle plus manual edits. > > > > Signed-off-by: Alison Schofield > I'm happy with this but please do make sure to cc the maintainer / author > of drivers if possible (often the email addresses are out of date!) > > Srinivas, this is one of yours. Are you happy with this? > I've also cc'd Irina who has worked on this driver recently for any > comments. > Looks good to me. Reviewed-by: Irina Tirdea Alison, I think bmc150_magn driver qualifies for this change as well after Daniel's patches got merged [1]. Thanks, Irina [1] https://lkml.org/lkml/2016/4/15/407 > If no one comments in the meantime I'll probably pick these up sometime > in the next week. > > Jonathan
RE: [PATCH 1/2] iio: magn: Split bmc150 driver in common/i2c parts
> -Original Message- > From: Jonathan Cameron [mailto:ji...@kernel.org] > Sent: 17 April, 2016 13:02 > To: Baluta, Daniel; Tirdea, Irina > Cc: knaac...@gmx.de; l...@metafoo.de; pme...@pmeerw.net; > ge...@linux-m68k.org; Dogaru, Vlad; Purdila, Octavian; linux- > ker...@vger.kernel.org; linux-...@vger.kernel.org > Subject: Re: [PATCH 1/2] iio: magn: Split bmc150 driver in common/i2c parts > > On 15/04/16 15:13, Daniel Baluta wrote: > > This is useful for easily adding SPI support in later patches. > > > > Now bmc150_magn exports core functions to be used by I2C/SPI drivers > > instances. For the moment only I2C driver is supported. > > > > Signed-off-by: Daniel Baluta > > This looks good to me - all mechanistic stuff so I doubt anything nasty > has snuck in. Ideally I'd like an Ack from Irina on this but it'll probably > be in my testing tree for a few days so I can add one if it comes in. > Looks good to me. Acked-by: Irina Tirdea > Applied to the togreg branch of iio.git - pushed out as testing for the > autobuilders to mess with it. > > Thanks, > > Jonathan
RE: [RFC PATCH 0/4] Add ACPI support for pinctrl configuration
> -Original Message- > From: Mark Rutland [mailto:mark.rutl...@arm.com] > Sent: 05 April, 2016 1:52 > To: Tirdea, Irina > Cc: Rafael J. Wysocki; Len Brown; Mika Westerberg; Linus Walleij; > linux-g...@vger.kernel.org; linux-a...@vger.kernel.org; Rob > Herring; Heikki Krogerus; Andy Shevchenko; Purdila, Octavian; Ciocan, > Cristina; devicet...@vger.kernel.org; linux- > ker...@vger.kernel.org; charles.garcia-to...@arm.com > Subject: Re: [RFC PATCH 0/4] Add ACPI support for pinctrl configuration > > Hi, Hi Mark, > > On Thu, Mar 31, 2016 at 02:44:41PM +0300, Irina Tirdea wrote: > > This is a proposal for adding ACPI support for pin controller > > configuration. > > > > It has been developed to enable the MinnowBoard and IoT community > > by providing an easy way to specify pin multiplexing and > > pin configuration. > > > > This proposal is based on using _DSD properties to specify device > > states and configuration nodes and it follows closely the device > > tree model. Device states are defined using the Device Properties > > format and the configuration nodes are defined using the > > Hierarchical Properties Extension format. The generic properties > > for the configuration nodes are the same as the ones for device > > tree, while pincontroller drivers can also define custom ones. > > From a look of the Documentation addition, and of the current uses of > pinctrl-names in device tree bindings, one reason for requiring multiple > pinctrl states is power management. Given that, I'm somewhat concerned by > this, > as it goes against the usual ACPI model of abstracting this sort of thing > behind power control methods. > Right, there is an overlap of the pinctrl "sleep" state with the ACPI power management model. However, the main reason for implementing this is setting initial pin multiplexing and configuration. This is normally done by BIOS, but there is currently no way of changing the default configuration (except for a BIOS update). This is a problem when using boards like MinnowBoard, where it is expected to get the board and to be able to add various devices to its exported GPIO pins. We need a way to change default pin multiplexing to enable the functionality required by a specific device. In some cases we also need to set the bias to get things like interrupts working. Another use case for pinctrl states is using custom reset pin configurations that need to be controlled from the driver. Since we have the pinctrl infrastructure and the all Intel ACPI pinctrl drivers already support it, this seems the most straightforward way to implement it. > To the best of my knowledge, that goes against the ASWG's expectations on how > _DSD will be used (per [1]). Charles, please correct me if that document is no > longer representative. > > Additionally, pinctrl has some cross-cutting concerns (e.g. mutually exclusive > device usage due to a shared pin), and I can imagine that may interact poorly > with any AML or firmware assumptions about the state of the world, as there's > no mechanism present to notify those of changes to pins. > This is a problem with any modification we would make to the ACPI tables. It is true that pinctrl configuration could create conflicts when changing pin multiplexing, but that could be avoided by using only the pinctrl states that make sense for the entire ACPI configuration. > I think that this is a class of problem which needs to be raised with the > ASWG, > and solved in an ACPI-native fashion, rather than simply copying properties > from DT using _DSD. If nothing else, the restrictions on FW and AML would need > to be specified. I agree this should be at least mentioned in the Documentation. I'll update it accordingly. Thanks, Irina > > Thanks, > Mark. > > [1] https://lists.acpica.org/pipermail/dsd/2015-September/19.html
RE: [RFC PATCH 4/4] pinctrl: Parse GpioInt/GpioIo resources
> -Original Message-
> From: Mika Westerberg [mailto:mika.westerb...@linux.intel.com]
> Sent: 04 April, 2016 16:48
> To: Tirdea, Irina
> Cc: Rafael J. Wysocki; Len Brown; Linus Walleij; linux-g...@vger.kernel.org;
> linux-a...@vger.kernel.org; Rob Herring; Heikki Krogerus;
> Andy Shevchenko; Purdila, Octavian; Ciocan, Cristina;
> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [RFC PATCH 4/4] pinctrl: Parse GpioInt/GpioIo resources
>
> On Thu, Mar 31, 2016 at 02:44:45PM +0300, Irina Tirdea wrote:
> > +static int acpi_parse_gpio_res(struct pinctrl *p,
> > + struct pinctrl_map **map,
> > + unsigned *num_maps,
> > + struct pinctrl_dev ***pctldevs)
> > +{
> > + struct acpi_gpio_lookup lookup;
> > + struct list_head res_list;
> > + struct acpi_device *adev;
> > + unsigned int index;
> > + int ret;
> > +
> > + adev = ACPI_COMPANION(p->dev);
> > +
> > + *map = NULL;
> > + *num_maps = 0;
> > + memset(&lookup, 0, sizeof(lookup));
> > +
> > + /* Parse all GpioInt/GpioIo resources in _CRS and extract pin conf */
> > + for (index = 0; ; index++) {
> > + lookup.index = index;
> > + lookup.n = 0;
> > + lookup.found = false;
> > +
> > + INIT_LIST_HEAD(&res_list);
> > + ret = acpi_dev_get_resources(adev, &res_list, acpi_gpio_to_map,
> > +&lookup);
> > + if (ret < 0)
> > + goto exit_free;
> > + acpi_dev_free_resource_list(&res_list);
> > + if (!lookup.found)
> > + break;
> > + }
> > +
> > + *map = lookup.map;
> > + *num_maps = lookup.num_maps;
> > + *pctldevs = lookup.pctldevs;
>
> This function has quite many stars in arguments and in the function
> body. In particular pctldevs has three stars!
>
> I wonder if this could be written in such way that avoids that. Like
> create a structure holding the map information and pass that to the
> function instead.
>
Yes, that would make the code more clear. I will rewrite it using a structure.
> Other parts of the patch look good to me.
RE: [RFC PATCH 3/4] pinctrl: Add ACPI support
> -Original Message- > From: Mika Westerberg [mailto:mika.westerb...@linux.intel.com] > Sent: 04 April, 2016 16:37 > To: Tirdea, Irina > Cc: Rafael J. Wysocki; Len Brown; Linus Walleij; linux-g...@vger.kernel.org; > linux-a...@vger.kernel.org; Rob Herring; Heikki Krogerus; > Andy Shevchenko; Purdila, Octavian; Ciocan, Cristina; > devicet...@vger.kernel.org; linux-kernel@vger.kernel.org > Subject: Re: [RFC PATCH 3/4] pinctrl: Add ACPI support > > On Thu, Mar 31, 2016 at 02:44:44PM +0300, Irina Tirdea wrote: > > Add ACPI support for pin controller properties. These are > > based on ACPI _DSD properties and follow the device tree > > model based on states and node configurations. The states > > are defined as _DSD properties and configuration nodes > > are defined using the _DSD Hierarchical Properties Extension. > > > > A configuration node supports the generic device tree properties. > > > > The implementation is based on device tree code from devicetree.c. > > > > Signed-off-by: Irina Tirdea > > Looks good to me. Few minor comments below, though. Thanks for the review, Mika! > > > --- > > Documentation/acpi/pinctrl-properties.txt | 274 + > > drivers/pinctrl/Makefile | 1 + > > drivers/pinctrl/acpi.c| 322 > > ++ > > drivers/pinctrl/acpi.h| 32 +++ > > drivers/pinctrl/core.c| 26 +++ > > drivers/pinctrl/core.h| 2 + > > 6 files changed, 657 insertions(+) > > create mode 100644 Documentation/acpi/pinctrl-properties.txt > > create mode 100644 drivers/pinctrl/acpi.c > > create mode 100644 drivers/pinctrl/acpi.h > > > > diff --git a/Documentation/acpi/pinctrl-properties.txt > > b/Documentation/acpi/pinctrl-properties.txt > > new file mode 100644 > > index 000..e93aaaf > > --- /dev/null > > +++ b/Documentation/acpi/pinctrl-properties.txt > > @@ -0,0 +1,274 @@ > > += _DSD Device Properties related to pin controllers = > > + > > +== Introduction == > > + > > +This document is an extension of the pin control subsystem in Linux [1] > > +and provides a way to describe pin controller properties in ACPI. It is > > +based on the Device Specific Data (_DSD) configuration object [2] that > > +was introduced in ACPI 5.1. > > + > > +Pin controllers are hardware modules that control pins by allowing pin > > +multiplexing and configuration. Pin multiplexing allows using the same > > +physical pins for multiple functions; for example, one pin or group of pins > > +may be used for the I2C bus, SPI bus or as general-purpose GPIO pin. Pin > > +configuration allows setting various properties such as pull-up/down, > > +tri-state, drive-strength, etc. > > + > > +Hardware modules whose signals are affected by pin configuration are > > +designated client devices. For a client device to operate correctly, > > +certain pin controllers must set up certain specific pin configurations. > > +Some client devices need a single static pin configuration, e.g. set up > > +during initialization. Others need to reconfigure pins at run-time, > > +for example to tri-state pins when the device is inactive. Hence, each > > +client device can define a set of named states. Each named state is > > +mapped to a pin controller configuration that describes the pin > > multiplexing > > +or configuration for that state. > > + > > +In ACPI, each pin controller and each client device is represented as an > > +ACPI device, just like any other hardware module. The pin controller > > +properties are defined using _DSD properties [2] under these devices. > > +The named states are defined using Device Properties UUID [3] under the > > +ACPI client device. The configuration nodes are defined using Hierarchical > > +Properties Extension UUID [4] and are split between the ACPI client device > > +and the pin controller device. The configuration nodes contain properties > > +that describe pin multiplexing or configuration that very similar to the > > +ones used for device tree [5]. > > + > > +== Example == > > + > > +For example, let's consider an accelerometer connected to the I2C bus on > > +a platform with a Baytrail pin controller. The accelerometer uses 2 GPIO > > +pins for I2C (SDA, SCL) and one GPIO pin for interrupt. > > + > > +The name for the pins, groups and functions used are the ones defined in > > the > > +pin controller driver, in the same way as it is done for device t
RE: [RFC PATCH 3/4] pinctrl: Add ACPI support
> -Original Message-
> From: Andy Shevchenko [mailto:andriy.shevche...@linux.intel.com]
> Sent: 01 April, 2016 17:15
> To: Tirdea, Irina; Rafael J. Wysocki; Len Brown; Mika Westerberg; Linus
> Walleij; linux-g...@vger.kernel.org; linux-
> a...@vger.kernel.org
> Cc: Rob Herring; Heikki Krogerus; Purdila, Octavian; Ciocan, Cristina;
> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [RFC PATCH 3/4] pinctrl: Add ACPI support
>
> On Thu, 2016-03-31 at 14:44 +0300, Irina Tirdea wrote:
> > Add ACPI support for pin controller properties. These are
> > based on ACPI _DSD properties and follow the device tree
> > model based on states and node configurations. The states
> > are defined as _DSD properties and configuration nodes
> > are defined using the _DSD Hierarchical Properties Extension.
> >
> > A configuration node supports the generic device tree properties.
> >
> > The implementation is based on device tree code from devicetree.c.
> >
>
> Patch is good to me, though few minor comments below.
>
> > +/**
> > + * struct pinctrl_acpi_map - mapping table chunk parsed from ACPI
> > + * @node: list node for struct pinctrl's @fw_maps field
> > + * @pctldev: the pin controller that allocated this struct, and will
> > free it
>
> > + * @maps: the mapping table entries
>
> We have @map and @num_maps.
Right, I'll add num_maps description.
>
> > + */
> > +struct pinctrl_acpi_map {
> > + struct list_head node;
> > + struct pinctrl_dev *pctldev;
> > + struct pinctrl_map *map;
> > + unsigned num_maps;
> > +};
> > +
> >
>
> > +static int acpi_remember_or_free_map(struct pinctrl *p, const char
> > *statename,
> > + struct pinctrl_dev *pctldev,
> > + struct pinctrl_map *map,
> > unsigned num_maps)
> > +{
> > + struct pinctrl_acpi_map *acpi_map;
> > + struct list_head *acpi_maps;
>
>
> > + unsigned int i;
>
> Just unsigned i to be in align with unsigned num_maps.
>
OK.
> > +
> > + /* Initialize common mapping table entry fields */
> > + for (i = 0; i < num_maps; i++) {
> > + map[i].dev_name = dev_name(p->dev);
> > + map[i].name = statename;
> > + if (pctldev)
> > + map[i].ctrl_dev_name = dev_name(pctldev-
> > >dev);
> > + }
>
>
> > +int pinctrl_acpi_to_map(struct pinctrl *p)
> > +{
> > + const union acpi_object *prop, *statenames, *configs;
> > + unsigned int state, nstates, nconfigs, config;
> > + char *statename, *propname, *configname;
> > + struct fwnode_handle *fw_prop;
> > + struct acpi_device *adev;
> > + int ret;
> > +
> > + /* We may store pointers to property names within the node
> > */
> > + adev = acpi_bus_get_acpi_device(ACPI_HANDLE(p->dev));
> > + if (!adev)
> > + return -ENODEV;
> > +
>
> > + /* Only allow named states (device must have prop 'pinctrl-
> > names') */
>
> Does it fit one line?
>
It has 77 characters, so it should fit one line.
> > +err_free_map:
>
> Perhaps err_free_maps?
>
OK.
> > + pinctrl_acpi_free_maps(p);
> > + return ret;
>
> --
> Andy Shevchenko
> Intel Finland Oy
RE: [RFC PATCH 2/4] pinctrl: pinconf-generic: Add ACPI support
> -Original Message-
> From: Andy Shevchenko [mailto:andriy.shevche...@linux.intel.com]
> Sent: 01 April, 2016 17:05
> To: Tirdea, Irina; Rafael J. Wysocki; Len Brown; Mika Westerberg; Linus
> Walleij; linux-g...@vger.kernel.org; linux-
> a...@vger.kernel.org
> Cc: Rob Herring; Heikki Krogerus; Purdila, Octavian; Ciocan, Cristina;
> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [RFC PATCH 2/4] pinctrl: pinconf-generic: Add ACPI support
>
> On Thu, 2016-03-31 at 14:44 +0300, Irina Tirdea wrote:
> > Add ACPI support for the generic device tree properties.
> > Convert the pinconf generic code to handle both ACPI and
> > device tree by using the fwnode_property API. Also include
> > renaming device tree references in names of functions and
> > structures from 'dt' to 'fwnode'.
>
> This is looks good to me, though few style / minor comments below.
Thanks for the review, Andy!
>
> > --- a/drivers/pinctrl/pinconf-generic.c
> > +++ b/drivers/pinctrl/pinconf-generic.c
> >
>
> > @@ -175,22 +176,22 @@ static const struct pinconf_generic_params
> > dt_params[] = {
> > };
> >
> > /**
> > - * parse_dt_cfg() - Parse DT pinconf parameters
> > - * @np:DT node
> > + * parse_fwnode_cfg() - Parse FW pinconf parameters
> > + * @fw:FW node
>
> Here and below it should be @fwnode.
OK.
>
> > -int pinconf_generic_dt_subnode_to_map(struct pinctrl_dev *pctldev,
> > - struct device_node *np, struct pinctrl_map **map,
> > +static int pinconf_generic_fwnode_subnode_to_map(struct pinctrl_dev
> > *pctldev,
> > + struct fwnode_handle *fwnode, struct pinctrl_map
> > **map,
> > unsigned *reserved_maps, unsigned *num_maps,
> > enum pinctrl_map_type type)
> > {
> > - int ret;
> > + int ret, i;
>
> Since you change this line anyway, perhaps move it to be last in the
> definition block?
>
> > const char *function;
> > struct device *dev = pctldev->dev;
> > unsigned long *configs = NULL;
> > unsigned num_configs = 0;
> > unsigned reserve, strings_count;
> > - struct property *prop;
> > - const char *group;
> > + const char **groups;
> > const char *subnode_target_type = "pins";
>
> ...to here.
>
Sure.
> > +#ifdef CONFIG_OF
> > +inline int pinconf_generic_parse_dt_config(struct device_node *np,
> > + struct pinctrl_dev
> > *pctldev,
> > + unsigned long **configs,
> > + unsigned int *nconfigs)
> > +{
> > + return pinconf_generic_parse_fwnode_config(&np->fwnode,
> > pctldev,
> > + configs,
> > nconfigs);
> > +}
>
> I didn't see any user of this.
pinconf_generic_parse_dt_config is defined in drivers/pinctrl/pinconf.h
and is used by various pinctrl drivers(e.g.:
drivers/pinctrl/nomadik/pinctrl-abx500.c,
drivers/pinctrl/pinctrl-tz1090-pdc.c, drivers/pinctrl/pinctrl-tz1090.c). Taking
a closer
look at its prototype, I should match it here exactly (by removing inline).
RE: [PATCH 1/1] iio: accel: bmc150: fix endianness when reading axes
> -Original Message-
> From: linux-iio-ow...@vger.kernel.org
> [mailto:linux-iio-ow...@vger.kernel.org] On Behalf Of Peter Meerwald-Stadler
> Sent: 28 March, 2016 20:43
> To: Tirdea, Irina
> Cc: Jonathan Cameron; linux-...@vger.kernel.org;
> linux-kernel@vger.kernel.org; Hartmut Knaack; Lars-Peter Clausen; Markus
> Pargmann
> Subject: Re: [PATCH 1/1] iio: accel: bmc150: fix endianness when reading axes
>
> On Mon, 28 Mar 2016, Irina Tirdea wrote:
>
> > For big endian platforms, reading the axes will return
> > invalid values.
> >
> > The device stores each axis value in a 16 bit little
> > endian register. The driver uses regmap_read_bulk to get
> > the axis value, resulting in a 16 bit little endian value.
> > This needs to be converted to cpu endianness to work
> > on big endian platforms.
> >
> > Fix endianness for big endian platforms by converting
> > the values for the axes read from little endian to
> > cpu.
> >
> > This is also partially fixed in commit b6fb9b6d6552 ("iio:
> > accel: bmc150: optimize transfers in trigger handler").
>
> looks good
>
> in bmc150_accel_get_axis() the call to regmap_bulk_read() could now pass
> sizeof(raw_val) instead of 2
>
Yes, that would look better. I'll send a new version with this change.
Thanks,
Irina
RE: [PATCH 1/1] iio: accel: bmc150: remove unused definition
> -Original Message- > From: Jonathan Cameron [mailto:ji...@kernel.org] > Sent: 28 March, 2016 13:09 > To: Tirdea, Irina; linux-...@vger.kernel.org > Cc: linux-kernel@vger.kernel.org; Hartmut Knaack; Lars-Peter Clausen; Peter > Meerwald; Markus Pargmann > Subject: Re: [PATCH 1/1] iio: accel: bmc150: remove unused definition > > On 24/03/16 09:00, Irina Tirdea wrote: > > bmc150_i2c_regmap_conf is defined in bmc150-accel-core.c, but > > never used here. The definition is needed in bmc150-accel-i2c.c, > > where it is again defined. > > > > Remove the unnecessary definition of bmc150_i2c_regmap_conf from > > bmc150-accel-core.c and update the one from bmc150-accel-i2c.c > > to contain all fields. > > > > Signed-off-by: Irina Tirdea > Silly question. Why isn't it shared between the i2c and spi drivers? > Looks to be the same in both cases (as we'd expect from regmap most > of the time!). I think it would be better to share it. > Good point. I'll keep the definition in the core file and share the regmap with the rest. Thanks, Irina
RE: [PATCH 4/6] iio: accel: bmg160: optimize transfers in trigger handler
> -Original Message- > From: Peter Meerwald-Stadler [mailto:pme...@pmeerw.net] > Sent: 28 March, 2016 13:09 > To: Jonathan Cameron > Cc: Tirdea, Irina; linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; > Hartmut Knaack; Lars-Peter Clausen; Purdila, Octavian; > Markus Pargmann; Pandruvada, Srinivas > Subject: Re: [PATCH 4/6] iio: accel: bmg160: optimize transfers in trigger > handler > > Thanks for the review, Peter! > > > Some i2c busses (e.g.: Synopsys DesignWare I2C adapter) need to > > > enable/disable the bus at each i2c transfer and must wait for > > > the enable/disable to happen before sending the data. > > > > > > When reading data in the trigger handler, the bmc150 accel driver does > > should refer to bmg160 > > > > one bus transfer for each axis. This has an impact on the frequency > > > of the accelerometer at high sample rates due to additional delays > > > introduced by the bus at each transfer. > > > > > > Reading all axis values in one bus transfer reduces the delays > > > introduced by the bus. > > > > > > Signed-off-by: Irina Tirdea > > I forgot to highlight on the earlier driver that there is also 'technically' > > a bit of an ABI change here because we are now exporting as LE rather than > > CPU > > order. However, I 'hope' anyone actually accessing the buffered data is > > either > > doing it through a nice library or hasn't hacked the endian unwinding out of > > the generic_buffer example! > > the patch takes away the possibility to do buffered reads on individual > channels (not sure if this is useful per se) We can still read individual channels, but the demux is now handled by the iio core (through available_scan_masks, added in the previous patch). As Jonathan mentioned in a previous patch, this will impact performance for reading only a subset of the available channels (since we will read all 3 axes regardless of how many axes the user actually requested and will receive). > > this optimizes for the common case, ok; > > wondering if adding > .endianness = IIO_LE > is actually an unrelated fix > Thanks for catching this! I already covered this point in the reply to Jonathan. Thanks, Irina
RE: [PATCH 4/6] iio: accel: bmg160: optimize transfers in trigger handler
> -Original Message-
> From: Jonathan Cameron [mailto:ji...@kernel.org]
> Sent: 28 March, 2016 17:15
> To: Peter Meerwald-Stadler
> Cc: Tirdea, Irina; linux-...@vger.kernel.org; linux-kernel@vger.kernel.org;
> Hartmut Knaack; Lars-Peter Clausen; Purdila, Octavian;
> Markus Pargmann; Pandruvada, Srinivas
> Subject: Re: [PATCH 4/6] iio: accel: bmg160: optimize transfers in trigger
> handler
>
> On 28/03/16 11:09, Peter Meerwald-Stadler wrote:
> >
> >>> Some i2c busses (e.g.: Synopsys DesignWare I2C adapter) need to
> >>> enable/disable the bus at each i2c transfer and must wait for
> >>> the enable/disable to happen before sending the data.
> >>>
> >>> When reading data in the trigger handler, the bmc150 accel driver does
> >
> > should refer to bmg160
> Good spot. It's also a gyroscope, not an accelerometer... I just fixed this
> up and repushed out testing.
> >
Oops... too much copy-paste :)
> >>> one bus transfer for each axis. This has an impact on the frequency
> >>> of the accelerometer at high sample rates due to additional delays
> >>> introduced by the bus at each transfer.
> >>>
> >>> Reading all axis values in one bus transfer reduces the delays
> >>> introduced by the bus.
> >>>
> >>> Signed-off-by: Irina Tirdea
> >> I forgot to highlight on the earlier driver that there is also
> >> 'technically'
> >> a bit of an ABI change here because we are now exporting as LE rather than
> >> CPU
> >> order. However, I 'hope' anyone actually accessing the buffered data is
> >> either
> >> doing it through a nice library or hasn't hacked the endian unwinding out
> >> of
> >> the generic_buffer example!
> >
> > the patch takes away the possibility to do buffered reads on individual
> > channels (not sure if this is useful per se)
> >
> > this optimizes for the common case, ok;
> >
> > wondering if adding
> > .endianness = IIO_LE
> > is actually an unrelated fix
> Good point, when I first read the code I assumed we were moving from an
> i2c_word
> read to a bulk read, thus necessitating this addition. However, we aren't as
> it
> was previously as an i2c_bulk read of 2 bytes...
>
> Irina, could you confirm if this was broken before your patches?
>
Peter is right. I also had in mind the change from i2c_word to bulk read, but
the regmap API has changed this in the meantime.
Since the driver uses regmap_bulk_read to read 2 bytes for each
axis, the data read will have the endianness of the device (little endian)
and we should do endianness conversion or else it will not work on big
endian platforms.
> I'll leave this as is, perhaps we need an additional fix patch specifying LE
> to
> put out as a fix.
There is one more place in both bmc150 and bmg160 drivers where
regmap_bulk_read is used without endianness conversion (when reading raw axes).
I will send a separate patch to fix all endianness issues.
While looking at the existent code, I also found another bug in the bmg160
driver
that this patch fixes as a side effect: the error code returned by
regmap_bulk_read
is saved in the data->buffer instead of the value read. Not sure how to handle
this,
since it is fixed now by this patch. Jonathan, should I send a fix patch for
this?
Thanks,
Irina
> >
> >> Again, fingers crossed this doesn't break anything significant.
> >>
> >> Applied,
> >>
> >> Thanks,
> >>
> >> Jonathan
> >>> ---
> >>> drivers/iio/gyro/bmg160_core.c | 17 ++---
> >>> 1 file changed, 6 insertions(+), 11 deletions(-)
> >>>
> >>> diff --git a/drivers/iio/gyro/bmg160_core.c
> >>> b/drivers/iio/gyro/bmg160_core.c
> >>> index 8d6e5b1..43570b8 100644
> >>> --- a/drivers/iio/gyro/bmg160_core.c
> >>> +++ b/drivers/iio/gyro/bmg160_core.c
> >>> @@ -734,6 +734,7 @@ static const struct iio_event_spec bmg160_event = {
> >>> .sign = 's',\
> >>> .realbits = 16, \
> >>> .storagebits = 16, \
> >>> + .endianness = IIO_LE, \
> >>> }, \
> >>> .event_spec = &bmg160_event,\
> >>> .num_event_specs = 1
RE: [PATCH v11 6/8] Input: goodix - add support for ESD
> -Original Message- > From: Rob Herring [mailto:r...@kernel.org] > Sent: 20 November, 2015 17:45 > To: Tirdea, Irina > Cc: Dmitry Torokhov; Bastien Nocera; Aleksei Mamlin; Karsten Merker; > linux-in...@vger.kernel.org; Mark Rutland; Purdila, Octavian; > linux-kernel@vger.kernel.org; devicet...@vger.kernel.org > Subject: Re: [PATCH v11 6/8] Input: goodix - add support for ESD > > On Thu, Nov 19, 2015 at 02:26:39PM +0200, Irina Tirdea wrote: > > Add ESD (Electrostatic Discharge) protection mechanism. > > [...] > > > This is based on Goodix datasheets for GT911 and GT9271 and on Goodix > > driver gt9xx.c for Android (publicly available in Android kernel > > trees for various devices). > > > > Signed-off-by: Irina Tirdea > > For the binding: Acked-by: Rob Herring > > You should not have the "For the binding:" part here. It was just a note > so it was clear what part I looked at. > I saw it done like that in another patch already merged, so I thought it's the right way [1]. Dmitry, could you fix this at merge or you need me to send another patchset? Thanks, Irina [1] https://git.kernel.org/cgit/linux/kernel/git/jic23/iio.git/commit/?id=d2a3e0931a8f3b95b910096d022ffd98adbd075c > It is preferred to split DT bindings to separate patches for this > reason. > > > Signed-off-by: Irina Tirdea > > --- > > .../bindings/input/touchscreen/goodix.txt | 4 + > > drivers/input/touchscreen/goodix.c | 160 > > - > > 2 files changed, 159 insertions(+), 5 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v11 3/8] Input: goodix - write configuration data to device
> -Original Message-
> From: Dmitry Torokhov [mailto:dmitry.torok...@gmail.com]
> Sent: 19 November, 2015 20:21
> To: Tirdea, Irina
> Cc: Bastien Nocera; Aleksei Mamlin; Karsten Merker;
> linux-in...@vger.kernel.org; Mark Rutland; Rob Herring; Purdila, Octavian;
> linux-
> ker...@vger.kernel.org; devicet...@vger.kernel.org
> Subject: Re: [PATCH v11 3/8] Input: goodix - write configuration data to
> device
>
> On Thu, Nov 19, 2015 at 02:26:36PM +0200, Irina Tirdea wrote:
> > + if (ts->gpiod_int && ts->gpiod_rst) {
> > + /* update device config */
> > + ts->cfg_name = kasprintf(GFP_KERNEL, "goodix_%d_cfg.bin",
> > +ts->id);
>
> devm_kasprintf maybe (don't resubmit)?
>
Yes, using devm_kasprintf would be better.
Thanks,
Irina
> Thanks.
>
> --
> Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v11 2/8] Input: goodix - reset device at init
> -Original Message- > From: Bastien Nocera [mailto:had...@hadess.net] > Sent: 19 November, 2015 17:25 > To: Tirdea, Irina; Dmitry Torokhov; Aleksei Mamlin; Karsten Merker; > linux-in...@vger.kernel.org > Cc: Mark Rutland; Rob Herring; Purdila, Octavian; > linux-kernel@vger.kernel.org; devicet...@vger.kernel.org > Subject: Re: [PATCH v11 2/8] Input: goodix - reset device at init > > On Thu, 2015-11-19 at 14:26 +0200, Irina Tirdea wrote: > > After power on, it is recommended that the driver resets the device. > > The reset procedure timing is described in the datasheet and is used > > at device init (before writing device configuration) and > > for power management. It is a sequence of setting the interrupt > > and reset pins high/low at specific timing intervals. This procedure > > also includes setting the slave address to the one specified in the > > ACPI/device tree. > > This fails on a 4.3 kernel with an ACPI device (WinBook TW100): > Goodix-TS: probe of i2c-GDIX1001:00 failed with error -16 > > Can you please document which upstream commit is necessary to make this > behave properly? > You need the patch that fixes the GPIO API [1] so that devm_gpiod_get_optional works properly (I mentioned that in the cover letter). This patch just got merged in the gpio tree, so it will take a while until it will be merged in the main kernel tree or input tree. Thanks, Irina [1] https://lkml.org/lkml/2015/11/11/465 > I'll test again with a newer kernel. > > Cheers
RE: [PATCH v10 2/8] Input: goodix - reset device at init
> -Original Message-
> From: Rob Herring [mailto:r...@kernel.org]
> Sent: 18 November, 2015 23:24
> To: Tirdea, Irina
> Cc: Dmitry Torokhov; Bastien Nocera; Aleksei Mamlin; Karsten Merker;
> linux-in...@vger.kernel.org; Mark Rutland; Purdila, Octavian;
> linux-kernel@vger.kernel.org; devicet...@vger.kernel.org
> Subject: Re: [PATCH v10 2/8] Input: goodix - reset device at init
>
> On Wed, Nov 18, 2015 at 06:31:35PM +0200, Irina Tirdea wrote:
> > After power on, it is recommended that the driver resets the device.
> > The reset procedure timing is described in the datasheet and is used
> > at device init (before writing device configuration) and
> > for power management. It is a sequence of setting the interrupt
> > and reset pins high/low at specific timing intervals. This procedure
> > also includes setting the slave address to the one specified in the
> > ACPI/device tree.
> >
> > This is based on Goodix datasheets for GT911 and GT9271 and on Goodix
> > driver gt9xx.c for Android (publicly available in Android kernel
> > trees for various devices).
> >
> > For reset the driver needs to control the interrupt and
> > reset gpio pins (configured through ACPI/device tree). For devices
> > that do not have the gpio pins properly declared, the functionality
> > depending on these pins will not be available, but the device can still
> > be used with basic functionality.
> >
> > For both device tree and ACPI, the interrupt gpio pin configuration is
> > read from the "irq-gpio" property and the reset pin configuration is
> > read from the "reset-gpio" property. For ACPI 5.1, named properties
> > can be specified using the _DSD section. This functionality will not be
> > available for devices that use indexed gpio pins declared in the _CRS
> > section (we need to provide backward compatibility with devices
> > that do not support using the interrupt gpio pin as output).
> >
> > For ACPI, the pins can be specified using ACPI 5.1:
> > Device (STAC)
> > {
> > Name (_HID, "GDIX1001")
> > ...
> >
> > Method (_CRS, 0, Serialized)
> > {
> > Name (RBUF, ResourceTemplate ()
> > {
> > I2cSerialBus (0x0014, ControllerInitiated, 0x00061A80,
> > AddressingMode7Bit, "\\I2C0",
> > 0x00, ResourceConsumer, ,
> > )
> >
> > GpioInt (Edge, ActiveHigh, Exclusive, PullNone, 0x,
> > "\\I2C0", 0x00, ResourceConsumer, ,
> > )
> > { // Pin list
> > 0
> > }
> >
> > GpioIo (Exclusive, PullDown, 0x, 0x,
> > IoRestrictionOutputOnly, "\\I2C0", 0x00,
> > ResourceConsumer, ,
> > )
> > {
> > 1
> > }
> > })
> > Return (RBUF)
> > }
> >
> > Name (_DSD, Package ()
> > {
> > ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
> > Package ()
> > {
> > Package (2) {"irq-gpio", Package() {^STAC, 0, 0, 0 }},
> > Package (2) {"reset-gpio", Package() {^STAC, 1, 0, 0 }},
> > ...
> > }
> > }
> >
> > Signed-off-by: Octavian Purdila
> > Signed-off-by: Irina Tirdea
> > ---
> > .../bindings/input/touchscreen/goodix.txt | 5 +
> > drivers/input/touchscreen/Kconfig | 1 +
> > drivers/input/touchscreen/goodix.c | 101
> > +
> > 3 files changed, 107 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/input/touchscreen/goodix.txt
> b/Documentation/devicetree/bindings/input/touchscreen/goodix.txt
> > index 8ba98ee..7137881 100644
> > --- a/Documentation/devicetree/bindings/input/touchscreen/goodix.txt
> > +++ b/Documentation/devicetree/bindings/input/touchscreen/goodix.txt
> > @@ -12,6 +12,8 @@ Required properties:
> > - reg : I2C address of the chip. Should be 0x5d or
> > 0x14
> > - interrupt-parent: Interrupt controller to which the chip is
> > connected
> > - interrupts : Interrupt to which the chip is connected
> > + - irq-gpio: GPIO pin used for IRQ
>
> Please note here why you need this in addition to just "interrupts".
Ok.
> Also, it should be irq-gpios instead.
>
> > + - reset-gpio : GPIO pin used for reset
>
> Should be reset-gpios instead.
>
I'll fix this, I wasn't aware that irq/reset-gpio is deprecated.
Thanks,
Irina
> Rob
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v9 0/9] Goodix touchscreen enhancements
> -Original Message- > From: Karsten Merker [mailto:mer...@debian.org] > Sent: 26 October, 2015 20:21 > To: Bastien Nocera; Tirdea, Irina > Cc: Dmitry Torokhov; Aleksei Mamlin; Karsten Merker; > linux-in...@vger.kernel.org; Mark Rutland; Purdila, Octavian; linux- > ker...@vger.kernel.org; devicet...@vger.kernel.org > Subject: Re: [PATCH v9 0/9] Goodix touchscreen enhancements > > On Mon, Oct 26, 2015 at 04:06:29PM +0100, Bastien Nocera wrote: > > On Mon, 2015-10-12 at 18:24 +0300, Irina Tirdea wrote: > > > > v9 only adds GPIOLIB dependency in Kconfig for patch 2: > > > "Input: goodix - reset device at init". There are no other code > > > changes from v8. > > > > > > Thanks for testing these changes, Bastien and Aleksei! > > > > > > Karsten, there is no need to rebase your series on top of v9. > > > > Are we waiting on anything else before merging this? I'd like it to be > > scheduled to be merged so I can start focusing on the subsequent and > > dependent patches for that same driver. > > Hello, > > AFAICS there is one open point (cf. > http://www.spinics.net/lists/linux-input/msg41567.html) which > Irina wanted to address in a v10 of the patchset (cf. > http://www.spinics.net/lists/linux-input/msg41642.html). > > Irina, how are your plans regarding the v10? It would be really > nice if the patches could go into kernel 4.4, but the merge > window opens on the coming weekend, so there is not much time > left. I can send v10 with the change mentioned above by the end of this week. However, as Dmitry already mentioned, there is another issue with the gpio ACPI layer that is blocking the entire patchset. > > Bastien, did you have time to look at v3 of the axis > swapping/inversion set? > (http://www.spinics.net/lists/linux-input/msg41628.html) > You had acked v2, but I had to do some small changes to address > Irina's review comments after you had acked it, so I didn't want > to carry your "acked-by" on to v3 without an ok from you. > > Regards, > Karsten > -- > Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung > sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der > Werbung sowie der Markt- oder Meinungsforschung.
RE: [PATCH v9 0/9] Goodix touchscreen enhancements
> -Original Message- > From: Dmitry Torokhov [mailto:dmitry.torok...@gmail.com] > Sent: 27 October, 2015 1:33 > To: Karsten Merker > Cc: Bastien Nocera; Tirdea, Irina; Aleksei Mamlin; > linux-in...@vger.kernel.org; Mark Rutland; Purdila, Octavian; linux- > ker...@vger.kernel.org; devicet...@vger.kernel.org > Subject: Re: [PATCH v9 0/9] Goodix touchscreen enhancements > > On Mon, Oct 26, 2015 at 07:21:12PM +0100, Karsten Merker wrote: > > On Mon, Oct 26, 2015 at 04:06:29PM +0100, Bastien Nocera wrote: > > > On Mon, 2015-10-12 at 18:24 +0300, Irina Tirdea wrote: > > > > > > v9 only adds GPIOLIB dependency in Kconfig for patch 2: > > > > "Input: goodix - reset device at init". There are no other code > > > > changes from v8. > > > > > > > > Thanks for testing these changes, Bastien and Aleksei! > > > > > > > > Karsten, there is no need to rebase your series on top of v9. > > > > > > Are we waiting on anything else before merging this? I'd like it to be > > > scheduled to be merged so I can start focusing on the subsequent and > > > dependent patches for that same driver. > > > > Hello, > > > > AFAICS there is one open point (cf. > > http://www.spinics.net/lists/linux-input/msg41567.html) which > > Irina wanted to address in a v10 of the patchset (cf. > > http://www.spinics.net/lists/linux-input/msg41642.html). > > There is also the whole thing about insane handling of named gpios in > ACPI layer, which stops me from merging the reset code since these gpios > should be marked as optional and we should stop ignoring errors coming > from gpiolib. The ACPI layer change is quite complex, since it includes changing the drivers that use the gpio API before removing the fallback to indexed ACPI. Not sure that will not also break current drivers that already count on this fallback. Unfortunately, I do not have the time right now to get involved in fixing the ACPI core myself. Dmitry, is there anything I can do in the driver to get these patches merged? I could go back to using indexed gpios and add an additional property to specify if irq can be used as output or not (as suggested in one of the previous reviews). Thanks, Irina > > Thanks. > > -- > Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH RFC V3 1/3] Input: goodix - add axis swapping and axis inversion support
> -Original Message-
> From: Karsten Merker [mailto:mer...@debian.org]
> Sent: 18 October, 2015 18:53
> To: Bastien Nocera; Dmitry Torokhov; Tirdea, Irina; Aleksei Mamlin;
> linux-in...@vger.kernel.org; Ian Campbell
> Cc: devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; Chen-Yu Tsai;
> Karsten Merker
> Subject: [PATCH RFC V3 1/3] Input: goodix - add axis swapping and axis
> inversion support
>
> Implement support for the following device-tree and ACPI 5.1 DSD
> properties in the goodix touchscreen driver:
>
> - touchscreen-inverted-x: X axis is inverted (boolean)
> - touchscreen-inverted-y: Y axis is inverted (boolean)
> - touchscreen-swapped-x-y: X and Y axis are swapped (boolean)
>
> These are necessary on tablets which have a display in portrait
> format while the touchscreen is in landscape format, such as e.g.
> the MSI Primo 81.
>
> Signed-off-by: Karsten Merker
> Tested-by: Bastien Nocera
> ---
Looks good to me, thanks for making the changes.
Tested this with ACPI _DSD properties.
Tested-by: Irina Tirdea
> drivers/input/touchscreen/goodix.c | 25 +
> 1 file changed, 25 insertions(+)
>
> diff --git a/drivers/input/touchscreen/goodix.c
> b/drivers/input/touchscreen/goodix.c
> index 22bfc4b..b585123 100644
> --- a/drivers/input/touchscreen/goodix.c
> +++ b/drivers/input/touchscreen/goodix.c
> @@ -2,6 +2,7 @@
> * Driver for Goodix Touchscreens
> *
> * Copyright (c) 2014 Red Hat Inc.
> + * Copyright (c) 2015 K. Merker
> *
> * This code is based on gt9xx.c authored by and...@goodix.com:
> *
> @@ -53,6 +54,9 @@ struct goodix_ts_data {
> atomic_t open_count;
> /* Protects power management calls and access to suspended flag */
> struct mutex mutex;
> + bool swapped_x_y;
> + bool inverted_x;
> + bool inverted_y;
> };
>
> #define GOODIX_GPIO_INT_NAME "irq"
> @@ -271,6 +275,14 @@ static void goodix_ts_report_touch(struct goodix_ts_data
> *ts, u8 *coor_data)
> input_y = ts->abs_y_max - input_y;
> }
>
> + /* Inversions have to happen before axis swapping */
> + if (ts->inverted_x)
> + input_x = ts->abs_x_max - input_x;
> + if (ts->inverted_y)
> + input_y = ts->abs_y_max - input_y;
> + if (ts->swapped_x_y)
> + swap(input_x, input_y);
> +
> input_mt_slot(ts->input_dev, id);
> input_mt_report_slot_state(ts->input_dev, MT_TOOL_FINGER, true);
> input_report_abs(ts->input_dev, ABS_MT_POSITION_X, input_x);
> @@ -666,6 +678,8 @@ static void goodix_read_config(struct goodix_ts_data *ts)
>error);
> ts->abs_x_max = GOODIX_MAX_WIDTH;
> ts->abs_y_max = GOODIX_MAX_HEIGHT;
> + if (ts->swapped_x_y)
> + swap(ts->abs_x_max, ts->abs_y_max);
> ts->int_trigger_type = GOODIX_INT_TRIGGER;
> ts->max_touch_num = GOODIX_MAX_CONTACTS;
> return;
> @@ -673,6 +687,8 @@ static void goodix_read_config(struct goodix_ts_data *ts)
>
> ts->abs_x_max = get_unaligned_le16(&config[RESOLUTION_LOC]);
> ts->abs_y_max = get_unaligned_le16(&config[RESOLUTION_LOC + 2]);
> + if (ts->swapped_x_y)
> + swap(ts->abs_x_max, ts->abs_y_max);
> ts->int_trigger_type = config[TRIGGER_LOC] & 0x03;
> ts->max_touch_num = config[MAX_CONTACTS_LOC] & 0x0f;
> if (!ts->abs_x_max || !ts->abs_y_max || !ts->max_touch_num) {
> @@ -680,6 +696,8 @@ static void goodix_read_config(struct goodix_ts_data *ts)
> "Invalid config, using defaults\n");
> ts->abs_x_max = GOODIX_MAX_WIDTH;
> ts->abs_y_max = GOODIX_MAX_HEIGHT;
> + if (ts->swapped_x_y)
> + swap(ts->abs_x_max, ts->abs_y_max);
> ts->max_touch_num = GOODIX_MAX_CONTACTS;
> }
>
> @@ -805,6 +823,13 @@ static int goodix_configure_dev(struct goodix_ts_data
> *ts)
> {
> int error;
>
> + ts->swapped_x_y = device_property_read_bool(&ts->client->dev,
> + "touchscreen-swapped-x-y");
> + ts->inverted_x = device_property_read_bool(&ts->client->dev,
> +"touchscreen-inverted-x");
> + ts->inverted_y = device_property_read_bool(&ts->client->dev,
> +"touchscreen-inverted-y");
> +
> goodix_read_config(ts);
>
> error = goodix_request_input_dev(ts);
> --
> 2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v9 2/9] Input: goodix - reset device at init
> -Original Message- > From: linux-input-ow...@vger.kernel.org > [mailto:linux-input-ow...@vger.kernel.org] On Behalf Of > mika.westerb...@linux.intel.com > Sent: 14 October, 2015 16:44 > To: Dmitry Torokhov > Cc: Tirdea, Irina; Bastien Nocera; Aleksei Mamlin; Karsten Merker; > linux-in...@vger.kernel.org; Mark Rutland; Purdila, Octavian; linux- > ker...@vger.kernel.org; devicet...@vger.kernel.org > Subject: Re: [PATCH v9 2/9] Input: goodix - reset device at init > > On Wed, Oct 14, 2015 at 02:18:20PM +0300, mika.westerb...@linux.intel.com > wrote: > > On Tue, Oct 13, 2015 at 11:23:03PM -0700, Dmitry Torokhov wrote: > > > I understand why one might use acpi_dev_add_driver_gpios() to augment > > > data in ACPI, however here we have completely different issue: driver > > > that expects named gpios gets returned gpio that has nothing to do with > > > what it requested, because gpiolib acpi code always falls back to > > > unnamed gpio if it does not find named gpio. That can be acceptable if > > > driver uses the same con_id for all requests to gpiolib, but is not > > > working when driver supplies different con_ids. > > > > Right, the ACPI fallback ignores con_id completely and uses only the > > index. > > > > AFAIK there is only one driver using ACPI _CRS index method: > > sdhci-[acpi|pci].c. If we can convert that to use > > acpi_dev_add_driver_gpios() > > to feed names for card detection GPIOs, I think we can remove the > > fallback alltogether in favor of named GPIOs for ACPI. > > Nah, there seems to be several drivers relying on this already :-/ Would it be possible to add an optional parameter to the GPIO API to specify whether we want to fall back to indexed GPIOs for ACPI? > -- > To unsubscribe from this list: send the line "unsubscribe linux-input" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v7 3/9] Input: goodix - write configuration data to device
> -Original Message-
> From: Dmitry Torokhov [mailto:dmitry.torok...@gmail.com]
> Sent: 14 October, 2015 9:59
> To: Tirdea, Irina
> Cc: Bastien Nocera; Aleksei Mamlin; linux-in...@vger.kernel.org; Mark
> Rutland; Purdila, Octavian; linux-kernel@vger.kernel.org;
> devicet...@vger.kernel.org
> Subject: Re: [PATCH v7 3/9] Input: goodix - write configuration data to device
>
> On Thu, Oct 08, 2015 at 01:19:29PM +0300, Irina Tirdea wrote:
> > Goodix devices can be configured by writing custom data to the device at
> > init. The configuration data is read with request_firmware from
> > "goodix__cfg.bin", where is the product id read from the device
> > (e.g.: goodix_911_cfg.bin for Goodix GT911, goodix_9271_cfg.bin for
> > GT9271).
> >
> > The configuration information has a specific format described in the Goodix
> > datasheet. It includes X/Y resolution, maximum supported touch points,
> > interrupt flags, various sensitivity factors and settings for advanced
> > features (like gesture recognition).
> >
> > Before writing the firmware, it is necessary to reset the device. If
> > the device ACPI/DT information does not declare gpio pins (needed for
> > reset), writing the firmware will not be available for these devices.
> >
> > This is based on Goodix datasheets for GT911 and GT9271 and on Goodix
> > driver gt9xx.c for Android (publicly available in Android kernel
> > trees for various devices).
> >
> > Signed-off-by: Octavian Purdila
> > Signed-off-by: Irina Tirdea
> > ---
> > drivers/input/touchscreen/goodix.c | 229
> > +++--
> > 1 file changed, 196 insertions(+), 33 deletions(-)
> >
> > +/**
> > + * goodix_config_cb - Callback to finish device init
> > + *
> > + * @ts: our goodix_ts_data pointer
> > + *
> > + * request_firmware_wait callback that finishes
> > + * initialization of the device.
> > + */
> > +static void goodix_config_cb(const struct firmware *cfg, void *ctx)
> > +{
> > + struct goodix_ts_data *ts = (struct goodix_ts_data *)ctx;
> > + int error;
> > +
> > + if (cfg) {
> > + /* send device configuration to the firmware */
> > + error = goodix_send_cfg(ts, cfg);
> > + if (error)
> > + goto err_release_cfg;
> > + }
> > + goodix_configure_dev(ts);
> > +
> > +err_release_cfg:
> > + kfree(ts->cfg_name);
> > + release_firmware(cfg);
>
> You need to use completion to signal remove() (and also probably
> suspend/resume in the subsequent patches) that you are done handling
> config, otherwise if you do bind/unbind via sysfs in a tight loop you
> will observe a nice crash.
>
> Thanks.
>
Right, missed that. Will fix in next version.
Thanks,
Irina
> --
> Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v9 2/9] Input: goodix - reset device at init
> -Original Message-
> From: Dmitry Torokhov [mailto:dmitry.torok...@gmail.com]
> Sent: 13 October, 2015 10:08
> To: Tirdea, Irina
> Cc: Bastien Nocera; Aleksei Mamlin; Karsten Merker;
> linux-in...@vger.kernel.org; Mark Rutland; Purdila, Octavian; linux-
> ker...@vger.kernel.org; devicet...@vger.kernel.org
> Subject: Re: [PATCH v9 2/9] Input: goodix - reset device at init
>
> On Tue, Oct 13, 2015 at 06:38:23AM +, Tirdea, Irina wrote:
> >
> >
> > > -Original Message-
> > > From: Dmitry Torokhov [mailto:dmitry.torok...@gmail.com]
> > > Sent: 12 October, 2015 19:48
> > > To: Tirdea, Irina
> > > Cc: Bastien Nocera; Aleksei Mamlin; Karsten Merker;
> > > linux-in...@vger.kernel.org; Mark Rutland; Purdila, Octavian; linux-
> > > ker...@vger.kernel.org; devicet...@vger.kernel.org
> > > Subject: Re: [PATCH v9 2/9] Input: goodix - reset device at init
> > >
> > > On Mon, Oct 12, 2015 at 06:24:30PM +0300, Irina Tirdea wrote:
> > > > After power on, it is recommended that the driver resets the device.
> > > > The reset procedure timing is described in the datasheet and is used
> > > > at device init (before writing device configuration) and
> > > > for power management. It is a sequence of setting the interrupt
> > > > and reset pins high/low at specific timing intervals. This procedure
> > > > also includes setting the slave address to the one specified in the
> > > > ACPI/device tree.
> > > >
> > > > This is based on Goodix datasheets for GT911 and GT9271 and on Goodix
> > > > driver gt9xx.c for Android (publicly available in Android kernel
> > > > trees for various devices).
> > > >
> > > > For reset the driver needs to control the interrupt and
> > > > reset gpio pins (configured through ACPI/device tree). For devices
> > > > that do not have the gpio pins properly declared, the functionality
> > > > depending on these pins will not be available, but the device can still
> > > > be used with basic functionality.
> > > >
> > > > For both device tree and ACPI, the interrupt gpio pin configuration is
> > > > read from the "irq-gpio" property and the reset pin configuration is
> > > > read from the "reset-gpio" property. For ACPI 5.1, named properties
> > > > can be specified using the _DSD section. This functionality will not be
> > > > available for devices that use indexed gpio pins declared in the _CRS
> > > > section (we need to provide backward compatibility with devices
> > > > that do not support using the interrupt gpio pin as output).
> > > >
> > > > For ACPI, the pins can be specified using ACPI 5.1:
> > > > Device (STAC)
> > > > {
> > > > Name (_HID, "GDIX1001")
> > > > ...
> > > >
> > > > Method (_CRS, 0, Serialized)
> > > > {
> > > > Name (RBUF, ResourceTemplate ()
> > > > {
> > > > I2cSerialBus (0x0014, ControllerInitiated, 0x00061A80,
> > > > AddressingMode7Bit, "\\I2C0",
> > > > 0x00, ResourceConsumer, ,
> > > > )
> > > >
> > > > GpioInt (Edge, ActiveHigh, Exclusive, PullNone, 0x,
> > > > "\\I2C0", 0x00, ResourceConsumer, ,
> > > > )
> > > > { // Pin list
> > > > 0
> > > > }
> > > >
> > > > GpioIo (Exclusive, PullDown, 0x, 0x,
> > > > IoRestrictionOutputOnly, "\\I2C0", 0x00,
> > > > ResourceConsumer, ,
> > > > )
> > > > {
> > > > 1
> > > > }
> > > > })
> > > > Return (RBUF)
> > > > }
> > > >
> > > > Name (_DSD, Package ()
> > > > {
> > > > ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
> > > > Package ()
> > > > {
> > > > Package (2) {"irq-gpio", Package() {^STAC, 0, 0, 0 }},
> > > > Package (2) {"reset-gpio", Package() {^STAC, 1, 0, 0 }},
> > > > ...
> > >
RE: [PATCH RFC V2 3/3] Input: goodix - update dt bindings documentation (axis swapping/inversion)
> -Original Message-
> From: linux-input-ow...@vger.kernel.org
> [mailto:linux-input-ow...@vger.kernel.org] On Behalf Of Karsten Merker
> Sent: 09 October, 2015 20:56
> To: Bastien Nocera; Dmitry Torokhov; Tirdea, Irina; Aleksei Mamlin;
> linux-in...@vger.kernel.org; Ian Campbell
> Cc: devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; Chen-Yu Tsai;
> Karsten Merker
> Subject: [PATCH RFC V2 3/3] Input: goodix - update dt bindings documentation
> (axis swapping/inversion)
>
> The goodix touchscreen driver has gained support for the
> optional touchscreen-inverted-x, touchscreen-inverted-y
> and touchscreen-swapped-x-y properties as described in
> Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt.
>
> Document these properties in the goodix bindings description.
>
> Signed-off-by: Karsten Merker
Reviewed-by: Irina Tirdea
> ---
> Documentation/devicetree/bindings/input/touchscreen/goodix.txt | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/input/touchscreen/goodix.txt
> b/Documentation/devicetree/bindings/input/touchscreen/goodix.txt
> index 4db3393..4ecd0e1 100644
> --- a/Documentation/devicetree/bindings/input/touchscreen/goodix.txt
> +++ b/Documentation/devicetree/bindings/input/touchscreen/goodix.txt
> @@ -14,6 +14,7 @@ Required properties:
> - interrupts: Interrupt to which the chip is connected
> - irq-gpio : GPIO pin used for IRQ
> - reset-gpio: GPIO pin used for reset
> +
> Optional properties:
>
> - esd-recovery-timeout-ms : ESD poll time (in milli seconds) for the driver
> to
> @@ -21,6 +22,11 @@ Optional properties:
> device. ESD is disabled if this property is not
> set
> or is set to 0.
>
> + - touchscreen-inverted-x : X axis is inverted (boolean)
> + - touchscreen-inverted-y : Y axis is inverted (boolean)
> + - touchscreen-swapped-x-y : X and Y axis are swapped (boolean)
> + (swapping is done after inverting the axis)
> +
> Example:
>
> i2c@ {
> --
> 2.1.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-input" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH RFC V2 2/3] Input: goodix - use "inverted_[xy]" flags instead of "rotated_screen"
> -Original Message-
> From: Karsten Merker [mailto:mer...@debian.org]
> Sent: 09 October, 2015 20:56
> To: Bastien Nocera; Dmitry Torokhov; Tirdea, Irina; Aleksei Mamlin;
> linux-in...@vger.kernel.org; Ian Campbell
> Cc: devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; Chen-Yu Tsai;
> Karsten Merker
> Subject: [PATCH RFC V2 2/3] Input: goodix - use "inverted_[xy]" flags instead
> of "rotated_screen"
>
> The goodix touchscreen driver uses a "rotated_screen" flag for
> systems on which the touchscreen is mounted rotated by 180
> degrees with respect to the display. With the addition of
> support for the dt properties "touchscreen-inverted-x" and
> "touchscreen-inverted-y", a separate "rotated_screen" flag
> is not necessary any more. This patch replaces it by setting
> the inverted_x and inverted_y flags instead.
>
> Signed-off-by: Karsten Merker
> ---
Reviewed-by: Irina Tirdea
> drivers/input/touchscreen/goodix.c | 12
> 1 file changed, 4 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/input/touchscreen/goodix.c
> b/drivers/input/touchscreen/goodix.c
> index a05bdad..d910b27 100644
> --- a/drivers/input/touchscreen/goodix.c
> +++ b/drivers/input/touchscreen/goodix.c
> @@ -40,7 +40,6 @@ struct goodix_ts_data {
> int abs_y_max;
> unsigned int max_touch_num;
> unsigned int int_trigger_type;
> - bool rotated_screen;
> int cfg_len;
> struct gpio_desc *gpiod_int;
> struct gpio_desc *gpiod_rst;
> @@ -270,11 +269,6 @@ static void goodix_ts_report_touch(struct goodix_ts_data
> *ts, u8 *coor_data)
> int input_y = get_unaligned_le16(&coor_data[3]);
> int input_w = get_unaligned_le16(&coor_data[5]);
>
> - if (ts->rotated_screen) {
> - input_x = ts->abs_x_max - input_x;
> - input_y = ts->abs_y_max - input_y;
> - }
> -
> /* Inversions have to happen before axis swapping */
> if (ts->inverted_x)
> input_x = ts->abs_x_max - input_x;
> @@ -701,10 +695,12 @@ static void goodix_read_config(struct goodix_ts_data
> *ts)
> ts->max_touch_num = GOODIX_MAX_CONTACTS;
> }
>
> - ts->rotated_screen = dmi_check_system(rotated_screen);
> - if (ts->rotated_screen)
> + if (dmi_check_system(rotated_screen)) {
> + ts->inverted_x = true;
> + ts->inverted_y = true;
> dev_dbg(&ts->client->dev,
>"Applying '180 degrees rotated screen' quirk\n");
> + }
> }
>
> /**
> --
> 2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH RFC V2 0/3] Input: goodix - add axis swapping and axis inversion support
> -Original Message- > From: Karsten Merker [mailto:mer...@debian.org] > Sent: 09 October, 2015 20:56 > To: Bastien Nocera; Dmitry Torokhov; Tirdea, Irina; Aleksei Mamlin; > linux-in...@vger.kernel.org; Ian Campbell > Cc: devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; Chen-Yu Tsai; > Karsten Merker > Subject: [PATCH RFC V2 0/3] Input: goodix - add axis swapping and axis > inversion support > > Hello, > > this is v2 of my "Input: goodix - add axis swapping and axis inversion > support" patchset. > The goodix touchscreen driver has gained device-tree support in kernel > 4.1, but doesn't currently support the touchscreen-swapped-x-y, > touchscreen-inverted-x and touchscreen-inverted-y properties. > > On systems which combine a portrait-mode display with a landscape-mode > touchscreen, such as e.g. the MSI Primo 81 tablet, support for these > features is necessary to have the touchscreen and the display use the > same coordinate system. > > With support for axis inversion, the "rotated_screen" flag in the > driver can also be removed, as "rotated_screen" is just a special case > of x/y axis inversion. > > This patchset sits on top of the "[PATCH v8 0/9] Goodix touchscreen > enhancements" series by Irina Tirdea: > https://www.spinics.net/lists/linux-input/msg41437.html > > I have successfully tested the axis swapping on an (arm-based) MSI > Primo 81 tablet, but I lack appropriate hardware to do a real-world > test of the "rotated_screen" code path, so I would appreciate very > much if somebody with appropriate hardware (WinBook TW100 or TW700) > could give it a try. > > Regards, > Karsten > Hi Karsten, I took a look at your patches and also did a quick test on my setup. Code looks good, I have just one comment I've mentioned on the first patch in the series. Thanks, Irina > Changelog: > > v1: * Initial version (based von v6 of Irina Tirdea's "Goodix > touchscreen enhancements" series). > Reviewed-by: Bastien Nocera > > v2: * Rebase against v8 of Irina Tirdea's "Goodix touchscreen > enhancements" series. > * Fix a typo in the commit message. > * Add an update for the goodix dt bindings documentation > (patch No. 3). > > > Karsten Merker (3): > Input: goodix - add dt axis swapping and axis inversion support > Input: goodix - use "inverted_[xy]" flags instead of "rotated_screen" > Input: goodix - update dt bindings documentation (axis > swapping/inversion) > > .../bindings/input/touchscreen/goodix.txt | 6 > drivers/input/touchscreen/goodix.c | 33 > ++ > 2 files changed, 34 insertions(+), 5 deletions(-) > > -- > 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH RFC V2 1/3] Input: goodix - add dt axis swapping and axis inversion support
> -Original Message-
> From: linux-input-ow...@vger.kernel.org
> [mailto:linux-input-ow...@vger.kernel.org] On Behalf Of Karsten Merker
> Sent: 09 October, 2015 20:56
> To: Bastien Nocera; Dmitry Torokhov; Tirdea, Irina; Aleksei Mamlin;
> linux-in...@vger.kernel.org; Ian Campbell
> Cc: devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; Chen-Yu Tsai;
> Karsten Merker
> Subject: [PATCH RFC V2 1/3] Input: goodix - add dt axis swapping and axis
> inversion support
>
> Implement support for the following device-tree properties
> in the goodix touchscreen driver:
>
> - touchscreen-inverted-x: X axis is inverted (boolean)
> - touchscreen-inverted-y: Y axis is inverted (boolean)
> - touchscreen-swapped-x-y: X and Y axis are swapped (boolean)
>
> These are necessary on tablets which have a display in portrait
> format while the touchscreen is in landscape format, such as e.g.
> the MSI Primo 81.
>
> Signed-off-by: Karsten Merker
> ---
> drivers/input/touchscreen/goodix.c | 27 +++
> 1 file changed, 27 insertions(+)
>
> diff --git a/drivers/input/touchscreen/goodix.c
> b/drivers/input/touchscreen/goodix.c
> index 22bfc4b..a05bdad 100644
> --- a/drivers/input/touchscreen/goodix.c
> +++ b/drivers/input/touchscreen/goodix.c
> @@ -2,6 +2,7 @@
> * Driver for Goodix Touchscreens
> *
> * Copyright (c) 2014 Red Hat Inc.
> + * Copyright (c) 2015 K. Merker
> *
> * This code is based on gt9xx.c authored by and...@goodix.com:
> *
> @@ -53,6 +54,9 @@ struct goodix_ts_data {
> atomic_t open_count;
> /* Protects power management calls and access to suspended flag */
> struct mutex mutex;
> + bool swapped_x_y;
> + bool inverted_x;
> + bool inverted_y;
> };
>
> #define GOODIX_GPIO_INT_NAME "irq"
> @@ -271,6 +275,14 @@ static void goodix_ts_report_touch(struct goodix_ts_data
> *ts, u8 *coor_data)
> input_y = ts->abs_y_max - input_y;
> }
>
> + /* Inversions have to happen before axis swapping */
> + if (ts->inverted_x)
> + input_x = ts->abs_x_max - input_x;
> + if (ts->inverted_y)
> + input_y = ts->abs_y_max - input_y;
> + if (ts->swapped_x_y)
> + swap(input_x, input_y);
> +
> input_mt_slot(ts->input_dev, id);
> input_mt_report_slot_state(ts->input_dev, MT_TOOL_FINGER, true);
> input_report_abs(ts->input_dev, ABS_MT_POSITION_X, input_x);
> @@ -666,6 +678,8 @@ static void goodix_read_config(struct goodix_ts_data *ts)
>error);
> ts->abs_x_max = GOODIX_MAX_WIDTH;
> ts->abs_y_max = GOODIX_MAX_HEIGHT;
> + if (ts->swapped_x_y)
> + swap(ts->abs_x_max, ts->abs_y_max);
> ts->int_trigger_type = GOODIX_INT_TRIGGER;
> ts->max_touch_num = GOODIX_MAX_CONTACTS;
> return;
> @@ -673,6 +687,8 @@ static void goodix_read_config(struct goodix_ts_data *ts)
>
> ts->abs_x_max = get_unaligned_le16(&config[RESOLUTION_LOC]);
> ts->abs_y_max = get_unaligned_le16(&config[RESOLUTION_LOC + 2]);
> + if (ts->swapped_x_y)
> + swap(ts->abs_x_max, ts->abs_y_max);
> ts->int_trigger_type = config[TRIGGER_LOC] & 0x03;
> ts->max_touch_num = config[MAX_CONTACTS_LOC] & 0x0f;
> if (!ts->abs_x_max || !ts->abs_y_max || !ts->max_touch_num) {
> @@ -680,6 +696,8 @@ static void goodix_read_config(struct goodix_ts_data *ts)
> "Invalid config, using defaults\n");
> ts->abs_x_max = GOODIX_MAX_WIDTH;
> ts->abs_y_max = GOODIX_MAX_HEIGHT;
> + if (ts->swapped_x_y)
> + swap(ts->abs_x_max, ts->abs_y_max);
> ts->max_touch_num = GOODIX_MAX_CONTACTS;
> }
>
> @@ -950,6 +968,15 @@ static int goodix_ts_probe(struct i2c_client *client,
> return 0;
> }
>
> +#ifdef CONFIG_OF
> + ts->swapped_x_y = of_property_read_bool(client->dev.of_node,
> + "touchscreen-swapped-x-y");
> + ts->inverted_x = of_property_read_bool(client->dev.of_node,
> +"touchscreen-inverted-x");
> + ts->inverted_y = of_property_read_bool(client->dev.of_node,
> +"touchscreen-inverted-y");
> +#endif
> +
If interrupt and reset gpio pins are declared in the DT configuration, this
code will not
be
RE: [PATCH v9 9/9] Input: goodix - sort includes using inverse Xmas tree order
> -Original Message- > From: Dmitry Torokhov [mailto:dmitry.torok...@gmail.com] > Sent: 12 October, 2015 19:31 > To: Bastien Nocera > Cc: Mark Rutland; Tirdea, Irina; Aleksei Mamlin; Karsten Merker; > linux-in...@vger.kernel.org; Purdila, Octavian; lkml; > devicet...@vger.kernel.org > Subject: Re: [PATCH v9 9/9] Input: goodix - sort includes using inverse Xmas > tree order > > On Mon, Oct 12, 2015 at 8:53 AM, Bastien Nocera wrote: > > On Mon, 2015-10-12 at 16:51 +0100, Mark Rutland wrote: > >> On Mon, Oct 12, 2015 at 05:40:37PM +0200, Bastien Nocera wrote: > >> > On Mon, 2015-10-12 at 16:39 +0100, Mark Rutland wrote: > >> > > Why? > >> > > >> > It was already discussed in the thread for a previous version, > >> > please > >> > refer to that. > >> > >> Fine, but surely that should be in the commit message, to prevent > >> others > >> like myself repeatedly asking the same question? > > > > Fair point. Irina? > > No, let's just leave poor includes alone. > OK, will drop this :) Thanks, Irina > -- > Dmitry
RE: [PATCH v9 2/9] Input: goodix - reset device at init
> -Original Message-
> From: Dmitry Torokhov [mailto:dmitry.torok...@gmail.com]
> Sent: 12 October, 2015 19:48
> To: Tirdea, Irina
> Cc: Bastien Nocera; Aleksei Mamlin; Karsten Merker;
> linux-in...@vger.kernel.org; Mark Rutland; Purdila, Octavian; linux-
> ker...@vger.kernel.org; devicet...@vger.kernel.org
> Subject: Re: [PATCH v9 2/9] Input: goodix - reset device at init
>
> On Mon, Oct 12, 2015 at 06:24:30PM +0300, Irina Tirdea wrote:
> > After power on, it is recommended that the driver resets the device.
> > The reset procedure timing is described in the datasheet and is used
> > at device init (before writing device configuration) and
> > for power management. It is a sequence of setting the interrupt
> > and reset pins high/low at specific timing intervals. This procedure
> > also includes setting the slave address to the one specified in the
> > ACPI/device tree.
> >
> > This is based on Goodix datasheets for GT911 and GT9271 and on Goodix
> > driver gt9xx.c for Android (publicly available in Android kernel
> > trees for various devices).
> >
> > For reset the driver needs to control the interrupt and
> > reset gpio pins (configured through ACPI/device tree). For devices
> > that do not have the gpio pins properly declared, the functionality
> > depending on these pins will not be available, but the device can still
> > be used with basic functionality.
> >
> > For both device tree and ACPI, the interrupt gpio pin configuration is
> > read from the "irq-gpio" property and the reset pin configuration is
> > read from the "reset-gpio" property. For ACPI 5.1, named properties
> > can be specified using the _DSD section. This functionality will not be
> > available for devices that use indexed gpio pins declared in the _CRS
> > section (we need to provide backward compatibility with devices
> > that do not support using the interrupt gpio pin as output).
> >
> > For ACPI, the pins can be specified using ACPI 5.1:
> > Device (STAC)
> > {
> > Name (_HID, "GDIX1001")
> > ...
> >
> > Method (_CRS, 0, Serialized)
> > {
> > Name (RBUF, ResourceTemplate ()
> > {
> > I2cSerialBus (0x0014, ControllerInitiated, 0x00061A80,
> > AddressingMode7Bit, "\\I2C0",
> > 0x00, ResourceConsumer, ,
> > )
> >
> > GpioInt (Edge, ActiveHigh, Exclusive, PullNone, 0x,
> > "\\I2C0", 0x00, ResourceConsumer, ,
> > )
> > { // Pin list
> > 0
> > }
> >
> > GpioIo (Exclusive, PullDown, 0x, 0x,
> > IoRestrictionOutputOnly, "\\I2C0", 0x00,
> > ResourceConsumer, ,
> > )
> > {
> > 1
> > }
> > })
> > Return (RBUF)
> > }
> >
> > Name (_DSD, Package ()
> > {
> > ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
> > Package ()
> > {
> > Package (2) {"irq-gpio", Package() {^STAC, 0, 0, 0 }},
> > Package (2) {"reset-gpio", Package() {^STAC, 1, 0, 0 }},
> > ...
> > }
> > }
> >
> > Signed-off-by: Octavian Purdila
> > Signed-off-by: Irina Tirdea
> > Acked-by: Bastien Nocera
> > Tested-by: Bastien Nocera
> > Tested-by: Aleksei Mamlin
> > ---
> > .../bindings/input/touchscreen/goodix.txt | 5 +
> > drivers/input/touchscreen/Kconfig | 1 +
> > drivers/input/touchscreen/goodix.c | 101
> > +
> > 3 files changed, 107 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/input/touchscreen/goodix.txt
> b/Documentation/devicetree/bindings/input/touchscreen/goodix.txt
> > index 8ba98ee..7137881 100644
> > --- a/Documentation/devicetree/bindings/input/touchscreen/goodix.txt
> > +++ b/Documentation/devicetree/bindings/input/touchscreen/goodix.txt
> > @@ -12,6 +12,8 @@ Required properties:
> > - reg : I2C address of the chip. Should be 0x5d or
> > 0x14
> > - interrupt-parent: Interrupt controller to which the chip is
> > connected
> > - interrupts : Interrupt to which the chip is connected
> > + - irq-gpio: GPIO
RE: [PATCH v8 0/9] Goodix touchscreen enhancements
> -Original Message- > From: linux-input-ow...@vger.kernel.org > [mailto:linux-input-ow...@vger.kernel.org] On Behalf Of Arnd Bergmann > Sent: 08 October, 2015 17:32 > To: Tirdea, Irina > Cc: Dmitry Torokhov; Bastien Nocera; Aleksei Mamlin; > linux-in...@vger.kernel.org; Mark Rutland; Purdila, Octavian; linux- > ker...@vger.kernel.org; devicet...@vger.kernel.org > Subject: Re: [PATCH v8 0/9] Goodix touchscreen enhancements > > On Thursday 08 October 2015 17:23:42 Irina Tirdea wrote: > > Add several enhancements to the Goodix touchscreen driver. > > > > The new functionality is only available for devices that > > declare named gpio pins for interrupt and reset in their > > ACPI/DT configuration. > > > > Thanks, > > Irina > > > > Changes in v8: > > - only allow new functionality for devices that declare named > > gpios (using _DSD properties in ACPI or named DT properties) > > > > > > Looks much cleaner this way, thanks! > > One remaining question: how would you handle the case where > the hardware doesn't support configuring the int-gpios line > as output but you still want to use the named gpios? > The only reason to use named gpios is to enable the new functionality introduced by this patch set (mainly reset and power management). You cannot use only one gpio either (e.g. only reset gpio but not the interrupt gpio), you need both for this functionality to work. If the hardware does not support using the interrupt gpio pin as output, it should not declare the named int-gpio pin in ACPI. It is true that we might later run into platforms that declare the int-gpio pin even if it does not actually work (just like we now have the indexed gpio pins). I could have added an additional property for this as you first suggested, but if we can modify the ACPI to add it, we could simply remove the named interrupt pin instead (that does not work anyway). > I assume you have that case covered, but I don't see it immediately. > > Arnd > -- > To unsubscribe from this list: send the line "unsubscribe linux-input" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v7 2/9] Input: goodix - reset device at init
> -Original Message-
> From: Arnd Bergmann [mailto:a...@arndb.de]
> Sent: 08 October, 2015 16:01
> To: Tirdea, Irina
> Cc: Dmitry Torokhov; Bastien Nocera; Aleksei Mamlin;
> linux-in...@vger.kernel.org; Mark Rutland; Purdila, Octavian; linux-
> ker...@vger.kernel.org; devicet...@vger.kernel.org
> Subject: Re: [PATCH v7 2/9] Input: goodix - reset device at init
>
> On Thursday 08 October 2015 12:18:37 Tirdea, Irina wrote:
> > > From: Arnd Bergmann [mailto:a...@arndb.de]
> > > Sent: 08 October, 2015 13:54
> > > To: Tirdea, Irina
> > > Cc: Dmitry Torokhov; Bastien Nocera; Aleksei Mamlin;
> > > linux-in...@vger.kernel.org; Mark Rutland; Purdila, Octavian; linux-
> > > ker...@vger.kernel.org; devicet...@vger.kernel.org
> > > Subject: Re: [PATCH v7 2/9] Input: goodix - reset device at init
> > >
> > > On Thursday 08 October 2015 13:19:28 Irina Tirdea wrote:
> > > > After power on, it is recommended that the driver resets the device.
> > > > The reset procedure timing is described in the datasheet and is used
> > > > at device init (before writing device configuration) and
> > > > for power management. It is a sequence of setting the interrupt
> > > > and reset pins high/low at specific timing intervals. This procedure
> > > > also includes setting the slave address to the one specified in the
> > > > ACPI/device tree.
> > > >
> > > > This is based on Goodix datasheets for GT911 and GT9271 and on Goodix
> > > > driver gt9xx.c for Android (publicly available in Android kernel
> > > > trees for various devices).
> > > >
> > > > For reset the driver needs to control the interrupt and
> > > > reset gpio pins (configured through ACPI/device tree). For devices
> > > > that do not have the gpio pins declared, the functionality depending
> > > > on these pins will not be available, but the device can still be used
> > > > with basic functionality.
> > > >
> > > > For both device tree and ACPI, the interrupt gpio pin configuration is
> > > > read from the "irq-gpio" property and the reset pin configuration is
> > > > read from the "reset-gpio" property. For ACPI 5.1, named properties
> > > > can be specified using the _DSD section. If there is no _DSD section
> > > > in the ACPI table, the driver will fall back to using indexed gpio
> > > > pins declared in the _CRS section.
> > >
> > > Would it help to use a plain "gpios" property here to always look
> > > up the lines by index?
> > >
> >
> > The problem with ACPI indexed gpios is that platforms declare the
> > pins in random order. In this case we have some platforms that declare
> > the interrupt pin first and others that declare the reset pin first.
> > There is no way to differentiate between them so the only way to support
> > these platforms is to pick a default and list all exceptions in the driver.
> > My previous implementation did that with indexed gpios and dmi quirks. [1]
> >
> > This can be solved by using named gpios, which are available starting with
> > ACPI 5.1.
> > In this way we know exactly which is the interrupt pin and which is the
> > reset pin
> > and we do not need to add any additional exceptions to the driver.
> > However, we still need to support the platforms that are already out there
> > so
> > we fall back to indexed gpios.
> >
> > [1] https://lkml.org/lkml/2015/9/15/609
>
> Right.
>
> > > > +/*
> > > > + * Some platforms specify the gpio pins for interrupt and reset
> > > > properly
> > > > + * in ACPI, but cannot use the interrupt pin as output due to their
> > > > specific
> > > > + * HW configuration.
> > > > + */
> > > > +static const struct dmi_system_id goodix_no_gpio_pins_support[] = {
> > > > +#if defined(CONFIG_DMI) && defined(CONFIG_X86)
> > > > + {
> > > > + .ident = "Onda v975w",
> > > > + .matches = {
> > > > + DMI_MATCH(DMI_BIOS_VENDOR, "American Megatrends
> > > > Inc."),
> > > > + DMI_MATCH(DMI_PRODUCT_UUID,
> > > > +
> > > > "03000200-0400-0500-0006-000700080009"),
> > > > + DMI_MATCH(DMI_BOARD_VENDOR, "AMI Corporation"),
> > >
RE: [PATCH v7 0/9] Goodix touchscreen enhancements
> -Original Message- > From: linux-input-ow...@vger.kernel.org > [mailto:linux-input-ow...@vger.kernel.org] On Behalf Of Arnd Bergmann > Sent: 08 October, 2015 14:10 > To: Tirdea, Irina > Cc: Dmitry Torokhov; Bastien Nocera; Aleksei Mamlin; > linux-in...@vger.kernel.org; Mark Rutland; Purdila, Octavian; linux- > ker...@vger.kernel.org; devicet...@vger.kernel.org > Subject: Re: [PATCH v7 0/9] Goodix touchscreen enhancements > > On Thursday 08 October 2015 13:19:26 Irina Tirdea wrote: > > Add several enhancements to the Goodix touchscreen driver. > > > > Bastien, the functionality from this patches should be now skipped > > for your devices (Onda v975w, WinBook TW100 and WinBook TW700). > > > > Aleksei, I have removed your Tested-by tag since I have done some > > non-trivial changes to the "reset device at init" patch. > > > > > > I've read over all 9 patches now, most of them look good, but I > commented on the one that I have concerns about. > Thanks for the review, Arnd! Irina > Arnd > -- > To unsubscribe from this list: send the line "unsubscribe linux-input" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v7 2/9] Input: goodix - reset device at init
> -Original Message-
> From: Arnd Bergmann [mailto:a...@arndb.de]
> Sent: 08 October, 2015 13:54
> To: Tirdea, Irina
> Cc: Dmitry Torokhov; Bastien Nocera; Aleksei Mamlin;
> linux-in...@vger.kernel.org; Mark Rutland; Purdila, Octavian; linux-
> ker...@vger.kernel.org; devicet...@vger.kernel.org
> Subject: Re: [PATCH v7 2/9] Input: goodix - reset device at init
>
> On Thursday 08 October 2015 13:19:28 Irina Tirdea wrote:
> > After power on, it is recommended that the driver resets the device.
> > The reset procedure timing is described in the datasheet and is used
> > at device init (before writing device configuration) and
> > for power management. It is a sequence of setting the interrupt
> > and reset pins high/low at specific timing intervals. This procedure
> > also includes setting the slave address to the one specified in the
> > ACPI/device tree.
> >
> > This is based on Goodix datasheets for GT911 and GT9271 and on Goodix
> > driver gt9xx.c for Android (publicly available in Android kernel
> > trees for various devices).
> >
> > For reset the driver needs to control the interrupt and
> > reset gpio pins (configured through ACPI/device tree). For devices
> > that do not have the gpio pins declared, the functionality depending
> > on these pins will not be available, but the device can still be used
> > with basic functionality.
> >
> > For both device tree and ACPI, the interrupt gpio pin configuration is
> > read from the "irq-gpio" property and the reset pin configuration is
> > read from the "reset-gpio" property. For ACPI 5.1, named properties
> > can be specified using the _DSD section. If there is no _DSD section
> > in the ACPI table, the driver will fall back to using indexed gpio
> > pins declared in the _CRS section.
>
> Would it help to use a plain "gpios" property here to always look
> up the lines by index?
>
The problem with ACPI indexed gpios is that platforms declare the
pins in random order. In this case we have some platforms that declare
the interrupt pin first and others that declare the reset pin first.
There is no way to differentiate between them so the only way to support
these platforms is to pick a default and list all exceptions in the driver.
My previous implementation did that with indexed gpios and dmi quirks. [1]
This can be solved by using named gpios, which are available starting with ACPI
5.1.
In this way we know exactly which is the interrupt pin and which is the reset
pin
and we do not need to add any additional exceptions to the driver.
However, we still need to support the platforms that are already out there so
we fall back to indexed gpios.
[1] https://lkml.org/lkml/2015/9/15/609
> > +/*
> > + * Some platforms specify the gpio pins for interrupt and reset properly
> > + * in ACPI, but cannot use the interrupt pin as output due to their
> > specific
> > + * HW configuration.
> > + */
> > +static const struct dmi_system_id goodix_no_gpio_pins_support[] = {
> > +#if defined(CONFIG_DMI) && defined(CONFIG_X86)
> > + {
> > + .ident = "Onda v975w",
> > + .matches = {
> > + DMI_MATCH(DMI_BIOS_VENDOR, "American Megatrends Inc."),
> > + DMI_MATCH(DMI_PRODUCT_UUID,
> > + "03000200-0400-0500-0006-000700080009"),
> > + DMI_MATCH(DMI_BOARD_VENDOR, "AMI Corporation"),
> > + DMI_MATCH(DMI_BOARD_NAME, "Aptio CRB"),
> > + }
> > + },
>
> I think lists like this in drivers should be avoided if at all possible,
> it just leads to other people adding their platform in the lists as
> opposed to fixing their boot loaders.
>
> Can you find another way to detect at runtime whether it works, and
> print a warning if it doesn't?
I agree with you on this, but unfortunately I have not found a better way to do
it.
The main problem comes from the interrupt pin. This device uses the interrupt
pin
as output, which some platforms do not support (either due to the HW
configuration
or due to flagging it wrong in BIOS) [2] [3]. There is no error returned, just
a warning
in dmesg.
[2] https://lkml.org/lkml/2015/9/28/851
[3] https://lkml.org/lkml/2015/9/30/607
> If there is no way to detect that kind
> of device, we should probably have another property that the driver
> can read to determine this, so we can avoid adding each system here.
>
If one or both gpio pins are not declared in ACPI/DT or if gpio initialization
fails,
the driver will work without the functionality that depends on them.
However, this will not wor
RE: [PATCH v5 1/9] Input: goodix - sort includes alphabetically
> -Original Message- > From: Pavel Machek [mailto:pa...@ucw.cz] > Sent: 05 October, 2015 23:58 > To: Tirdea, Irina > Cc: Dmitry Torokhov; Bastien Nocera; Aleksei Mamlin; > linux-in...@vger.kernel.org; Mark Rutland; Purdila, Octavian; linux- > ker...@vger.kernel.org; devicet...@vger.kernel.org > Subject: Re: [PATCH v5 1/9] Input: goodix - sort includes alphabetically > > Hi! > Hi! > > > Subject: Re: [PATCH v5 1/9] Input: goodix - sort includes alphabetically > > > > > > On Mon 2015-09-07 17:36:15, Irina Tirdea wrote: > > > > Signed-off-by: Irina Tirdea > > > > --- > > > > drivers/input/touchscreen/goodix.c | 12 ++-- > > > > 1 file changed, 6 insertions(+), 6 deletions(-) > > > > > > Don't. > > > > > > Yes, we sometimes sort includes... to avoid patch rejects. > > > > > > This is guaranteed to cause rejects. > > > > > > If we do sort them, we use "longest-first" usually. > > > > > > > When using random order, I've been told by reviewers that my ordering > > is wrong [1], but I could not figure out what the "right" ordering is in > > order to apply. > > I did not find any mention of how to sort includes in > > Documentation/CodingStyle, > > but I've seen patches in the kernel that fix random ordering by sorting them > > alphabetically [2]. > > Ok, I have seen this more often: > > https://lkml.org/lkml/2009/3/28/99 > I see. I wasn't aware of the inverse Xmas tree ordering. > > However, I do not feel strongly about this so I can drop this patch. > > Well, its really nit picking. > I was thinking of dropping it since there does not seem to be a consensus on how to order the includes (or even if we should order them). In this case, I guess it's up to Dmitry. I'll use the inverse Xmas tree ordering in next patch set and see if that works for him. Thanks, Irina > > Pavel > -- > (english) http://www.livejournal.com/~pavelmachek > (cesky, pictures) > http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v5 1/9] Input: goodix - sort includes alphabetically
> -Original Message-
> From: Pavel Machek [mailto:pa...@ucw.cz]
> Sent: 04 October, 2015 22:47
> To: Tirdea, Irina
> Cc: Dmitry Torokhov; Bastien Nocera; Aleksei Mamlin;
> linux-in...@vger.kernel.org; Mark Rutland; Purdila, Octavian; linux-
> ker...@vger.kernel.org; devicet...@vger.kernel.org
> Subject: Re: [PATCH v5 1/9] Input: goodix - sort includes alphabetically
>
> On Mon 2015-09-07 17:36:15, Irina Tirdea wrote:
> > Signed-off-by: Irina Tirdea
> > ---
> > drivers/input/touchscreen/goodix.c | 12 ++--
> > 1 file changed, 6 insertions(+), 6 deletions(-)
>
> Don't.
>
> Yes, we sometimes sort includes... to avoid patch rejects.
>
> This is guaranteed to cause rejects.
>
> If we do sort them, we use "longest-first" usually.
>
When using random order, I've been told by reviewers that my ordering
is wrong [1], but I could not figure out what the "right" ordering is in order
to apply.
I did not find any mention of how to sort includes in
Documentation/CodingStyle,
but I've seen patches in the kernel that fix random ordering by sorting them
alphabetically [2].
However, I do not feel strongly about this so I can drop this patch.
Thanks,
Irina
[1] https://lkml.org/lkml/2015/5/28/363
[2] https://patchwork.ozlabs.org/patch/408022/
> >
> > diff --git a/drivers/input/touchscreen/goodix.c
> > b/drivers/input/touchscreen/goodix.c
> > index e36162b..6ae28c5 100644
> > --- a/drivers/input/touchscreen/goodix.c
> > +++ b/drivers/input/touchscreen/goodix.c
> > @@ -14,18 +14,18 @@
> > * Software Foundation; version 2 of the License.
> > */
> >
> > -#include
> > +#include
> > +#include
> > #include
> > #include
> > #include
> > #include
> > -#include
> > -#include
> > -#include
> > #include
> > -#include
> > -#include
> > +#include
> > +#include
> > +#include
> > #include
> > +#include
> > #include
> >
> > struct goodix_ts_data {
> > --
> > 1.9.1
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/
>
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures)
> http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v3 1/5] Input: goodix - reset device at init
> -Original Message- > From: mrgarna...@gmail.com [mailto:mrgarna...@gmail.com] On Behalf Of Carlos > Garnacho > Sent: 30 September, 2015 17:02 > To: Bastien Nocera > Cc: Tirdea, Irina; linux-in...@vger.kernel.org; Cosimo Cecchi; Christian > Hergert; linux-kernel@vger.kernel.org; Rob Herring; Pawel > Moll; Ian Campbell; Kumar Gala; Purdila, Octavian; Dmitry Torokhov; Mark > Rutland; devicet...@vger.kernel.org > Subject: Re: [PATCH v3 1/5] Input: goodix - reset device at init > > Hey, > Hi Carlos and Bastien, Thanks for your help and for testing these patches! > >> > I'm not sure how we can detect, and blacklist, those devices. At > >> > least > >> > my original device, the Onda v975w, and the WinBook TW100 would > >> > have > >> > those problems. > >> > > >> > >> I can use DMI quirks to exclude these devices from using the features > >> that > >> depend on the gpio pins. I already have the DMI information for > >> WinBook TW100 > >> and WinBook TW700. Could you tell me the DMI_SYS_VENDOR and > >> DMI_PRODUCT_NAME for Onda v975w so I can add it as well? > > > > I don't have access to the Onda v975w anymore, but let me CC: a few > > people that could also help with testing. > > > > Carlos, Cosimo, Christian, there's a patchset for you to test on the > > Onda v975w at: > > https://github.com/hadess/gt9xx/commits/irina-tirdea > > > > Doing an "rmmod goodix ; insmod ./goodix_backport.ko" should be enough > > to test whether the patch set works. If it doesn't work correctly, > > you'll need to reboot the machine, swap the irq_idx and rst_idx values > > at: > > https://github.com/hadess/gt9xx/commit/c27de79f494c2b2e7a198ff4d27976ae93669dbd#diff- > dddc2849e36327439530f3e2faacec4fR321 > > > > and try again. > > Unswapped does fail with: > > sep 30 15:37:29 tablet kernel: Goodix-TS i2c-GDIX1001:00: i2c test > failed attempt 1: -121 > sep 30 15:37:29 tablet kernel: Goodix-TS i2c-GDIX1001:00: i2c test > failed attempt 2: -121 > sep 30 15:37:29 tablet kernel: Goodix-TS i2c-GDIX1001:00: I2C > communication failure: -121 > sep 30 15:37:29 tablet kernel: Goodix-TS: probe of i2c-GDIX1001:00 > failed with error -121 > > Swapping the values triggers some errors: > > sep 30 15:48:17 tablet kernel: [ cut here ] > sep 30 15:48:17 tablet kernel: WARNING: CPU: 1 PID: 2341 at > drivers/pinctrl/intel/pinctrl-baytrail.c:342 > byt_gpio_direction_output+0xa1/0xb0() > sep 30 15:48:17 tablet kernel: Potential Error: Setting GPIO with > direct_irq_en to output > sep 30 15:48:17 tablet kernel: Modules linked in: > sep 30 15:48:17 tablet kernel: goodix_backport(OE+) r8723bs(OE) nfsd > lockd grace sunrpc [last unloaded: goodix] > sep 30 15:48:17 tablet kernel: CPU: 1 PID: 2341 Comm: insmod Tainted: > G OE 4.3.0-rc1+ #36 > sep 30 15:48:17 tablet kernel: Hardware name: To be filled by O.E.M. > To be filled by O.E.M./Aptio CRB, BIOS 5.6.5 07/25/2014 > sep 30 15:48:17 tablet kernel: d3f61c08 c13b347f > d3f61c48 d3f61c38 c10a9e1d c20f10e0 > sep 30 15:48:17 tablet kernel: d3f61c64 0925 c20f111c 0156 > c13e7ce1 c13e7ce1 f80580b8 f53a4b0c > sep 30 15:48:17 tablet kernel: 0156 d3f61c50 c10a9e93 0009 > d3f61c48 c20f10e0 d3f61c64 d3f61c78 > sep 30 15:48:17 tablet kernel: Call Trace: > sep 30 15:48:17 tablet kernel: [] dump_stack+0x48/0x69 > sep 30 15:48:17 tablet kernel: [] warn_slowpath_common+0x8d/0xd0 > sep 30 15:48:17 tablet kernel: [] ? > byt_gpio_direction_output+0xa1/0xb0 > sep 30 15:48:17 tablet kernel: [] ? > byt_gpio_direction_output+0xa1/0xb0 > sep 30 15:48:17 tablet kernel: [] warn_slowpath_fmt+0x33/0x40 > sep 30 15:48:17 tablet kernel: [] > byt_gpio_direction_output+0xa1/0xb0 > sep 30 15:48:17 tablet kernel: [] ? byt_gpio_irq_handler+0xb0/0xb0 > sep 30 15:48:17 tablet kernel: [] > _gpiod_direction_output_raw+0x63/0x350 > sep 30 15:48:17 tablet kernel: [] gpiod_direction_output+0x2a/0x50 > sep 30 15:48:17 tablet kernel: [] ? msleep+0x36/0x40 > sep 30 15:48:17 tablet kernel: [] goodix_reset+0x3e/0x90 > [goodix_backport] > sep 30 15:48:17 tablet kernel: [] > goodix_ts_probe+0x12a/0x5aa [goodix_backport] > sep 30 15:48:17 tablet kernel: [] ? acpi_device_wakeup+0x7a/0x80 > sep 30 15:48:17 tablet kernel: [] ? acpi_dev_pm_attach+0x71/0x87 > sep 30 15:48:17 tablet kernel: [] i2c_device_probe+0x121/0x1d0 > sep 30 15:48:17 tablet kernel: [] ? _raw_spin_unlock+0x22/0x30 > sep 30 15:48:17 tablet kernel: [] ? > goodix_config_cb+0xc0/0xc0 [goodix_backport] > sep 30
RE: [PATCH v3 1/5] Input: goodix - reset device at init
> -Original Message- > From: Bastien Nocera [mailto:had...@hadess.net] > Sent: 29 September, 2015 5:04 > To: Tirdea, Irina; linux-in...@vger.kernel.org > Cc: linux-kernel@vger.kernel.org; Rob Herring; Pawel Moll; Ian Campbell; > Kumar Gala; Purdila, Octavian; Dmitry Torokhov; Mark > Rutland; devicet...@vger.kernel.org > Subject: Re: [PATCH v3 1/5] Input: goodix - reset device at init > > On Fri, 2015-09-25 at 21:04 +, Tirdea, Irina wrote: > > > > > > The warning from your dmesg output will not cause probe to fail. > > If you look at the code for byt_gpio_direction_output, it will just > > print > > a warning and continue [1]: > > WARN(readl(conf_reg) & BYT_DIRECT_IRQ_EN, > > "Potential Error: Setting GPIO with direct_irq_en to > > output"); > > I thought probe finishes successfully, but due to the warning in > > dmesg you > > are not sure whether the IRQ GPIO pin can be used as output. > > If probe fails, it must be for another reason than the direct_irq_en > > warning. > > > > > Would you have a patch for me to test that would bypass this error, > > > or > > > at least fallback gracefully to not resetting, not probing GPIOs if > > > they're badly setup? > > > > If the driver fails to initialize the GPIOs, it will at least print > > some > > "Failed to get GPIO" warnings in dmesg. Do you have such messages in > > dmesg or any additional information on why probe fails? > > > > The current code will ignore GPIOs if they are not defined in ACPI > > (see the check for -ENOENT), but does not ignore other error codes. > > If you want to bypass all GPIO errors, you can use the code below. > > The failure isn't there, it's when running goodix_i2c_test(): > Sep 25 16:39:20 winbook kernel: Goodix-TS i2c-GDIX1001:00: i2c test failed > attempt 1: -121 > Sep 25 16:39:20 winbook kernel: Goodix-TS i2c-GDIX1001:00: i2c test failed > attempt 2: -121 > Sep 25 16:39:20 winbook kernel: Goodix-TS i2c-GDIX1001:00: I2C communication > failure: -121 > Sep 25 16:39:20 winbook kernel: Goodix-TS: probe of i2c-GDIX1001:00 failed > with error -121 > Are you using v6 of the patches? There was an issue with reset that Aleksei reported and was fixed in v6 (although he had a different i2c error and a different scenario). > The GPIO setup seems to work (bar the warnings), and the reset as well, > but then the device fails to communicate. Likely a fallout from the > reset actually failing. > > Swapping around the RST and INT pins leads to the same problem. Either > this device's GPIO PINs aren't actually functional, and the firmware > contains garbage, or something else is wrong. > I agree. Either the interrupt pin cannot be used as output in your configuration or there are some specifics in the ACPI tables that prevent using these pins. > I'm not sure how we can detect, and blacklist, those devices. At least > my original device, the Onda v975w, and the WinBook TW100 would have > those problems. > I can use DMI quirks to exclude these devices from using the features that depend on the gpio pins. I already have the DMI information for WinBook TW100 and WinBook TW700. Could you tell me the DMI_SYS_VENDOR and DMI_PRODUCT_NAME for Onda v975w so I can add it as well? Thanks, Irina > Cheers
RE: [PATCH v6 4/9] Input: goodix - write configuration data to device
> -Original Message-
> From: Bastien Nocera [mailto:had...@hadess.net]
> Sent: 25 September, 2015 17:41
> To: Tirdea, Irina; Dmitry Torokhov; Aleksei Mamlin;
> linux-in...@vger.kernel.org
> Cc: Mark Rutland; Purdila, Octavian; linux-kernel@vger.kernel.org;
> devicet...@vger.kernel.org
> Subject: Re: [PATCH v6 4/9] Input: goodix - write configuration data to device
>
> On Tue, 2015-09-15 at 17:31 +0300, Irina Tirdea wrote:
> > Goodix devices can be configured by writing custom data to the device
> > at
> > init. The configuration data is read with request_firmware from
> > "goodix__cfg.bin", where is the product id read from the
> > device
> > (e.g.: goodix_911_cfg.bin for Goodix GT911, goodix_9271_cfg.bin for
> > GT9271).
> >
> > The configuration information has a specific format described in the
> > Goodix
> > datasheet. It includes X/Y resolution, maximum supported touch
> > points,
> > interrupt flags, various sesitivity factors and settings for advanced
>
> sensitivity.
Will fix this in next version of the patches. I will wait for you reply on
the gpio issue before sending a new version.
Thanks,
Irina
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�&j:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
RE: [PATCH v3 1/5] Input: goodix - reset device at init
> -Original Message- > From: Bastien Nocera [mailto:had...@hadess.net] > Sent: 25 September, 2015 17:44 > To: Tirdea, Irina; linux-in...@vger.kernel.org > Cc: linux-kernel@vger.kernel.org; Rob Herring; Pawel Moll; Ian Campbell; > Kumar Gala; Purdila, Octavian; Dmitry Torokhov; Mark > Rutland; devicet...@vger.kernel.org > Subject: Re: [PATCH v3 1/5] Input: goodix - reset device at init > > On Thu, 2015-09-10 at 14:04 +, Tirdea, Irina wrote: > > > > > -Original Message- > > > From: Bastien Nocera [mailto:had...@hadess.net] > > > Sent: 09 September, 2015 20:03 > > > To: Tirdea, Irina; linux-in...@vger.kernel.org > > > Cc: linux-kernel@vger.kernel.org; Rob Herring; Pawel Moll; Ian > > > Campbell; Kumar Gala; Purdila, Octavian; Dmitry Torokhov; Mark > > > Rutland; devicet...@vger.kernel.org > > > Subject: Re: [PATCH v3 1/5] Input: goodix - reset device at init > > > > > > On Thu, 2015-07-30 at 11:27 +, Tirdea, Irina wrote: > > > > I can send some additional patches that will simplify testing the > > > > configuration update to the Goodix device. I think this feature > > > > is > > > > the easiest > > > > to test so we can determine if writing to the interrupt pin > > > > actually > > > > works. > > > > However, even if it is a BIOS problem and the code will work, the > > > > warning > > > > will still be printed in dmesg. > > > > > > > > > Somehow missed this mail before replying to the current patchset. > > > I'd > > > be fine with that, though it's still not clear to me whether the > > > BIOS/hardware is at fault, or the code that's being added to the > > > driver > > > ;) > > > > > > > The reset procedure is described in the Goodix GT911 datasheet [1] > > and is > > used for power-on reset and power management. The power-on sequence > > is described in chapter 6.1. I2C Timing, in the Power-on Timing > > diagram. > > The sequence for putting the device to sleep is described in chapter > > 7.1. Operating Modes, c) Sleep mode. These sequences use the > > interrupt > > pin as output. > > > > The warning you mentioned comes from the following code in the goodix > > driver, which sets the interrupt to be used as output: > > > > + error = gpiod_direction_output(ts->gpiod_int, ts->client- > > >addr == 0x14); > > > > The gpiod_direction_output() call ends up in > > drivers/pinctrl/intel/pinctrl-baytrail.c: > > /* > > * Before making any direction modifications, do a check if gpio > > * is set for direct IRQ. On baytrail, setting GPIO to output does > > * not make sense, so let's at least warn the caller before they > > shoot > > * themselves in the foot. > > */ > > WARN(readl(conf_reg) & BYT_DIRECT_IRQ_EN, > > "Potential Error: Setting GPIO with direct_irq_en to output"); > > > > So the problem comes from using the gpio interrupt pin as output, > > which > > should not work on Baytrail if BYT_DIRECT_IRQ_EN is set by BIOS. > > The above warning is introduced and discussed in [2] and [3]. As I > > mentioned, > > this could be a real HW issue or the BIOS sets BYT_DIRECT_IRQ_EN when > > it should not. I have also tested these patches on a Baytrail > > plarform > > (that uses the same pinctrl driver), but I did not see any issues > > since > > BYT_DIRECT_IRQ_EN is not set in my case for the interrupt gpio pin. > > Do we have a way to work-around this in the GPIO driver? > > > To determine if using the interrupt pin as output works, you can test > > updating > > the goodix configuration [4]. > > Right, the problem being that it's a later patch in the branch, and > that the driver will fail to probe if there's an error from the GPIO > call. > The warning from your dmesg output will not cause probe to fail. If you look at the code for byt_gpio_direction_output, it will just print a warning and continue [1]: WARN(readl(conf_reg) & BYT_DIRECT_IRQ_EN, "Potential Error: Setting GPIO with direct_irq_en to output"); I thought probe finishes successfully, but due to the warning in dmesg you are not sure whether the IRQ GPIO pin can be used as output. If probe fails, it must be for another reason than the direct_irq_en warning. > Would you have a patch for me to test that would bypass this error, or > at least fallback gracefully to not resetting, not probing GPIOs if > they're bad
RE: [PATCH v3 3/4] iio: bmc150: Split the driver into core and i2c
> -Original Message-
> From: Markus Pargmann [mailto:m...@pengutronix.de]
> Sent: 21 September, 2015 13:55
> To: Jonathan Cameron
> Cc: Srinivas Pandruvada; Tirdea, Irina; Lars-Peter Clausen;
> linux-...@vger.kernel.org; linux-kernel@vger.kernel.org;
> ker...@pengutronix.de; Markus Pargmann
> Subject: [PATCH v3 3/4] iio: bmc150: Split the driver into core and i2c
>
> Signed-off-by: Markus Pargmann
Tested-by: Irina Tirdea
> ---
> drivers/iio/accel/Kconfig | 9 +-
> drivers/iio/accel/Makefile | 3 +-
> .../accel/{bmc150-accel.c => bmc150-accel-core.c} | 85 -
> drivers/iio/accel/bmc150-accel-i2c.c | 102
> +
> drivers/iio/accel/bmc150-accel.h | 20
> 5 files changed, 145 insertions(+), 74 deletions(-)
> rename drivers/iio/accel/{bmc150-accel.c => bmc150-accel-core.c} (96%)
> create mode 100644 drivers/iio/accel/bmc150-accel-i2c.c
> create mode 100644 drivers/iio/accel/bmc150-accel.h
>
> diff --git a/drivers/iio/accel/Kconfig b/drivers/iio/accel/Kconfig
> index 3ff2c83f7492..280635545240 100644
> --- a/drivers/iio/accel/Kconfig
> +++ b/drivers/iio/accel/Kconfig
> @@ -19,21 +19,22 @@ config BMA180
>
> config BMC150_ACCEL
> tristate "Bosch BMC150 Accelerometer Driver"
> - depends on I2C
> select IIO_BUFFER
> select IIO_TRIGGERED_BUFFER
> select REGMAP
> - select REGMAP_I2C
> + select BMC150_ACCEL_I2C if I2C
> help
> Say yes here to build support for the following Bosch accelerometers:
> BMC150, BMI055, BMA250E, BMA222E, BMA255, BMA280.
>
> - Currently this only supports the device via an i2c interface.
> -
> This is a combo module with both accelerometer and magnetometer.
> This driver is only implementing accelerometer part, which has
> its own address and register map.
>
> +config BMC150_ACCEL_I2C
> + tristate
> + select REGMAP_I2C
> +
> config HID_SENSOR_ACCEL_3D
> depends on HID_SENSOR_HUB
> select IIO_BUFFER
> diff --git a/drivers/iio/accel/Makefile b/drivers/iio/accel/Makefile
> index ebd2675b2a02..5ef8bdbad092 100644
> --- a/drivers/iio/accel/Makefile
> +++ b/drivers/iio/accel/Makefile
> @@ -4,7 +4,8 @@
>
> # When adding new entries keep the list in alphabetical order
> obj-$(CONFIG_BMA180) += bma180.o
> -obj-$(CONFIG_BMC150_ACCEL) += bmc150-accel.o
> +obj-$(CONFIG_BMC150_ACCEL) += bmc150-accel-core.o
> +obj-$(CONFIG_BMC150_ACCEL_I2C) += bmc150-accel-i2c.o
> obj-$(CONFIG_HID_SENSOR_ACCEL_3D) += hid-sensor-accel-3d.o
> obj-$(CONFIG_KXCJK1013) += kxcjk-1013.o
> obj-$(CONFIG_KXSD9) += kxsd9.o
> diff --git a/drivers/iio/accel/bmc150-accel.c
> b/drivers/iio/accel/bmc150-accel-core.c
> similarity index 96%
> rename from drivers/iio/accel/bmc150-accel.c
> rename to drivers/iio/accel/bmc150-accel-core.c
> index 425885dc6800..f492d2a4bce5 100644
> --- a/drivers/iio/accel/bmc150-accel.c
> +++ b/drivers/iio/accel/bmc150-accel-core.c
> @@ -37,6 +37,8 @@
> #include
> #include
>
> +#include "bmc150-accel.h"
> +
> #define BMC150_ACCEL_DRV_NAME"bmc150_accel"
> #define BMC150_ACCEL_IRQ_NAME"bmc150_accel_event"
> #define BMC150_ACCEL_GPIO_NAME "bmc150_accel_int"
> @@ -1015,15 +1017,6 @@ static const struct iio_chan_spec
> bmc150_accel_channels[] =
> static const struct iio_chan_spec bma280_accel_channels[] =
> BMC150_ACCEL_CHANNELS(14);
>
> -enum {
> - bmc150,
> - bmi055,
> - bma255,
> - bma250e,
> - bma222e,
> - bma280,
> -};
> -
> static const struct bmc150_accel_chip_info bmc150_accel_chip_info_tbl[] = {
> [bmc150] = {
> .name = "BMC150A",
> @@ -1576,33 +1569,23 @@ static int bmc150_accel_chip_init(struct
> bmc150_accel_data *data)
> return 0;
> }
>
> -static int bmc150_accel_probe(struct i2c_client *client,
> - const struct i2c_device_id *id)
> +int bmc150_accel_core_probe(struct device *dev, struct regmap *regmap, int
> irq,
> + const char *name, bool block_supported)
> {
> struct bmc150_accel_data *data;
> struct iio_dev *indio_dev;
> int ret;
> - const char *name = NULL;
> - struct device *dev;
>
> - indio_dev = devm_iio_device_alloc(&client->dev, sizeof(*data));
> + indio_dev = devm_iio_device_alloc(dev, sizeof(*data));
> if (!indio_dev)
> return -ENOMEM;
>
>
RE: [PATCH v3 1/4] iio: bmc150: Use i2c regmap
> -Original Message-
> From: Markus Pargmann [mailto:m...@pengutronix.de]
> Sent: 21 September, 2015 13:55
> To: Jonathan Cameron
> Cc: Srinivas Pandruvada; Tirdea, Irina; Lars-Peter Clausen;
> linux-...@vger.kernel.org; linux-kernel@vger.kernel.org;
> ker...@pengutronix.de; Markus Pargmann
> Subject: [PATCH v3 1/4] iio: bmc150: Use i2c regmap
>
> This replaces all usage of direct i2c accesses with regmap accesses.
>
> Signed-off-by: Markus Pargmann
Tested-by: Irina Tirdea
> ---
> drivers/iio/accel/Kconfig| 2 +
> drivers/iio/accel/bmc150-accel.c | 225
> +--
> 2 files changed, 99 insertions(+), 128 deletions(-)
>
> diff --git a/drivers/iio/accel/Kconfig b/drivers/iio/accel/Kconfig
> index a59047d7657e..3ff2c83f7492 100644
> --- a/drivers/iio/accel/Kconfig
> +++ b/drivers/iio/accel/Kconfig
> @@ -22,6 +22,8 @@ config BMC150_ACCEL
> depends on I2C
> select IIO_BUFFER
> select IIO_TRIGGERED_BUFFER
> + select REGMAP
> + select REGMAP_I2C
> help
> Say yes here to build support for the following Bosch accelerometers:
> BMC150, BMI055, BMA250E, BMA222E, BMA255, BMA280.
> diff --git a/drivers/iio/accel/bmc150-accel.c
> b/drivers/iio/accel/bmc150-accel.c
> index 0104cdef8709..a17034fd53fb 100644
> --- a/drivers/iio/accel/bmc150-accel.c
> +++ b/drivers/iio/accel/bmc150-accel.c
> @@ -35,6 +35,7 @@
> #include
> #include
> #include
> +#include
>
> #define BMC150_ACCEL_DRV_NAME"bmc150_accel"
> #define BMC150_ACCEL_IRQ_NAME"bmc150_accel_event"
> @@ -186,6 +187,8 @@ enum bmc150_accel_trigger_id {
>
> struct bmc150_accel_data {
> struct i2c_client *client;
> + struct regmap *regmap;
> + struct device *dev;
> struct bmc150_accel_interrupt interrupts[BMC150_ACCEL_INTERRUPTS];
> atomic_t active_intr;
> struct bmc150_accel_trigger triggers[BMC150_ACCEL_TRIGGERS];
> @@ -242,6 +245,12 @@ static const struct {
> {50, BMC150_ACCEL_SLEEP_500_MS},
> {100, BMC150_ACCEL_SLEEP_1_SEC} };
>
> +static const struct regmap_config bmc150_i2c_regmap_conf = {
> + .reg_bits = 8,
> + .val_bits = 8,
> + .max_register = 0x3f,
> +};
> +
> static int bmc150_accel_set_mode(struct bmc150_accel_data *data,
>enum bmc150_power_modes mode,
>int dur_us)
> @@ -271,8 +280,7 @@ static int bmc150_accel_set_mode(struct bmc150_accel_data
> *data,
>
> dev_dbg(&data->client->dev, "Set Mode bits %x\n", lpw_bits);
>
> - ret = i2c_smbus_write_byte_data(data->client,
> - BMC150_ACCEL_REG_PMU_LPW, lpw_bits);
> + ret = regmap_write(data->regmap, BMC150_ACCEL_REG_PMU_LPW, lpw_bits);
> if (ret < 0) {
> dev_err(&data->client->dev, "Error writing reg_pmu_lpw\n");
> return ret;
> @@ -290,8 +298,7 @@ static int bmc150_accel_set_bw(struct bmc150_accel_data
> *data, int val,
> for (i = 0; i < ARRAY_SIZE(bmc150_accel_samp_freq_table); ++i) {
> if (bmc150_accel_samp_freq_table[i].val == val &&
> bmc150_accel_samp_freq_table[i].val2 == val2) {
> - ret = i2c_smbus_write_byte_data(
> - data->client,
> + ret = regmap_write(data->regmap,
> BMC150_ACCEL_REG_PMU_BW,
> bmc150_accel_samp_freq_table[i].bw_bits);
> if (ret < 0)
> @@ -308,26 +315,19 @@ static int bmc150_accel_set_bw(struct bmc150_accel_data
> *data, int val,
>
> static int bmc150_accel_update_slope(struct bmc150_accel_data *data)
> {
> - int ret, val;
> + int ret;
>
> - ret = i2c_smbus_write_byte_data(data->client, BMC150_ACCEL_REG_INT_6,
> + ret = regmap_write(data->regmap, BMC150_ACCEL_REG_INT_6,
> data->slope_thres);
> if (ret < 0) {
> dev_err(&data->client->dev, "Error writing reg_int_6\n");
> return ret;
> }
>
> - ret = i2c_smbus_read_byte_data(data->client, BMC150_ACCEL_REG_INT_5);
> + ret = regmap_update_bits(data->regmap, BMC150_ACCEL_REG_INT_5,
> + BMC150_ACCEL_SLOPE_DUR_MASK, data->slope_dur);
> if (ret < 0) {
> - dev_err(&data->client->dev, "Error reading reg_int
RE: [PATCH v3 2/4] iio: bcm150: Remove i2c_client from private data
> -Original Message-
> From: Markus Pargmann [mailto:m...@pengutronix.de]
> Sent: 21 September, 2015 13:55
> To: Jonathan Cameron
> Cc: Srinivas Pandruvada; Tirdea, Irina; Lars-Peter Clausen;
> linux-...@vger.kernel.org; linux-kernel@vger.kernel.org;
> ker...@pengutronix.de; Markus Pargmann
> Subject: [PATCH v3 2/4] iio: bcm150: Remove i2c_client from private data
>
> i2c_client struct is now only used for debugging output. We can use the
> device struct as well so we can remove all struct i2c_client usage.
>
> Signed-off-by: Markus Pargmann
> Acked-by: Jonathan Cameron
Tested-by: Irina Tirdea
> ---
> drivers/iio/accel/bmc150-accel.c | 116
> +++
> 1 file changed, 56 insertions(+), 60 deletions(-)
>
> diff --git a/drivers/iio/accel/bmc150-accel.c
> b/drivers/iio/accel/bmc150-accel.c
> index a17034fd53fb..425885dc6800 100644
> --- a/drivers/iio/accel/bmc150-accel.c
> +++ b/drivers/iio/accel/bmc150-accel.c
> @@ -186,9 +186,9 @@ enum bmc150_accel_trigger_id {
> };
>
> struct bmc150_accel_data {
> - struct i2c_client *client;
> struct regmap *regmap;
> struct device *dev;
> + int irq;
> struct bmc150_accel_interrupt interrupts[BMC150_ACCEL_INTERRUPTS];
> atomic_t active_intr;
> struct bmc150_accel_trigger triggers[BMC150_ACCEL_TRIGGERS];
> @@ -278,11 +278,11 @@ static int bmc150_accel_set_mode(struct
> bmc150_accel_data *data,
> lpw_bits = mode << BMC150_ACCEL_PMU_MODE_SHIFT;
> lpw_bits |= (dur_val << BMC150_ACCEL_PMU_BIT_SLEEP_DUR_SHIFT);
>
> - dev_dbg(&data->client->dev, "Set Mode bits %x\n", lpw_bits);
> + dev_dbg(data->dev, "Set Mode bits %x\n", lpw_bits);
>
> ret = regmap_write(data->regmap, BMC150_ACCEL_REG_PMU_LPW, lpw_bits);
> if (ret < 0) {
> - dev_err(&data->client->dev, "Error writing reg_pmu_lpw\n");
> + dev_err(data->dev, "Error writing reg_pmu_lpw\n");
> return ret;
> }
>
> @@ -320,18 +320,18 @@ static int bmc150_accel_update_slope(struct
> bmc150_accel_data *data)
> ret = regmap_write(data->regmap, BMC150_ACCEL_REG_INT_6,
> data->slope_thres);
> if (ret < 0) {
> - dev_err(&data->client->dev, "Error writing reg_int_6\n");
> + dev_err(data->dev, "Error writing reg_int_6\n");
> return ret;
> }
>
> ret = regmap_update_bits(data->regmap, BMC150_ACCEL_REG_INT_5,
>BMC150_ACCEL_SLOPE_DUR_MASK, data->slope_dur);
> if (ret < 0) {
> - dev_err(&data->client->dev, "Error updating reg_int_5\n");
> + dev_err(data->dev, "Error updating reg_int_5\n");
> return ret;
> }
>
> - dev_dbg(&data->client->dev, "%s: %x %x\n", __func__, data->slope_thres,
> + dev_dbg(data->dev, "%s: %x %x\n", __func__, data->slope_thres,
> data->slope_dur);
>
> return ret;
> @@ -380,17 +380,17 @@ static int bmc150_accel_set_power_state(struct
> bmc150_accel_data *data, bool on)
> int ret;
>
> if (on) {
> - ret = pm_runtime_get_sync(&data->client->dev);
> + ret = pm_runtime_get_sync(data->dev);
> } else {
> - pm_runtime_mark_last_busy(&data->client->dev);
> - ret = pm_runtime_put_autosuspend(&data->client->dev);
> + pm_runtime_mark_last_busy(data->dev);
> + ret = pm_runtime_put_autosuspend(data->dev);
> }
>
> if (ret < 0) {
> - dev_err(&data->client->dev,
> + dev_err(data->dev,
> "Failed: bmc150_accel_set_power_state for %d\n", on);
> if (on)
> - pm_runtime_put_noidle(&data->client->dev);
> + pm_runtime_put_noidle(data->dev);
>
> return ret;
> }
> @@ -473,7 +473,7 @@ static int bmc150_accel_set_interrupt(struct
> bmc150_accel_data *data, int i,
> ret = regmap_update_bits(data->regmap, info->map_reg, info->map_bitmask,
>(state ? info->map_bitmask : 0));
> if (ret < 0) {
> - dev_err(&data->client->dev, "Error updating reg_int_map\n");
> + dev_err(data->dev, "Error updating reg_int_map\n");
> goto out_fix_power_
RE: [PATCH v3 0/4] iio: bmc150 regmap and SPI
> -Original Message-
> From: Markus Pargmann [mailto:m...@pengutronix.de]
> Sent: 21 September, 2015 13:55
> To: Jonathan Cameron
> Cc: Srinivas Pandruvada; Tirdea, Irina; Lars-Peter Clausen;
> linux-...@vger.kernel.org; linux-kernel@vger.kernel.org;
> ker...@pengutronix.de; Markus Pargmann
> Subject: [PATCH v3 0/4] iio: bmc150 regmap and SPI
>
> Hi,
>
Hi Markus,
I tested the new version of you patches and everything works fine.
I used a BMA250E chip connected on the i2c bus.
The tests included the iio buffer code path and the i2c code path
(including using the fifo and forcing the i2c bus to use
the regmap_i2c_smbus_i2c_block calls you added to regmap).
> this series converts the bmc150 driver to use regmap and adds an SPI
> interface.
>
> Thanks for testing and review so far. I rebased the series onto v4.3-rc2 now
> (the togreg branch seems to be on v4.2).
> It still works for me but there were some differences regarding the chip id.
>
I actually used the togreg branch (to get the latest bmc150 driver changes) and
cherry-picked the regmap patches. Everything applied without any conflicts.
Thanks,
Irina
> Changes in v3:
> - Fixed type of variable 'step' which lead to compile warnings. Type is now
> size_t.
> - Fixed patch that moved irq variable without reason
> - Readded MODULE_* to the core driver
> - Reintroduced check id NULL check
>
> Changes in v2:
> - Removed default values for regmap_config fields.
> - Redesigned the fifo_transfer function to avoid running in errors first.
> - Dropped irq checks patch as it is already mainline
> - Core can now be built as module with autoselection of i2c and spi parts
>
> As my hardware is missing an interrupt line from the SPI connected bmc150 I am
> not able to test the iio buffer code path and the i2c code path. Tests would
> be
> appreciated.
>
> @Srinivas:
> As there were some rebase conflicts on the first patch, I removed your
> reviewed-by tag again for the moment.
>
> Best regards,
>
> Markus
>
>
> Markus Pargmann (4):
> iio: bmc150: Use i2c regmap
> iio: bcm150: Remove i2c_client from private data
> iio: bmc150: Split the driver into core and i2c
> iio: bmc150: Add SPI driver
>
> drivers/iio/accel/Kconfig | 14 +-
> drivers/iio/accel/Makefile | 4 +-
> .../accel/{bmc150-accel.c => bmc150-accel-core.c} | 388
> -
> drivers/iio/accel/bmc150-accel-i2c.c | 102 ++
> drivers/iio/accel/bmc150-accel-spi.c | 80 +
> drivers/iio/accel/bmc150-accel.h | 20 ++
> 6 files changed, 366 insertions(+), 242 deletions(-)
> rename drivers/iio/accel/{bmc150-accel.c => bmc150-accel-core.c} (82%)
> create mode 100644 drivers/iio/accel/bmc150-accel-i2c.c
> create mode 100644 drivers/iio/accel/bmc150-accel-spi.c
> create mode 100644 drivers/iio/accel/bmc150-accel.h
>
> --
> 2.5.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v2 0/4] iio: bmc150 regmap and SPI
> -Original Message-
> From: Markus Pargmann [mailto:m...@pengutronix.de]
> Sent: 16 September, 2015 13:13
> To: Tirdea, Irina
> Cc: Jonathan Cameron; Srinivas Pandruvada; Lars-Peter Clausen;
> linux-...@vger.kernel.org; linux-kernel@vger.kernel.org;
> ker...@pengutronix.de
> Subject: Re: [PATCH v2 0/4] iio: bmc150 regmap and SPI
>
> Hi Irina,
>
> On Wed, Sep 09, 2015 at 02:30:30PM +, Tirdea, Irina wrote:
> >
> >
> > > -Original Message-
> > > From: Markus Pargmann [mailto:m...@pengutronix.de]
> > > Sent: 20 August, 2015 15:50
> > > To: Jonathan Cameron
> > > Cc: Srinivas Pandruvada; Tirdea, Irina; Lars-Peter Clausen;
> > > linux-...@vger.kernel.org; linux-kernel@vger.kernel.org;
> > > ker...@pengutronix.de; Markus Pargmann
> > > Subject: [PATCH v2 0/4] iio: bmc150 regmap and SPI
> > >
> > > Hi,
> > >
> >
> > Hi Markus,
> >
> > I tested your patches with my BMA250E driver connected on the i2c bus .
> > The code looks good and most of it works. There are a couple of issues I
> > will mention
> > below and in the individual patches.
> >
> > The patches in this version no longer apply cleanly on the togreg branch of
> > the iio tree.
> > I did the rebase myself, but since there were many conflicts I will do
> > another test
> > when you send the new rebased v3.
>
> Thank you for review and testing. I will integrate your comments and
> send a rebased v3.
>
> >
> > > this series converts the bmc150 driver to use regmap and adds an SPI
> > > interface.
> > >
> > > In v1 this was part of the series "Regmap max_raw_io and bmc150 SPI
> > > support".
> > > It now depends on "regmap: i2c block support".
> > >
> >
> > I used the patches that were already merged in the regmap tree. This bmc150
> > series should
> > probably wait until the regmap patches end up in Jonathan's tree, otherwise
> > they will
> > break the build.
>
> It seems the necessary patches are already in v4.3-rc1:
> 29332534e2b6 (regmap-i2c: Add smbus i2c block support)
>
AFAIK, Jonathan waits until changes from the main kernel get merged back
into his togreg branch. Since you are using regmap_get_raw_read_max that
is introduced in the regmap patches, the driver won't build without them
(if they are merged now in the iio tree).
However, that does not prevent me from testing the changes using
the regmap changes from v4.3-rc1.
Thanks,
Irina
> Best Regards,
>
> Markus
>
> >
> > Thanks,
> > Irina
> >
> > > Changes in v2:
> > > - Removed default values for regmap_config fields.
> > > - Redesigned the fifo_transfer function to avoid running in errors first.
> > > - Dropped irq checks patch as it is already mainline
> > > - Core can now be built as module with autoselection of i2c and spi parts
> > >
> > > As my hardware is missing an interrupt line from the SPI connected bmc150
> > > I am
> > > not able to test the iio buffer code path and the i2c code path. Tests
> > > would be
> > > appreciated.
> > >
> > > Best regards,
> > >
> > > Markus
> > >
> > >
> > > Markus Pargmann (4):
> > > iio: bmc150: Use i2c regmap
> > > iio: bcm150: Remove i2c_client from private data
> > > iio: bmc150: Split the driver into core and i2c
> > > iio: bmc150: Add SPI driver
> > >
> > > drivers/iio/accel/Kconfig | 14 +-
> > > drivers/iio/accel/Makefile | 4 +-
> > > .../accel/{bmc150-accel.c => bmc150-accel-core.c} | 398
> > > -
> > > drivers/iio/accel/bmc150-accel-i2c.c | 99 +
> > > drivers/iio/accel/bmc150-accel-spi.c | 83 +
> > > drivers/iio/accel/bmc150-accel.h | 21 ++
> > > 6 files changed, 367 insertions(+), 252 deletions(-)
> > > rename drivers/iio/accel/{bmc150-accel.c => bmc150-accel-core.c} (81%)
> > > create mode 100644 drivers/iio/accel/bmc150-accel-i2c.c
> > > create mode 100644 drivers/iio/accel/bmc150-accel-spi.c
> > > create mode 100644 drivers/iio/accel/bmc150-accel.h
> > >
> > > --
> > > 2.4.6
> >
> >
>
> --
> Pengutronix e.K. | |
> Industrial Linux Solutions | http://www.pengutronix.de/ |
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
RE: [PATCH v3] Add generic driver for Silead tochscreens
> -Original Message- > From: linux-input-ow...@vger.kernel.org > [mailto:linux-input-ow...@vger.kernel.org] On Behalf Of Robert Dolca > Sent: 26 August, 2015 0:32 > To: linux-in...@vger.kernel.org > Cc: linux-kernel@vger.kernel.org; Dmitry Torokhov; Henrik Rydberg; Gregor > Riepl; Dolca, Robert > Subject: [PATCH v3] Add generic driver for Silead tochscreens > > This driver adds support for Silead touchscreens. It has been tested > with GSL1680 and GSL3680 touch panels. > > It supports ACPI and device tree enumeration. Screen resolution, > the maximum number of fingers supported and firmware name are > configurable using ACPI/DT properties. > > If the device properties are not present it falls back to using defaults: > - x 4095 > - y 4095 > - max fingers 10 > - firmware name [HID/name].fw > > If there is no named GPIO for power it falls back to using an indexed GPIO > and it requests the GPIO pin with index 1. If there isn't one it disables > PM support. > > All the hardware variants tested report finger id 0 for all fingers so > the finger tracking is done using the input subsystem's slot assignment. > > Signed-off-by: Robert Dolca Hi Robert, The code looks good, just a couple of comments below. > --- > Changes since v2 > - removed device properties requirements > - max x and y default to 4095 > - max fingers default to 10 > - firmware name uses the HID / device name > - power named GPIO optional with fallback to indexed GPIO > (without it there is no pm support in the driver) > - finger tracking in the kernel using slot assignment > - add device property for x/y inverting and xy swaping > > Changes since v1 > - changed device tree properties names > - removed cast for `void *id` > - removed ifdef from suspend and resume and use __maybe_unused > - remove ifdef from ACPI_PTR > - renamed ret to error > - removed input_set_capability for EV_ABS > - fixed endianess issues > - added mask for y in order to use only 12 bits > - using the 4 MSb for touch ID instead of LSb (bug) > - using the 4 LSB for X instead of MSb (bug) > > > > drivers/input/touchscreen/Kconfig | 12 + > drivers/input/touchscreen/Makefile | 1 + > drivers/input/touchscreen/silead.c | 635 > + > 3 files changed, 648 insertions(+) > create mode 100644 drivers/input/touchscreen/silead.c > > diff --git a/drivers/input/touchscreen/Kconfig > b/drivers/input/touchscreen/Kconfig > index 80f6386..05fda4a 100644 > --- a/drivers/input/touchscreen/Kconfig > +++ b/drivers/input/touchscreen/Kconfig > @@ -1027,4 +1027,16 @@ config TOUCHSCREEN_ZFORCE > To compile this driver as a module, choose M here: the > module will be called zforce_ts. > > +config TOUCHSCREEN_SILEAD > + tristate "Silead I2C touchscreen" > + depends on I2C > + help > + Say Y here if you have the Silead touchscreen connected to > + your system. > + > + If unsure, say N. > + > + To compile this driver as a module, choose M here: the > + module will be called silead. > + > endif > diff --git a/drivers/input/touchscreen/Makefile > b/drivers/input/touchscreen/Makefile > index 44deea7..2c6beaa 100644 > --- a/drivers/input/touchscreen/Makefile > +++ b/drivers/input/touchscreen/Makefile > @@ -84,3 +84,4 @@ obj-$(CONFIG_TOUCHSCREEN_W90X900) += w90p910_ts.o > obj-$(CONFIG_TOUCHSCREEN_SX8654) += sx8654.o > obj-$(CONFIG_TOUCHSCREEN_TPS6507X) += tps6507x-ts.o > obj-$(CONFIG_TOUCHSCREEN_ZFORCE) += zforce_ts.o > +obj-$(CONFIG_TOUCHSCREEN_SILEAD) += silead.o > diff --git a/drivers/input/touchscreen/silead.c > b/drivers/input/touchscreen/silead.c > new file mode 100644 > index 000..5339f93 > --- /dev/null > +++ b/drivers/input/touchscreen/silead.c > @@ -0,0 +1,635 @@ > +/* - > + * Copyright (C) 2014-2015, Intel Corporation > + * > + * Derived from: > + * gslX68X.c > + * Copyright (C) 2010-2015, Shanghai Sileadinc Co.Ltd > + * > + * This program is free software; you can redistribute it and/or modify > + * it under the terms of the GNU General Public License as published by > + * the Free Software Foundation; either version 2 of the License, or > + * (at your option) any later version. > + * > + * This program is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + * GNU General Public License for more details. > + * - > */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#define SILEAD_TS_NAME "silead_ts" > + > +#define SILEAD_REG_RESET 0xE0 > +#define SILEAD_REG_DATA 0x80 > +#define SILEAD_REG_TOUCH_N
RE: [PATCH v5 3/9] Input: goodix - reset device at init
> -Original Message-
> From: Aleksei Mamlin [mailto:mamli...@gmail.com]
> Sent: 15 September, 2015 12:48
> To: Tirdea, Irina
> Cc: Dmitry Torokhov; Bastien Nocera; linux-in...@vger.kernel.org; Mark
> Rutland; Purdila, Octavian; linux-kernel@vger.kernel.org;
> devicet...@vger.kernel.org
> Subject: Re: [PATCH v5 3/9] Input: goodix - reset device at init
>
> On Mon, 7 Sep 2015 17:36:17 +0300
> Irina Tirdea wrote:
>
> > After power on, it is recommended that the driver resets the device.
> > The reset procedure timing is described in the datasheet and is used
> > at device init (before writing device configuration) and
> > for power management. It is a sequence of setting the interrupt
> > and reset pins high/low at specific timing intervals. This procedure
> > also includes setting the slave address to the one specified in the
> > ACPI/device tree.
> >
> > This is based on Goodix datasheets for GT911 and GT9271 and on Goodix
> > driver gt9xx.c for Android (publicly available in Android kernel
> > trees for various devices).
> >
> > For reset the driver needs to control the interrupt and
> > reset gpio pins (configured through ACPI/device tree). For devices
> > that do not have the gpio pins declared, the functionality depending
> > on these pins will not be available, but the device can still be used
> > with basic functionality.
> >
> > Signed-off-by: Octavian Purdila
> > Signed-off-by: Irina Tirdea
> > ---
> > .../bindings/input/touchscreen/goodix.txt | 5 +
> > drivers/input/touchscreen/goodix.c | 136
> > +
> > 2 files changed, 141 insertions(+)
> >
> > +/**
> > + * goodix_reset - Reset device during power on
> > + *
> > + * @ts: goodix_ts_data pointer
> > + */
> > +static int goodix_reset(struct goodix_ts_data *ts)
> > +{
> > + int error;
> > +
> > + /* begin select I2C slave addr */
> > + error = gpiod_direction_output(ts->gpiod_rst, 0);
> > + if (error)
> > + return error;
> > + msleep(20); /* T2: > 10ms */
> > + /* HIGH: 0x28/0x29, LOW: 0xBA/0xBB */
> > + error = gpiod_direction_output(ts->gpiod_int, ts->client->addr == 0x14);
> > + if (error)
> > + return error;
> > + usleep_range(100, 2000);/* T3: > 100us */
> > + error = gpiod_direction_output(ts->gpiod_rst, 1);
> > + if (error)
> > + return error;
> > + usleep_range(6000, 1); /* T4: > 5ms */
> > + /* end select I2C slave addr */
> > + error = gpiod_direction_input(ts->gpiod_rst);
> > + if (error)
> > + return error;
> > + return goodix_int_sync(ts);
> > +}
> > +
> > /**
> > * goodix_read_config - Read the embedded configuration of the panel
> > *
> > @@ -419,6 +542,19 @@ static int goodix_ts_probe(struct i2c_client *client,
> >
> > ts->cfg_len = goodix_get_cfg_len(id_info);
> >
> > + error = goodix_get_gpio_config(ts, id);
> > + if (error)
> > + return error;
> > +
> > + if (ts->gpiod_int && ts->gpiod_rst) {
> > + /* reset the controller */
> > + error = goodix_reset(ts);
> > + if (error) {
> > + dev_err(&client->dev, "Controller reset failed.\n");
> > + return error;
> > + }
> > + }
> > +
>
> On devices with devicetree, such as ARM tablets, we can set I2C address via
> DT, so driver should reset controller and set right address.
> If we don't do this we get "I2C communication failure: -6".
>
This is exactly what this patch tries to do. The address set in ACPI or DT will
be available
in ts->client->addr. The reset code checks for the address set by ACPI/DT and
configures
the device to use that address.
> Also, most of touchscreen drivers tries to reset controllers before start
> communicating, so we need do the same.
Good catch! goodix_reset should be called before goodix_i2c_test. I'll send a
new version with this fix.
Thanks,
Irina
>
> > goodix_read_config(ts);
> >
> > error = goodix_request_input_dev(ts, version_info, id_info);
> > --
> > 1.9.1
> >
>
>
> --
> Thanks and regards,
> Aleksei Mamlin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v3 1/5] Input: goodix - reset device at init
> -Original Message-
> From: Bastien Nocera [mailto:had...@hadess.net]
> Sent: 09 September, 2015 20:03
> To: Tirdea, Irina; linux-in...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org; Rob Herring; Pawel Moll; Ian Campbell;
> Kumar Gala; Purdila, Octavian; Dmitry Torokhov; Mark
> Rutland; devicet...@vger.kernel.org
> Subject: Re: [PATCH v3 1/5] Input: goodix - reset device at init
>
> On Thu, 2015-07-30 at 11:27 +, Tirdea, Irina wrote:
> > I can send some additional patches that will simplify testing the
> > configuration update to the Goodix device. I think this feature is
> > the easiest
> > to test so we can determine if writing to the interrupt pin actually
> > works.
> > However, even if it is a BIOS problem and the code will work, the
> > warning
> > will still be printed in dmesg.
>
>
> Somehow missed this mail before replying to the current patchset. I'd
> be fine with that, though it's still not clear to me whether the
> BIOS/hardware is at fault, or the code that's being added to the driver
> ;)
>
The reset procedure is described in the Goodix GT911 datasheet [1] and is
used for power-on reset and power management. The power-on sequence
is described in chapter 6.1. I2C Timing, in the Power-on Timing diagram.
The sequence for putting the device to sleep is described in chapter
7.1. Operating Modes, c) Sleep mode. These sequences use the interrupt
pin as output.
The warning you mentioned comes from the following code in the goodix
driver, which sets the interrupt to be used as output:
+ error = gpiod_direction_output(ts->gpiod_int, ts->client->addr == 0x14);
The gpiod_direction_output() call ends up in
drivers/pinctrl/intel/pinctrl-baytrail.c:
/*
* Before making any direction modifications, do a check if gpio
* is set for direct IRQ. On baytrail, setting GPIO to output does
* not make sense, so let's at least warn the caller before they shoot
* themselves in the foot.
*/
WARN(readl(conf_reg) & BYT_DIRECT_IRQ_EN,
"Potential Error: Setting GPIO with direct_irq_en to output");
So the problem comes from using the gpio interrupt pin as output, which
should not work on Baytrail if BYT_DIRECT_IRQ_EN is set by BIOS.
The above warning is introduced and discussed in [2] and [3]. As I mentioned,
this could be a real HW issue or the BIOS sets BYT_DIRECT_IRQ_EN when
it should not. I have also tested these patches on a Baytrail plarform
(that uses the same pinctrl driver), but I did not see any issues since
BYT_DIRECT_IRQ_EN is not set in my case for the interrupt gpio pin.
To determine if using the interrupt pin as output works, you can test updating
the goodix configuration [4]. Normally if something goes wrong with the reset
procedure, the configuration will not be updated. To make that easier, I have
already included a sysfs interface to dump the current configuration [5] and
a script to help generate a new configuration [6] (with details on how to use it
in the commit message). Please let me know if you need something more to
test this.
Thanks,
Irina
[1]
https://drive.google.com/a/intel.com/folderview?id=0BxCVOQS3ZymGfmJyY2RKbE5XbVlKNlktVTlwV0lxNEdxd2dzeWZER094cmJPVnMxN1F0Yzg
[2] https://lkml.org/lkml/2014/6/2/654
[3] https://lkml.org/lkml/2014/9/18/129
[4] https://lkml.org/lkml/2015/9/7/339
[5] https://lkml.org/lkml/2015/9/7/337
[6] https://lkml.org/lkml/2015/7/31/706
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�&j:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
RE: [PATCH v2 3/4] iio: bmc150: Split the driver into core and i2c
> -Original Message-
> From: Markus Pargmann [mailto:m...@pengutronix.de]
> Sent: 20 August, 2015 15:50
> To: Jonathan Cameron
> Cc: Srinivas Pandruvada; Tirdea, Irina; Lars-Peter Clausen;
> linux-...@vger.kernel.org; linux-kernel@vger.kernel.org;
> ker...@pengutronix.de; Markus Pargmann
> Subject: [PATCH v2 3/4] iio: bmc150: Split the driver into core and i2c
>
> Signed-off-by: Markus Pargmann
> ---
> drivers/iio/accel/Kconfig | 9 +-
> drivers/iio/accel/Makefile | 3 +-
> .../accel/{bmc150-accel.c => bmc150-accel-core.c} | 95 -
> drivers/iio/accel/bmc150-accel-i2c.c | 99
> ++
> drivers/iio/accel/bmc150-accel.h | 21 +
> 5 files changed, 144 insertions(+), 83 deletions(-)
> rename drivers/iio/accel/{bmc150-accel.c => bmc150-accel-core.c} (95%)
> create mode 100644 drivers/iio/accel/bmc150-accel-i2c.c
> create mode 100644 drivers/iio/accel/bmc150-accel.h
>
> diff --git a/drivers/iio/accel/Kconfig b/drivers/iio/accel/Kconfig
> index 01dd03d194d1..6da4eb0db57b 100644
> --- a/drivers/iio/accel/Kconfig
> +++ b/drivers/iio/accel/Kconfig
> @@ -19,21 +19,22 @@ config BMA180
>
> config BMC150_ACCEL
> tristate "Bosch BMC150 Accelerometer Driver"
> - depends on I2C
> select IIO_BUFFER
> select IIO_TRIGGERED_BUFFER
> select REGMAP
> - select REGMAP_I2C
> + select BMC150_ACCEL_I2C if I2C
> help
> Say yes here to build support for the following Bosch accelerometers:
> BMC150, BMI055, BMA250E, BMA222E, BMA255, BMA280.
>
> - Currently this only supports the device via an i2c interface.
> -
> This is a combo module with both accelerometer and magnetometer.
> This driver is only implementing accelerometer part, which has
> its own address and register map.
>
> +config BMC150_ACCEL_I2C
> + tristate
> + select REGMAP_I2C
> +
> config HID_SENSOR_ACCEL_3D
> depends on HID_SENSOR_HUB
> select IIO_BUFFER
> diff --git a/drivers/iio/accel/Makefile b/drivers/iio/accel/Makefile
> index ebd2675b2a02..5ef8bdbad092 100644
> --- a/drivers/iio/accel/Makefile
> +++ b/drivers/iio/accel/Makefile
> @@ -4,7 +4,8 @@
>
> # When adding new entries keep the list in alphabetical order
> obj-$(CONFIG_BMA180) += bma180.o
> -obj-$(CONFIG_BMC150_ACCEL) += bmc150-accel.o
> +obj-$(CONFIG_BMC150_ACCEL) += bmc150-accel-core.o
> +obj-$(CONFIG_BMC150_ACCEL_I2C) += bmc150-accel-i2c.o
> obj-$(CONFIG_HID_SENSOR_ACCEL_3D) += hid-sensor-accel-3d.o
> obj-$(CONFIG_KXCJK1013) += kxcjk-1013.o
> obj-$(CONFIG_KXSD9) += kxsd9.o
> diff --git a/drivers/iio/accel/bmc150-accel.c
> b/drivers/iio/accel/bmc150-accel-core.c
> similarity index 95%
> rename from drivers/iio/accel/bmc150-accel.c
> rename to drivers/iio/accel/bmc150-accel-core.c
> index e4a0691d9b88..614cf61f0110 100644
> --- a/drivers/iio/accel/bmc150-accel.c
> +++ b/drivers/iio/accel/bmc150-accel-core.c
> @@ -37,6 +37,8 @@
> #include
> #include
>
> +#include "bmc150-accel.h"
> +
> #define BMC150_ACCEL_DRV_NAME"bmc150_accel"
> #define BMC150_ACCEL_IRQ_NAME"bmc150_accel_event"
> #define BMC150_ACCEL_GPIO_NAME "bmc150_accel_int"
> @@ -187,7 +189,6 @@ enum bmc150_accel_trigger_id {
> struct bmc150_accel_data {
> struct regmap *regmap;
> struct device *dev;
> - int irq;
> struct bmc150_accel_interrupt interrupts[BMC150_ACCEL_INTERRUPTS];
> atomic_t active_intr;
> struct bmc150_accel_trigger triggers[BMC150_ACCEL_TRIGGERS];
> @@ -201,6 +202,7 @@ struct bmc150_accel_data {
> int ev_enable_state;
> int64_t timestamp, old_timestamp; /* Only used in hw fifo mode. */
> const struct bmc150_accel_chip_info *chip_info;
> + int irq;
> };
>
> static const struct {
> @@ -1070,15 +1072,6 @@ static const struct iio_chan_spec
> bmc150_accel_channels[] =
> static const struct iio_chan_spec bma280_accel_channels[] =
> BMC150_ACCEL_CHANNELS(14);
>
> -enum {
> - bmc150,
> - bmi055,
> - bma255,
> - bma250e,
> - bma222e,
> - bma280,
> -};
> -
> static const struct bmc150_accel_chip_info bmc150_accel_chip_info_tbl[] = {
> [bmc150] = {
> .chip_id = 0xFA,
> @@ -1567,36 +1560,22 @@ static const struct iio_buffer_setup_ops
> bmc150_accel_buffer_ops = {
> .postdisable = bmc150_accel_buffer_postdisable,
> };
>
> -static int bmc150_accel_probe(struct i2c_c
RE: [PATCH v2 2/4] iio: bcm150: Remove i2c_client from private data
> -Original Message-
> From: Markus Pargmann [mailto:m...@pengutronix.de]
> Sent: 20 August, 2015 15:50
> To: Jonathan Cameron
> Cc: Srinivas Pandruvada; Tirdea, Irina; Lars-Peter Clausen;
> linux-...@vger.kernel.org; linux-kernel@vger.kernel.org;
> ker...@pengutronix.de; Markus Pargmann
> Subject: [PATCH v2 2/4] iio: bcm150: Remove i2c_client from private data
>
> i2c_client struct is now only used for debugging output. We can use the
> device struct as well so we can remove all struct i2c_client usage.
>
> Signed-off-by: Markus Pargmann
> Acked-by: Jonathan Cameron
> ---
This patch also works (in my rebased version) .
I have tested the iio buffer code path and the i2c code path.
> drivers/iio/accel/bmc150-accel.c | 120
> +++
> 1 file changed, 58 insertions(+), 62 deletions(-)
>
> diff --git a/drivers/iio/accel/bmc150-accel.c
> b/drivers/iio/accel/bmc150-accel.c
> index c5c773e75173..e4a0691d9b88 100644
> --- a/drivers/iio/accel/bmc150-accel.c
> +++ b/drivers/iio/accel/bmc150-accel.c
> @@ -185,9 +185,9 @@ enum bmc150_accel_trigger_id {
> };
>
> struct bmc150_accel_data {
> - struct i2c_client *client;
> struct regmap *regmap;
> struct device *dev;
> + int irq;
> struct bmc150_accel_interrupt interrupts[BMC150_ACCEL_INTERRUPTS];
> atomic_t active_intr;
> struct bmc150_accel_trigger triggers[BMC150_ACCEL_TRIGGERS];
> @@ -276,11 +276,11 @@ static int bmc150_accel_set_mode(struct
> bmc150_accel_data *data,
> lpw_bits = mode << BMC150_ACCEL_PMU_MODE_SHIFT;
> lpw_bits |= (dur_val << BMC150_ACCEL_PMU_BIT_SLEEP_DUR_SHIFT);
>
> - dev_dbg(&data->client->dev, "Set Mode bits %x\n", lpw_bits);
> + dev_dbg(data->dev, "Set Mode bits %x\n", lpw_bits);
>
> ret = regmap_write(data->regmap, BMC150_ACCEL_REG_PMU_LPW, lpw_bits);
> if (ret < 0) {
> - dev_err(&data->client->dev, "Error writing reg_pmu_lpw\n");
> + dev_err(data->dev, "Error writing reg_pmu_lpw\n");
> return ret;
> }
>
> @@ -318,18 +318,18 @@ static int bmc150_accel_update_slope(struct
> bmc150_accel_data *data)
> ret = regmap_write(data->regmap, BMC150_ACCEL_REG_INT_6,
> data->slope_thres);
> if (ret < 0) {
> - dev_err(&data->client->dev, "Error writing reg_int_6\n");
> + dev_err(data->dev, "Error writing reg_int_6\n");
> return ret;
> }
>
> ret = regmap_update_bits(data->regmap, BMC150_ACCEL_REG_INT_5,
>BMC150_ACCEL_SLOPE_DUR_MASK, data->slope_dur);
> if (ret < 0) {
> - dev_err(&data->client->dev, "Error updating reg_int_5\n");
> + dev_err(data->dev, "Error updating reg_int_5\n");
> return ret;
> }
>
> - dev_dbg(&data->client->dev, "%s: %x %x\n", __func__, data->slope_thres,
> + dev_dbg(data->dev, "%s: %x %x\n", __func__, data->slope_thres,
> data->slope_dur);
>
> return ret;
> @@ -351,14 +351,14 @@ static int bmc150_accel_chip_init(struct
> bmc150_accel_data *data)
>
> ret = regmap_read(data->regmap, BMC150_ACCEL_REG_CHIP_ID, &val);
> if (ret < 0) {
> - dev_err(&data->client->dev,
> + dev_err(data->dev,
> "Error: Reading chip id\n");
> return ret;
> }
>
> - dev_dbg(&data->client->dev, "Chip Id %x\n", val);
> + dev_dbg(data->dev, "Chip Id %x\n", val);
> if (val != data->chip_info->chip_id) {
> - dev_err(&data->client->dev, "Invalid chip %x\n", val);
> + dev_err(data->dev, "Invalid chip %x\n", val);
> return -ENODEV;
> }
>
> @@ -375,8 +375,7 @@ static int bmc150_accel_chip_init(struct
> bmc150_accel_data *data)
> ret = regmap_write(data->regmap, BMC150_ACCEL_REG_PMU_RANGE,
> BMC150_ACCEL_DEF_RANGE_4G);
> if (ret < 0) {
> - dev_err(&data->client->dev,
> - "Error writing reg_pmu_range\n");
> + dev_err(data->dev, "Error writing reg_pmu_range\n");
> return ret;
> }
>
> @@ -394,7 +393,7 @@ static int bmc150_accel_chip_init(struct
> bmc150_accel_data
RE: [PATCH v2 1/4] iio: bmc150: Use i2c regmap
> -Original Message-
> From: Markus Pargmann [mailto:m...@pengutronix.de]
> Sent: 20 August, 2015 15:50
> To: Jonathan Cameron
> Cc: Srinivas Pandruvada; Tirdea, Irina; Lars-Peter Clausen;
> linux-...@vger.kernel.org; linux-kernel@vger.kernel.org;
> ker...@pengutronix.de; Markus Pargmann
> Subject: [PATCH v2 1/4] iio: bmc150: Use i2c regmap
>
> This replaces all usage of direct i2c accesses with regmap accesses.
>
> Signed-off-by: Markus Pargmann
> ---
This patch works, but I would wait for the rebased version and check again.
One minor comment below.
> drivers/iio/accel/Kconfig| 2 +
> drivers/iio/accel/bmc150-accel.c | 219
> +--
> 2 files changed, 95 insertions(+), 126 deletions(-)
>
> diff --git a/drivers/iio/accel/Kconfig b/drivers/iio/accel/Kconfig
> index 00e7bcbdbe24..01dd03d194d1 100644
> --- a/drivers/iio/accel/Kconfig
> +++ b/drivers/iio/accel/Kconfig
> @@ -22,6 +22,8 @@ config BMC150_ACCEL
> depends on I2C
> select IIO_BUFFER
> select IIO_TRIGGERED_BUFFER
> + select REGMAP
> + select REGMAP_I2C
> help
> Say yes here to build support for the following Bosch accelerometers:
> BMC150, BMI055, BMA250E, BMA222E, BMA255, BMA280.
> diff --git a/drivers/iio/accel/bmc150-accel.c
> b/drivers/iio/accel/bmc150-accel.c
> index 55751d9e1ade..c5c773e75173 100644
> --- a/drivers/iio/accel/bmc150-accel.c
> +++ b/drivers/iio/accel/bmc150-accel.c
> @@ -35,6 +35,7 @@
> #include
> #include
> #include
> +#include
>
> #define BMC150_ACCEL_DRV_NAME"bmc150_accel"
> #define BMC150_ACCEL_IRQ_NAME"bmc150_accel_event"
> @@ -185,6 +186,8 @@ enum bmc150_accel_trigger_id {
>
> struct bmc150_accel_data {
> struct i2c_client *client;
> + struct regmap *regmap;
> + struct device *dev;
> struct bmc150_accel_interrupt interrupts[BMC150_ACCEL_INTERRUPTS];
> atomic_t active_intr;
> struct bmc150_accel_trigger triggers[BMC150_ACCEL_TRIGGERS];
> @@ -241,6 +244,11 @@ static const struct {
> {50, BMC150_ACCEL_SLEEP_500_MS},
> {100, BMC150_ACCEL_SLEEP_1_SEC} };
>
> +static const struct regmap_config bmc150_i2c_regmap_conf = {
> + .reg_bits = 8,
> + .val_bits = 8,
> + .max_register = 0x3f,
> +};
>
> static int bmc150_accel_set_mode(struct bmc150_accel_data *data,
>enum bmc150_power_modes mode,
> @@ -270,8 +278,7 @@ static int bmc150_accel_set_mode(struct bmc150_accel_data
> *data,
>
> dev_dbg(&data->client->dev, "Set Mode bits %x\n", lpw_bits);
>
> - ret = i2c_smbus_write_byte_data(data->client,
> - BMC150_ACCEL_REG_PMU_LPW, lpw_bits);
> + ret = regmap_write(data->regmap, BMC150_ACCEL_REG_PMU_LPW, lpw_bits);
> if (ret < 0) {
> dev_err(&data->client->dev, "Error writing reg_pmu_lpw\n");
> return ret;
> @@ -289,8 +296,7 @@ static int bmc150_accel_set_bw(struct bmc150_accel_data
> *data, int val,
> for (i = 0; i < ARRAY_SIZE(bmc150_accel_samp_freq_table); ++i) {
> if (bmc150_accel_samp_freq_table[i].val == val &&
> bmc150_accel_samp_freq_table[i].val2 == val2) {
> - ret = i2c_smbus_write_byte_data(
> - data->client,
> + ret = regmap_write(data->regmap,
> BMC150_ACCEL_REG_PMU_BW,
> bmc150_accel_samp_freq_table[i].bw_bits);
> if (ret < 0)
> @@ -307,26 +313,19 @@ static int bmc150_accel_set_bw(struct bmc150_accel_data
> *data, int val,
>
> static int bmc150_accel_update_slope(struct bmc150_accel_data *data)
> {
> - int ret, val;
> + int ret;
>
> - ret = i2c_smbus_write_byte_data(data->client, BMC150_ACCEL_REG_INT_6,
> + ret = regmap_write(data->regmap, BMC150_ACCEL_REG_INT_6,
> data->slope_thres);
> if (ret < 0) {
> dev_err(&data->client->dev, "Error writing reg_int_6\n");
> return ret;
> }
>
> - ret = i2c_smbus_read_byte_data(data->client, BMC150_ACCEL_REG_INT_5);
> + ret = regmap_update_bits(data->regmap, BMC150_ACCEL_REG_INT_5,
> + BMC150_ACCEL_SLOPE_DUR_MASK, data->slope_dur);
> if (ret < 0) {
> - dev_err(&data->client-
RE: [PATCH v2 0/4] iio: bmc150 regmap and SPI
> -Original Message-
> From: Markus Pargmann [mailto:m...@pengutronix.de]
> Sent: 20 August, 2015 15:50
> To: Jonathan Cameron
> Cc: Srinivas Pandruvada; Tirdea, Irina; Lars-Peter Clausen;
> linux-...@vger.kernel.org; linux-kernel@vger.kernel.org;
> ker...@pengutronix.de; Markus Pargmann
> Subject: [PATCH v2 0/4] iio: bmc150 regmap and SPI
>
> Hi,
>
Hi Markus,
I tested your patches with my BMA250E driver connected on the i2c bus .
The code looks good and most of it works. There are a couple of issues I will
mention
below and in the individual patches.
The patches in this version no longer apply cleanly on the togreg branch of the
iio tree.
I did the rebase myself, but since there were many conflicts I will do another
test
when you send the new rebased v3.
> this series converts the bmc150 driver to use regmap and adds an SPI
> interface.
>
> In v1 this was part of the series "Regmap max_raw_io and bmc150 SPI support".
> It now depends on "regmap: i2c block support".
>
I used the patches that were already merged in the regmap tree. This bmc150
series should
probably wait until the regmap patches end up in Jonathan's tree, otherwise
they will
break the build.
Thanks,
Irina
> Changes in v2:
> - Removed default values for regmap_config fields.
> - Redesigned the fifo_transfer function to avoid running in errors first.
> - Dropped irq checks patch as it is already mainline
> - Core can now be built as module with autoselection of i2c and spi parts
>
> As my hardware is missing an interrupt line from the SPI connected bmc150 I am
> not able to test the iio buffer code path and the i2c code path. Tests would
> be
> appreciated.
>
> Best regards,
>
> Markus
>
>
> Markus Pargmann (4):
> iio: bmc150: Use i2c regmap
> iio: bcm150: Remove i2c_client from private data
> iio: bmc150: Split the driver into core and i2c
> iio: bmc150: Add SPI driver
>
> drivers/iio/accel/Kconfig | 14 +-
> drivers/iio/accel/Makefile | 4 +-
> .../accel/{bmc150-accel.c => bmc150-accel-core.c} | 398
> -
> drivers/iio/accel/bmc150-accel-i2c.c | 99 +
> drivers/iio/accel/bmc150-accel-spi.c | 83 +
> drivers/iio/accel/bmc150-accel.h | 21 ++
> 6 files changed, 367 insertions(+), 252 deletions(-)
> rename drivers/iio/accel/{bmc150-accel.c => bmc150-accel-core.c} (81%)
> create mode 100644 drivers/iio/accel/bmc150-accel-i2c.c
> create mode 100644 drivers/iio/accel/bmc150-accel-spi.c
> create mode 100644 drivers/iio/accel/bmc150-accel.h
>
> --
> 2.4.6
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing runtime suspend
> -Original Message- > From: linux-input-ow...@vger.kernel.org > [mailto:linux-input-ow...@vger.kernel.org] On Behalf Of Rafael J. Wysocki > Sent: 08 September, 2015 0:20 > To: Tirdea, Irina > Cc: Alan Stern; linux...@vger.kernel.org; linux-in...@vger.kernel.org; > linux-kernel@vger.kernel.org; Brown, Len; Pavel Machek; > Purdila, Octavian; Dmitry Torokhov > Subject: Re: [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing > runtime suspend > > On Monday, September 07, 2015 11:42:41 PM Irina Tirdea wrote: > > Add new option to sysfs control interface, allowing the user to force > > suspend the device. > > Had we thought this had been a good idea, we'd have added that thing to > the interface from the start. > > The problem with it is that user space generally doesn't know when it is > safe to suspend a device, so it cannot force anything into runtime suspend. > Yes, this is generally true. However, in the scenario I mentioned this is exactly what is happening. When turning off the screen of a mobile device, the user space is the one that suspends the devices that are not needed in order to save power (like touchscreens). Each such driver export an enable/disable attribute that calls the same code as resume/suspend (e.g. touchscreen drivers ads7846, ad7877 and most Android drivers not merged upstream). This adds more complexity to every driver by adding one more logical power state. It would be good to have a common interface instead of doing this in every driver. I might have not used "forced" in the proper way here. What I mean by it is that the device can be runtime suspended while ignoring the runtime usage count. > > This is useful for devices that need to be > > suspended when closing the lid of a laptop or the screen of a mobile > > device, while user space still holds open handles to it and the > > system does not enter system suspend. > > > > Add the "off" option to the sysfs control power interface, along with > > the already present "on" and "auto". When this attribute is set to > > "off", the device will be force suspended by calling its runtime > > suspend callback and disabling runtime power management so that > > further accesses to the device will not change the actual state. > > And how is user space supposed to know that it doesn't break things > this way? > In this implementation, user space is only allowed to change the states bottom-up in the sysfs hierarchy (it cannot force suspend a device if it has children that have not been suspended by user space). Another way to do this is to keep runtime power management enabled but to force the usage count to 0 while the device is set to runtime mode "off". > > The device can be resumed by setting the attribute to "on" or "auto". > > The behavior of the interface when switching only between "on" > > and "auto" states remains unchanged. > > > > Signed-off-by: Irina Tirdea > > --- > > > > Hi, > > > > This is a proposal for suspending devices when the closing the lid of > > a laptop or the screen of a mobile device. > > > > I am testing this with a Goodix touchscreen [1] for an Android mobile > > device. Android has an user space layer (power HAL) that would normally > > close the touchscreen when the screen is closed. Android touchscreen > > drivers usually provide a custom sysfs interface to allow this. > > This would be better implemented in a common place, to avoid code > > duplication and to simplify the driver code (as previously discussed > > in [1]). > > > > I know there are more ways to implement this, so I would appreciate > > your feedback. > > So the feedback is that this is not going to work in general. Please > use a different approach. > Would it work if this would be a capability that individual drivers need to declare? In the previous discussion thread , there were a couple of options mentioned, but none seemed to reach a consensus. You mentioned adding a "more aggressive runtime PM mode" [1]. I'm not sure how this would work except for adding a sysfs attribute that would trigger a runtime suspend while ignoring usage count. Would that be a better direction? Thank you, Irina [1] http://marc.info/?l=linux-input&m=140564626306396&w=2 > Thanks, > Rafael > > -- > To unsubscribe from this list: send the line "unsubscribe linux-input" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2 1/4] iio: bmc150: Use i2c regmap
> -Original Message-
> From: Srinivas Pandruvada [mailto:srinivas.pandruv...@linux.intel.com]
> Sent: 31 August, 2015 22:39
> To: Jonathan Cameron; Markus Pargmann; Tirdea, Irina
> Cc: Lars-Peter Clausen; linux-...@vger.kernel.org;
> linux-kernel@vger.kernel.org; ker...@pengutronix.de
> Subject: Re: [PATCH v2 1/4] iio: bmc150: Use i2c regmap
>
> Hi Irina,
>
Hi Srinivas,
> Is it possible for you to test this patchset? I don't have platform to
> test with me now (working remotely for couple of weeks).
>
Sure, I'll test this patch set today.
Sorry for the late response, seems I somehow missed your e-mail.
Regards,
Irina
> Thanks,
> Srinivas
>
> On Mon, 2015-08-31 at 17:11 +0100, Jonathan Cameron wrote:
> > On 20/08/15 13:49, Markus Pargmann wrote:
> > > This replaces all usage of direct i2c accesses with regmap
> > > accesses.
> > >
> > > Signed-off-by: Markus Pargmann
> > Looks fine to me, but I will be wanting an Ack / reviewed-by
> > and preferably a tested by from Srinivas.
> >
> > Thanks,
> >
> > Jonathan
> > > ---
> > > drivers/iio/accel/Kconfig| 2 +
> > > drivers/iio/accel/bmc150-accel.c | 219 +--
> > >
> > > 2 files changed, 95 insertions(+), 126 deletions(-)
> > >
> > > diff --git a/drivers/iio/accel/Kconfig b/drivers/iio/accel/Kconfig
> > > index 00e7bcbdbe24..01dd03d194d1 100644
> > > --- a/drivers/iio/accel/Kconfig
> > > +++ b/drivers/iio/accel/Kconfig
> > > @@ -22,6 +22,8 @@ config BMC150_ACCEL
> > > depends on I2C
> > > select IIO_BUFFER
> > > select IIO_TRIGGERED_BUFFER
> > > + select REGMAP
> > > + select REGMAP_I2C
> > > help
> > > Say yes here to build support for the following Bosch
> > > accelerometers:
> > > BMC150, BMI055, BMA250E, BMA222E, BMA255, BMA280.
> > > diff --git a/drivers/iio/accel/bmc150-accel.c
> > > b/drivers/iio/accel/bmc150-accel.c
> > > index 55751d9e1ade..c5c773e75173 100644
> > > --- a/drivers/iio/accel/bmc150-accel.c
> > > +++ b/drivers/iio/accel/bmc150-accel.c
> > > @@ -35,6 +35,7 @@
> > > #include
> > > #include
> > > #include
> > > +#include
> > >
> > > #define BMC150_ACCEL_DRV_NAME"bmc150_accel
> > > "
> > > #define BMC150_ACCEL_IRQ_NAME"bmc150_accel
> > > _event"
> > > @@ -185,6 +186,8 @@ enum bmc150_accel_trigger_id {
> > >
> > > struct bmc150_accel_data {
> > > struct i2c_client *client;
> > > + struct regmap *regmap;
> > > + struct device *dev;
> > > struct bmc150_accel_interrupt
> > > interrupts[BMC150_ACCEL_INTERRUPTS];
> > > atomic_t active_intr;
> > > struct bmc150_accel_trigger
> > > triggers[BMC150_ACCEL_TRIGGERS];
> > > @@ -241,6 +244,11 @@ static const struct {
> > > {50,
> > > BMC150_ACCEL_SLEEP_500_MS},
> > > {100,
> > > BMC150_ACCEL_SLEEP_1_SEC} };
> > >
> > > +static const struct regmap_config bmc150_i2c_regmap_conf = {
> > > + .reg_bits = 8,
> > > + .val_bits = 8,
> > > + .max_register = 0x3f,
> > > +};
> > >
> > > static int bmc150_accel_set_mode(struct bmc150_accel_data *data,
> > >enum bmc150_power_modes mode,
> > > @@ -270,8 +278,7 @@ static int bmc150_accel_set_mode(struct
> > > bmc150_accel_data *data,
> > >
> > > dev_dbg(&data->client->dev, "Set Mode bits %x\n",
> > > lpw_bits);
> > >
> > > - ret = i2c_smbus_write_byte_data(data->client,
> > > - BMC150_ACCEL_REG_PMU_LPW,
> > > lpw_bits);
> > > + ret = regmap_write(data->regmap, BMC150_ACCEL_REG_PMU_LPW,
> > > lpw_bits);
> > > if (ret < 0) {
> > > dev_err(&data->client->dev, "Error writing
> > > reg_pmu_lpw\n");
> > > return ret;
> > > @@ -289,8 +296,7 @@ static int bmc150_accel_set_bw(struct
> > > bmc150_accel_data *data, int val,
> > > for (i = 0; i < ARRAY_SIZE(bmc150_accel_samp_freq_table);
> > > ++i) {
> > > if (bmc150_accel_samp_freq_table[i].val == val &&
> > > bmc150_accel_samp_freq_table[i].va
> > > l2 == v
RE: [PATCH v5 6/8] iio: gyro: bmg160: optimize i2c transfers in trigger handler
> -Original Message-
> From: Markus Pargmann [mailto:m...@pengutronix.de]
> Sent: 17 August, 2015 12:10
> To: Jonathan Cameron
> Cc: Tirdea, Irina; Wolfram Sang; linux-...@vger.kernel.org;
> linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; Pandruvada,
> Srinivas; Peter Meerwald
> Subject: Re: [PATCH v5 6/8] iio: gyro: bmg160: optimize i2c transfers in
> trigger handler
>
> On Sun, Aug 16, 2015 at 10:24:47AM +0100, Jonathan Cameron wrote:
> > On 12/08/15 15:31, Irina Tirdea wrote:
> > > Some i2c busses (e.g.: Synopsys DesignWare I2C adapter) need to
> > > enable/disable the bus at each i2c transfer and must wait for
> > > the enable/disable to happen before sending the data.
> > >
> > > When reading data in the trigger handler, the bmg160 driver does
> > > one i2c transfer for each axis. This has an impact on the frequency
> > > of the gyroscope at high sample rates due to additional delays
> > > introduced by the i2c bus at each transfer.
> > >
> > > Reading all axis values in one i2c transfer reduces the delays
> > > introduced by the i2c bus. Uses i2c_smbus_read_i2c_block_data_or_emulated
> > > that will fallback to reading each axis as a separate word in case i2c
> > > block read is not supported.
> > >
> > > Signed-off-by: Irina Tirdea
> > > Acked-by: Jonathan Cameron
> > > Acked-by: Srinivas Pandruvada
> > Note, that in the meantime the bmg160 driver just went all regmap
> > on us (as part of adding SPI support - though that step hasn't
> > happened yet). Hence we'll need a means of telling regmap about this
> > possibility.
>
> Perhaps this is covered by a regmap_bulk_read()?
I think it is. However, if that does not work for the i2c controllers I'm
testing with I'll take a look at the patches you mention below.
I'll rebase this patch on top of your next version for bmg160 and
resend.
Thanks,
Irina
>
> The series[1] I am working on implements a i2c smbus block data regmap
> bus driver. Regmap should then automatically do a block read in
> regmap_bulk_read.
>
> Patch 15 introduces the i2c block data regmap bus driver[2].
> I am only implementing this so I don't break bmc150 behavior. I do not
> have the hardware available to test this regmap driver so it would be great
> if someone else could test one of the next versions of this bus driver.
>
> Best regards,
>
> Markus
>
> [1] http://thread.gmane.org/gmane.linux.kernel/2018643
> [2] http://thread.gmane.org/gmane.linux.kernel/2018639
>
> >
> > > ---
> > > drivers/iio/gyro/bmg160.c | 18 --
> > > 1 file changed, 8 insertions(+), 10 deletions(-)
> > >
> > > diff --git a/drivers/iio/gyro/bmg160.c b/drivers/iio/gyro/bmg160.c
> > > index b2a6ccb..1ff306d 100644
> > > --- a/drivers/iio/gyro/bmg160.c
> > > +++ b/drivers/iio/gyro/bmg160.c
> > > @@ -772,6 +772,7 @@ static const struct iio_event_spec bmg160_event = {
> > > .sign = 's',\
> > > .realbits = 16, \
> > > .storagebits = 16, \
> > > + .endianness = IIO_LE, \
> > > }, \
> > > .event_spec = &bmg160_event,\
> > > .num_event_specs = 1\
> > > @@ -809,19 +810,16 @@ static irqreturn_t bmg160_trigger_handler(int irq,
> > > void *p)
> > > struct iio_poll_func *pf = p;
> > > struct iio_dev *indio_dev = pf->indio_dev;
> > > struct bmg160_data *data = iio_priv(indio_dev);
> > > - int bit, ret, i = 0;
> > > + int ret = 0;
> > >
> > > mutex_lock(&data->mutex);
> > > - for (bit = 0; bit < AXIS_MAX; bit++) {
> > > - ret = i2c_smbus_read_word_data(data->client,
> > > -BMG160_AXIS_TO_REG(bit));
> > > - if (ret < 0) {
> > > - mutex_unlock(&data->mutex);
> > > - goto err;
> > > - }
> > > - data->buffer[i++] = ret;
> > > - }
> > > + ret = i2c_smbus_read_i2c_block_data_or_emulated(data->client,
> > > + BMG160_REG_XOUT_L,
> > > + AXIS_MAX * 2,
> > >
RE: [PATCH v5 6/8] iio: gyro: bmg160: optimize i2c transfers in trigger handler
> -Original Message-
> From: Jonathan Cameron [mailto:ji...@kernel.org]
> Sent: 16 August, 2015 12:25
> To: Tirdea, Irina; Wolfram Sang; linux-...@vger.kernel.org;
> linux-...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org; Pandruvada, Srinivas; Peter Meerwald
> Subject: Re: [PATCH v5 6/8] iio: gyro: bmg160: optimize i2c transfers in
> trigger handler
>
> On 12/08/15 15:31, Irina Tirdea wrote:
> > Some i2c busses (e.g.: Synopsys DesignWare I2C adapter) need to
> > enable/disable the bus at each i2c transfer and must wait for
> > the enable/disable to happen before sending the data.
> >
> > When reading data in the trigger handler, the bmg160 driver does
> > one i2c transfer for each axis. This has an impact on the frequency
> > of the gyroscope at high sample rates due to additional delays
> > introduced by the i2c bus at each transfer.
> >
> > Reading all axis values in one i2c transfer reduces the delays
> > introduced by the i2c bus. Uses i2c_smbus_read_i2c_block_data_or_emulated
> > that will fallback to reading each axis as a separate word in case i2c
> > block read is not supported.
> >
> > Signed-off-by: Irina Tirdea
> > Acked-by: Jonathan Cameron
> > Acked-by: Srinivas Pandruvada
> Note, that in the meantime the bmg160 driver just went all regmap
> on us (as part of adding SPI support - though that step hasn't
> happened yet). Hence we'll need a means of telling regmap about this
> possibility.
I think regmap_bulk_read might be enough in my case, but I'll have to
test this. I have also seen there are similar changes for the bmc150 driver,
so I will rebase my changes on top of the regmap ones. That leaves only the
kxcjk-1013 changes to be applied from this patchset.
Thanks,
Irina
>
> > ---
> > drivers/iio/gyro/bmg160.c | 18 --
> > 1 file changed, 8 insertions(+), 10 deletions(-)
> >
> > diff --git a/drivers/iio/gyro/bmg160.c b/drivers/iio/gyro/bmg160.c
> > index b2a6ccb..1ff306d 100644
> > --- a/drivers/iio/gyro/bmg160.c
> > +++ b/drivers/iio/gyro/bmg160.c
> > @@ -772,6 +772,7 @@ static const struct iio_event_spec bmg160_event = {
> > .sign = 's',\
> > .realbits = 16, \
> > .storagebits = 16, \
> > + .endianness = IIO_LE, \
> > }, \
> > .event_spec = &bmg160_event,\
> > .num_event_specs = 1\
> > @@ -809,19 +810,16 @@ static irqreturn_t bmg160_trigger_handler(int irq,
> > void *p)
> > struct iio_poll_func *pf = p;
> > struct iio_dev *indio_dev = pf->indio_dev;
> > struct bmg160_data *data = iio_priv(indio_dev);
> > - int bit, ret, i = 0;
> > + int ret = 0;
> >
> > mutex_lock(&data->mutex);
> > - for (bit = 0; bit < AXIS_MAX; bit++) {
> > - ret = i2c_smbus_read_word_data(data->client,
> > - BMG160_AXIS_TO_REG(bit));
> > - if (ret < 0) {
> > - mutex_unlock(&data->mutex);
> > - goto err;
> > - }
> > - data->buffer[i++] = ret;
> > - }
> > + ret = i2c_smbus_read_i2c_block_data_or_emulated(data->client,
> > + BMG160_REG_XOUT_L,
> > + AXIS_MAX * 2,
> > + (u8 *)data->buffer);
> > mutex_unlock(&data->mutex);
> > + if (ret < 0)
> > + goto err;
> >
> > iio_push_to_buffers_with_timestamp(indio_dev, data->buffer,
> >pf->timestamp);
> >
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v3 0/6] iio: bmg160: Add SPI connection
> -Original Message-
> From: Lars-Peter Clausen [mailto:l...@metafoo.de]
> Sent: 12 August, 2015 18:04
> To: Markus Pargmann; Jonathan Cameron
> Cc: Srinivas Pandruvada; Dogaru, Vlad; Paul Bolle; linux-...@vger.kernel.org;
> linux-kernel@vger.kernel.org; ker...@pengutronix.de;
> Tirdea, Irina
> Subject: Re: [PATCH v3 0/6] iio: bmg160: Add SPI connection
>
> Hi,
>
> Markus and Irina can you try to synchronize your efforts. This series will
> conflict with http://marc.info/?l=linux-iio&m=143938994602171&w=2
>
Hi Lars,
Good catch, especially since those patches might have been merged
through another tree. Completely missed this one.
> I think it would be best if the multi-read emulation support is added to
> regmap (which I think Markus' earlier series did).
>
I think my i2c controllers will work directly with regmap_bulk_read,
so I probably won't need additional changes for regmap. I will rebase
the bmg160 patches on top of the ones that add regmap support.
Thanks,
Irina
> - Lars
>
> On 08/12/2015 04:50 PM, Markus Pargmann wrote:
> > Hi,
> >
> > bmg160 and bmi055 can be used via I2C and SPI. This series converts the
> > driver
> > to regmap and splits core driver and I2C/SPI.
> >
> > Changes in v3:
> > - removed 'select REGMAP' as it is selected by REGMAP_I2C
> > - added EXPORT_SYMBOL_GPL for the core functions
> > - removed default values from regmap_config
> > - Added max_register and unset use_single_rw in regmap_config
> > - Changed Makefile to always compile bmg160-core with either spi or i2c.
> > It is
> >not possible now to compile the core alone.
> >
> > Changes in v2:
> > - Added the id->name from the SPI driver to be used as iio device name
> > - Fixed Kconfig in patch 2 to add selects for REGMAP_I2C
> > - Fixed regmap configs to be static const
> >
> >
> > Best regards,
> >
> > Markus
> >
> >
> > Markus Pargmann (6):
> > iio: bmg160: Use i2c regmap instead of direct i2c access
> > iio: bmg160: Remove i2c_client from data struct
> > iio: bmg160: Use generic dev_drvdata
> > iio: bmg160: Remove remaining uses of i2c_client
> > iio: bmg160: Separate i2c and core driver
> > iio: bmg160: Add SPI driver
> >
> > drivers/iio/gyro/Kconfig | 28 ++-
> > drivers/iio/gyro/Makefile| 3 +-
> > drivers/iio/gyro/bmg160.h| 10 +
> > drivers/iio/gyro/{bmg160.c => bmg160_core.c} | 358
> > +++
> > drivers/iio/gyro/bmg160_i2c.c| 71 ++
> > drivers/iio/gyro/bmg160_spi.c| 57 +
> > 6 files changed, 306 insertions(+), 221 deletions(-)
> > create mode 100644 drivers/iio/gyro/bmg160.h
> > rename drivers/iio/gyro/{bmg160.c => bmg160_core.c} (74%)
> > create mode 100644 drivers/iio/gyro/bmg160_i2c.c
> > create mode 100644 drivers/iio/gyro/bmg160_spi.c
> >
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v4 1/8] i2c: core: Add support for best effort block read emulation
> -Original Message-
> From: Wolfram Sang [mailto:w...@the-dreams.de]
> Sent: 09 August, 2015 10:32
> To: Tirdea, Irina
> Cc: Jonathan Cameron; linux-...@vger.kernel.org; linux-...@vger.kernel.org;
> linux-kernel@vger.kernel.org; Pandruvada, Srinivas;
> Peter Meerwald
> Subject: Re: [PATCH v4 1/8] i2c: core: Add support for best effort block read
> emulation
>
> On Tue, Aug 04, 2015 at 05:04:09PM +0300, Irina Tirdea wrote:
> > There are devices that need to handle block transactions
> > regardless of the capabilities exported by the adapter.
> > For performance reasons, they need to use i2c read blocks
> > if available, otherwise emulate the block transaction with word
> > or byte transactions.
> >
> > Add support for a helper function that would read a data block
> > using the best transfer available: I2C_FUNC_SMBUS_READ_I2C_BLOCK,
> > I2C_FUNC_SMBUS_READ_WORD_DATA or I2C_FUNC_SMBUS_READ_BYTE_DATA.
> >
> > Signed-off-by: Irina Tirdea
>
> We are close, but I think there is one optimization left to do.
>
> > +/**
> > + * i2c_smbus_read_i2c_block_data_or_emulated - read block or emulate
> > + * @client: Handle to slave device
> > + * @command: Byte interpreted by slave
> > + * @length: Size of data block; SMBus allows at most 32 bytes
>
> Please refer to I2C_SMBUS_BLOCK_MAX instead of 32. The new SMBus specs
> increased this amount to 256. (Yes, we don't support that yet.)
>
Sure, I'll use I2C_SMBUS_BLOCK_MAX instead to be compatible with these changes.
> > + * @values: Byte array into which data will be read; big enough to hold
> > + * the data returned by the slave. SMBus allows at most 32 bytes.
> > + *
> > + * This executes the SMBus "block read" protocol if supported by the
> > adapter.
> > + * If block read is not supported, it emulates it using either word or byte
> > + * read protocols depending on availability.
> > + *
> > + * The addresses of the I2C slave device that are accessed with this
> > function
> > + * must be mapped to a linear region, so that a block read will have the
> > same
> > + * effect as a byte read. Before using this function you must double-check
> > + * if the I2C slave does support exchanging a block transfer with a byte
> > + * transfer.
> > + */
> > +s32 i2c_smbus_read_i2c_block_data_or_emulated(const struct i2c_client
> > *client,
> > + u8 command, u8 length, u8 *values)
> > +{
> > + u8 i;
> > + int status;
> > +
> > + if (length > I2C_SMBUS_BLOCK_MAX)
> > + length = I2C_SMBUS_BLOCK_MAX;
> > +
> > + if (i2c_check_functionality(client->adapter,
> > I2C_FUNC_SMBUS_READ_I2C_BLOCK))
> > + return i2c_smbus_read_i2c_block_data(client, command, length,
> > values);
> > +
> > + if (i2c_check_functionality(client->adapter,
> > I2C_FUNC_SMBUS_READ_WORD_DATA |
> > + I2C_FUNC_SMBUS_READ_BYTE_DATA)) {
> > + for (i = 0; (i + 2) <= length; i += 2) {
> > + status = i2c_smbus_read_word_data(client, command + i);
> > + if (status < 0)
> > + return status;
> > + values[i] = status & 0xff;
> > + values[i + 1] = status >> 8;
> > + }
> > + if (i < length) {
> > + status = i2c_smbus_read_byte_data(client, command + i);
> > + if (status < 0)
> > + return status;
> > + values[i] = status;
> > + i++;
> > + }
> > + return i;
> > + }
> > +
> > + if (i2c_check_functionality(client->adapter,
> > I2C_FUNC_SMBUS_READ_BYTE_DATA)) {
> > + for (i = 0; i < length; i++) {
> > + status = i2c_smbus_read_byte_data(client, command + i);
> > + if (status < 0)
> > + return status;
> > + values[i] = status;
> > + }
> > + return i;
> > + }
>
> We have two very similar blocks for transferring READ_BYTE_DATA now.
> What about this pseudo code:
>
> if (check_func(I2C_BLOCK))
> return i2c_smbus_read_i2c_block_data(...);
>
> if (!check_func(I2C_READ_BYTE_DATA)
> return -EOPNOTSUPP;
>
> if (check_func(I2C_READ_WORD_DATA)
> read_as_many_words_as_possible;
>
> re
RE: [PATCH v4 0/8] Goodix touchscreen enhancements
> -Original Message- > From: Bastien Nocera [mailto:had...@hadess.net] > Sent: 03 August, 2015 13:30 > To: Tirdea, Irina; Dmitry Torokhov; linux-in...@vger.kernel.org > Cc: Mark Rutland; Purdila, Octavian; linux-kernel@vger.kernel.org; > devicet...@vger.kernel.org > Subject: Re: [PATCH v4 0/8] Goodix touchscreen enhancements > > On Fri, 2015-07-31 at 20:42 +0300, Irina Tirdea wrote: > > Add several enhancements to the Goodix touchscreen driver. > > It's going to be a couple of weeks before I have the time to sit down > and test most of those. Also note that I'll be using a different device > (WinBook TW100), though the new owner of the Onda v975w should be able > to run tests as well. > Thanks for letting me know, Bastien! I might send one more version in the meantime if I have more updates, so please use the latest version when you test them. Thanks, Irina > Cheers
RE: [PATCH v3 2/8] eeprom: at24: use i2c_smbus_read_i2c_block_data_or_emulated
> -Original Message-
> From: Wolfram Sang [mailto:w...@the-dreams.de]
> Sent: 01 August, 2015 22:58
> To: Tirdea, Irina
> Cc: Jonathan Cameron; linux-...@vger.kernel.org; linux-...@vger.kernel.org;
> linux-kernel@vger.kernel.org; Pandruvada, Srinivas;
> Peter Meerwald
> Subject: Re: [PATCH v3 2/8] eeprom: at24: use
> i2c_smbus_read_i2c_block_data_or_emulated
>
> > + if (at24->use_smbus) {
> > + status =
> > + i2c_smbus_read_i2c_block_data_or_emulated(client,
> > + offset,
> > + count,
> > + buf);
>
> Please ignore checkpatch warnings for this one and find a nice readable
> way to squeeze that into two lines.
Sure, I will fix this.
Thanks,
Irina
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v3 1/8] i2c: core: Add support for best effort block read emulation
> -Original Message-
> From: linux-iio-ow...@vger.kernel.org
> [mailto:linux-iio-ow...@vger.kernel.org] On Behalf Of Wolfram Sang
> Sent: 01 August, 2015 22:53
> To: Tirdea, Irina
> Cc: Jonathan Cameron; linux-kernel@vger.kernel.org; Pandruvada, Srinivas;
> Peter Meerwald; linux-...@vger.kernel.org; linux-
> i...@vger.kernel.org
> Subject: Re: [PATCH v3 1/8] i2c: core: Add support for best effort block read
> emulation
>
>
> > > I wonder what devices do if you do a word read beyond their end address?
> > > Perhaps in odd cases we should always fall back to byte reads?
> >
> > In my tests I can read beyond the end address, but I cannot be sure if this
> > is OK for all
> > devices. This was actually a suggestion from Wolfram for v1, but maybe I'm
> > missing
> > something.
> >
> > Wolfram, is it safe to read one byte beyond the end address or should I
> > better use
> > only byte reads for odd lengths?
>
> Well, from a device perspective, it is probably better to be safe than
> sorry and fall back to a single byte read. That means, however, that we
> need READ_WORD_DATA and READ_BYTE_DATA to be supported by the adapter.
> Should be OK, I don't think there are adapters which can only read words.
>
OK. In this case, I would rather go back to how reading odd lengths was handled
in
the first version of this patch: use word reads up to the last byte and read
that last
byte using a byte read. In this way, odd and even lengths are both handled as
expected (by first falling back to word reads and then to byte reads).
Also, some adapters have performance issues when using more i2c transactions,
so using word instead of byte reads where is possible could help.
I'll send v4 like this and wait for your feedback.
> > > > + */
> > > > +s32 i2c_smbus_read_i2c_block_data_or_emulated(const struct i2c_client
> > > > *client,
> > > > + u8 command, u8 length, u8
> > > > *values)
> > > > +{
> > > > + u8 i;
> > > > + int status;
> > > > +
> > > > + if (length > I2C_SMBUS_BLOCK_MAX)
> > > > + length = I2C_SMBUS_BLOCK_MAX;
> > > > +
> > > > + if (i2c_check_functionality(client->adapter,
> > > > + I2C_FUNC_SMBUS_READ_I2C_BLOCK)) {
> > > > + return i2c_smbus_read_i2c_block_data(client, command,
> > > > +length, values);
>
> I am not very strict with the 80 char limit. I'd think the code is more
> readable if the two statements above would be oneliners. And for some
> other lines later as well.
>
Ok.
> > > > + } else if (i2c_check_functionality(client->adapter,
>
> No need for else since we return in the above if anyhow.
Ok. Will fix this.
>
> > > > +
> > > > I2C_FUNC_SMBUS_READ_WORD_DATA)) {
> > > > + for (i = 0; i < length; i += 2) {
> > > > + status = i2c_smbus_read_word_data(client,
> > > > command + i);
> > > > + if (status < 0)
> > > > + return status;
> > > > + values[i] = status & 0xff;
> > > > + if ((i + 1) < length)
> > > > + values[i + 1] = status >> 8;
> > > > + }
> > > > + if (i > length)
> > > > + return length;
> > > > + return i;
> > > > + } else if (i2c_check_functionality(client->adapter,
> > > > +
> > > > I2C_FUNC_SMBUS_READ_BYTE_DATA)) {
> > > > + for (i = 0; i < length; i++) {
> > > > + status = i2c_smbus_read_byte_data(client,
> > > > command + i);
> > > > + if (status < 0)
> > > > + return status;
> > > > + values[i] = status;
> > > > + }
> > > > + return i;
> > > > + }
> > > > +
> > > > + dev_err(&client->adapter->dev, "Unsupported transactions:
> > > > %d,%d,%d\n",
> > > > + I2C_SMBUS_I2C_BLOCK_DATA, I2C_SMBUS_WORD_DATA,
>
RE: [PATCH 8/9] input: goodix: add support for ESD
> -Original Message- > From: linux-input-ow...@vger.kernel.org > [mailto:linux-input-ow...@vger.kernel.org] On Behalf Of Tirdea, Irina > Sent: 08 June, 2015 17:29 > To: Dmitry Torokhov > Cc: Bastien Nocera; Mark Rutland; linux-in...@vger.kernel.org; > devicet...@vger.kernel.org; linux-kernel@vger.kernel.org > Subject: RE: [PATCH 8/9] input: goodix: add support for ESD > > > > > -Original Message- > > From: Dmitry Torokhov [mailto:dmitry.torok...@gmail.com] > > Sent: 05 June, 2015 19:46 > > To: Tirdea, Irina > > Cc: Bastien Nocera; Mark Rutland; linux-in...@vger.kernel.org; > > devicet...@vger.kernel.org; linux-kernel@vger.kernel.org > > Subject: Re: [PATCH 8/9] input: goodix: add support for ESD > > > > On Fri, Jun 05, 2015 at 04:37:49PM +, Tirdea, Irina wrote: > > > > > > > > > > -Original Message- > > > > From: Bastien Nocera [mailto:had...@hadess.net] > > > > Sent: 04 June, 2015 15:58 > > > > To: Tirdea, Irina > > > > Cc: Mark Rutland; Dmitry Torokhov; linux-in...@vger.kernel.org; > > > > devicet...@vger.kernel.org; linux-kernel@vger.kernel.org > > > > Subject: Re: [PATCH 8/9] input: goodix: add support for ESD > > > > > > > > On Thu, 2015-05-28 at 14:26 +, Tirdea, Irina wrote: > > > > > > > > > > > -Original Message- > > > > > > From: linux-input-ow...@vger.kernel.org [mailto: > > > > > > linux-input-ow...@vger.kernel.org] On Behalf Of Mark Rutland > > > > > > Sent: 28 May, 2015 16:24 > > > > > > To: Tirdea, Irina > > > > > > Cc: Dmitry Torokhov; Bastien Nocera; linux-in...@vger.kernel.org; > > > > > > devicet...@vger.kernel.org; linux-kernel@vger.kernel.org > > > > > > Subject: Re: [PATCH 8/9] input: goodix: add support for ESD > > > > > > > > > > > > On Thu, May 28, 2015 at 01:47:44PM +0100, Irina Tirdea wrote: > > > > > > > Add ESD (Electrostatic Discharge) protection mechanism. > > > > > > > > > > > > > > The driver enables ESD protection in HW and checks a register > > > > > > > to determine if ESD occurred. If ESD is signalled by the HW, > > > > > > > the driver will reset the device. > > > > > > > > > > > > > > The ESD poll time (in ms) can be set through > > > > > > > esd-recovery-timeout-ms ACPI/DT property. If it is set to 0, > > > > > > > ESD protection is disabled. > > > > > > > > > > > > > > Signed-off-by: Irina Tirdea > > > > > > > --- > > > > > > > .../bindings/input/touchscreen/goodix.txt | 4 + > > > > > > > drivers/input/touchscreen/goodix.c | 106 > > > > > > > - > > > > > > > 2 files changed, 106 insertions(+), 4 deletions(-) > > > > > > > > > > > > > > diff --git > > > > > > > a/Documentation/devicetree/bindings/input/touchscreen/goodix.txt > > > > > > b/Documentation/devicetree/bindings/input/touchscreen/goodix.txt > > > > > > > index 9e4ff69..9132ee0 100644 > > > > > > > --- > > > > > > > a/Documentation/devicetree/bindings/input/touchscreen/goodix.txt > > > > > > > +++ > > > > > > > b/Documentation/devicetree/bindings/input/touchscreen/goodix.txt > > > > > > > @@ -19,6 +19,10 @@ Optional properties: > > > > > > > > > > > > > > - device-config : device configuration information > > > > > > > (specified as byte > > > > > > > array). Maximum size is 240 bytes. > > > > > > > + - esd-recovery-timeout-ms : ESD poll time (in milli seconds) > > > > > > > for the driver to > > > > > > > + check if ESD occurred and in that > > > > > > > case reset the > > > > > > > + device. ESD is disabled if this > > > > > > > property is not set > > > > > > > + or is set to 0. > > > > > > > > > > > > This sounds like software configuration rather than HW description. > > > > > > Is > > > > > >
RE: [PATCH v3 3/5] Input: goodix - add power management support
> -Original Message-
> From: linux-input-ow...@vger.kernel.org
> [mailto:linux-input-ow...@vger.kernel.org] On Behalf Of Bastien Nocera
> Sent: 30 June, 2015 18:56
> To: Tirdea, Irina; Dmitry Torokhov; Mark Rutland;
> linux-in...@vger.kernel.org; devicet...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org; Rob Herring; Pawel Moll; Ian Campbell;
> Kumar Gala; Purdila, Octavian
> Subject: Re: [PATCH v3 3/5] Input: goodix - add power management support
>
> On Mon, 2015-06-29 at 19:28 +0300, Irina Tirdea wrote:
> > Implement suspend/resume for goodix driver.
> >
> > The suspend and resume process uses the gpio pins.
> > If the device ACPI/DT information does not declare gpio pins,
> > suspend/resume will not be available for these devices.
> >
> > This is based on Goodix datasheets for GT911 and GT9271
> > and on Goodix driver gt9xx.c for Android (publicly available
> > in Android kernel trees for various devices).
>
> How can I functionally test this?
We are testing the power management feature by putting the system
in suspend and measuring the power consumed by the touchscreen
using HW measurement tools.
I can send a set of patches that export an interface to put
the touchscreen into suspend from sysfs (something similar to
what ads7846 has). In this way you can test what happens to
the touchscreen alone without putting the entire system into
suspend.
When suspending the device you will see that there are no events
received from the touchscreen (the interrupt is unregistered before
suspending the device). To actually check that the device
has been suspended and is not consuming power you need to measure
the power consumed by the touchscreen. To do that entirely from
software, you could compare the power consumed by the battery when the
touchscreen is powered on with the power consumed by the battery
when the touchscreen is powered off (batteries export interfaces in
sysfs that can be used for that). The difference should match the
device specifications. I am doing some tests to see how that works,
but I am not getting the expected results so far (seems there are other
components that affect the measurements). I will look more into this and
come back with details if you think this would work for you.
Thanks,
Irina
> --
> To unsubscribe from this list: send the line "unsubscribe linux-input" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�&j:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
RE: [PATCH v3 1/5] Input: goodix - reset device at init
> -Original Message- > From: Bastien Nocera [mailto:had...@hadess.net] > Sent: 30 June, 2015 18:57 > To: Tirdea, Irina; Dmitry Torokhov; Mark Rutland; > linux-in...@vger.kernel.org; devicet...@vger.kernel.org > Cc: linux-kernel@vger.kernel.org; Rob Herring; Pawel Moll; Ian Campbell; > Kumar Gala; Purdila, Octavian > Subject: Re: [PATCH v3 1/5] Input: goodix - reset device at init > > On Mon, 2015-06-29 at 19:28 +0300, Irina Tirdea wrote: > > After power on, it is recommended that the driver resets the device. > > The reset procedure timing is described in the datasheet and is used > > at device init (before writing device configuration) and > > for power management. It is a sequence of setting the interrupt > > and reset pins high/low at specific timing intervals. This procedure > > also includes setting the slave address to the one specified in the > > ACPI/device tree. > > > > This is based on Goodix datasheets for GT911 and GT9271 and on Goodix > > driver gt9xx.c for Android (publicly available in Android kernel > > trees for various devices). > > > > For reset the driver needs to control the interrupt and > > reset gpio pins (configured through ACPI/device tree). For devices > > that do not have the gpio pins declared, the functionality depending > > on these pins will not be available, but the device can still be used > > with basic functionality. > > > I'm having a little trouble with this first patch, on a 4.2 "pre" Linus > tree and on a 4.1 kernel. > > [6.720214] [ cut here ] > [6.720230] WARNING: CPU: 2 PID: 475 at > drivers/pinctrl/intel/pinctrl-baytrail.c:338 > byt_gpio_direction_output+0x97/0xa0() > [6.720234] Potential Error: Setting GPIO with direct_irq_en to output > [6.720238] Modules linked in: > [6.720241] regmap_i2c intel_soc_dts_iosf int340x_thermal_zone soundcore > industrialio battery iosf_mbi acpi_thermal_rel > dell_smo8800 snd_soc_sst_acpi goodix_backport(OE+) i2c_hid acpi_pad ac > rfkill_gpio i2c_designware_platform rfkill > pwm_lpss_platform pwm_lpss i2c_designware_core nfsd auth_rpcgss nfs_acl lockd > grace sunrpc i915 mmc_block i2c_algo_bit > drm_kms_helper drm video sdhci_acpi sdhci mmc_core > [6.720292] CPU: 2 PID: 475 Comm: systemd-udevd Tainted: GW OE > 4.2.0-0.rc0.git2.2.fc22.i686 #1 > [6.720295] Hardware name: To be filled by O.E.M. To be filled by > O.E.M./Aptio CRB, BIOS 5.6.5 07/25/2014 > [6.720299] c0d39967 11197204 f6d37bc8 c0a9ce3c f6d37c08 > f6d37bf8 c045c677 > [6.720311] c0cb62a4 f6d37c28 01db c0cb62e0 0152 c073bfc7 > c073bfc7 f7c580b8 > [6.720321] f441409c f7c580b0 f6d37c14 c045c6ee 0009 f6d37c08 > c0cb62a4 f6d37c28 > [6.720331] Call Trace: > [6.720342] [] dump_stack+0x41/0x52 > [6.720349] [] warn_slowpath_common+0x87/0xc0 > [6.720355] [] ? byt_gpio_direction_output+0x97/0xa0 > [6.720360] [] ? byt_gpio_direction_output+0x97/0xa0 > [6.720365] [] warn_slowpath_fmt+0x3e/0x60 > [6.720370] [] byt_gpio_direction_output+0x97/0xa0 > [6.720376] [] ? byt_gpio_irq_handler+0xc0/0xc0 > [6.720382] [] _gpiod_direction_output_raw+0x59/0x1c0 > [6.720388] [] ? _raw_spin_unlock_irqrestore+0xd/0x10 > [6.720393] [] ? byt_gpio_direction_input+0x43/0x50 > [6.720398] [] ? byt_gpio_set+0x70/0x70 > [6.720404] [] gpiod_direction_output+0x2a/0x50 > [6.720413] [] goodix_ts_probe+0x2fb/0x5fd [goodix_backport] > [6.720422] [] i2c_device_probe+0x101/0x1b0 > [6.720428] [] ? sysfs_create_link+0x25/0x50 > [6.720436] [] ? goodix_ts_irq_handler+0x1f0/0x1f0 > [goodix_backport] > [6.720442] [] ? driver_sysfs_add+0x62/0x80 > [6.720448] [] driver_probe_device+0x1ca/0x460 > [6.720454] [] ? driver_probe_device+0x460/0x460 > [6.720461] [] ? acpi_driver_match_device+0x36/0x3f > [6.720467] [] __driver_attach+0x79/0x80 > [6.720473] [] ? driver_probe_device+0x460/0x460 > [6.720478] [] bus_for_each_dev+0x57/0xa0 > [6.720484] [] driver_attach+0x1e/0x20 > [6.720489] [] ? driver_probe_device+0x460/0x460 > [6.720494] [] bus_add_driver+0x1ef/0x290 > [6.720501] [] ? 0xf7ca7000 > [6.720506] [] ? 0xf7ca7000 > [6.720512] [] driver_register+0x5d/0xf0 > [6.720518] [] i2c_register_driver+0x2a/0xa0 > [6.720524] [] ? do_one_initcall+0x9f/0x200 > [6.720531] [] goodix_ts_driver_init+0x12/0x1000 > [goodix_backport] > [6.720536] [] do_one_initcall+0xaa/0x200 > [6.720541] [] ? 0xf7ca7000 > [6.720547] [] ? free_vmap_area_noflush+0x38/0x80 > [6.720554] [] ? kmem_cache_alloc_trace+0x
RE: [PATCH 2/2] tools: iio: print error message when buffer enable fails
> -Original Message-
> From: Hartmut Knaack [mailto:knaac...@gmx.de]
> Sent: 24 July, 2015 2:13
> To: Tirdea, Irina; Jonathan Cameron; linux-...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Subject: Re: [PATCH 2/2] tools: iio: print error message when buffer enable
> fails
>
> Irina Tirdea schrieb am 23.07.2015 um 19:22:
> > Running generic_buffer without enabling any channel of the
> > sensor will fail without printing any error message.
> >
> > Add an error message that indicates buffer enable failed.
>
> Hi,
> please make use of the error code stored in ret (with negative sign), as
> in most cases the value of errno has already changed since the original
> error has occurred.
> Thanks,
>
Hi Hartmut,
Yes, you are right. Missed that. Will fix in v2.
Thanks,
Irina
> Hartmut
>
> >
> > Signed-off-by: Irina Tirdea
> > ---
> > tools/iio/generic_buffer.c | 5 -
> > 1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/tools/iio/generic_buffer.c b/tools/iio/generic_buffer.c
> > index 32f389eb..936469c 100644
> > --- a/tools/iio/generic_buffer.c
> > +++ b/tools/iio/generic_buffer.c
> > @@ -364,8 +364,11 @@ int main(int argc, char **argv)
> >
> > /* Enable the buffer */
> > ret = write_sysfs_int("enable", buf_dir_name, 1);
> > - if (ret < 0)
> > + if (ret < 0) {
> > + fprintf(stderr,
> > + "Failed to enable buffer: %s\n", strerror(errno));
> > goto error_free_buf_dir_name;
> > + }
> >
> > scan_size = size_from_channelarray(channels, num_channels);
> > data = malloc(scan_size * buf_len);
> >
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v3 6/8] iio: gyro: bmg160: optimize i2c transfers in trigger handler
> -Original Message-
> From: Jonathan Cameron [mailto:ji...@kernel.org]
> Sent: 05 July, 2015 15:08
> To: Tirdea, Irina; Wolfram Sang; linux-...@vger.kernel.org;
> linux-...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org; Pandruvada, Srinivas; Peter Meerwald
> Subject: Re: [PATCH v3 6/8] iio: gyro: bmg160: optimize i2c transfers in
> trigger handler
>
> On 03/07/15 10:33, Irina Tirdea wrote:
> > Some i2c busses (e.g.: Synopsys DesignWare I2C adapter) need to
> > enable/disable the bus at each i2c transfer and must wait for
> > the enable/disable to happen before sending the data.
> >
> > When reading data in the trigger handler, the bmg160 driver does
> > one i2c transfer for each axis. This has an impact on the frequency
> > of the gyroscope at high sample rates due to additional delays
> > introduced by the i2c bus at each transfer.
> >
> > Reading all axis values in one i2c transfer reduces the delays
> > introduced by the i2c bus. Uses i2c_smbus_read_i2c_block_data_or_emulated
> > that will fallback to reading each axis as a separate word in case i2c
> > block read is not supported.
> >
> > Signed-off-by: Irina Tirdea
> Acked-by: Jonathan Cameron
>
Thanks Jonathan!
> Obviously you'll ideally pick up Ack's from the driver authors /maintainers
> as well.
>
Srinivas, are you OK with these changes for bmc150, bmg160 and kxcjk-1013?
Thanks,
Irina
> Jonathan
> > ---
> > drivers/iio/gyro/bmg160.c | 18 --
> > 1 file changed, 8 insertions(+), 10 deletions(-)
> >
> > diff --git a/drivers/iio/gyro/bmg160.c b/drivers/iio/gyro/bmg160.c
> > index 4b423f2..04e15e9 100644
> > --- a/drivers/iio/gyro/bmg160.c
> > +++ b/drivers/iio/gyro/bmg160.c
> > @@ -784,6 +784,7 @@ static const struct iio_event_spec bmg160_event = {
> > .sign = 's',\
> > .realbits = 16, \
> > .storagebits = 16, \
> > + .endianness = IIO_LE, \
> > }, \
> > .event_spec = &bmg160_event,\
> > .num_event_specs = 1\
> > @@ -822,19 +823,16 @@ static irqreturn_t bmg160_trigger_handler(int irq,
> > void *p)
> > struct iio_poll_func *pf = p;
> > struct iio_dev *indio_dev = pf->indio_dev;
> > struct bmg160_data *data = iio_priv(indio_dev);
> > - int bit, ret, i = 0;
> > + int ret = 0;
> >
> > mutex_lock(&data->mutex);
> > - for (bit = 0; bit < AXIS_MAX; bit++) {
> > - ret = i2c_smbus_read_word_data(data->client,
> > - BMG160_AXIS_TO_REG(bit));
> > - if (ret < 0) {
> > - mutex_unlock(&data->mutex);
> > - goto err;
> > - }
> > - data->buffer[i++] = ret;
> > - }
> > + ret = i2c_smbus_read_i2c_block_data_or_emulated(data->client,
> > + BMG160_REG_XOUT_L,
> > + AXIS_MAX * 2,
> > + (u8 *)data->buffer);
> > mutex_unlock(&data->mutex);
> > + if (ret < 0)
> > + goto err;
> >
> > iio_push_to_buffers_with_timestamp(indio_dev, data->buffer,
> >data->timestamp);
> >
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v3 1/8] i2c: core: Add support for best effort block read emulation
> -Original Message-
> From: Jonathan Cameron [mailto:ji...@kernel.org]
> Sent: 05 July, 2015 14:59
> To: Tirdea, Irina; Wolfram Sang; linux-...@vger.kernel.org;
> linux-...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org; Pandruvada, Srinivas; Peter Meerwald
> Subject: Re: [PATCH v3 1/8] i2c: core: Add support for best effort block read
> emulation
>
> On 03/07/15 10:33, Irina Tirdea wrote:
> > There are devices that need to handle block transactions
> > regardless of the capabilities exported by the adapter.
> > For performance reasons, they need to use i2c read blocks
> > if available, otherwise emulate the block transaction with word
> > or byte transactions.
> >
> > Add support for a helper function that would read a data block
> > using the best transfer available: I2C_FUNC_SMBUS_READ_I2C_BLOCK,
> > I2C_FUNC_SMBUS_READ_WORD_DATA or I2C_FUNC_SMBUS_READ_BYTE_DATA.
> >
> > Signed-off-by: Irina Tirdea
> Looks good to me - I vaguely wondered if it would make sense to use
> an endian conversion in the word case, but as we have possible odd
> numbers of bytes that gets fiddly.
>
Thanks for the review, Jonathan!
> I wonder what devices do if you do a word read beyond their end address?
> Perhaps in odd cases we should always fall back to byte reads?
In my tests I can read beyond the end address, but I cannot be sure if this is
OK for all
devices. This was actually a suggestion from Wolfram for v1, but maybe I'm
missing
something.
Wolfram, is it safe to read one byte beyond the end address or should I better
use
only byte reads for odd lengths?
>
> > ---
> > drivers/i2c/i2c-core.c | 60
> > ++
> > include/linux/i2c.h| 3 +++
> > 2 files changed, 63 insertions(+)
> >
> > diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
> > index 96771ea..55a3455 100644
> > --- a/drivers/i2c/i2c-core.c
> > +++ b/drivers/i2c/i2c-core.c
> > @@ -2914,6 +2914,66 @@ trace:
> > }
> > EXPORT_SYMBOL(i2c_smbus_xfer);
> >
> > +/**
> > + * i2c_smbus_read_i2c_block_data_or_emulated - read block or emulate
> > + * @client: Handle to slave device
> > + * @command: Byte interpreted by slave
> > + * @length: Size of data block; SMBus allows at most 32 bytes
> > + * @values: Byte array into which data will be read; big enough to hold
> > + * the data returned by the slave. SMBus allows at most 32 bytes.
> > + *
> > + * This executes the SMBus "block read" protocol if supported by the
> > adapter.
> > + * If block read is not supported, it emulates it using either word or byte
> > + * read protocols depending on availability.
> > + *
> > + * Before using this function you must double-check if the I2C slave does
> > + * support exchanging a block transfer with a byte transfer.
> Add something here about addressing assumptions. You get odd devices which
> will give bulk reads of addresses not mapped to a nice linear region when
> you do byte reads.
OK, I'll add this to the comment above:
"The addresses of the I2C slave device that are accessed with this function
must be mapped to a linear region, so that a block read will have the same
effect as a byte read."
Thanks,
Irina
> > + */
> > +s32 i2c_smbus_read_i2c_block_data_or_emulated(const struct i2c_client
> > *client,
> > + u8 command, u8 length, u8 *values)
> > +{
> > + u8 i;
> > + int status;
> > +
> > + if (length > I2C_SMBUS_BLOCK_MAX)
> > + length = I2C_SMBUS_BLOCK_MAX;
> > +
> > + if (i2c_check_functionality(client->adapter,
> > + I2C_FUNC_SMBUS_READ_I2C_BLOCK)) {
> > + return i2c_smbus_read_i2c_block_data(client, command,
> > +length, values);
> > + } else if (i2c_check_functionality(client->adapter,
> > + I2C_FUNC_SMBUS_READ_WORD_DATA)) {
> > + for (i = 0; i < length; i += 2) {
> > + status = i2c_smbus_read_word_data(client, command + i);
> > + if (status < 0)
> > + return status;
> > + values[i] = status & 0xff;
> > + if ((i + 1) < length)
> > + values[i + 1] = status >> 8;
> > + }
> > + if (i > length)
> > + return length;
> > + return i;
> > + } else if (i2c_check_functionality(client->adapte
RE: [PATCH v2 4/8] input: goodix: reset device at init
> -Original Message- > From: Octavian Purdila [mailto:octavian.purd...@intel.com] > Sent: 23 June, 2015 17:51 > To: Bastien Nocera > Cc: Tirdea, Irina; Dmitry Torokhov; Mark Rutland; > linux-in...@vger.kernel.org; devicet...@vger.kernel.org; linux- > ker...@vger.kernel.org; Rob Herring; Pawel Moll; Ian Campbell; Kumar Gala > Subject: Re: [PATCH v2 4/8] input: goodix: reset device at init > > On Tue, Jun 23, 2015 at 5:12 PM, Bastien Nocera wrote: > > > > On Tue, 2015-06-23 at 13:23 +, Tirdea, Irina wrote: > > > > > > > -Original Message- > > > > From: linux-input-ow...@vger.kernel.org [mailto: > > > > linux-input-ow...@vger.kernel.org] On Behalf Of Bastien Nocera > > > > Sent: 09 June, 2015 18:53 > > > > To: Tirdea, Irina > > > > Cc: Dmitry Torokhov; Mark Rutland; linux-in...@vger.kernel.org; > > > > devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; Rob > > > > Herring; Pawel Moll; Ian Campbell; Kumar Gala; Purdila, Octavian > > > > Subject: Re: [PATCH v2 4/8] input: goodix: reset device at init > > > > > > > > On Tue, 2015-06-09 at 17:34 +0200, Bastien Nocera wrote: > > > > > On Mon, 2015-06-08 at 17:37 +0300, Irina Tirdea wrote: > > > > > > After power on, it is recommended that the driver resets the > > > > > > device. > > > > > > The reset procedure timing is described in the datasheet and is > > > > > > used > > > > > > at device init (before writing device configuration) and > > > > > > for power management. It is a sequence of setting the interrupt > > > > > > and reset pins high/low at specific timing intervals. This > > > > > > procedure > > > > > > also includes setting the slave address to the one specified in > > > > > > the > > > > > > ACPI/device tree. > > > > > > > > > > This breaks the touchscreen on my Onda v975w: > > > > > [ 239.732858] Goodix-TS i2c-GDIX1001:00: ID 9271, version: 1020 > > > > > [ 239.732977] Goodix-TS i2c-GDIX1001:00: Failed to get reset > > > > > GPIO: > > > > > -16 > > > > > [ 239.736071] Goodix-TS: probe of i2c-GDIX1001:00 failed with > > > > > error > > > > > -16 > > > > > > > > > > This is the DSDT for that device: > > > > > https://bugzilla.kernel.org/attachment.cgi?id=149331 > > > > > > > > > > Oops. That's right - I am using named interrupts which are available > > > only for ACPI 5.1, so > > > devices already out there will not work. > > > > > > The problem here is that handling -ENOENT will not help. The gpio > > > pins are declared in the > > > ACPI DSDT, but are not named. The devm_gpiod_get API will look for > > > the named interrupt > > > first and fallback to searching by index if not found. Index will be > > > 0 in both cases, this is why > > > the first call will succeed and the second will fail with -EBUSY. > > > > > > One way to handle this would be to use indexed gpio pins instead of > > > named gpio pins: > > > e.g. consider the first gpio pin to be the reset pin and the second > > > to be the interrupt pin. > > > This is used in other drivers as well, e.g. zforce_ts. The problem > > > with this approach is that > > > any devices that declare the gpio pins in reversed order in the DSDT > > > will not work and give > > > no warning (the pins will be requested successfully, but some of the > > > functionality will not > > > work). The DSDT mentioned in > > > https://bugzilla.kernel.org/attachment.cgi?id=149331 lists > > > the reset pin first, while I am working on some devices that declare > > > the interrupt gpio pin > > > first. > > > > > > Another way to handle this is to treat -EBUSY like -ENOENT and not > > > use any functionality > > > that depends on the gpio pins. Unfortunately, this means we will not > > > have suspend, esd and > > > custom configs even if the pins are connected on the board and > > > available in ACPI(just not > > > named). > > > > > > I would go with the first approach and document the order requested > > > for the pins, but I would > > > like to hear what you think first. Is there a better way to do this? > > > > > > > (Note that this means that I haven't been able to test any > > > > following > > > > patches in that series than 4/8). > > > > > > Sure, that makes sense. The following patches depend on the gpio pins > > > so they would not have > > > worked either. > > > > We can apply quirks based on DMI information, so that devices with ACPI > > in different orders will work after applying a quirk (as long as > > there's a way to detect that it's in the wrong order, obviously). > > > > I think even using the ACPI id (_HID) should be enough (at least in > the cases we know so far) to make the difference in how the pins are > used. Thanks for the suggestions Bastien and Octavian! I will use the ACPI ID in v3 considering the ACPI table Bastien has mentioned [1]. Thanks, Irina [1] https://bugzilla.kernel.org/attachment.cgi?id=149331
RE: [PATCH v2 5/8] input: goodix: write configuration data to device
> -Original Message- > From: Dmitry Torokhov [mailto:dmitry.torok...@gmail.com] > Sent: 23 June, 2015 21:59 > To: Tirdea, Irina > Cc: Bastien Nocera; Mark Rutland; linux-in...@vger.kernel.org; > devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; Rob > Herring; Pawel Moll; Ian Campbell; Kumar Gala; Purdila, Octavian > Subject: Re: [PATCH v2 5/8] input: goodix: write configuration data to device > > On Tue, Jun 23, 2015 at 01:27:01PM +, Tirdea, Irina wrote: > > > > > > > -Original Message- > > > From: linux-input-ow...@vger.kernel.org > > > [mailto:linux-input-ow...@vger.kernel.org] On Behalf Of Dmitry Torokhov > > > Sent: 09 June, 2015 21:14 > > > To: Tirdea, Irina > > > Cc: Bastien Nocera; Mark Rutland; linux-in...@vger.kernel.org; > > > devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; Rob > > > Herring; Pawel Moll; Ian Campbell; Kumar Gala; Purdila, Octavian > > > Subject: Re: [PATCH v2 5/8] input: goodix: write configuration data to > > > device > > > > > > Hi Irina, > > > > > > > Hi Dmitry, > > > > > On Mon, Jun 08, 2015 at 05:37:50PM +0300, Irina Tirdea wrote: > > > > Goodix devices can be configured by writing custom data to the device at > > > > init. The configuration data is read with request_firmware from > > > > "goodix__cfg.bin", where is the product id read from the device > > > > (e.g.: goodix_911_cfg.bin for Goodix GT911, goodix_9271_cfg.bin for > > > > GT9271). > > > > > > > > The configuration information has a specific format described in the > > > > Goodix > > > > datasheet. It includes X/Y resolution, maximum supported touch points, > > > > interrupt flags, various sesitivity factors and settings for advanced > > > > features (like gesture recognition). > > > > > > > > This is based on Goodix datasheets for GT911 and GT9271 and on Goodix > > > > driver gt9xx.c for Android (publicly available in Android kernel > > > > trees for various devices). > > > > > > I am afraid that just using request_firmware() in probe() is not the > > > best option as it may cause either errors or delays in > > > initialization of the driver is compiled into the kernel and tries to > > > initialize before filesystem with configuration file is mounted (and > > > firmware is not built into the kernel). We can either try switch to > > > request_firmware_nowait() or at least document that we need firmware at > > > boot. > > > > > > > The reason I did not use request_firmware_nowait() is that this > > configuration data > > includes information needed by probe (x/y resolution, interrupt trigger > > type, max > > touch num), used in goodix_read_config, goodix_ts_report_touch and for irq > > flags > > when requesting the interrupt. I will document that we need this > > configuration > > firmware at boot in the commit message and add a comment in the code. > > Is there any other documentation I need to update? > > > > > > > > > > Signed-off-by: Octavian Purdila > > > > Signed-off-by: Irina Tirdea > > > > --- > > > > drivers/input/touchscreen/goodix.c | 128 > > > > + > > > > 1 file changed, 128 insertions(+) > > > > > > > > diff --git a/drivers/input/touchscreen/goodix.c > > > > b/drivers/input/touchscreen/goodix.c > > > > index c345eb7..1ce9278 100644 > > > > --- a/drivers/input/touchscreen/goodix.c > > > > +++ b/drivers/input/touchscreen/goodix.c > > > > @@ -24,6 +24,7 @@ > > > > #include > > > > #include > > > > #include > > > > +#include > > > > #include > > > > #include > > > > #include > > > > @@ -95,6 +96,39 @@ static int goodix_i2c_read(struct i2c_client *client, > > > > return ret < 0 ? ret : (ret != ARRAY_SIZE(msgs) ? -EIO : 0); > > > > } > > > > > > > > +/** > > > > + * goodix_i2c_write - write data to a register of the i2c slave device. > > > > + * > > > > + * @client: i2c device. > > > > + * @reg: the register to write to. > > > > + * @buf: raw data buffer to write. > > > > + * @len: length of the buffer to write > > > > + */ > > > > +static int
RE: [PATCH v2 14/17] iio: accel: mma9551_core: use size in words for word buffers
> -Original Message-
> From: Jonathan Cameron [mailto:ji...@kernel.org]
> Sent: 14 June, 2015 18:01
> To: Tirdea, Irina; linux-...@vger.kernel.org; Hartmut Knaack
> Cc: linux-kernel@vger.kernel.org; Dogaru, Vlad
> Subject: Re: [PATCH v2 14/17] iio: accel: mma9551_core: use size in words for
> word buffers
>
> On 29/04/15 13:20, Tirdea, Irina wrote:
> >
> >
> >> -Original Message-
> >> From: Jonathan Cameron [mailto:ji...@kernel.org]
> >> Sent: 26 April, 2015 22:05
> >> To: Tirdea, Irina; linux-...@vger.kernel.org; Hartmut Knaack
> >> Cc: linux-kernel@vger.kernel.org; Dogaru, Vlad
> >> Subject: Re: [PATCH v2 14/17] iio: accel: mma9551_core: use size in words
> >> for word buffers
> >>
> >> On 13/04/15 16:41, Irina Tirdea wrote:
> >>> Change the prototype for the mma9551_read/write_*_words functions
> >>> to receive the length of the buffer in words (instead of bytes) since
> >>> we are using a word buffer. This will prevent users from sending an
> >>> odd number of bytes for a word array.
> >>>
> >>> Signed-off-by: Irina Tirdea
> >> Lots of merge issues by this point in the series so I'll hold this one at
> >> least until the fixes filter through.
> >>
> >> Remind me if I seem to have forgotten (it wouldn't be the first time :)
> >>
> > Sure, I'll keep an eye on when the fixes will be merged in togreg branch.
> >
> They are there now, so applied to the togreg branch of iio.git, initially
> pushed
> out as testing for the autobuilders to play with it.
>
> Now looking at the merge window in 3 months time though to go upstream
> unfortunately.
> Sorry for the delay, been a busy couple of months!
>
No problem, thanks for keeping an eye on when the fixes got merged.
Thanks,
Irina
> Jonathan
> > Thanks,
> > Irina
> >
> >> Jonathan
> >>> ---
> >>> drivers/iio/accel/mma9551_core.c | 27 ---
> >>> drivers/iio/accel/mma9553.c | 9 ++---
> >>> 2 files changed, 18 insertions(+), 18 deletions(-)
> >>>
> >>> diff --git a/drivers/iio/accel/mma9551_core.c
> >>> b/drivers/iio/accel/mma9551_core.c
> >>> index 2fd2a99..583660b 100644
> >>> --- a/drivers/iio/accel/mma9551_core.c
> >>> +++ b/drivers/iio/accel/mma9551_core.c
> >>> @@ -373,7 +373,7 @@ EXPORT_SYMBOL(mma9551_read_status_word);
> >>> * @client: I2C client
> >>> * @app_id: Application ID
> >>> * @reg: Application register
> >>> - * @len: Length of array to read in bytes
> >>> + * @len: Length of array to read (in words)
> >>> * @buf: Array of words to read
> >>> *
> >>> * Read multiple configuration registers (word-sized registers).
> >>> @@ -388,20 +388,19 @@ int mma9551_read_config_words(struct i2c_client
> >>> *client, u8 app_id,
> >>>u16 reg, u8 len, u16 *buf)
> >>> {
> >>> int ret, i;
> >>> - int len_words = len / sizeof(u16);
> >>> __be16 be_buf[MMA9551_MAX_MAILBOX_DATA_REGS / 2];
> >>>
> >>> - if (len_words > ARRAY_SIZE(be_buf)) {
> >>> + if (len > ARRAY_SIZE(be_buf)) {
> >>> dev_err(&client->dev, "Invalid buffer size %d\n", len);
> >>> return -EINVAL;
> >>> }
> >>>
> >>> ret = mma9551_transfer(client, app_id, MMA9551_CMD_READ_CONFIG,
> >>> -reg, NULL, 0, (u8 *) be_buf, len);
> >>> +reg, NULL, 0, (u8 *)be_buf, len * sizeof(u16));
> >>> if (ret < 0)
> >>> return ret;
> >>>
> >>> - for (i = 0; i < len_words; i++)
> >>> + for (i = 0; i < len; i++)
> >>> buf[i] = be16_to_cpu(be_buf[i]);
> >>>
> >>> return 0;
> >>> @@ -413,7 +412,7 @@ EXPORT_SYMBOL(mma9551_read_config_words);
> >>> * @client: I2C client
> >>> * @app_id: Application ID
> >>> * @reg: Application register
> >>> - * @len: Length of array to read in bytes
> >>> + * @len: Length of array to read (in words)
> >>> * @buf: Array of words to read
> >>> *
> >>> * Read multiple status registers (word-sized registers).
> >>> @@ -428,20 +427,19 @@ int mma9551_read_status_words(struct i2c_client
&g
RE: [PATCH v2 17/17] iio: accel: mma9553: use unsigned counters
> -Original Message-
> From: Jonathan Cameron [mailto:ji...@kernel.org]
> Sent: 14 June, 2015 18:04
> To: Tirdea, Irina; linux-...@vger.kernel.org; Hartmut Knaack
> Cc: linux-kernel@vger.kernel.org; Dogaru, Vlad
> Subject: Re: [PATCH v2 17/17] iio: accel: mma9553: use unsigned counters
>
> On 13/04/15 16:41, Irina Tirdea wrote:
> > Use unsigned counters instead of signed when all the
> > possible values are positive.
> >
> > Signed-off-by: Irina Tirdea
> > Suggested-by: Hartmut Knaack
> Hmm. I'm actually going to drop this one. I'm not sure
> there is a significant gain to be had by using minimal
> sized integers as loop iterators.
>
> int is just fine.
>
Fair enough, wasn't sure about this one either.
Thanks,
Irina
> Jonathan
> > ---
> > drivers/iio/accel/mma9551_core.c | 12 +++-
> > drivers/iio/accel/mma9553.c | 8
> > 2 files changed, 11 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/iio/accel/mma9551_core.c
> > b/drivers/iio/accel/mma9551_core.c
> > index c34c5ce..44b8243 100644
> > --- a/drivers/iio/accel/mma9551_core.c
> > +++ b/drivers/iio/accel/mma9551_core.c
> > @@ -115,8 +115,8 @@ struct mma9551_version_info {
> >
> > static int mma9551_transfer(struct i2c_client *client,
> > u8 app_id, u8 command, u16 offset,
> > - u8 *inbytes, int num_inbytes,
> > - u8 *outbytes, int num_outbytes)
> > + u8 *inbytes, u8 num_inbytes,
> > + u8 *outbytes, u8 num_outbytes)
> > {
> > struct mma9551_mbox_request req;
> > struct mma9551_mbox_response rsp;
> > @@ -387,7 +387,8 @@ EXPORT_SYMBOL(mma9551_read_status_word);
> > int mma9551_read_config_words(struct i2c_client *client, u8 app_id,
> > u16 reg, u8 len, u16 *buf)
> > {
> > - int ret, i;
> > + int ret;
> > + u8 i;
> > __be16 be_buf[MMA9551_MAX_MAILBOX_DATA_REGS / 2];
> >
> > if (len > ARRAY_SIZE(be_buf)) {
> > @@ -426,7 +427,8 @@ EXPORT_SYMBOL(mma9551_read_config_words);
> > int mma9551_read_status_words(struct i2c_client *client, u8 app_id,
> > u16 reg, u8 len, u16 *buf)
> > {
> > - int ret, i;
> > + int ret;
> > + u8 i;
> > __be16 be_buf[MMA9551_MAX_MAILBOX_DATA_REGS / 2];
> >
> > if (len > ARRAY_SIZE(be_buf)) {
> > @@ -465,7 +467,7 @@ EXPORT_SYMBOL(mma9551_read_status_words);
> > int mma9551_write_config_words(struct i2c_client *client, u8 app_id,
> >u16 reg, u8 len, u16 *buf)
> > {
> > - int i;
> > + u8 i;
> > __be16 be_buf[(MMA9551_MAX_MAILBOX_DATA_REGS - 1) / 2];
> >
> > if (len > ARRAY_SIZE(be_buf)) {
> > diff --git a/drivers/iio/accel/mma9553.c b/drivers/iio/accel/mma9553.c
> > index a605280..ad587ec 100644
> > --- a/drivers/iio/accel/mma9553.c
> > +++ b/drivers/iio/accel/mma9553.c
> > @@ -189,7 +189,7 @@ struct mma9553_data {
> > struct mutex mutex;
> > struct mma9553_conf_regs conf;
> > struct mma9553_event events[MMA9553_EVENTS_INFO_SIZE];
> > - int num_events;
> > + u8 num_events;
> > u8 gpio_bitnum;
> > /*
> > * This is used for all features that depend on step count:
> > @@ -230,7 +230,7 @@ static enum iio_modifier mma9553_activity_to_mod(enum
> > activity_level activity)
> >
> > static void mma9553_init_events(struct mma9553_data *data)
> > {
> > - int i;
> > + u8 i;
> >
> > data->num_events = MMA9553_EVENTS_INFO_SIZE;
> > for (i = 0; i < data->num_events; i++) {
> > @@ -244,7 +244,7 @@ static struct mma9553_event *mma9553_get_event(struct
> > mma9553_data *data,
> >enum iio_modifier mod,
> >enum iio_event_direction dir)
> > {
> > - int i;
> > + u8 i;
> >
> > for (i = 0; i < data->num_events; i++)
> > if (data->events[i].info->type == type &&
> > @@ -259,7 +259,7 @@ static bool mma9553_is_any_event_enabled(struct
> > mma9553_data *data,
> > bool check_type,
> > enum iio_chan_type type)
> > {
> > - int i;
> > + u8 i;
> >
> > for (i = 0; i < data->num_events; i++)
> > if ((check_type && data->events[i].info->type == type &&
> >
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v2 6/8] input: goodix: add power management support
> -Original Message-
> From: Dmitry Torokhov [mailto:dmitry.torok...@gmail.com]
> Sent: 09 June, 2015 21:16
> To: Tirdea, Irina
> Cc: Bastien Nocera; Mark Rutland; linux-in...@vger.kernel.org;
> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; Rob
> Herring; Pawel Moll; Ian Campbell; Kumar Gala; Purdila, Octavian
> Subject: Re: [PATCH v2 6/8] input: goodix: add power management support
>
> On Mon, Jun 08, 2015 at 05:37:51PM +0300, Irina Tirdea wrote:
> > Implement suspend/resume for goodix driver.
> >
> > This is based on Goodix datasheets for GT911 and GT9271
> > and on Goodix driver gt9xx.c for Android (publicly available
> > in Android kernel trees for various devices).
> >
> > Signed-off-by: Octavian Purdila
> > Signed-off-by: Irina Tirdea
> > ---
> > drivers/input/touchscreen/goodix.c | 88
> > +++---
> > 1 file changed, 83 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/input/touchscreen/goodix.c
> > b/drivers/input/touchscreen/goodix.c
> > index 1ce9278..903c83d 100644
> > --- a/drivers/input/touchscreen/goodix.c
> > +++ b/drivers/input/touchscreen/goodix.c
> > @@ -38,6 +38,7 @@ struct goodix_ts_data {
> > unsigned int int_trigger_type;
> > struct gpio_desc *gpiod_int;
> > struct gpio_desc *gpiod_rst;
> > + unsigned long irq_flags;
> > };
> >
> > #define GOODIX_GPIO_INT_NAME "irq"
> > @@ -52,6 +53,9 @@ struct goodix_ts_data {
> > #define GOODIX_CONFIG_MAX_LENGTH 240
> >
> > /* Register defines */
> > +#define GOODIX_REG_COMMAND 0x8040
> > +#define GOODIX_CMD_SCREEN_OFF 0x05
> > +
> > #define GOODIX_READ_COOR_ADDR 0x814E
> > #define GOODIX_REG_CONFIG_DATA 0x8047
> > #define GOODIX_REG_ID 0x8140
> > @@ -129,6 +133,11 @@ static int goodix_i2c_write(struct i2c_client *client,
> > u16 reg, const u8 *buf,
> > return ret < 0 ? ret : (ret != 1 ? -EIO : 0);
> > }
> >
> > +static int goodix_i2c_write_u8(struct i2c_client *client, u16 reg, u8
> > value)
> > +{
> > + return goodix_i2c_write(client, reg, &value, sizeof(value));
> > +}
> > +
> > static int goodix_ts_read_input_report(struct goodix_ts_data *ts, u8 *data)
> > {
> > int touch_num;
> > @@ -226,6 +235,18 @@ static irqreturn_t goodix_ts_irq_handler(int irq, void
> > *dev_id)
> > return IRQ_HANDLED;
> > }
> >
> > +static void goodix_free_irq(struct goodix_ts_data *ts)
> > +{
> > + devm_free_irq(&ts->client->dev, ts->client->irq, ts);
> > +}
> > +
> > +static int goodix_request_irq(struct goodix_ts_data *ts)
> > +{
> > + return devm_request_threaded_irq(&ts->client->dev, ts->client->irq,
> > +NULL, goodix_ts_irq_handler,
> > +ts->irq_flags, ts->client->name, ts);
> > +}
> > +
> > /**
> > * goodix_check_cfg - Checks if config buffer is valid
> > *
> > @@ -547,7 +568,6 @@ static int goodix_ts_probe(struct i2c_client *client,
> >const struct i2c_device_id *id)
> > {
> > struct goodix_ts_data *ts;
> > - unsigned long irq_flags;
> > int error;
> > u16 version_info, id_info;
> >
> > @@ -599,10 +619,8 @@ static int goodix_ts_probe(struct i2c_client *client,
> > if (error)
> > return error;
> >
> > - irq_flags = goodix_irq_flags[ts->int_trigger_type] | IRQF_ONESHOT;
> > - error = devm_request_threaded_irq(&ts->client->dev, client->irq,
> > - NULL, goodix_ts_irq_handler,
> > - irq_flags, client->name, ts);
> > + ts->irq_flags = goodix_irq_flags[ts->int_trigger_type] | IRQF_ONESHOT;
> > + error = goodix_request_irq(ts);
> > if (error) {
> > dev_err(&client->dev, "request IRQ failed: %d\n", error);
> > return error;
> > @@ -611,6 +629,65 @@ static int goodix_ts_probe(struct i2c_client *client,
> > return 0;
> > }
> >
> > +#ifdef CONFIG_PM_SLEEP
> > +static int goodix_suspend(struct device *dev)
>
> Please drop #ifdef CONFIG_PM_SLEEP and annotate with __maybe_unused
> instead.
>
Ok, will fix this.
> > +{
> > + struct i2c_client *client = to_i2c_client(dev);
> > + struct goodix_ts_data
RE: [PATCH v2 5/8] input: goodix: write configuration data to device
> -Original Message-
> From: linux-input-ow...@vger.kernel.org
> [mailto:linux-input-ow...@vger.kernel.org] On Behalf Of Dmitry Torokhov
> Sent: 09 June, 2015 21:14
> To: Tirdea, Irina
> Cc: Bastien Nocera; Mark Rutland; linux-in...@vger.kernel.org;
> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; Rob
> Herring; Pawel Moll; Ian Campbell; Kumar Gala; Purdila, Octavian
> Subject: Re: [PATCH v2 5/8] input: goodix: write configuration data to device
>
> Hi Irina,
>
Hi Dmitry,
> On Mon, Jun 08, 2015 at 05:37:50PM +0300, Irina Tirdea wrote:
> > Goodix devices can be configured by writing custom data to the device at
> > init. The configuration data is read with request_firmware from
> > "goodix__cfg.bin", where is the product id read from the device
> > (e.g.: goodix_911_cfg.bin for Goodix GT911, goodix_9271_cfg.bin for
> > GT9271).
> >
> > The configuration information has a specific format described in the Goodix
> > datasheet. It includes X/Y resolution, maximum supported touch points,
> > interrupt flags, various sesitivity factors and settings for advanced
> > features (like gesture recognition).
> >
> > This is based on Goodix datasheets for GT911 and GT9271 and on Goodix
> > driver gt9xx.c for Android (publicly available in Android kernel
> > trees for various devices).
>
> I am afraid that just using request_firmware() in probe() is not the
> best option as it may cause either errors or delays in
> initialization of the driver is compiled into the kernel and tries to
> initialize before filesystem with configuration file is mounted (and
> firmware is not built into the kernel). We can either try switch to
> request_firmware_nowait() or at least document that we need firmware at
> boot.
>
The reason I did not use request_firmware_nowait() is that this configuration
data
includes information needed by probe (x/y resolution, interrupt trigger type,
max
touch num), used in goodix_read_config, goodix_ts_report_touch and for irq
flags
when requesting the interrupt. I will document that we need this configuration
firmware at boot in the commit message and add a comment in the code.
Is there any other documentation I need to update?
> >
> > Signed-off-by: Octavian Purdila
> > Signed-off-by: Irina Tirdea
> > ---
> > drivers/input/touchscreen/goodix.c | 128
> > +
> > 1 file changed, 128 insertions(+)
> >
> > diff --git a/drivers/input/touchscreen/goodix.c
> > b/drivers/input/touchscreen/goodix.c
> > index c345eb7..1ce9278 100644
> > --- a/drivers/input/touchscreen/goodix.c
> > +++ b/drivers/input/touchscreen/goodix.c
> > @@ -24,6 +24,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -95,6 +96,39 @@ static int goodix_i2c_read(struct i2c_client *client,
> > return ret < 0 ? ret : (ret != ARRAY_SIZE(msgs) ? -EIO : 0);
> > }
> >
> > +/**
> > + * goodix_i2c_write - write data to a register of the i2c slave device.
> > + *
> > + * @client: i2c device.
> > + * @reg: the register to write to.
> > + * @buf: raw data buffer to write.
> > + * @len: length of the buffer to write
> > + */
> > +static int goodix_i2c_write(struct i2c_client *client, u16 reg, const u8
> > *buf,
> > + unsigned len)
> > +{
> > + u8 *addr_buf;
> > + struct i2c_msg msg;
> > + int ret;
> > +
> > + addr_buf = kmalloc(len + 2, GFP_KERNEL);
> > + if (!addr_buf)
> > + return -ENOMEM;
> > +
> > + addr_buf[0] = reg >> 8;
> > + addr_buf[1] = reg & 0xFF;
> > + memcpy(&addr_buf[2], buf, len);
> > +
> > + msg.flags = 0;
> > + msg.addr = client->addr;
> > + msg.buf = addr_buf;
> > + msg.len = len + 2;
> > +
> > + ret = i2c_transfer(client->adapter, &msg, 1);
> > + kfree(addr_buf);
> > + return ret < 0 ? ret : (ret != 1 ? -EIO : 0);
> > +}
> > +
> > static int goodix_ts_read_input_report(struct goodix_ts_data *ts, u8 *data)
> > {
> > int touch_num;
> > @@ -192,6 +226,95 @@ static irqreturn_t goodix_ts_irq_handler(int irq, void
> > *dev_id)
> > return IRQ_HANDLED;
> > }
> >
> > +/**
> > + * goodix_check_cfg - Checks if config buffer is valid
> > + *
> > + * @ts: goodix_ts_data pointer
> > + * @fw: firmware config data
> > + */
> > +static int goodix_check_cfg(struct goodix_ts_data *ts,
> > +
RE: [PATCH v2 4/8] input: goodix: reset device at init
> -Original Message- > From: linux-input-ow...@vger.kernel.org > [mailto:linux-input-ow...@vger.kernel.org] On Behalf Of Bastien Nocera > Sent: 09 June, 2015 18:53 > To: Tirdea, Irina > Cc: Dmitry Torokhov; Mark Rutland; linux-in...@vger.kernel.org; > devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; Rob > Herring; Pawel Moll; Ian Campbell; Kumar Gala; Purdila, Octavian > Subject: Re: [PATCH v2 4/8] input: goodix: reset device at init > > On Tue, 2015-06-09 at 17:34 +0200, Bastien Nocera wrote: > > On Mon, 2015-06-08 at 17:37 +0300, Irina Tirdea wrote: > > > After power on, it is recommended that the driver resets the > > > device. > > > The reset procedure timing is described in the datasheet and is > > > used > > > at device init (before writing device configuration) and > > > for power management. It is a sequence of setting the interrupt > > > and reset pins high/low at specific timing intervals. This > > > procedure > > > also includes setting the slave address to the one specified in the > > > ACPI/device tree. > > > > This breaks the touchscreen on my Onda v975w: > > [ 239.732858] Goodix-TS i2c-GDIX1001:00: ID 9271, version: 1020 > > [ 239.732977] Goodix-TS i2c-GDIX1001:00: Failed to get reset GPIO: > > -16 > > [ 239.736071] Goodix-TS: probe of i2c-GDIX1001:00 failed with error > > -16 > > > > This is the DSDT for that device: > > https://bugzilla.kernel.org/attachment.cgi?id=149331 > Oops. That's right - I am using named interrupts which are available only for ACPI 5.1, so devices already out there will not work. The problem here is that handling -ENOENT will not help. The gpio pins are declared in the ACPI DSDT, but are not named. The devm_gpiod_get API will look for the named interrupt first and fallback to searching by index if not found. Index will be 0 in both cases, this is why the first call will succeed and the second will fail with -EBUSY. One way to handle this would be to use indexed gpio pins instead of named gpio pins: e.g. consider the first gpio pin to be the reset pin and the second to be the interrupt pin. This is used in other drivers as well, e.g. zforce_ts. The problem with this approach is that any devices that declare the gpio pins in reversed order in the DSDT will not work and give no warning (the pins will be requested successfully, but some of the functionality will not work). The DSDT mentioned in https://bugzilla.kernel.org/attachment.cgi?id=149331 lists the reset pin first, while I am working on some devices that declare the interrupt gpio pin first. Another way to handle this is to treat -EBUSY like -ENOENT and not use any functionality that depends on the gpio pins. Unfortunately, this means we will not have suspend, esd and custom configs even if the pins are connected on the board and available in ACPI(just not named). I would go with the first approach and document the order requested for the pins, but I would like to hear what you think first. Is there a better way to do this? > (Note that this means that I haven't been able to test any following > patches in that series than 4/8). Sure, that makes sense. The following patches depend on the gpio pins so they would not have worked either. Thanks, Irina > -- > To unsubscribe from this list: send the line "unsubscribe linux-input" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2 4/8] input: goodix: reset device at init
> -Original Message-
> From: linux-input-ow...@vger.kernel.org
> [mailto:linux-input-ow...@vger.kernel.org] On Behalf Of Dmitry Torokhov
> Sent: 09 June, 2015 20:58
> To: Tirdea, Irina
> Cc: Bastien Nocera; Mark Rutland; linux-in...@vger.kernel.org;
> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; Rob
> Herring; Pawel Moll; Ian Campbell; Kumar Gala; Purdila, Octavian
> Subject: Re: [PATCH v2 4/8] input: goodix: reset device at init
>
> Hi Irina,
>
> On Mon, Jun 08, 2015 at 05:37:49PM +0300, Irina Tirdea wrote:
> > +static int goodix_get_gpio_config(struct goodix_ts_data *ts)
> > +{
> > + struct device *dev;
> > + struct gpio_desc *gpiod;
> > + int ret;
> > +
> > + if (!ts->client)
> > + return -EINVAL;
> > + dev = &ts->client->dev;
> > +
> > + /* Get interrupt GPIO pin number */
> > + gpiod = devm_gpiod_get(dev, GOODIX_GPIO_INT_NAME, GPIOD_IN);
> > + if (IS_ERR(gpiod)) {
> > + ret = PTR_ERR(gpiod);
> > + dev_err(dev, "Failed to get %s GPIO: %d\n",
> > + GOODIX_GPIO_INT_NAME, ret);
>
> You need to handle -EPROBE_DEFER (suppress error) and especially -ENOENT error
> codes, otherwise, as Bastien mentioned, you will break existing DTS.
>
Yes, I will handle the -EPROBE_DEFER and -ENOENT for devices that might not
have these
gpio pins connected or declared in ACPI/DTS. Since the following patches depend
on these
pins, I will bypass the functionality for these devices (suspend/resume, esd,
writing config
will not be available if gpio pins are not found).
Thanks,
Irina
> Thanks.
>
> --
> Dmitry
> --
> To unsubscribe from this list: send the line "unsubscribe linux-input" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v2 0/8] Goodix touchscreen enhancements
> -Original Message-
> From: Dmitry Torokhov [mailto:dmitry.torok...@gmail.com]
> Sent: 09 June, 2015 21:17
> To: Tirdea, Irina
> Cc: Bastien Nocera; Mark Rutland; linux-in...@vger.kernel.org;
> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; Rob
> Herring; Pawel Moll; Ian Campbell; Kumar Gala
> Subject: Re: [PATCH v2 0/8] Goodix touchscreen enhancements
>
> On Mon, Jun 08, 2015 at 05:37:45PM +0300, Irina Tirdea wrote:
> > Add several enhancements to the Goodix touchscreen driver:
> > - write configuration data to the device
> > - power management support
> > - cleanup and refactoring
> >
> > I have kept the original patch for ESD ("input: goodix: add support
> > for ESD") since it is still under discussion. I have moved it to the
> > end of the patch set so it does not block the other changes. Once I have
> > an answer from DT folks on this I will make the necessary changes for it.
> >
> > For testing the ACPI changes "ACPI: Translate Linux IRQ number directly
> > from GpioInt" patchset is needed [1]. This patchset has been merged in
> > the GPIO tree.
> >
> > This patches are based on Goodix datasheets for GT911 and GT9271 and
> > on Goodix driver gt9xx.c for Android (publicly available in Android kernel
> > trees for various devices). Commit 771d8f1b178e ("Input: goodix - add
> > device tree support") references a set of public datasheets that can
> > be used for reference.
> >
> > [1] https://lkml.org/lkml/2015/5/6/281
> >
> > Changes in v2:
> > - use request_firmware instead of ACPI/DT property for config
> > - dropped "input: goodix: add ACPI IDs for GT911 and GT9271" patch
> > - add ACPI DSDT excerpt in commit message where necessary
> > - add comments for suspend/resume sleep values
> > - dropped the checkpatch fixes that did not make sense
> > - added Bastien's ack to the first patch
> >
> > Irina Tirdea (8):
> > input: goodix: fix alignment issues
> > input: goodix: fix variable length array warning
> > input: goodix: export id and version read from device
>
> Applied first 3.
>
> Thanks.
>
Thanks Dmitry and Bastien for taking a look at the patches!
Sorry for the delay - I have been on vacation for the last 2 weeks.
I am back in the office now so I will quickly address the issues for the
remaining patches.
Thanks,
Irina
> > input: goodix: reset device at init
> > input: goodix: write configuration data to device
> > input: goodix: add power management support
> > input: goodix: use goodix_i2c_write_u8 instead of i2c_master_send
> > input: goodix: add support for ESD
> >
> > .../bindings/input/touchscreen/goodix.txt | 12 +
> > drivers/input/touchscreen/goodix.c | 467
> > +++--
> > 2 files changed, 449 insertions(+), 30 deletions(-)
> >
> > --
> > 1.9.1
> >
>
> --
> Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 8/9] input: goodix: add support for ESD
> -Original Message- > From: Dmitry Torokhov [mailto:dmitry.torok...@gmail.com] > Sent: 05 June, 2015 19:46 > To: Tirdea, Irina > Cc: Bastien Nocera; Mark Rutland; linux-in...@vger.kernel.org; > devicet...@vger.kernel.org; linux-kernel@vger.kernel.org > Subject: Re: [PATCH 8/9] input: goodix: add support for ESD > > On Fri, Jun 05, 2015 at 04:37:49PM +, Tirdea, Irina wrote: > > > > > > > -Original Message- > > > From: Bastien Nocera [mailto:had...@hadess.net] > > > Sent: 04 June, 2015 15:58 > > > To: Tirdea, Irina > > > Cc: Mark Rutland; Dmitry Torokhov; linux-in...@vger.kernel.org; > > > devicet...@vger.kernel.org; linux-kernel@vger.kernel.org > > > Subject: Re: [PATCH 8/9] input: goodix: add support for ESD > > > > > > On Thu, 2015-05-28 at 14:26 +, Tirdea, Irina wrote: > > > > > > > > > -Original Message- > > > > > From: linux-input-ow...@vger.kernel.org [mailto: > > > > > linux-input-ow...@vger.kernel.org] On Behalf Of Mark Rutland > > > > > Sent: 28 May, 2015 16:24 > > > > > To: Tirdea, Irina > > > > > Cc: Dmitry Torokhov; Bastien Nocera; linux-in...@vger.kernel.org; > > > > > devicet...@vger.kernel.org; linux-kernel@vger.kernel.org > > > > > Subject: Re: [PATCH 8/9] input: goodix: add support for ESD > > > > > > > > > > On Thu, May 28, 2015 at 01:47:44PM +0100, Irina Tirdea wrote: > > > > > > Add ESD (Electrostatic Discharge) protection mechanism. > > > > > > > > > > > > The driver enables ESD protection in HW and checks a register > > > > > > to determine if ESD occurred. If ESD is signalled by the HW, > > > > > > the driver will reset the device. > > > > > > > > > > > > The ESD poll time (in ms) can be set through > > > > > > esd-recovery-timeout-ms ACPI/DT property. If it is set to 0, > > > > > > ESD protection is disabled. > > > > > > > > > > > > Signed-off-by: Irina Tirdea > > > > > > --- > > > > > > .../bindings/input/touchscreen/goodix.txt | 4 + > > > > > > drivers/input/touchscreen/goodix.c | 106 > > > > > > - > > > > > > 2 files changed, 106 insertions(+), 4 deletions(-) > > > > > > > > > > > > diff --git > > > > > > a/Documentation/devicetree/bindings/input/touchscreen/goodix.txt > > > > > b/Documentation/devicetree/bindings/input/touchscreen/goodix.txt > > > > > > index 9e4ff69..9132ee0 100644 > > > > > > --- > > > > > > a/Documentation/devicetree/bindings/input/touchscreen/goodix.txt > > > > > > +++ > > > > > > b/Documentation/devicetree/bindings/input/touchscreen/goodix.txt > > > > > > @@ -19,6 +19,10 @@ Optional properties: > > > > > > > > > > > > - device-config : device configuration information > > > > > > (specified as byte > > > > > > array). Maximum size is 240 bytes. > > > > > > + - esd-recovery-timeout-ms : ESD poll time (in milli seconds) > > > > > > for the driver to > > > > > > + check if ESD occurred and in that > > > > > > case reset the > > > > > > + device. ESD is disabled if this > > > > > > property is not set > > > > > > + or is set to 0. > > > > > > > > > > This sounds like software configuration rather than HW description. > > > > > Is > > > > > there any reason this needs to be a DT property? > > > > > > > > > > > > > Although this enables a software feature, it depends on the platform > > > > if electrostatic discharge > > > > protection should be enabled or not. Some platform designs handle ESD > > > > better and do not need > > > > the SW mechanism, so the property can be used to disable it. > > Even though it depends on the platform it describes software function, > not hardware. Since it is not necessary for starting the device maybe we > should indeed export it through sysfs and userspace board code should > activate it as needed? Sure, I can do it through sysfs. The only confusing part is that the tsc2005 touchscreen driver uses the device tree property esd-recovery-timeout-ms. > > I'll leave the decision to DT folks here. > OK. I will keep this version of the esd patch in v2 and wait for an answer from DT folks so I know exactly how to handle it. Thanks, Irina > Thanks. > > -- > Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 2/9] input: goodix: fix variable length array warning
> -Original Message-
> From: Dmitry Torokhov [mailto:dmitry.torok...@gmail.com]
> Sent: 05 June, 2015 20:12
> To: Tirdea, Irina
> Cc: 'Antonio Ospite'; Bastien Nocera; linux-in...@vger.kernel.org;
> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH 2/9] input: goodix: fix variable length array warning
>
> On Fri, Jun 05, 2015 at 05:00:05PM +, Tirdea, Irina wrote:
> >
> >
> > > -Original Message-
> > > From: Dmitry Torokhov [mailto:dmitry.torok...@gmail.com]
> > > Sent: 05 June, 2015 19:41
> > > To: Tirdea, Irina
> > > Cc: 'Antonio Ospite'; Bastien Nocera; linux-in...@vger.kernel.org;
> > > devicet...@vger.kernel.org; linux-kernel@vger.kernel.org
> > > Subject: Re: [PATCH 2/9] input: goodix: fix variable length array warning
> > >
> > > On Fri, Jun 05, 2015 at 04:34:38PM +, Tirdea, Irina wrote:
> > > >
> > > >
> > > > > -Original Message-
> > > > > From: linux-input-ow...@vger.kernel.org
> > > > > [mailto:linux-input-ow...@vger.kernel.org] On Behalf Of Antonio Ospite
> > > > > Sent: 03 June, 2015 23:50
> > > > > To: Tirdea, Irina
> > > > > Cc: Dmitry Torokhov; Bastien Nocera; linux-in...@vger.kernel.org;
> > > > > devicet...@vger.kernel.org; linux-kernel@vger.kernel.org
> > > > > Subject: Re: [PATCH 2/9] input: goodix: fix variable length array
> > > > > warning
> > > > >
> > > > > On Wed, 3 Jun 2015 10:26:47 +
> > > > > "Tirdea, Irina" wrote:
> > > > >
> > > > > > > -Original Message-
> > > > > > > From: Antonio Ospite [mailto:a...@ao2.it]
> > > > > > > Sent: 28 May, 2015 18:58
> > > > > > > To: Tirdea, Irina
> > > > > > > Cc: Dmitry Torokhov; Bastien Nocera; linux-in...@vger.kernel.org;
> > > > > > > devicet...@vger.kernel.org; linux-
> ker...@vger.kernel.org
> > > > > > > Subject: Re: [PATCH 2/9] input: goodix: fix variable length array
> > > > > > > warning
> > > > > > >
> > > > > > > On Thu, 28 May 2015 15:47:38 +0300
> > > > > > > Irina Tirdea wrote:
> > > > > > >
> > > > > > > > Fix sparse warning:
> > > > > > > > drivers/input/touchscreen/goodix.c:182:26: warning:
> > > > > > > > Variable length array is used.
> > > > > > > >
> > > > > > > > Replace the variable length array with fixed length.
> > > > > > > >
> > > > > > > > Signed-off-by: Irina Tirdea
> > > > > > > > ---
> > > > > > > > drivers/input/touchscreen/goodix.c | 2 +-
> > > > > > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > > > > > >
> > > > > > > > diff --git a/drivers/input/touchscreen/goodix.c
> > > > > > > > b/drivers/input/touchscreen/goodix.c
> > > > > > > > index c2e785c..dac1b3c 100644
> > > > > > > > --- a/drivers/input/touchscreen/goodix.c
> > > > > > > > +++ b/drivers/input/touchscreen/goodix.c
> > > > > > > > @@ -147,7 +147,7 @@ static void goodix_ts_report_touch(struct
> > > > > > > > goodix_ts_data *ts, u8 *coor_data)
> > > > > > > > */
> > > > > > > > static void goodix_process_events(struct goodix_ts_data *ts)
> > > > > > > > {
> > > > > > > > - u8 point_data[1 + GOODIX_CONTACT_SIZE *
> > > > > > > > ts->max_touch_num];
> > > > > > > > + u8 point_data[1 + GOODIX_CONTACT_SIZE *
> > > > > > > > GOODIX_MAX_CONTACTS];
> > > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > >
> > > > > > Hi Antonio,
> > > > > >
> > > > > > > this fixes the warning from sparse, but also changes the
> > > > > > > semantics of
> > > > > > > the code: ts->max_touch_num is less that GOODIX_MAX_CONTACTS for 5
> > > > > > > touches devices and in this case we'll end up using more memory
> > > > > > &g
RE: [PATCH 1/9] input: goodix: fix alignment issues
> -Original Message-
> From: Dmitry Torokhov [mailto:dmitry.torok...@gmail.com]
> Sent: 05 June, 2015 19:49
> To: Tirdea, Irina
> Cc: Bastien Nocera; linux-in...@vger.kernel.org; devicet...@vger.kernel.org;
> linux-kernel@vger.kernel.org
> Subject: Re: [PATCH 1/9] input: goodix: fix alignment issues
>
> Hi Irina,
>
Hi Dmitry,
Thanks for the review!
Will keep the good parts below and remove the bad ones.
Thanks,
Irina
> On Thu, May 28, 2015 at 03:47:37PM +0300, Irina Tirdea wrote:
> > Fix alignment to match open parenthesis detected by
> > running checkpatch.pl --strict.
>
> Mixed bag of changes here, but that's checkpatch for you.
>
> >
> > Signed-off-by: Irina Tirdea
> > ---
> > drivers/input/touchscreen/goodix.c | 17 +
> > 1 file changed, 9 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/input/touchscreen/goodix.c
> > b/drivers/input/touchscreen/goodix.c
> > index 0d93b1e..c2e785c 100644
> > --- a/drivers/input/touchscreen/goodix.c
> > +++ b/drivers/input/touchscreen/goodix.c
> > @@ -69,7 +69,7 @@ static const unsigned long goodix_irq_flags[] = {
> > * @len: length of the buffer to write
> > */
> > static int goodix_i2c_read(struct i2c_client *client,
> > - u16 reg, u8 *buf, int len)
> > + u16 reg, u8 *buf, int len)
> > {
> > struct i2c_msg msgs[2];
> > u16 wbuf = cpu_to_be16(reg);
> > @@ -78,7 +78,7 @@ static int goodix_i2c_read(struct i2c_client *client,
> > msgs[0].flags = 0;
> > msgs[0].addr = client->addr;
> > msgs[0].len = 2;
> > - msgs[0].buf = (u8 *) &wbuf;
> > + msgs[0].buf = (u8 *)&wbuf;
>
> Good.
>
> >
> > msgs[1].flags = I2C_M_RD;
> > msgs[1].addr = client->addr;
> > @@ -112,7 +112,7 @@ static int goodix_ts_read_input_report(struct
> > goodix_ts_data *ts, u8 *data)
> > data += 1 + GOODIX_CONTACT_SIZE;
> > error = goodix_i2c_read(ts->client,
> > GOODIX_READ_COOR_ADDR +
> > - 1 + GOODIX_CONTACT_SIZE,
> > + 1 + GOODIX_CONTACT_SIZE,
>
> Bad - makes 1 + GOODIX_CONTACT_SIZE look like extra argument, not
> continuation of expression.
>
>
> > data,
> > GOODIX_CONTACT_SIZE * (touch_num - 1));
> > if (error)
> > @@ -157,7 +157,8 @@ static void goodix_process_events(struct goodix_ts_data
> > *ts)
> >
> > for (i = 0; i < touch_num; i++)
> > goodix_ts_report_touch(ts,
> > - &point_data[1 + GOODIX_CONTACT_SIZE * i]);
> > + &point_data[1 +
> > + GOODIX_CONTACT_SIZE * i]);
>
> No, this is plain ugly.
>
> >
> > input_mt_sync_frame(ts->input_dev);
> > input_sync(ts->input_dev);
> > @@ -199,8 +200,8 @@ static void goodix_read_config(struct goodix_ts_data
> > *ts)
> > int error;
> >
> > error = goodix_i2c_read(ts->client, GOODIX_REG_CONFIG_DATA,
> > - config,
> > - GOODIX_CONFIG_MAX_LENGTH);
> > + config,
> > + GOODIX_CONFIG_MAX_LENGTH);
>
> Good.
>
> > if (error) {
> > dev_warn(&ts->client->dev,
> > "Error reading config (%d), using defaults\n",
> > @@ -297,9 +298,9 @@ static int goodix_request_input_dev(struct
> > goodix_ts_data *ts)
> > BIT_MASK(EV_ABS);
> >
> > input_set_abs_params(ts->input_dev, ABS_MT_POSITION_X, 0,
> > - ts->abs_x_max, 0, 0);
> > +ts->abs_x_max, 0, 0);
>
> Good.
>
> > input_set_abs_params(ts->input_dev, ABS_MT_POSITION_Y, 0,
> > - ts->abs_y_max, 0, 0);
> > +ts->abs_y_max, 0, 0);
>
> Good.
>
> > input_set_abs_params(ts->input_dev, ABS_MT_WIDTH_MAJOR, 0, 255, 0, 0);
> > input_set_abs_params(ts->input_dev, ABS_MT_TOUCH_MAJOR, 0, 255, 0, 0);
> >
> > --
> > 1.9.1
> >
>
> Thanks.
>
> --
> Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 6/9] input: goodix: write configuration data to device
> -Original Message- > From: Dmitry Torokhov [mailto:dmitry.torok...@gmail.com] > Sent: 05 June, 2015 19:43 > To: Tirdea, Irina > Cc: Bastien Nocera; Mark Rutland; linux-in...@vger.kernel.org; > devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; Purdila, > Octavian > Subject: Re: [PATCH 6/9] input: goodix: write configuration data to device > > On Fri, Jun 05, 2015 at 04:36:24PM +, Tirdea, Irina wrote: > > > > > > > -Original Message- > > > From: Bastien Nocera [mailto:had...@hadess.net] > > > Sent: 04 June, 2015 15:55 > > > To: Tirdea, Irina > > > Cc: Mark Rutland; Dmitry Torokhov; linux-in...@vger.kernel.org; > > > devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; > Purdila, > > > Octavian > > > Subject: Re: [PATCH 6/9] input: goodix: write configuration data to device > > > > > > On Thu, 2015-05-28 at 13:51 +, Tirdea, Irina wrote: > > > > > > > > > -Original Message- > > > > > From: Mark Rutland [mailto:mark.rutl...@arm.com] > > > > > Sent: 28 May, 2015 16:22 > > > > > To: Tirdea, Irina > > > > > Cc: Dmitry Torokhov; Bastien Nocera; linux-in...@vger.kernel.org; > > > > > devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; > > > > > Purdila, Octavian > > > > > Subject: Re: [PATCH 6/9] input: goodix: write configuration data to > > > > > device > > > > > > > > > > On Thu, May 28, 2015 at 01:47:42PM +0100, Irina Tirdea wrote: > > > > > > Goodix devices can be configured by writing this information > > > > > > to the device at init. The configuration data can > > > > > > be provided through the ACPI/device tree property > > > > > > "device-config". If "device-config" is not set, the default > > > > > > device configuration will be used. > > > > > > > > > > > > Signed-off-by: Octavian Purdila > > > > > > Signed-off-by: Irina Tirdea > > > > > > --- > > > > > > .../bindings/input/touchscreen/goodix.txt | 5 + > > > > > > drivers/input/touchscreen/goodix.c | 143 > > > > > > + > > > > > > 2 files changed, 148 insertions(+) > > > > > > > > > > > > diff --git > > > > > > a/Documentation/devicetree/bindings/input/touchscreen/goodix.txt > > > > > b/Documentation/devicetree/bindings/input/touchscreen/goodix.txt > > > > > > index 7137881..9e4ff69 100644 > > > > > > --- > > > > > > a/Documentation/devicetree/bindings/input/touchscreen/goodix.txt > > > > > > +++ > > > > > > b/Documentation/devicetree/bindings/input/touchscreen/goodix.txt > > > > > > @@ -15,6 +15,11 @@ Required properties: > > > > > > - irq-gpio : GPIO pin used for IRQ > > > > > > - reset-gpio: GPIO pin used for reset > > > > > > > > > > > > +Optional properties: > > > > > > + > > > > > > + - device-config : device configuration information > > > > > > (specified as byte > > > > > > + array). Maximum size is 240 bytes. > > > > > > > > > > Generally we frown on passing opaque data. > > > > > > > > > > What exactly is encoded in device-config? The description is very > > > > > vague. > > > > > > > > > > Does this correspond to anything in a data sheet or manual? > > > > > > > > Yes, it is configuration data described in chapter 6.2. b of the > > > > datasheet: > > > > https://drive.google.com/folderview?id=0BxCVOQS3ZymGfmJyY2RKbE5XbVlKN > > > > lktVTlwV0lxNEdxd2dzeWZER094cmJPVnMxN1F0Yzg&usp=sharing. > > > > This includes things like x/y resolution, maximum touch numbers > > > > supported, > > > > interrupt flags, various sensitivity factors. > > > > > > > > I should have included a link to the datasheet in the commit message > > > > - will do that in v2 for all patches. > > > > > > > > I did consider writing this as firmware, but it seems that some > > > > Goodix touchscreens have a > > > > real firmware they need to write in addition to this configuration > > > > data. > > > > If there is a better way to do this, please let me know and I will > > > > change it. > > > > > > I would at least expect an excerpt from an ACPI DSDT that would make > > > use of that feature. > > > > Ok, I will add this to the commit message. > > No, it really shoudl be done via request_firmware() mechanism. There are > drivers in kernel that use request_firmware() for both firmware and > configuration data (see elan_i2c, elants_i2c, atmel_mxt_ts and I am sure > there are others). > Ok, I didn't know there are these other drivers that already do that. I will change this to use request_firmware then. Thanks, Irina > Thanks. > > -- > Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 4/9] input: goodix: add ACPI IDs for GT911 and GT9271
> -Original Message-
> From: Dmitry Torokhov [mailto:dmitry.torok...@gmail.com]
> Sent: 05 June, 2015 19:42
> To: Tirdea, Irina
> Cc: 'Bastien Nocera'; linux-in...@vger.kernel.org;
> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH 4/9] input: goodix: add ACPI IDs for GT911 and GT9271
>
> On Fri, Jun 05, 2015 at 04:36:24PM +, Tirdea, Irina wrote:
> >
> >
> > > -Original Message-
> > > From: Bastien Nocera [mailto:had...@hadess.net]
> > > Sent: 04 June, 2015 15:51
> > > To: Tirdea, Irina
> > > Cc: Dmitry Torokhov; linux-in...@vger.kernel.org;
> > > devicet...@vger.kernel.org; linux-kernel@vger.kernel.org
> > > Subject: Re: [PATCH 4/9] input: goodix: add ACPI IDs for GT911 and GT9271
> > >
> > > On Thu, 2015-05-28 at 15:47 +0300, Irina Tirdea wrote:
> > > > Add ACPI IDs to support Goodix GT911 and GT9271
> > > > touchscreens.
> > >
> > > Those devices are present on which systems which you would have tested
> > > this on?
> > >
> >
> > I have been using a custom setup by connecting the touchscreen directly
> > to a virtual Linux environment through an USB-I2C adapter
> > (https://diolan.com/dln-2).
> > So these ACPI IDs do not correspond to any device publicly available.
> > However, once in upstream we can use this IDs for our future platforms.
>
> I'd rather wait until they become available then.
>
Ok, I will drop this patch then.
> Thanks.
>
> >
> > > > Signed-off-by: Irina Tirdea
> > > > ---
> > > > drivers/input/touchscreen/goodix.c | 2 ++
> > > > 1 file changed, 2 insertions(+)
> > > >
> > > > diff --git a/drivers/input/touchscreen/goodix.c
> > > > b/drivers/input/touchscreen/goodix.c
> > > > index 9561396..9e7d215 100644
> > > > --- a/drivers/input/touchscreen/goodix.c
> > > > +++ b/drivers/input/touchscreen/goodix.c
> > > > @@ -392,6 +392,8 @@ static const struct i2c_device_id goodix_ts_id[]
> > > > = {
> > > > #ifdef CONFIG_ACPI
> > > > static const struct acpi_device_id goodix_acpi_match[] = {
> > > > { "GDIX1001", 0 },
> > > > + { "GDIX0911", 0 },
> > > > + { "GDIX9271", 0 },
> > > > { }
> > > > };
> > > > MODULE_DEVICE_TABLE(acpi, goodix_acpi_match);
>
> --
> Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 2/9] input: goodix: fix variable length array warning
> -Original Message-
> From: Dmitry Torokhov [mailto:dmitry.torok...@gmail.com]
> Sent: 05 June, 2015 19:41
> To: Tirdea, Irina
> Cc: 'Antonio Ospite'; Bastien Nocera; linux-in...@vger.kernel.org;
> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH 2/9] input: goodix: fix variable length array warning
>
> On Fri, Jun 05, 2015 at 04:34:38PM +, Tirdea, Irina wrote:
> >
> >
> > > -Original Message-
> > > From: linux-input-ow...@vger.kernel.org
> > > [mailto:linux-input-ow...@vger.kernel.org] On Behalf Of Antonio Ospite
> > > Sent: 03 June, 2015 23:50
> > > To: Tirdea, Irina
> > > Cc: Dmitry Torokhov; Bastien Nocera; linux-in...@vger.kernel.org;
> > > devicet...@vger.kernel.org; linux-kernel@vger.kernel.org
> > > Subject: Re: [PATCH 2/9] input: goodix: fix variable length array warning
> > >
> > > On Wed, 3 Jun 2015 10:26:47 +
> > > "Tirdea, Irina" wrote:
> > >
> > > > > -Original Message-
> > > > > From: Antonio Ospite [mailto:a...@ao2.it]
> > > > > Sent: 28 May, 2015 18:58
> > > > > To: Tirdea, Irina
> > > > > Cc: Dmitry Torokhov; Bastien Nocera; linux-in...@vger.kernel.org;
> > > > > devicet...@vger.kernel.org; linux-kernel@vger.kernel.org
> > > > > Subject: Re: [PATCH 2/9] input: goodix: fix variable length array
> > > > > warning
> > > > >
> > > > > On Thu, 28 May 2015 15:47:38 +0300
> > > > > Irina Tirdea wrote:
> > > > >
> > > > > > Fix sparse warning:
> > > > > > drivers/input/touchscreen/goodix.c:182:26: warning:
> > > > > > Variable length array is used.
> > > > > >
> > > > > > Replace the variable length array with fixed length.
> > > > > >
> > > > > > Signed-off-by: Irina Tirdea
> > > > > > ---
> > > > > > drivers/input/touchscreen/goodix.c | 2 +-
> > > > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > > > >
> > > > > > diff --git a/drivers/input/touchscreen/goodix.c
> > > > > > b/drivers/input/touchscreen/goodix.c
> > > > > > index c2e785c..dac1b3c 100644
> > > > > > --- a/drivers/input/touchscreen/goodix.c
> > > > > > +++ b/drivers/input/touchscreen/goodix.c
> > > > > > @@ -147,7 +147,7 @@ static void goodix_ts_report_touch(struct
> > > > > > goodix_ts_data *ts, u8 *coor_data)
> > > > > > */
> > > > > > static void goodix_process_events(struct goodix_ts_data *ts)
> > > > > > {
> > > > > > - u8 point_data[1 + GOODIX_CONTACT_SIZE * ts->max_touch_num];
> > > > > > + u8 point_data[1 + GOODIX_CONTACT_SIZE * GOODIX_MAX_CONTACTS];
> > > > >
> > > > > Hi,
> > > > >
> > > >
> > > > Hi Antonio,
> > > >
> > > > > this fixes the warning from sparse, but also changes the semantics of
> > > > > the code: ts->max_touch_num is less that GOODIX_MAX_CONTACTS for 5
> > > > > touches devices and in this case we'll end up using more memory than
> > > > > is
> > > > > necessary.
> > > > >
> > > >
> > > > I wasn't sure if it is better to save the 5 bytes or fix the warning,
> > > > so I sent this to get some more input.
> > > > Thanks for the feedback, I will drop this patch.
> > > >
> > >
> > > Use kmalloc() or, alternatively, add at least a comment telling why you
> > > think that sacrificing a few bytes —only for some devices— has
> > > advantages over dynamic allocation.
> > >
> >
> > You are right, kmalloc will solve both problems - the sparse warning and
> > allocating
> > more bytes than necessary. Don't know why I did not think of that.
> > Will use that in v2.
>
> Please leave the patch as is. We can spare 80 bytes on the stack given
> that we are running in threaded IRQ. kmallocing will use more code and
> runtime resources and won't give any benefits.
I was actually thinking of allocating it with devm_kzalloc just once at device
init and
storing a pointer to it in the goodix_ts_data structure.
Thanks,
Irina
>
> Thanks.
>
> --
> Dmitry
RE: [PATCH 7/9] input: goodix: add power management support
> -Original Message-
> From: Bastien Nocera [mailto:had...@hadess.net]
> Sent: 04 June, 2015 16:01
> To: Tirdea, Irina
> Cc: Dmitry Torokhov; linux-in...@vger.kernel.org; devicet...@vger.kernel.org;
> linux-kernel@vger.kernel.org; Purdila, Octavian
> Subject: Re: [PATCH 7/9] input: goodix: add power management support
>
> On Thu, 2015-05-28 at 15:47 +0300, Irina Tirdea wrote:
> > Implement suspend/resume for goodix driver.
> >
> > Signed-off-by: Octavian Purdila
> > Signed-off-by: Irina Tirdea
> > ---
> > drivers/input/touchscreen/goodix.c | 81
> > +++---
> > 1 file changed, 76 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/input/touchscreen/goodix.c
> > b/drivers/input/touchscreen/goodix.c
> > index 22052c9..ce7e834 100644
> > --- a/drivers/input/touchscreen/goodix.c
> > +++ b/drivers/input/touchscreen/goodix.c
> > @@ -37,6 +37,7 @@ struct goodix_ts_data {
> > unsigned int int_trigger_type;
> > struct gpio_desc *gpiod_int;
> > struct gpio_desc *gpiod_rst;
> > + unsigned long irq_flags;
> > };
> >
> > #define GOODIX_GPIO_INT_NAME "irq"
> > @@ -52,6 +53,9 @@ struct goodix_ts_data {
> > #define GOODIX_CONFIG_MAX_LENGTH 240
> >
> > /* Register defines */
> > +#define GOODIX_REG_COMMAND 0x8040
> > +#define GOODIX_CMD_SCREEN_OFF0x05
> > +
> > #define GOODIX_READ_COOR_ADDR0x814E
> > #define GOODIX_REG_CONFIG_DATA 0x8047
> > #define GOODIX_REG_ID0x8140
> > @@ -129,6 +133,11 @@ static int goodix_i2c_write(struct i2c_client
> > *client, u16 reg, u8 *buf,
> > return ret < 0 ? ret : (ret != 1 ? -EIO : 0);
> > }
> >
> > +static int goodix_i2c_write_u8(struct i2c_client *client, u16 reg,
> > u8 value)
> > +{
> > + return goodix_i2c_write(client, reg, &value, sizeof(value));
> > +}
> > +
> > static int goodix_ts_read_input_report(struct goodix_ts_data *ts, u8
> > *data)
> > {
> > int touch_num;
> > @@ -227,6 +236,18 @@ static irqreturn_t goodix_ts_irq_handler(int
> > irq, void *dev_id)
> > return IRQ_HANDLED;
> > }
> >
> > +static void goodix_free_irq(struct goodix_ts_data *ts)
> > +{
> > + devm_free_irq(&ts->client->dev, ts->client->irq, ts);
> > +}
> > +
> > +static int goodix_request_irq(struct goodix_ts_data *ts)
> > +{
> > + return devm_request_threaded_irq(&ts->client->dev, ts
> > ->client->irq,
> > + NULL,
> > goodix_ts_irq_handler,
> > + ts->irq_flags, ts->client
> > ->name, ts);
> > +}
> > +
> > /**
> > * goodix_get_cfg - Get device config from ACPI/DT.
> > *
> > @@ -562,7 +583,6 @@ static int goodix_ts_probe(struct i2c_client
> > *client,
> > const struct i2c_device_id *id)
> > {
> > struct goodix_ts_data *ts;
> > - unsigned long irq_flags;
> > int error;
> > u16 version_info, id_info;
> >
> > @@ -614,10 +634,8 @@ static int goodix_ts_probe(struct i2c_client
> > *client,
> > if (error)
> > return error;
> >
> > - irq_flags = goodix_irq_flags[ts->int_trigger_type] |
> > IRQF_ONESHOT;
> > - error = devm_request_threaded_irq(&ts->client->dev, client
> > ->irq,
> > - NULL,
> > goodix_ts_irq_handler,
> > - irq_flags, client->name,
> > ts);
> > + ts->irq_flags = goodix_irq_flags[ts->int_trigger_type] |
> > IRQF_ONESHOT;
> > + error = goodix_request_irq(ts);
> > if (error) {
> > dev_err(&client->dev, "request IRQ failed: %d\n",
> > error);
> > return error;
> > @@ -626,6 +644,58 @@ static int goodix_ts_probe(struct i2c_client
> > *client,
> > return 0;
> > }
> >
> > +#ifdef CONFIG_PM_SLEEP
> > +static int goodix_suspend(struct device *dev)
> > +{
> > + struct i2c_client *client = to_i2c_client(dev);
> > + struct goodix_ts_data *ts = i2c_get_clientdata(client);
> > + int ret;
> > +
> > + goodix_free_irq(ts);
> > + ret = gpiod_direction_output(ts->gpiod_int, 0);
> > + if (ret) {
> > + goodix_r
RE: [PATCH 8/9] input: goodix: add support for ESD
> -Original Message-
> From: Bastien Nocera [mailto:had...@hadess.net]
> Sent: 04 June, 2015 15:58
> To: Tirdea, Irina
> Cc: Mark Rutland; Dmitry Torokhov; linux-in...@vger.kernel.org;
> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH 8/9] input: goodix: add support for ESD
>
> On Thu, 2015-05-28 at 14:26 +, Tirdea, Irina wrote:
> >
> > > -Original Message-
> > > From: linux-input-ow...@vger.kernel.org [mailto:
> > > linux-input-ow...@vger.kernel.org] On Behalf Of Mark Rutland
> > > Sent: 28 May, 2015 16:24
> > > To: Tirdea, Irina
> > > Cc: Dmitry Torokhov; Bastien Nocera; linux-in...@vger.kernel.org;
> > > devicet...@vger.kernel.org; linux-kernel@vger.kernel.org
> > > Subject: Re: [PATCH 8/9] input: goodix: add support for ESD
> > >
> > > On Thu, May 28, 2015 at 01:47:44PM +0100, Irina Tirdea wrote:
> > > > Add ESD (Electrostatic Discharge) protection mechanism.
> > > >
> > > > The driver enables ESD protection in HW and checks a register
> > > > to determine if ESD occurred. If ESD is signalled by the HW,
> > > > the driver will reset the device.
> > > >
> > > > The ESD poll time (in ms) can be set through
> > > > esd-recovery-timeout-ms ACPI/DT property. If it is set to 0,
> > > > ESD protection is disabled.
> > > >
> > > > Signed-off-by: Irina Tirdea
> > > > ---
> > > > .../bindings/input/touchscreen/goodix.txt | 4 +
> > > > drivers/input/touchscreen/goodix.c | 106
> > > > -
> > > > 2 files changed, 106 insertions(+), 4 deletions(-)
> > > >
> > > > diff --git
> > > > a/Documentation/devicetree/bindings/input/touchscreen/goodix.txt
> > > b/Documentation/devicetree/bindings/input/touchscreen/goodix.txt
> > > > index 9e4ff69..9132ee0 100644
> > > > ---
> > > > a/Documentation/devicetree/bindings/input/touchscreen/goodix.txt
> > > > +++
> > > > b/Documentation/devicetree/bindings/input/touchscreen/goodix.txt
> > > > @@ -19,6 +19,10 @@ Optional properties:
> > > >
> > > > - device-config : device configuration information
> > > > (specified as byte
> > > > array). Maximum size is 240 bytes.
> > > > + - esd-recovery-timeout-ms : ESD poll time (in milli seconds)
> > > > for the driver to
> > > > + check if ESD occurred and in that
> > > > case reset the
> > > > + device. ESD is disabled if this
> > > > property is not set
> > > > + or is set to 0.
> > >
> > > This sounds like software configuration rather than HW description.
> > > Is
> > > there any reason this needs to be a DT property?
> > >
> >
> > Although this enables a software feature, it depends on the platform
> > if electrostatic discharge
> > protection should be enabled or not. Some platform designs handle ESD
> > better and do not need
> > the SW mechanism, so the property can be used to disable it.
> >
> > I also saw an example in
> > Documentation/devicetree/bindings/input/touchscreen/tsc2005.txt
> > and I though this is the standard way to use it.
>
> As for the configuration data, is this useful/used on ACPI?
This can be used with ACPI 5.1 by specifying the timeout as a _DSD property.
I will add an excerpt from an ACPI DSDT file in the commit message.
>
> > > Can we not just choose a sensible default and allow this to be
> > > overridden dynamically?
> >
> > I could separate the enabling part from the actual poll timeout by
> > using a DT property to enable/disable
> > ESD and a sysfs property to set the timeout. I can also move this
> > over to sysfs entirely if you prefer.
>
> If this needs to be in the DT for some devices, and isn't available
> from ACPI, maybe we should have a list of DMI matches for ACPI instead,
> with a module option to override it?
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�&j:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
RE: [PATCH 4/9] input: goodix: add ACPI IDs for GT911 and GT9271
> -Original Message-
> From: Bastien Nocera [mailto:had...@hadess.net]
> Sent: 04 June, 2015 15:51
> To: Tirdea, Irina
> Cc: Dmitry Torokhov; linux-in...@vger.kernel.org; devicet...@vger.kernel.org;
> linux-kernel@vger.kernel.org
> Subject: Re: [PATCH 4/9] input: goodix: add ACPI IDs for GT911 and GT9271
>
> On Thu, 2015-05-28 at 15:47 +0300, Irina Tirdea wrote:
> > Add ACPI IDs to support Goodix GT911 and GT9271
> > touchscreens.
>
> Those devices are present on which systems which you would have tested
> this on?
>
I have been using a custom setup by connecting the touchscreen directly
to a virtual Linux environment through an USB-I2C adapter
(https://diolan.com/dln-2).
So these ACPI IDs do not correspond to any device publicly available.
However, once in upstream we can use this IDs for our future platforms.
> > Signed-off-by: Irina Tirdea
> > ---
> > drivers/input/touchscreen/goodix.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/drivers/input/touchscreen/goodix.c
> > b/drivers/input/touchscreen/goodix.c
> > index 9561396..9e7d215 100644
> > --- a/drivers/input/touchscreen/goodix.c
> > +++ b/drivers/input/touchscreen/goodix.c
> > @@ -392,6 +392,8 @@ static const struct i2c_device_id goodix_ts_id[]
> > = {
> > #ifdef CONFIG_ACPI
> > static const struct acpi_device_id goodix_acpi_match[] = {
> > { "GDIX1001", 0 },
> > + { "GDIX0911", 0 },
> > + { "GDIX9271", 0 },
> > { }
> > };
> > MODULE_DEVICE_TABLE(acpi, goodix_acpi_match);
RE: [PATCH 6/9] input: goodix: write configuration data to device
> -Original Message- > From: Bastien Nocera [mailto:had...@hadess.net] > Sent: 04 June, 2015 15:55 > To: Tirdea, Irina > Cc: Mark Rutland; Dmitry Torokhov; linux-in...@vger.kernel.org; > devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; Purdila, > Octavian > Subject: Re: [PATCH 6/9] input: goodix: write configuration data to device > > On Thu, 2015-05-28 at 13:51 +, Tirdea, Irina wrote: > > > > > -Original Message- > > > From: Mark Rutland [mailto:mark.rutl...@arm.com] > > > Sent: 28 May, 2015 16:22 > > > To: Tirdea, Irina > > > Cc: Dmitry Torokhov; Bastien Nocera; linux-in...@vger.kernel.org; > > > devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; > > > Purdila, Octavian > > > Subject: Re: [PATCH 6/9] input: goodix: write configuration data to > > > device > > > > > > On Thu, May 28, 2015 at 01:47:42PM +0100, Irina Tirdea wrote: > > > > Goodix devices can be configured by writing this information > > > > to the device at init. The configuration data can > > > > be provided through the ACPI/device tree property > > > > "device-config". If "device-config" is not set, the default > > > > device configuration will be used. > > > > > > > > Signed-off-by: Octavian Purdila > > > > Signed-off-by: Irina Tirdea > > > > --- > > > > .../bindings/input/touchscreen/goodix.txt | 5 + > > > > drivers/input/touchscreen/goodix.c | 143 > > > > + > > > > 2 files changed, 148 insertions(+) > > > > > > > > diff --git > > > > a/Documentation/devicetree/bindings/input/touchscreen/goodix.txt > > > b/Documentation/devicetree/bindings/input/touchscreen/goodix.txt > > > > index 7137881..9e4ff69 100644 > > > > --- > > > > a/Documentation/devicetree/bindings/input/touchscreen/goodix.txt > > > > +++ > > > > b/Documentation/devicetree/bindings/input/touchscreen/goodix.txt > > > > @@ -15,6 +15,11 @@ Required properties: > > > > - irq-gpio : GPIO pin used for IRQ > > > > - reset-gpio: GPIO pin used for reset > > > > > > > > +Optional properties: > > > > + > > > > + - device-config : device configuration information > > > > (specified as byte > > > > + array). Maximum size is 240 bytes. > > > > > > Generally we frown on passing opaque data. > > > > > > What exactly is encoded in device-config? The description is very > > > vague. > > > > > > Does this correspond to anything in a data sheet or manual? > > > > Yes, it is configuration data described in chapter 6.2. b of the > > datasheet: > > https://drive.google.com/folderview?id=0BxCVOQS3ZymGfmJyY2RKbE5XbVlKN > > lktVTlwV0lxNEdxd2dzeWZER094cmJPVnMxN1F0Yzg&usp=sharing. > > This includes things like x/y resolution, maximum touch numbers > > supported, > > interrupt flags, various sensitivity factors. > > > > I should have included a link to the datasheet in the commit message > > - will do that in v2 for all patches. > > > > I did consider writing this as firmware, but it seems that some > > Goodix touchscreens have a > > real firmware they need to write in addition to this configuration > > data. > > If there is a better way to do this, please let me know and I will > > change it. > > I would at least expect an excerpt from an ACPI DSDT that would make > use of that feature. Ok, I will add this to the commit message.
RE: [PATCH 0/9] Goodix touchscreen enhancements
> -Original Message-
> From: Bastien Nocera [mailto:had...@hadess.net]
> Sent: 04 June, 2015 16:05
> To: Tirdea, Irina
> Cc: Dmitry Torokhov; linux-in...@vger.kernel.org; devicet...@vger.kernel.org;
> linux-kernel@vger.kernel.org
> Subject: Re: [PATCH 0/9] Goodix touchscreen enhancements
>
> Hey Irina,
>
Hi Bastien,
> On Thu, 2015-05-28 at 15:47 +0300, Irina Tirdea wrote:
> > Add several enhancements to the Goodix touchscreen driver:
> > - write configuration data to the device
> > - power management support
> > - cleanup and refactoring
> >
> > Irina Tirdea (9):
> > input: goodix: fix alignment issues
> > input: goodix: fix variable length array warning
> > input: goodix: export id and version read from device
> > input: goodix: add ACPI IDs for GT911 and GT9271
> > input: goodix: reset device at init
> > input: goodix: write configuration data to device
> > input: goodix: add power management support
> > input: goodix: add support for ESD
> > input: goodix: use goodix_i2c_write_u8 instead of i2c_master_send
>
> Thanks a lot of that patch series. I was travelling when you sent it,
> but I should be able to test the patch series quicker when you send a
> v2.
Thanks for the review and for offering to test the patches. I will send v2 asap.
>
> Could you please also add some references to hardware that you're
> enabling (and presumably have been testing on) to the driver's Kconfig?
> If the hardware is still not public, any sort of other reference would
> be useful (Windows 8 compatible harwdare? Hardware that usually runs a
> particular Android vendor tree?...)
I have been using a custom setup by connecting the touchscreen directly
to a virtual Linux environment through an USB-I2C adapter
(https://diolan.com/dln-2).
This is how I could test both ACPI and DT configurations and why the ACPI IDs I
used do not
correspond to an actual device.
I have also done tests for the main functionality (writing config, reset,
suspend/resume,
ESD) on an Android tablet. Unfortunately the HW is not public and neither is the
Android tree. There is an Android tree publicly available at
https://01.org/android-ia,
but it is quite different from the internal tree I am using.
I can add a reference in Kconfig that this driver supports chip models that can
be found
on Intel tablets running Android.
Thanks,
Irina
>
> Cheers
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�&j:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
RE: [PATCH 2/9] input: goodix: fix variable length array warning
> -Original Message-
> From: linux-input-ow...@vger.kernel.org
> [mailto:linux-input-ow...@vger.kernel.org] On Behalf Of Antonio Ospite
> Sent: 03 June, 2015 23:50
> To: Tirdea, Irina
> Cc: Dmitry Torokhov; Bastien Nocera; linux-in...@vger.kernel.org;
> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH 2/9] input: goodix: fix variable length array warning
>
> On Wed, 3 Jun 2015 10:26:47 +
> "Tirdea, Irina" wrote:
>
> > > -Original Message-
> > > From: Antonio Ospite [mailto:a...@ao2.it]
> > > Sent: 28 May, 2015 18:58
> > > To: Tirdea, Irina
> > > Cc: Dmitry Torokhov; Bastien Nocera; linux-in...@vger.kernel.org;
> > > devicet...@vger.kernel.org; linux-kernel@vger.kernel.org
> > > Subject: Re: [PATCH 2/9] input: goodix: fix variable length array warning
> > >
> > > On Thu, 28 May 2015 15:47:38 +0300
> > > Irina Tirdea wrote:
> > >
> > > > Fix sparse warning:
> > > > drivers/input/touchscreen/goodix.c:182:26: warning:
> > > > Variable length array is used.
> > > >
> > > > Replace the variable length array with fixed length.
> > > >
> > > > Signed-off-by: Irina Tirdea
> > > > ---
> > > > drivers/input/touchscreen/goodix.c | 2 +-
> > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/input/touchscreen/goodix.c
> > > > b/drivers/input/touchscreen/goodix.c
> > > > index c2e785c..dac1b3c 100644
> > > > --- a/drivers/input/touchscreen/goodix.c
> > > > +++ b/drivers/input/touchscreen/goodix.c
> > > > @@ -147,7 +147,7 @@ static void goodix_ts_report_touch(struct
> > > > goodix_ts_data *ts, u8 *coor_data)
> > > > */
> > > > static void goodix_process_events(struct goodix_ts_data *ts)
> > > > {
> > > > - u8 point_data[1 + GOODIX_CONTACT_SIZE * ts->max_touch_num];
> > > > + u8 point_data[1 + GOODIX_CONTACT_SIZE * GOODIX_MAX_CONTACTS];
> > >
> > > Hi,
> > >
> >
> > Hi Antonio,
> >
> > > this fixes the warning from sparse, but also changes the semantics of
> > > the code: ts->max_touch_num is less that GOODIX_MAX_CONTACTS for 5
> > > touches devices and in this case we'll end up using more memory than is
> > > necessary.
> > >
> >
> > I wasn't sure if it is better to save the 5 bytes or fix the warning,
> > so I sent this to get some more input.
> > Thanks for the feedback, I will drop this patch.
> >
>
> Use kmalloc() or, alternatively, add at least a comment telling why you
> think that sacrificing a few bytes —only for some devices— has
> advantages over dynamic allocation.
>
You are right, kmalloc will solve both problems - the sparse warning and
allocating
more bytes than necessary. Don't know why I did not think of that.
Will use that in v2.
Thanks,
Irina
> I am not necessarily against the static allocation change, I was just
> pointing out the issue.
>
> Thanks,
>Antonio
>
> --
> Antonio Ospite
> http://ao2.it
>
> A: Because it messes up the order in which people normally read text.
>See http://en.wikipedia.org/wiki/Posting_style
> Q: Why is top-posting such a bad thing?
> --
> To unsubscribe from this list: send the line "unsubscribe linux-input" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/9] input: goodix: fix variable length array warning
> -Original Message-
> From: Antonio Ospite [mailto:a...@ao2.it]
> Sent: 28 May, 2015 18:58
> To: Tirdea, Irina
> Cc: Dmitry Torokhov; Bastien Nocera; linux-in...@vger.kernel.org;
> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH 2/9] input: goodix: fix variable length array warning
>
> On Thu, 28 May 2015 15:47:38 +0300
> Irina Tirdea wrote:
>
> > Fix sparse warning:
> > drivers/input/touchscreen/goodix.c:182:26: warning:
> > Variable length array is used.
> >
> > Replace the variable length array with fixed length.
> >
> > Signed-off-by: Irina Tirdea
> > ---
> > drivers/input/touchscreen/goodix.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/input/touchscreen/goodix.c
> > b/drivers/input/touchscreen/goodix.c
> > index c2e785c..dac1b3c 100644
> > --- a/drivers/input/touchscreen/goodix.c
> > +++ b/drivers/input/touchscreen/goodix.c
> > @@ -147,7 +147,7 @@ static void goodix_ts_report_touch(struct
> > goodix_ts_data *ts, u8 *coor_data)
> > */
> > static void goodix_process_events(struct goodix_ts_data *ts)
> > {
> > - u8 point_data[1 + GOODIX_CONTACT_SIZE * ts->max_touch_num];
> > + u8 point_data[1 + GOODIX_CONTACT_SIZE * GOODIX_MAX_CONTACTS];
>
> Hi,
>
Hi Antonio,
> this fixes the warning from sparse, but also changes the semantics of
> the code: ts->max_touch_num is less that GOODIX_MAX_CONTACTS for 5
> touches devices and in this case we'll end up using more memory than is
> necessary.
>
I wasn't sure if it is better to save the 5 bytes or fix the warning, so I sent
this to get some more input.
Thanks for the feedback, I will drop this patch.
Thanks,
Irina
> Thanks,
>Antonio
>
> > int touch_num;
> > int i;
> >
> > --
> > 1.9.1
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-input" in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
>
> --
> Antonio Ospite
> http://ao2.it
>
> A: Because it messes up the order in which people normally read text.
>See http://en.wikipedia.org/wiki/Posting_style
> Q: Why is top-posting such a bad thing?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 8/9] input: goodix: add support for ESD
> -Original Message- > From: linux-input-ow...@vger.kernel.org > [mailto:linux-input-ow...@vger.kernel.org] On Behalf Of Mark Rutland > Sent: 28 May, 2015 16:24 > To: Tirdea, Irina > Cc: Dmitry Torokhov; Bastien Nocera; linux-in...@vger.kernel.org; > devicet...@vger.kernel.org; linux-kernel@vger.kernel.org > Subject: Re: [PATCH 8/9] input: goodix: add support for ESD > > On Thu, May 28, 2015 at 01:47:44PM +0100, Irina Tirdea wrote: > > Add ESD (Electrostatic Discharge) protection mechanism. > > > > The driver enables ESD protection in HW and checks a register > > to determine if ESD occurred. If ESD is signalled by the HW, > > the driver will reset the device. > > > > The ESD poll time (in ms) can be set through > > esd-recovery-timeout-ms ACPI/DT property. If it is set to 0, > > ESD protection is disabled. > > > > Signed-off-by: Irina Tirdea > > --- > > .../bindings/input/touchscreen/goodix.txt | 4 + > > drivers/input/touchscreen/goodix.c | 106 > > - > > 2 files changed, 106 insertions(+), 4 deletions(-) > > > > diff --git a/Documentation/devicetree/bindings/input/touchscreen/goodix.txt > b/Documentation/devicetree/bindings/input/touchscreen/goodix.txt > > index 9e4ff69..9132ee0 100644 > > --- a/Documentation/devicetree/bindings/input/touchscreen/goodix.txt > > +++ b/Documentation/devicetree/bindings/input/touchscreen/goodix.txt > > @@ -19,6 +19,10 @@ Optional properties: > > > > - device-config : device configuration information (specified as byte > > array). Maximum size is 240 bytes. > > + - esd-recovery-timeout-ms : ESD poll time (in milli seconds) for the > > driver to > > +check if ESD occurred and in that case reset the > > +device. ESD is disabled if this property is not set > > +or is set to 0. > > This sounds like software configuration rather than HW description. Is > there any reason this needs to be a DT property? > Although this enables a software feature, it depends on the platform if electrostatic discharge protection should be enabled or not. Some platform designs handle ESD better and do not need the SW mechanism, so the property can be used to disable it. I also saw an example in Documentation/devicetree/bindings/input/touchscreen/tsc2005.txt and I though this is the standard way to use it. > Can we not just choose a sensible default and allow this to be > overridden dynamically? I could separate the enabling part from the actual poll timeout by using a DT property to enable/disable ESD and a sysfs property to set the timeout. I can also move this over to sysfs entirely if you prefer. Thanks, Irina > > Mark. > -- > To unsubscribe from this list: send the line "unsubscribe linux-input" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 6/9] input: goodix: write configuration data to device
> -Original Message- > From: Mark Rutland [mailto:mark.rutl...@arm.com] > Sent: 28 May, 2015 16:22 > To: Tirdea, Irina > Cc: Dmitry Torokhov; Bastien Nocera; linux-in...@vger.kernel.org; > devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; > Purdila, Octavian > Subject: Re: [PATCH 6/9] input: goodix: write configuration data to device > > On Thu, May 28, 2015 at 01:47:42PM +0100, Irina Tirdea wrote: > > Goodix devices can be configured by writing this information > > to the device at init. The configuration data can > > be provided through the ACPI/device tree property > > "device-config". If "device-config" is not set, the default > > device configuration will be used. > > > > Signed-off-by: Octavian Purdila > > Signed-off-by: Irina Tirdea > > --- > > .../bindings/input/touchscreen/goodix.txt | 5 + > > drivers/input/touchscreen/goodix.c | 143 > > + > > 2 files changed, 148 insertions(+) > > > > diff --git a/Documentation/devicetree/bindings/input/touchscreen/goodix.txt > b/Documentation/devicetree/bindings/input/touchscreen/goodix.txt > > index 7137881..9e4ff69 100644 > > --- a/Documentation/devicetree/bindings/input/touchscreen/goodix.txt > > +++ b/Documentation/devicetree/bindings/input/touchscreen/goodix.txt > > @@ -15,6 +15,11 @@ Required properties: > > - irq-gpio: GPIO pin used for IRQ > > - reset-gpio : GPIO pin used for reset > > > > +Optional properties: > > + > > + - device-config : device configuration information (specified as byte > > + array). Maximum size is 240 bytes. > > Generally we frown on passing opaque data. > > What exactly is encoded in device-config? The description is very vague. > > Does this correspond to anything in a data sheet or manual? Yes, it is configuration data described in chapter 6.2. b of the datasheet: https://drive.google.com/folderview?id=0BxCVOQS3ZymGfmJyY2RKbE5XbVlKNlktVTlwV0lxNEdxd2dzeWZER094cmJPVnMxN1F0Yzg&usp=sharing. This includes things like x/y resolution, maximum touch numbers supported, interrupt flags, various sensitivity factors. I should have included a link to the datasheet in the commit message - will do that in v2 for all patches. I did consider writing this as firmware, but it seems that some Goodix touchscreens have a real firmware they need to write in addition to this configuration data. If there is a better way to do this, please let me know and I will change it. Thanks, Irina > > Mark. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 5/9] input: goodix: reset device at init
> -Original Message- > From: Mark Rutland [mailto:mark.rutl...@arm.com] > Sent: 28 May, 2015 16:20 > To: Tirdea, Irina > Cc: Dmitry Torokhov; Bastien Nocera; linux-in...@vger.kernel.org; > devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; > Purdila, Octavian > Subject: Re: [PATCH 5/9] input: goodix: reset device at init > > Hi, > Hi Mark, Thanks for your quick review! > On Thu, May 28, 2015 at 01:47:41PM +0100, Irina Tirdea wrote: > > After power on, it is recommended that the driver resets the device. > > For reset the driver needs to control the interrupt and > > reset gpio pins (configured through ACPI/device tree). > > Why is it necessary to mess with the GPIO the interrupts is wired up to? > What exactly does the device expect at reset w.r.t. the interrupt line? > The reset procedure is described in the Goodix documentation (https://drive.google.com/folderview?id=0BxCVOQS3ZymGfmJyY2RKbE5XbVlKNlktVTlwV0lxNEdxd2dzeWZER094cmJPVnMxN1F0Yzg&usp=sharing) and implemented in their reference driver. It is used at device init (before writing device configuration) and for power management (as described in chapter 7.1 of the documentation, when entering suspend the device must output low on the interrupt pin and when resuming it must output high on the interrupt pin). > > > > Signed-off-by: Octavian Purdila > > Signed-off-by: Irina Tirdea > > --- > > .../bindings/input/touchscreen/goodix.txt | 5 ++ > > drivers/input/touchscreen/goodix.c | 99 > > ++ > > 2 files changed, 104 insertions(+) > > > > diff --git a/Documentation/devicetree/bindings/input/touchscreen/goodix.txt > b/Documentation/devicetree/bindings/input/touchscreen/goodix.txt > > index 8ba98ee..7137881 100644 > > --- a/Documentation/devicetree/bindings/input/touchscreen/goodix.txt > > +++ b/Documentation/devicetree/bindings/input/touchscreen/goodix.txt > > @@ -12,6 +12,8 @@ Required properties: > > - reg : I2C address of the chip. Should be 0x5d or > > 0x14 > > - interrupt-parent: Interrupt controller to which the chip is > > connected > > - interrupts : Interrupt to which the chip is connected > > + - irq-gpio: GPIO pin used for IRQ > > + - reset-gpio : GPIO pin used for reset > > > > Example: > > > > @@ -23,6 +25,9 @@ Example: > > reg = <0x5d>; > > interrupt-parent = <&gpio>; > > interrupts = <0 0>; > > + > > + irq-gpio = <&gpio1 0 0>; > > + reset-gpio = <&gpio1 1 0>; > > }; > > > > /* ... */ > > diff --git a/drivers/input/touchscreen/goodix.c > > b/drivers/input/touchscreen/goodix.c > > index 9e7d215..4405c55 100644 > > --- a/drivers/input/touchscreen/goodix.c > > +++ b/drivers/input/touchscreen/goodix.c > > @@ -26,6 +26,7 @@ > > #include > > #include > > #include > > +#include > > Nit: weird include ordering. Will fix this in v2. > > Mark. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v2 1/4] iio: magn: Add support for BMC150 magnetometer
> -Original Message- > From: Jonathan Cameron [mailto:ji...@kernel.org] > Sent: 26 April, 2015 20:19 > To: Tirdea, Irina; linux-...@vger.kernel.org; devicet...@vger.kernel.org > Cc: linux-kernel@vger.kernel.org; Hartmut Knaack; Lars-Peter Clausen; Peter > Meerwald; Rob Herring; Pawel Moll; Mark Rutland; Ian > Campbell; Kumar Gala > Subject: Re: [PATCH v2 1/4] iio: magn: Add support for BMC150 magnetometer > > On 23/04/15 19:34, Irina Tirdea wrote: > > Add support for the Bosh BMC150 Magnetometer. > Bosch. Good start :) > > The specification can be downloaded from: > > http://ae-bst.resource.bosch.com/media/products/dokumente/bmc150/BST-BMC150-DS000-04.pdf. > > The chip contains both an accelerometer and a magnetometer. > > This patch adds support only for the magnetometer part. > > > > The temperature compensation formulas are based on bmm050_api.c > > authored by cont...@bosch.sensortec.com. > > > > Signed-off-by: Irina Tirdea > Very nice. A couple of tiny bits inline. I'd like to leave this > on the list for a few more days to see if anyone else has any comments > to add to mine. We are very early in this cycle, so no rush! > Thanks for the review, Jonathan! > Thanks, > > Jonathan > > --- > > drivers/iio/magnetometer/Kconfig | 14 + > > drivers/iio/magnetometer/Makefile | 2 + > > drivers/iio/magnetometer/bmc150_magn.c | 986 > > + > > 3 files changed, 1002 insertions(+) > > create mode 100644 drivers/iio/magnetometer/bmc150_magn.c > > > > diff --git a/drivers/iio/magnetometer/Kconfig > > b/drivers/iio/magnetometer/Kconfig > > index a5d6de7..008baca 100644 > > --- a/drivers/iio/magnetometer/Kconfig > > +++ b/drivers/iio/magnetometer/Kconfig > > @@ -76,4 +76,18 @@ config IIO_ST_MAGN_SPI_3AXIS > > depends on IIO_ST_MAGN_3AXIS > > depends on IIO_ST_SENSORS_SPI > > > > +config BMC150_MAGN > > + tristate "Bosch BMC150 Magnetometer Driver" > > + depends on I2C > > + select IIO_BUFFER > > + select IIO_TRIGGERED_BUFFER > > + help > > + Say yes here to build support for the BMC150 magnetometer. > > + > > + Currently this only supports the device via an i2c interface. > > + > > + This is a combo module with both accelerometer and magnetometer. > > + This driver is only implementing magnetometer part, which has > > + its own address and register map. > > + > > endmenu > > diff --git a/drivers/iio/magnetometer/Makefile > > b/drivers/iio/magnetometer/Makefile > > index 0f5d3c9..e2c3459 100644 > > --- a/drivers/iio/magnetometer/Makefile > > +++ b/drivers/iio/magnetometer/Makefile > > @@ -13,3 +13,5 @@ st_magn-$(CONFIG_IIO_BUFFER) += st_magn_buffer.o > > > > obj-$(CONFIG_IIO_ST_MAGN_I2C_3AXIS) += st_magn_i2c.o > > obj-$(CONFIG_IIO_ST_MAGN_SPI_3AXIS) += st_magn_spi.o > > + > > +obj-$(CONFIG_BMC150_MAGN) += bmc150_magn.o > > diff --git a/drivers/iio/magnetometer/bmc150_magn.c > > b/drivers/iio/magnetometer/bmc150_magn.c > > new file mode 100644 > > index 000..b8e4c90 > > --- /dev/null > > +++ b/drivers/iio/magnetometer/bmc150_magn.c > > @@ -0,0 +1,986 @@ > > +/* > > + * Bosch BMC150 three-axis magnetic field sensor driver > > + * > > + * Copyright (c) 2015, Intel Corporation. > > + * > > + * This code is based on bmm050_api.c authored by > > cont...@bosch.sensortec.com: > > + * > > + * (C) Copyright 2011~2014 Bosch Sensortec GmbH All Rights Reserved > > + * > > + * This program is free software; you can redistribute it and/or modify it > > + * under the terms and conditions of the GNU General Public License, > > + * version 2, as published by the Free Software Foundation. > > + * > > + * This program is distributed in the hope it will be useful, but WITHOUT > > + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or > > + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License > > for > > + * more details. > > + */ > > + > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > + > > +#define BMC150_MAGN_DRV_NAME "bmc150_magn" > > +#define BMC150_MAGN_IRQ_NAME
RE: [PATCH v2 14/17] iio: accel: mma9551_core: use size in words for word buffers
> -Original Message-
> From: Jonathan Cameron [mailto:ji...@kernel.org]
> Sent: 26 April, 2015 22:05
> To: Tirdea, Irina; linux-...@vger.kernel.org; Hartmut Knaack
> Cc: linux-kernel@vger.kernel.org; Dogaru, Vlad
> Subject: Re: [PATCH v2 14/17] iio: accel: mma9551_core: use size in words for
> word buffers
>
> On 13/04/15 16:41, Irina Tirdea wrote:
> > Change the prototype for the mma9551_read/write_*_words functions
> > to receive the length of the buffer in words (instead of bytes) since
> > we are using a word buffer. This will prevent users from sending an
> > odd number of bytes for a word array.
> >
> > Signed-off-by: Irina Tirdea
> Lots of merge issues by this point in the series so I'll hold this one at
> least until the fixes filter through.
>
> Remind me if I seem to have forgotten (it wouldn't be the first time :)
>
Sure, I'll keep an eye on when the fixes will be merged in togreg branch.
Thanks,
Irina
> Jonathan
> > ---
> > drivers/iio/accel/mma9551_core.c | 27 ---
> > drivers/iio/accel/mma9553.c | 9 ++---
> > 2 files changed, 18 insertions(+), 18 deletions(-)
> >
> > diff --git a/drivers/iio/accel/mma9551_core.c
> > b/drivers/iio/accel/mma9551_core.c
> > index 2fd2a99..583660b 100644
> > --- a/drivers/iio/accel/mma9551_core.c
> > +++ b/drivers/iio/accel/mma9551_core.c
> > @@ -373,7 +373,7 @@ EXPORT_SYMBOL(mma9551_read_status_word);
> > * @client:I2C client
> > * @app_id:Application ID
> > * @reg: Application register
> > - * @len: Length of array to read in bytes
> > + * @len: Length of array to read (in words)
> > * @buf: Array of words to read
> > *
> > * Read multiple configuration registers (word-sized registers).
> > @@ -388,20 +388,19 @@ int mma9551_read_config_words(struct i2c_client
> > *client, u8 app_id,
> > u16 reg, u8 len, u16 *buf)
> > {
> > int ret, i;
> > - int len_words = len / sizeof(u16);
> > __be16 be_buf[MMA9551_MAX_MAILBOX_DATA_REGS / 2];
> >
> > - if (len_words > ARRAY_SIZE(be_buf)) {
> > + if (len > ARRAY_SIZE(be_buf)) {
> > dev_err(&client->dev, "Invalid buffer size %d\n", len);
> > return -EINVAL;
> > }
> >
> > ret = mma9551_transfer(client, app_id, MMA9551_CMD_READ_CONFIG,
> > - reg, NULL, 0, (u8 *) be_buf, len);
> > + reg, NULL, 0, (u8 *)be_buf, len * sizeof(u16));
> > if (ret < 0)
> > return ret;
> >
> > - for (i = 0; i < len_words; i++)
> > + for (i = 0; i < len; i++)
> > buf[i] = be16_to_cpu(be_buf[i]);
> >
> > return 0;
> > @@ -413,7 +412,7 @@ EXPORT_SYMBOL(mma9551_read_config_words);
> > * @client:I2C client
> > * @app_id:Application ID
> > * @reg: Application register
> > - * @len: Length of array to read in bytes
> > + * @len: Length of array to read (in words)
> > * @buf: Array of words to read
> > *
> > * Read multiple status registers (word-sized registers).
> > @@ -428,20 +427,19 @@ int mma9551_read_status_words(struct i2c_client
> > *client, u8 app_id,
> > u16 reg, u8 len, u16 *buf)
> > {
> > int ret, i;
> > - int len_words = len / sizeof(u16);
> > __be16 be_buf[MMA9551_MAX_MAILBOX_DATA_REGS / 2];
> >
> > - if (len_words > ARRAY_SIZE(be_buf)) {
> > + if (len > ARRAY_SIZE(be_buf)) {
> > dev_err(&client->dev, "Invalid buffer size %d\n", len);
> > return -EINVAL;
> > }
> >
> > ret = mma9551_transfer(client, app_id, MMA9551_CMD_READ_STATUS,
> > - reg, NULL, 0, (u8 *) be_buf, len);
> > + reg, NULL, 0, (u8 *)be_buf, len * sizeof(u16));
> > if (ret < 0)
> > return ret;
> >
> > - for (i = 0; i < len_words; i++)
> > + for (i = 0; i < len; i++)
> > buf[i] = be16_to_cpu(be_buf[i]);
> >
> > return 0;
> > @@ -453,7 +451,7 @@ EXPORT_SYMBOL(mma9551_read_status_words);
> > * @client:I2C client
> > * @app_id:Application ID
> > * @reg: Application register
> > - * @len: Length of array to write in bytes
> > + * @len: Length of array to write (in words)
> > * @buf: Array of words to write
> > *
> > * Write multiple co
RE: [PATCH 3/3] iio: magn: bmc150_magn: Add devicetree binding documentation
> -Original Message-
> From: linux-iio-ow...@vger.kernel.org
> [mailto:linux-iio-ow...@vger.kernel.org] On Behalf Of Jonathan Cameron
> Sent: 18 April, 2015 21:09
> To: Tirdea, Irina; linux-...@vger.kernel.org; devicet...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org; Hartmut Knaack; Lars-Peter Clausen; Peter
> Meerwald; Rob Herring; Pawel Moll; Mark Rutland; Ian
> Campbell; Kumar Gala
> Subject: Re: [PATCH 3/3] iio: magn: bmc150_magn: Add devicetree binding
> documentation
>
> On 17/04/15 11:50, Irina Tirdea wrote:
> > Add binding documentation for Bosch BMC150 magnetometer.
> >
> > Signed-off-by: Irina Tirdea
> > ---
> > .../bindings/iio/magnetometer/bmc150_magn.txt| 20
> >
> > 1 file changed, 20 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/iio/magnetometer/bmc150_magn.txt
> >
> > diff --git
> > a/Documentation/devicetree/bindings/iio/magnetometer/bmc150_magn.txt
> b/Documentation/devicetree/bindings/iio/magnetometer/bmc150_magn.txt
> > new file mode 100644
> > index 000..4ed035c
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/iio/magnetometer/bmc150_magn.txt
> > @@ -0,0 +1,20 @@
> > +* Bosch BMC150 magnetometer sensor
> > +
> > +http://ae-bst.resource.bosch.com/media/products/dokumente/bmc150/BST-BMC150-DS000-04.pdf
> > +
> > +Required properties:
> > +
> > + - compatible : should be "bosch,bmc150_magn"
> > + - reg : the I2C address of the magnetometer
> > +
> > +Optional properties:
> > +
> > + - gpios : should be device tree identifier of the magnetometer DRDY pin
> Hmm. Under device tree this should be done as an interrupt. You only
> (currently) need the dubious frig with gpios for ACPI I think.
Using the gpios declared like this, it will go the same code path as the ACPI.
I wasn't sure which to list in the optional properties, so I used gpios because
the other magnetometer device tree
bindings listed also gpios.
It is better to specify the interrupt directly since it will be handled by the
core, so I will remove gpios and list interrupts
instead.
Thanks,
Irina
> > +
> > +Example:
> > +
> > +bmc150_magn@12 {
> > +compatible = "bosch,bmc150_magn";
> > +reg = <0x12>;
> > +interrupt-gpio = <&gpio1 0 1>;
> > +};
> >
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 2/3] iio: magn: Add support for BMC150 magnetometer
> -Original Message- > From: Jonathan Cameron [mailto:ji...@kernel.org] > Sent: 18 April, 2015 21:07 > To: Tirdea, Irina; linux-...@vger.kernel.org; devicet...@vger.kernel.org > Cc: linux-kernel@vger.kernel.org; Hartmut Knaack; Lars-Peter Clausen; Peter > Meerwald; Rob Herring; Pawel Moll; Mark Rutland; Ian > Campbell; Kumar Gala > Subject: Re: [PATCH 2/3] iio: magn: Add support for BMC150 magnetometer > > On 17/04/15 11:50, Irina Tirdea wrote: > > Add support for the Bosh BMC150 Magnetometer. > > The specification can be downloaded from: > > http://ae-bst.resource.bosch.com/media/products/dokumente/bmc150/BST-BMC150-DS000-04.pdf. > > The chip contains both an accelerometer and a magnetometer. > > This patch adds support only for the magnetometer part. > > > > The temperature compensation formulas are based on bmm050_api.c > > authored by cont...@bosch.sensortec.com. > > > > Signed-off-by: Irina Tirdea > Generally looks good, but a few odd bits and pieces... Thanks for the review, Jonathan! > Quite a few places you use regmap_update_bits to write with a mask of 0xFF > which seems odd.. > The idea there is to not do unnecessary i2c_reads/writes if the value does not change: regmap_update_bits will check the cached value and only do the i2c transfer if the value did not change. > Various other bits inline. > > --- > > drivers/iio/magnetometer/Kconfig | 14 + > > drivers/iio/magnetometer/Makefile |2 + > > drivers/iio/magnetometer/bmc150_magn.c | 1060 > > > > 3 files changed, 1076 insertions(+) > > create mode 100644 drivers/iio/magnetometer/bmc150_magn.c > > > > diff --git a/drivers/iio/magnetometer/Kconfig > > b/drivers/iio/magnetometer/Kconfig > > index a5d6de7..008baca 100644 > > --- a/drivers/iio/magnetometer/Kconfig > > +++ b/drivers/iio/magnetometer/Kconfig > > @@ -76,4 +76,18 @@ config IIO_ST_MAGN_SPI_3AXIS > > depends on IIO_ST_MAGN_3AXIS > > depends on IIO_ST_SENSORS_SPI > > > > +config BMC150_MAGN > > + tristate "Bosch BMC150 Magnetometer Driver" > > + depends on I2C > > + select IIO_BUFFER > > + select IIO_TRIGGERED_BUFFER > > + help > > + Say yes here to build support for the BMC150 magnetometer. > > + > > + Currently this only supports the device via an i2c interface. > > + > > + This is a combo module with both accelerometer and magnetometer. > > + This driver is only implementing magnetometer part, which has > > + its own address and register map. > > + > > endmenu > > diff --git a/drivers/iio/magnetometer/Makefile > > b/drivers/iio/magnetometer/Makefile > > index 0f5d3c9..e2c3459 100644 > > --- a/drivers/iio/magnetometer/Makefile > > +++ b/drivers/iio/magnetometer/Makefile > > @@ -13,3 +13,5 @@ st_magn-$(CONFIG_IIO_BUFFER) += st_magn_buffer.o > > > > obj-$(CONFIG_IIO_ST_MAGN_I2C_3AXIS) += st_magn_i2c.o > > obj-$(CONFIG_IIO_ST_MAGN_SPI_3AXIS) += st_magn_spi.o > > + > > +obj-$(CONFIG_BMC150_MAGN) += bmc150_magn.o > > diff --git a/drivers/iio/magnetometer/bmc150_magn.c > > b/drivers/iio/magnetometer/bmc150_magn.c > > new file mode 100644 > > index 000..e970a0c > > --- /dev/null > > +++ b/drivers/iio/magnetometer/bmc150_magn.c > > @@ -0,0 +1,1060 @@ > > +/* > > + * Bosch BMC150 three-axis magnetic field sensor driver > > + * > > + * Copyright (c) 2015, Intel Corporation. > > + * > > + * This code is based on bmm050_api.c authored by > > cont...@bosch.sensortec.com: > > + * > > + * (C) Copyright 2011~2014 Bosch Sensortec GmbH All Rights Reserved > > + * > > + * This program is free software; you can redistribute it and/or modify it > > + * under the terms and conditions of the GNU General Public License, > > + * version 2, as published by the Free Software Foundation. > > + * > > + * This program is distributed in the hope it will be useful, but WITHOUT > > + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or > > + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License > > for > > + * more details. > > + */ > > + > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > + > > +#d
RE: [PATCH 1/3] iio: core: Introduce IIO_CHAN_INFO_CALIBREPETITIONS
> -Original Message-
> From: Jonathan Cameron [mailto:ji...@kernel.org]
> Sent: 18 April, 2015 19:47
> To: Tirdea, Irina; linux-...@vger.kernel.org; devicet...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org; Hartmut Knaack; Lars-Peter Clausen; Peter
> Meerwald; Rob Herring; Pawel Moll; Mark Rutland; Ian
> Campbell; Kumar Gala
> Subject: Re: [PATCH 1/3] iio: core: Introduce IIO_CHAN_INFO_CALIBREPETITIONS
>
> On 17/04/15 11:50, Irina Tirdea wrote:
> > Some magnetometers can perform a number of repetitions in HW
> > for each measurement to increase accuracy. One example is
> > Bosch BMC150:
> > http://ae-bst.resource.bosch.com/media/products/dokumente/bmc150/BST-BMC150-DS000-04.pdf.
> >
> > Introduce an interface to set the number of repetitions
> > for these devices.
> >
> > Signed-off-by: Irina Tirdea
> > ---
> > Documentation/ABI/testing/sysfs-bus-iio | 10 ++
> > drivers/iio/industrialio-core.c | 1 +
> > include/linux/iio/iio.h | 1 +
> > 3 files changed, 12 insertions(+)
> >
> > diff --git a/Documentation/ABI/testing/sysfs-bus-iio
> > b/Documentation/ABI/testing/sysfs-bus-iio
> > index 866b4ec..74c1444 100644
> > --- a/Documentation/ABI/testing/sysfs-bus-iio
> > +++ b/Documentation/ABI/testing/sysfs-bus-iio
> > @@ -1375,3 +1375,13 @@ Description:
> > The emissivity ratio of the surface in the field of view of the
> > contactless temperature sensor. Emissivity varies from 0 to 1,
> > with 1 being the emissivity of a black body.
> > +
> > +What:
> > /sys/bus/iio/devices/iio:deviceX/in_magn_x_calibrepetitions
> > +What:
> > /sys/bus/iio/devices/iio:deviceX/in_magn_y_calibrepetitions
> > +What:
> > /sys/bus/iio/devices/iio:deviceX/in_magn_z_calibrepetitions
> > +KernelVersion: 4.2
> > +Contact: linux-...@vger.kernel.org
> > +Description:
> > + Hardware applied number of repetitions for acquiring one
> > + data point. The HW will do [_name]_calibrepetitions
> > + measurements and return the average value as output data.
> This is an interesting way of naming what is often referred to as
> oversampling.
> I'd like to get some other opinions on naming before we go with the ABI for
> this..
>
> We do have one driver in staging exporting oversampling_ratio which is
> probably
> the same thing, but that ABI was never standardized so I have no problem with
> ignoring that one case. A couple of other drivers provide oversampling
> control
> via platform data. We must make sure we give a sensible default for this.
>
I didn't know about the oversampling_ratio. I used "repetitions" because Bosch
calls them so
in the datasheet.
However, I think oversampling_ratio is a better name since it suggests a
connection with sampling. I will change it to oversampling_ratio in v2 and then
wait for more opinions on this.
> There is also the interesting question of whether sampling_frequency applies
> before or after this... I'd argue after, but again would like more opinions
> before we dictate that. However, whatever we choose should definitely be
> documented here!
>
The HW sees the sampling_frequency as the frequency the user sees, so it does
not take into
account the oversampling_ratio: each value resulted after oversampling_ratio
repetitions is
considered one sample for the sampling_frequency. However, I am not sure how
other
devices handle this so more opinions on this would be useful.
Looking more into the oversampling ratio from BMC150, seems there are some
sampling limitations I missed the first time: when setting a certain value for
x/y/z repetitions,
not all sampling rates are available. I am going to fix this in v2 by not
allowing invalid
sampling rates once a certain value for oversampling_ratio is set.
Thanks,
Irina
> > diff --git a/drivers/iio/industrialio-core.c
> > b/drivers/iio/industrialio-core.c
> > index 7c98bc1..9e0da7f 100644
> > --- a/drivers/iio/industrialio-core.c
> > +++ b/drivers/iio/industrialio-core.c
> > @@ -129,6 +129,7 @@ static const char * const iio_chan_info_postfix[] = {
> > [IIO_CHAN_INFO_DEBOUNCE_COUNT] = "debounce_count",
> > [IIO_CHAN_INFO_DEBOUNCE_TIME] = "debounce_time",
> > [IIO_CHAN_INFO_CALIBEMISSIVITY] = "calibemissivity",
> > + [IIO_CHAN_INFO_CALIBREPETITIONS] = "calibrepetitions",
> > };
> >
> > /**
> > diff --git a/include/linux/iio/iio.h b/include/linux/iio/iio.h
> > index b1e46ae..07fbfb2 100644
> > --- a/include/linux/
RE: [RFC PATCH 1/1] i2c: core: Add support for best effort block read emulation
> -Original Message-
> From: Wolfram Sang [mailto:w...@the-dreams.de]
> Sent: 15 April, 2015 18:55
> To: Tirdea, Irina
> Cc: linux-...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [RFC PATCH 1/1] i2c: core: Add support for best effort block
> read emulation
>
> On Wed, Mar 25, 2015 at 04:33:20PM +0200, Irina Tirdea wrote:
> > There are devices that need to handle block transactions
> > regardless of the capabilities exported by the adapter.
> > For performance reasons, they need to use i2c read blocks
> > if available, otherwise emulate the block transaction with word
> > or byte transactions.
> >
> > Add support for a helper function that would read a data block
> > using the best transfer available: I2C_FUNC_SMBUS_READ_I2C_BLOCK,
> > I2C_FUNC_SMBUS_READ_WORD_DATA or I2C_FUNC_SMBUS_READ_BYTE_DATA.
> >
> > Signed-off-by: Irina Tirdea
> > ---
> >
> > Hi,
> >
> > This is a new API proposal to handle i2c block emulation in the
> > core instead of the driver code.
> >
> > This is needed for a set of iio sensor changes ([1], [2], [3])
> > that would otherwise duplicate this code. There are also some
> > usages of this functionality in the kernel (e.g. eeprom driver at24).
> >
> > Please let me know what you think.
>
> I am open to add something like this. One change I'd like to request is
> to introduce a user, e.g. convert at24.
>
Thanks for the review!
Sure, I'll send a new version with the fixes you suggested and include a user
as well.
> >
> > Thanks,
> > Irina
> >
> > [1] https://lkml.org/lkml/2015/2/16/408
> > [2] https://lkml.org/lkml/2015/2/16/413
> > [3] https://lkml.org/lkml/2015/2/16/402
> >
> > drivers/i2c/i2c-core.c | 62
> > ++
> > include/linux/i2c.h| 3 +++
> > 2 files changed, 65 insertions(+)
> >
> > diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
> > index fe80f85..2579f7d 100644
> > --- a/drivers/i2c/i2c-core.c
> > +++ b/drivers/i2c/i2c-core.c
> > @@ -2907,6 +2907,68 @@ trace:
> > }
> > EXPORT_SYMBOL(i2c_smbus_xfer);
> >
> > +/**
> > + * i2c_smbus_read_i2c_block_data_or_emulated - read block or emulate
> > + * @client: Handle to slave device
> > + * @command: Byte interpreted by slave
> > + * @length: Size of data block; SMBus allows at most 32 bytes
> > + * @values: Byte array into which data will be read; big enough to hold
> > + * the data returned by the slave. SMBus allows at most 32 bytes.
>
> Sidenote: SMBus3 allows 255 byte, but we don't support that (yet), so
> this is okay for now.
>
> > + *
> > + * This executes the SMBus "block read" protocol if supported by the
> > adapter.
> > + * If block read is not supported, it emulates it using either word or byte
> > + * read protocols depending on availability.
>
> Here I'd like to see a warning that people should double-check if their
> I2C slave does support that. Sometimes one can't exchange a block
> transfer with a byte transfer.
>
Ok.
> > + */
> > +s32 i2c_smbus_read_i2c_block_data_or_emulated(const struct i2c_client
> > *client,
> > + u8 command, u8 length, u8 *values)
> > +{
> > + u8 i;
> > + int status;
> > +
> > + if (length > I2C_SMBUS_BLOCK_MAX)
> > + length = I2C_SMBUS_BLOCK_MAX;
> > +
> > + if (i2c_check_functionality(client->adapter,
> > + I2C_FUNC_SMBUS_READ_I2C_BLOCK)) {
> > + return i2c_smbus_read_i2c_block_data(client, command,
> > +length, values);
> > + } else if (i2c_check_functionality(client->adapter,
> > + I2C_FUNC_SMBUS_READ_WORD_DATA |
> > + I2C_FUNC_SMBUS_READ_BYTE_DATA)) {
>
> What about skipping the need for READ_BYTE_DATA and dump the byte which
> was maybe read too much?
>
Yes, that will simply the code.
> > + for (i = 0; (i + 2) <= length; i += 2) {
> > + status = i2c_smbus_read_word_data(client, command + i);
> > + if (status < 0)
> > + return status;
> > + values[i] = status & 0xff;
> > + values[i+1] = status >> 8;
> > + }
> > + if (i < length) {
> > + status = i2c_s
RE: [PATCH 2/8] iio: accel: mma9553: use unsigned counters
> -Original Message-
> From: Jonathan Cameron [mailto:ji...@kernel.org]
> Sent: 09 April, 2015 14:37
> To: Tirdea, Irina; linux-...@vger.kernel.org; Hartmut Knaack
> Cc: linux-kernel@vger.kernel.org
> Subject: Re: [PATCH 2/8] iio: accel: mma9553: use unsigned counters
>
> On 08/04/15 15:37, Irina Tirdea wrote:
> > Use unsigned counters instead of signed when all the
> > possible values are positive.
> >
> > Signed-off-by: Irina Tirdea
> > Suggested-by: Hartmut Knaack
> Does it make sense to carry this through to mma9551_transfer as well?
> Can't say I really care about this one. It's nice, but the compiler may
> well mess with the types used anyway given it can trivially tell their
> limits...
>
> Still it does no harm so what the heck. Certainly not a high
> priority change though.
Indeed, I should also change mma9551_transfer signature to reflect the changes
for length.
Since this is just a "nice to have" change, will add it at the end of the
series.
Thanks,
Irina
> > ---
> > drivers/iio/accel/mma9551_core.c | 11 +--
> > drivers/iio/accel/mma9553.c | 8
> > 2 files changed, 9 insertions(+), 10 deletions(-)
> >
> > diff --git a/drivers/iio/accel/mma9551_core.c
> > b/drivers/iio/accel/mma9551_core.c
> > index 54b3ae6..438cfed 100644
> > --- a/drivers/iio/accel/mma9551_core.c
> > +++ b/drivers/iio/accel/mma9551_core.c
> > @@ -387,8 +387,8 @@ EXPORT_SYMBOL(mma9551_read_status_word);
> > int mma9551_read_config_words(struct i2c_client *client, u8 app_id,
> > u16 reg, u8 len, u16 *buf)
> > {
> > - int ret, i;
> > - int len_words = len / sizeof(u16);
> > + int ret;
> > + u8 i, len_words = len / sizeof(u16);
> > __be16 be_buf[MMA9551_MAX_MAILBOX_DATA_REGS];
> >
> > ret = mma9551_transfer(client, app_id, MMA9551_CMD_READ_CONFIG,
> > @@ -422,8 +422,8 @@ EXPORT_SYMBOL(mma9551_read_config_words);
> > int mma9551_read_status_words(struct i2c_client *client, u8 app_id,
> > u16 reg, u8 len, u16 *buf)
> > {
> > - int ret, i;
> > - int len_words = len / sizeof(u16);
> > + int ret;
> > + u8 i, len_words = len / sizeof(u16);
> > __be16 be_buf[MMA9551_MAX_MAILBOX_DATA_REGS];
> >
> > ret = mma9551_transfer(client, app_id, MMA9551_CMD_READ_STATUS,
> > @@ -457,8 +457,7 @@ EXPORT_SYMBOL(mma9551_read_status_words);
> > int mma9551_write_config_words(struct i2c_client *client, u8 app_id,
> >u16 reg, u8 len, u16 *buf)
> > {
> > - int i;
> > - int len_words = len / sizeof(u16);
> > + u8 i, len_words = len / sizeof(u16);
> > __be16 be_buf[MMA9551_MAX_MAILBOX_DATA_REGS];
> >
> > for (i = 0; i < len_words; i++)
> > diff --git a/drivers/iio/accel/mma9553.c b/drivers/iio/accel/mma9553.c
> > index d095f81..9cfedb5 100644
> > --- a/drivers/iio/accel/mma9553.c
> > +++ b/drivers/iio/accel/mma9553.c
> > @@ -184,7 +184,7 @@ struct mma9553_data {
> > struct mutex mutex;
> > struct mma9553_conf_regs conf;
> > struct mma9553_event events[MMA9553_EVENTS_INFO_SIZE];#define
> > MMA9551_APPID_RCS 0x17
> +#define MMA9551_APPID_RSC0x17
> > - int num_events;
> > + u8 num_events;
> > u8 gpio_bitnum;
> > /*
> > * This is used for all features that depend on step count:
> > @@ -225,7 +225,7 @@ static enum iio_modifier mma9553_activity_to_mod(enum
> > activity_level activity)
> >
> > static void mma9553_init_events(struct mma9553_data *data)
> > {
> > - int i;
> > + u8 i;
> >
> > data->num_events = MMA9553_EVENTS_INFO_SIZE;
> > for (i = 0; i < data->num_events; i++) {
> > @@ -239,7 +239,7 @@ static struct mma9553_event *mma9553_get_event(struct
> > mma9553_data *data,
> >enum iio_modifier mod,
> >enum iio_event_direction dir)
> > {
> > - int i;
> > + u8 i;
> >
> > for (i = 0; i < data->num_events; i++)
> > if (data->events[i].info->type == type &&
> > @@ -254,7 +254,7 @@ static bool mma9553_is_any_event_enabled(struct
> > mma9553_data *data,
> > bool check_type,
> > enum iio_chan_type type)
> > {
> > - int i;
> > + u8 i;
> >
> > for (i = 0; i < data->num_events; i++)
> > if ((check_type && data->events[i].info->type == type &&
> >
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 7/8] iio: accel: mma9551_core: prevent buffer overrun
> -Original Message-
> From: Jonathan Cameron [mailto:ji...@kernel.org]
> Sent: 09 April, 2015 14:51
> To: Tirdea, Irina; linux-...@vger.kernel.org; Hartmut Knaack
> Cc: linux-kernel@vger.kernel.org
> Subject: Re: [PATCH 7/8] iio: accel: mma9551_core: prevent buffer overrun
>
> On 08/04/15 15:37, Irina Tirdea wrote:
> > The mma9551 functions that read/write word arrays from the
> > device have a limit for the buffer size given by the device
> > specifications.
> >
> > Check that the requested buffer length is within required limits
> > when transferring word arrays. This will prevent buffer overrun
> > in the mma9551_read/write_*_words functions and also in the
> > mma9551_transfer call when writing into the MBOX response/request
> > structure.
> >
> > Change the prototype for the mma9551_read/write_*_words functions
> > to receive the length of the buffer in words (instead of bytes) since
> > we are using a word buffer. This will prevent users from sending an
> > odd number of bytes for a word array.
> >
> > Signed-off-by: Irina Tirdea
> > Suggested-by: Hartmut Knaack
> This is a bit of a mixture of a fix and a refactor. That leaves
> us with a rather longer fix patch than would be ideal.
>
> could you break this into the minimal fix (just check limits and perhaps
> fix the buffer length to be half as long) then a follow up rework patch
> that gets you to the state at the end of this current patch?
>
Sure, I'll break this in two patches: the actual fix and the change in function
signature.
> Thanks,
>
> J
> > ---
> > drivers/iio/accel/mma9551_core.c | 45
> > ++--
> > drivers/iio/accel/mma9553.c | 7 ---
> > 2 files changed, 34 insertions(+), 18 deletions(-)
> >
> > diff --git a/drivers/iio/accel/mma9551_core.c
> > b/drivers/iio/accel/mma9551_core.c
> > index 438cfed..5c6f69d 100644
> > --- a/drivers/iio/accel/mma9551_core.c
> > +++ b/drivers/iio/accel/mma9551_core.c
> > @@ -373,7 +373,7 @@ EXPORT_SYMBOL(mma9551_read_status_word);
> > * @client:I2C client
> > * @app_id:Application ID
> > * @reg: Application register
> > - * @len: Length of array to read in bytes
> > + * @len: Length of array to read (in words)
> > * @buf: Array of words to read
> > *
> > * Read multiple configuration registers (word-sized registers).
> > @@ -388,15 +388,20 @@ int mma9551_read_config_words(struct i2c_client
> > *client, u8 app_id,
> > u16 reg, u8 len, u16 *buf)
> > {
> > int ret;
> > - u8 i, len_words = len / sizeof(u16);
> > - __be16 be_buf[MMA9551_MAX_MAILBOX_DATA_REGS];
> > + u8 i;
> > + __be16 be_buf[MMA9551_MAX_MAILBOX_DATA_REGS / 2];
> > +
> > + if (len > ARRAY_SIZE(be_buf)) {
> > + dev_err(&client->dev, "Invalid buffer size %d\n", len);
> > + return -EINVAL;
> > + }
> >
> > ret = mma9551_transfer(client, app_id, MMA9551_CMD_READ_CONFIG,
> > - reg, NULL, 0, (u8 *) be_buf, len);
> > + reg, NULL, 0, (u8 *)be_buf, len * sizeof(u16));
> > if (ret < 0)
> > return ret;
> >
> > - for (i = 0; i < len_words; i++)
> > + for (i = 0; i < len; i++)
> > buf[i] = be16_to_cpu(be_buf[i]);
> >
> > return 0;
> > @@ -408,7 +413,7 @@ EXPORT_SYMBOL(mma9551_read_config_words);
> > * @client:I2C client
> > * @app_id:Application ID
> > * @reg: Application register
> > - * @len: Length of array to read in bytes
> > + * @len: Length of array to read (in words)
> > * @buf: Array of words to read
> > *
> > * Read multiple status registers (word-sized registers).
> > @@ -423,15 +428,20 @@ int mma9551_read_status_words(struct i2c_client
> > *client, u8 app_id,
> > u16 reg, u8 len, u16 *buf)
> > {
> > int ret;
> > - u8 i, len_words = len / sizeof(u16);
> > - __be16 be_buf[MMA9551_MAX_MAILBOX_DATA_REGS];
> > + u8 i;
> > + __be16 be_buf[MMA9551_MAX_MAILBOX_DATA_REGS / 2];
> > +
> > + if (len > ARRAY_SIZE(be_buf)) {
> > + dev_err(&client->dev, "Invalid buffer size %d\n", len);
> > + return -EINVAL;
> > + }
> >
> > ret = mma9551_transfer(client, app_id, MMA9551_CMD_READ_STATUS,
> > - reg, NULL, 0, (u8 *) be_buf, len);
> > +
