* Re: [PATCH 2/2] iio: adc: hx711: Add IIO driver for AVIA HX711
From: Peter Meerwald-Stadler @ 2016-12-13 20:22 UTC (permalink / raw)
To: Andreas Klinger
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-iio-u79uwXL29TY76Z2rM5mHXA,
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
In-Reply-To: <20161213180254.GA3185@andreas>
> This is the IIO driver for AVIA HX711 ADC which ist mostly used in weighting
> cells.
comments below
> The protocol is quite simple and using GPIO's:
GPIOs
> One GPIO is used as clock (SCK) while another GPIO is read (DOUT)
>
> Signed-off-by: Andreas Klinger <ak-n176/SwNRljddJNmlsFzeA@public.gmane.org>
> ---
> drivers/iio/adc/Kconfig | 13 +++
> drivers/iio/adc/Makefile | 1 +
> drivers/iio/adc/hx711.c | 269 +++++++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 283 insertions(+)
> create mode 100644 drivers/iio/adc/hx711.c
>
> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
> index 932de1f9d1e7..7902b50fcf32 100644
> --- a/drivers/iio/adc/Kconfig
> +++ b/drivers/iio/adc/Kconfig
> @@ -205,6 +205,19 @@ 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 GPIO's, one for setting the clock and the other
GPIOs
> + one for getting the data
> +
> + 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..cbc89e467985
> --- /dev/null
> +++ b/drivers/iio/adc/hx711.c
> @@ -0,0 +1,269 @@
> +/*
> + * HX711: analog to digital converter for weight sensor module
> + *
> + * Copyright (c) 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>
> +
> +#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 */
> +
only one newline here please
> +
> +struct hx711_data {
> + struct device *dev;
> + dev_t devt;
devt is not used, delete
> + struct gpio_desc *gpiod_sck;
> + struct gpio_desc *gpiod_dout;
> + int gain_pulse;
> + struct mutex lock;
> +};
> +
> +static void hx711_reset(struct hx711_data *hx711_data)
> +{
> + int val;
> + int i;
> +
> + val = gpiod_get_value(hx711_data->gpiod_dout);
> + if (val) {
> + dev_warn(hx711_data->dev, "RESET-HX711\n");
message needed?
> +
> + 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*/
add space before */
> + msleep(1);
> + }
can this fail? what is it takes longer than 1000 * 1ms?
> + }
> +}
> +
> +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 unsigned int hx711_read(struct hx711_data *hx711_data)
> +{
> + int i;
> + int ret;
> + int wert = 0;
val or value maybe?
should be unsigned int to match the return type of the function
> +
> + hx711_reset(hx711_data);
> +
> + for (i = 0; i < 24; i++) {
> + wert <<= 1;
> + ret = hx711_cycle(hx711_data);
> + if (ret)
> + wert++;
> + }
> +
> + wert ^= 0x800000;
> +
> + for (i = 0; i < hx711_data->gain_pulse; i++)
> + ret = hx711_cycle(hx711_data);
> +
> + return wert;
> +}
> +
delete newline
> +
> +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);
> + int ret;
> +
> + switch (mask) {
> + case IIO_CHAN_INFO_RAW:
> + switch (chan->type) {
> + case IIO_VOLTAGE:
> + mutex_lock(&hx711_data->lock);
> + *val = (int)hx711_read(hx711_data);
> + mutex_unlock(&hx711_data->lock);
> + ret = IIO_VAL_INT;
return IIO_VAL_INT;
> + break;
> + default:
> + return -EINVAL;
> + }
> + return ret;
> + default:
> + return -EINVAL;
> + }
> +
> + return ret;
delete, dead code
> +}
> +
> +static const struct iio_info hx711_iio_info = {
> + .driver_module = THIS_MODULE,
> + .read_raw = hx711_read_raw,
> +};
> +
> +static const struct iio_chan_spec hx711_chan_spec[] = {
> + { .type = IIO_VOLTAGE,
> + .channel = 0,
.channel = 0 not needed, there is only one channel
> + .info_mask_separate =
> + BIT(IIO_CHAN_INFO_RAW),
> + .scan_type = {
scan_type not needed, driver does not support buffered reads
> + .sign = 'u',
> + .realbits = 24,
> + .storagebits = 32,
> + .shift = 0,
> + }
> + },
> +};
> +
> +static int hx711_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct device_node *node = dev->of_node;
> + struct hx711_data *hx711_data = NULL;
> + struct iio_dev *iio;
> + int ret = 0, ival;
> +
> + 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)) {
> + ret = PTR_ERR(hx711_data->gpiod_sck);
> + goto err;
> + }
> +
> + hx711_data->gpiod_dout = devm_gpiod_get(dev, "dout", GPIOD_OUT_HIGH);
> + if (IS_ERR(hx711_data->gpiod_dout)) {
> + ret = PTR_ERR(hx711_data->gpiod_dout);
> + goto err;
> + }
> +
> + ret = of_property_read_u32 (node, "gain", &ival);
> + if (!ret) {
> + switch (ival) {
> + case 32:
> + hx711_data->gain_pulse = HX711_GAIN_32;
> + break;
> + case 64:
> + hx711_data->gain_pulse = HX711_GAIN_64;
> + break;
> + case 128:
merge default and case 128?
> + hx711_data->gain_pulse = HX711_GAIN_128;
> + break;
> + default:
> + hx711_data->gain_pulse = HX711_GAIN_128;
> + }
> + } else
> + hx711_data->gain_pulse = HX711_GAIN_128;
> + dev_dbg(hx711_data->dev, "gain: %d\n", hx711_data->gain_pulse);
> +
> + ret = gpiod_direction_input(hx711_data->gpiod_dout);
> + if (ret < 0) {
> + dev_err(hx711_data->dev, "gpiod_direction_input: %d\n", ret);
> + goto err;
> + }
> +
> + ret = gpiod_direction_output(hx711_data->gpiod_sck, 0);
> + if (ret < 0) {
> + dev_err(hx711_data->dev, "gpiod_direction_output: %d\n", ret);
> + goto err;
> + }
> +
> + 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);
> +
> + dev_err(hx711_data->dev, "initialized\n");
excessive logging, please remove
> +
> + return devm_iio_device_register(dev, iio);
> +
> +err:
> + return ret;
just return directly without goto?
> +}
> +
> +
> +static int hx711_suspend(struct device *dev)
> +{
pointless, just don't do PM support
> + return 0;
> +}
> +
> +static int hx711_resume(struct device *dev)
> +{
> + return 0;
> +}
> +
> +static SIMPLE_DEV_PM_OPS(hx711_pm_ops, hx711_suspend, hx711_resume);
> +
> +
> +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",
> + .pm = &hx711_pm_ops,
> + .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");
> +
>
--
Peter Meerwald-Stadler
+43-664-2444418 (mobile)
^ permalink raw reply
* Re: [PATCH 2/6] clk: sunxi-ng: set the parent rate when adjustin CPUX clock on A33
From: Icenowy Zheng @ 2016-12-13 20:54 UTC (permalink / raw)
To: Maxime Ripard
Cc: devicetree@vger.kernel.org, Quentin Schulz, Michael Turquette,
Stephen Boyd, Russell King, linux-kernel@vger.kernel.org,
Hans de Goede, Chen-Yu Tsai, linux-clk@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, Jorik Jonker
In-Reply-To: <20161213154451.y4wcrqhtcc5sqli7@lukather>
13.12.2016, 23:44, "Maxime Ripard" <maxime.ripard@free-electrons.com>:
> On Tue, Dec 13, 2016 at 11:22:48PM +0800, Icenowy Zheng wrote:
>> The CPUX clock on A33, which is for the Cortex-A7 cores, is designed to
>> be changeable by changing the rate of PLL_CPUX.
>>
>> Add CLK_SET_RATE_PARENT flag to this clock.
>>
>> Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
>
> Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Excuse me, have you merged this patch?
If merged, I won't contain it in my PATCH v2, thus the PATCH v2 will contain
only an updated OPP patch.
>
> Thanks!
> Maxime
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v6 1/8] MFD: add bindings for STM32 Timers driver
From: Rob Herring @ 2016-12-13 21:07 UTC (permalink / raw)
To: Benjamin Gaignard
Cc: Lee Jones, Mark Rutland, Alexandre Torgue,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Linux Kernel Mailing List, Thierry Reding, Linux PWM List,
Jonathan Cameron, Hartmut Knaack, Lars-Peter Clausen,
Peter Meerwald-Stadler,
linux-iio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Fabrice Gasnier, Gerald Baeza, Arnaud Pouliquen,
Linus Walleij <linus.walleij@
In-Reply-To: <CA+M3ks4ukP14YE5-6+gAzJBjEmjEyGyVbsVGOm8ehVm0EfzO-w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Tue, Dec 13, 2016 at 3:29 AM, Benjamin Gaignard
<benjamin.gaignard-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> 2016-12-12 19:51 GMT+01:00 Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>:
>> On Fri, Dec 09, 2016 at 03:15:12PM +0100, Benjamin Gaignard wrote:
>>> Add bindings information for STM32 Timers
>>>
>>> version 6:
>>> - rename stm32-gtimer to stm32-timers
>>> - change compatible
>>> - add description about the IPs
>>>
>>> version 2:
>>> - rename stm32-mfd-timer to stm32-gptimer
>>> - only keep one compatible string
>>>
>>> Signed-off-by: Benjamin Gaignard <benjamin.gaignard-qxv4g6HH51o@public.gmane.org>
>>> ---
>>> .../devicetree/bindings/mfd/stm32-timers.txt | 46 ++++++++++++++++++++++
>>> 1 file changed, 46 insertions(+)
>>> create mode 100644 Documentation/devicetree/bindings/mfd/stm32-timers.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/mfd/stm32-timers.txt b/Documentation/devicetree/bindings/mfd/stm32-timers.txt
>>> new file mode 100644
>>> index 0000000..b30868e
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/mfd/stm32-timers.txt
>>> @@ -0,0 +1,46 @@
>>> +STM32 Timers driver bindings
>>> +
>>> +This IP provides 3 types of timer along with PWM functionality:
>>> +- advanced-control timers consist of a 16-bit auto-reload counter driven by a programmable
>>> + prescaler, break input feature, PWM outputs and complementary PWM ouputs channels.
>>> +- general-purpose timers consist of a 16-bit or 32-bit auto-reload counter driven by a
>>> + programmable prescaler and PWM outputs.
>>> +- basic timers consist of a 16-bit auto-reload counter driven by a programmable prescaler.
>>> +
>>> +Required parameters:
>>> +- compatible: must be "st,stm32-timers"
>>> +
>>> +- reg: Physical base address and length of the controller's
>>> + registers.
>>> +- clock-names: Set to "clk_int".
>>
>> 'clk' is redundant. Also, you don't really need -names when there is
>> only one of them.
>
> I use devm_regmap_init_mmio_clk() which get the clock by it name so
> I have to define it in DT.
Are you sure NULL is not allowed? I don't know, but at least clk_get()
allows NULL.
It's fine to keep, just drop the "clk_" part.
>
>>> +- clocks: Phandle to the clock used by the timer module.
>>> + For Clk properties, please refer to ../clock/clock-bindings.txt
>>> +
>>> +Optional parameters:
>>> +- resets: Phandle to the parent reset controller.
>>> + See ../reset/st,stm32-rcc.txt
>>> +
>>> +Optional subnodes:
>>> +- pwm: See ../pwm/pwm-stm32.txt
>>> +- timer: See ../iio/timer/stm32-timer-trigger.txt
>>> +
>>> +Example:
>>> + timers@40010000 {
>>> + #address-cells = <1>;
>>> + #size-cells = <0>;
>>> + compatible = "st,stm32-timers";
>>> + reg = <0x40010000 0x400>;
>>> + clocks = <&rcc 0 160>;
>>> + clock-names = "clk_int";
>>> +
>>> + pwm {
>>> + compatible = "st,stm32-pwm";
>>> + pinctrl-0 = <&pwm1_pins>;
>>> + pinctrl-names = "default";
>>> + };
>>> +
>>> + timer {
>>> + compatible = "st,stm32-timer-trigger";
>>> + reg = <0>;
>>
>> You don't need reg here as there is only one. In turn, you don't need
>> #address-cells or #size-cells.
>
> I use "reg" to set each timer configuration.
> From hardware point of view they are all the same except for which hardware
> signals they could consume and/or send.
This sounds okay, but...
> "reg" is used as index of the two tables in driver code.
this statement doesn't really sound like valid use of reg.
If you keep reg, then the node needs a unit address (timer@0).
Rob
^ permalink raw reply
* Re: [PATCH 2/4] dt-bindings: mfd: Remove TPS65217 interrupts
From: Rob Herring @ 2016-12-13 21:09 UTC (permalink / raw)
To: Milo Kim
Cc: Arnd Bergmann, Benoit Cousson, Tony Lindgren, Lee Jones,
Sebastian Reichel, Dmitry Torokhov, linux-omap,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <fe4985c0-d60a-2562-12a7-064404efd64c@gmail.com>
On Mon, Dec 12, 2016 at 5:24 PM, Milo Kim <woogyom.kim@gmail.com> wrote:
> On 12/13/2016 02:25 AM, Rob Herring wrote:
>>
>> On Fri, Dec 09, 2016 at 03:28:31PM +0900, Milo Kim wrote:
>>>
>>> Interrupt numbers are from the datasheet, so no need to keep them in
>>> the ABI. Use the number in the DT file.
>>
>> I don't see the purpose of ripping this out. The headers have always
>> been for convienence, not whether the values come from the datasheet or
>> not.
>
>
> My understanding is it's a same rule as other interrupt controllers.
Oh yes, that's true. We never use defines for interrupts. In that case:
Acked-by: Rob Herring <robh@kernel.org>
Rob
^ permalink raw reply
* Re: [PATCH 5/5] Documentation: fsl-quadspi: Add fsl, ls1012a-qspi compatible string
From: Rob Herring @ 2016-12-13 21:14 UTC (permalink / raw)
To: Yao Yuan
Cc: Yuan Yao, shawnguo-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
mark.rutland-5wv7dgnIgG8@public.gmane.org,
computersforpeace-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <DB6PR0402MB2902DADEB4E6D06418AD311F899B0-2mNvjAGDOPmZPt/6Y1Ah+Y3W/0Ik+aLCnBOFsp37pqbUKgpGm//BTAC/G2K4zDHf@public.gmane.org>
On Mon, Dec 12, 2016 at 8:47 PM, Yao Yuan <yao.yuan-3arQi8VN3Tc@public.gmane.org> wrote:
> On Thu, Dec 13, 2016 at 05:23:02PM +0800, Rob Herring wrote:
>> On Thu, Dec 08, 2016 at 05:23:04PM +0800, Yuan Yao wrote:
>> > From: Yuan Yao <yao.yuan-3arQi8VN3Tc@public.gmane.org>
>>
>> Same problem in this subject too.
>>
>> >
>> > new compatible string: "fsl,ls1012a-qspi".
>> >
>> > Signed-off-by: Yuan Yao <yao.yuan-3arQi8VN3Tc@public.gmane.org>
>> > ---
>> > Documentation/devicetree/bindings/mtd/fsl-quadspi.txt | 1 +
>> > 1 file changed, 1 insertion(+)
>>
>> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>
> Thanks for your review.
> And do you have any suggestion for this subject?
The problem is you have a space in the compatible string: "fsl,
ls1012a-qspi" rather than "fsl,ls1012a-qspi"
Also, I prefer "dt/bindings: " as the beginning of binding patch subjects.
Rob
--
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/2] devicetree: i2c-hid: Add Wacom digitizer + regulator support
From: Rob Herring @ 2016-12-13 22:10 UTC (permalink / raw)
To: Brian Norris
Cc: Benjamin Tissoires, Jiri Kosina, Dmitry Torokhov, Doug Anderson,
Caesar Wang, open list:ARM/Rockchip SoC...,
linux-input@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, Mark Rutland
In-Reply-To: <20161212183422.GA138477@google.com>
On Mon, Dec 12, 2016 at 12:34 PM, Brian Norris <briannorris@chromium.org> wrote:
> Hi all,
>
> On Mon, Dec 12, 2016 at 08:47:06AM -0600, Rob Herring wrote:
>
> [Snip Benjamin's proposal; I agree we don't really want a multi-level DT
> layout purely for making the driver look a little nicer (I'm not sure
> this would really be nicer anyway). And I think, as Rob notes here, our
> disagreement is smaller than appears. But I might be wrong.]
>
>> Anyway, we're only debating this:
>
> OK, so I think we might have a consensus of sorts? I'll describe it
> here, in case I'm wrong. Otherwise, I'll send another rev.
>
>> i2c-hid-dev@2c {
>> compatible = "wacom,w9013", "hid-over-i2c";
>
> I plan to document the above, but not treat "wacom,w9013" specially in
> the driver, apart from possibly listing it in the driver of_match_table.
> This was mentioned by Dmitry earlier, and I didn't see any objection.
>
> (Note that there are problems with module autoload when using multiple
> compatible strings like above. May not be supremely relevant to the
> documentation, but it *is* practically important.)
I'm not sure what is not working here exactly. We emit all the
compatible strings in the uevent. However, it looks like this is only
called for platform devices. In the case of i2c, I don't think any
compatible string is emitted. It looks to me like i2c_device_uevent
just needs a call to of_device_get_modalias to fix this. There's some
issues in the I2C core in how it does matching and maybe this is
related? I would guess if it was that easy, then it would be fixed
already. Maybe not.
>> reg = <0x2c>;
>> hid-descr-addr = <0x0020>;
>> interrupt-parent = <&gpx3>;
>> interrupts = <3 2>;
>> vdd-supply = <sth>;
>
> Document and support 'vdd-supply', optionally.
>
>> init-delay-ms = <100>;
>
> Per Rob's mention below, support this as 'post-power-on-delay-ms',
> optionally.
>
> We can use either of these properties on any device, with the
> intention that if there are future needs for divergent bindings, the
> aforementioned compatible property can help us differentiate.
TBC, from a DT perspective (and what the binding should say), is the
properties are only valid with a wacom compatible present (or any
others you want to add). If the driver doesn't enforce that and
supports having those properties with just "hid-over-i2c", then
downstream dts's can use that for all I care.
Rob
^ permalink raw reply
* [PATCH] pinctrl: fix DT bindings for marvell,kirkwood-pinctrl
From: Andreas Klinger @ 2016-12-13 23:08 UTC (permalink / raw)
To: devicetree
Cc: Linus Walleij, Rob Herring, Mark Rutland, linux-gpio,
linux-kernel, Andreas Klinger
On Marvell mv88f6180 mpp pins range from 0 to 19 as well as from 35 to 44.
This is already fixed in commit: 9573e7923007961799beff38bc5c5a7635634eef
This is the documentation change for above commit.
Signed-off-by: Andreas Klinger <ak@it-klinger.de>
---
.../bindings/pinctrl/marvell,kirkwood-pinctrl.txt | 20 ++++++++++----------
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/Documentation/devicetree/bindings/pinctrl/marvell,kirkwood-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/marvell,kirkwood-pinctrl.txt
index 730444a9a4de..6c0ea155b708 100644
--- a/Documentation/devicetree/bindings/pinctrl/marvell,kirkwood-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/marvell,kirkwood-pinctrl.txt
@@ -44,16 +44,16 @@ mpp16 16 gpio, sdio(d2), uart0(cts), uart1(rxd), mii(crs)
mpp17 17 gpio, sdio(d3)
mpp18 18 gpo, nand(io0)
mpp19 19 gpo, nand(io1)
-mpp20 20 gpio, mii(rxerr)
-mpp21 21 gpio, audio(spdifi)
-mpp22 22 gpio, audio(spdifo)
-mpp23 23 gpio, audio(rmclk)
-mpp24 24 gpio, audio(bclk)
-mpp25 25 gpio, audio(sdo)
-mpp26 26 gpio, audio(lrclk)
-mpp27 27 gpio, audio(mclk)
-mpp28 28 gpio, audio(sdi)
-mpp29 29 gpio, audio(extclk)
+mpp35 35 gpio, mii(rxerr)
+mpp36 36 gpio, audio(spdifi)
+mpp37 37 gpio, audio(spdifo)
+mpp38 38 gpio, audio(rmclk)
+mpp39 39 gpio, audio(bclk)
+mpp40 40 gpio, audio(sdo)
+mpp41 41 gpio, audio(lrclk)
+mpp42 42 gpio, audio(mclk)
+mpp43 43 gpio, audio(sdi)
+mpp44 44 gpio, audio(extclk)
* Marvell Kirkwood 88f6190
--
2.1.4
^ permalink raw reply related
* Re: [PATCH v4 4/4] regulator: Prevent falling too fast
From: Matthias Kaehlcke @ 2016-12-13 23:14 UTC (permalink / raw)
To: Doug Anderson
Cc: Mark Brown, Liam Girdwood, Brian Norris, Javier Martinez Canillas,
Rob Herring, Mark Rutland, linux-kernel@vger.kernel.org,
devicetree@vger.kernel.org
In-Reply-To: <CAD=FV=WhUVeq5GZ5-ae4SxypHGB9jWqgvkO02S=G6Zz6cexRzQ@mail.gmail.com>
Hi,
El Tue, Dec 13, 2016 at 12:00:32PM -0800 Doug Anderson ha dit:
> On Tue, Dec 13, 2016 at 9:19 AM, Mark Brown <broonie@kernel.org> wrote:
> > On Mon, Dec 12, 2016 at 01:15:02PM -0800, Matthias Kaehlcke wrote:
> >> El Fri, Oct 28, 2016 at 07:15:21PM +0100 Mark Brown ha dit:
> >> > On Mon, Sep 26, 2016 at 10:41:59AM -0700, Doug Anderson wrote:
> >
> >> > What you're describing to me is a discrete DCDC that has an input
> >> > voltage that sets the output voltage which happens to be set with a PWM.
> >
> >> I experimented a bit with this. Besides the question of how to model
> >> the passives I wonder how the two regulators would interact. The
> >> correct thing seems to be to specify the input regulator as a supply
> >> of the DCDC. dcdc->set_voltage breaks down a voltage transition into
> >
> > No, not unless the prior descriptions of the hardware have been wildly
> > inaccurate - my understanding had been that the DCDC was a normal DCDC
> > with an analogue input intended to be biased to set the output voltage
> > (presumably in terms of a full rail supply) and that the PWM had been
> > connected to this analogue input. If the PWM is supplying the DCDC then
> > the hardware design just seems bizzare, I can't see how this would even
> > work.
>
> Looking at one schematic, the discrete BUCK for at least one of the
> rails is TPS65261RHBR, which appears to be described at
> <https://store.ti.com/TPS65261RHBR.aspx>. Data sheet appears to be at
> <http://www.ti.com/product/tps65261/technicaldocuments?HQS=TI-null-null-octopart-df-pf-null-wwe>.
>
> As you can see from the datasheet ("Adjusting the Output Voltage"
> section), it is intended that you stuff a resistor to make a voltage
> divider and that's how you select the output voltage. In our case the
> PWM interacts here and allows you to make a more dynamic output
> voltage. I've always thought about the input to the "FB" pin as
> making an input voltage, but I guess it's not terribly simple since
> the voltage divider ends up dividing between ground and the output
> voltage.
I also had put my mind on seeing the output of the PWM circuitry as an
input voltage, but technically it isn't a supply of the buck
regulator. It seems we could consider it a "control voltage" instead
and thus avoid the recursive lock acquisition.
Matthias
^ permalink raw reply
* Re: [PATCH 03/11] driver: clk: imx: Add clock driver for imx6sll
From: Stephen Boyd @ 2016-12-13 23:28 UTC (permalink / raw)
To: Jacky Bai
Cc: shawnguo@kernel.org, mturquette@baylibre.com, robh+dt@kernel.org,
mark.rutland@arm.com, linus.walleij@linaro.org,
kernel@pengutronix.de, Fabio Estevam, daniel.lezcano@linaro.org,
tglx@linutronix.de, p.zabel@pengutronix.de,
linux-clk@vger.kernel.org, devicetree@vger.kernel.org,
linux-gpio@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
jacky.baip@gmail.com
In-Reply-To: <AM3PR04MB5302BE33BE1F2C9913FF61587980@AM3PR04MB530.eurprd04.prod.outlook.com>
On 12/12, Jacky Bai wrote:
> > On 12/02, Bai Ping wrote:
> > > diff --git a/drivers/clk/imx/clk-imx6sll.c
> > > b/drivers/clk/imx/clk-imx6sll.c new file mode 100644 index
> > > 0000000..c5219e1
> > > --- /dev/null
> > > +++ b/drivers/clk/imx/clk-imx6sll.c
> > > +0x20, 16, 1, pll7_bypass_sels, ARRAY_SIZE(pll7_bypass_sels),
> > > +CLK_SET_RATE_PARENT);
> > > +
> > > + /* Do not bypass PLLs initially */
> > > + clk_set_parent(clks[IMX6SLL_PLL1_BYPASS], clks[IMX6SLL_CLK_PLL1]);
> > > + clk_set_parent(clks[IMX6SLL_PLL2_BYPASS], clks[IMX6SLL_CLK_PLL2]);
> > > + clk_set_parent(clks[IMX6SLL_PLL3_BYPASS], clks[IMX6SLL_CLK_PLL3]);
> > > + clk_set_parent(clks[IMX6SLL_PLL4_BYPASS], clks[IMX6SLL_CLK_PLL4]);
> > > + clk_set_parent(clks[IMX6SLL_PLL5_BYPASS], clks[IMX6SLL_CLK_PLL5]);
> > > + clk_set_parent(clks[IMX6SLL_PLL6_BYPASS], clks[IMX6SLL_CLK_PLL6]);
> > > + clk_set_parent(clks[IMX6SLL_PLL7_BYPASS], clks[IMX6SLL_CLK_PLL7]);
> >
> > Can we just put raw register writes here instead? I'd prefer we didn't use clk
> > consumer APIs to do things to the clk tree from the providers. The problem
> > there being that:
> >
> > 1) We're trying to move away from using consumer APIs in provider drivers.
> > It's ok if they're used during probe, but inside clk_ops is not preferred.
> >
> > 2) Even if you have a clk pointer, it may be "orphaned" at the time of
> > registration and so calling the APIs here works now but eventually we may
> > want to return an EPROBE_DEFER error in that case and this may block that
> > effort.
> >
> > I suppose if this is the only clk driver on this machine then this last point isn't a
> > concern and things are probably ok here.
> >
>
> Using raw register writing has an issue. The register is modified, but it seems the clock 'parent-child' relationship can
> not match the register setting. The register setting is not bypass the pll, but in debug 'clk_summary', the
> pll is bypassed.
So program the register settings before registering the clocks
with the framework?
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: Re: [PATCH v3 -next 2/2] ARM: dts: sunxi: add support for Orange Pi Zero board
From: Alexey Kardashevskiy @ 2016-12-13 23:49 UTC (permalink / raw)
To: Icenowy Zheng
Cc: Rob Herring, Vishnu Patekar, Andre Przywara,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-doc-u79uwXL29TY76Z2rM5mHXA, Hans de Goede, Arnd Bergmann,
Maxime Ripard, Russell King,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Chen-Yu Tsai,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20161207100132.1Qp0ZxGD-/icbEWb855g0PDqKvflMoHmW9unr2Ajn@public.gmane.org>
On 07/12/16 18:01, Icenowy Zheng wrote:
>
> 2016年12月7日 05:52于 Alexey Kardashevskiy <aik-sLpHqDYs0B2HXe+LvDLADg@public.gmane.org>写道:
>>
>> On 06/12/16 18:43, Icenowy Zheng wrote:
>>>
>>> 2016年12月6日 09:51于 Alexey Kardashevskiy <aik-sLpHqDYs0B2HXe+LvDLADg@public.gmane.org>写道:
>>>>
>>>> On 03/12/16 02:05, Icenowy Zheng wrote:
>>>>> Orange Pi Zero is a board that came with the new Allwinner H2+ SoC and a
>>>>> SDIO Wi-Fi chip by Allwinner (XR819).
>>>>>
>>>>> Add a device tree file for it.
>>>>>
>>>>> Signed-off-by: Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org>
>>>>> ---
>>>>> Changes since v2:
>>>>> - Merged SDIO Wi-Fi patch into it.
>>>>> - SDIO Wi-Fi: add a ethernet1 alias to it, as it has no internal NVRAM.
>>>>> - SDIO Wi-Fi: changed pinctrl binding to generic pinconf
>>>>> - removed all gpio pinctrl nodes
>>>>> - changed h2plus to h2-plus
>>>>> Changes since v1:
>>>>> - Convert to generic pinconf bindings.
>>>>> - SDIO Wi-Fi: add patch.
>>>>>
>>>>> Some notes:
>>>>> - The uart1 and uart2 is available on the unsoldered gpio header.
>>>>> - The onboard USB connector has its Vbus directly connected to DCIN-5V (the
>>>>> power jack)
>>>>>
>>>>> arch/arm/boot/dts/Makefile | 1 +
>>>>> arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts | 159 ++++++++++++++++++++++
>>>>> 2 files changed, 160 insertions(+)
>>>>> create mode 100644 arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts
>>>>>
>>>>> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
>>>>> index 6447abc..59f6e86 100644
>>>>> --- a/arch/arm/boot/dts/Makefile
>>>>> +++ b/arch/arm/boot/dts/Makefile
>>>>> @@ -844,6 +844,7 @@ dtb-$(CONFIG_MACH_SUN8I) += \
>>>>> sun8i-a33-sinlinx-sina33.dtb \
>>>>> sun8i-a83t-allwinner-h8homlet-v2.dtb \
>>>>> sun8i-a83t-cubietruck-plus.dtb \
>>>>> + sun8i-h2-plus-orangepi-zero.dtb \
>>>>> sun8i-h3-bananapi-m2-plus.dtb \
>>>>> sun8i-h3-nanopi-neo.dtb \
>>>>> sun8i-h3-orangepi-2.dtb \
>>>>> diff --git a/arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts b/arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts
>>>>> new file mode 100644
>>>>> index 0000000..d18807f
>>>>> --- /dev/null
>>>>> +++ b/arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts
>>>>> @@ -0,0 +1,159 @@
>>>>> +/*
>>>>> + * Copyright (C) 2016 Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org>
>>>>> + *
>>>>> + * Based on sun8i-h3-orangepi-one.dts, which is:
>>>>> + * Copyright (C) 2016 Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
>>>>> + *
>>>>> + * This file is dual-licensed: you can use it either under the terms
>>>>> + * of the GPL or the X11 license, at your option. Note that this dual
>>>>> + * licensing only applies to this file, and not this project as a
>>>>> + * whole.
>>>>> + *
>>>>> + * a) This file 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 file 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.
>>>>> + *
>>>>> + * Or, alternatively,
>>>>> + *
>>>>> + * b) Permission is hereby granted, free of charge, to any person
>>>>> + * obtaining a copy of this software and associated documentation
>>>>> + * files (the "Software"), to deal in the Software without
>>>>> + * restriction, including without limitation the rights to use,
>>>>> + * copy, modify, merge, publish, distribute, sublicense, and/or
>>>>> + * sell copies of the Software, and to permit persons to whom the
>>>>> + * Software is furnished to do so, subject to the following
>>>>> + * conditions:
>>>>> + *
>>>>> + * The above copyright notice and this permission notice shall be
>>>>> + * included in all copies or substantial portions of the Software.
>>>>> + *
>>>>> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
>>>>> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
>>>>> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
>>>>> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
>>>>> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
>>>>> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
>>>>> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
>>>>> + * OTHER DEALINGS IN THE SOFTWARE.
>>>>> + */
>>>>> +
>>>>> +/dts-v1/;
>>>>> +#include "sun8i-h3.dtsi"
>>>>> +#include "sunxi-common-regulators.dtsi"
>>>>> +
>>>>> +#include <dt-bindings/gpio/gpio.h>
>>>>> +#include <dt-bindings/input/input.h>
>>>>> +#include <dt-bindings/pinctrl/sun4i-a10.h>
>>>>> +
>>>>> +/ {
>>>>> + model = "Xunlong Orange Pi Zero";
>>>>> + compatible = "xunlong,orangepi-zero", "allwinner,sun8i-h2-plus";
>>>>> +
>>>>> + aliases {
>>>>> + serial0 = &uart0;
>>>>> + /* ethernet0 is the H3 emac, defined in sun8i-h3.dtsi */
>>>>
>>>>
>>>> It is not defined there as for:
>>>>
>>>> cef87e9 (tag: next-20161205) 20 hours ago Stephen Rothwell Add linux-next
>>>> specific files for 20161205
>>>
>>> The driver of H3's obfuscated DesignWare MAC is not yet mainlined, so there won't be one ethernet0 now.
>>>
>>> But it's reserved for the onboard Ethernet.
>>
>>
>> Could you please elaborate how you tested this patch (ideally some tree
>> somewhere on github)? This patch added RX819, it assumes EMAC support is
>> there, neither is there nor there is a way to test this... Thanks.
>
> It do not assume EMAC is there.
> It only assume EMAC will be there someday :-)
>
> For tree... wait for my push :-)
Has it happened yet? :)
--
Alexey
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* [PATCH v2 0/3] bq24735-charger: allow gpio polling and sharing
From: Peter Rosin @ 2016-12-13 23:56 UTC (permalink / raw)
To: linux-kernel
Cc: Peter Rosin, Sebastian Reichel, Rob Herring, Mark Rutland,
linux-pm, devicetree
Hi!
v1 -> v2 changes:
- use poll-interval instead of ti,poll-interval-ms in the bindings
- properly initialize the shared_lock mutex
- don't share gpios on active low/high mismatch
- don't regress users specifying the old ti,ac-detect-gpio form (without
the trailing s)
I have a board that features a couple of parallel bq24735 chargers.
However, only one of the chargers has its ACOK pin wired to a gpio,
the other parallel chargers are expected to just behave the same
as the charger that has been singled out like this. Another thing
with the board is that the gpio is not capable of generating an
interrupt.
This series fixes things for me (ok, the first patch was just a
fix for a thing that initially had me confused for a bit, and is
totally unrelated. Ignore if you want to, it's basically just churn).
One thing that I wonder about is if anything should be done to
prevent unloading of the instance that shares its gpio? I thought
about adding a device_link_add() call, but am unsure if that would
be approprite? I'm not unloading drivers at all so it's a total
non-issue for me...
Cheers,
peda
Peter Rosin (3):
power: supply: bq24735-charger: simplify register update to stop
charging
power: supply: bq24735-charger: optionally poll the ac-detect gpio
power: supply: bq24735-charger: allow chargers to share the ac-detect
gpio
.../bindings/power/supply/ti,bq24735.txt | 2 +
drivers/power/supply/bq24735-charger.c | 164 ++++++++++++++++++---
2 files changed, 148 insertions(+), 18 deletions(-)
--
2.1.4
^ permalink raw reply
* [PATCH v2 1/3] power: supply: bq24735-charger: simplify register update to stop charging
From: Peter Rosin @ 2016-12-13 23:56 UTC (permalink / raw)
To: linux-kernel
Cc: Peter Rosin, Sebastian Reichel, Rob Herring, Mark Rutland,
linux-pm, devicetree
In-Reply-To: <1481673405-4547-1-git-send-email-peda@axentia.se>
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)
--
2.1.4
^ permalink raw reply related
* [PATCH v2 2/3] power: supply: bq24735-charger: optionally poll the ac-detect gpio
From: Peter Rosin @ 2016-12-13 23:56 UTC (permalink / raw)
To: linux-kernel
Cc: Peter Rosin, Sebastian Reichel, Rob Herring, Mark Rutland,
linux-pm, devicetree
In-Reply-To: <1481673405-4547-1-git-send-email-peda@axentia.se>
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>
---
.../bindings/power/supply/ti,bq24735.txt | 2 +
drivers/power/supply/bq24735-charger.c | 50 +++++++++++++++++++---
2 files changed, 47 insertions(+), 5 deletions(-)
diff --git a/Documentation/devicetree/bindings/power/supply/ti,bq24735.txt b/Documentation/devicetree/bindings/power/supply/ti,bq24735.txt
index 3bf55757ceec..54f0004643e2 100644
--- a/Documentation/devicetree/bindings/power/supply/ti,bq24735.txt
+++ b/Documentation/devicetree/bindings/power/supply/ti,bq24735.txt
@@ -25,6 +25,8 @@ Optional properties :
- ti,external-control : Indicates that the charger is configured externally
and that the host should not attempt to enable/disable charging or set the
charge voltage/current.
+ - poll-interval : In case 'interrupts' is not specified, poll AC presense
+ on the ti,ac-detect-gpios GPIO with this interval (milliseconds).
Example:
diff --git a/drivers/power/supply/bq24735-charger.c b/drivers/power/supply/bq24735-charger.c
index 1d5c9206e0ed..f45876927676 100644
--- a/drivers/power/supply/bq24735-charger.c
+++ b/drivers/power/supply/bq24735-charger.c
@@ -50,6 +50,8 @@ struct bq24735 {
struct bq24735_platform *pdata;
struct mutex lock;
struct gpio_desc *status_gpio;
+ struct delayed_work poll;
+ u32 poll_interval;
bool charging;
};
@@ -209,11 +211,8 @@ static int bq24735_charger_is_charging(struct bq24735 *charger)
return !(ret & BQ24735_CHG_OPT_CHARGE_DISABLE);
}
-static irqreturn_t bq24735_charger_isr(int irq, void *devid)
+static void bq24735_update(struct bq24735 *charger)
{
- struct power_supply *psy = devid;
- struct bq24735 *charger = to_bq24735(psy);
-
mutex_lock(&charger->lock);
if (charger->charging && bq24735_charger_is_present(charger))
@@ -223,11 +222,29 @@ static irqreturn_t bq24735_charger_isr(int irq, void *devid)
mutex_unlock(&charger->lock);
- power_supply_changed(psy);
+ power_supply_changed(charger->charger);
+}
+
+static irqreturn_t bq24735_charger_isr(int irq, void *devid)
+{
+ struct power_supply *psy = devid;
+ struct bq24735 *charger = to_bq24735(psy);
+
+ bq24735_update(charger);
return IRQ_HANDLED;
}
+static void bq24735_poll(struct work_struct *work)
+{
+ struct bq24735 *charger = container_of(work, struct bq24735, poll.work);
+
+ bq24735_update(charger);
+
+ schedule_delayed_work(&charger->poll,
+ msecs_to_jiffies(charger->poll_interval));
+}
+
static int bq24735_charger_get_property(struct power_supply *psy,
enum power_supply_property psp,
union power_supply_propval *val)
@@ -455,11 +472,33 @@ static int bq24735_charger_probe(struct i2c_client *client,
client->irq, ret);
return ret;
}
+ } else if (charger->status_gpio) {
+ ret = of_property_read_u32(client->dev.of_node,
+ "poll-interval",
+ &charger->poll_interval);
+ if (ret)
+ return 0;
+ if (!charger->poll_interval)
+ return 0;
+
+ INIT_DELAYED_WORK(&charger->poll, bq24735_poll);
+ schedule_delayed_work(&charger->poll,
+ msecs_to_jiffies(charger->poll_interval));
}
return 0;
}
+static int bq24735_charger_remove(struct i2c_client *client)
+{
+ struct bq24735 *charger = i2c_get_clientdata(client);
+
+ if (charger->poll_interval)
+ cancel_delayed_work_sync(&charger->poll);
+
+ return 0;
+}
+
static const struct i2c_device_id bq24735_charger_id[] = {
{ "bq24735-charger", 0 },
{}
@@ -478,6 +517,7 @@ static struct i2c_driver bq24735_charger_driver = {
.of_match_table = bq24735_match_ids,
},
.probe = bq24735_charger_probe,
+ .remove = bq24735_charger_remove,
.id_table = bq24735_charger_id,
};
--
2.1.4
^ permalink raw reply related
* [PATCH v2 3/3] power: supply: bq24735-charger: allow chargers to share the ac-detect gpio
From: Peter Rosin @ 2016-12-13 23:56 UTC (permalink / raw)
To: linux-kernel
Cc: Peter Rosin, Sebastian Reichel, Rob Herring, Mark Rutland,
linux-pm, devicetree
In-Reply-To: <1481673405-4547-1-git-send-email-peda@axentia.se>
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.
However, only do this for the polling case, sharing is not supported if
the ac detection is handled with interrupts.
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
^ permalink raw reply related
* Re: [PATCH v4 3/4] powernv: Pass PSSCR value and mask to power9_idle_stop
From: Balbir Singh @ 2016-12-14 0:16 UTC (permalink / raw)
To: Gautham R. Shenoy, Michael Ellerman, Benjamin Herrenschmidt,
Paul Mackerras, Rafael J. Wysocki, Daniel Lezcano,
Michael Neuling, Vaidyanathan Srinivasan, Shreyas B. Prabhu,
Shilpasri G Bhat, Stewart Smith, Oliver O'Halloran
Cc: linuxppc-dev, linux-kernel, linux-pm, devicetree, Rob Herring,
Mark Rutland
In-Reply-To: <31b1024af69726cdf3cfb25413fc3dff28fa3547.1481288905.git.ego@linux.vnet.ibm.com>
On 10/12/16 00:32, Gautham R. Shenoy wrote:
> From: "Gautham R. Shenoy" <ego@linux.vnet.ibm.com>
>
> The power9_idle_stop method currently takes only the requested stop
> level as a parameter and picks up the rest of the PSSCR bits from a
> hand-coded macro. This is not a very flexible design, especially when
> the firmware has the capability to communicate the psscr value and the
> mask associated with a particular stop state via device tree.
>
> This patch modifies the power9_idle_stop API to take as parameters the
> PSSCR value and the PSSCR mask corresponding to the stop state that
> needs to be set. These PSSCR value and mask are respectively obtained
> by parsing the "ibm,cpu-idle-state-psscr" and
> "ibm,cpu-idle-state-psscr-mask" fields from the device tree.
>
> In addition to this, the patch adds support for handling stop states
> for which ESL and EC bits in the PSSCR are zero. As per the
> architecture, a wakeup from these stop states resumes execution from
> the subsequent instruction as opposed to waking up at the System
> Vector.
>
> The older firmware sets only the Requested Level (RL) field in the
> psscr and psscr-mask exposed in the device tree. For older firmware
> where psscr-mask=0xf, this patch will set the default sane values that
> the set for for remaining PSSCR fields (i.e PSLL, MTL, ESL, EC, and
> TR).
>
> This skiboot patch that exports fully populated PSSCR values and the
> mask for all the stop states can be found here:
> https://lists.ozlabs.org/pipermail/skiboot/2016-September/004869.html
>
> Signed-off-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
> ---
> arch/powerpc/include/asm/cpuidle.h | 41 ++++++++++++++++
> arch/powerpc/include/asm/processor.h | 3 +-
> arch/powerpc/kernel/idle_book3s.S | 31 +++++++-----
> arch/powerpc/platforms/powernv/idle.c | 81 ++++++++++++++++++++++++++------
> arch/powerpc/platforms/powernv/powernv.h | 3 +-
> arch/powerpc/platforms/powernv/smp.c | 14 +++---
> drivers/cpuidle/cpuidle-powernv.c | 40 +++++++++++-----
> 7 files changed, 169 insertions(+), 44 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/cpuidle.h b/arch/powerpc/include/asm/cpuidle.h
> index 0a3255b..fa0b6c0 100644
> --- a/arch/powerpc/include/asm/cpuidle.h
> +++ b/arch/powerpc/include/asm/cpuidle.h
> @@ -10,11 +10,52 @@
> #define PNV_CORE_IDLE_LOCK_BIT 0x100
> #define PNV_CORE_IDLE_THREAD_BITS 0x0FF
>
> +/*
> + * ============================ NOTE =================================
> + * The older firmware populates only the RL field in the psscr_val and
> + * sets the psscr_mask to 0xf. On such a firmware, the kernel sets the
> + * remaining PSSCR fields to default values as follows:
> + *
> + * - ESL and EC bits are to 1. So wakeup from any stop state will be
> + * at vector 0x100.
> + *
> + * - MTL and PSLL are set to the maximum allowed value as per the ISA,
> + * i.e. 15.
> + *
> + * - The Transition Rate, TR is set to the Maximum value 3.
> + */
> +#define PSSCR_HV_DEFAULT_VAL (PSSCR_ESL | PSSCR_EC | \
> + PSSCR_PSLL_MASK | PSSCR_TR_MASK | \
> + PSSCR_MTL_MASK)
> +
> +#define PSSCR_HV_DEFAULT_MASK (PSSCR_ESL | PSSCR_EC | \
> + PSSCR_PSLL_MASK | PSSCR_TR_MASK | \
> + PSSCR_MTL_MASK | PSSCR_RL_MASK)
> +
> #ifndef __ASSEMBLY__
> extern u32 pnv_fastsleep_workaround_at_entry[];
> extern u32 pnv_fastsleep_workaround_at_exit[];
>
> extern u64 pnv_first_deep_stop_state;
> +
> +static inline u64 compute_psscr_val(u64 psscr_val, u64 psscr_mask)
> +{
> + /*
> + * psscr_mask == 0xf indicates an older firmware.
> + * Set remaining fields of psscr to the default values.
> + * See NOTE above definition of PSSCR_HV_DEFAULT_VAL
> + */
> + if (psscr_mask == 0xf)
> + return psscr_val | PSSCR_HV_DEFAULT_VAL;
> + return psscr_val;
> +}
> +
> +static inline u64 compute_psscr_mask(u64 psscr_mask)
> +{
> + if (psscr_mask == 0xf)
> + return PSSCR_HV_DEFAULT_MASK;
> + return psscr_mask;
> +}
> #endif
>
> #endif
> diff --git a/arch/powerpc/include/asm/processor.h b/arch/powerpc/include/asm/processor.h
> index c07c31b..422becd 100644
> --- a/arch/powerpc/include/asm/processor.h
> +++ b/arch/powerpc/include/asm/processor.h
> @@ -458,7 +458,8 @@ static inline unsigned long get_clean_sp(unsigned long sp, int is_32)
> extern unsigned long power7_nap(int check_irq);
> extern unsigned long power7_sleep(void);
> extern unsigned long power7_winkle(void);
> -extern unsigned long power9_idle_stop(unsigned long stop_level);
> +extern unsigned long power9_idle_stop(unsigned long stop_psscr_val,
> + unsigned long stop_psscr_mask);
>
> extern void flush_instruction_cache(void);
> extern void hard_reset_now(void);
> diff --git a/arch/powerpc/kernel/idle_book3s.S b/arch/powerpc/kernel/idle_book3s.S
> index be90e2f..37ee533 100644
> --- a/arch/powerpc/kernel/idle_book3s.S
> +++ b/arch/powerpc/kernel/idle_book3s.S
> @@ -40,9 +40,7 @@
> #define _WORC GPR11
> #define _PTCR GPR12
>
> -#define PSSCR_HV_TEMPLATE PSSCR_ESL | PSSCR_EC | \
> - PSSCR_PSLL_MASK | PSSCR_TR_MASK | \
> - PSSCR_MTL_MASK
> +#define PSSCR_EC_ESL_MASK_SHIFTED (PSSCR_EC | PSSCR_ESL) >> 16
>
> .text
>
> @@ -264,7 +262,7 @@ enter_winkle:
> IDLE_STATE_ENTER_SEQ_NORET(PPC_WINKLE)
>
> /*
> - * r3 - requested stop state
> + * r3 - PSSCR value corresponding to the requested stop state.
> */
> power_enter_stop:
> #ifdef CONFIG_KVM_BOOK3S_HV_POSSIBLE
> @@ -274,9 +272,19 @@ power_enter_stop:
> stb r4,HSTATE_HWTHREAD_STATE(r13)
> #endif
> /*
> + * Check if we are executing the lite variant with ESL=EC=0
> + */
> + andis. r4, r3, PSSCR_EC_ESL_MASK_SHIFTED
r4 = psscr & (PSSCR_EC | PSSCR_ESL)
> + andi. r3, r3, PSSCR_RL_MASK /* r3 = requested stop state */
r3 = psscr & RL_MASK (requested mask).
Why do we do and andis. followed by andi. and a compdi below?
> + cmpdi r4, 0
r4 == 0 implies we either both PSSCR_EC|ESL are cleared.
I am not sure if our checks for EC are well defined/implemented.
Should we worry about EC at all at this point?
> + bne 1f
> + IDLE_STATE_ENTER_SEQ(PPC_STOP)
> + li r3,0 /* Since we didn't lose state, return 0 */
> + b pnv_wakeup_noloss
> +/*
> * Check if the requested state is a deep idle state.
> */
> - LOAD_REG_ADDRBASE(r5,pnv_first_deep_stop_state)
> +1: LOAD_REG_ADDRBASE(r5,pnv_first_deep_stop_state)
> ld r4,ADDROFF(pnv_first_deep_stop_state)(r5)
> cmpd r3,r4
> bge 2f
> @@ -353,16 +361,17 @@ ALT_FTR_SECTION_END_NESTED_IFSET(CPU_FTR_ARCH_207S, 66); \
> ld r3,ORIG_GPR3(r1); /* Restore original r3 */ \
> 20: nop;
>
> -
Spurious change?
> /*
> - * r3 - requested stop state
> + * r3 - The PSSCR value corresponding to the stop state.
> + * r4 - The PSSCR mask corrresonding to the stop state.
> */
> _GLOBAL(power9_idle_stop)
> - LOAD_REG_IMMEDIATE(r4, PSSCR_HV_TEMPLATE)
> - or r4,r4,r3
> - mtspr SPRN_PSSCR, r4
> - li r4, 1
> + mfspr r5, SPRN_PSSCR
> + andc r5, r5, r4
> + or r3, r3, r5
> + mtspr SPRN_PSSCR, r3
> LOAD_REG_ADDR(r5,power_enter_stop)
> + li r4, 1
> b pnv_powersave_common
> /* No return */
> /*
> diff --git a/arch/powerpc/platforms/powernv/idle.c b/arch/powerpc/platforms/powernv/idle.c
> index 479c256..663c6ef 100644
> --- a/arch/powerpc/platforms/powernv/idle.c
> +++ b/arch/powerpc/platforms/powernv/idle.c
> @@ -237,15 +237,21 @@ static DEVICE_ATTR(fastsleep_workaround_applyonce, 0600,
> show_fastsleep_workaround_applyonce,
> store_fastsleep_workaround_applyonce);
>
> +/*
> + * The default stop state that will be used by ppc_md.power_save
> + * function on platforms that support stop instruction.
> + */
> +u64 pnv_default_stop_val;
> +u64 pnv_default_stop_mask;
>
> /*
> * Used for ppc_md.power_save which needs a function with no parameters
> */
> static void power9_idle(void)
> {
> - /* Requesting stop state 0 */
> - power9_idle_stop(0);
> + power9_idle_stop(pnv_default_stop_val, pnv_default_stop_mask);
> }
> +
> /*
> * First deep stop state. Used to figure out when to save/restore
> * hypervisor context.
> @@ -253,9 +259,11 @@ static void power9_idle(void)
> u64 pnv_first_deep_stop_state = MAX_STOP_STATE;
>
> /*
> - * Deepest stop idle state. Used when a cpu is offlined
> + * psscr value and mask of the deepest stop idle state.
> + * Used when a cpu is offlined.
> */
> -u64 pnv_deepest_stop_state;
> +u64 pnv_deepest_stop_psscr_val;
> +u64 pnv_deepest_stop_psscr_mask;
>
> /*
> * Power ISA 3.0 idle initialization.
> @@ -302,28 +310,58 @@ static int __init pnv_arch300_idle_init(struct device_node *np, u32 *flags,
> int dt_idle_states)
In some cases we say power9 and arch300 in others, not related to this patchset, but just a generic comment
> {
> u64 *psscr_val = NULL;
> + u64 *psscr_mask = NULL;
> + u32 *residency_ns = NULL;
> + u64 max_residency_ns = 0;
> int rc = 0, i;
> + bool default_stop_found = false;
>
> - psscr_val = kcalloc(dt_idle_states, sizeof(*psscr_val),
> - GFP_KERNEL);
> - if (!psscr_val) {
> + psscr_val = kcalloc(dt_idle_states, sizeof(*psscr_val), GFP_KERNEL);
> + psscr_mask = kcalloc(dt_idle_states, sizeof(*psscr_mask), GFP_KERNEL);
> + residency_ns = kcalloc(dt_idle_states, sizeof(*residency_ns),
> + GFP_KERNEL);
> +
> + if (!psscr_val || !psscr_mask || !residency_ns) {
> rc = -1;
> goto out;
> }
> +
> if (of_property_read_u64_array(np,
> "ibm,cpu-idle-state-psscr",
> psscr_val, dt_idle_states)) {
> - pr_warn("cpuidle-powernv: missing ibm,cpu-idle-states-psscr in DT\n");
> + pr_warn("cpuidle-powernv: missing ibm,cpu-idle-state-psscr in DT\n");
> + rc = -1;
> + goto out;
> + }
> +
> + if (of_property_read_u64_array(np,
> + "ibm,cpu-idle-state-psscr-mask",
> + psscr_mask, dt_idle_states)) {
> + pr_warn("cpuidle-powernv: missing ibm,cpu-idle-state-psscr-mask in DT\n");
> + rc = -1;
> + goto out;
> + }
> +
> + if (of_property_read_u32_array(np,
> + "ibm,cpu-idle-state-residency-ns",
> + residency_ns, dt_idle_states)) {
> + pr_warn("cpuidle-powernv: missing ibm,cpu-idle-state-residency-ns in DT\n");
> rc = -1;
> goto out;
> }
>
> /*
> - * Set pnv_first_deep_stop_state and pnv_deepest_stop_state.
> + * Set pnv_first_deep_stop_state, pnv_deepest_stop_psscr_{val,mask},
> + * and the pnv_default_stop_{val,mask}.
> + *
> * pnv_first_deep_stop_state should be set to the first stop
> * level to cause hypervisor state loss.
> - * pnv_deepest_stop_state should be set to the deepest stop
> - * stop state.
> + *
> + * pnv_deepest_stop_{val,mask} should be set to values corresponding to
> + * the deepest stop state.
> + *
> + * pnv_default_stop_{val,mask} should be set to values corresponding to
> + * the shallowest (OPAL_PM_STOP_INST_FAST) loss-less stop state.
> */
> pnv_first_deep_stop_state = MAX_STOP_STATE;
> for (i = 0; i < dt_idle_states; i++) {
> @@ -333,12 +371,27 @@ static int __init pnv_arch300_idle_init(struct device_node *np, u32 *flags,
> (pnv_first_deep_stop_state > psscr_rl))
> pnv_first_deep_stop_state = psscr_rl;
>
> - if (pnv_deepest_stop_state < psscr_rl)
> - pnv_deepest_stop_state = psscr_rl;
> - }
> + if (max_residency_ns < residency_ns[i]) {
> + max_residency_ns = residency_ns[i];
> + pnv_deepest_stop_psscr_val =
> + compute_psscr_val(psscr_val[i], psscr_mask[i]);
> + pnv_deepest_stop_psscr_mask =
> + compute_psscr_mask(psscr_mask[i]);
> + }
>
Does it make sense to have them sorted and then use the last value from the array?
Balbir Singh
^ permalink raw reply
* [PATCH] mmc: sdhci-cadence: add SoC specific compatible string
From: Masahiro Yamada @ 2016-12-14 1:59 UTC (permalink / raw)
To: linux-mmc
Cc: Rob Herring, Adrian Hunter, Ulf Hansson, Masahiro Yamada,
devicetree, linux-kernel, Rob Herring, Mark Rutland
Add a Socionext SoC specific compatible (suggested by Rob Herring).
No SoC specific data are associated with the compatible strings for
now, but other SoC vendors may use this IP and want to differentiate
IP variants in the future.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
---
Documentation/devicetree/bindings/mmc/sdhci-cadence.txt | 6 ++++--
drivers/mmc/host/sdhci-cadence.c | 1 +
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/mmc/sdhci-cadence.txt b/Documentation/devicetree/bindings/mmc/sdhci-cadence.txt
index 750374f..de66ac0 100644
--- a/Documentation/devicetree/bindings/mmc/sdhci-cadence.txt
+++ b/Documentation/devicetree/bindings/mmc/sdhci-cadence.txt
@@ -1,7 +1,9 @@
* Cadence SD/SDIO/eMMC Host Controller
Required properties:
-- compatible: should be "cdns,sd4hc".
+- compatible: should be one of the following:
+ "cdns,sd4hc"
+ "socionext,sd4hc"
- reg: offset and length of the register set for the device.
- interrupts: a single interrupt specifier.
- clocks: phandle to the input clock.
@@ -19,7 +21,7 @@ if supported. See mmc.txt for details.
Example:
emmc: sdhci@5a000000 {
- compatible = "cdns,sd4hc";
+ compatible = "socionext,sd4hc", "cdns,sd4hc";
reg = <0x5a000000 0x400>;
interrupts = <0 78 4>;
clocks = <&clk 4>;
diff --git a/drivers/mmc/host/sdhci-cadence.c b/drivers/mmc/host/sdhci-cadence.c
index 1501cfd..66b99f7 100644
--- a/drivers/mmc/host/sdhci-cadence.c
+++ b/drivers/mmc/host/sdhci-cadence.c
@@ -262,6 +262,7 @@ static int sdhci_cdns_probe(struct platform_device *pdev)
}
static const struct of_device_id sdhci_cdns_match[] = {
+ { .compatible = "socionext,sd4hc" },
{ .compatible = "cdns,sd4hc" },
{ /* sentinel */ }
};
--
2.7.4
^ permalink raw reply related
* [PATCH v2] mmc: sdhci-cadence: add Socionext UniPhier specific compatible string
From: Masahiro Yamada @ 2016-12-14 2:10 UTC (permalink / raw)
To: linux-mmc
Cc: Rob Herring, Adrian Hunter, Ulf Hansson, Masahiro Yamada,
devicetree, linux-kernel, Rob Herring, Mark Rutland
Add a Socionext SoC specific compatible (suggested by Rob Herring).
No SoC specific data are associated with the compatible strings for
now, but other SoC vendors may use this IP and want to differentiate
IP variants in the future.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
---
Changes in v2:
- Add "uniphier" to the compatible to make it more SoC-specific
Documentation/devicetree/bindings/mmc/sdhci-cadence.txt | 6 ++++--
drivers/mmc/host/sdhci-cadence.c | 1 +
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/mmc/sdhci-cadence.txt b/Documentation/devicetree/bindings/mmc/sdhci-cadence.txt
index 750374f..c0f37cb 100644
--- a/Documentation/devicetree/bindings/mmc/sdhci-cadence.txt
+++ b/Documentation/devicetree/bindings/mmc/sdhci-cadence.txt
@@ -1,7 +1,9 @@
* Cadence SD/SDIO/eMMC Host Controller
Required properties:
-- compatible: should be "cdns,sd4hc".
+- compatible: should be one of the following:
+ "cdns,sd4hc" - default of the IP
+ "socionext,uniphier-sd4hc" - for Socionext UniPhier SoCs
- reg: offset and length of the register set for the device.
- interrupts: a single interrupt specifier.
- clocks: phandle to the input clock.
@@ -19,7 +21,7 @@ if supported. See mmc.txt for details.
Example:
emmc: sdhci@5a000000 {
- compatible = "cdns,sd4hc";
+ compatible = "socionext,uniphier-sd4hc", "cdns,sd4hc";
reg = <0x5a000000 0x400>;
interrupts = <0 78 4>;
clocks = <&clk 4>;
diff --git a/drivers/mmc/host/sdhci-cadence.c b/drivers/mmc/host/sdhci-cadence.c
index 1501cfd..4b0ecb9 100644
--- a/drivers/mmc/host/sdhci-cadence.c
+++ b/drivers/mmc/host/sdhci-cadence.c
@@ -262,6 +262,7 @@ static int sdhci_cdns_probe(struct platform_device *pdev)
}
static const struct of_device_id sdhci_cdns_match[] = {
+ { .compatible = "socionext,uniphier-sd4hc" },
{ .compatible = "cdns,sd4hc" },
{ /* sentinel */ }
};
--
2.7.4
^ permalink raw reply related
* Re: [PATCH] mmc: sdhci-cadence: add SoC specific compatible string
From: Masahiro Yamada @ 2016-12-14 2:12 UTC (permalink / raw)
To: linux-mmc
Cc: Rob Herring, Adrian Hunter, Ulf Hansson, Masahiro Yamada,
devicetree, Linux Kernel Mailing List, Rob Herring, Mark Rutland
In-Reply-To: <1481680795-15697-1-git-send-email-yamada.masahiro@socionext.com>
2016-12-14 10:59 GMT+09:00 Masahiro Yamada <yamada.masahiro@socionext.com>:
> Add a Socionext SoC specific compatible (suggested by Rob Herring).
>
> No SoC specific data are associated with the compatible strings for
> now, but other SoC vendors may use this IP and want to differentiate
> IP variants in the future.
>
> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
I thought adding SoC family name ("uniphier") would be better.
I've just sent v2.
--
Best Regards
Masahiro Yamada
^ permalink raw reply
* Re: [PATCH v5 2/2] mmc: sdhci-cadence: add Cadence SD4HC support
From: Masahiro Yamada @ 2016-12-14 2:27 UTC (permalink / raw)
To: Ulf Hansson
Cc: Rob Herring, linux-mmc, Adrian Hunter, Douglas Anderson,
devicetree@vger.kernel.org, Al Cooper, Linux Kernel Mailing List,
Stefan Wahren, Andrei Pistirica, Wolfram Sang, Mark Rutland,
Simon Horman
In-Reply-To: <CAPDyKFrejOSGVWb=gsuCixxj_OXfLfo22VwLDC_Y4scw+Se8FQ@mail.gmail.com>
Hi Ulf,
2016-12-13 16:52 GMT+09:00 Ulf Hansson <ulf.hansson@linaro.org>:
> [...]
>
>>>> +
>>>> +Optional properties:
>>>> +For eMMC configuration, supported speed modes are not indicated by the SDHCI
>>>> +Capabilities Register. Instead, the following properties should be specified
>>>> +if supported. See mmc.txt for details.
>>>> +- mmc-ddr-1_8v
>>>> +- mmc-ddr-1_2v
>>>> +- mmc-hs200-1_8v
>>>> +- mmc-hs200-1_2v
>>>> +- mmc-hs400-1_8v
>>>> +- mmc-hs400-1_2v
>>>
>>> There's now a property to override SDHCI capabilities register. Maybe
>>> you should use that instead? I'll defer to Ulf.
>>>
>>
>> I did not know this new property.
>>
>> So, now we have two ways to specify MMC speed mode capabilities
>> by only touching DT.
>
> Let me clarify a bit.
>
> The point with the new bindings is to be able to override *broken*
> SDHCI caps bits. So, not only related to the speed modes.
Right.
So my approach ([1] Add MMC mode flags directly)
basically sounds OK.
>>
>> [1] Add MMC mode flags directly, like I did.
>> [2] Use "sdhci-caps-mask" and "sdhci-caps"
>>
>>
>> The problem for [2] is that eMMC capabilities
>> do not perfectly correspond to the SDHCI capabilities register.
>>
>>
>>>> +- mmc-hs400-1_8v
>>>> +- mmc-hs400-1_2v
>>
>> If the driver sets SDHCI_QUIRK2_CAPS_BIT63_FOR_HS400,
>> we can use the bit63 of caps for specifying HS400.
>>
>> But, this is not defined in the SDHCI standard.
>> #define SDHCI_SUPPORT_HS400 0x80000000 /* Non-standard */
>>
>>
>>
>>>> +- mmc-ddr-1_8v
>>
>> For High Speed DDR, perhaps we can imply MMC_CAP_1_8V_DDR
>> from MMC_CAP_UHS_DDR50 (bit34 of caps)
>>
>> This is not supported in the current code, but
>> if this is a good idea, I can send a patch.
>>
>>
>>>> +- mmc-ddr-1_2v
>>
>> This does not have the corresponding bit, but
>> 1.2V is not commonly used, so this is not a fatal problem.
>>
>>
>>
>> What I can do at most now, is to delete the
>> Optional properties section entirely
>> so users can choose [1] or [2] as they like.
>>
>
> I think a better approach is to use the new sdhci-caps* bindings to
> mask those caps that can't be trusted. And then use the generic mmc
> bindings for speed modes instead.
>
> That should be a safer approach, right!?
Right.
But, if I know the caps register bits 63-32 are all zero,
I need not explicitly specify sdhci-caps-mask, right?
--
Best Regards
Masahiro Yamada
^ permalink raw reply
* (unknown),
From: Mr Friedrich Mayrhofer @ 2016-12-14 2:45 UTC (permalink / raw)
Good Day,
This is the second time i am sending you this mail.
I, Friedrich Mayrhofer Donate $ 1,000,000.00 to You, Email Me
personally for more details.
Regards.
Friedrich Mayrhofer
--
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 v3 1/2] dt-bindings: display: Add BOE nv101wxmn51 panel binding
From: Caesar Wang @ 2016-12-14 3:19 UTC (permalink / raw)
To: thierry.reding
Cc: devicetree, linux-kernel, dri-devel, dianders, robh+dt,
Caesar Wang
The BOE 10.1" NV101WXMN51 panel is an WXGA TFT LCD panel.
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
---
Changes in v3: None
Changes in v2: None
.../devicetree/bindings/display/panel/boe,nv101wxmn51.txt | 7 +++++++
1 file changed, 7 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/panel/boe,nv101wxmn51.txt
diff --git a/Documentation/devicetree/bindings/display/panel/boe,nv101wxmn51.txt b/Documentation/devicetree/bindings/display/panel/boe,nv101wxmn51.txt
new file mode 100644
index 0000000..b258d6a
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/boe,nv101wxmn51.txt
@@ -0,0 +1,7 @@
+BOE OPTOELECTRONICS TECHNOLOGY 10.1" WXGA TFT LCD panel
+
+Required properties:
+- compatible: should be "boe,nv101wxmn51"
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
--
2.7.4
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related
* [PATCH v3 2/2] drm/panel: simple: Add support BOE nv101wxmn51
From: Caesar Wang @ 2016-12-14 3:19 UTC (permalink / raw)
To: thierry.reding
Cc: devicetree, linux-kernel, dri-devel, dianders, robh+dt,
Caesar Wang
In-Reply-To: <1481685596-15608-1-git-send-email-wxt@rock-chips.com>
10.1WXGA is a color active matrix TFT LCD module using amorphous silicon
TFT's as an active switching devices. It can be supported by the
simple-panel driver.
Read the panel default edid information:
EDID MODE DETAILS
name = <NULL>
pixel_clock = 71900
lvds_dual_channel = 0
refresh = 0
ha = 1280
hbl = 160
hso = 48
hspw = 32
hborder = 0
va = 800
vbl = 32
vso = 3
vspw = 5
vborder = 0
phsync = +
pvsync = -
x_mm = 0
y_mm = 0
drm_display_mode
.hdisplay = 1280
.hsync_start = 1328
.hsync_end = 1360
.htotal = 1440
.vdisplay = 800
.vsync_start = 803
.vsync_end = 808
.vtotal = 832
There are two modes in the edid:
Detailed mode1: Clock 71.900 MHz, 216 mm x 135 mm
1280 1328 1360 1440 hborder 0
800 803 808 832 vborder 0
+hsync -vsync
Detailed mode2: Clock 57.500 MHz, 216 mm x 135 mm
1280 1328 1360 1440 hborder 0
800 803 808 832 vborder 0
+hsync -vsync
Add the both edid to support more modes for BOE nv101wxmn51.
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
---
Changes in v3:
- As Stéphane commented on https://patchwork.kernel.org/patch/9465911,
add downclock mode for edid.
Changes in v2:
- fix the vsync_start and vsync_end from the edid.
- change the commit.
drivers/gpu/drm/panel/panel-simple.c | 45 ++++++++++++++++++++++++++++++++++++
1 file changed, 45 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
index 06aaf79..1ce25b5 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -668,6 +668,48 @@ static const struct panel_desc avic_tm070ddh03 = {
},
};
+static const struct drm_display_mode boe_nv101wxmn51_modes[] = {
+ {
+ .clock = 71900,
+ .hdisplay = 1280,
+ .hsync_start = 1280 + 48,
+ .hsync_end = 1280 + 48 + 32,
+ .htotal = 1280 + 48 + 32 + 80,
+ .vdisplay = 800,
+ .vsync_start = 800 + 3,
+ .vsync_end = 800 + 3 + 5,
+ .vtotal = 800 + 3 + 5 + 24,
+ .vrefresh = 60,
+ },
+ {
+ .clock = 57500,
+ .hdisplay = 1280,
+ .hsync_start = 1280 + 48,
+ .hsync_end = 1280 + 48 + 32,
+ .htotal = 1280 + 48 + 32 + 80,
+ .vdisplay = 800,
+ .vsync_start = 800 + 3,
+ .vsync_end = 800 + 3 + 5,
+ .vtotal = 800 + 3 + 5 + 24,
+ .vrefresh = 48,
+ },
+};
+
+static const struct panel_desc boe_nv101wxmn51 = {
+ .modes = boe_nv101wxmn51_modes,
+ .num_modes = ARRAY_SIZE(boe_nv101wxmn51_modes),
+ .bpc = 8,
+ .size = {
+ .width = 217,
+ .height = 136,
+ },
+ .delay = {
+ .prepare = 210,
+ .enable = 50,
+ .unprepare = 160,
+ },
+};
+
static const struct drm_display_mode chunghwa_claa070wp03xg_mode = {
.clock = 66770,
.hdisplay = 800,
@@ -1748,6 +1790,9 @@ static const struct of_device_id platform_of_match[] = {
.compatible = "avic,tm070ddh03",
.data = &avic_tm070ddh03,
}, {
+ .compatible = "boe,nv101wxmn51",
+ .data = &boe_nv101wxmn51,
+ }, {
.compatible = "chunghwa,claa070wp03xg",
.data = &chunghwa_claa070wp03xg,
}, {
--
2.7.4
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related
* Re: [PATCH v7 2/5] drm: bridge: add DT bindings for TI ths8135
From: Archit Taneja @ 2016-12-14 5:04 UTC (permalink / raw)
To: Bartosz Golaszewski, Jyri Sarha, Tomi Valkeinen, David Airlie,
Kevin Hilman, Michael Turquette, Sekhar Nori, Rob Herring,
Frank Rowand, Mark Rutland, Laurent Pinchart, Peter Ujfalusi,
Russell King, Maxime Ripard
Cc: linux-devicetree, linux-drm, LKML, arm-soc
In-Reply-To: <1481623759-12786-3-git-send-email-bgolaszewski@baylibre.com>
Hi,
On 12/13/2016 03:39 PM, Bartosz Golaszewski wrote:
> THS8135 is a configurable video DAC. Add DT bindings for this chip.
Queued to drm-misc-next
>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Acked-by: Rob Herring <robh@kernel.org>
> ---
> .../bindings/display/bridge/ti,ths8135.txt | 46 ++++++++++++++++++++++
> 1 file changed, 46 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/display/bridge/ti,ths8135.txt
>
> diff --git a/Documentation/devicetree/bindings/display/bridge/ti,ths8135.txt b/Documentation/devicetree/bindings/display/bridge/ti,ths8135.txt
> new file mode 100644
> index 0000000..6ec1a88
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/ti,ths8135.txt
> @@ -0,0 +1,46 @@
> +THS8135 Video DAC
> +-----------------
> +
> +This is the binding for Texas Instruments THS8135 Video DAC bridge.
> +
> +Required properties:
> +
> +- compatible: Must be "ti,ths8135"
> +
> +Required nodes:
> +
> +This device has two video ports. Their connections are modelled using the OF
> +graph bindings specified in Documentation/devicetree/bindings/graph.txt.
> +
> +- Video port 0 for RGB input
> +- Video port 1 for VGA output
> +
> +Example
> +-------
> +
> +vga-bridge {
> + compatible = "ti,ths8135";
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> +
> + vga_bridge_in: endpoint {
> + remote-endpoint = <&lcdc_out_vga>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> +
> + vga_bridge_out: endpoint {
> + remote-endpoint = <&vga_con_in>;
> + };
> + };
> + };
> +};
>
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH v7 3/5] drm: bridge: add support for TI ths8135
From: Archit Taneja @ 2016-12-14 5:05 UTC (permalink / raw)
To: Bartosz Golaszewski, Jyri Sarha, Tomi Valkeinen, David Airlie,
Kevin Hilman, Michael Turquette, Sekhar Nori, Rob Herring,
Frank Rowand, Mark Rutland, Laurent Pinchart, Peter Ujfalusi,
Russell King, Maxime Ripard
Cc: linux-devicetree, linux-drm, LKML, arm-soc
In-Reply-To: <1481623759-12786-4-git-send-email-bgolaszewski@baylibre.com>
On 12/13/2016 03:39 PM, Bartosz Golaszewski wrote:
> THS8135 is a configurable video DAC, but no configuration is actually
> necessary to make it work.
>
> For now use the dumb-vga-dac driver to support it.
Queued to drm-misc-next
Archit
>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> ---
> drivers/gpu/drm/bridge/dumb-vga-dac.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/bridge/dumb-vga-dac.c b/drivers/gpu/drm/bridge/dumb-vga-dac.c
> index e570698..86e9f9c 100644
> --- a/drivers/gpu/drm/bridge/dumb-vga-dac.c
> +++ b/drivers/gpu/drm/bridge/dumb-vga-dac.c
> @@ -237,6 +237,7 @@ static int dumb_vga_remove(struct platform_device *pdev)
>
> static const struct of_device_id dumb_vga_match[] = {
> { .compatible = "dumb-vga-dac" },
> + { .compatible = "ti,ths8135" },
> {},
> };
> MODULE_DEVICE_TABLE(of, dumb_vga_match);
>
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* [PATCH 0/2] Add support for the S6E3HA2 panel on TM2 board
From: Hoegeun Kwon @ 2016-12-14 6:04 UTC (permalink / raw)
To: thierry.reding, kgene, krzk
Cc: devicetree, linux-samsung-soc, linux-kernel, dri-devel,
Hoegeun Kwon
Purpose of this patch is add support for S6E3HA2 AMOLED panel on
the TM2 board. The first patch adds support for S6E3HA2 panel
device tree document and driver, the second patch add support for
S6E3HA2 panel device tree.
Hoegeun Kwon (1):
drm/panel: Add support for S6E3HA2 panel driver on TM2 board
Hyungwon Hwang (1):
arm64: dts: exynos: Add support for S6E3HA2 panel device on TM2 board
.../bindings/display/panel/samsung,s6e3ha2.txt | 52 ++
arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 33 +
drivers/gpu/drm/panel/Kconfig | 6 +
drivers/gpu/drm/panel/Makefile | 1 +
drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c | 756 +++++++++++++++++++++
5 files changed, 848 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt
create mode 100644 drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
--
1.9.1
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ 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