* Re: [PATCHv3 02/10] serdev: add serdev_device_wait_until_sent
From: Greg Kroah-Hartman @ 2017-04-08 16:57 UTC (permalink / raw)
To: Sebastian Reichel
Cc: Marcel Holtmann, Gustavo Padovan, Johan Hedberg, Rob Herring,
Samuel Thibault, Pavel Machek, Tony Lindgren, Jiri Slaby,
Mark Rutland, linux-bluetooth, linux-serial, devicetree,
linux-kernel
In-Reply-To: <20170328155939.31566-3-sre@kernel.org>
On Tue, Mar 28, 2017 at 05:59:31PM +0200, Sebastian Reichel wrote:
> Add method, which waits until the transmission buffer has been sent.
> Note, that the change in ttyport_write_wakeup is related, since
> tty_wait_until_sent will hang without that change.
>
> Acked-by: Rob Herring <robh@kernel.org>
> Acked-by: Pavel Machek <pavel@ucw.cz>
> Signed-off-by: Sebastian Reichel <sre@kernel.org>
> ---
> Changes since PATCHv2:
> * Avoid goto in ttyport_write_wakeup
> ---
> drivers/tty/serdev/core.c | 11 +++++++++++
> drivers/tty/serdev/serdev-ttyport.c | 18 ++++++++++++++----
> include/linux/serdev.h | 3 +++
> 3 files changed, 28 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/tty/serdev/core.c b/drivers/tty/serdev/core.c
> index f4c6c90add78..a63b74031e22 100644
> --- a/drivers/tty/serdev/core.c
> +++ b/drivers/tty/serdev/core.c
> @@ -173,6 +173,17 @@ void serdev_device_set_flow_control(struct serdev_device *serdev, bool enable)
> }
> EXPORT_SYMBOL_GPL(serdev_device_set_flow_control);
>
> +void serdev_device_wait_until_sent(struct serdev_device *serdev, long timeout)
> +{
> + struct serdev_controller *ctrl = serdev->ctrl;
> +
> + if (!ctrl || !ctrl->ops->wait_until_sent)
> + return;
> +
> + ctrl->ops->wait_until_sent(ctrl, timeout);
> +}
> +EXPORT_SYMBOL_GPL(serdev_device_wait_until_sent);
Is this still needed now that we have serdev_device_write() with an
unlimited timeout available?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH v5 1/4] Documentation: dt-bindings: iio: Add max9611 ADC
From: jmondi @ 2017-04-08 16:45 UTC (permalink / raw)
To: Jonathan Cameron
Cc: Geert Uytterhoeven, Jacopo Mondi, Wolfram Sang, Magnus Damm,
Laurent Pinchart, Hartmut Knaack, Lars-Peter Clausen,
Peter Meerwald, Rob Herring, Mark Rutland,
linux-iio-u79uwXL29TY76Z2rM5mHXA, Linux-Renesas,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <e7a53314-2e57-ae3a-af53-0d22ab445f5a-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Hi Jonathan,
On Sat, Apr 08, 2017 at 04:59:39PM +0100, Jonathan Cameron wrote:
> On 06/04/17 15:43, Geert Uytterhoeven wrote:
>
> > On Thu, Apr 6, 2017 at 4:20 PM, Jacopo Mondi <jacopo+renesas-AW8dsiIh9cEdnm+yROfE0A@public.gmane.org> wrote:
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/iio/adc/max9611.txt
> >> @@ -0,0 +1,27 @@
> >> +* Maxim max9611/max9612 current sense amplifier with 12-bits ADC interface
> >> +
> >> +Maxim max9611/max9612 is an high-side current sense amplifier with integrated
> >> +12-bits ADC communicating over I2c bus.
> >> +The device node for this driver shall be a child of a I2c controller.
> >> +
> >> +Required properties
> >> + - compatible: Should be "maxim,max9611" or "maxim,max9612"
> >> + - reg: The 7-bits long I2c address of the device
> >> + - shunt-resistor-micro-homs: Value, in micro Ohms, of the current sense shunt
> >
> > s/homs/ohms/
> I'll fix the title as Rob requested and this.
>
Uh! I missed that title thing! Sorry about this, and thank you
Jonathan for doing that!
> Applied to the togreg branch of iio.git and pushed out as testing
> for the autobuilders to play with it.
>
> Thanks for your hard work on this one!
>
Thank you all for your effort in reviewing this
Thanks
j
> Jonathan
> >
> >> + resistor
> >
> > Gr{oetje,eeting}s,
> >
> > Geert
> >
> > --
> > Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org
> >
> > In personal conversations with technical people, I call myself a hacker. But
> > when I'm talking to journalists I just say "programmer" or something like that.
> > -- Linus Torvalds
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> > the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> >
>
--
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 1/3 v5] iio: xoadc: augment DT bindings a bit
From: Jonathan Cameron @ 2017-04-08 16:40 UTC (permalink / raw)
To: Linus Walleij, linux-iio-u79uwXL29TY76Z2rM5mHXA
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170404120819.6921-1-linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
On 04/04/17 13:08, Linus Walleij wrote:
> In order to accommodate in a logical manner for the premuxed channels
> in PM8921 and the similarly addressed channels in later PMICs, we
> need a twocell arrangement with premux and analog mux setting as
> a tuple to uniquely identify a hardware channel.
>
> These bindings are not yet in use, so it should be fine to augment
> them before we actually start using it in drivers and device trees.
>
> This scheme came out of lengthy discussions and reverse-engineering
> and reading of the few information sources we have.
>
> Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Acked-by: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Suggested-by: Björn Andersson <bjorn.andersson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> Signed-off-by: Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Applied to the togreg branch of iio.git and pushed out as testing
for the autobuilders to play with it.
Thanks,
Jonathan
> ---
> ChangeLog v3->v5:
> - Some nitpicky spelling fixes. Added Rob's ACK.
> ChangeLog v2->v3:
> - Drop leading zeroes on unit addresses.
> ChangeLog v1->v2:
> - Name nodes with <01 02> in a foo@0102 pattern.
> - Minor spelling nits.
> - Delete flimsy leftover docs from an interrim development path.
> ---
> .../bindings/iio/adc/qcom,pm8xxx-xoadc.txt | 76 ++++++++++++----------
> 1 file changed, 42 insertions(+), 34 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/iio/adc/qcom,pm8xxx-xoadc.txt b/Documentation/devicetree/bindings/iio/adc/qcom,pm8xxx-xoadc.txt
> index 53cd146d8096..3ae06127789e 100644
> --- a/Documentation/devicetree/bindings/iio/adc/qcom,pm8xxx-xoadc.txt
> +++ b/Documentation/devicetree/bindings/iio/adc/qcom,pm8xxx-xoadc.txt
> @@ -19,32 +19,42 @@ Required properties:
> with PMIC variant but is typically something like 2.2 or 1.8V.
>
> The following required properties are standard for IO channels, see
> -iio-bindings.txt for more details:
> +iio-bindings.txt for more details, but notice that this particular
> +ADC has a special addressing scheme that require two cells for
> +identifying each ADC channel:
>
> -- #address-cells: should be set to <1>
> +- #address-cells: should be set to <2>, the first cell is the
> + prescaler (on PM8058) or premux (on PM8921) with two valid bits
> + so legal values are 0x00, 0x01 or 0x02. The second cell
> + is the main analog mux setting (0x00..0x0f). The combination
> + of prescaler/premux and analog mux uniquely addresses a hardware
> + channel on all systems.
>
> - #size-cells: should be set to <0>
>
> -- #io-channel-cells: should be set to <1>
> +- #io-channel-cells: should be set to <2>, again the cells are
> + precaler or premux followed by the analog muxing line.
>
> - interrupts: should refer to the parent PMIC interrupt controller
> and reference the proper ADC interrupt.
>
> Required subnodes:
>
> -The ADC channels are configured as subnodes of the ADC. Since some of
> -them are used for calibrating the ADC, these nodes are compulsory:
> +The ADC channels are configured as subnodes of the ADC.
> +
> +Since some of them are used for calibrating the ADC, these nodes are
> +compulsory:
>
> adc-channel@c {
> - reg = <0x0c>;
> + reg = <0x00 0x0c>;
> };
>
> adc-channel@d {
> - reg = <0x0d>;
> + reg = <0x00 0x0d>;
> };
>
> adc-channel@f {
> - reg = <0x0f>;
> + reg = <0x00 0x0f>;
> };
>
> These three nodes are used for absolute and ratiometric calibration
> @@ -52,13 +62,13 @@ and only need to have these reg values: they are by hardware definition
> 1:1 ratio converters that sample 625, 1250 and 0 milliV and create
> an interpolation calibration for all other ADCs.
>
> -Optional subnodes: any channels other than channel 0x0c, 0x0d and
> -0x0f are optional.
> +Optional subnodes: any channels other than channels [0x00 0x0c],
> +[0x00 0x0d] and [0x00 0x0f] are optional.
>
> Required channel node properties:
>
> - reg: should contain the hardware channel number in the range
> - 0 .. 0x0f (4 bits). The hardware only supports 16 channels.
> + 0 .. 0xff (8 bits).
>
> Optional channel node properties:
>
> @@ -94,56 +104,54 @@ Example:
> xoadc: xoadc@197 {
> compatible = "qcom,pm8058-adc";
> reg = <0x197>;
> - interrupt-parent = <&pm8058>;
> - interrupts = <76 1>;
> - #address-cells = <1>;
> + interrupts-extended = <&pm8058 76 IRQ_TYPE_EDGE_RISING>;
> + #address-cells = <2>;
> #size-cells = <0>;
> - #io-channel-cells = <1>;
> + #io-channel-cells = <2>;
>
> vcoin: adc-channel@0 {
> - reg = <0x00>;
> + reg = <0x00 0x00>;
> };
> vbat: adc-channel@1 {
> - reg = <0x01>;
> + reg = <0x00 0x01>;
> };
> dcin: adc-channel@2 {
> - reg = <0x02>;
> + reg = <0x00 0x02>;
> };
> ichg: adc-channel@3 {
> - reg = <0x03>;
> + reg = <0x00 0x03>;
> };
> vph_pwr: adc-channel@4 {
> - reg = <0x04>;
> + reg = <0x00 0x04>;
> };
> usb_vbus: adc-channel@a {
> - reg = <0x0a>;
> + reg = <0x00 0x0a>;
> };
> die_temp: adc-channel@b {
> - reg = <0x0b>;
> + reg = <0x00 0x0b>;
> };
> ref_625mv: adc-channel@c {
> - reg = <0x0c>;
> + reg = <0x00 0x0c>;
> };
> ref_1250mv: adc-channel@d {
> - reg = <0x0d>;
> + reg = <0x00 0x0d>;
> };
> ref_325mv: adc-channel@e {
> - reg = <0x0e>;
> + reg = <0x00 0x0e>;
> };
> ref_muxoff: adc-channel@f {
> - reg = <0x0f>;
> + reg = <0x00 0x0f>;
> };
> };
>
> -
> /* IIO client node */
> iio-hwmon {
> compatible = "iio-hwmon";
> - io-channels = <&xoadc 0x01>, /* Battery */
> - <&xoadc 0x02>, /* DC in (charger) */
> - <&xoadc 0x04>, /* VPH the main system voltage */
> - <&xoadc 0x0b>, /* Die temperature */
> - <&xoadc 0x0c>, /* Reference voltage 1.25V */
> - <&xoadc 0x0d>, /* Reference voltage 0.625V */
> - <&xoadc 0x0e>; /* Reference voltage 0.325V */
> + io-channels = <&xoadc 0x00 0x01>, /* Battery */
> + <&xoadc 0x00 0x02>, /* DC in (charger) */
> + <&xoadc 0x00 0x04>, /* VPH the main system voltage */
> + <&xoadc 0x00 0x0b>, /* Die temperature */
> + <&xoadc 0x00 0x0c>, /* Reference voltage 1.25V */
> + <&xoadc 0x00 0x0d>, /* Reference voltage 0.625V */
> + <&xoadc 0x00 0x0e>; /* Reference voltage 0.325V */
> };
>
^ permalink raw reply
* Re: [PATCH v4 4/8] iio: adc: sun4i-gpadc-iio: add support for A33 thermal sensor
From: Jonathan Cameron @ 2017-04-08 16:36 UTC (permalink / raw)
To: Quentin Schulz, dmitry.torokhov, robh+dt, mark.rutland,
maxime.ripard, wens, lee.jones, linux, knaack.h, lars, pmeerw
Cc: thomas.petazzoni, devicetree, linux-iio, linux-kernel,
linux-sunxi, icenowy, linux-input, linux-arm-kernel
In-Reply-To: <20170405090634.4649-5-quentin.schulz@free-electrons.com>
On 05/04/17 10:06, Quentin Schulz wrote:
> This adds support for the Allwinner A33 thermal sensor.
>
> Unlike the A10, A13 and A31, the Allwinner A33 only has one channel
> which is dedicated to the thermal sensor. Moreover, its thermal sensor
> does not generate interruptions, thus we only need to directly read the
> register storing the temperature value.
>
> The MFD used by the A10, A13 and A31, was created to avoid breaking the
> DT binding, but since the nodes for the ADC weren't there for the A33,
> it is not needed.
>
> Though the A33 does not have an internal ADC, it has a thermal sensor
> which shares the same registers with GPADC of the already supported SoCs
> and almost the same bits, for the same purpose (thermal sensor).
>
> The thermal sensor behaves exactly the same (except the presence of
> interrupts or not) on the different SoCs.
>
> Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
> Acked-by: Lee Jones <lee.jones@linaro.org>
> Acked-by: Jonathan Cameron <jic23@kernel.org>
A small amount of fuzz turned up with a fix from Arnd for thermal
dependencies.
Applied to the togreg branch of iio.git and pushed out as testing
for the autobuilders to play with it.
Thanks,
Jonathan
> ---
>
> v3:
> - switched compatible from allwinner,sun8i-a33-gpadc-iio to
> allwinner,sun8i-a33-ths to better reflect the datasheet's name,
> - fixed the non-working if (!IS_ENABLED(THERMAL_OF)) by prefixing it with
> CONFIG,
>
> v2:
> - removed added comments in Kconfig,
> - simplified Kconfig depends on condition,
> - removed THERMAL_OF requirement for sun8i,
> - renamed sun8i_gpadc_channels to sun8i_a33_gpadc_channels,
> - renamed use_dt boolean in no_irq as it reflects better why we need it,
> - removed spurious/unneeded modifications done in v1,
>
> drivers/iio/adc/Kconfig | 2 +-
> drivers/iio/adc/sun4i-gpadc-iio.c | 100 ++++++++++++++++++++++++++++++++++++--
> include/linux/mfd/sun4i-gpadc.h | 4 ++
> 3 files changed, 102 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
> index d0af51d..d9b6101 100644
> --- a/drivers/iio/adc/Kconfig
> +++ b/drivers/iio/adc/Kconfig
> @@ -561,7 +561,7 @@ config STX104
> config SUN4I_GPADC
> tristate "Support for the Allwinner SoCs GPADC"
> depends on IIO
> - depends on MFD_SUN4I_GPADC
> + depends on MFD_SUN4I_GPADC || MACH_SUN8I
> help
> Say yes here to build support for Allwinner (A10, A13 and A31) SoCs
> GPADC. This ADC provides 4 channels which can be used as an ADC or as
> diff --git a/drivers/iio/adc/sun4i-gpadc-iio.c b/drivers/iio/adc/sun4i-gpadc-iio.c
> index 7cb997a..74705aa 100644
> --- a/drivers/iio/adc/sun4i-gpadc-iio.c
> +++ b/drivers/iio/adc/sun4i-gpadc-iio.c
> @@ -85,6 +85,12 @@ static const struct gpadc_data sun6i_gpadc_data = {
> .adc_chan_mask = SUN6I_GPADC_CTRL1_ADC_CHAN_MASK,
> };
>
> +static const struct gpadc_data sun8i_a33_gpadc_data = {
> + .temp_offset = -1662,
> + .temp_scale = 162,
> + .tp_mode_en = SUN8I_GPADC_CTRL1_CHOP_TEMP_EN,
> +};
> +
> struct sun4i_gpadc_iio {
> struct iio_dev *indio_dev;
> struct completion completion;
> @@ -96,6 +102,7 @@ struct sun4i_gpadc_iio {
> unsigned int temp_data_irq;
> atomic_t ignore_temp_data_irq;
> const struct gpadc_data *data;
> + bool no_irq;
> /* prevents concurrent reads of temperature and ADC */
> struct mutex mutex;
> };
> @@ -138,6 +145,23 @@ static const struct iio_chan_spec sun4i_gpadc_channels_no_temp[] = {
> SUN4I_GPADC_ADC_CHANNEL(3, "adc_chan3"),
> };
>
> +static const struct iio_chan_spec sun8i_a33_gpadc_channels[] = {
> + {
> + .type = IIO_TEMP,
> + .info_mask_separate = BIT(IIO_CHAN_INFO_RAW) |
> + BIT(IIO_CHAN_INFO_SCALE) |
> + BIT(IIO_CHAN_INFO_OFFSET),
> + .datasheet_name = "temp_adc",
> + },
> +};
> +
> +static const struct regmap_config sun4i_gpadc_regmap_config = {
> + .reg_bits = 32,
> + .val_bits = 32,
> + .reg_stride = 4,
> + .fast_io = true,
> +};
> +
> static int sun4i_prepare_for_irq(struct iio_dev *indio_dev, int channel,
> unsigned int irq)
> {
> @@ -247,6 +271,17 @@ static int sun4i_gpadc_temp_read(struct iio_dev *indio_dev, int *val)
> {
> struct sun4i_gpadc_iio *info = iio_priv(indio_dev);
>
> + if (info->no_irq) {
> + pm_runtime_get_sync(indio_dev->dev.parent);
> +
> + regmap_read(info->regmap, SUN4I_GPADC_TEMP_DATA, val);
> +
> + pm_runtime_mark_last_busy(indio_dev->dev.parent);
> + pm_runtime_put_autosuspend(indio_dev->dev.parent);
> +
> + return 0;
> + }
> +
> return sun4i_gpadc_read(indio_dev, 0, val, info->temp_data_irq);
> }
>
> @@ -454,6 +489,58 @@ static int sun4i_irq_init(struct platform_device *pdev, const char *name,
> return 0;
> }
>
> +static const struct of_device_id sun4i_gpadc_of_id[] = {
> + {
> + .compatible = "allwinner,sun8i-a33-ths",
> + .data = &sun8i_a33_gpadc_data,
> + },
> + { /* sentinel */ }
> +};
> +
> +static int sun4i_gpadc_probe_dt(struct platform_device *pdev,
> + struct iio_dev *indio_dev)
> +{
> + struct sun4i_gpadc_iio *info = iio_priv(indio_dev);
> + const struct of_device_id *of_dev;
> + struct thermal_zone_device *tzd;
> + struct resource *mem;
> + void __iomem *base;
> + int ret;
> +
> + of_dev = of_match_device(sun4i_gpadc_of_id, &pdev->dev);
> + if (!of_dev)
> + return -ENODEV;
> +
> + info->no_irq = true;
> + info->data = (struct gpadc_data *)of_dev->data;
> + indio_dev->num_channels = ARRAY_SIZE(sun8i_a33_gpadc_channels);
> + indio_dev->channels = sun8i_a33_gpadc_channels;
> +
> + mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + base = devm_ioremap_resource(&pdev->dev, mem);
> + if (IS_ERR(base))
> + return PTR_ERR(base);
> +
> + info->regmap = devm_regmap_init_mmio(&pdev->dev, base,
> + &sun4i_gpadc_regmap_config);
> + if (IS_ERR(info->regmap)) {
> + ret = PTR_ERR(info->regmap);
> + dev_err(&pdev->dev, "failed to init regmap: %d\n", ret);
> + return ret;
> + }
> +
> + if (!IS_ENABLED(CONFIG_THERMAL_OF))
> + return 0;
> +
> + tzd = devm_thermal_zone_of_sensor_register(&pdev->dev, 0, info,
> + &sun4i_ts_tz_ops);
> + if (IS_ERR(tzd))
> + dev_err(&pdev->dev, "could not register thermal sensor: %ld\n",
> + PTR_ERR(tzd));
> +
> + return PTR_ERR_OR_ZERO(tzd);
> +}
> +
> static int sun4i_gpadc_probe_mfd(struct platform_device *pdev,
> struct iio_dev *indio_dev)
> {
> @@ -462,6 +549,7 @@ static int sun4i_gpadc_probe_mfd(struct platform_device *pdev,
> dev_get_drvdata(pdev->dev.parent);
> int ret;
>
> + info->no_irq = false;
> info->regmap = sun4i_gpadc_dev->regmap;
>
> indio_dev->num_channels = ARRAY_SIZE(sun4i_gpadc_channels);
> @@ -561,7 +649,11 @@ static int sun4i_gpadc_probe(struct platform_device *pdev)
> indio_dev->info = &sun4i_gpadc_iio_info;
> indio_dev->modes = INDIO_DIRECT_MODE;
>
> - ret = sun4i_gpadc_probe_mfd(pdev, indio_dev);
> + if (pdev->dev.of_node)
> + ret = sun4i_gpadc_probe_dt(pdev, indio_dev);
> + else
> + ret = sun4i_gpadc_probe_mfd(pdev, indio_dev);
> +
> if (ret)
> return ret;
>
> @@ -580,7 +672,7 @@ static int sun4i_gpadc_probe(struct platform_device *pdev)
> return 0;
>
> err_map:
> - if (IS_ENABLED(CONFIG_THERMAL_OF))
> + if (!info->no_irq && IS_ENABLED(CONFIG_THERMAL_OF))
> iio_map_array_unregister(indio_dev);
>
> pm_runtime_put(&pdev->dev);
> @@ -592,10 +684,11 @@ static int sun4i_gpadc_probe(struct platform_device *pdev)
> static int sun4i_gpadc_remove(struct platform_device *pdev)
> {
> struct iio_dev *indio_dev = platform_get_drvdata(pdev);
> + struct sun4i_gpadc_iio *info = iio_priv(indio_dev);
>
> pm_runtime_put(&pdev->dev);
> pm_runtime_disable(&pdev->dev);
> - if (IS_ENABLED(CONFIG_THERMAL_OF))
> + if (!info->no_irq && IS_ENABLED(CONFIG_THERMAL_OF))
> iio_map_array_unregister(indio_dev);
>
> return 0;
> @@ -611,6 +704,7 @@ static const struct platform_device_id sun4i_gpadc_id[] = {
> static struct platform_driver sun4i_gpadc_driver = {
> .driver = {
> .name = "sun4i-gpadc-iio",
> + .of_match_table = sun4i_gpadc_of_id,
> .pm = &sun4i_gpadc_pm_ops,
> },
> .id_table = sun4i_gpadc_id,
> diff --git a/include/linux/mfd/sun4i-gpadc.h b/include/linux/mfd/sun4i-gpadc.h
> index 509e736..139872c 100644
> --- a/include/linux/mfd/sun4i-gpadc.h
> +++ b/include/linux/mfd/sun4i-gpadc.h
> @@ -38,6 +38,10 @@
> #define SUN6I_GPADC_CTRL1_ADC_CHAN_SELECT(x) (GENMASK(3, 0) & BIT(x))
> #define SUN6I_GPADC_CTRL1_ADC_CHAN_MASK GENMASK(3, 0)
>
> +/* TP_CTRL1 bits for sun8i SoCs */
> +#define SUN8I_GPADC_CTRL1_CHOP_TEMP_EN BIT(8)
> +#define SUN8I_GPADC_CTRL1_GPADC_CALI_EN BIT(7)
> +
> #define SUN4I_GPADC_CTRL2 0x08
>
> #define SUN4I_GPADC_CTRL2_TP_SENSITIVE_ADJUST(x) ((GENMASK(3, 0) & (x)) << 28)
>
^ permalink raw reply
* Re: [PATCH v3 5/9] arm, arm64: factorize common cpu capacity default code
From: Greg KH @ 2017-04-08 16:25 UTC (permalink / raw)
To: Juri Lelli
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, peterz-wEGCiKHe2LqWVfeAwA7xHQ,
vincent.guittot-QSEj5FYQhm4dnm+yROfE0A,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
linux-lFZ/pmaqli7XmaaqVzeoHQ, sudeep.holla-5wv7dgnIgG8,
lorenzo.pieralisi-5wv7dgnIgG8, catalin.marinas-5wv7dgnIgG8,
will.deacon-5wv7dgnIgG8, morten.rasmussen-5wv7dgnIgG8,
dietmar.eggemann-5wv7dgnIgG8, broonie-DgEjT+Ai2ygdnm+yROfE0A,
Russell King
In-Reply-To: <20170327131825.32134-6-juri.lelli-5wv7dgnIgG8@public.gmane.org>
On Mon, Mar 27, 2017 at 02:18:21PM +0100, Juri Lelli wrote:
> arm and arm64 share lot of code relative to parsing CPU capacity
> information from DT, using that information for appropriate scaling and
> exposing a sysfs interface for chaging such values at runtime.
>
> Factorize such code in a common place (driver/base/arch_topology.c) in
> preparation for further additions.
>
> Suggested-by: Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org>
> Suggested-by: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
> Suggested-by: Catalin Marinas <catalin.marinas-5wv7dgnIgG8@public.gmane.org>
I need some acks here from the arm maintainers before I can take this
series...
thanks,
greg k-h
--
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 v5 4/4] arm64: dts: salvator-x: Add current sense amplifiers
From: Jonathan Cameron @ 2017-04-08 16:02 UTC (permalink / raw)
To: Jacopo Mondi, geert-Td1EMuHUCqxL1ZNQvxDV9g,
wsa+renesas-jBu1N2QxHDJrcw3mvpCnnVaTQe2KTcn/,
magnus.damm-Re5JQEeQqe8AvxtiuMwx3w,
laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw, knaack.h-Mmb7MZpHnFY,
lars-Qo5EllUWu/uELgA04lAiVw, pmeerw-jW+XmwGofnusTnJN9+BGXg,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8
Cc: linux-iio-u79uwXL29TY76Z2rM5mHXA,
linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1491488454-22468-5-git-send-email-jacopo+renesas-AW8dsiIh9cEdnm+yROfE0A@public.gmane.org>
On 06/04/17 15:20, Jacopo Mondi wrote:
> Add device nodes for two Maxim max961x current sense amplifiers
> sensing VDD_08 and DVFS_08 lines.
>
> Signed-off-by: Jacopo Mondi <jacopo+renesas-AW8dsiIh9cEdnm+yROfE0A@public.gmane.org>
> Reviewed-by: Geert Uytterhoeven <geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org>
Driver now applied and should make the coming merge window easily,
so I'll assume this will head upstream via an appropriate tree.
Thanks,
Jonathan
> ---
> arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts | 18 ++++++++++++++++++
> 1 file changed, 18 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts b/arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts
> index c7f40f8..c4860a1 100644
> --- a/arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts
> +++ b/arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts
> @@ -257,6 +257,24 @@
> status = "okay";
> };
>
> +&i2c4 {
> + status = "okay";
> +
> + csa_vdd: adc@7c {
> + compatible = "maxim,max9611";
> + reg = <0x7c>;
> +
> + shunt-resistor-micro-ohms = <5000>;
> + };
> +
> + csa_dvfs: adc@7f {
> + compatible = "maxim,max9611";
> + reg = <0x7f>;
> +
> + shunt-resistor-micro-ohms = <5000>;
> + };
> +};
> +
> &wdt0 {
> timeout-sec = <60>;
> status = "okay";
>
--
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 v5 3/4] iio: adc: Add Maxim max9611 ADC driver
From: Jonathan Cameron @ 2017-04-08 16:01 UTC (permalink / raw)
To: Jacopo Mondi, geert, wsa+renesas, magnus.damm, laurent.pinchart,
knaack.h, lars, pmeerw, robh+dt, mark.rutland
Cc: linux-iio, linux-renesas-soc, devicetree
In-Reply-To: <1491488454-22468-4-git-send-email-jacopo+renesas@jmondi.org>
On 06/04/17 15:20, Jacopo Mondi wrote:
> Add iio driver for Maxim max9611 and max9612 current-sense amplifiers
> with 12-bits ADC interface.
>
> Datasheet publicly available at:
> https://datasheets.maximintegrated.com/en/ds/MAX9611-MAX9612.pdf
>
> Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
Applied to the togreg branch of iio.git and and pushed out as testing
to see if the various tests can find anything we have all missed!
Jonathan
> ---
>
> Output of iio_info on Salvator-X board for max9611 chip installed on
> VDD_0.8 lines.
> The VDD_0.8 line powers the CPU cluster and on-board RAM.
>
> iio:device0: max9611
> 5 channels found:
> voltage0: (input)
> 1 channel-specific attributes found:
> attr 0: input value: 4.085000000
> voltage1: (input)
> 3 channel-specific attributes found:
> attr 0: scale value: 14
> attr 1: offset value: 1
> attr 2: raw value: 59
> power: (input)
> 2 channel-specific attributes found:
> attr 0: shunt_resistor value: 5.000
> attr 1: input value: 663.404000000
> current: (input)
> 2 channel-specific attributes found:
> attr 0: shunt_resistor value: 5.000
> attr 1: input value: 817.000000000
> temp: (input)
> 2 channel-specific attributes found:
> attr 0: scale value: 480.076812289
> attr 1: raw value: 59
>
> The collected information represent:
>
> * voltage0 (current sense voltage) Vcsa
> voltage drop between RS+ and RS- input = 4,085 mV
> * voltage1: (common input voltage) Vcim
> voltage at RS+ input = (59 - 1) * 14 = 812 mV
> * current flowing on shunt resistor (Icsa)
> = Vcsa / Rshunt = 817 mA
> * power load on the sensed line (Pload)
> = Vcim * Icsa = 663 m
> * die temperature = (57 * 480.07) = 27360 milli Celsius
>
> ---
> drivers/iio/adc/Kconfig | 10 +
> drivers/iio/adc/Makefile | 1 +
> drivers/iio/adc/max9611.c | 585 ++++++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 596 insertions(+)
> create mode 100644 drivers/iio/adc/max9611.c
>
> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
> index dedae7a..82f2e7b8 100644
> --- a/drivers/iio/adc/Kconfig
> +++ b/drivers/iio/adc/Kconfig
> @@ -354,6 +354,16 @@ config MAX1363
> To compile this driver as a module, choose M here: the module will be
> called max1363.
>
> +config MAX9611
> + tristate "Maxim max9611/max9612 ADC driver"
> + depends on I2C
> + help
> + Say yes here to build support for Maxim max9611/max9612 current sense
> + amplifier with 12-bits ADC interface.
> +
> + To compile this driver as a module, choose M here: the module will be
> + called max9611.
> +
> config MCP320X
> tristate "Microchip Technology MCP3x01/02/04/08"
> depends on SPI
> diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
> index d001262..149f979 100644
> --- a/drivers/iio/adc/Makefile
> +++ b/drivers/iio/adc/Makefile
> @@ -34,6 +34,7 @@ obj-$(CONFIG_LTC2485) += ltc2485.o
> obj-$(CONFIG_MAX1027) += max1027.o
> obj-$(CONFIG_MAX11100) += max11100.o
> obj-$(CONFIG_MAX1363) += max1363.o
> +obj-$(CONFIG_MAX9611) += max9611.o
> obj-$(CONFIG_MCP320X) += mcp320x.o
> obj-$(CONFIG_MCP3422) += mcp3422.o
> obj-$(CONFIG_MEDIATEK_MT6577_AUXADC) += mt6577_auxadc.o
> diff --git a/drivers/iio/adc/max9611.c b/drivers/iio/adc/max9611.c
> new file mode 100644
> index 0000000..f0b47fa
> --- /dev/null
> +++ b/drivers/iio/adc/max9611.c
> @@ -0,0 +1,585 @@
> +/*
> + * iio/adc/max9611.c
> + *
> + * Maxim max9611/max9612 high side current sense amplifier with
> + * 12-bit ADC interface.
> + *
> + * Copyright (C) 2017 Jacopo Mondi
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +/*
> + * This driver supports input common-mode voltage, current-sense
> + * amplifier with programmable gains and die temperature reading from
> + * Maxim max9611/max9612.
> + *
> + * Op-amp, analog comparator, and watchdog functionalities are not
> + * supported by this driver.
> + */
> +
> +#include <linux/delay.h>
> +#include <linux/i2c.h>
> +#include <linux/iio/iio.h>
> +#include <linux/iio/sysfs.h>
> +#include <linux/module.h>
> +#include <linux/of_device.h>
> +
> +#define DRIVER_NAME "max9611"
> +
> +/* max9611 register addresses */
> +#define MAX9611_REG_CSA_DATA 0x00
> +#define MAX9611_REG_RS_DATA 0x02
> +#define MAX9611_REG_TEMP_DATA 0x08
> +#define MAX9611_REG_CTRL1 0x0a
> +#define MAX9611_REG_CTRL2 0x0b
> +
> +/* max9611 REG1 mux configuration options */
> +#define MAX9611_MUX_MASK GENMASK(3, 0)
> +#define MAX9611_MUX_SENSE_1x 0x00
> +#define MAX9611_MUX_SENSE_4x 0x01
> +#define MAX9611_MUX_SENSE_8x 0x02
> +#define MAX9611_INPUT_VOLT 0x03
> +#define MAX9611_MUX_TEMP 0x06
> +
> +/* max9611 voltage (both csa and input) helper macros */
> +#define MAX9611_VOLTAGE_SHIFT 0x04
> +#define MAX9611_VOLTAGE_RAW(_r) ((_r) >> MAX9611_VOLTAGE_SHIFT)
> +
> +/*
> + * max9611 current sense amplifier voltage output:
> + * LSB and offset values depends on selected gain (1x, 4x, 8x)
> + *
> + * GAIN LSB (nV) OFFSET (LSB steps)
> + * 1x 107500 1
> + * 4x 26880 1
> + * 8x 13440 3
> + *
> + * The complete formula to calculate current sense voltage is:
> + * (((adc_read >> 4) - offset) / ((1 / LSB) * 10^-3)
> + */
> +#define MAX9611_CSA_1X_LSB_nV 107500
> +#define MAX9611_CSA_4X_LSB_nV 26880
> +#define MAX9611_CSA_8X_LSB_nV 13440
> +
> +#define MAX9611_CSA_1X_OFFS_RAW 1
> +#define MAX9611_CSA_4X_OFFS_RAW 1
> +#define MAX9611_CSA_8X_OFFS_RAW 3
> +
> +/*
> + * max9611 common input mode (CIM): LSB is 14mV, with 14mV offset at 25 C
> + *
> + * The complete formula to calculate input common voltage is:
> + * (((adc_read >> 4) * 1000) - offset) / (1 / 14 * 1000)
> + */
> +#define MAX9611_CIM_LSB_mV 14
> +#define MAX9611_CIM_OFFSET_RAW 1
> +
> +/*
> + * max9611 temperature reading: LSB is 480 milli degrees Celsius
> + *
> + * The complete formula to calculate temperature is:
> + * ((adc_read >> 7) * 1000) / (1 / 480 * 1000)
> + */
> +#define MAX9611_TEMP_MAX_POS 0x7f80
> +#define MAX9611_TEMP_MAX_NEG 0xff80
> +#define MAX9611_TEMP_MIN_NEG 0xd980
> +#define MAX9611_TEMP_MASK GENMASK(7, 15)
> +#define MAX9611_TEMP_SHIFT 0x07
> +#define MAX9611_TEMP_RAW(_r) ((_r) >> MAX9611_TEMP_SHIFT)
> +#define MAX9611_TEMP_SCALE_NUM 1000000
> +#define MAX9611_TEMP_SCALE_DIV 2083
> +
> +struct max9611_dev {
> + struct device *dev;
> + struct i2c_client *i2c_client;
> + struct mutex lock;
> + unsigned int shunt_resistor_uohm;
> +};
> +
> +enum max9611_conf_ids {
> + CONF_SENSE_1x,
> + CONF_SENSE_4x,
> + CONF_SENSE_8x,
> + CONF_IN_VOLT,
> + CONF_TEMP,
> +};
> +
> +/**
> + * max9611_mux_conf - associate ADC mux configuration with register address
> + * where data shall be read from
> + */
> +static const unsigned int max9611_mux_conf[][2] = {
> + /* CONF_SENSE_1x */
> + { MAX9611_MUX_SENSE_1x, MAX9611_REG_CSA_DATA },
> + /* CONF_SENSE_4x */
> + { MAX9611_MUX_SENSE_4x, MAX9611_REG_CSA_DATA },
> + /* CONF_SENSE_8x */
> + { MAX9611_MUX_SENSE_8x, MAX9611_REG_CSA_DATA },
> + /* CONF_IN_VOLT */
> + { MAX9611_INPUT_VOLT, MAX9611_REG_RS_DATA },
> + /* CONF_TEMP */
> + { MAX9611_MUX_TEMP, MAX9611_REG_TEMP_DATA },
> +};
> +
> +enum max9611_csa_gain {
> + CSA_GAIN_1x,
> + CSA_GAIN_4x,
> + CSA_GAIN_8x,
> +};
> +
> +enum max9611_csa_gain_params {
> + CSA_GAIN_LSB_nV,
> + CSA_GAIN_OFFS_RAW,
> +};
> +
> +/**
> + * max9611_csa_gain_conf - associate gain multiplier with LSB and
> + * offset values.
> + *
> + * Group together parameters associated with configurable gain
> + * on current sense amplifier path to ADC interface.
> + * Current sense read routine adjusts gain until it gets a meaningful
> + * value; use this structure to retrieve the correct LSB and offset values.
> + */
> +static const unsigned int max9611_gain_conf[][2] = {
> + { /* [0] CSA_GAIN_1x */
> + MAX9611_CSA_1X_LSB_nV,
> + MAX9611_CSA_1X_OFFS_RAW,
> + },
> + { /* [1] CSA_GAIN_4x */
> + MAX9611_CSA_4X_LSB_nV,
> + MAX9611_CSA_4X_OFFS_RAW,
> + },
> + { /* [2] CSA_GAIN_8x */
> + MAX9611_CSA_8X_LSB_nV,
> + MAX9611_CSA_8X_OFFS_RAW,
> + },
> +};
> +
> +enum max9611_chan_addrs {
> + MAX9611_CHAN_VOLTAGE_INPUT,
> + MAX9611_CHAN_VOLTAGE_SENSE,
> + MAX9611_CHAN_TEMPERATURE,
> + MAX9611_CHAN_CURRENT_LOAD,
> + MAX9611_CHAN_POWER_LOAD,
> +};
> +
> +static const struct iio_chan_spec max9611_channels[] = {
> + {
> + .type = IIO_TEMP,
> + .info_mask_separate = BIT(IIO_CHAN_INFO_RAW) |
> + BIT(IIO_CHAN_INFO_SCALE),
> + .address = MAX9611_CHAN_TEMPERATURE,
> + },
> + {
> + .type = IIO_VOLTAGE,
> + .info_mask_separate = BIT(IIO_CHAN_INFO_PROCESSED),
> + .address = MAX9611_CHAN_VOLTAGE_SENSE,
> + .indexed = 1,
> + .channel = 0,
> + },
> + {
> + .type = IIO_VOLTAGE,
> + .info_mask_separate = BIT(IIO_CHAN_INFO_RAW) |
> + BIT(IIO_CHAN_INFO_SCALE) |
> + BIT(IIO_CHAN_INFO_OFFSET),
> + .address = MAX9611_CHAN_VOLTAGE_INPUT,
> + .indexed = 1,
> + .channel = 1,
> + },
> + {
> + .type = IIO_CURRENT,
> + .info_mask_separate = BIT(IIO_CHAN_INFO_PROCESSED),
> + .address = MAX9611_CHAN_CURRENT_LOAD,
> + },
> + {
> + .type = IIO_POWER,
> + .info_mask_separate = BIT(IIO_CHAN_INFO_PROCESSED),
> + .address = MAX9611_CHAN_POWER_LOAD
> + },
> +};
> +
> +/**
> + * max9611_read_single() - read a single value from ADC interface
> + *
> + * Data registers are 16 bit long, spread between two 8 bit registers
> + * with consecutive addresses.
> + * Configure ADC mux first, then read register at address "reg_addr".
> + * The smbus_read_word routine asks for 16 bits and the ADC is kind enough
> + * to return values from "reg_addr" and "reg_addr + 1" consecutively.
> + * Data are transmitted with big-endian ordering: MSB arrives first.
> + *
> + * @max9611: max9611 device
> + * @selector: index for mux and register configuration
> + * @raw_val: the value returned from ADC
> + */
> +static int max9611_read_single(struct max9611_dev *max9611,
> + enum max9611_conf_ids selector,
> + u16 *raw_val)
> +{
> + int ret;
> +
> + u8 mux_conf = max9611_mux_conf[selector][0] & MAX9611_MUX_MASK;
> + u8 reg_addr = max9611_mux_conf[selector][1];
> +
> + /*
> + * Keep mutex lock held during read-write to avoid mux register
> + * (CTRL1) re-configuration.
> + */
> + mutex_lock(&max9611->lock);
> + ret = i2c_smbus_write_byte_data(max9611->i2c_client,
> + MAX9611_REG_CTRL1, mux_conf);
> + if (ret) {
> + dev_err(max9611->dev, "i2c write byte failed: 0x%2x - 0x%2x\n",
> + MAX9611_REG_CTRL1, mux_conf);
> + mutex_unlock(&max9611->lock);
> + return ret;
> + }
> +
> + /*
> + * need a delay here to make register configuration
> + * stabilize. 1 msec at least, from empirical testing.
> + */
> + usleep_range(1000, 2000);
> +
> + ret = i2c_smbus_read_word_swapped(max9611->i2c_client, reg_addr);
> + if (ret < 0) {
> + dev_err(max9611->dev, "i2c read word from 0x%2x failed\n",
> + reg_addr);
> + mutex_unlock(&max9611->lock);
> + return ret;
> + }
> +
> + *raw_val = ret;
> + mutex_unlock(&max9611->lock);
> +
> + return 0;
> +}
> +
> +/**
> + * max9611_read_csa_voltage() - read current sense amplifier output voltage
> + *
> + * Current sense amplifier output voltage is read through a configurable
> + * 1x, 4x or 8x gain.
> + * Start with plain 1x gain, and adjust gain control properly until a
> + * meaningful value is read from ADC output.
> + *
> + * @max9611: max9611 device
> + * @adc_raw: raw value read from ADC output
> + * @csa_gain: gain configuration option selector
> + */
> +static int max9611_read_csa_voltage(struct max9611_dev *max9611,
> + u16 *adc_raw,
> + enum max9611_csa_gain *csa_gain)
> +{
> + enum max9611_conf_ids gain_selectors[] = {
> + CONF_SENSE_1x,
> + CONF_SENSE_4x,
> + CONF_SENSE_8x
> + };
> + unsigned int i;
> + int ret;
> +
> + for (i = 0; i < ARRAY_SIZE(gain_selectors); ++i) {
> + ret = max9611_read_single(max9611, gain_selectors[i], adc_raw);
> + if (ret)
> + return ret;
> +
> + if (*adc_raw > 0) {
> + *csa_gain = gain_selectors[i];
> + return 0;
> + }
> + }
> +
> + return -EIO;
> +}
> +
> +static int max9611_read_raw(struct iio_dev *indio_dev,
> + struct iio_chan_spec const *chan,
> + int *val, int *val2, long mask)
> +{
> + struct max9611_dev *dev = iio_priv(indio_dev);
> + enum max9611_csa_gain gain_selector;
> + const unsigned int *csa_gain;
> + u16 adc_data;
> + int ret;
> +
> + switch (mask) {
> + case IIO_CHAN_INFO_RAW:
> +
> + switch (chan->address) {
> + case MAX9611_CHAN_TEMPERATURE:
> + ret = max9611_read_single(dev, CONF_TEMP,
> + &adc_data);
> + if (ret)
> + return -EINVAL;
> +
> + *val = MAX9611_TEMP_RAW(adc_data);
> + return IIO_VAL_INT;
> +
> + case MAX9611_CHAN_VOLTAGE_INPUT:
> + ret = max9611_read_single(dev, CONF_IN_VOLT,
> + &adc_data);
> + if (ret)
> + return -EINVAL;
> +
> + *val = MAX9611_VOLTAGE_RAW(adc_data);
> + return IIO_VAL_INT;
> + }
> +
> + break;
> +
> + case IIO_CHAN_INFO_OFFSET:
> + /* MAX9611_CHAN_VOLTAGE_INPUT */
> + *val = MAX9611_CIM_OFFSET_RAW;
> +
> + return IIO_VAL_INT;
> +
> + case IIO_CHAN_INFO_SCALE:
> +
> + switch (chan->address) {
> + case MAX9611_CHAN_TEMPERATURE:
> + *val = MAX9611_TEMP_SCALE_NUM;
> + *val2 = MAX9611_TEMP_SCALE_DIV;
> +
> + return IIO_VAL_FRACTIONAL;
> +
> + case MAX9611_CHAN_VOLTAGE_INPUT:
> + *val = MAX9611_CIM_LSB_mV;
> +
> + return IIO_VAL_INT;
> + }
> +
> + break;
> +
> + case IIO_CHAN_INFO_PROCESSED:
> +
> + switch (chan->address) {
> + case MAX9611_CHAN_VOLTAGE_SENSE:
> + /*
> + * processed (mV): (raw - offset) * LSB (nV) / 10^6
> + *
> + * Even if max9611 can output raw csa voltage readings,
> + * use a produced value as scale depends on gain.
> + */
> + ret = max9611_read_csa_voltage(dev, &adc_data,
> + &gain_selector);
> + if (ret)
> + return -EINVAL;
> +
> + csa_gain = max9611_gain_conf[gain_selector];
> +
> + adc_data -= csa_gain[CSA_GAIN_OFFS_RAW];
> + *val = MAX9611_VOLTAGE_RAW(adc_data) *
> + csa_gain[CSA_GAIN_LSB_nV];
> + *val2 = 1000000;
> +
> + return IIO_VAL_FRACTIONAL;
> +
> + case MAX9611_CHAN_CURRENT_LOAD:
> + /* processed (mA): Vcsa (nV) / Rshunt (uOhm) */
> + ret = max9611_read_csa_voltage(dev, &adc_data,
> + &gain_selector);
> + if (ret)
> + return -EINVAL;
> +
> + csa_gain = max9611_gain_conf[gain_selector];
> +
> + adc_data -= csa_gain[CSA_GAIN_OFFS_RAW];
> + *val = MAX9611_VOLTAGE_RAW(adc_data) *
> + csa_gain[CSA_GAIN_LSB_nV];
> + *val2 = dev->shunt_resistor_uohm;
> +
> + return IIO_VAL_FRACTIONAL;
> +
> + case MAX9611_CHAN_POWER_LOAD:
> + /*
> + * processed (mW): Vin (mV) * Vcsa (uV) /
> + * Rshunt (uOhm)
> + */
> + ret = max9611_read_single(dev, CONF_IN_VOLT,
> + &adc_data);
> + if (ret)
> + return -EINVAL;
> +
> + adc_data -= MAX9611_CIM_OFFSET_RAW;
> + *val = MAX9611_VOLTAGE_RAW(adc_data) *
> + MAX9611_CIM_LSB_mV;
> +
> + ret = max9611_read_csa_voltage(dev, &adc_data,
> + &gain_selector);
> + if (ret)
> + return -EINVAL;
> +
> + csa_gain = max9611_gain_conf[gain_selector];
> +
> + /* divide by 10^3 here to avoid 32bit overflow */
> + adc_data -= csa_gain[CSA_GAIN_OFFS_RAW];
> + *val *= MAX9611_VOLTAGE_RAW(adc_data) *
> + csa_gain[CSA_GAIN_LSB_nV] / 1000;
> + *val2 = dev->shunt_resistor_uohm;
> +
> + return IIO_VAL_FRACTIONAL;
> + }
> +
> + break;
> + }
> +
> + return -EINVAL;
> +}
> +
> +static ssize_t max9611_shunt_resistor_show(struct device *dev,
> + struct device_attribute *attr,
> + char *buf)
> +{
> + struct max9611_dev *max9611 = iio_priv(dev_to_iio_dev(dev));
> + unsigned int i, r;
> +
> + i = max9611->shunt_resistor_uohm / 1000;
> + r = max9611->shunt_resistor_uohm % 1000;
> +
> + return sprintf(buf, "%u.%03u\n", i, r);
> +}
> +
> +static IIO_DEVICE_ATTR(in_power_shunt_resistor, 0444,
> + max9611_shunt_resistor_show, NULL, 0);
> +static IIO_DEVICE_ATTR(in_current_shunt_resistor, 0444,
> + max9611_shunt_resistor_show, NULL, 0);
> +
> +static struct attribute *max9611_attributes[] = {
> + &iio_dev_attr_in_power_shunt_resistor.dev_attr.attr,
> + &iio_dev_attr_in_current_shunt_resistor.dev_attr.attr,
> + NULL,
> +};
> +
> +static const struct attribute_group max9611_attribute_group = {
> + .attrs = max9611_attributes,
> +};
> +
> +static const struct iio_info indio_info = {
> + .driver_module = THIS_MODULE,
> + .read_raw = max9611_read_raw,
> + .attrs = &max9611_attribute_group,
> +};
> +
> +static int max9611_init(struct max9611_dev *max9611)
> +{
> + struct i2c_client *client = max9611->i2c_client;
> + u16 regval;
> + int ret;
> +
> + if (!i2c_check_functionality(client->adapter,
> + I2C_FUNC_SMBUS_WRITE_BYTE |
> + I2C_FUNC_SMBUS_READ_WORD_DATA)) {
> + dev_err(max9611->dev,
> + "I2c adapter does not support smbus write_byte or read_word functionalities: aborting probe.\n");
> + return -EINVAL;
> + }
> +
> + /* Make sure die temperature is in range to test communications. */
> + ret = max9611_read_single(max9611, CONF_TEMP, ®val);
> + if (ret)
> + return ret;
> +
> + regval = ret & MAX9611_TEMP_MASK;
> +
> + if ((regval > MAX9611_TEMP_MAX_POS &&
> + regval < MAX9611_TEMP_MIN_NEG) ||
> + regval > MAX9611_TEMP_MAX_NEG) {
> + dev_err(max9611->dev,
> + "Invalid value received from ADC 0x%4x: aborting\n",
> + regval);
> + return -EIO;
> + }
> +
> + /* Mux shall be zeroed back before applying other configurations */
> + ret = i2c_smbus_write_byte_data(max9611->i2c_client,
> + MAX9611_REG_CTRL1, 0);
> + if (ret) {
> + dev_err(max9611->dev, "i2c write byte failed: 0x%2x - 0x%2x\n",
> + MAX9611_REG_CTRL1, 0);
> + return ret;
> + }
> +
> + ret = i2c_smbus_write_byte_data(max9611->i2c_client,
> + MAX9611_REG_CTRL2, 0);
> + if (ret) {
> + dev_err(max9611->dev, "i2c write byte failed: 0x%2x - 0x%2x\n",
> + MAX9611_REG_CTRL2, 0);
> + return ret;
> + }
> + usleep_range(1000, 2000);
> +
> + return 0;
> +}
> +
> +static const struct of_device_id max9611_of_table[] = {
> + {.compatible = "maxim,max9611", .data = "max9611"},
> + {.compatible = "maxim,max9612", .data = "max9612"},
> + { },
> +};
> +
> +MODULE_DEVICE_TABLE(of, max9611_of_table);
> +static int max9611_probe(struct i2c_client *client,
> + const struct i2c_device_id *id)
> +{
> + const char * const shunt_res_prop = "shunt-resistor-micro-ohms";
> + const struct device_node *of_node = client->dev.of_node;
> + const struct of_device_id *of_id =
> + of_match_device(max9611_of_table, &client->dev);
> + struct max9611_dev *max9611;
> + struct iio_dev *indio_dev;
> + unsigned int of_shunt;
> + int ret;
> +
> + indio_dev = devm_iio_device_alloc(&client->dev, sizeof(*max9611));
> + if (IS_ERR(indio_dev))
> + return PTR_ERR(indio_dev);
> +
> + i2c_set_clientdata(client, indio_dev);
> +
> + max9611 = iio_priv(indio_dev);
> + max9611->dev = &client->dev;
> + max9611->i2c_client = client;
> + mutex_init(&max9611->lock);
> +
> + ret = of_property_read_u32(of_node, shunt_res_prop, &of_shunt);
> + if (ret) {
> + dev_err(&client->dev,
> + "Missing %s property for %s node\n",
> + shunt_res_prop, of_node->full_name);
> + return ret;
> + }
> + max9611->shunt_resistor_uohm = of_shunt;
> +
> + ret = max9611_init(max9611);
> + if (ret)
> + return ret;
> +
> + indio_dev->dev.parent = &client->dev;
> + indio_dev->dev.of_node = client->dev.of_node;
> + indio_dev->name = of_id->data;
> + indio_dev->modes = INDIO_DIRECT_MODE;
> + indio_dev->info = &indio_info;
> + indio_dev->channels = max9611_channels;
> + indio_dev->num_channels = ARRAY_SIZE(max9611_channels);
> +
> + return devm_iio_device_register(&client->dev, indio_dev);
> +}
> +
> +static struct i2c_driver max9611_driver = {
> + .driver = {
> + .name = DRIVER_NAME,
> + .owner = THIS_MODULE,
> + .of_match_table = max9611_of_table,
> + },
> + .probe = max9611_probe,
> +};
> +module_i2c_driver(max9611_driver);
> +
> +MODULE_AUTHOR("Jacopo Mondi <jacopo+renesas@jmondi.org>");
> +MODULE_DESCRIPTION("Maxim max9611/12 current sense amplifier with 12bit ADC");
> +MODULE_LICENSE("GPL v2");
> --
> 2.7.4
>
^ permalink raw reply
* Re: [PATCH v5 2/4] iio: Documentation: Add max9611 sysfs documentation
From: Jonathan Cameron @ 2017-04-08 16:00 UTC (permalink / raw)
To: Jacopo Mondi, geert-Td1EMuHUCqxL1ZNQvxDV9g,
wsa+renesas-jBu1N2QxHDJrcw3mvpCnnVaTQe2KTcn/,
magnus.damm-Re5JQEeQqe8AvxtiuMwx3w,
laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw, knaack.h-Mmb7MZpHnFY,
lars-Qo5EllUWu/uELgA04lAiVw, pmeerw-jW+XmwGofnusTnJN9+BGXg,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8
Cc: linux-iio-u79uwXL29TY76Z2rM5mHXA,
linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1491488454-22468-3-git-send-email-jacopo+renesas-AW8dsiIh9cEdnm+yROfE0A@public.gmane.org>
On 06/04/17 15:20, Jacopo Mondi wrote:
> Add documentation for max9611 driver.
> Document attributes describing value of shunt resistor installed between
> RS+ and RS- voltage sense inputs.
>
> Signed-off-by: Jacopo Mondi <jacopo+renesas-AW8dsiIh9cEdnm+yROfE0A@public.gmane.org>
Looks good to me. There is the small matter that when we generalize this
we will probably loose some detail, but such is life.
Applied to the togreg branch of iio.git and pushed out as testing.
Thanks,
Jonathan
> ---
> Documentation/ABI/testing/sysfs-bus-iio-adc-max9611 | 17 +++++++++++++++++
> 1 file changed, 17 insertions(+)
> create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-adc-max9611
>
> diff --git a/Documentation/ABI/testing/sysfs-bus-iio-adc-max9611 b/Documentation/ABI/testing/sysfs-bus-iio-adc-max9611
> new file mode 100644
> index 0000000..6d2d2b0
> --- /dev/null
> +++ b/Documentation/ABI/testing/sysfs-bus-iio-adc-max9611
> @@ -0,0 +1,17 @@
> +What: /sys/bus/iio/devices/iio:deviceX/in_power_shunt_resistor
> +Date: March 2017
> +KernelVersion: 4.12
> +Contact: linux-iio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> +Description: The value of the shunt resistor used to compute power drain on
> + common input voltage pin (RS+). In Ohms.
> +
> +What: /sys/bus/iio/devices/iio:deviceX/in_current_shunt_resistor
> +Date: March 2017
> +KernelVersion: 4.12
> +Contact: linux-iio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> +Description: The value of the shunt resistor used to compute current flowing
> + between RS+ and RS- voltage sense inputs. In Ohms.
> +
> +These attributes describe a single physical component, exposed as two distinct
> +attributes as it is used to calculate two different values: power load and
> +current flowing between RS+ and RS- inputs.
>
^ permalink raw reply
* Re: [PATCH v5 1/4] Documentation: dt-bindings: iio: Add max9611 ADC
From: Jonathan Cameron @ 2017-04-08 15:59 UTC (permalink / raw)
To: Geert Uytterhoeven, Jacopo Mondi
Cc: Wolfram Sang, Magnus Damm, Laurent Pinchart, Hartmut Knaack,
Lars-Peter Clausen, Peter Meerwald, Rob Herring, Mark Rutland,
linux-iio-u79uwXL29TY76Z2rM5mHXA, Linux-Renesas,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <CAMuHMdUNWJ2C9b9Xzod5HRU_ZG3mVamN6a-ZdOywODJqv6TxQw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 06/04/17 15:43, Geert Uytterhoeven wrote:
> On Thu, Apr 6, 2017 at 4:20 PM, Jacopo Mondi <jacopo+renesas-AW8dsiIh9cEdnm+yROfE0A@public.gmane.org> wrote:
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/iio/adc/max9611.txt
>> @@ -0,0 +1,27 @@
>> +* Maxim max9611/max9612 current sense amplifier with 12-bits ADC interface
>> +
>> +Maxim max9611/max9612 is an high-side current sense amplifier with integrated
>> +12-bits ADC communicating over I2c bus.
>> +The device node for this driver shall be a child of a I2c controller.
>> +
>> +Required properties
>> + - compatible: Should be "maxim,max9611" or "maxim,max9612"
>> + - reg: The 7-bits long I2c address of the device
>> + - shunt-resistor-micro-homs: Value, in micro Ohms, of the current sense shunt
>
> s/homs/ohms/
I'll fix the title as Rob requested and this.
Applied to the togreg branch of iio.git and pushed out as testing
for the autobuilders to play with it.
Thanks for your hard work on this one!
Jonathan
>
>> + resistor
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
> -- Linus Torvalds
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" 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 1/2] leds: Add driver for Qualcomm LPG
From: Pavel Machek @ 2017-04-08 13:39 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Jacek Anaszewski, Rob Herring, Richard Purdie, linux-kernel,
linux-leds, linux-arm-msm, Mark Rutland, devicetree
In-Reply-To: <20170407202603.GC15143@minitux>
[-- Attachment #1: Type: text/plain, Size: 2306 bytes --]
Hi!
> [..]
> > > For the patterns I don't know how a trigger for this would look like,
> > > how would setting the pattern of a trigger be propagated down to the
> > > hardware?
> >
> > We'd need a new op and API similar to blink_set()/led_blink_set().
> >
>
> I've tried to find different LED circuits with some sort of pattern
> generator in an attempt to figure out how to design this interface, but
> turned out to be quite hard to find examples; the three I can compare
> are:
>
> * LP5xx series "implements" pattern generation by executing code.
>
> * Qualcomm LPG iterates over 2-64 brightness-values in a pattern, at a
> fixed rate with knobs to configure what happens before starting and
> after finishing iterating over the defined values. It does not support
> smooth transitions between values.
>
> * AS3676 supports a pattern of 32 values controlling if the output
> should be enabled or disabled for each 32.5ms (or 250ms) time period.
> The delay before repeating the pattern can be configured. It support
> smooth transitions between the states.
>
>
> So, while I think I see how you would like to architect this interface I
> am not sure how to figure out the details.
>
> The pattern definition would have to be expressive enough to support the
> features of LP5xx and direct enough to support the limited AS3676. It
> would likely have to express transitions, so that the LPG could generate
> intermediate steps (and we will have to adapt the resolution of the
> ramps based on the other LPGs in the system).
>
> How do we do with patterns that are implementable by the LP5xx but are
> not with the LPG? Should we reject those or should we do some sort of
> best-effort approach in the kernel?
Lets say you get series of
(red, green, blue, delta_t )
points, meaning "in delta_t msec, change color to red, green,
blue. Lets ignore other channels for now. delta_t of 0 would be step
change. Would such interface work for you?
Simple compiler from this to LP5XX code should not be hard to
do. AS3676 ... I'm not sure what to do, AFAICT it is too limited.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: [PATCH 0/4] arm64: renesas: enable M3ULCB board peripherals
From: Simon Horman @ 2017-04-08 13:18 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Vladimir Barinov, Magnus Damm, Rob Herring, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Linux-Renesas,
Sjoerd Simons
In-Reply-To: <20170407135212.GA24096-/R6kz+dDXgpPR4JQBCEnsQ@public.gmane.org>
On Fri, Apr 07, 2017 at 09:52:13AM -0400, Simon Horman wrote:
> On Thu, Apr 06, 2017 at 11:53:45AM +0200, Geert Uytterhoeven wrote:
> > Hi Simon,
> >
> > On Fri, Mar 17, 2017 at 11:02 PM, Sjoerd Simons
> > <sjoerd.simons-ZGY8ohtN/8pPYcu2f3hruQ@public.gmane.org> wrote:
> > > On Thu, 2017-01-26 at 17:53 +0300, Vladimir Barinov wrote:
> > >> This adds the folowing:
> > >> - R8A7796 SoC based M3ULCB board peripherals
> > >>
> > >> Vladimir Barinov (4):
> > >> [1/4] arm64: dts: m3ulcb: enable I2C
> > >> [2/4] arm64: dts: m3ulcb: Update memory node to 2 GiB map
>
> I have queued up the above two patches.
> > >> [3/4] arm64: dts: m3ulcb: enable EthernetAVB
>
> Please update the above patch to reflect the changes made in
> ef3f08c83fd1 ("arm64: dts: r8a7796: salvator-x: Fix EthernetAVB PHY timing")
>
> > >> [4/4] arm64: dts: m3ulcb: enable HS200 for eMMC
>
> I will look at queuing this up in the near future
> with other HS200 enablement patches.
I have now done so; patches 1,2,4 are queued up for v4.13.
--
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 2/6] dma: pl08x: Add Faraday FTDMAC020 to compatible list
From: Linus Walleij @ 2017-04-08 12:04 UTC (permalink / raw)
To: Vinod Koul, dmaengine-u79uwXL29TY76Z2rM5mHXA
Cc: Janos Laube, Paulius Zaleckas,
openwrt-devel-p3rKhJxN3npAfugRpC6u6w,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Hans Ulli Kroll, Florian Fainelli, Kuo-Jung Su, Linus Walleij,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170408120457.22750-1-linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
This augments the PL08x bindings to include the Faraday Technology
FTDMAC020 DMA engine, as it is clearly a derivative of the PL08x
PrimeCell. Also specify that it needs the special peripheral ID
specified to work properly.
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Signed-off-by: Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
---
Seeking a DT maintainer ACK on this.
---
Documentation/devicetree/bindings/dma/arm-pl08x.txt | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/dma/arm-pl08x.txt b/Documentation/devicetree/bindings/dma/arm-pl08x.txt
index 8a0097a029d3..0ba81f79266f 100644
--- a/Documentation/devicetree/bindings/dma/arm-pl08x.txt
+++ b/Documentation/devicetree/bindings/dma/arm-pl08x.txt
@@ -3,6 +3,11 @@
Required properties:
- compatible: "arm,pl080", "arm,primecell";
"arm,pl081", "arm,primecell";
+ "faraday,ftdmac020", "arm,primecell"
+- arm,primecell-periphid: on the FTDMAC020 the primecell ID is not hard-coded
+ in the hardware and must be specified here as <0x0003b080>. This number
+ follows the PrimeCell standard numbering using the JEP106 vendor code 0x38
+ for Faraday Technology.
- reg: Address range of the PL08x registers
- interrupt: The PL08x interrupt number
- clocks: The clock running the IP core clock
@@ -20,8 +25,8 @@ Optional properties:
- dma-requests: contains the total number of DMA requests supported by the DMAC
- memcpy-burst-size: the size of the bursts for memcpy: 1, 4, 8, 16, 32
64, 128 or 256 bytes are legal values
-- memcpy-bus-width: the bus width used for memcpy: 8, 16 or 32 are legal
- values
+- memcpy-bus-width: the bus width used for memcpy in bits: 8, 16 or 32 are legal
+ values, the Faraday FTDMAC020 can also accept 64 bits
Clients
Required properties:
--
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 related
* I expect your urgent communication.
From: Mr. Mudi Feez @ 2017-04-08 11:39 UTC (permalink / raw)
--
Dear Friend,
Good day. I am Mr. Mudi Feez. I am working with one of the prime banks
in Burkina Faso. I have decided to contact you for a financial
transaction which values $14,500,000.00 (Fourteen Million Five Hundred
Thousand USA Dollars). This is an abandoned fund that belongs to a
late foreign customer of our bank. I want a foreign account where the
bank will transfer this fund.
I was very fortunate to come across the deceased customer's security
file; during documentation of old and abandoned customers files for an
official re-documentation and audit of the year 2017.
If you are really sure of your trustworthiness, accountability and
confidentiality over this transaction, contact me urgently. I will let
you know the next step and procedure to follow in order to finalize
this transaction successfully.
I expect your urgent communication.
Yours sincerely,
Mr. Mudi Feez
--
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
* I expect your urgent communication.
From: Mr. Mudi Feez @ 2017-04-08 11:11 UTC (permalink / raw)
--
Dear Friend,
Good day. I am Mr. Mudi Feez. I am working with one of the prime banks
in Burkina Faso. I have decided to contact you for a financial
transaction which values $14,500,000.00 (Fourteen Million Five Hundred
Thousand USA Dollars). This is an abandoned fund that belongs to a
late foreign customer of our bank. I want a foreign account where the
bank will transfer this fund.
I was very fortunate to come across the deceased customer's security
file; during documentation of old and abandoned customers files for an
official re-documentation and audit of the year 2017.
If you are really sure of your trustworthiness, accountability and
confidentiality over this transaction, contact me urgently. I will let
you know the next step and procedure to follow in order to finalize
this transaction successfully.
I expect your urgent communication.
Yours sincerely,
Mr. Mudi Feez
--
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] dt-bindings: Add documentation for GP10B GPU
From: Alexandre Courbot @ 2017-04-08 10:20 UTC (permalink / raw)
To: Thierry Reding
Cc: Alexandre Courbot, Jonathan Hunter, Rob Herring, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Linux Kernel Mailing List,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <20170331125607.GA29779-EkSeR96xj6Pcmrwk2tT4+A@public.gmane.org>
On Fri, Mar 31, 2017 at 9:56 PM, Thierry Reding
<thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On Thu, Mar 30, 2017 at 06:26:44PM +0900, Alexandre Courbot wrote:
>> GP10B's definition is mostly similar to GK20A's and GM20B's. The only
>> noticeable difference is the use of power domains instead of a regulator
>> for power supply.
>>
>> Signed-off-by: Alexandre Courbot <acourbot-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
>> ---
>> Changes since v1:
>> - It's much better when it compiles.
>>
>> .../devicetree/bindings/gpu/nvidia,gk20a.txt | 25 +++++++++++++++++++++-
>> 1 file changed, 24 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/devicetree/bindings/gpu/nvidia,gk20a.txt b/Documentation/devicetree/bindings/gpu/nvidia,gk20a.txt
>> index ff3db65e50de..b7e4c7444510 100644
>> --- a/Documentation/devicetree/bindings/gpu/nvidia,gk20a.txt
>> +++ b/Documentation/devicetree/bindings/gpu/nvidia,gk20a.txt
>> @@ -5,6 +5,7 @@ Required properties:
>> Currently recognized values:
>> - nvidia,gk20a
>> - nvidia,gm20b
>> + - nvidia,gp10b
>> - reg: Physical base address and length of the controller's registers.
>> Must contain two entries:
>> - first entry for bar0
>> @@ -14,7 +15,8 @@ Required properties:
>> - interrupt-names: Must include the following entries:
>> - stall
>> - nonstall
>> -- vdd-supply: regulator for supply voltage.
>> +- vdd-supply: regulator for supply voltage. Only required for GPUs not using
>> + power domains.
>> - clocks: Must contain an entry for each entry in clock-names.
>> See ../clocks/clock-bindings.txt for details.
>> - clock-names: Must include the following entries:
>> @@ -27,6 +29,8 @@ is also required:
>> See ../reset/reset.txt for details.
>> - reset-names: Must include the following entries:
>> - gpu
>> +- power-domains: GPUs that make use of power domains can define this property
>> + instead of vdd-supply. Currently "nvidia,gp10b" makes use of this.
>>
>> Optional properties:
>> - iommus: A reference to the IOMMU. See ../iommu/iommu.txt for details.
>> @@ -68,3 +72,22 @@ Example for GM20B:
>> iommus = <&mc TEGRA_SWGROUP_GPU>;
>> status = "disabled";
>> };
>> +
>> +Example for GP10B:
>> +
>> + gpu@17000000 {
>> + compatible = "nvidia,gp10b";
>> + reg = <0x0 0x17000000 0x0 0x1000000>,
>> + <0x0 0x18000000 0x0 0x1000000>;
>
> Would it make sense to add a reg-names property to give these meaning? I
> know that the binding describes what each entry is, but having the names
> specified in a property would make it more immediately obvious.
Would certainly work, especially since we have been doing this for
other properties. Is there an obvious pro to doing this though?
^ permalink raw reply
* [PATCH v2] ARM: dts: armada-38x: label USB and SATA nodes
From: Ralph Sennhauser @ 2017-04-08 10:16 UTC (permalink / raw)
To: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: Ralph Sennhauser, Jason Cooper, Andrew Lunn, Gregory Clement,
Sebastian Hesselbarth, Rob Herring, Mark Rutland, Russell King,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
Recently most nodes got labels to make them referenceable. The USB 3.0
nodes as well as the nodes for the SATA controllers were left out,
rectify the omission.
The labels "sataX" are already used by some boards for the SATA ports,
therefore use "ahciX" to label the SATA controller nodes.
To avoid potential confusion by labeling an USB3.0 controller "usb2" use
usb3_X as labels. This also coincides with the node names themselves
(usb@xxxxx vs usb3@xxxxx).
Signed-off-by: Ralph Sennhauser <ralph.sennhauser-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
Hi everybody,
Using satacX for controllers with satacXpY for ports might have been a
possiblity, since ahciX is already used similarly (to avoid a conflict
with current use of sataX) ahciX seems the better choice. Works well me
thinks.
The usb3_X labels still seem the best choice even though they aren't
perfectly consitent, however, I don't see an alternative which would fit
this requirement either.
Regards
Ralph
---
Changes v1 -> v2:
* use ahciX instead of satacX for the SATA controller nodes (suggested
by Andrew Lunn)
arch/arm/boot/dts/armada-38x.dtsi | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/armada-38x.dtsi b/arch/arm/boot/dts/armada-38x.dtsi
index ba27ec1..8b165c3 100644
--- a/arch/arm/boot/dts/armada-38x.dtsi
+++ b/arch/arm/boot/dts/armada-38x.dtsi
@@ -530,7 +530,7 @@
interrupts = <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>;
};
- sata@a8000 {
+ ahci0: sata@a8000 {
compatible = "marvell,armada-380-ahci";
reg = <0xa8000 0x2000>;
interrupts = <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH>;
@@ -546,7 +546,7 @@
status = "disabled";
};
- sata@e0000 {
+ ahci1: sata@e0000 {
compatible = "marvell,armada-380-ahci";
reg = <0xe0000 0x2000>;
interrupts = <GIC_SPI 28 IRQ_TYPE_LEVEL_HIGH>;
@@ -590,7 +590,7 @@
status = "disabled";
};
- usb3@f0000 {
+ usb3_0: usb3@f0000 {
compatible = "marvell,armada-380-xhci";
reg = <0xf0000 0x4000>,<0xf4000 0x4000>;
interrupts = <GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH>;
@@ -598,7 +598,7 @@
status = "disabled";
};
- usb3@f8000 {
+ usb3_1: usb3@f8000 {
compatible = "marvell,armada-380-xhci";
reg = <0xf8000 0x4000>,<0xfc000 0x4000>;
interrupts = <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH>;
--
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 1/2] leds: Add driver for Qualcomm LPG
From: Pavel Machek @ 2017-04-08 9:57 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Jacek Anaszewski, Rob Herring, Richard Purdie, linux-kernel,
linux-leds, linux-arm-msm, Mark Rutland, devicetree
In-Reply-To: <20170407202603.GC15143@minitux>
[-- Attachment #1: Type: text/plain, Size: 3467 bytes --]
Hi!
> > On 04/03/2017 09:00 PM, Bjorn Andersson wrote:
> [..]
> > > For the patterns I don't know how a trigger for this would look like,
> > > how would setting the pattern of a trigger be propagated down to the
> > > hardware?
> >
> > We'd need a new op and API similar to blink_set()/led_blink_set().
> >
>
> I've tried to find different LED circuits with some sort of pattern
> generator in an attempt to figure out how to design this interface, but
> turned out to be quite hard to find examples; the three I can compare
> are:
>
> * LP5xx series "implements" pattern generation by executing code.
It supports "linear" and "exponential" transitions between
values. Variable number of steps.
> * Qualcomm LPG iterates over 2-64 brightness-values in a pattern, at a
> fixed rate with knobs to configure what happens before starting and
> after finishing iterating over the defined values. It does not support
> smooth transitions between values.
>
> * AS3676 supports a pattern of 32 values controlling if the output
> should be enabled or disabled for each 32.5ms (or 250ms) time period.
> The delay before repeating the pattern can be configured. It support
> smooth transitions between the states.
Ok, that's "really interesting" one. As far as I can see, the pattern
really should only contain justtwo intensities...
> So, while I think I see how you would like to architect this interface I
> am not sure how to figure out the details.
>
> The pattern definition would have to be expressive enough to support the
> features of LP5xx and direct enough to support the limited AS3676. It
> would likely have to express transitions, so that the LPG could generate
> intermediate steps (and we will have to adapt the resolution of the
> ramps based on the other LPGs in the system).
That's why I believe it is important to present whole pattern engine
as one unit to the userspace. Userspace should always upload pattern
for _all_ the LEDs at once.
> How do we do with patterns that are implementable by the LP5xx but are
> not with the LPG? Should we reject those or should we do some sort of
> best-effort approach in the kernel?
Up to you, I guess. Both rejecting and best-effort make some sense.
OTOH if pattern is "(off, 0msec), (white, +1000msec), (off,
+0msec)"... you can't really do it "exactly" even on LP5xx, due to
non-trivial conversion between PWM and what user sees....
So on LPG you'd really do "(off, 0msec), (10% white, +100msec), (20%
white, +100msec), ..."
AS3676... I guess after we reject all patterns that have more than 0
and one specific brightness, we can use similar approximation we'd do
on LPG?
> > This is what we have now, so we can live with it. Addition of a new
> > RGB trigger would be an improvement of the existing state.
> >
>
> If we do the brightness compensation (for e.g. white balance
> adjustments) in a trigger then there's added value.
>
> The part where I see this affects the LPG driver is that the brightness
> of the patterns might have to be adjusted accordingly - which probably
> would be easier to implement if the kernel just exposed the compensation
> values to user space.
Well, compensation needs to happen "during the transitions",
too.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] leds: Add driver for Qualcomm LPG
From: Pavel Machek @ 2017-04-08 9:33 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Jacek Anaszewski, Rob Herring, Richard Purdie,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-leds-u79uwXL29TY76Z2rM5mHXA,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170407203649.GD15143@minitux>
[-- Attachment #1: Type: text/plain, Size: 1443 bytes --]
On Fri 2017-04-07 13:36:49, Bjorn Andersson wrote:
> On Fri 07 Apr 06:32 PDT 2017, Pavel Machek wrote:
>
> > > For the patterns I don't know how a trigger for this would look like,
> > > how would setting the pattern of a trigger be propagated down to the
> > > hardware?
> >
> > Well... I'm not sure if we _want_ to do triggers for
> > patterns. LED triggers change rather quickly (100 times a second?) so
> > doing them in kernel makes sense. Patterns take 10s of seconds, so we
> > do not need to handle them in kernel.
> >
>
> On any current Qualcomm based phone (using the Qualcomm PMIC to drive
> the RGB notification LED) the patterns are hard coded in DeviceTree and
> the option you have in runtime is to enable/disable the usage of the
> configured pattern and a few knobs of how to traverse the configured
> pattern.
Yes... that's easy, but I believe too limiting. Users will want to
configure their own patterns for their own events.
> When you enter e.g. a low-battery scenario you trigger the red LED to
> run its low-battery-pattern and you don't touch it until there's a
> higher prio notification (e.g. someone connects the charger).
Yes, I have something like that, too.
https://gitlab.com/tui/tui/blob/master/ofone/watchdog.py
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* [PATCH 1/3] gpio - Add EXAR XRA1403 SPI GPIO expander driver
From: Han, Nandor (GE Healthcare) @ 2017-04-08 7:38 UTC (permalink / raw)
To: Linus Walleij
Cc: Alexandre Courbot, Rob Herring, Mark Rutland,
linux-gpio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Malinen, Semi (GE Healthcare)
In-Reply-To: <CACRpkdYZVy2t9=K0jVm5=BxhWWUwiNsGDTMVBbSiB9+1+uafJQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 2429 bytes --]
> -----Original Message-----
> From: Linus Walleij [mailto:linus.walleij@linaro.org]
> Sent: 07 April 2017 13:07
> To: Han, Nandor (GE Healthcare) <nandor.han@ge.com>
> Cc: Alexandre Courbot <gnurou@gmail.com>; Rob Herring <robh+dt@kernel.org>; Mark Rutland
> <mark.rutland@arm.com>; linux-gpio@vger.kernel.org; devicetree@vger.kernel.org; linux-kernel@vger.kernel.org;
> Malinen, Semi (GE Healthcare) <semi.malinen@ge.com>
> Subject: EXT: Re: [PATCH 1/3] gpio - Add EXAR XRA1403 SPI GPIO expander driver
>
> On Wed, Apr 5, 2017 at 3:24 PM, Han, Nandor (GE Healthcare)
> <nandor.han@ge.com> wrote:
> > [Me]
> >> > + /* bring the chip out of reset */
> >> > + reset_gpio = gpiod_get_optional(&spi->dev, "reset", GPIOD_OUT_LOW);
> >> > + if (IS_ERR(reset_gpio))
> >> > + dev_warn(&spi->dev, "could not get reset-gpios\n");
> >> > + else if (reset_gpio)
> >> > + gpiod_put(reset_gpio);
> >>
> >> I don't think you should put it, other than in the remove()
> >> function and in that case you need to have it in the
> >> state container.
> >
> > Can you please be more explicit here.
> >
> > Currently I'm trying to bring the device out from reset in case reset GPIO is provided.
> > I don't see how this could be done in remove() :)
>
> If you issue gpiod_put() you release the GPIO hande so something else
> can go in and grab the GPIO and assert the reset.
>
> This is not what you want to make possible: you want to hold this gpiod handle
> as long as the driver is running. devm_gpiod_get_optional() will do the
> trick if you don't want to put the handle under explicit control.
>
That was my first intention to release the reset line in case somebody else wants to control it. I did it
like that because usually reset line controls multiple devices and probably some upper layer wants to
control that.
After your comment I did some analysing and I will follow your advice and change the reset line handling.
Once the GPIO is provided to the driver the driver will own it and bring out the device from reset. In case not
provided the reset line is somebody else responsibility.
This way we are able to cover multiple use-cases.
Thanks Linus,
Nandy
> Yours,
> Linus Walleij
N‹§²æìr¸›yúèšØb²X¬¶Ç§vØ^–)Þº{.nÇ+‰·zøœzÚÞz)í…æèw*\x1fjg¬±¨\x1e¶‰šŽŠÝ¢j.ïÛ°\½½MŽúgjÌæa×\x02››–' ™©Þ¢¸\f¢·¦j:+v‰¨ŠwèjØm¶Ÿÿ¾\a«‘êçzZ+ƒùšŽŠÝ¢j"ú!¶i
^ permalink raw reply
* 33011 devicetree
From: john.faust-H4SBLDCxrCifRvmTrFJqzg @ 2017-04-08 7:03 UTC (permalink / raw)
To: devicetree
[-- Attachment #1: 886869958978.zip --]
[-- Type: application/zip, Size: 2486 bytes --]
^ permalink raw reply
* Re: [PATCH 0/5] arm64: dts: hisi: add NIC, RoCE and SAS support for hip07
From: Wei Xu @ 2017-04-08 6:51 UTC (permalink / raw)
To: robh+dt, mark.rutland, catalin.marinas, will.deacon, arnd
Cc: wangkefeng.wang, gabriele.paoloni, charles.chenxin, linuxarm,
guohanjun, yankejian, yimin, huangdaode, liudongdong3,
yisen.zhuang, devicetree, john.garry, tanxiaofei, lipeng321,
linux-arm-kernel, salil.mehta, chenxiang66, linux-kernel,
shameerali.kolothum.thodi, wangzhou1, liguozhu, majun258
In-Reply-To: <1491530876-109791-1-git-send-email-xuwei5@hisilicon.com>
Hi All,
On 2017/4/7 10:07, Wei.Xu wrote:
> This patch series adds Mbigen, NIC, RoCE and SAS nodes for the hip07
> SoC and enables the NIC, RoCE and SAS on the hip07 d05 board.
>
> Wei Xu (5):
> arm64: dts: hisi: add mbigen nodes for the hip07 SoC
> arm64: dts: hisi: add network related nodes for the hip07 SoC
> arm64: dts: hisi: add RoCE nodes for the hip07 SoC
> arm64: dts: hisi: add SAS nodes for the hip07 SoC
> arm64: dts: hisi: enalbe the NIC and SAS for the hip07-d05 board
>
> arch/arm64/boot/dts/hisilicon/hip07-d05.dts | 24 ++
> arch/arm64/boot/dts/hisilicon/hip07.dtsi | 479 ++++++++++++++++++++++++++++
> 2 files changed, 503 insertions(+)
>
After removed the PCIe node in the patch 5, the series has been applied
to the hisilicon arm64
dt tree since this series patches just to add the nodes and the binding
has been reviewed before.
Best Regards,
Wei
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: arm: hisilicon: add bindings for hi3798cv200 SoC and Poplar board
From: Wei Xu @ 2017-04-08 6:46 UTC (permalink / raw)
To: Jiancheng Xue, robh+dt, arnd, catalin.marinas, will.deacon
Cc: devicetree, linux-kernel, yanhaifeng, peter.griffin, elder,
hermit.wangheming, afaerber, linux-arm-kernel
In-Reply-To: <1490769009-12552-2-git-send-email-xuejiancheng@hisilicon.com>
Hi Jiancheng,
On 2017/3/29 14:30, Jiancheng Xue wrote:
> Add bindings for HiSilicon hi3798cv200 SoC and Poplar Board.
>
> Signed-off-by: Jiancheng Xue <xuejiancheng@hisilicon.com>
> Reviewed-by: Alex Elder <elder@linaro.org>
> Acked-by: Peter Griffin <peter.griffin@linaro.org>
> Acked-by: Rob Herring <robh@kernel.org>
Thanks!
Applied both to the hisilicon arm64 dt tree but added hi3798cv200 soc
binding to avoid the patch checking warning.
Best Regards,
Wei
> ---
> Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt b/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt
> index f1c1e21..1fd3dd7 100644
> --- a/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt
> +++ b/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt
> @@ -4,6 +4,10 @@ Hi3660 SoC
> Required root node properties:
> - compatible = "hisilicon,hi3660";
>
> +Hi3798cv200 Poplar Board
> +Required root node properties:
> + - compatible = "hisilicon,hi3798cv200-poplar", "hisilicon,hi3798cv200";
> +
> Hi4511 Board
> Required root node properties:
> - compatible = "hisilicon,hi3620-hi4511";
^ permalink raw reply
* Re: [PATCH 1/2] arm64: dts: add drive-strength levels of pin for Hi3660 SoC
From: Wei Xu @ 2017-04-08 6:42 UTC (permalink / raw)
To: Wang Xiaoyin, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, catalin.marinas-5wv7dgnIgG8,
will.deacon-5wv7dgnIgG8,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: chenya99-C8/M+/jPZTeaMJb+Lgu22Q
In-Reply-To: <20170330064803.18648-1-hw.wangxiaoyin-C8/M+/jPZTeaMJb+Lgu22Q@public.gmane.org>
Hi Xiaoyin,
On 2017/3/30 14:48, Wang Xiaoyin wrote:
> Add drive-strength levels of pin for Hi3660 Soc.
>
> Signed-off-by: Wang Xiaoyin <hw.wangxiaoyin-C8/M+/jPZTeaMJb+Lgu22Q@public.gmane.org>
Thanks!
Applied both to the hisilicon arm64 dt tree.
Best Regards,
Wei
> ---
> include/dt-bindings/pinctrl/hisi.h | 15 +++++++++++++++
> 1 file changed, 15 insertions(+)
>
> diff --git a/include/dt-bindings/pinctrl/hisi.h b/include/dt-bindings/pinctrl/hisi.h
> index 38f1ea879ea1..0359bfdc9119 100644
> --- a/include/dt-bindings/pinctrl/hisi.h
> +++ b/include/dt-bindings/pinctrl/hisi.h
> @@ -56,4 +56,19 @@
> #define DRIVE4_08MA (4 << 4)
> #define DRIVE4_10MA (6 << 4)
>
> +/* drive strength definition for hi3660 */
> +#define DRIVE6_MASK (15 << 4)
> +#define DRIVE6_04MA (0 << 4)
> +#define DRIVE6_12MA (4 << 4)
> +#define DRIVE6_19MA (8 << 4)
> +#define DRIVE6_27MA (10 << 4)
> +#define DRIVE6_32MA (15 << 4)
> +#define DRIVE7_02MA (0 << 4)
> +#define DRIVE7_04MA (1 << 4)
> +#define DRIVE7_06MA (2 << 4)
> +#define DRIVE7_08MA (3 << 4)
> +#define DRIVE7_10MA (4 << 4)
> +#define DRIVE7_12MA (5 << 4)
> +#define DRIVE7_14MA (6 << 4)
> +#define DRIVE7_16MA (7 << 4)
> #endif
--
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: hi6220: Reset the mmc hosts
From: Wei Xu @ 2017-04-08 6:38 UTC (permalink / raw)
To: Daniel Lezcano
Cc: stable, linux-kernel, linux-arm-kernel, guodong.xu, devicetree
In-Reply-To: <1489673004-11075-1-git-send-email-daniel.lezcano@linaro.org>
Hi Daniel,
On 2017/3/16 22:03, Daniel Lezcano wrote:
> The MMC hosts could be left in an unconsistent or uninitialized state from
> the firmware. Instead of assuming, the firmware did the right things, let's
> reset the host controllers.
>
> This change fixes a bug when the mmc2/sdio is initialized leading to a hung
> task:
>
> [ 242.704294] INFO: task kworker/7:1:675 blocked for more than 120 seconds.
> [ 242.711129] Not tainted 4.9.0-rc8-00017-gcf0251f #3
> [ 242.716571] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> [ 242.724435] kworker/7:1 D 0 675 2 0x00000000
> [ 242.729973] Workqueue: events_freezable mmc_rescan
> [ 242.734796] Call trace:
> [ 242.737269] [<ffff00000808611c>] __switch_to+0xa8/0xb4
> [ 242.742437] [<ffff000008d07c04>] __schedule+0x1c0/0x67c
> [ 242.747689] [<ffff000008d08254>] schedule+0x40/0xa0
> [ 242.752594] [<ffff000008d0b284>] schedule_timeout+0x1c4/0x35c
> [ 242.758366] [<ffff000008d08e38>] wait_for_common+0xd0/0x15c
> [ 242.763964] [<ffff000008d09008>] wait_for_completion+0x28/0x34
> [ 242.769825] [<ffff000008a1a9f4>] mmc_wait_for_req_done+0x40/0x124
> [ 242.775949] [<ffff000008a1ab98>] mmc_wait_for_req+0xc0/0xf8
> [ 242.781549] [<ffff000008a1ac3c>] mmc_wait_for_cmd+0x6c/0x84
> [ 242.787149] [<ffff000008a26610>] mmc_io_rw_direct_host+0x9c/0x114
> [ 242.793270] [<ffff000008a26aa0>] sdio_reset+0x34/0x7c
> [ 242.798347] [<ffff000008a1d46c>] mmc_rescan+0x2fc/0x360
>
> [ ... ]
>
> Cc: stable@vger.kernel.org
> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Thanks!
Applied to the hisilicon arm64 dt tree.
Best Regards,
Wei
> ---
> arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
> index 470461d..1e5129b 100644
> --- a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
> +++ b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
> @@ -774,6 +774,7 @@
> clocks = <&sys_ctrl 2>, <&sys_ctrl 1>;
> clock-names = "ciu", "biu";
> resets = <&sys_ctrl PERIPH_RSTDIS0_MMC0>;
> + reset-names = "reset";
> bus-width = <0x8>;
> vmmc-supply = <&ldo19>;
> pinctrl-names = "default";
> @@ -797,6 +798,7 @@
> clocks = <&sys_ctrl 4>, <&sys_ctrl 3>;
> clock-names = "ciu", "biu";
> resets = <&sys_ctrl PERIPH_RSTDIS0_MMC1>;
> + reset-names = "reset";
> vqmmc-supply = <&ldo7>;
> vmmc-supply = <&ldo10>;
> bus-width = <0x4>;
> @@ -815,6 +817,7 @@
> clocks = <&sys_ctrl HI6220_MMC2_CIUCLK>, <&sys_ctrl HI6220_MMC2_CLK>;
> clock-names = "ciu", "biu";
> resets = <&sys_ctrl PERIPH_RSTDIS0_MMC2>;
> + reset-names = "reset";
> bus-width = <0x4>;
> broken-cd;
> pinctrl-names = "default", "idle";
^ permalink raw reply
* RE: Device Tree Binding for Intel FPGA Video and Image Processing Suite
From: Ong, Hean Loong @ 2017-04-08 5:25 UTC (permalink / raw)
To: Rob Herring
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Ong, Hean Loong
In-Reply-To: <CAL_JsqLFbHHcVYs4a+-WS7yUEMsFR6-Y_4gootxoAwxD+RRF1A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Hi,
First of all thank you Rob for your time and patience. Especially on how this patch was sent out. I would ensure it would not happen again for the subsequent patches.
On the issue of why the DT has certain resolution fixed is due to the fact that our Quartus system generates these attributes in according to the specific display resolution as desired by the user. The values here are the ideal resolution supported by the hardware for the reference design.
On the other hand my bad on the vendor prefix as I misunderstood the "altr," as the vendor prefix
Thanks
Hean Loong
>-----Original Message-----
>From: Rob Herring [mailto:robh+dt@kernel.org]
>Sent: Saturday, April 8, 2017 5:53 AM
>To: Ong, Hean Loong <hean.loong.ong@intel.com>
>Cc: devicetree@vger.kernel.org
>Subject: Re: Device Tree Binding for Intel FPGA Video and Image Processing Suite
>
>On Thu, Apr 6, 2017 at 1:42 AM, Ong, Hean Loong <hean.loong.ong@intel.com>
>wrote:
>> Hi Rob,
>>
>> Any comments on the patch?
>
>Yes, the same ones I provided 5 months ago to you. Repeated below.
>
>>
>> BR
>>
>> Hean Loong
>>
>> On Tue, 2017-04-04 at 03:57 +0000, Ong, Hean Loong wrote:
>>> Hi Rob,
>>>
>>> Apologies for the mistake. Below are the bindings
>>>
>>> From 23a9e274bb517b8e232c5aa4cf9737de1644b708 Mon Sep 17 00:00:00
>>> 2001
>>> From: Ong, Hean Loong <hean.loong.ong@intel.com>
>>> Date: Thu, 30 Mar 2017 17:59:37 +0800
>>> Subject: [PATCHv0] Intel FPGA Video and Image Processing Suite device
>>> tree binding
>
>This is still not how you email patches. The easiest way is git-send-email.
>
>>> Device tree binding for Intel FPGA Video and Image
>>> Processing Suite. The binding involved would be generated
>>> from the Altera (Intel) Qsys system. The bindings would
>>> set the max width, max height, buts per pixel and memory
>>> port width. The device tree binding only supports the Intel
>>> Arria10 devkit and its variants. Vendor name retained as
>>> altr.
>
>There should be no indentation here.
>
>>>
>>> Signed-off-by: Ong, Hean Loong <hean.loong.ong@intel.com>
>>> ---
>>> .../devicetree/bindings/gpu/altr,vip-fb2.txt | 24
>>> ++++++++++++++++++++
>
>bindings/display/. This is not a GPU.
>
>>> 1 files changed, 24 insertions(+), 0 deletions(-) create mode
>>> 100644 Documentation/devicetree/bindings/gpu/altr,vip-
>>> fb2.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/gpu/altr,vip-fb2.txt
>>> b/Documentation/devicetree/bindings/gpu/altr,vip-fb2.txt
>>> new file mode 100644
>>> index 0000000..9ba3209
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/gpu/altr,vip-fb2.txt
>>> @@ -0,0 +1,24 @@
>>> +Intel Video and Image Processing(VIP) Frame Buffer II bindings
>>> +
>>> +Supported hardware: Arria 10 and above with display port IP
>>> +
>>> +Required properties:
>>> +- compatible: "altr,vip-frame-buffer-2.0"
>>> +- reg: Physical base address and length of the framebuffer
>>> controller's
>>> + registers.
>
>>> +- max-width: The width of the framebuffer in pixels.
>>> +- max-height: The height of the framebuffer in pixels.
>>> +- bits-per-symbol: only "8" is currently supported
>
>Why do these need to be in DT?
>
>>> +- mem-port-width = the bus width of the avalon master port on the
>>> frame reader
>
>Still needs a vendor prefix.
>
>>> +
>>> +Example:
>>> +
>>> +dp_0_frame_buf: vip@0x100000280 {
>
>display-controller@100000280
>
>>> + compatible = "altr,vip-frame-buffer-2.0";
>>> + reg = <0x00000001 0x00000280 0x00000040>;
>>> + altr,max-width = <1280>;
>>> + altr,max-height = <720>;
>>> + altr,bits-per-symbol = <8>;
>>> + altr,mem-port-width = <128>;
>>> +};
>>> +
>>> --
>>> 1.7.1
>>>
^ 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