* Re: [PATCH v2 2/3] power: supply: bq24735-charger: optionally poll the ac-detect gpio
From: Sebastian Reichel @ 2016-12-14 15:10 UTC (permalink / raw)
To: Peter Rosin; +Cc: linux-kernel, Rob Herring, Mark Rutland, linux-pm, devicetree
In-Reply-To: <1481673405-4547-3-git-send-email-peda@axentia.se>
[-- Attachment #1: Type: text/plain, Size: 502 bytes --]
Hi,
On Wed, Dec 14, 2016 at 12:56:44AM +0100, Peter Rosin wrote:
> If the ac-detect gpio does not support interrupts, provide a fallback
> to poll the gpio at a configurable interval.
>
> Signed-off-by: Peter Rosin <peda@axentia.se>
> ---
>
> [...]
>
> + } else if (charger->status_gpio) {
> + ret = of_property_read_u32(client->dev.of_node,
> + "poll-interval",
> + &charger->poll_interval);
Please use device_property_read_u32() instead.
> [...]
-- Sebastian
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v2] ARM: dts: sunxi: Change node name for pwrseq pin on Olinuxino-lime2-emmc
From: Maxime Ripard @ 2016-12-14 15:30 UTC (permalink / raw)
To: Emmanuel Vadot
Cc: robh+dt, mark.rutland, linux, wens, devicetree, linux-arm-kernel,
linux-kernel
In-Reply-To: <20161214145724.42745-1-manu@bidouilliste.com>
[-- Attachment #1: Type: text/plain, Size: 559 bytes --]
On Wed, Dec 14, 2016 at 03:57:24PM +0100, Emmanuel Vadot wrote:
> The node name for the power seq pin is mmc2@0 like the mmc2_pins_a one.
> This makes the original node (mmc2_pins_a) scrapped out of the dtb and
> result in a unusable eMMC if U-Boot didn't configured the pins to the
> correct functions.
>
> Changes since v1:
> * Rename the node mmc2-rst-pin
That changelog should be after the ---. Removed it and applied.
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH v2 01/11] power: supply: axp20x_usb_power: use of_device_id data field instead of device_is_compatible
From: Chen-Yu Tsai @ 2016-12-14 15:38 UTC (permalink / raw)
To: Quentin Schulz
Cc: Mark Rutland, devicetree, open list:THERMAL, linux-kernel,
Sebastian Reichel, Russell King, Chen-Yu Tsai, Rob Herring,
Maxime Ripard, Lee Jones, Thomas Petazzoni, linux-arm-kernel
In-Reply-To: <20161209110419.28981-2-quentin.schulz@free-electrons.com>
On Fri, Dec 9, 2016 at 7:04 PM, Quentin Schulz
<quentin.schulz@free-electrons.com> wrote:
> This replaces calls to of_device_is_compatible to check data field of
> of_device_id matched when probing the driver.
>
> Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
Acked-by: Chen-Yu Tsai <wens@csie.org>
^ permalink raw reply
* Re: [PATCH v9 3/3] fpga: Add support for Lattice iCE40 FPGAs
From: Alan Tull @ 2016-12-14 15:40 UTC (permalink / raw)
To: Moritz Fischer
Cc: Joel Holdsworth, Alan Tull, Rob Herring, Devicetree List,
Linux Kernel Mailing List, linux-spi-u79uwXL29TY76Z2rM5mHXA,
Marek Vašut
In-Reply-To: <CAAtXAHcV+AG4en2U=KB0DeLa6RauC9ndojT=ffj+8hWtzS1o4w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Fri, 9 Dec 2016, Moritz Fischer wrote:
> Joel,
>
> A couple of minor nits below (none of them are real blockers), other
> than that looks good.
>
> On Thu, Dec 8, 2016 at 9:35 PM, Joel Holdsworth
> <joel-IJEoVVyKhCJXvIrf17iDB/XRex20P6io@public.gmane.org> wrote:
> > The Lattice iCE40 is a family of FPGAs with a minimalistic architecture
> > and very regular structure, designed for low-cost, high-volume consumer
> > and system applications.
>
> <snip>
>
> > This patch adds support to the FPGA manager for configuring the SRAM of
> > iCE40LM, iCE40LP, iCE40HX, iCE40 Ultra, iCE40 UltraLite and iCE40
> > UltraPlus devices, through slave SPI.
>
> </snip>
>
> I think just this paragraph would be enough.
With these changes,
Acked-by: Alan Tull <atull-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx@public.gmane.org>
Thanks,
Alan
> >
> > The iCE40 family is notable because it is the first FPGA family to have
> > complete reverse engineered bit-stream documentation for the iCE40LP and
> > iCE40HX devices. Furthermore, there is now a Free Software Verilog
> > synthesis tool-chain: the "IceStorm" tool-chain.
> >
> > This project is the work of Clifford Wolf, who is the maintainer of
> > Yosys Verilog RTL synthesis framework, and Mathias Lasser, with notable
> > contributions from "Cotton Seed", the main author of "arachne-pnr"; a
> > place-and-route tool for iCE40 FPGAs.
> >
> > Having a Free Software synthesis tool-chain offers interesting
> > opportunities for embedded devices that are able reconfigure themselves
> > with open firmware that is generated on the device itself. For example
> > a mobile device might have an application processor with an iCE40 FPGA
> > attached, which implements slave devices, or through which the processor
> > communicates with other devices through the FPGA fabric.
> >
> > A kernel driver for the iCE40 is useful, because in some cases, the FPGA
> > may need to be configured before other devices can be accessed.
> >
> > An example of such a device is the icoBoard; a RaspberryPI HAT which
> > features an iCE40HX8K with a 1 or 8 MBit SRAM and ports for
> > Digilent-compatible PMOD modules. A PMOD module may contain a device
> > with which the kernel communicates, via the FPGA.
> >
> > Signed-off-by: Joel Holdsworth <joel-IJEoVVyKhCJXvIrf17iDB/XRex20P6io@public.gmane.org>
> Modulo nits:
>
> Reviewed-by: Moritz Fischer <moritz.fischer-+aYTwkv1SeIAvxtiuMwx3w@public.gmane.org>
>
> > ---
> > drivers/fpga/Kconfig | 6 ++
> > drivers/fpga/Makefile | 1 +
> > drivers/fpga/ice40-spi.c | 213 +++++++++++++++++++++++++++++++++++++++++++++++
> > 3 files changed, 220 insertions(+)
> > create mode 100644 drivers/fpga/ice40-spi.c
> >
> > diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
> > index ce861a2..967cda4 100644
> > --- a/drivers/fpga/Kconfig
> > +++ b/drivers/fpga/Kconfig
> > @@ -20,6 +20,12 @@ config FPGA_REGION
> > FPGA Regions allow loading FPGA images under control of
> > the Device Tree.
> >
> > +config FPGA_MGR_ICE40_SPI
> > + tristate "Lattice iCE40 SPI"
> > + depends on OF && SPI
> > + help
> > + FPGA manager driver support for Lattice iCE40 FPGAs over SPI.
> > +
> > config FPGA_MGR_SOCFPGA
> > tristate "Altera SOCFPGA FPGA Manager"
> > depends on ARCH_SOCFPGA || COMPILE_TEST
> > diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile
> > index 8df07bc..cc0d364 100644
> > --- a/drivers/fpga/Makefile
> > +++ b/drivers/fpga/Makefile
> > @@ -6,6 +6,7 @@
> > obj-$(CONFIG_FPGA) += fpga-mgr.o
> >
> > # FPGA Manager Drivers
> > +obj-$(CONFIG_FPGA_MGR_ICE40_SPI) += ice40-spi.o
> > obj-$(CONFIG_FPGA_MGR_SOCFPGA) += socfpga.o
> > obj-$(CONFIG_FPGA_MGR_SOCFPGA_A10) += socfpga-a10.o
> > obj-$(CONFIG_FPGA_MGR_ZYNQ_FPGA) += zynq-fpga.o
> > diff --git a/drivers/fpga/ice40-spi.c b/drivers/fpga/ice40-spi.c
> > new file mode 100644
> > index 0000000..3c99859
> > --- /dev/null
> > +++ b/drivers/fpga/ice40-spi.c
> > @@ -0,0 +1,213 @@
> > +/*
> > + * FPGA Manager Driver for Lattice iCE40.
> > + *
> > + * Copyright (c) 2016 Joel Holdsworth
> > + *
> > + * 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; version 2 of the License.
> > + *
> > + * This driver adds support to the FPGA manager for configuring the SRAM of
> > + * Lattice iCE40 FPGAs through slave SPI.
> > + */
> > +
> > +#include <linux/fpga/fpga-mgr.h>
> > +#include <linux/gpio/consumer.h>
> > +#include <linux/module.h>
> > +#include <linux/of_gpio.h>
> > +#include <linux/spi/spi.h>
> > +
> > +#define ICE40_SPI_FPGAMGR_RESET_DELAY 1 /* us (>200ns) */
> > +#define ICE40_SPI_FPGAMGR_HOUSEKEEPING_DELAY 1200 /* us */
> > +
> > +#define ICE40_SPI_FPGAMGR_NUM_ACTIVATION_BYTES DIV_ROUND_UP(49, 8)
> > +
> > +struct ice40_fpga_priv {
> > + struct spi_device *dev;
> > + struct gpio_desc *reset;
> > + struct gpio_desc *cdone;
> > +};
> > +
> > +static enum fpga_mgr_states ice40_fpga_ops_state(struct fpga_manager *mgr)
> > +{
> > + struct ice40_fpga_priv *priv = mgr->priv;
> > +
> > + return gpiod_get_value(priv->cdone) ? FPGA_MGR_STATE_OPERATING :
> > + FPGA_MGR_STATE_UNKNOWN;
> > +}
> > +
> > +static int ice40_fpga_ops_write_init(struct fpga_manager *mgr,
> > + struct fpga_image_info *info,
> > + const char *buf, size_t count)
> > +{
> > + struct ice40_fpga_priv *priv = mgr->priv;
> > + struct spi_device *dev = priv->dev;
> > + struct spi_message message;
> > + struct spi_transfer assert_cs_then_reset_delay = {
> > + .cs_change = 1,
> > + .delay_usecs = ICE40_SPI_FPGAMGR_RESET_DELAY
> > + };
> > + struct spi_transfer housekeeping_delay_then_release_cs = {
> > + .delay_usecs = ICE40_SPI_FPGAMGR_HOUSEKEEPING_DELAY
> > + };
> > + int ret;
> > +
> > + if ((info->flags & FPGA_MGR_PARTIAL_RECONFIG)) {
> > + dev_err(&dev->dev,
> > + "Partial reconfiguration is not supported\n");
> > + return -ENOTSUPP;
> > + }
> > +
> > + /* Lock the bus, assert CRESET_B and SS_B and delay >200ns */
> > + spi_bus_lock(dev->master);
> > +
> > + gpiod_set_value(priv->reset, 1);
> > +
> > + spi_message_init(&message);
> > + spi_message_add_tail(&assert_cs_then_reset_delay, &message);
> > + ret = spi_sync_locked(dev, &message);
> > +
> > + /* Come out of reset */
> > + gpiod_set_value(priv->reset, 0);
> > +
> > + /* Abort if the chip-select failed */
> > + if (ret)
> > + goto fail;
> > +
> > + /* Check CDONE is de-asserted i.e. the FPGA is reset */
> > + if (gpiod_get_value(priv->cdone)) {
> > + dev_err(&dev->dev, "Device reset failed, CDONE is asserted\n");
> > + ret = -EIO;
> > + goto fail;
> > + }
> > +
> > + /* Wait for the housekeeping to complete, and release SS_B */
> > + spi_message_init(&message);
> > + spi_message_add_tail(&housekeeping_delay_then_release_cs, &message);
> > + ret = spi_sync_locked(dev, &message);
> > +
> > +fail:
> > + spi_bus_unlock(dev->master);
> > +
> > + return ret;
> > +}
> > +
> > +static int ice40_fpga_ops_write(struct fpga_manager *mgr,
> > + const char *buf, size_t count)
> > +{
> > + struct ice40_fpga_priv *priv = mgr->priv;
> > +
> > + return spi_write(priv->dev, buf, count);
> > +}
> > +
> > +static int ice40_fpga_ops_write_complete(struct fpga_manager *mgr,
> > + struct fpga_image_info *info)
> > +{
> > + struct ice40_fpga_priv *priv = mgr->priv;
> > + struct spi_device *dev = priv->dev;
> > + const u8 padding[ICE40_SPI_FPGAMGR_NUM_ACTIVATION_BYTES] = {0};
> > +
> > + /* Check CDONE is asserted */
> > + if (!gpiod_get_value(priv->cdone)) {
> > + dev_err(&dev->dev,
> > + "CDONE was not asserted after firmware transfer\n");
> > + return -EIO;
> > + }
> > +
> > + /* Send of zero-padding to activate the firmware */
> > + return spi_write(dev, padding, sizeof(padding));
> > +}
> > +
> > +static const struct fpga_manager_ops ice40_fpga_ops = {
> > + .state = ice40_fpga_ops_state,
> > + .write_init = ice40_fpga_ops_write_init,
> > + .write = ice40_fpga_ops_write,
> > + .write_complete = ice40_fpga_ops_write_complete,
> > +};
> > +
> > +static int ice40_fpga_probe(struct spi_device *spi)
> > +{
> > + struct device *dev = &spi->dev;
> > + struct device_node *np = spi->dev.of_node;
> > + struct ice40_fpga_priv *priv;
> > + int ret;
> > +
> > + if (!np) {
> > + dev_err(dev, "No Device Tree entry\n");
> > + return -EINVAL;
> > + }
> > +
> > + priv = devm_kzalloc(&spi->dev, sizeof(*priv), GFP_KERNEL);
> > + if (!priv)
> > + return -ENOMEM;
> > +
> > + priv->dev = spi;
> > +
> > + /* Check board setup data. */
> > + if (spi->max_speed_hz > 25000000) {
> > + dev_err(dev, "Speed is too high\n");
>
> Speed is too high, maximum speed is X. Maybe make it a ICE40_SPI_MAX_SPEED
> > + return -EINVAL;
> > + }
> > +
> > + if (spi->max_speed_hz < 1000000) {
> > + dev_err(dev, "Speed is too low\n");
>
> Speed is too low, minimum speed is X. Maybe make it a ICE40_SPI_MIN_SPEED
> > + return -EINVAL;
> > + }
> > +
> > + if (spi->mode & SPI_CPHA) {
> > + dev_err(dev, "Bad mode\n");
>
> 'Bad mode, SPI_CPHA not supported' mabye.
> > + return -EINVAL;
> > + }
> > +
> > + /* Set up the GPIOs */
> > + priv->cdone = devm_gpiod_get(dev, "cdone", GPIOD_IN);
> > + if (IS_ERR(priv->cdone)) {
> > + dev_err(dev, "Failed to get CDONE GPIO: %ld\n",
> > + PTR_ERR(priv->cdone));
> > + return -EINVAL;
> > + }
> > +
> > + priv->reset = devm_gpiod_get(dev, "reset", GPIOD_OUT_HIGH);
> > + if (IS_ERR(priv->reset)) {
> > + dev_err(dev, "Failed to get CRESET_B GPIO: %ld\n",
> > + PTR_ERR(priv->reset));
> > + return -EINVAL;
> > + }
> > +
> > + /* Register with the FPGA manager */
> > + ret = fpga_mgr_register(dev, "Lattice iCE40 FPGA Manager",
> > + &ice40_fpga_ops, priv);
> > + if (ret) {
> > + dev_err(dev, "Unable to register FPGA manager");
> > + return ret;
> > + }
> > +
> > + return 0;
> > +}
> > +
> > +static int ice40_fpga_remove(struct spi_device *spi)
> > +{
> > + fpga_mgr_unregister(&spi->dev);
> > + return 0;
> > +}
> > +
> > +static const struct of_device_id ice40_fpga_of_match[] = {
> > + { .compatible = "lattice,ice40-fpga-mgr", },
> > + {},
> > +};
> > +MODULE_DEVICE_TABLE(of, ice40_fpga_of_match);
> > +
> > +static struct spi_driver ice40_fpga_driver = {
> > + .probe = ice40_fpga_probe,
> > + .remove = ice40_fpga_remove,
> > + .driver = {
> > + .name = "ice40spi",
> > + .of_match_table = of_match_ptr(ice40_fpga_of_match),
> > + },
> > +};
> > +
> > +module_spi_driver(ice40_fpga_driver);
> > +
> > +MODULE_AUTHOR("Joel Holdsworth <joel-IJEoVVyKhCJXvIrf17iDB/XRex20P6io@public.gmane.org>");
> > +MODULE_DESCRIPTION("Lattice iCE40 FPGA Manager");
> > +MODULE_LICENSE("GPL v2");
> > --
> > 2.7.4
> >
>
> Thanks,
>
> Moritz
>
> PS: can you also Cc linux-fpga mailing list in the future?
>
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 02/11] mfd: axp20x: add volatile and writeable reg ranges for VBUS power supply driver
From: Chen-Yu Tsai @ 2016-12-14 15:43 UTC (permalink / raw)
To: Quentin Schulz
Cc: Sebastian Reichel, Rob Herring, Mark Rutland, Chen-Yu Tsai,
Russell King, Maxime Ripard, Lee Jones, open list:THERMAL,
devicetree, linux-kernel, linux-arm-kernel, Thomas Petazzoni
In-Reply-To: <20161209110419.28981-3-quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
On Fri, Dec 9, 2016 at 7:04 PM, Quentin Schulz
<quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
> The X-Powers AXP20X and AXP22X PMICs allow to choose the maximum voltage
> and minimum current delivered by the VBUS power supply.
>
> This adds the register used by the VBUS power supply driver to the range
> of volatile and writeable regs ranges.
>
> Signed-off-by: Quentin Schulz <quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> ---
>
> added in v2
>
> drivers/mfd/axp20x.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
> index ba130be..6ee2cc6 100644
> --- a/drivers/mfd/axp20x.c
> +++ b/drivers/mfd/axp20x.c
> @@ -65,12 +65,14 @@ static const struct regmap_access_table axp152_volatile_table = {
>
> static const struct regmap_range axp20x_writeable_ranges[] = {
> regmap_reg_range(AXP20X_DATACACHE(0), AXP20X_IRQ5_STATE),
> + regmap_reg_range(AXP20X_VBUS_IPSOUT_MGMT, AXP20X_VBUS_IPSOUT_MGMT),
This is already covered by the previous entry.
> regmap_reg_range(AXP20X_DCDC_MODE, AXP20X_FG_RES),
> regmap_reg_range(AXP20X_RDC_H, AXP20X_OCV(AXP20X_OCV_MAX)),
> };
>
> static const struct regmap_range axp20x_volatile_ranges[] = {
> regmap_reg_range(AXP20X_PWR_INPUT_STATUS, AXP20X_USB_OTG_STATUS),
> + regmap_reg_range(AXP20X_VBUS_IPSOUT_MGMT, AXP20X_VBUS_IPSOUT_MGMT),
And I'm not sure why you specify it as volatile? The PMIC doesn't change any
of the bits in this register on its own.
Same for the AXP22x bits. So basically I think you don't need this patch.
ChenYu
> regmap_reg_range(AXP20X_CHRG_CTRL1, AXP20X_CHRG_CTRL2),
> regmap_reg_range(AXP20X_IRQ1_EN, AXP20X_IRQ5_STATE),
> regmap_reg_range(AXP20X_ACIN_V_ADC_H, AXP20X_IPSOUT_V_HIGH_L),
> @@ -91,11 +93,13 @@ static const struct regmap_access_table axp20x_volatile_table = {
> /* AXP22x ranges are shared with the AXP809, as they cover the same range */
> static const struct regmap_range axp22x_writeable_ranges[] = {
> regmap_reg_range(AXP20X_DATACACHE(0), AXP20X_IRQ5_STATE),
> + regmap_reg_range(AXP20X_VBUS_IPSOUT_MGMT, AXP20X_VBUS_IPSOUT_MGMT),
> regmap_reg_range(AXP20X_DCDC_MODE, AXP22X_BATLOW_THRES1),
> };
>
> static const struct regmap_range axp22x_volatile_ranges[] = {
> regmap_reg_range(AXP20X_PWR_INPUT_STATUS, AXP20X_PWR_OP_MODE),
> + regmap_reg_range(AXP20X_VBUS_IPSOUT_MGMT, AXP20X_VBUS_IPSOUT_MGMT),
> regmap_reg_range(AXP20X_IRQ1_EN, AXP20X_IRQ5_STATE),
> regmap_reg_range(AXP22X_GPIO_STATE, AXP22X_GPIO_STATE),
> regmap_reg_range(AXP20X_FG_RES, AXP20X_FG_RES),
> --
> 2.9.3
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 03/11] power: supply: axp20x_usb_power: set min voltage and max current from sysfs
From: Chen-Yu Tsai @ 2016-12-14 15:45 UTC (permalink / raw)
To: Quentin Schulz
Cc: Sebastian Reichel, Rob Herring, Mark Rutland, Chen-Yu Tsai,
Russell King, Maxime Ripard, Lee Jones, open list:THERMAL,
devicetree, linux-kernel, linux-arm-kernel, Thomas Petazzoni
In-Reply-To: <20161209110419.28981-4-quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
On Fri, Dec 9, 2016 at 7:04 PM, Quentin Schulz
<quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
> AXP20X and AXP22X PMICs allow setting the min voltage and max current of
> VBUS power supply. This adds entries in sysfs to allow to do so.
>
> Signed-off-by: Quentin Schulz <quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Acked-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] ARM: dts: Add missing CPU frequencies for Exynos5422/5800
From: Bartlomiej Zolnierkiewicz @ 2016-12-14 16:10 UTC (permalink / raw)
To: Javier Martinez Canillas
Cc: Arjun K V, Krzysztof Kozlowski, Kukjin Kim, Rob Herring,
Mark Rutland, Russell King, Doug Anderson, Andreas Faerber,
Thomas Abraham, Ben Gamari, linux-samsung-soc, linux-arm-kernel,
linux-pm, devicetree, linux-kernel
In-Reply-To: <ee4321d6-dcc9-4de7-c376-6b169d160322@osg.samsung.com>
Hi,
On Wednesday, December 14, 2016 11:40:08 AM Javier Martinez Canillas wrote:
> Hello Bartlomiej,
>
> On 12/14/2016 11:25 AM, Bartlomiej Zolnierkiewicz wrote:
> >
> > Hi,
> >
> > On Wednesday, December 14, 2016 11:06:45 AM Javier Martinez Canillas wrote:
> >>
> >> Hello Bartlomiej,
> >>
> >> On 12/14/2016 10:28 AM, Bartlomiej Zolnierkiewicz wrote:
> >>>
> >>> On Tuesday, December 13, 2016 04:18:05 PM Javier Martinez Canillas wrote:
> >>>> Hello Bartlomiej,
> >>>
> >>> Hi,
> >>>
> >>>> On 12/13/2016 01:52 PM, Bartlomiej Zolnierkiewicz wrote:
> >>>>> Add missing 2000MHz & 1900MHz OPPs (for A15 cores) and 1400MHz OPP
> >>>>> (for A7 cores). Also update common Odroid-XU3 Lite/XU3/XU4 thermal
> >>>>> cooling maps to account for new OPPs.
> >>>>>
> >>>>> Since new OPPs are not available on all Exynos5422/5800 boards modify
> >>>>> dts files for Odroid-XU3 Lite (limited to 1.8 GHz / 1.3 GHz) & Peach
> >>>>> Pi (limited to 2.0 GHz / 1.3 GHz) accordingly.
> >>>>>
> >>>>> Tested on Odroid-XU3 and XU3 Lite.
> >>>>>
> >>>>> Cc: Doug Anderson <dianders@chromium.org>
> >>>>> Cc: Javier Martinez Canillas <javier@osg.samsung.com>
> >>>>> Cc: Andreas Faerber <afaerber@suse.de>
> >>>>> Cc: Thomas Abraham <thomas.ab@samsung.com>
> >>>>> Cc: Ben Gamari <ben@smart-cactus.org>
> >>>>> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
> >>>>> ---
> >>>>> arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 14 +++++++-------
> >>>>> arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts | 17 +++++++++++++++++
> >>>>> arch/arm/boot/dts/exynos5800-peach-pi.dts | 4 ++++
> >>>>> arch/arm/boot/dts/exynos5800.dtsi | 15 +++++++++++++++
> >>>>> 4 files changed, 43 insertions(+), 7 deletions(-)
> >>>>>
> >>>>> Index: b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
> >>>>> ===================================================================
> >>>>> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi 2016-12-13 15:59:33.779763261 +0100
> >>>>> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi 2016-12-13 15:59:33.775763261 +0100
> >>>>> @@ -118,7 +118,7 @@
> >>>>> /*
> >>>>> * When reaching cpu_alert3, reduce CPU
> >>>>> * by 2 steps. On Exynos5422/5800 that would
> >>>>> - * be: 1600 MHz and 1100 MHz.
> >>>>> + * (usually) be: 1800 MHz and 1200 MHz.
> >>>>> */
> >>>>> map3 {
> >>>>> trip = <&cpu_alert3>;
> >>>>> @@ -131,16 +131,16 @@
> >>>>>
> >>>>> /*
> >>>>> * When reaching cpu_alert4, reduce CPU
> >>>>> - * further, down to 600 MHz (11 steps for big,
> >>>>> - * 7 steps for LITTLE).
> >>>>> + * further, down to 600 MHz (13 steps for big,
> >>>>> + * 8 steps for LITTLE).
> >>>>> */
> >>>>> - map5 {
> >>>>> + cooling_map5: map5 {
> >>>>> trip = <&cpu_alert4>;
> >>>>> - cooling-device = <&cpu0 3 7>;
> >>>>> + cooling-device = <&cpu0 3 8>;
> >>>>> };
> >>>>> - map6 {
> >>>>> + cooling_map6: map6 {
> >>>>> trip = <&cpu_alert4>;
> >>>>> - cooling-device = <&cpu4 3 11>;
> >>>>> + cooling-device = <&cpu4 3 13>;
> >>>>> };
> >>>>> };
> >>>>> };
> >>>>> Index: b/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts
> >>>>> ===================================================================
> >>>>> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts 2016-12-13 15:59:33.779763261 +0100
> >>>>> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts 2016-12-13 15:59:33.775763261 +0100
> >>>>> @@ -21,6 +21,23 @@
> >>>>> compatible = "hardkernel,odroid-xu3-lite", "samsung,exynos5800", "samsung,exynos5";
> >>>>> };
> >>>>>
> >>>>> +&cluster_a15_opp_table {
> >>>>> + /delete-node/opp@2000000000;
> >>>>> + /delete-node/opp@1900000000;
> >>>>> +};
> >>>>> +
> >>>>> +&cluster_a7_opp_table {
> >>>>> + /delete-node/opp@1400000000;
> >>>>> +};
> >>>>> +
> >>>>
> >>>> I think that a comment in the DTS why these operating points aren't available
> >>>> in this board will make more clear why the nodes are being deleted.
> >>>
> >>> Ok, I will add these comments in the next patch revision.
> >>>
> >>>>> +&cooling_map5 {
> >>>>> + cooling-device = <&cpu0 3 7>;
> >>>>> +};
> >>>>> +
> >>>>> +&cooling_map6 {
> >>>>> + cooling-device = <&cpu4 3 11>;
> >>>>> +};
> >>>>> +
> >>>>> &pwm {
> >>>>> /*
> >>>>> * PWM 0 -- fan
> >>>>> Index: b/arch/arm/boot/dts/exynos5800-peach-pi.dts
> >>>>> ===================================================================
> >>>>> --- a/arch/arm/boot/dts/exynos5800-peach-pi.dts 2016-12-13 15:59:33.779763261 +0100
> >>>>> +++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts 2016-12-13 15:59:33.779763261 +0100
> >>>>> @@ -146,6 +146,10 @@
> >>>>> vdd-supply = <&ldo9_reg>;
> >>>>> };
> >>>>>
> >>>>> +&cluster_a7_opp_table {
> >>>>> + /delete-property/opp@1400000000;
> >>>>> +};
> >>>>> +
> >>>>> &cpu0 {
> >>>>> cpu-supply = <&buck2_reg>;
> >>>>> };
> >>>>> Index: b/arch/arm/boot/dts/exynos5800.dtsi
> >>>>> ===================================================================
> >>>>> --- a/arch/arm/boot/dts/exynos5800.dtsi 2016-12-13 15:59:33.779763261 +0100
> >>>>> +++ b/arch/arm/boot/dts/exynos5800.dtsi 2016-12-13 15:59:33.779763261 +0100
> >>>>> @@ -24,6 +24,16 @@
> >>>>> };
> >>>>>
> >>>>> &cluster_a15_opp_table {
> >>>>> + opp@2000000000 {
> >>>>> + opp-hz = /bits/ 64 <2000000000>;
> >>>>> + opp-microvolt = <1250000>;
> >>>>> + clock-latency-ns = <140000>;
> >>>>> + };
> >>>>> + opp@1900000000 {
> >>>>> + opp-hz = /bits/ 64 <1900000000>;
> >>>>> + opp-microvolt = <1250000>;
> >>>>> + clock-latency-ns = <140000>;
> >>>>> + };
> >>>>> opp@1700000000 {
> >>>>> opp-microvolt = <1250000>;
> >>>>> };
> >>>>> @@ -85,6 +95,11 @@
> >>>>> };
> >>>>>
> >>>>
> >>>> AFAIK Thomas restricted the maximum OPP, because for A15 freqs > 1.8GHz the
> >>>> INT rail would need to be scaled up as well since there's a maximum voltage
> >>>> difference between the ARM and INT rails before the system becomes unstable:
> >>>>
> >>>> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-July/276766.html
> >>>> https://lkml.org/lkml/2014/5/2/419
> >>>>
> >>>> The ChromiumOS vendor tree uses a virtual regulator driver that makes sure
> >>>> the maximum voltage skew is between a limit. But that never made to mainline:
> >>>>
> >>>> https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.8/arch/arm/boot/dts/exynos5420-peach-pit.dtsi#90
> >>>> https://lkml.org/lkml/2014/4/29/28
> >>>>
> >>>> Did that change and there's infrastructure in mainline now to cope with that?
> >>>> If that's the case, I think it would be good to mention in the commit message.
> >>>
> >>> I was not aware of this limitation and AFAIK mainline has currently
> >>> no code to handle it. I also cannot find any code to handle this in
> >>
> >> Yes, that's what I thought as well but maybe I was missing something.
> >>
> >>> Hardkernel's vendor kernel for Odroid-XU3 board.
> >>>
> >>> Do you know whether this problem exists also on Exynos5422/5800
> >>> SoCs or only on Exynos5420 one? I see that ChromiumOS uses virtual
> >>> regulator code also on Exynos5800 SoC based Peach Pi board but was
> >>> the problem actually present on this board?
> >>>
> >>
> >> My understanding is that this problem is present in 5420/5422/5800
> >> but I have no way to confirm this. I'm just guessing from the info
> >> in the ChromiumOS vendor tree.
> >>
> >> If you look at the commit that added the regulator-locker driver,
> >> the test says to be done in a Peach Pi so it seems the problem is
> >> not restricted to only Exynos5420:
> >>
> >> https://chromium.googlesource.com/chromiumos/third_party/kernel/+/ba63620feace4eaed5572ac2e77d8d61754af704
> >>
> >>> [ I added Arjun to Cc:, maybe he can help in explaining this issue
> >>> (unfortunately Inderpal's email is no longer working). ]
> >>>
> >>
> >> Added Abhilash to cc list as well since he was involved in the Exynos ChromeOS tree.
> >
> > Abhilash's email is also no longer valid.. :(
> >
>
> Yes, I noticed that as well :(
>
> >>> Please also note that on Exynos5422/5800 SoCs the same ARM rail
> >>> voltage is used for 1.9 GHz & 2.0 GHz OPPs as for the 1.8 GHz one.
> >>> IOW if the problem exists it is already present in the mainline
> >>> kernel.
> >>>
> >>
> >> Ah, I only looked at your patch and I didn't compare the voltage levels
> >> in your 1.9 GHz and 2.0 GHz OPPs with the current 1.8 GHz in mainline.
> >>
> >> I wonder if the voltage levels in your patch are correct then, since the
> >> ChromiumOS tree uses a higher voltages for the 1.9 GHz and 2.0 GHz OPPs:
> >>
> >> /*
> >> * Default ASV table
> >> */
> >> static const unsigned int asv_voltage_5420[CPUFREQ_NUM_LEVELS] = {
> >> 1362500, /* L0 2100 */
> >> 1312500, /* L1 2000 */
> >> 1275000, /* L2 1900 */
> >> 1225000, /* L3 1800 */
> >> 1200000, /* L4 1700 */
> >>
> >> This is from https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.8/drivers/cpufreq/exynos5420-cpufreq.c#175
> >
> > I think that the above voltages are original ones for Exynos5420
> > (not for Exynos5422/5800).
> >
>
> In the ChromiumOS tree, the same CPUFreq driver is used for both the Peach
> Pit (Exynos5420) and Peach Pi (Exynos5800) Chromebooks.
This seems suboptimal (or maybe even incorrect as Exynos5422/5800
SoCs also use different clock divider values for clocks related to
CPU clock than Exynos5420 SoC).
Anyway, I can drop Peach Pi support from my patch for now if you want.
> > The voltages in my patch were taken from Hardkernel's kernel for
> > Odroid-XU3:
> >
> > /*
> > * ASV group voltage table
> > */
> > static const unsigned int asv_voltage_5422_CA15[CPUFREQ_LEVEL_END_CA15] = {
> > ...
> > 1250000, /* L4 2000 */
> > 1250000, /* L5 1900 */
> > 1250000, /* L6 1800 */
> > ...
> >
> > https://github.com/hardkernel/linux/blob/odroidxu3-3.10.y-android/drivers/cpufreq/exynos5422-eagle-cpufreq.c#L314
> >
>
> In general I prefer to use the ChromiumOS tree as a reference instead of the
> HardKernel one, since the former is in a much better shape IMHO.
I generally agree, OTOH Hardkernel's tree is based on Samsung's
vendor trees and additionally it contains all low-level hardware
details for Odroid-XU3 board (not present in ChromiumOS tree).
> I think is worth to check in a kernel tree in http://opensource.samsung.com/
> for a product that's Exynos5422/5800 based.
I've just checked kernel from SM-G900H_LL_Opensource.zip (for Galaxy
S5 which is Exynos5422 based) and it uses 50mV lower voltages for
1.6 GHz - 2.0 GHz OPPs, for the lower frequencies OPPs voltages are
identical to the ones used by HardKernel's tree,
drivers/cpufreq/exynos5422-eagle-cpufreq.c:
/*
* ASV group voltage table
*/
static const unsigned int asv_voltage_5422_CA15[CPUFREQ_LEVEL_END_CA15] = {
...
1200000, /* L4 2000 */
1200000, /* L5 1900 */
1200000, /* L6 1800 */
1200000, /* L7 1700 */
1200000, /* L8 1600 */
1100000, /* L9 1500 */
1100000, /* L10 1400 */
1100000, /* L11 1300 */
1000000, /* L12 1200 */
1000000, /* L13 1100 */
1000000, /* L14 1000 */
1000000, /* L15 900 */
900000, /* L16 800 */
900000, /* L17 700 */
900000, /* L18 600 */
900000, /* L19 500 */
900000, /* L20 400 */
900000, /* L22 300 */
900000, /* L22 200 */
};
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
^ permalink raw reply
* Re: [PATCH v2 04/11] Documentation: DT: binding: axp20x_usb_power: add axp223 compatible
From: Chen-Yu Tsai @ 2016-12-14 16:12 UTC (permalink / raw)
To: Quentin Schulz
Cc: Mark Rutland, devicetree, open list:THERMAL, linux-kernel,
Sebastian Reichel, Russell King, Chen-Yu Tsai, Rob Herring,
Maxime Ripard, Lee Jones, Thomas Petazzoni, linux-arm-kernel
In-Reply-To: <20161209110419.28981-5-quentin.schulz@free-electrons.com>
On Fri, Dec 9, 2016 at 7:04 PM, Quentin Schulz
<quentin.schulz@free-electrons.com> wrote:
> This adds the "x-powers,axp223-usb-power-supply" to the list of
> compatibles for AXP20X VBUS power supply driver.
>
> Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
> ---
>
> v2:
> - adding small explanation on AXP223 variation compared to the AXP221,
>
> Documentation/devicetree/bindings/power/supply/axp20x_usb_power.txt | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/power/supply/axp20x_usb_power.txt b/Documentation/devicetree/bindings/power/supply/axp20x_usb_power.txt
> index f1d7bee..ba8d35f 100644
> --- a/Documentation/devicetree/bindings/power/supply/axp20x_usb_power.txt
> +++ b/Documentation/devicetree/bindings/power/supply/axp20x_usb_power.txt
> @@ -3,6 +3,11 @@ AXP20x USB power supply
> Required Properties:
> -compatible: One of: "x-powers,axp202-usb-power-supply"
> "x-powers,axp221-usb-power-supply"
> + "x-powers,axp223-usb-power-supply"
> +
> +The AXP223 PMIC shares most of its behaviour with the AXP221 but has slight
> +variations such as the former being able to set the VBUS power supply max
> +current to 100mA, unlike the latter.
I actually wanted this in the commit log, but this works too.
Acked-by: Chen-Yu Tsai <wens@csie.org>
>
> This node is a subnode of the axp20x PMIC.
>
> --
> 2.9.3
>
^ permalink raw reply
* [PATCH v3 0/2] iio: adc: hx711: Add IIO driver for AVIA HX711 ADC
From: Andreas Klinger @ 2016-12-14 16:16 UTC (permalink / raw)
To: devicetree, linux-iio
Cc: linux-kernel, robh+dt, pawel.moll, mark.rutland, ijc+devicetree,
galak, jic23, knaack.h, lars, pmeerw, ak
This series adds IIO driver support for the AVIA HX711 ADC which is
mostly used in weighting cells.
The first patch adds the new DT binding for which a new vendor avia
was also added.
The second patch is the simple IIO driver implemented as ADC.
The protocol is specific to this device and implemented using GPIO's.
Documentation of the chip can be found here:
https://cdn.sparkfun.com/datasheets/Sensors/ForceFlex/hx711_english.pdf
Changes in v3:
moved gain from devicetree to sysfs, according to comment of Lars-Peter
Thanks for reviewing and giving suggestions
* Patch 1: "iio: adc: hx711: Add DT binding for avia,hx711"
- removed property gain
* Patch 2: "iio: adc: hx711: Add IIO driver for AVIA HX711"
- removed property gain from devicetree
- added device attribute (rw) for gain
- support reading from both channels now
Changes in v2:
Lots of updates thanks to Peters review.
* Patch 1: "iio: adc: hx711: Add DT binding for avia,hx711"
- typo
- removed unneded section
* Patch 2: "iio: adc: hx711: Add IIO driver for AVIA HX711"
- updated help text in Kconfig
- removed dead code
- removed unused power management
- reduced channel spec to what is actually used
- added error handling in case reset of chip not possible
Andreas Klinger (2):
iio: adc: hx711: Add DT binding for avia,hx711
iio: adc: hx711: Add IIO driver for AVIA HX711
.../devicetree/bindings/iio/adc/avia-hx711.txt | 16 ++
.../devicetree/bindings/vendor-prefixes.txt | 1 +
drivers/iio/adc/Kconfig | 18 ++
drivers/iio/adc/Makefile | 1 +
drivers/iio/adc/hx711.c | 292 +++++++++++++++++++++
5 files changed, 328 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iio/adc/avia-hx711.txt
create mode 100644 drivers/iio/adc/hx711.c
--
2.1.4
^ permalink raw reply
* [PATCH v3 1/2] iio: adc: hx711: Add DT binding for avia,hx711
From: Andreas Klinger @ 2016-12-14 16:16 UTC (permalink / raw)
To: devicetree, linux-iio
Cc: linux-kernel, robh+dt, pawel.moll, mark.rutland, ijc+devicetree,
galak, jic23, knaack.h, lars, pmeerw, ak
Add DT bindings for avia,hx711
Add vendor avia to vendor list
Signed-off-by: Andreas Klinger <ak@it-klinger.de>
---
Documentation/devicetree/bindings/iio/adc/avia-hx711.txt | 16 ++++++++++++++++
Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
2 files changed, 17 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iio/adc/avia-hx711.txt
diff --git a/Documentation/devicetree/bindings/iio/adc/avia-hx711.txt b/Documentation/devicetree/bindings/iio/adc/avia-hx711.txt
new file mode 100644
index 000000000000..27300b186cf4
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/avia-hx711.txt
@@ -0,0 +1,16 @@
+* AVIA HX711 ADC chip for weight cells
+ Bit-banging driver
+
+Required properties:
+ - compatible: Should be "avia,hx711"
+ - sck-gpios: Definition of the GPIO for the clock
+ - dout-gpios: Definition of the GPIO for data-out
+ See Documentation/devicetree/bindings/gpio/gpio.txt
+
+Example:
+weight@0 {
+ compatible = "avia,hx711";
+ sck-gpios = <&gpio3 10 GPIO_ACTIVE_HIGH>;
+ dout-gpios = <&gpio0 7 GPIO_ACTIVE_HIGH>;
+};
+
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 44ddc980b085..4696bb5c2198 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -32,6 +32,7 @@ atlas Atlas Scientific LLC
atmel Atmel Corporation
auo AU Optronics Corporation
avago Avago Technologies
+avia avia semiconductor
avic Shanghai AVIC Optoelectronics Co., Ltd.
axis Axis Communications AB
boe BOE Technology Group Co., Ltd.
--
2.1.4
^ permalink raw reply related
* [PATCH v3 2/2] iio: adc: hx711: Add IIO driver for AVIA HX711
From: Andreas Klinger @ 2016-12-14 16:17 UTC (permalink / raw)
To: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-iio-u79uwXL29TY76Z2rM5mHXA
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, pawel.moll-5wv7dgnIgG8,
mark.rutland-5wv7dgnIgG8, ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg,
galak-sgV2jX0FEOL9JmXXK+q4OQ, jic23-DgEjT+Ai2ygdnm+yROfE0A,
knaack.h-Mmb7MZpHnFY, lars-Qo5EllUWu/uELgA04lAiVw,
pmeerw-jW+XmwGofnusTnJN9+BGXg, ak-n176/SwNRljddJNmlsFzeA
This is the IIO driver for AVIA HX711 ADC which ist mostly used in weighting
cells.
The protocol is quite simple and using GPIOs:
One GPIO is used as clock (SCK) while another GPIO is read (DOUT)
The raw value read from the chip is delivered.
To get a weight one needs to subtract the zero offset and scale it.
Signed-off-by: Andreas Klinger <ak-n176/SwNRljddJNmlsFzeA@public.gmane.org>
---
drivers/iio/adc/Kconfig | 18 +++
drivers/iio/adc/Makefile | 1 +
drivers/iio/adc/hx711.c | 292 +++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 311 insertions(+)
create mode 100644 drivers/iio/adc/hx711.c
diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index 932de1f9d1e7..918f582288c9 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -205,6 +205,24 @@ config HI8435
This driver can also be built as a module. If so, the module will be
called hi8435.
+config HX711
+ tristate "AVIA HX711 ADC for weight cells"
+ depends on GPIOLIB
+ help
+ If you say yes here you get support for AVIA HX711 ADC which is used
+ for weight cells
+
+ This driver uses two GPIOs, one for setting the clock and the other
+ one for getting the data
+
+ Currently the raw value is read from the chip and delivered.
+ For getting an actual weight one needs to subtract the
+ zero offset and multiply by a scale factor.
+ This should be done in userspace.
+
+ This driver can also be built as a module. If so, the module will be
+ called hx711.
+
config INA2XX_ADC
tristate "Texas Instruments INA2xx Power Monitors IIO driver"
depends on I2C && !SENSORS_INA2XX
diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
index b1aa456e6af3..d46e289900ef 100644
--- a/drivers/iio/adc/Makefile
+++ b/drivers/iio/adc/Makefile
@@ -21,6 +21,7 @@ obj-$(CONFIG_CC10001_ADC) += cc10001_adc.o
obj-$(CONFIG_DA9150_GPADC) += da9150-gpadc.o
obj-$(CONFIG_EXYNOS_ADC) += exynos_adc.o
obj-$(CONFIG_HI8435) += hi8435.o
+obj-$(CONFIG_HX711) += hx711.o
obj-$(CONFIG_IMX7D_ADC) += imx7d_adc.o
obj-$(CONFIG_INA2XX_ADC) += ina2xx-adc.o
obj-$(CONFIG_LP8788_ADC) += lp8788_adc.o
diff --git a/drivers/iio/adc/hx711.c b/drivers/iio/adc/hx711.c
new file mode 100644
index 000000000000..700281932ff0
--- /dev/null
+++ b/drivers/iio/adc/hx711.c
@@ -0,0 +1,292 @@
+/*
+ * HX711: analog to digital converter for weight sensor module
+ *
+ * Copyright (c) 2016 Andreas Klinger <ak-n176/SwNRljddJNmlsFzeA@public.gmane.org>
+ *
+ * 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 <linux/err.h>
+#include <linux/gpio.h>
+#include <linux/gpio/consumer.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/property.h>
+#include <linux/slab.h>
+#include <linux/sched.h>
+#include <linux/delay.h>
+#include <linux/iio/iio.h>
+#include <linux/iio/sysfs.h>
+
+#define HX711_GAIN_32 2 /* gain = 32 for channel B */
+#define HX711_GAIN_64 3 /* gain = 64 for channel A */
+#define HX711_GAIN_128 1 /* gain = 128 for channel A */
+
+struct hx711_data {
+ struct device *dev;
+ struct gpio_desc *gpiod_sck;
+ struct gpio_desc *gpiod_dout;
+ int gain_pulse;
+ struct mutex lock;
+};
+
+static int hx711_reset(struct hx711_data *hx711_data)
+{
+ int i, val;
+
+ val = gpiod_get_value(hx711_data->gpiod_dout);
+ if (val) {
+ gpiod_set_value(hx711_data->gpiod_sck, 1);
+ udelay(80);
+ gpiod_set_value(hx711_data->gpiod_sck, 0);
+
+ for (i = 0; i < 1000; i++) {
+ val = gpiod_get_value(hx711_data->gpiod_dout);
+ if (!val)
+ break;
+ /* sleep at least 1 ms */
+ msleep(1);
+ }
+ }
+
+ return val;
+}
+
+static int hx711_cycle(struct hx711_data *hx711_data)
+{
+ int val;
+
+ /* if preempted for more then 60us while SCK is high:
+ * hx711 is going in reset
+ * ==> measuring is false
+ */
+ preempt_disable();
+ gpiod_set_value(hx711_data->gpiod_sck, 1);
+ val = gpiod_get_value(hx711_data->gpiod_dout);
+ gpiod_set_value(hx711_data->gpiod_sck, 0);
+ preempt_enable();
+
+ return val;
+}
+
+static int hx711_read(struct hx711_data *hx711_data)
+{
+ int i, ret;
+ int value = 0;
+
+ mutex_lock(&hx711_data->lock);
+
+ if (hx711_reset(hx711_data)) {
+ dev_err(hx711_data->dev, "reset failed!");
+ mutex_unlock(&hx711_data->lock);
+ return -1;
+ }
+
+ for (i = 0; i < 24; i++) {
+ value <<= 1;
+ ret = hx711_cycle(hx711_data);
+ if (ret)
+ value++;
+ }
+
+ value ^= 0x800000;
+
+ for (i = 0; i < hx711_data->gain_pulse; i++)
+ ret = hx711_cycle(hx711_data);
+
+ mutex_unlock(&hx711_data->lock);
+
+ return value;
+}
+
+static int hx711_read_raw(struct iio_dev *iio_dev,
+ const struct iio_chan_spec *chan,
+ int *val, int *val2, long mask)
+{
+ struct hx711_data *hx711_data = iio_priv(iio_dev);
+
+ switch (mask) {
+ case IIO_CHAN_INFO_RAW:
+ switch (chan->type) {
+ case IIO_VOLTAGE:
+ *val = hx711_read(hx711_data);
+ return IIO_VAL_INT;
+ default:
+ return -EINVAL;
+ }
+ default:
+ return -EINVAL;
+ }
+}
+
+static ssize_t hx711_gain_show(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+ struct hx711_data *hx711_data = iio_priv(dev_to_iio_dev(dev));
+ int val;
+
+ switch (hx711_data->gain_pulse) {
+ case HX711_GAIN_32:
+ val = 32;
+ break;
+ case HX711_GAIN_64:
+ val = 64;
+ break;
+ default:
+ val = 128;
+ }
+
+ return sprintf(buf, "%d\n", val);
+}
+
+static ssize_t hx711_gain_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t len)
+{
+ struct hx711_data *hx711_data = iio_priv(dev_to_iio_dev(dev));
+ int ret, val;
+ int gain_save = hx711_data->gain_pulse;
+
+ ret = kstrtoint((const char *) buf, 10, &val);
+ if (ret)
+ return -EINVAL;
+
+ switch (val) {
+ case 32:
+ hx711_data->gain_pulse = HX711_GAIN_32;
+ break;
+ case 64:
+ hx711_data->gain_pulse = HX711_GAIN_64;
+ break;
+ case 128:
+ hx711_data->gain_pulse = HX711_GAIN_128;
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ dev_dbg(hx711_data->dev, "gain_pulse: %d\n", hx711_data->gain_pulse);
+
+ /* if gain has changed do a fake read for the new gain to be set
+ * for the next read
+ */
+ if (gain_save != hx711_data->gain_pulse)
+ hx711_read(hx711_data);
+
+ return len;
+}
+
+static IIO_DEVICE_ATTR(gain, S_IRUGO | S_IWUSR,
+ hx711_gain_show, hx711_gain_store, 0);
+
+static struct attribute *hx711_attributes[] = {
+ &iio_dev_attr_gain.dev_attr.attr,
+ NULL,
+};
+
+static struct attribute_group hx711_attribute_group = {
+ .attrs = hx711_attributes,
+};
+
+static const struct iio_info hx711_iio_info = {
+ .driver_module = THIS_MODULE,
+ .read_raw = hx711_read_raw,
+ .attrs = &hx711_attribute_group,
+};
+
+static const struct iio_chan_spec hx711_chan_spec[] = {
+ { .type = IIO_VOLTAGE,
+ .info_mask_separate =
+ BIT(IIO_CHAN_INFO_RAW),
+ },
+};
+
+static int hx711_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct hx711_data *hx711_data = NULL;
+ struct iio_dev *iio;
+ int ret = 0;
+
+ iio = devm_iio_device_alloc(dev, sizeof(struct hx711_data));
+ if (!iio) {
+ dev_err(dev, "failed to allocate IIO device\n");
+ return -ENOMEM;
+ }
+
+ hx711_data = iio_priv(iio);
+ hx711_data->dev = dev;
+
+ mutex_init(&hx711_data->lock);
+
+ hx711_data->gpiod_sck = devm_gpiod_get(dev, "sck", GPIOD_OUT_HIGH);
+ if (IS_ERR(hx711_data->gpiod_sck)) {
+ dev_err(dev, "failed to get sck-gpiod: err=%ld\n",
+ PTR_ERR(hx711_data->gpiod_sck));
+ return PTR_ERR(hx711_data->gpiod_sck);
+ }
+
+ hx711_data->gpiod_dout = devm_gpiod_get(dev, "dout", GPIOD_OUT_HIGH);
+ if (IS_ERR(hx711_data->gpiod_dout)) {
+ dev_err(dev, "failed to get dout-gpiod: err=%ld\n",
+ PTR_ERR(hx711_data->gpiod_dout));
+ return PTR_ERR(hx711_data->gpiod_dout);
+ }
+
+ ret = gpiod_direction_input(hx711_data->gpiod_dout);
+ if (ret < 0) {
+ dev_err(hx711_data->dev, "gpiod_direction_input: %d\n", ret);
+ return ret;
+ }
+
+ ret = gpiod_direction_output(hx711_data->gpiod_sck, 0);
+ if (ret < 0) {
+ dev_err(hx711_data->dev, "gpiod_direction_output: %d\n", ret);
+ return ret;
+ }
+
+ platform_set_drvdata(pdev, iio);
+
+ iio->name = pdev->name;
+ iio->dev.parent = &pdev->dev;
+ iio->info = &hx711_iio_info;
+ iio->modes = INDIO_DIRECT_MODE;
+ iio->channels = hx711_chan_spec;
+ iio->num_channels = ARRAY_SIZE(hx711_chan_spec);
+
+ return devm_iio_device_register(dev, iio);
+}
+
+static const struct of_device_id of_hx711_match[] = {
+ { .compatible = "avia,hx711", },
+ {},
+};
+
+MODULE_DEVICE_TABLE(of, of_hx711_match);
+
+static struct platform_driver hx711_driver = {
+ .probe = hx711_probe,
+ .driver = {
+ .name = "hx711-gpio",
+ .of_match_table = of_hx711_match,
+ },
+};
+
+module_platform_driver(hx711_driver);
+
+MODULE_AUTHOR("Andreas Klinger <ak-n176/SwNRljddJNmlsFzeA@public.gmane.org>");
+MODULE_DESCRIPTION("HX711 bitbanging driver - ADC for weight cells");
+MODULE_LICENSE("GPL");
+MODULE_ALIAS("platform:hx711-gpio");
+
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* RE: clk: clk-mstp has never worked for RZ/A1
From: Chris Brandt @ 2016-12-14 16:22 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: linux-renesas-soc@vger.kernel.org, geert+renesas@glider.be,
devicetree@vger.kernel.org
In-Reply-To: <CAMuHMdUJFSbX96pqY2Ogxztxz-SWCNfbe=d3eWKn+eWSdHLwfw@mail.gmail.com>
Hi Geert,
On Dec 14, 2016, Geert Uytterhoeven wrote:
> Another option is to let the driver bind against "renesas,r7s72100-mstp-
> clocks", and switch to 8-bit access mode.
>
> CLK_OF_DECLARE(cpg_mstp_clks, "renesas,r7s72100-mstp-clocks",
> cpg_mstp_clocks_init8);
>
> cpg_mstp_clocks_init8() can set a gloal flag, and call
> cpg_mstp_clocks_init().
>
> The latter means no DT update is needed, and thus preserves compatibility
> with old DTBs.
I just coded that and it works good. Thank you.
Now, one more question before I submit a patch for review:
I would like to add a "Fixes:" to the commit log so it can be considered for 4.9-stable (in reality it could go all the way back to when r7s72100 support was added)
But, the current file path didn't exist until after commit b3a33077c0dd ("clk: renesas: move drivers to renesas directory") on 2016-03-02.
So should I use that commit for my 'Fixes'?
Thanks,
Chris
^ permalink raw reply
* Re: [PATCH] MIPS: NI 169445 board support
From: Nathan Sullivan @ 2016-12-14 16:32 UTC (permalink / raw)
To: Rob Herring
Cc: ralf-6z/3iImG2C8G8FEW9MqTrA, mark.rutland-5wv7dgnIgG8,
linux-mips-6z/3iImG2C8G8FEW9MqTrA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161209211828.dykl2l4kmthqgq6e@rob-hp-laptop>
On Fri, Dec 09, 2016 at 03:18:28PM -0600, Rob Herring wrote:
> On Fri, Dec 02, 2016 at 09:42:09AM -0600, Nathan Sullivan wrote:
> > Support the National Instruments 169445 board.
> >
> > Signed-off-by: Nathan Sullivan <nathan.sullivan-acOepvfBmUk@public.gmane.org>
> > ---
> > "gpio: mmio: add support for NI 169445 NAND GPIO" and
> > "devicetree: add vendor prefix for National Instruments" are required for the
> > NAND on this board to work.
>
> These should have been a series, but I already applied the first one.
>
> >
> > Documentation/devicetree/bindings/mips/ni.txt | 7 ++
> > arch/mips/Kbuild.platforms | 1 +
> > arch/mips/Kconfig | 26 ++++++
> > arch/mips/boot/dts/Makefile | 1 +
> > arch/mips/boot/dts/ni/169445.dts | 99 +++++++++++++++++++++
> > arch/mips/boot/dts/ni/Makefile | 9 ++
> > arch/mips/configs/ni169445_defconfig | 120 ++++++++++++++++++++++++++
> > arch/mips/ni169445/169445-console.c | 38 ++++++++
> > arch/mips/ni169445/169445-init.c | 39 +++++++++
> > arch/mips/ni169445/169445-int.c | 34 ++++++++
> > arch/mips/ni169445/169445-setup.c | 58 +++++++++++++
> > arch/mips/ni169445/169445-time.c | 35 ++++++++
> > arch/mips/ni169445/Makefile | 9 ++
> > arch/mips/ni169445/Platform | 6 ++
> > 14 files changed, 482 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/mips/ni.txt
> > create mode 100644 arch/mips/boot/dts/ni/169445.dts
> > create mode 100644 arch/mips/boot/dts/ni/Makefile
> > create mode 100644 arch/mips/configs/ni169445_defconfig
> > create mode 100644 arch/mips/ni169445/169445-console.c
> > create mode 100644 arch/mips/ni169445/169445-init.c
> > create mode 100644 arch/mips/ni169445/169445-int.c
> > create mode 100644 arch/mips/ni169445/169445-setup.c
> > create mode 100644 arch/mips/ni169445/169445-time.c
> > create mode 100644 arch/mips/ni169445/Makefile
> > create mode 100644 arch/mips/ni169445/Platform
> >
> > diff --git a/Documentation/devicetree/bindings/mips/ni.txt b/Documentation/devicetree/bindings/mips/ni.txt
> > new file mode 100644
> > index 0000000..722bf2d
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/mips/ni.txt
> > @@ -0,0 +1,7 @@
> > +National Instruments MIPS platforms
> > +
> > +required root node properties:
> > + - compatible: must be "ni,169445"
> > +
> > +CPU Nodes
> > + - compatible: must be "mti,mips14KEc"
> > diff --git a/arch/mips/Kbuild.platforms b/arch/mips/Kbuild.platforms
> > index f5f1bdb..f2d7b5c 100644
> > --- a/arch/mips/Kbuild.platforms
> > +++ b/arch/mips/Kbuild.platforms
> > @@ -20,6 +20,7 @@ platforms += loongson32
> > platforms += loongson64
> > platforms += mti-malta
> > platforms += netlogic
> > +platforms += ni169445
> > platforms += paravirt
> > platforms += pic32
> > platforms += pistachio
> > diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
> > index b3c5bde..d24d11f 100644
> > --- a/arch/mips/Kconfig
> > +++ b/arch/mips/Kconfig
> > @@ -574,6 +574,32 @@ config NXP_STB225
> > help
> > Support for NXP Semiconductors STB225 Development Board.
> >
> > +config NI_169445
> > + bool "NI 169445 board"
> > + select ARCH_WANT_OPTIONAL_GPIOLIB
> > + select BOOT_ELF32
> > + select BOOT_RAW
> > + select BUILTIN_DTB
> > + select CEVT_R4K
> > + select CSRC_R4K
> > + select CPU_MIPSR2_IRQ_VI
> > + select CPU_MIPSR2_IRQ_EI
> > + select DMA_NONCOHERENT
> > + select IRQ_MIPS_CPU
> > + select LIBFDT
> > + select MIPS_MSC
> > + select SYS_HAS_CPU_MIPS32_R1
> > + select SYS_HAS_CPU_MIPS32_R2
> > + select SYS_HAS_EARLY_PRINTK
> > + select SYS_SUPPORTS_32BIT_KERNEL
> > + select SYS_SUPPORTS_LITTLE_ENDIAN
> > + select USE_OF
> > + select COMMON_CLK
> > + help
> > + This enables support for the National Instruments 169445A
> > + board.
> > +
> > +
> > config PMC_MSP
> > bool "PMC-Sierra MSP chipsets"
> > select CEVT_R4K
> > diff --git a/arch/mips/boot/dts/Makefile b/arch/mips/boot/dts/Makefile
> > index fc7a0a9..65a0ad8 100644
> > --- a/arch/mips/boot/dts/Makefile
> > +++ b/arch/mips/boot/dts/Makefile
> > @@ -3,6 +3,7 @@ dts-dirs += cavium-octeon
> > dts-dirs += ingenic
> > dts-dirs += lantiq
> > dts-dirs += mti
> > +dts-dirs += ni
> > dts-dirs += netlogic
> > dts-dirs += pic32
> > dts-dirs += qca
> > diff --git a/arch/mips/boot/dts/ni/169445.dts b/arch/mips/boot/dts/ni/169445.dts
> > new file mode 100644
> > index 0000000..a2b49f9
> > --- /dev/null
> > +++ b/arch/mips/boot/dts/ni/169445.dts
> > @@ -0,0 +1,99 @@
> > +/dts-v1/;
> > +
> > +/ {
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + compatible = "ni,169445";
> > +
> > + cpus {
> > + mips-hpt-frequency = <25000000>;
> > +
> > + cpu@0 {
> > + compatible = "mti,mips14KEc";
> > + };
> > + };
> > +
> > + memory {
>
> memory@0
>
> > + device_type = "memory";
> > + reg = <0x0 0x08000000>;
> > + };
> > +
> > + clocks {
> > + baseclk: baseclock {
> > + compatible = "fixed-clock";
> > + #clock-cells = <0>;
> > + clock-frequency = <50000000>;
> > + };
> > + };
> > +
> > + cpu_intc: cpu_intc {
> > + #address-cells = <0>;
> > + compatible = "mti,cpu-interrupt-controller";
> > + interrupt-controller;
> > + #interrupt-cells = <1>;
> > + };
> > +
> > + ahb@0 {
> > + compatible = "simple-bus";
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + ranges;
>
> If everything is under 0x1f3xxxxx, then add in the ranges here (and the
> unit address).
>
I noticed that some systems call out their axi/ahb busses, some do not. Would
you prefer that I remove the bus entirely?
> > +
> > + gpio1: nand-gpio-out@1f300010 {
>
> As in the binding example: gpio-controller@...
>
> > + compatible = "ni,169445-nand-gpio";
> > + reg = <0x1f300010 0x4>;
> > + reg-names = "dat";
> > + gpio-controller;
> > + #gpio-cells = <2>;
> > + ngpios = <5>;
> > + };
> > +
> > + gpio2: nand-gpio-in@1f300014 {
>
> ditto
>
> > + compatible = "ni,169445-nand-gpio";
> > + reg = <0x1f300014 0x4>;
> > + reg-names = "dat";
> > + gpio-controller;
> > + #gpio-cells = <2>;
> > + ngpios = <1>;
> > + };
> > +
> > + nand@1f300000 {
> > + compatible = "gpio-control-nand";
> > + nand-on-flash-bbt;
> > + nand-ecc-mode = "soft_bch";
> > + nand-ecc-step-size = <512>;
> > + nand-ecc-strength = <4>;
> > + reg = <0x1f300000 4>;
> > + gpios = <&gpio2 0 0>, /* rdy */
> > + <&gpio1 1 0>, /* nce */
> > + <&gpio1 2 0>, /* ale */
> > + <&gpio1 3 0>, /* cle */
> > + <&gpio1 4 0>; /* nwp */
> > + };
> > +
> > + serial@1f380000 {
> > + compatible = "ns16550a";
> > + reg = <0x1f380000 0x1000>;
> > + interrupt-parent = <&cpu_intc>;
> > + interrupts = <6>;
> > + clocks = <&baseclk>;
> > + reg-shift = <0>;
> > + };
> > +
> > + ethernet@1f340000 {
> > + compatible = "snps,dwc-qos-ethernet-4.10";
> > + interrupt-parent = <&cpu_intc>;
> > + interrupts = <5>;
> > + reg = <0x1f340000 0x2000>;
> > + clock-names = "apb_pclk", "phy_ref_clk";
> > + clocks = <&baseclk>, <&baseclk>;
> > +
> > + phy-mode = "rgmii";
> > +
> > + fixed-link {
> > + speed = <1000>;
> > + full-duplex;
> > + };
> > + };
> > + };
> > +};
>
> [...]
>
> > diff --git a/arch/mips/ni169445/169445-setup.c b/arch/mips/ni169445/169445-setup.c
> > new file mode 100644
> > index 0000000..80a5c91
> > --- /dev/null
> > +++ b/arch/mips/ni169445/169445-setup.c
> > @@ -0,0 +1,58 @@
> > +/* Copyright 2016 National Instruments Corporation
> > + *
> > + * 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 <linux/init.h>
> > +#include <linux/clk-provider.h>
> > +#include <linux/libfdt.h>
> > +#include <linux/of_platform.h>
> > +#include <linux/of_fdt.h>
> > +
> > +#include <asm/prom.h>
> > +#include <asm/fw/fw.h>
> > +
> > +#include <asm/mips-boards/generic.h>
> > +
> > +const char *get_system_type(void)
> > +{
> > + return "NI 169445 FPGA";
>
> Perhaps this should come from model property. There's a patch in flight
> to add a function to get machine name.
>
> > +}
> > +
> > +void __init plat_mem_setup(void)
> > +{
> > + /*
> > + * Load the builtin devicetree. This causes the chosen node to be
> > + * parsed resulting in our memory appearing
> > + */
> > + __dt_setup_arch(__dtb_start);
> > +}
> > +
> > +void __init device_tree_init(void)
> > +{
> > + if (!initial_boot_params)
> > + return;
> > +
> > + unflatten_and_copy_device_tree();
> > +}
> > +
> > +static int __init customize_machine(void)
> > +{
> > + of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
>
> This should happen by default now.
>
> > + return 0;
> > +}
> > +arch_initcall(customize_machine);
Thank you for the feedback.
Nathan
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 1/3] power: supply: bq24735-charger: simplify register update to stop charging
From: Sebastian Reichel @ 2016-12-14 16:41 UTC (permalink / raw)
To: Peter Rosin; +Cc: linux-kernel, Rob Herring, Mark Rutland, linux-pm, devicetree
In-Reply-To: <1481673405-4547-2-git-send-email-peda@axentia.se>
[-- Attachment #1: Type: text/plain, Size: 1233 bytes --]
Hi,
On Wed, Dec 14, 2016 at 12:56:43AM +0100, Peter Rosin wrote:
> Providing value bits outside of the mask is pointless.
>
> Signed-off-by: Peter Rosin <peda@axentia.se>
> ---
> drivers/power/supply/bq24735-charger.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/power/supply/bq24735-charger.c b/drivers/power/supply/bq24735-charger.c
> index eb7783b42e0a..1d5c9206e0ed 100644
> --- a/drivers/power/supply/bq24735-charger.c
> +++ b/drivers/power/supply/bq24735-charger.c
> @@ -111,8 +111,7 @@ static inline int bq24735_enable_charging(struct bq24735 *charger)
> return 0;
>
> return bq24735_update_word(charger->client, BQ24735_CHG_OPT,
> - BQ24735_CHG_OPT_CHARGE_DISABLE,
> - ~BQ24735_CHG_OPT_CHARGE_DISABLE);
> + BQ24735_CHG_OPT_CHARGE_DISABLE, 0);
> }
>
> static inline int bq24735_disable_charging(struct bq24735 *charger)
Thanks for your patch. We are currently in the merge
window and your patch will appear in linux-next once
4.10-rc1 has been tagged by Linus Torvalds.
Until then I queued it into this branch:
https://git.kernel.org/cgit/linux/kernel/git/sre/linux-power-supply.git/log/?h=for-next-next
-- Sebastian
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v3 1/4] pinctrl: aspeed: Read and write bits in LPC and GFX controllers
From: Rob Herring @ 2016-12-14 16:46 UTC (permalink / raw)
To: Andrew Jeffery
Cc: Linus Walleij, Mark Rutland, Joel Stanley,
linux-gpio@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <1481609543.3112.34.camel@aj.id.au>
On Tue, Dec 13, 2016 at 12:12 AM, Andrew Jeffery <andrew@aj.id.au> wrote:
> On Mon, 2016-12-12 at 10:27 -0600, Rob Herring wrote:
>> On Tue, Dec 06, 2016 at 02:11:49PM +1100, Andrew Jeffery wrote:
>> > The System Control Unit IP block in the Aspeed SoCs is typically where
>> > the pinmux configuration is found, but not always. A number of pins
>> > depend on state in one of LPC Host Control (LHC) or SoC Display
>> > Controller (GFX) IP blocks, so the Aspeed pinmux drivers should have the
>> > means to adjust these as necessary.
>> >
>> > We use syscon to cast a regmap over the GFX and LPC blocks, which is
>> > used as an arbitration layer between the relevant driver and the pinctrl
>> > subsystem. The regmaps are then exposed to the SoC-specific pinctrl
>> > drivers by phandles in the devicetree, and are selected during a mux
>> > request by querying a new 'ip' member in struct aspeed_sig_desc.
>> >
>> > > > Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
>> > ---
>> > .../devicetree/bindings/pinctrl/pinctrl-aspeed.txt | 50 ++++++-
>> > drivers/pinctrl/aspeed/pinctrl-aspeed-g4.c | 18 +--
>> > drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c | 48 ++++--
>> > drivers/pinctrl/aspeed/pinctrl-aspeed.c | 161 +++++++++++++--------
>> > drivers/pinctrl/aspeed/pinctrl-aspeed.h | 32 ++--
>> > 5 files changed, 214 insertions(+), 95 deletions(-)
>> >
>> > diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-aspeed.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-aspeed.txt
>> > index 2ad18c4ea55c..115b0cce6c1c 100644
>> > --- a/Documentation/devicetree/bindings/pinctrl/pinctrl-aspeed.txt
>> > +++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-aspeed.txt
>> > @@ -4,12 +4,19 @@ Aspeed Pin Controllers
>> > The Aspeed SoCs vary in functionality inside a generation but have a common mux
>> > device register layout.
>> >
>> > -Required properties:
>> > -- compatible : Should be any one of the following:
>> > > > - "aspeed,ast2400-pinctrl"
>> > > > - "aspeed,g4-pinctrl"
>> > > > - "aspeed,ast2500-pinctrl"
>> > > > - "aspeed,g5-pinctrl"
>> > +Required properties for g4:
>> > > > +- compatible : Should be any one of the following:
>> > > > + "aspeed,ast2400-pinctrl"
>> > > > + "aspeed,g4-pinctrl"
>> > +
>> > +Required properties for g5:
>> > > > +- compatible : Should be any one of the following:
>> > > > + "aspeed,ast2500-pinctrl"
>> > > > + "aspeed,g5-pinctrl"
>> > +
>> > > > +- aspeed,external-nodes: A cell of phandles to external controller nodes:
>> > > > + 0: compatible with "aspeed,ast2500-gfx", "syscon"
>> > > > + 1: compatible with "aspeed,ast2500-lpchc", "syscon"
>> >
>> > The pin controller node should be a child of a syscon node with the required
>> > property:
>> > @@ -47,7 +54,7 @@ RGMII1 RGMII2 RMII1 RMII2 SD1 SPI1 SPI1DEBUG SPI1PASSTHRU TIMER4 TIMER5 TIMER6
>> > TIMER7 TIMER8 VGABIOSROM
>> >
>> >
>> > -Examples:
>> > +g4 Example:
>> >
>> > > > syscon: scu@1e6e2000 {
>> > > > compatible = "syscon", "simple-mfd";
>> > > > @@ -63,5 +70,34 @@ syscon: scu@1e6e2000 {
>> > > > };
>> > };
>> >
>> > +g5 Example:
>> > +
>> > +apb {
>> > > > > > + gfx: display@1e6e6000 {
>> > > > + compatible = "aspeed,ast2500-gfx", "syscon";
>> > > > + reg = <0x1e6e6000 0x1000>;
>> > > > + };
>> > +
>> > > > > > + lpchc: lpchc@1e7890a0 {
>> > > > + compatible = "aspeed,ast2500-lpchc", "syscon";
>> > > > + reg = <0x1e7890a0 0xc4>;
>> > > > + };
>> > +
>> > > > > > + syscon: scu@1e6e2000 {
>> > + compatible = "syscon", "simple-mfd";
>>
>> I must have missed this the first time, but "syscon" should be used with
>> a specific compatible. Though, the scu binding does define one.
>
> Yes, the example should be fixed.
>
>>
>> > > > + reg = <0x1e6e2000 0x1a8>;
>> > +
>> > + pinctrl: pinctrl {
>>
>> Is this the only child?
>
> No. A incomplete list of other functions in the SCU includes:
>
> * An RNG
> * Power management
> * PCI configuration
> * System reset
> * Clock configuration
>
>>
>> > + compatible = "aspeed,g5-pinctrl";
>>
>> There's no register range for pinctrl?
>
> This may be a mistake on my part; when I wrote this I had no experience
> with writing devicetree bindings (and still don't have a lot).
>
> The SCU does have register regions for pinctrl but on reflection I feel
> neither the mfd nor syscon bindings describe how children's resources
> should be treated in general. The example in the mfd bindings is for
> hardware that is register-bit-led,compatible, whose bindings use the
> 'offset' property rather than 'reg', which still describes where, but
> not using the reg property. Given my uncertainty with reg in an mfd
> child, I wrote the pinctrl/pinmux driver using offsets from the base of
> the SCU's syscon rather than describing the exact region(s) of the
> syscon that should be used.
>
> The issue you raise here occurred to me when writing the LPC Host
> Controller bindings, but there I wasn't convinced using the ranges
> property to give offsets was the right thing to do either.
>
> Regardless, whilst there are two dedicated regions of pinmux registers,
> the mux state also depends on bits in SCU registers outside of these
> regions. Assuming we define an appropriate ranges property for the SCU
> syscon the pinctrl reg property would look like:
>
> reg = <0x2c 0x1>, <0x3c 0x1>, <0x48 0x1>, <0x70 0x1>, <0x7c 0x1>, <0x80 0x18>, <0xa0 0x10>, <0xd0 0x1>;
>
> This is the list of registers affecting the mux taken from the pinctrl-
> aspeed.h.
With other registers in the holes, right? If it is sparse like that,
then yes you probably just want to have reg in the parent for the
whole block.
> What action do you recommend here? The pinctrl dts patches for the
> Aspeed SoCs are yet to be applied, so changing the bindings to require
> a reg property can't break any existing in-tree users as there are
> none. The pinctrl driver can be patched to respect the reg property
> after the fact, though actually using the region descriptions might be
> interesting.
>
>>
>> > + aspeed,external-nodes = <&gfx, &lpchc>;
>
> Did you have feedback on this approach? I queried you about it in the
> previous revision, but never received a reply:
It seems okay. At least, I don't have a better suggestion.
Rob
^ permalink raw reply
* Re: [PATCH] MIPS: NI 169445 board support
From: Rob Herring @ 2016-12-14 16:48 UTC (permalink / raw)
To: Nathan Sullivan
Cc: Ralf Baechle, Mark Rutland, Linux-MIPS,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <20161214163253.GA25341@nathan3500-linux-VM>
On Wed, Dec 14, 2016 at 10:32 AM, Nathan Sullivan
<nathan.sullivan@ni.com> wrote:
> On Fri, Dec 09, 2016 at 03:18:28PM -0600, Rob Herring wrote:
>> On Fri, Dec 02, 2016 at 09:42:09AM -0600, Nathan Sullivan wrote:
>> > Support the National Instruments 169445 board.
>> >
>> > Signed-off-by: Nathan Sullivan <nathan.sullivan@ni.com>
>> > ---
>> > "gpio: mmio: add support for NI 169445 NAND GPIO" and
>> > "devicetree: add vendor prefix for National Instruments" are required for the
>> > NAND on this board to work.
>> > + ahb@0 {
>> > + compatible = "simple-bus";
>> > + #address-cells = <1>;
>> > + #size-cells = <1>;
>> > + ranges;
>>
>> If everything is under 0x1f3xxxxx, then add in the ranges here (and the
>> unit address).
>>
>
> I noticed that some systems call out their axi/ahb busses, some do not. Would
> you prefer that I remove the bus entirely?
Definitely not. IMO, not having a bus node is an error.
Rob
^ permalink raw reply
* Re: [PATCH linux v1 0/4] Seven segment display support
From: Greg KH @ 2016-12-14 16:50 UTC (permalink / raw)
To: Neil Armstrong
Cc: Thomas Petazzoni, mark.rutland,
Jaghathiswari Rankappagounder Natarajan, arnd, devicetree,
openbmc, linux, linux-kernel, robh+dt, joel, linux-arm-kernel
In-Reply-To: <ac324946-41da-c090-a0ca-78155611bb7e@baylibre.com>
On Wed, Dec 14, 2016 at 02:12:41PM +0100, Neil Armstrong wrote:
> On 12/14/2016 01:56 PM, Greg KH wrote:
> > On Wed, Dec 14, 2016 at 01:45:30PM +0100, Thomas Petazzoni wrote:
> >> Hello,
> >>
> >> On Tue, 13 Dec 2016 23:55:00 -0800, Jaghathiswari Rankappagounder
> >> Natarajan wrote:
> >>
> >>> Documentation for the binding which provides an interface for adding clock,
> >>> data and clear signal GPIO lines to control seven segment display.
> >>>
> >>> The platform device driver provides an API for displaying on two 7-segment
> >>> displays, and implements the required bit-banging. The hardware assumed is
> >>> 74HC164 wired to two 7-segment displays.
> >>>
> >>> The character device driver implements the user-space API for letting a user
> >>> write to two 7-segment displays including any conversion methods necessary
> >>> to map the user input to two 7-segment displays.
> >>>
> >>> Adding clock, data and clear signal GPIO lines in the devicetree to control
> >>> seven segment display on zaius platform.
> >>>
> >>> The platform driver matches on the device tree node; the platform driver also
> >>> initializes the character device.
> >>>
> >>> Tested that the seven segment display works properly by writing to the
> >>> character device file on a EVB AST2500 board which also has 74HC164 wired
> >>> to two 7-segment displays.
> >>
> >> FWIW, I proposed a driver for seven segment displays back in 2013:
> >>
> >> http://lists.infradead.org/pipermail/linux-arm-kernel/2013-January/139986.html
> >>
> >> And the feedback from Greg KH was: we don't need a driver for that, do
> >> it from userspace. See:
> >>
> >> http://lists.infradead.org/pipermail/linux-arm-kernel/2013-January/139992.html
> >>
> >> So: good luck :-)
> >
> > Did anyone ever write a library for this type of thing?
> >
> > Again, I don't want to see one-off drivers for random devices like this
> > that should be able to all be controlled from userspace in a common
> > manner. Much like we did for fingerprint readers a long long time
> > ago...
> >
> > thanks,
> >
> > greg k-h
>
> Hi Greg,
>
> Actually, it's more than a random interface, a lot of SoCs and boards actually have such displays
> and it's a pity to use UIO, sysfs gpio bitbanging and all sort of ugly stuff to only print a few
> characters a simple and clean driver could achieve.
Great, then let's make an API that all devices of this type could use,
and not just take individual drivers that all have a custom char or
sysfs interface which requires custom userspace code to be able to drive
all of the different devices in a common way (i.e. a library would have
to be written anyways...)
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH 1/2] devicetree: power: add bindings for GPIO-driven power switches
From: Bartosz Golaszewski @ 2016-12-14 16:58 UTC (permalink / raw)
To: Rob Herring
Cc: Jonathan Cameron, Hartmut Knaack, Lars-Peter Clausen,
Peter Meerwald-Stadler, Mark Rutland, linux-iio, linux-devicetree,
LKML, Kevin Hilman, Patrick Titiano, Neil Armstrong,
Linus Walleij, Alexandre Courbot, linux-gpio, Sebastian Reichel,
linux-pm, Mark Brown, Liam Girdwood
In-Reply-To: <20161213192712.gbaw4t4awayybnta@rob-hp-laptop>
2016-12-13 20:27 GMT+01:00 Rob Herring <robh@kernel.org>:
> On Sun, Dec 11, 2016 at 11:21:44PM +0100, Bartosz Golaszewski wrote:
>> Some boards are equipped with simple, GPIO-driven power load switches.
>> An example of such ICs is the TI tps229* series.
>
> How is this different than a GPIO regulator? The input and output
> voltages just happen to be the same. I could be convinced this is
> different enough to have a different compatible, but it somewhat seems
> you want to use this for IIO, so you are creating a different binding
> for that usecase.
>
It's more of a fixed regulator I suppose. Do you mean adding a new
compatible to the fixed-regulator binding (e.g. "gpio-power-switch" or
"simple-power-switch") and then providing an iio driver for toggling
the switch?
Thanks,
Bartosz
^ permalink raw reply
* Re: [PATCH v2 3/3] power: supply: bq24735-charger: allow chargers to share the ac-detect gpio
From: Sebastian Reichel @ 2016-12-14 16:59 UTC (permalink / raw)
To: Peter Rosin; +Cc: linux-kernel, Rob Herring, Mark Rutland, linux-pm, devicetree
In-Reply-To: <1481673405-4547-4-git-send-email-peda@axentia.se>
[-- Attachment #1: Type: text/plain, Size: 7445 bytes --]
Hi,
On Wed, Dec 14, 2016 at 12:56:45AM +0100, Peter Rosin wrote:
> If several parallel bq24735 chargers have their ac-detect gpios wired
> together (or if only one of the parallel bq24735 chargers have its
> ac-detect pin wired to a gpio, and the others are assumed to react the
> same), then all driver instances need to check the same gpio. But the
> gpio subsystem does not allow sharing gpios, so handle that locally.
Adding GPIO subsystem people to see if they can come up with
something in the gpiod API for this usecase.
> However, only do this for the polling case, sharing is not supported if
> the ac detection is handled with interrupts.
Why? I guess you only added the gpio polling stuff for the shared
gpio feature, so we can skip the gpio polling if we add shared irq
support instead?
> Signed-off-by: Peter Rosin <peda@axentia.se>
> ---
> drivers/power/supply/bq24735-charger.c | 111 +++++++++++++++++++++++++++++----
> 1 file changed, 100 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/power/supply/bq24735-charger.c b/drivers/power/supply/bq24735-charger.c
> index f45876927676..c2403c4d5ece 100644
> --- a/drivers/power/supply/bq24735-charger.c
> +++ b/drivers/power/supply/bq24735-charger.c
> @@ -25,6 +25,7 @@
> #include <linux/kernel.h>
> #include <linux/module.h>
> #include <linux/of.h>
> +#include <linux/of_gpio.h>
> #include <linux/gpio/consumer.h>
> #include <linux/power_supply.h>
> #include <linux/slab.h>
> @@ -43,12 +44,24 @@
> #define BQ24735_MANUFACTURER_ID 0xfe
> #define BQ24735_DEVICE_ID 0xff
>
> +struct bq24735;
> +
> +struct bq24735_shared {
> + struct list_head list;
> + struct bq24735 *owner;
> + struct gpio_desc *status_gpio;
> +};
> +
> +static DEFINE_MUTEX(shared_lock);
> +static LIST_HEAD(shared_list);
> +
> struct bq24735 {
> struct power_supply *charger;
> struct power_supply_desc charger_desc;
> struct i2c_client *client;
> struct bq24735_platform *pdata;
> struct mutex lock;
> + struct bq24735_shared *shared;
> struct gpio_desc *status_gpio;
> struct delayed_work poll;
> u32 poll_interval;
> @@ -346,6 +359,75 @@ static struct bq24735_platform *bq24735_parse_dt_data(struct i2c_client *client)
> return pdata;
> }
>
> +static struct gpio_desc *bq24735_get_status_gpio(struct bq24735 *charger)
> +{
> + struct device *dev = &charger->client->dev;
> + struct bq24735_shared *shared;
> + int gpio;
> + enum of_gpio_flags flags;
> + int active_low;
> + struct list_head *pos;
> +
> + if (of_property_read_bool(dev->of_node, "ti,ac-detect-gpios"))
> + gpio = of_get_named_gpio_flags(dev->of_node,
> + "ti,ac-detect-gpios", 0, &flags);
> + else if (of_property_read_bool(dev->of_node, "ti,ac-detect-gpio"))
> + gpio = of_get_named_gpio_flags(dev->of_node,
> + "ti,ac-detect-gpio", 0, &flags);
> + else
> + return NULL;
> +
> + if (!gpio_is_valid(gpio))
> + return ERR_PTR(gpio);
> + active_low = flags & OF_GPIO_ACTIVE_LOW;
> +
> + mutex_lock(&shared_lock);
> + list_for_each(pos, &shared_list) {
> + shared = list_entry(pos, struct bq24735_shared, list);
> + if (gpio != desc_to_gpio(shared->status_gpio))
> + continue;
> + if (!active_low ^ !gpiod_is_active_low(shared->status_gpio))
> + continue;
> +
> + get_device(&shared->owner->client->dev);
> + dev_dbg(dev, "sharing gpio with %s\n",
> + shared->owner->pdata->name);
> + charger->shared = shared;
> + mutex_unlock(&shared_lock);
> + return shared->status_gpio;
> + }
> +
> + shared = devm_kzalloc(dev, sizeof(*shared), GFP_KERNEL);
> + if (!shared) {
> + mutex_unlock(&shared_lock);
> + return ERR_PTR(-ENOMEM);
> + }
> + shared->owner = charger;
> + shared->status_gpio = gpiod_get(dev, "ti,ac-detect", GPIOD_IN);
> + if (!IS_ERR(shared->status_gpio)) {
> + charger->shared = shared;
> + list_add(&shared->list, &shared_list);
> + }
> + mutex_unlock(&shared_lock);
> +
> + return shared->status_gpio;
> +}
> +
> +static void bq24735_put_status_gpio(struct bq24735 *charger)
> +{
> + if (!charger->shared)
> + return;
> +
> + mutex_lock(&shared_lock);
> + if (charger->shared->owner != charger) {
> + put_device(&charger->shared->owner->client->dev);
> + } else {
> + list_del(&charger->shared->list);
> + gpiod_put(charger->shared->status_gpio);
> + }
> + mutex_unlock(&shared_lock);
> +}
> +
> static int bq24735_charger_probe(struct i2c_client *client,
> const struct i2c_device_id *id)
> {
> @@ -402,9 +484,7 @@ static int bq24735_charger_probe(struct i2c_client *client,
>
> i2c_set_clientdata(client, charger);
>
> - charger->status_gpio = devm_gpiod_get_optional(&client->dev,
> - "ti,ac-detect",
> - GPIOD_IN);
> + charger->status_gpio = bq24735_get_status_gpio(charger);
> if (IS_ERR(charger->status_gpio)) {
> ret = PTR_ERR(charger->status_gpio);
> dev_err(&client->dev, "Getting gpio failed: %d\n", ret);
> @@ -416,28 +496,30 @@ static int bq24735_charger_probe(struct i2c_client *client,
> if (ret < 0) {
> dev_err(&client->dev, "Failed to read manufacturer id : %d\n",
> ret);
> - return ret;
> + goto out;
> } else if (ret != 0x0040) {
> dev_err(&client->dev,
> "manufacturer id mismatch. 0x0040 != 0x%04x\n", ret);
> - return -ENODEV;
> + ret = -ENODEV;
> + goto out;
> }
>
> ret = bq24735_read_word(client, BQ24735_DEVICE_ID);
> if (ret < 0) {
> dev_err(&client->dev, "Failed to read device id : %d\n", ret);
> - return ret;
> + goto out;
> } else if (ret != 0x000B) {
> dev_err(&client->dev,
> "device id mismatch. 0x000b != 0x%04x\n", ret);
> - return -ENODEV;
> + ret = -ENODEV;
> + goto out;
> }
> }
>
> ret = bq24735_config_charger(charger);
> if (ret < 0) {
> dev_err(&client->dev, "failed in configuring charger");
> - return ret;
> + goto out;
> }
>
> /* check for AC adapter presence */
> @@ -445,7 +527,7 @@ static int bq24735_charger_probe(struct i2c_client *client,
> ret = bq24735_enable_charging(charger);
> if (ret < 0) {
> dev_err(&client->dev, "Failed to enable charging\n");
> - return ret;
> + goto out;
> }
> }
>
> @@ -455,7 +537,7 @@ static int bq24735_charger_probe(struct i2c_client *client,
> ret = PTR_ERR(charger->charger);
> dev_err(&client->dev, "Failed to register power supply: %d\n",
> ret);
> - return ret;
> + goto out;
> }
>
> if (client->irq) {
> @@ -470,7 +552,7 @@ static int bq24735_charger_probe(struct i2c_client *client,
> dev_err(&client->dev,
> "Unable to register IRQ %d err %d\n",
> client->irq, ret);
> - return ret;
> + goto out;
> }
> } else if (charger->status_gpio) {
> ret = of_property_read_u32(client->dev.of_node,
> @@ -487,6 +569,11 @@ static int bq24735_charger_probe(struct i2c_client *client,
> }
>
> return 0;
> +
> +out:
> + bq24735_put_status_gpio(charger);
> +
> + return ret;
> }
>
> static int bq24735_charger_remove(struct i2c_client *client)
> @@ -496,6 +583,8 @@ static int bq24735_charger_remove(struct i2c_client *client)
> if (charger->poll_interval)
> cancel_delayed_work_sync(&charger->poll);
>
> + bq24735_put_status_gpio(charger);
> +
> return 0;
> }
>
> --
> 2.1.4
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v2 3/3] power: supply: bq24735-charger: allow chargers to share the ac-detect gpio
From: Sebastian Reichel @ 2016-12-14 17:01 UTC (permalink / raw)
To: Peter Rosin, Linus Walleij, Alexandre Courbot
Cc: linux-kernel, linux-pm, devicetree, linux-gpio
In-Reply-To: <20161214165921.jsatcznbljd7anqi@earth>
[-- Attachment #1: Type: text/plain, Size: 8056 bytes --]
[of course I forgot to actually add gpio people, let's try again]
On Wed, Dec 14, 2016 at 05:59:21PM +0100, Sebastian Reichel wrote:
> Hi,
>
> On Wed, Dec 14, 2016 at 12:56:45AM +0100, Peter Rosin wrote:
> > If several parallel bq24735 chargers have their ac-detect gpios wired
> > together (or if only one of the parallel bq24735 chargers have its
> > ac-detect pin wired to a gpio, and the others are assumed to react the
> > same), then all driver instances need to check the same gpio. But the
> > gpio subsystem does not allow sharing gpios, so handle that locally.
>
> Adding GPIO subsystem people to see if they can come up with
> something in the gpiod API for this usecase.
>
> > However, only do this for the polling case, sharing is not supported if
> > the ac detection is handled with interrupts.
>
> Why? I guess you only added the gpio polling stuff for the shared
> gpio feature, so we can skip the gpio polling if we add shared irq
> support instead?
>
> > Signed-off-by: Peter Rosin <peda@axentia.se>
> > ---
> > drivers/power/supply/bq24735-charger.c | 111 +++++++++++++++++++++++++++++----
> > 1 file changed, 100 insertions(+), 11 deletions(-)
> >
> > diff --git a/drivers/power/supply/bq24735-charger.c b/drivers/power/supply/bq24735-charger.c
> > index f45876927676..c2403c4d5ece 100644
> > --- a/drivers/power/supply/bq24735-charger.c
> > +++ b/drivers/power/supply/bq24735-charger.c
> > @@ -25,6 +25,7 @@
> > #include <linux/kernel.h>
> > #include <linux/module.h>
> > #include <linux/of.h>
> > +#include <linux/of_gpio.h>
> > #include <linux/gpio/consumer.h>
> > #include <linux/power_supply.h>
> > #include <linux/slab.h>
> > @@ -43,12 +44,24 @@
> > #define BQ24735_MANUFACTURER_ID 0xfe
> > #define BQ24735_DEVICE_ID 0xff
> >
> > +struct bq24735;
> > +
> > +struct bq24735_shared {
> > + struct list_head list;
> > + struct bq24735 *owner;
> > + struct gpio_desc *status_gpio;
> > +};
> > +
> > +static DEFINE_MUTEX(shared_lock);
> > +static LIST_HEAD(shared_list);
> > +
> > struct bq24735 {
> > struct power_supply *charger;
> > struct power_supply_desc charger_desc;
> > struct i2c_client *client;
> > struct bq24735_platform *pdata;
> > struct mutex lock;
> > + struct bq24735_shared *shared;
> > struct gpio_desc *status_gpio;
> > struct delayed_work poll;
> > u32 poll_interval;
> > @@ -346,6 +359,75 @@ static struct bq24735_platform *bq24735_parse_dt_data(struct i2c_client *client)
> > return pdata;
> > }
> >
> > +static struct gpio_desc *bq24735_get_status_gpio(struct bq24735 *charger)
> > +{
> > + struct device *dev = &charger->client->dev;
> > + struct bq24735_shared *shared;
> > + int gpio;
> > + enum of_gpio_flags flags;
> > + int active_low;
> > + struct list_head *pos;
> > +
> > + if (of_property_read_bool(dev->of_node, "ti,ac-detect-gpios"))
> > + gpio = of_get_named_gpio_flags(dev->of_node,
> > + "ti,ac-detect-gpios", 0, &flags);
> > + else if (of_property_read_bool(dev->of_node, "ti,ac-detect-gpio"))
> > + gpio = of_get_named_gpio_flags(dev->of_node,
> > + "ti,ac-detect-gpio", 0, &flags);
> > + else
> > + return NULL;
> > +
> > + if (!gpio_is_valid(gpio))
> > + return ERR_PTR(gpio);
> > + active_low = flags & OF_GPIO_ACTIVE_LOW;
> > +
> > + mutex_lock(&shared_lock);
> > + list_for_each(pos, &shared_list) {
> > + shared = list_entry(pos, struct bq24735_shared, list);
> > + if (gpio != desc_to_gpio(shared->status_gpio))
> > + continue;
> > + if (!active_low ^ !gpiod_is_active_low(shared->status_gpio))
> > + continue;
> > +
> > + get_device(&shared->owner->client->dev);
> > + dev_dbg(dev, "sharing gpio with %s\n",
> > + shared->owner->pdata->name);
> > + charger->shared = shared;
> > + mutex_unlock(&shared_lock);
> > + return shared->status_gpio;
> > + }
> > +
> > + shared = devm_kzalloc(dev, sizeof(*shared), GFP_KERNEL);
> > + if (!shared) {
> > + mutex_unlock(&shared_lock);
> > + return ERR_PTR(-ENOMEM);
> > + }
> > + shared->owner = charger;
> > + shared->status_gpio = gpiod_get(dev, "ti,ac-detect", GPIOD_IN);
> > + if (!IS_ERR(shared->status_gpio)) {
> > + charger->shared = shared;
> > + list_add(&shared->list, &shared_list);
> > + }
> > + mutex_unlock(&shared_lock);
> > +
> > + return shared->status_gpio;
> > +}
> > +
> > +static void bq24735_put_status_gpio(struct bq24735 *charger)
> > +{
> > + if (!charger->shared)
> > + return;
> > +
> > + mutex_lock(&shared_lock);
> > + if (charger->shared->owner != charger) {
> > + put_device(&charger->shared->owner->client->dev);
> > + } else {
> > + list_del(&charger->shared->list);
> > + gpiod_put(charger->shared->status_gpio);
> > + }
> > + mutex_unlock(&shared_lock);
> > +}
> > +
> > static int bq24735_charger_probe(struct i2c_client *client,
> > const struct i2c_device_id *id)
> > {
> > @@ -402,9 +484,7 @@ static int bq24735_charger_probe(struct i2c_client *client,
> >
> > i2c_set_clientdata(client, charger);
> >
> > - charger->status_gpio = devm_gpiod_get_optional(&client->dev,
> > - "ti,ac-detect",
> > - GPIOD_IN);
> > + charger->status_gpio = bq24735_get_status_gpio(charger);
> > if (IS_ERR(charger->status_gpio)) {
> > ret = PTR_ERR(charger->status_gpio);
> > dev_err(&client->dev, "Getting gpio failed: %d\n", ret);
> > @@ -416,28 +496,30 @@ static int bq24735_charger_probe(struct i2c_client *client,
> > if (ret < 0) {
> > dev_err(&client->dev, "Failed to read manufacturer id : %d\n",
> > ret);
> > - return ret;
> > + goto out;
> > } else if (ret != 0x0040) {
> > dev_err(&client->dev,
> > "manufacturer id mismatch. 0x0040 != 0x%04x\n", ret);
> > - return -ENODEV;
> > + ret = -ENODEV;
> > + goto out;
> > }
> >
> > ret = bq24735_read_word(client, BQ24735_DEVICE_ID);
> > if (ret < 0) {
> > dev_err(&client->dev, "Failed to read device id : %d\n", ret);
> > - return ret;
> > + goto out;
> > } else if (ret != 0x000B) {
> > dev_err(&client->dev,
> > "device id mismatch. 0x000b != 0x%04x\n", ret);
> > - return -ENODEV;
> > + ret = -ENODEV;
> > + goto out;
> > }
> > }
> >
> > ret = bq24735_config_charger(charger);
> > if (ret < 0) {
> > dev_err(&client->dev, "failed in configuring charger");
> > - return ret;
> > + goto out;
> > }
> >
> > /* check for AC adapter presence */
> > @@ -445,7 +527,7 @@ static int bq24735_charger_probe(struct i2c_client *client,
> > ret = bq24735_enable_charging(charger);
> > if (ret < 0) {
> > dev_err(&client->dev, "Failed to enable charging\n");
> > - return ret;
> > + goto out;
> > }
> > }
> >
> > @@ -455,7 +537,7 @@ static int bq24735_charger_probe(struct i2c_client *client,
> > ret = PTR_ERR(charger->charger);
> > dev_err(&client->dev, "Failed to register power supply: %d\n",
> > ret);
> > - return ret;
> > + goto out;
> > }
> >
> > if (client->irq) {
> > @@ -470,7 +552,7 @@ static int bq24735_charger_probe(struct i2c_client *client,
> > dev_err(&client->dev,
> > "Unable to register IRQ %d err %d\n",
> > client->irq, ret);
> > - return ret;
> > + goto out;
> > }
> > } else if (charger->status_gpio) {
> > ret = of_property_read_u32(client->dev.of_node,
> > @@ -487,6 +569,11 @@ static int bq24735_charger_probe(struct i2c_client *client,
> > }
> >
> > return 0;
> > +
> > +out:
> > + bq24735_put_status_gpio(charger);
> > +
> > + return ret;
> > }
> >
> > static int bq24735_charger_remove(struct i2c_client *client)
> > @@ -496,6 +583,8 @@ static int bq24735_charger_remove(struct i2c_client *client)
> > if (charger->poll_interval)
> > cancel_delayed_work_sync(&charger->poll);
> >
> > + bq24735_put_status_gpio(charger);
> > +
> > return 0;
> > }
> >
> > --
> > 2.1.4
> >
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* [PATCH 0/2] xilinx_dma: Add external reset control
From: Ramiro Oliveira @ 2016-12-14 17:18 UTC (permalink / raw)
To: dmaengine-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: vinod.koul-ral2JQCrhuEAvxtiuMwx3w, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, michal.simek-gjFFaj9aHVfQT0dZR+AlfA,
soren.brinkmann-gjFFaj9aHVfQT0dZR+AlfA,
appana.durga.rao-gjFFaj9aHVfQT0dZR+AlfA,
anuragku-gjFFaj9aHVfQT0dZR+AlfA,
dan.j.williams-ral2JQCrhuEAvxtiuMwx3w,
laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw,
CARLOS.PALMINHA-HKixBCOQz3hWk0Htik3J/w, Ramiro Oliveira
This patchset adds support for controlling an external reset line. Since
this reset line is optional it won't break compatibility.
Ramiro Oliveira (2):
xilinx_dma: Edit device tree bindings documentation
xilinx_dma: Add reset support
.../devicetree/bindings/dma/xilinx/xilinx_dma.txt | 6 ++++++
drivers/dma/xilinx/xilinx_dma.c | 23 ++++++++++++++++++++++
2 files changed, 29 insertions(+)
--
2.10.2
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH 1/2] xilinx_dma: Edit device tree bindings documentation
From: Ramiro Oliveira @ 2016-12-14 17:18 UTC (permalink / raw)
To: dmaengine, devicetree, linux-arm-kernel, linux-kernel
Cc: vinod.koul, robh+dt, mark.rutland, michal.simek, soren.brinkmann,
appana.durga.rao, anuragku, dan.j.williams, laurent.pinchart,
CARLOS.PALMINHA, Ramiro Oliveira
In-Reply-To: <cover.1481735244.git.roliveir@synopsys.com>
Add reset property documentation for Xilinx DMA
Signed-off-by: Ramiro Oliveira <roliveir@synopsys.com>
---
Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt b/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt
index a2b8bfa..7ebce72 100644
--- a/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt
+++ b/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt
@@ -40,6 +40,10 @@ Required properties for VDMA:
Optional properties:
- xlnx,include-sg: Tells configured for Scatter-mode in
the hardware.
+- resets : Must contain an entry for each entry in reset-names.
+ See ../reset/reset.txt for details.
+- reset-names : Must include the following entries:
+ - reset
Optional properties for AXI DMA:
- xlnx,mcdma: Tells whether configured for multi-channel mode in the hardware.
Optional properties for VDMA:
@@ -83,6 +87,8 @@ axi_vdma_0: axivdma@40030000 {
clocks = <&clk 0>, <&clk 1>, <&clk 2>, <&clk 3>, <&clk 4>;
clock-names = "s_axi_lite_aclk", "m_axi_mm2s_aclk", "m_axi_s2mm_aclk",
"m_axis_mm2s_aclk", "s_axis_s2mm_aclk";
+ resets = <&rst 2>;
+ reset-names = "reset";
dma-channel@40030000 {
compatible = "xlnx,axi-vdma-mm2s-channel";
interrupts = < 0 54 4 >;
--
2.10.2
^ permalink raw reply related
* [PATCH 2/2] xilinx_dma: Add reset support
From: Ramiro Oliveira @ 2016-12-14 17:18 UTC (permalink / raw)
To: dmaengine-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: vinod.koul-ral2JQCrhuEAvxtiuMwx3w, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, michal.simek-gjFFaj9aHVfQT0dZR+AlfA,
soren.brinkmann-gjFFaj9aHVfQT0dZR+AlfA,
appana.durga.rao-gjFFaj9aHVfQT0dZR+AlfA,
anuragku-gjFFaj9aHVfQT0dZR+AlfA,
dan.j.williams-ral2JQCrhuEAvxtiuMwx3w,
laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw,
CARLOS.PALMINHA-HKixBCOQz3hWk0Htik3J/w, Ramiro Oliveira
In-Reply-To: <cover.1481735244.git.roliveir-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
Add a DT property to control an optional external reset line
Signed-off-by: Ramiro Oliveira <roliveir-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
---
drivers/dma/xilinx/xilinx_dma.c | 23 +++++++++++++++++++++++
1 file changed, 23 insertions(+)
diff --git a/drivers/dma/xilinx/xilinx_dma.c b/drivers/dma/xilinx/xilinx_dma.c
index 5c9f11b..b845224 100644
--- a/drivers/dma/xilinx/xilinx_dma.c
+++ b/drivers/dma/xilinx/xilinx_dma.c
@@ -46,6 +46,7 @@
#include <linux/slab.h>
#include <linux/clk.h>
#include <linux/io-64-nonatomic-lo-hi.h>
+#include <linux/reset.h>
#include "../dmaengine.h"
@@ -409,6 +410,7 @@ struct xilinx_dma_device {
struct clk *rxs_clk;
u32 nr_channels;
u32 chan_id;
+ struct reset_control *rst;
};
/* Macros */
@@ -2543,6 +2545,27 @@ static int xilinx_dma_probe(struct platform_device *pdev)
if (IS_ERR(xdev->regs))
return PTR_ERR(xdev->regs);
+ xdev->rst = devm_reset_control_get_optional(&pdev->dev, "reset");
+ if (IS_ERR(xdev->rst)) {
+ err = PTR_ERR(xdev->rst);
+ switch (err) {
+ case -ENOENT:
+ case -ENOTSUPP:
+ xdev->rst = NULL;
+ break;
+ default:
+ dev_err(xdev->dev, "error getting reset %d\n", err);
+ return err;
+ }
+ } else {
+ err = reset_control_deassert(xdev->rst);
+ if (err) {
+ dev_err(xdev->dev, "failed to deassert reset: %d\n",
+ err);
+ return err;
+ }
+ }
+
/* Retrieve the DMA engine properties from the device tree */
xdev->has_sg = of_property_read_bool(node, "xlnx,include-sg");
if (xdev->dma_config->dmatype == XDMA_TYPE_AXIDMA)
--
2.10.2
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH] ARM: dts: Add missing CPU frequencies for Exynos5422/5800
From: Javier Martinez Canillas @ 2016-12-14 17:19 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz
Cc: Arjun K V, Krzysztof Kozlowski, Kukjin Kim, Rob Herring,
Mark Rutland, Russell King, Doug Anderson, Andreas Faerber,
Thomas Abraham, Ben Gamari, linux-samsung-soc, linux-arm-kernel,
linux-pm, devicetree, linux-kernel
In-Reply-To: <4861151.PfdUkXTZox@amdc3058>
Hello Bartlomiej,
On 12/14/2016 01:10 PM, Bartlomiej Zolnierkiewicz wrote:
>
> Hi,
>
> On Wednesday, December 14, 2016 11:40:08 AM Javier Martinez Canillas wrote:
>> Hello Bartlomiej,
>>
>> On 12/14/2016 11:25 AM, Bartlomiej Zolnierkiewicz wrote:
>>>
>>> Hi,
>>>
>>> On Wednesday, December 14, 2016 11:06:45 AM Javier Martinez Canillas wrote:
>>>>
>>>> Hello Bartlomiej,
>>>>
>>>> On 12/14/2016 10:28 AM, Bartlomiej Zolnierkiewicz wrote:
>>>>>
>>>>> On Tuesday, December 13, 2016 04:18:05 PM Javier Martinez Canillas wrote:
>>>>>> Hello Bartlomiej,
>>>>>
>>>>> Hi,
>>>>>
>>>>>> On 12/13/2016 01:52 PM, Bartlomiej Zolnierkiewicz wrote:
>>>>>>> Add missing 2000MHz & 1900MHz OPPs (for A15 cores) and 1400MHz OPP
>>>>>>> (for A7 cores). Also update common Odroid-XU3 Lite/XU3/XU4 thermal
>>>>>>> cooling maps to account for new OPPs.
>>>>>>>
>>>>>>> Since new OPPs are not available on all Exynos5422/5800 boards modify
>>>>>>> dts files for Odroid-XU3 Lite (limited to 1.8 GHz / 1.3 GHz) & Peach
>>>>>>> Pi (limited to 2.0 GHz / 1.3 GHz) accordingly.
>>>>>>>
>>>>>>> Tested on Odroid-XU3 and XU3 Lite.
>>>>>>>
>>>>>>> Cc: Doug Anderson <dianders@chromium.org>
>>>>>>> Cc: Javier Martinez Canillas <javier@osg.samsung.com>
>>>>>>> Cc: Andreas Faerber <afaerber@suse.de>
>>>>>>> Cc: Thomas Abraham <thomas.ab@samsung.com>
>>>>>>> Cc: Ben Gamari <ben@smart-cactus.org>
>>>>>>> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
>>>>>>> ---
>>>>>>> arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 14 +++++++-------
>>>>>>> arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts | 17 +++++++++++++++++
>>>>>>> arch/arm/boot/dts/exynos5800-peach-pi.dts | 4 ++++
>>>>>>> arch/arm/boot/dts/exynos5800.dtsi | 15 +++++++++++++++
>>>>>>> 4 files changed, 43 insertions(+), 7 deletions(-)
>>>>>>>
>>>>>>> Index: b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>>>>>>> ===================================================================
>>>>>>> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi 2016-12-13 15:59:33.779763261 +0100
>>>>>>> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi 2016-12-13 15:59:33.775763261 +0100
>>>>>>> @@ -118,7 +118,7 @@
>>>>>>> /*
>>>>>>> * When reaching cpu_alert3, reduce CPU
>>>>>>> * by 2 steps. On Exynos5422/5800 that would
>>>>>>> - * be: 1600 MHz and 1100 MHz.
>>>>>>> + * (usually) be: 1800 MHz and 1200 MHz.
>>>>>>> */
>>>>>>> map3 {
>>>>>>> trip = <&cpu_alert3>;
>>>>>>> @@ -131,16 +131,16 @@
>>>>>>>
>>>>>>> /*
>>>>>>> * When reaching cpu_alert4, reduce CPU
>>>>>>> - * further, down to 600 MHz (11 steps for big,
>>>>>>> - * 7 steps for LITTLE).
>>>>>>> + * further, down to 600 MHz (13 steps for big,
>>>>>>> + * 8 steps for LITTLE).
>>>>>>> */
>>>>>>> - map5 {
>>>>>>> + cooling_map5: map5 {
>>>>>>> trip = <&cpu_alert4>;
>>>>>>> - cooling-device = <&cpu0 3 7>;
>>>>>>> + cooling-device = <&cpu0 3 8>;
>>>>>>> };
>>>>>>> - map6 {
>>>>>>> + cooling_map6: map6 {
>>>>>>> trip = <&cpu_alert4>;
>>>>>>> - cooling-device = <&cpu4 3 11>;
>>>>>>> + cooling-device = <&cpu4 3 13>;
>>>>>>> };
>>>>>>> };
>>>>>>> };
>>>>>>> Index: b/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts
>>>>>>> ===================================================================
>>>>>>> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts 2016-12-13 15:59:33.779763261 +0100
>>>>>>> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts 2016-12-13 15:59:33.775763261 +0100
>>>>>>> @@ -21,6 +21,23 @@
>>>>>>> compatible = "hardkernel,odroid-xu3-lite", "samsung,exynos5800", "samsung,exynos5";
>>>>>>> };
>>>>>>>
>>>>>>> +&cluster_a15_opp_table {
>>>>>>> + /delete-node/opp@2000000000;
>>>>>>> + /delete-node/opp@1900000000;
>>>>>>> +};
>>>>>>> +
>>>>>>> +&cluster_a7_opp_table {
>>>>>>> + /delete-node/opp@1400000000;
>>>>>>> +};
>>>>>>> +
>>>>>>
>>>>>> I think that a comment in the DTS why these operating points aren't available
>>>>>> in this board will make more clear why the nodes are being deleted.
>>>>>
>>>>> Ok, I will add these comments in the next patch revision.
>>>>>
>>>>>>> +&cooling_map5 {
>>>>>>> + cooling-device = <&cpu0 3 7>;
>>>>>>> +};
>>>>>>> +
>>>>>>> +&cooling_map6 {
>>>>>>> + cooling-device = <&cpu4 3 11>;
>>>>>>> +};
>>>>>>> +
>>>>>>> &pwm {
>>>>>>> /*
>>>>>>> * PWM 0 -- fan
>>>>>>> Index: b/arch/arm/boot/dts/exynos5800-peach-pi.dts
>>>>>>> ===================================================================
>>>>>>> --- a/arch/arm/boot/dts/exynos5800-peach-pi.dts 2016-12-13 15:59:33.779763261 +0100
>>>>>>> +++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts 2016-12-13 15:59:33.779763261 +0100
>>>>>>> @@ -146,6 +146,10 @@
>>>>>>> vdd-supply = <&ldo9_reg>;
>>>>>>> };
>>>>>>>
>>>>>>> +&cluster_a7_opp_table {
>>>>>>> + /delete-property/opp@1400000000;
>>>>>>> +};
>>>>>>> +
>>>>>>> &cpu0 {
>>>>>>> cpu-supply = <&buck2_reg>;
>>>>>>> };
>>>>>>> Index: b/arch/arm/boot/dts/exynos5800.dtsi
>>>>>>> ===================================================================
>>>>>>> --- a/arch/arm/boot/dts/exynos5800.dtsi 2016-12-13 15:59:33.779763261 +0100
>>>>>>> +++ b/arch/arm/boot/dts/exynos5800.dtsi 2016-12-13 15:59:33.779763261 +0100
>>>>>>> @@ -24,6 +24,16 @@
>>>>>>> };
>>>>>>>
>>>>>>> &cluster_a15_opp_table {
>>>>>>> + opp@2000000000 {
>>>>>>> + opp-hz = /bits/ 64 <2000000000>;
>>>>>>> + opp-microvolt = <1250000>;
>>>>>>> + clock-latency-ns = <140000>;
>>>>>>> + };
>>>>>>> + opp@1900000000 {
>>>>>>> + opp-hz = /bits/ 64 <1900000000>;
>>>>>>> + opp-microvolt = <1250000>;
>>>>>>> + clock-latency-ns = <140000>;
>>>>>>> + };
>>>>>>> opp@1700000000 {
>>>>>>> opp-microvolt = <1250000>;
>>>>>>> };
>>>>>>> @@ -85,6 +95,11 @@
>>>>>>> };
>>>>>>>
>>>>>>
>>>>>> AFAIK Thomas restricted the maximum OPP, because for A15 freqs > 1.8GHz the
>>>>>> INT rail would need to be scaled up as well since there's a maximum voltage
>>>>>> difference between the ARM and INT rails before the system becomes unstable:
>>>>>>
>>>>>> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-July/276766.html
>>>>>> https://lkml.org/lkml/2014/5/2/419
>>>>>>
>>>>>> The ChromiumOS vendor tree uses a virtual regulator driver that makes sure
>>>>>> the maximum voltage skew is between a limit. But that never made to mainline:
>>>>>>
>>>>>> https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.8/arch/arm/boot/dts/exynos5420-peach-pit.dtsi#90
>>>>>> https://lkml.org/lkml/2014/4/29/28
>>>>>>
>>>>>> Did that change and there's infrastructure in mainline now to cope with that?
>>>>>> If that's the case, I think it would be good to mention in the commit message.
>>>>>
>>>>> I was not aware of this limitation and AFAIK mainline has currently
>>>>> no code to handle it. I also cannot find any code to handle this in
>>>>
>>>> Yes, that's what I thought as well but maybe I was missing something.
>>>>
>>>>> Hardkernel's vendor kernel for Odroid-XU3 board.
>>>>>
>>>>> Do you know whether this problem exists also on Exynos5422/5800
>>>>> SoCs or only on Exynos5420 one? I see that ChromiumOS uses virtual
>>>>> regulator code also on Exynos5800 SoC based Peach Pi board but was
>>>>> the problem actually present on this board?
>>>>>
>>>>
>>>> My understanding is that this problem is present in 5420/5422/5800
>>>> but I have no way to confirm this. I'm just guessing from the info
>>>> in the ChromiumOS vendor tree.
>>>>
>>>> If you look at the commit that added the regulator-locker driver,
>>>> the test says to be done in a Peach Pi so it seems the problem is
>>>> not restricted to only Exynos5420:
>>>>
>>>> https://chromium.googlesource.com/chromiumos/third_party/kernel/+/ba63620feace4eaed5572ac2e77d8d61754af704
>>>>
>>>>> [ I added Arjun to Cc:, maybe he can help in explaining this issue
>>>>> (unfortunately Inderpal's email is no longer working). ]
>>>>>
>>>>
>>>> Added Abhilash to cc list as well since he was involved in the Exynos ChromeOS tree.
>>>
>>> Abhilash's email is also no longer valid.. :(
>>>
>>
>> Yes, I noticed that as well :(
>>
>>>>> Please also note that on Exynos5422/5800 SoCs the same ARM rail
>>>>> voltage is used for 1.9 GHz & 2.0 GHz OPPs as for the 1.8 GHz one.
>>>>> IOW if the problem exists it is already present in the mainline
>>>>> kernel.
>>>>>
>>>>
>>>> Ah, I only looked at your patch and I didn't compare the voltage levels
>>>> in your 1.9 GHz and 2.0 GHz OPPs with the current 1.8 GHz in mainline.
>>>>
>>>> I wonder if the voltage levels in your patch are correct then, since the
>>>> ChromiumOS tree uses a higher voltages for the 1.9 GHz and 2.0 GHz OPPs:
>>>>
>>>> /*
>>>> * Default ASV table
>>>> */
>>>> static const unsigned int asv_voltage_5420[CPUFREQ_NUM_LEVELS] = {
>>>> 1362500, /* L0 2100 */
>>>> 1312500, /* L1 2000 */
>>>> 1275000, /* L2 1900 */
>>>> 1225000, /* L3 1800 */
>>>> 1200000, /* L4 1700 */
>>>>
>>>> This is from https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.8/drivers/cpufreq/exynos5420-cpufreq.c#175
>>>
>>> I think that the above voltages are original ones for Exynos5420
>>> (not for Exynos5422/5800).
>>>
>>
>> In the ChromiumOS tree, the same CPUFreq driver is used for both the Peach
>> Pit (Exynos5420) and Peach Pi (Exynos5800) Chromebooks.
>
> This seems suboptimal (or maybe even incorrect as Exynos5422/5800
> SoCs also use different clock divider values for clocks related to
> CPU clock than Exynos5420 SoC).
>
Yes, I know. There's lot of if (soc_is_exynos5420()) and if (soc_is_exynos5422())
checks in the driver though so I guess those differences are taken into account.
I haven't reviewed that driver in detail though so maybe something is missing.
> Anyway, I can drop Peach Pi support from my patch for now if you want.
>
I'm not against adding all the missing operating points btw, I'm just trying to
make sure that's safe to do so in mainline.
>>> The voltages in my patch were taken from Hardkernel's kernel for
>>> Odroid-XU3:
>>>
>>> /*
>>> * ASV group voltage table
>>> */
>>> static const unsigned int asv_voltage_5422_CA15[CPUFREQ_LEVEL_END_CA15] = {
>>> ...
>>> 1250000, /* L4 2000 */
>>> 1250000, /* L5 1900 */
>>> 1250000, /* L6 1800 */
>>> ...
>>>
>>> https://github.com/hardkernel/linux/blob/odroidxu3-3.10.y-android/drivers/cpufreq/exynos5422-eagle-cpufreq.c#L314
>>>
>>
>> In general I prefer to use the ChromiumOS tree as a reference instead of the
>> HardKernel one, since the former is in a much better shape IMHO.
>
> I generally agree, OTOH Hardkernel's tree is based on Samsung's
> vendor trees and additionally it contains all low-level hardware
> details for Odroid-XU3 board (not present in ChromiumOS tree).
>
Fair enough.
>> I think is worth to check in a kernel tree in http://opensource.samsung.com/
>> for a product that's Exynos5422/5800 based.
>
> I've just checked kernel from SM-G900H_LL_Opensource.zip (for Galaxy
> S5 which is Exynos5422 based) and it uses 50mV lower voltages for
> 1.6 GHz - 2.0 GHz OPPs, for the lower frequencies OPPs voltages are
> identical to the ones used by HardKernel's tree,
>
Interesting, thanks a lot for checking. So if the voltage levels for 1.9 GHz
and 2.0 GHz are the same than 1.8 GHz, then I agree with you that either is
safe to add these OPPs in mainline or the problem is already present there.
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
^ permalink raw reply
* Re: [PATCH 1/2] devicetree: power: add bindings for GPIO-driven power switches
From: Jonathan Cameron @ 2016-12-14 17:36 UTC (permalink / raw)
To: Bartosz Golaszewski, Rob Herring
Cc: Jonathan Cameron, Hartmut Knaack, Lars-Peter Clausen,
Peter Meerwald-Stadler, Mark Rutland, linux-iio, linux-devicetree,
LKML, Kevin Hilman, Patrick Titiano, Neil Armstrong,
Linus Walleij, Alexandre Courbot, linux-gpio, Sebastian Reichel,
linux-pm, Mark Brown, Liam Girdwood
In-Reply-To: <CAMpxmJWw3wCE4ch8TVik+2b3BC8Lvxbi13HGd9GxruSRLu95Mg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1978 bytes --]
On 14 December 2016 16:58:21 GMT+00:00, Bartosz Golaszewski <bgolaszewski@baylibre.com> wrote:
>2016-12-13 20:27 GMT+01:00 Rob Herring <robh@kernel.org>:
>> On Sun, Dec 11, 2016 at 11:21:44PM +0100, Bartosz Golaszewski wrote:
>>> Some boards are equipped with simple, GPIO-driven power load
>switches.
>>> An example of such ICs is the TI tps229* series.
>>
>> How is this different than a GPIO regulator? The input and output
>> voltages just happen to be the same. I could be convinced this is
>> different enough to have a different compatible, but it somewhat
>seems
>> you want to use this for IIO, so you are creating a different binding
>> for that usecase.
>>
>
>It's more of a fixed regulator I suppose. Do you mean adding a new
>compatible to the fixed-regulator binding (e.g. "gpio-power-switch" or
>"simple-power-switch") and then providing an iio driver for toggling
>the switch?
I am rather torn on whether the IIO interface makes any sense beyond that of convenience.
A bridge to a regulator in general might make sense to cover the case of a reg effectively
acting as a DAC at the edge of the known hardware.
Lars' point about perhaps adding support for the new gpio userspace stuff to libiio would in
this case also be rather papering over the issue.
There is known hardware there so we should describe it!
I think we should be considering this as the general case of the Linux controlled power supply.
How do we want to represent that?
Ultimately does a general regulator userspace interface make sense?
Classic case of people cutting our hardware in half and making boundaries beyond which lie dragons.
I would love to see the general case covered.
Jonathan
>
>Thanks,
>Bartosz
>--
>To unsubscribe from this list: send the line "unsubscribe linux-iio" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
[-- Attachment #2: Type: text/html, Size: 2396 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox