* Re: [PATCH v4 1/2] dt-bindings: Document the STM32 QSPI bindings
From: Brian Norris @ 2017-05-02 1:09 UTC (permalink / raw)
To: Cyrille Pitchen
Cc: Ludovic Barre, Cyrille Pitchen, Marek Vasut, Boris Brezillon,
Alexandre Torgue, devicetree-u79uwXL29TY76Z2rM5mHXA,
Richard Weinberger, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
Rob Herring, linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
David Woodhouse
In-Reply-To: <b62272c9-027c-9c9b-42f0-1056d88aac7c-yU5RGvR974pGWvitb5QawA@public.gmane.org>
On Sun, Apr 16, 2017 at 06:53:06PM +0200, Cyrille Pitchen wrote:
> Hi all,
>
> Rob, is this version ok for you? If so, I can take it into the
> github/spi-nor tree.
I see this was missing from your pull request. Rob has since acked,
so...
Applied to l2-mtd.git
--
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 v4 2/2] mtd: spi-nor: add driver for STM32 quad spi flash controller
From: Brian Norris @ 2017-05-02 1:05 UTC (permalink / raw)
To: Ludovic Barre
Cc: Cyrille Pitchen, Marek Vasut, David Woodhouse, Boris Brezillon,
Richard Weinberger, Alexandre Torgue, Rob Herring,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Joachim Eastwood
In-Reply-To: <1492103757-22375-3-git-send-email-ludovic.Barre-qxv4g6HH51o@public.gmane.org>
Hi,
On Thu, Apr 13, 2017 at 07:15:57PM +0200, Ludovic Barre wrote:
> From: Ludovic Barre <ludovic.barre-qxv4g6HH51o@public.gmane.org>
>
> The quadspi is a specialized communication interface targeting single,
> dual or quad SPI Flash memories.
>
> It can operate in any of the following modes:
> -indirect mode: all the operations are performed using the quadspi
> registers
> -read memory-mapped mode: the external Flash memory is mapped to the
> microcontroller address space and is seen by the system as if it was
> an internal memory
>
> Signed-off-by: Ludovic Barre <ludovic.barre-qxv4g6HH51o@public.gmane.org>
> ---
> drivers/mtd/spi-nor/Kconfig | 7 +
> drivers/mtd/spi-nor/Makefile | 1 +
> drivers/mtd/spi-nor/stm32-quadspi.c | 694 ++++++++++++++++++++++++++++++++++++
> 3 files changed, 702 insertions(+)
> create mode 100644 drivers/mtd/spi-nor/stm32-quadspi.c
>
> diff --git a/drivers/mtd/spi-nor/Kconfig b/drivers/mtd/spi-nor/Kconfig
> index 7252087..bfdfb1e 100644
> --- a/drivers/mtd/spi-nor/Kconfig
> +++ b/drivers/mtd/spi-nor/Kconfig
> @@ -106,4 +106,11 @@ config SPI_INTEL_SPI_PLATFORM
> To compile this driver as a module, choose M here: the module
> will be called intel-spi-platform.
>
> +config SPI_STM32_QUADSPI
> + tristate "STM32 Quad SPI controller"
> + depends on ARCH_STM32
> + help
> + This enables support for the STM32 Quad SPI controller.
> + We only connect the NOR to this controller.
> +
> endif # MTD_SPI_NOR
> diff --git a/drivers/mtd/spi-nor/Makefile b/drivers/mtd/spi-nor/Makefile
> index 72238a7..285aab8 100644
> --- /dev/null
> +++ b/drivers/mtd/spi-nor/stm32-quadspi.c
> @@ -0,0 +1,694 @@
...
> +static int stm32_qspi_flash_setup(struct stm32_qspi *qspi,
> + struct device_node *np)
> +{
> + u32 width, flash_read, presc, cs_num, max_rate = 0;
> + struct stm32_qspi_flash *flash;
> + struct mtd_info *mtd;
> + int ret;
> +
> + of_property_read_u32(np, "reg", &cs_num);
> + if (cs_num >= STM32_MAX_NORCHIP)
> + return -EINVAL;
> +
> + of_property_read_u32(np, "spi-max-frequency", &max_rate);
> + if (!max_rate)
> + return -EINVAL;
> +
> + presc = DIV_ROUND_UP(qspi->clk_rate, max_rate) - 1;
> +
> + if (of_property_read_u32(np, "spi-rx-bus-width", &width))
Can we move handling of this into spi-nor.c sometime? This is the 2nd
driver that wants this. And in this case, there's absolutely no
driver-specific handling for it. (For nxp-spifi.c, the hanling looks a
little wrong anyway -- the DT could have a larger bus width, but the
flash might only support a smaller. So the driver should gracefull
downgrade *after* we detect this, I think.)
Not a blocker for now, but just room for future work.
Brian
> + width = 1;
> +
> + if (width == 4)
> + flash_read = SPI_NOR_QUAD;
> + else if (width == 2)
> + flash_read = SPI_NOR_DUAL;
> + else if (width == 1)
> + flash_read = SPI_NOR_NORMAL;
> + else
> + return -EINVAL;
[...]
Brian
--
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 v4 1/3] drm/vc4: Turn the V3D clock on at runtime.
From: Rob Herring @ 2017-05-01 22:59 UTC (permalink / raw)
To: Eric Anholt
Cc: dri-devel, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <20170428224223.21904-1-eric-WhKQ6XTQaPysTnJN9+BGXg@public.gmane.org>
On Fri, Apr 28, 2017 at 5:42 PM, Eric Anholt <eric-WhKQ6XTQaPysTnJN9+BGXg@public.gmane.org> wrote:
> For the Raspberry Pi's bindings, the power domain also implicitly
> turns on the clock and deasserts reset, but for the new Cygnus port we
> start representing the clock in the devicetree.
>
> v2: Document the clock-names property, check for -ENOENT for no clock
> in DT.
> v3: Drop NULL checks around clk calls which embed NULL checks.
> v4: Drop clk-names (feedback by Rob Herring)
>
> Signed-off-by: Eric Anholt <eric-WhKQ6XTQaPysTnJN9+BGXg@public.gmane.org>
> ---
> .../devicetree/bindings/display/brcm,bcm-vc4.txt | 3 +++
> drivers/gpu/drm/vc4/vc4_drv.h | 1 +
> drivers/gpu/drm/vc4/vc4_v3d.c | 31 +++++++++++++++++++++-
> 3 files changed, 34 insertions(+), 1 deletion(-)
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] of: undeclared variable when CONFIG_DEBUG_LOCK_ALLOC
From: Frank Rowand @ 2017-05-01 22:23 UTC (permalink / raw)
To: Rowand, Frank, Rob Herring
Cc: Stephen Boyd, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <ED290C750E1B324E972B0017C9D4BAB01FDD5370-t8YLG9SB9XQEb75RT/aEbJZPSYnAH24X@public.gmane.org>
On 05/01/17 14:20, Rowand, Frank wrote:
> On Monday, May 01, 2017 1:13 PM, Rob Herring [mailto:robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org] wrote:
>>
>> On Sun, Apr 30, 2017 at 3:00 PM, Frank Rowand <frank.rowand-7U/KSKJipcs@public.gmane.org>
>> wrote:
>>> An undeclared variable was used in a macro that evaluates to nothing
>>> when CONFIG_DEBUG_LOCK_ALLOC is not defined. Change to use the correct
>>> variable that does exist.
>>>
>>> ---
>>>
>>> reported by kbuild test robot on on robh/for-next
>>> https://lkml.org/lkml/2017/4/29/134
>>
>> That's a bit misleading because I've not applied the offending patch.
>> Please squash this.
>>
>> Rob
>
> Does "squash this" mean to redo the original path to include this fix?
^^^^ patch
>
> Thanks,
>
> Frank
>
--
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] of: undeclared variable when CONFIG_DEBUG_LOCK_ALLOC
From: Rowand, Frank @ 2017-05-01 21:20 UTC (permalink / raw)
To: Rob Herring
Cc: Stephen Boyd, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Frank Rowand
In-Reply-To: <CAL_JsqKMB4exBFTDNFAio87JeOF0sXjMBkueizgfoiG38Mb_8A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 797 bytes --]
On Monday, May 01, 2017 1:13 PM, Rob Herring [mailto:robh+dt@kernel.org] wrote:
>
> On Sun, Apr 30, 2017 at 3:00 PM, Frank Rowand <frank.rowand@sony.com>
> wrote:
>> An undeclared variable was used in a macro that evaluates to nothing
>> when CONFIG_DEBUG_LOCK_ALLOC is not defined. Change to use the correct
>> variable that does exist.
>>
>> ---
>>
>> reported by kbuild test robot on on robh/for-next
>> https://lkml.org/lkml/2017/4/29/134
>
> That's a bit misleading because I've not applied the offending patch.
> Please squash this.
>
> Rob
Does "squash this" mean to redo the original path to include this fix?
Thanks,
Frank
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
* Re: [PATCH] of: undeclared variable when CONFIG_DEBUG_LOCK_ALLOC
From: Rob Herring @ 2017-05-01 20:13 UTC (permalink / raw)
To: Frank Rowand
Cc: Stephen Boyd, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <1493582403-12291-1-git-send-email-frank.rowand-7U/KSKJipcs@public.gmane.org>
On Sun, Apr 30, 2017 at 3:00 PM, Frank Rowand <frank.rowand-7U/KSKJipcs@public.gmane.org> wrote:
> An undeclared variable was used in a macro that evaluates to nothing
> when CONFIG_DEBUG_LOCK_ALLOC is not defined. Change to use the correct
> variable that does exist.
>
> ---
>
> reported by kbuild test robot on on robh/for-next
> https://lkml.org/lkml/2017/4/29/134
That's a bit misleading because I've not applied the offending patch.
Please squash this.
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
* [PATCH v2 2/2] regulator: Allow for asymmetric settling times
From: Matthias Kaehlcke @ 2017-05-01 18:37 UTC (permalink / raw)
To: Liam Girdwood, Mark Brown, Laxman Dewangan, Rob Herring,
Mark Rutland
Cc: linux-kernel, devicetree, Douglas Anderson, Brian Norris,
Matthias Kaehlcke
In-Reply-To: <20170501183715.35375-1-mka@chromium.org>
Some regulators have different settling times for voltage increases and
decreases. To avoid a time penalty on the faster transition allow for
different settings for up- and downward transitions.
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
---
Changes in v2:
- Don't remove settling_time property
- Split DT bindings doc into separate patch
drivers/regulator/core.c | 6 ++++++
drivers/regulator/of_regulator.c | 9 +++++++++
include/linux/regulator/machine.h | 6 ++++++
3 files changed, 21 insertions(+)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 811096b23143..7836f07431d8 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -2775,6 +2775,12 @@ static int _regulator_set_voltage_time(struct regulator_dev *rdev,
ramp_delay = rdev->desc->ramp_delay;
else if (rdev->constraints->settling_time)
return rdev->constraints->settling_time;
+ else if (rdev->constraints->settling_time_up &&
+ (new_uV > old_uV))
+ return rdev->constraints->settling_time_up;
+ else if (rdev->constraints->settling_time_down &&
+ (new_uV < old_uV))
+ return rdev->constraints->settling_time_down;
if (ramp_delay == 0) {
rdev_dbg(rdev, "ramp_delay not set\n");
diff --git a/drivers/regulator/of_regulator.c b/drivers/regulator/of_regulator.c
index 09d677d5d3f0..b0a007c349ef 100644
--- a/drivers/regulator/of_regulator.c
+++ b/drivers/regulator/of_regulator.c
@@ -90,6 +90,15 @@ static void of_get_regulation_constraints(struct device_node *np,
if (!ret)
constraints->settling_time = pval;
+ ret = of_property_read_u32(np, "regulator-settling-time-up-us", &pval);
+ if (!ret)
+ constraints->settling_time_up = pval;
+
+ ret = of_property_read_u32(np, "regulator-settling-time-down-us",
+ &pval);
+ if (!ret)
+ constraints->settling_time_down = pval;
+
ret = of_property_read_u32(np, "regulator-enable-ramp-delay", &pval);
if (!ret)
constraints->enable_time = pval;
diff --git a/include/linux/regulator/machine.h b/include/linux/regulator/machine.h
index 117699d1f7df..9cd4fef37203 100644
--- a/include/linux/regulator/machine.h
+++ b/include/linux/regulator/machine.h
@@ -110,6 +110,10 @@ struct regulator_state {
* @ramp_delay: Time to settle down after voltage change (unit: uV/us)
* @settling_time: Time to settle down after voltage change when voltage
* change is non-linear (unit: microseconds).
+ * @settling_time_up: Time to settle down after voltage increase when voltage
+ * change is non-linear (unit: microseconds).
+ * @settling_time_down : Time to settle down after voltage decrease when
+ * voltage change is non-linear (unit: microseconds).
* @active_discharge: Enable/disable active discharge. The enum
* regulator_active_discharge values are used for
* initialisation.
@@ -152,6 +156,8 @@ struct regulation_constraints {
unsigned int ramp_delay;
unsigned int settling_time;
+ unsigned int settling_time_up;
+ unsigned int settling_time_down;
unsigned int enable_time;
unsigned int active_discharge;
--
2.13.0.rc0.306.g87b477812d-goog
^ permalink raw reply related
* [PATCH v2 1/2] regulator: DT: Add properties for asymmetric settling times
From: Matthias Kaehlcke @ 2017-05-01 18:37 UTC (permalink / raw)
To: Liam Girdwood, Mark Brown, Laxman Dewangan, Rob Herring,
Mark Rutland
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Douglas Anderson, Brian Norris,
Matthias Kaehlcke
Some regulators have different settling times for voltage increases and
decreases. Add DT properties to define separate settling times for up-
and downward voltage changes.
Signed-off-by: Matthias Kaehlcke <mka-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
---
Changes in v2:
- Moved DT binding doc to separate patch
- Don't remove settling_time property
Documentation/devicetree/bindings/regulator/regulator.txt | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/Documentation/devicetree/bindings/regulator/regulator.txt b/Documentation/devicetree/bindings/regulator/regulator.txt
index d18edb075e1c..378f6dc8b8bd 100644
--- a/Documentation/devicetree/bindings/regulator/regulator.txt
+++ b/Documentation/devicetree/bindings/regulator/regulator.txt
@@ -24,6 +24,14 @@ Optional properties:
- regulator-settling-time-us: Settling time, in microseconds, for voltage
change if regulator have the constant time for any level voltage change.
This is useful when regulator have exponential voltage change.
+- regulator-settling-time-up-us: Settling time, in microseconds, for voltage
+ increase if the regulator needs a constant time to settle after voltage
+ increases of any level. This is useful for regulators with exponential
+ voltage changes.
+- regulator-settling-time-down-us: Settling time, in microseconds, for voltage
+ decrease if the regulator needs a constant time to settle after voltage
+ decreases of any level. This is useful for regulators with exponential
+ voltage changes.
- regulator-soft-start: Enable soft start so that voltage ramps slowly
- regulator-state-mem sub-root node for Suspend-to-RAM mode
: suspend to memory, the device goes to sleep, but all data stored in memory,
--
2.13.0.rc0.306.g87b477812d-goog
--
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 v2 2/2] fpga: lattice machxo2: Add Lattice MachXO2 support
From: Moritz Fischer @ 2017-05-01 17:59 UTC (permalink / raw)
To: Paolo Pisati
Cc: Alan Tull, Rob Herring, Mark Rutland, Moritz Fischer,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-fpga-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1493644512-14776-3-git-send-email-p.pisati-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 8011 bytes --]
Hi Paolo,
couple of nits inline, looks pretty good already.
On Mon, May 01, 2017 at 03:15:12PM +0200, Paolo Pisati wrote:
> This patch adds support to the FPGA manager for programming
> MachXO2 device’s internal flash memory, via slave SPI.
>
> Signed-off-by: Paolo Pisati <p.pisati-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> ---
> drivers/fpga/Kconfig | 7 ++
> drivers/fpga/Makefile | 1 +
> drivers/fpga/machxo2-spi.c | 214 +++++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 222 insertions(+)
> create mode 100644 drivers/fpga/machxo2-spi.c
>
> diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
> index c81cb7d..cce135b 100644
> --- a/drivers/fpga/Kconfig
> +++ b/drivers/fpga/Kconfig
> @@ -26,6 +26,13 @@ config FPGA_MGR_ICE40_SPI
> help
> FPGA manager driver support for Lattice iCE40 FPGAs over SPI.
>
> +config FPGA_MGR_MACHXO2_SPI
> + tristate "Lattice MachXO2 SPI"
> + depends on SPI
> + help
> + FPGA manager driver support for Lattice MachXO2 configuration
> + over slave SPI interface.
> +
> config FPGA_MGR_SOCFPGA
> tristate "Altera SOCFPGA FPGA Manager"
> depends on ARCH_SOCFPGA || COMPILE_TEST
> diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile
> index c6f5d74..cdab1fe 100644
> --- a/drivers/fpga/Makefile
> +++ b/drivers/fpga/Makefile
> @@ -7,6 +7,7 @@ obj-$(CONFIG_FPGA) += fpga-mgr.o
>
> # FPGA Manager Drivers
> obj-$(CONFIG_FPGA_MGR_ICE40_SPI) += ice40-spi.o
> +obj-$(CONFIG_FPGA_MGR_MACHXO2_SPI) += machxo2-spi.o
> obj-$(CONFIG_FPGA_MGR_SOCFPGA) += socfpga.o
> obj-$(CONFIG_FPGA_MGR_SOCFPGA_A10) += socfpga-a10.o
> obj-$(CONFIG_FPGA_MGR_TS73XX) += ts73xx-fpga.o
> diff --git a/drivers/fpga/machxo2-spi.c b/drivers/fpga/machxo2-spi.c
> new file mode 100644
> index 0000000..264ef63
> --- /dev/null
> +++ b/drivers/fpga/machxo2-spi.c
> @@ -0,0 +1,214 @@
> +/**
> + * Lattice MachXO2 Slave SPI Driver
> + *
> + * Copyright (C) 2017 Paolo Pisati <p.pisati-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * Manage Lattice FPGA firmware that is loaded over SPI using
> + * the slave serial configuration interface.
> + */
> +
> +#include <linux/delay.h>
> +#include <linux/fpga/fpga-mgr.h>
> +#include <linux/gpio/consumer.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/spi/spi.h>
> +
> +/* MachXO2 Programming Guide - sysCONFIG Programming Commands */
> +
> +#define ISC_ENABLE 0x000008c6
> +#define ISC_ERASE 0x0000040e
> +#define ISC_PROGRAMDONE 0x0000005e
> +#define LSC_CHECKBUSY 0x000000f0
> +#define LSC_INITADDRESS 0x00000046
> +#define LSC_PROGINCRNV 0x01000070
> +#define LSC_REFRESH 0x00000079
> +
> +#define BUSYFLAG 0x80
Maybe BIT() macro?
> +
> +/*
> + * Max CCLK in Slave SPI mode according to 'MachXO2 Family Data
> + * Sheet' sysCONFIG Port Timing Specifications (3-36)
> + */
> +#define MACHXO2_MAX_SPEED 66000000
> +
> +#define MACHXO2_LOW_DELAY 5 /* us */
> +#define MACHXO2_HIGH_DELAY 200 /* us */
> +
> +#define MACHXO2_OP_SIZE sizeof(u32)
> +#define MACHXO2_PAGE_SIZE 16
> +#define MACHXO2_BUF_SIZE (MACHXO2_OP_SIZE + MACHXO2_PAGE_SIZE)
> +
> +static int wait_until_not_busy(struct spi_device *spi)
> +{
> + u8 rx;
> + u32 checkbusy = LSC_CHECKBUSY;
> + int ret;
> +
> + do {
> + ret = spi_write_then_read(spi, &checkbusy, MACHXO2_OP_SIZE,
> + &rx, sizeof(rx));
> + if (ret)
> + return ret;
> + } while (rx & BUSYFLAG);
> +
> + return 0;
> +}
> +
> +static enum fpga_mgr_states machxo2_spi_state(struct fpga_manager *mgr)
> +{
> + return FPGA_MGR_STATE_UNKNOWN;
> +}
> +
> +static int machxo2_write_init(struct fpga_manager *mgr,
> + struct fpga_image_info *info,
> + const char *buf, size_t count)
> +{
> + struct spi_device *spi = mgr->priv;
> + u32 enable = ISC_ENABLE;
> + u32 erase = ISC_ERASE;
> + u32 initaddr = LSC_INITADDRESS;
> + int ret;
> +
> + if ((info->flags & FPGA_MGR_PARTIAL_RECONFIG)) {
> + dev_err(&mgr->dev,
> + "Partial reconfiguration is not supported\n");
> + return -ENOTSUPP;
> + }
> +
> + ret = spi_write(spi, &enable, MACHXO2_OP_SIZE);
> + if (ret)
> + goto fail;
> +
> + udelay(MACHXO2_LOW_DELAY);
Does this have to be a delay, or can this be a sleep?
Can you maybe make the whole thing a chain of transactions
making use of spi_message_init() and trans.delay_usecs?
> + ret = spi_write(spi, &erase, MACHXO2_OP_SIZE);
> + if (ret)
> + goto fail;
> +
> + ret = wait_until_not_busy(spi);
> + if (ret)
> + goto fail;
> +
> + ret = spi_write(spi, &initaddr, MACHXO2_OP_SIZE);
> + if (ret)
> + goto fail;
> +
> + return 0;
> +
> +fail:
> + dev_err(&mgr->dev, "Error during FPGA init.\n");
> + return ret;
> +}
> +
> +static int machxo2_write(struct fpga_manager *mgr, const char *buf,
> + size_t count)
> +{
> + struct spi_device *spi = mgr->priv;
> + u32 progincr = LSC_PROGINCRNV;
> + u8 payload[MACHXO2_BUF_SIZE];
> + int i, ret;
> +
> + if (count % MACHXO2_PAGE_SIZE != 0) {
> + dev_err(&mgr->dev, "Malformed payload.\n");
> + return -EINVAL;
> + }
> +
> + memcpy(payload, &progincr, MACHXO2_OP_SIZE);
> + for (i = 0; i < count; i += MACHXO2_PAGE_SIZE) {
> + memcpy(&payload[MACHXO2_OP_SIZE], &buf[i], MACHXO2_PAGE_SIZE);
> + ret = spi_write(spi, payload, MACHXO2_BUF_SIZE);
> + if (ret) {
> + dev_err(&mgr->dev, "Error loading the bitstream.\n");
> + return ret;
> + }
> + udelay(MACHXO2_HIGH_DELAY);
> + }
Same here.
> +
> + return 0;
> +}
> +
> +static int machxo2_write_complete(struct fpga_manager *mgr,
> + struct fpga_image_info *info)
> +{
> + struct spi_device *spi = mgr->priv;
> + u32 progdone = ISC_PROGRAMDONE;
> + u32 refresh = LSC_REFRESH;
> + int ret;
> +
> + ret = spi_write(spi, &progdone, MACHXO2_OP_SIZE);
> + if (ret)
> + goto fail;
> +
> + udelay(MACHXO2_HIGH_DELAY);
See above.
> + /* yep, LSC_REFRESH is 3 bytes long actually */
> + ret = spi_write(spi, &refresh, MACHXO2_OP_SIZE - 1);
> + if (ret)
> + goto fail;
> +
> + return 0;
> +
> +fail:
> + dev_err(&mgr->dev, "Refresh failed.\n");
> + return ret;
> +}
> +
> +static const struct fpga_manager_ops machxo2_ops = {
> + .state = machxo2_spi_state,
> + .write_init = machxo2_write_init,
> + .write = machxo2_write,
> + .write_complete = machxo2_write_complete,
> +};
> +
> +static int machxo2_spi_probe(struct spi_device *spi)
> +{
> + struct device *dev = &spi->dev;
> +
> + if (spi->max_speed_hz > MACHXO2_MAX_SPEED) {
> + dev_err(dev, "Speed is too high\n");
> + return -EINVAL;
> + }
> +
> + return fpga_mgr_register(dev, "Lattice MachXO2 SPI FPGA Manager",
> + &machxo2_ops, spi);
> +}
> +
> +static int machxo2_spi_remove(struct spi_device *spi)
> +{
> + struct device *dev = &spi->dev;
> +
> + fpga_mgr_unregister(dev);
> +
> + return 0;
> +}
> +
> +static const struct of_device_id of_match[] = {
> + { .compatible = "lattice,machxo2-slave-spi", },
> + {}
> +};
> +MODULE_DEVICE_TABLE(of, of_match);
> +
> +static const struct spi_device_id lattice_ids[] = {
> + { "machxo2-slave-spi", 0 },
> + { },
> +};
> +MODULE_DEVICE_TABLE(spi, lattice_ids);
> +
> +static struct spi_driver machxo2_spi_driver = {
> + .driver = {
> + .name = "machxo2-slave-spi",
> + .of_match_table = of_match_ptr(of_match),
> + },
> + .probe = machxo2_spi_probe,
> + .remove = machxo2_spi_remove,
> + .id_table = lattice_ids,
> +};
> +
> +module_spi_driver(machxo2_spi_driver)
> +
> +MODULE_AUTHOR("Paolo Pisati <p.pisati-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>");
> +MODULE_DESCRIPTION("Load Lattice FPGA firmware over SPI");
> +MODULE_LICENSE("GPL v2");
> --
> 2.7.4
>
Thanks,
Moritz
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
^ permalink raw reply
* Re: [PATCH v2 0/2] ARM: sun8i: a83t: device tree cleanup
From: Maxime Ripard @ 2017-05-01 17:31 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20170501031408.10469-1-wens-jdAy2FN1RRM@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 558 bytes --]
On Mon, May 01, 2017 at 11:14:06AM +0800, Chen-Yu Tsai wrote:
> Hi Maxime,
>
> Here's v2 of the A83T device tree cleanup patches. I dropped the change
> to the uart device node name for now.
>
> Also added a second patch changing the underscores in device node names
> I just added to hyphens. AFAIK that is the preferred naming scheme.
> Please squash it into "ARM: sun8i: a83t: Rename pinmux setting names".
Applied both, thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH] regulator: Allow for asymmetric settling times
From: Matthias Kaehlcke @ 2017-05-01 16:42 UTC (permalink / raw)
To: Mark Brown
Cc: Laxman Dewangan, Liam Girdwood, Rob Herring, Mark Rutland,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Douglas Anderson, Brian Norris
In-Reply-To: <20170430123001.iwauodtjkbnmjmsl-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
Hi Mark and Laxman,
thanks for your comments.
El Sun, Apr 30, 2017 at 09:30:01PM +0900 Mark Brown ha dit:
> On Sat, Apr 29, 2017 at 01:32:09PM +0530, Laxman Dewangan wrote:
> > On Saturday 29 April 2017 05:36 AM, Matthias Kaehlcke wrote:
>
> > > -- regulator-settling-time-us: Settling time, in microseconds, for voltage
> > > - change if regulator have the constant time for any level voltage change.
> > > - This is useful when regulator have exponential voltage change.
> > > +- regulator-settling-time-up-us: Settling time, in microseconds, for voltage
> > > + increase if the regulator needs a constant time to settle after voltage
> > > + increases of any level. This is useful for regulators with exponential
> > > + voltage changes.
> > > +- regulator-settling-time-down-us: Settling time, in microseconds, for voltage
> > > + decrease if the regulator needs a constant time to settle after voltage
> > > + decreases of any level. This is useful for regulators with exponential
> > > + voltage changes.
>
> > Can we have regulator-settling-time-us also so if it is there then up/down
> > same.
> > If up/down different then separate properties can be used.
>
> Removing the existing binding would also break existing DTs using it
> which we obviously don't want.
I thought it might be ok in this case since the driver just landed.
> I don't see any reason to even deprecate it, like Laxman says it's
> nice and convenient for people with symmetric performance.
Ok, I was 'concerned' about the redundancy, but if that is not seen as
an issue I'm happy to just add the new properties. I'll send an
updated patch soon.
Thanks
Matthias
--
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 00/20] net-next: stmmac: add dwmac-sun8i ethernet driver
From: Andrew Lunn @ 2017-05-01 16:10 UTC (permalink / raw)
To: Corentin Labbe
Cc: Chen-Yu Tsai, Rob Herring, Mark Rutland, Maxime Ripard,
Russell King, Catalin Marinas, Will Deacon, Giuseppe Cavallaro,
alexandre.torgue-qxv4g6HH51o, devicetree, linux-kernel,
linux-arm-kernel, netdev
In-Reply-To: <20170501155856.GA1957@Red>
> > > > Does the internal PHY have a phy driver? It seems like
> > > > tx-delay-ps/rx-delay-ps are properties of this internal PHY, and so
> > > > should be in the phy driver, if it has one.
> > >
> > > Nope. These affect the delay lines for the external PHY interface.
>
> I will add some sentences in the documentation to be more clear about that.
Thanks
>
> >
> > Oh, yes. I understood the patch wrong.
> >
> > None of the patches actually use these properties. Are they actually
> > needed? We should avoid adding vendor specific properties, if they are
> > not used.
> >
>
> The board that use it is the BananaPi M3, but the SoC A83T still lack clocks support.
> So theses properties is already used out of tree, and will be used in tree soon.
Fair enough.
Thanks
Andrew
--
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 v3 4/5] ARM: sun7i: Convert to CCU
From: Maxime Ripard @ 2017-05-01 16:05 UTC (permalink / raw)
To: Priit Laes
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA, Philipp Zabel, Russell King,
Chen-Yu Tsai, Mark Rutland, Rob Herring, Stephen Boyd,
Michael Turquette, linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <560676328328d23f344468f5c43ff1b1533f36f0.1493235134.git-series.plaes-q/aMd4JkU83YtjvyW6yDsg@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 839 bytes --]
Hi,
On Wed, Apr 26, 2017 at 10:32:24PM +0300, Priit Laes wrote:
> compatible = "allwinner,simple-framebuffer",
> "simple-framebuffer";
> allwinner,pipeline = "de_be0-lcd0-hdmi";
> - clocks = <&ahb_gates 36>, <&ahb_gates 43>,
> - <&ahb_gates 44>, <&de_be0_clk>,
> - <&tcon0_ch1_clk>, <&dram_gates 26>;
> + clocks = <&ccu CLK_AHB_LCD0>, <&ccu CLK_AHB_HDMI0>,
> + <&ccu CLK_AHB_DE_BE0>, <&ccu CLK_DE_BE0>,
> + <&ccu CLK_TCON0_CH1>, <&ccu CLK_DRAM_DE_BE0>,
> + <&ccu CLK_HDMI>;
In order to make merging those patches *much* easier, could you just
use the raw IDs (ie not the defines, but the numbers) for now?
And ideally, send a patch after 4.13-rc1 that will switch to the
defines.
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH v3 1/5] clk: sunxi-ng: Add sun4i/sun7i CCU driver
From: Maxime Ripard @ 2017-05-01 16:02 UTC (permalink / raw)
To: Priit Laes
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA, Philipp Zabel, Russell King,
Chen-Yu Tsai, Mark Rutland, Rob Herring, Stephen Boyd,
Michael Turquette, linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <528b9b3895e654b6d3cf95187433f9fb7b4eb50c.1493235134.git-series.plaes-q/aMd4JkU83YtjvyW6yDsg@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 607 bytes --]
Hi Priit,
Almost good, thanks!
On Wed, Apr 26, 2017 at 10:32:21PM +0300, Priit Laes wrote:
> +/* TODO: GPS CLK 0x0d0 */
You should still create a define in the header for this one.
> +/* Following only exist on sun7i-a20 */
> +#define CLK_MBUS 165
> +#define CLK_HDMI1_SLOW 166
> +#define CLK_HDMI1 167
> +#define CLK_OUT_A 168
> +#define CLK_OUT_B 169
Wouldn't it be better to simply create a new A20-only header that
would include the A10's and add the A20 specific clocks on top?
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH v5 00/20] net-next: stmmac: add dwmac-sun8i ethernet driver
From: Corentin Labbe @ 2017-05-01 15:58 UTC (permalink / raw)
To: Andrew Lunn
Cc: Chen-Yu Tsai, Rob Herring, Mark Rutland, Maxime Ripard,
Russell King, Catalin Marinas, Will Deacon, Giuseppe Cavallaro,
alexandre.torgue, devicetree, linux-kernel, linux-arm-kernel,
netdev
In-Reply-To: <20170501144541.GB1285@lunn.ch>
On Mon, May 01, 2017 at 04:45:41PM +0200, Andrew Lunn wrote:
> On Mon, May 01, 2017 at 10:28:46PM +0800, Chen-Yu Tsai wrote:
> > On Mon, May 1, 2017 at 10:01 PM, Andrew Lunn <andrew@lunn.ch> wrote:
> > > On Mon, May 01, 2017 at 02:45:00PM +0200, Corentin Labbe wrote:
> > >> Hello
> > >>
> > >> This patch series add the driver for dwmac-sun8i which handle the Ethernet MAC
> > >> present on Allwinner H3/H5/A83T/A64 SoCs.
> > >>
> > >> This driver is the continuation of the sun8i-emac driver.
> > >> During the development, it appeared that in fact the hardware was a modified
> > >> version of some dwmac.
> > >> So the driver is now written as a glue driver for stmmac.
> > >>
> > >> It supports 10/100/1000 Mbit/s speed with half/full duplex.
> > >> It can use an internal PHY (MII 10/100) or an external PHY
> > >> via RGMII/RMII.
> > >
> > > Hi Corentin
> > >
> > > Sorry if this has been asked before....
> > >
> > > Does the internal PHY have a phy driver? It seems like
> > > tx-delay-ps/rx-delay-ps are properties of this internal PHY, and so
> > > should be in the phy driver, if it has one.
> >
> > Nope. These affect the delay lines for the external PHY interface.
I will add some sentences in the documentation to be more clear about that.
>
> Oh, yes. I understood the patch wrong.
>
> None of the patches actually use these properties. Are they actually
> needed? We should avoid adding vendor specific properties, if they are
> not used.
>
The board that use it is the BananaPi M3, but the SoC A83T still lack clocks support.
So theses properties is already used out of tree, and will be used in tree soon.
Regards
^ permalink raw reply
* Re: [PATCH 1/3] ARM: dts: rockchip: Move cros-ec-sbs to rk3288-veyron-chromebook-sbs
From: Doug Anderson @ 2017-05-01 15:49 UTC (permalink / raw)
To: Heiko Stuebner
Cc: Paul Kocialkowski, Brian Norris,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
open list:ARM/Rockchip SoC...,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Rob Herring,
Mark Rutland, Russell King
In-Reply-To: <2337202.q9Cdx8Nyxy@phil>
Hi,
On Mon, May 1, 2017 at 7:07 AM, Heiko Stuebner <heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org> wrote:
> Am Sonntag, 30. April 2017, 22:56:52 CEST schrieb Paul Kocialkowski:
>> Le dimanche 30 avril 2017 à 22:37 +0200, Heiko Stuebner a écrit :
>> > Hi Paul,
>> >
>> > Am Sonntag, 30. April 2017, 20:30:52 CEST schrieb Paul Kocialkowski:
>> > > This moves the cros-ec-sbs dtsi to a new rk3288-veyron-chromebook-sbs
>> > > dtsi since it only concerns rk3288 veyron Chromebooks.
>> > >
>> > > Other Chromebooks (such as the tegra124 nyans) also have sbs batteries
>> > > and don't use this dtsi, that only makes sense when used with
>> > > rk3288-veyron-chromebook anyway.
>> >
>> > That isn't true. The gru series (rk3399-based) also uses the
>> > sbs-battery [0]. And while it is currently limited to Rockchip-based
>> > Chromebooks it is nevertheless used on more than one platform, so
>> > the probability is high that it will be used in future series as well.
>>
>> That's good to know, but as pointed out, other cros devices are using a sbs
>> battery without this header, so such a generic name isn't really a good fit.
It would be interesting to know if the "retry-count" ought to be the
same across all Chromebooks. I guess you could argue that maybe
someone found it needed to be 10 in all "nyan" variants and needed to
be 1 in all "veyron" variants, but it seems more likely that the
difference is arbitrary, or that one of the two values would work for
everyone. It sure looks like we've just been copying values from
device to device. Given that all the "veyron" devices have vastly
different batteries (and probably all the nyan ones too), it seems
likely there ought to be one value.
In terms of setting the "charger", that also could potentially be
something that could be for all Chromebooks, or at least older ones
that don't have their charger implemented by the type C driver. ...or
nyan devices could simply have a line in their dts like:
&battery {
power-supplies = <&charger>;
};
>> Note that &charger has to be defined (after my subsequent patches), which it is
>> for devices that also include rk3288-veyron-chromebook, but not necessarily
>> others.
>>
>> Overall, I think having one -sbs dtsi file makes sense here because there is
>> already a rk3288-veyron-chromebook dtsi that veyron chromebooks use. That file
>> cannot contain the battery bindings because minnie has a different one and it
>> would be a bit silly to copy it over all devices. That definitely makes sense.
>>
>> As for other devices, I don't see why we should have a separate include file for
>> the battery instead of having it in the device's dts. I think this should be the
>> case on gru/kevin.
>>
>> Also maybe not *all* gru-based devices will turn out to use a SBS battery, so it
>> seems early to include this header in the gru dtsi.
For gru devices, we've moved to a "virtual sbs battery" provided by
the EC. I'm not 100% positive that everything will just magically
work and be converted in the EC if we put a non-sbs battery on a board
with this EC feature, but I would hope we'd convert everything
properly.
>> One last point, gru/kevin
>> currently don't define a charger, which will break my subsequent patch (that is
>> however needed for the veyrons that use this file).
Arguably this should be fixed. On veyron-chromebook we just use
"gpio-charger". We didn't add a special charger driver w/ a property
like "ti,external-control" since the only piece of information that
Linux really needed from the charger was whether or not AC was
connected.
>> To me, it seems that there's little advantage and major drawbacks in keeping
>> this file the way it is.
>
> I don't have any set opinion right now but after looking through the
> other uses of the sbs-battery the cros-ec-sbs.dtsi snippet really seems
> somewhat veyron/gru-specific - especially wrt. the retry-count values.
>
> What I'm not sure about is whether it is actually better to keep the include
> around under a new name or just move the (rather tiny) sbs-battery node
> into the relevant devicetrees directly, when there aren't that many users
> anyway.
I'm fine with whatever you guys choose to do here. It's nice not to
have copied "code", but with device tree sometimes copies are cleaner
than trying to share something.
-Doug
--
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] power: tps65217_charger: Add properties like voltage and current charge
From: Sebastian Reichel @ 2017-05-01 15:41 UTC (permalink / raw)
To: Enric Balletbo i Serra
Cc: Rob Herring, Mark Rutland, linux-pm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170421155032.22784-1-enric.balletbo-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 10860 bytes --]
Hi Enric,
On Fri, Apr 21, 2017 at 05:50:32PM +0200, Enric Balletbo i Serra wrote:
> Allow the possibility to configure the charge and the current voltage of
> the charger and also the NTC type for battery temperature measurement.
>
> Signed-off-by: Enric Balletbo i Serra <enric.balletbo-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
> ---
> Changes since v1:
> - Requested by Rob Herring
> - Rename ti,charge-* to charge-* to be standard properties.
> - Use unit suffixes as per bindings/property-units.txt
> ---
> .../bindings/power/supply/tps65217_charger.txt | 15 ++
> drivers/power/supply/tps65217_charger.c | 187 +++++++++++++++++++--
> include/linux/mfd/tps65217.h | 2 +
> 3 files changed, 192 insertions(+), 12 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/power/supply/tps65217_charger.txt b/Documentation/devicetree/bindings/power/supply/tps65217_charger.txt
> index a11072c..4415618 100644
> --- a/Documentation/devicetree/bindings/power/supply/tps65217_charger.txt
> +++ b/Documentation/devicetree/bindings/power/supply/tps65217_charger.txt
> @@ -6,6 +6,18 @@ Required Properties:
> Should be <0> for the USB charger and <1> for the AC adapter.
> -interrupt-names: Should be "USB" and "AC"
>
> +Optional properties:
> +-charge-voltage-microvolt: set the charge voltage. The value can be: 4100000,
> + 4150000, 4200000, 4250000; default: 4100000
> +
> +-charge-current-microamp: set the charging current. The value can be: 300000,
> + 400000, 500000, 700000; default: 500000
These two are battery specific. Please use newly introduced
"simple-battery" instead. See
https://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-power-supply.git/commit/?h=for-next&id=ecc931a585b3b2567da772233215f59b56fb42f9
https://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-power-supply.git/commit/?h=for-next&id=fb38342a5ae6e4f438256e98e4c29a7916195125
> +-ti,ntc-type: set the NTC type for battery temperature measurement. The value
> + must be 0 or 1, where:
> + 0 – 100k (curve 1, B = 3960)
> + 1 – 10k (curve 2, B = 3480) (default)
> +
This looks fine. Might make sense to move this into its own patch.
> This node is a subnode of the tps65217 PMIC.
>
> Example:
> @@ -14,4 +26,7 @@ Example:
> compatible = "ti,tps65217-charger";
> interrupts = <0>, <1>;
> interrupt-names = "USB", "AC";
> + charge-voltage-microvolt = <4100000>;
> + charge-current-microamp = <500000>;
> + ti,ntc-type = <1>;
> };
> diff --git a/drivers/power/supply/tps65217_charger.c b/drivers/power/supply/tps65217_charger.c
> index 1f52340..087f29c 100644
> --- a/drivers/power/supply/tps65217_charger.c
> +++ b/drivers/power/supply/tps65217_charger.c
> @@ -39,6 +39,12 @@
> #define NUM_CHARGER_IRQS 2
> #define POLL_INTERVAL (HZ * 2)
>
> +struct tps65217_charger_platform_data {
> + u32 charge_current_uamp;
> + u32 charge_voltage_uvolt;
> + int ntc_type;
> +};
> +
> struct tps65217_charger {
> struct tps65217 *tps;
> struct device *dev;
> @@ -48,16 +54,82 @@ struct tps65217_charger {
> int prev_online;
>
> struct task_struct *poll_task;
> + struct tps65217_charger_platform_data *pdata;
> };
>
> static enum power_supply_property tps65217_charger_props[] = {
> POWER_SUPPLY_PROP_ONLINE,
> };
>
> -static int tps65217_config_charger(struct tps65217_charger *charger)
> +static int tps65217_set_charge_current(struct tps65217_charger *charger,
> + unsigned int uamp)
> +{
> + int ret, val;
> +
> + dev_dbg(charger->dev, "setting charge current to %d uA\n", uamp);
> +
> + if (uamp == 300000)
> + val = 0x00;
> + else if (uamp == 400000)
> + val = 0x01;
> + else if (uamp == 500000)
> + val = 0x02;
> + else if (uamp == 700000)
> + val = 0x03;
> + else
> + return -EINVAL;
> +
> + ret = tps65217_set_bits(charger->tps, TPS65217_REG_CHGCONFIG3,
> + TPS65217_CHGCONFIG3_ICHRG_MASK,
> + val << TPS65217_CHGCONFIG3_ICHRG_SHIFT,
> + TPS65217_PROTECT_NONE);
> + if (ret) {
> + dev_err(charger->dev,
> + "failed to set ICHRG setting to 0x%02x (err: %d)\n",
> + val, ret);
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> +static int tps65217_set_charge_voltage(struct tps65217_charger *charger,
> + unsigned int uvolt)
> +{
> + int ret, val;
> +
> + dev_dbg(charger->dev, "setting charge voltage to %d uV\n", uvolt);
> +
> + if (uvolt != 4100000 && uvolt != 4150000 &&
> + uvolt != 4200000 && uvolt != 4250000)
> + return -EINVAL;
> +
> + val = (uvolt - 4100000) / 50000;
> +
> + ret = tps65217_set_bits(charger->tps, TPS65217_REG_CHGCONFIG2,
> + TPS65217_CHGCONFIG2_VOREG_MASK,
> + val << TPS65217_CHGCONFIG2_VOREG_SHIFT,
> + TPS65217_PROTECT_NONE);
> + if (ret) {
> + dev_err(charger->dev,
> + "failed to set VOCHG setting to 0x%02x (err: %d)\n",
> + val, ret);
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> +static int tps65217_set_ntc_type(struct tps65217_charger *charger,
> + unsigned int ntc)
> {
> int ret;
>
> + dev_dbg(charger->dev, "setting NTC type to %d\n", ntc);
> +
> + if (ntc != 0 && ntc != 1)
> + return -EINVAL;
> +
> /*
> * tps65217 rev. G, p. 31 (see p. 32 for NTC schematic)
> *
> @@ -74,14 +146,57 @@ static int tps65217_config_charger(struct tps65217_charger *charger)
> * NTC TYPE (for battery temperature measurement)
> * 0 – 100k (curve 1, B = 3960)
> * 1 – 10k (curve 2, B = 3480) (default on reset)
> - *
> */
> - ret = tps65217_clear_bits(charger->tps, TPS65217_REG_CHGCONFIG1,
> - TPS65217_CHGCONFIG1_NTC_TYPE,
> - TPS65217_PROTECT_NONE);
> + if (ntc) {
> + ret = tps65217_set_bits(charger->tps, TPS65217_REG_CHGCONFIG1,
> + TPS65217_CHGCONFIG1_NTC_TYPE,
> + TPS65217_CHGCONFIG1_NTC_TYPE,
> + TPS65217_PROTECT_NONE);
> + if (ret) {
> + dev_err(charger->dev,
> + "failed to set NTC type to 10K: %d\n", ret);
> + return ret;
> + }
> + } else {
> + ret = tps65217_clear_bits(charger->tps, TPS65217_REG_CHGCONFIG1,
> + TPS65217_CHGCONFIG1_NTC_TYPE,
> + TPS65217_PROTECT_NONE);
> + if (ret) {
> + dev_err(charger->dev,
> + "failed to set NTC type to 100K: %d\n", ret);
> + return ret;
> + }
> + }
> +
> + return 0;
> +}
> +
> +static int tps65217_config_charger(struct tps65217_charger *charger)
> +{
> + int ret;
> + struct tps65217_charger_platform_data *pdata = charger->pdata;
> +
> + if (!charger->pdata)
> + return -EINVAL;
> +
> + ret = tps65217_set_charge_voltage(charger, pdata->charge_voltage_uvolt);
> if (ret) {
> dev_err(charger->dev,
> - "failed to set 100k NTC setting: %d\n", ret);
> + "failed to set charge voltage setting: %d\n", ret);
> + return ret;
> + }
> +
> + ret = tps65217_set_charge_current(charger, pdata->charge_current_uamp);
> + if (ret) {
> + dev_err(charger->dev,
> + "failed to set charge current setting: %d\n", ret);
> + return ret;
> + }
> +
> + ret = tps65217_set_ntc_type(charger, pdata->ntc_type);
> + if (ret) {
> + dev_err(charger->dev,
> + "failed to set NTC type setting: %d\n", ret);
> return ret;
> }
>
> @@ -185,6 +300,48 @@ static int tps65217_charger_poll_task(void *data)
> return 0;
> }
>
> +#ifdef CONFIG_OF
> +static struct tps65217_charger_platform_data *tps65217_charger_pdata_init(
> + struct platform_device *pdev)
> +{
> + struct tps65217_charger_platform_data *pdata;
> + struct device_node *np = pdev->dev.of_node;
> + int ret;
> +
> + if (!np) {
> + dev_err(&pdev->dev, "No charger OF node\n");
> + return ERR_PTR(-EINVAL);
> + }
> +
> + pdata = devm_kzalloc(&pdev->dev, sizeof(*pdata), GFP_KERNEL);
> + if (!pdata)
> + return ERR_PTR(-ENOMEM);
> +
> + ret = of_property_read_u32(np, "charge-voltage-microvolt",
> + &pdata->charge_voltage_uvolt);
> + if (ret)
> + pdata->charge_voltage_uvolt = 4100000;
> +
> + ret = of_property_read_u32(np, "charge-current-microamp",
> + &pdata->charge_current_uamp);
> + if (ret)
> + pdata->charge_current_uamp = 500000;
struct power_supply_battery_info info = {};
power_supply_get_battery_info(tps65217, &info);
The simple-battery framework does not yet provide charge
current/voltage, so you will need to add that first. Please
Cc Liam on that patch.
> + ret = of_property_read_u32(np, "ti,ntc-type",
> + &pdata->ntc_type);
> + if (ret)
> + pdata->ntc_type = 1; /* 10k (curve 2, B = 3480) */
Please use device_property_read_u32(dev, ...) instead.
> +
> + return pdata;
> +}
> +#else /* CONFIG_OF */
> +static struct tps65217_charger_platform_data *tps65217_charger_pdata_init(
> + struct platform_device *pdev)
> +{
> + return NULL;
> +}
> +#endif /* CONFIG_OF */
> +
> static const struct power_supply_desc tps65217_charger_desc = {
> .name = "tps65217-charger",
> .type = POWER_SUPPLY_TYPE_MAINS,
> @@ -214,6 +371,18 @@ static int tps65217_charger_probe(struct platform_device *pdev)
> cfg.of_node = pdev->dev.of_node;
> cfg.drv_data = charger;
>
> + charger->pdata = tps65217_charger_pdata_init(pdev);
> + if (IS_ERR(charger->pdata)) {
> + dev_err(charger->dev, "failed: getting platform data\n");
> + return PTR_ERR(charger->pdata);
> + }
> +
> + ret = tps65217_config_charger(charger);
> + if (ret < 0) {
> + dev_err(charger->dev, "charger config failed, err %d\n", ret);
> + return ret;
> + }
> +
> charger->psy = devm_power_supply_register(&pdev->dev,
> &tps65217_charger_desc,
> &cfg);
> @@ -225,12 +394,6 @@ static int tps65217_charger_probe(struct platform_device *pdev)
> irq[0] = platform_get_irq_byname(pdev, "USB");
> irq[1] = platform_get_irq_byname(pdev, "AC");
>
> - ret = tps65217_config_charger(charger);
> - if (ret < 0) {
> - dev_err(charger->dev, "charger config failed, err %d\n", ret);
> - return ret;
> - }
> -
> /* Create a polling thread if an interrupt is invalid */
> if (irq[0] < 0 || irq[1] < 0) {
> poll_task = kthread_run(tps65217_charger_poll_task,
> diff --git a/include/linux/mfd/tps65217.h b/include/linux/mfd/tps65217.h
> index eac2857..d040062 100644
> --- a/include/linux/mfd/tps65217.h
> +++ b/include/linux/mfd/tps65217.h
> @@ -103,8 +103,10 @@
> #define TPS65217_CHGCONFIG2_DYNTMR BIT(7)
> #define TPS65217_CHGCONFIG2_VPREGHG BIT(6)
> #define TPS65217_CHGCONFIG2_VOREG_MASK 0x30
> +#define TPS65217_CHGCONFIG2_VOREG_SHIFT 4
>
> #define TPS65217_CHGCONFIG3_ICHRG_MASK 0xC0
> +#define TPS65217_CHGCONFIG3_ICHRG_SHIFT 6
> #define TPS65217_CHGCONFIG3_DPPMTH_MASK 0x30
> #define TPS65217_CHGCONFIG2_PCHRGT BIT(3)
> #define TPS65217_CHGCONFIG2_TERMIF 0x06
-- Sebastian
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v3 1/2] net: dsa: b53: Add compatible strings for the Cygnus-family BCM11360.
From: Eric Anholt @ 2017-05-01 15:15 UTC (permalink / raw)
To: David Miller
Cc: mark.rutland, andrew, f.fainelli, sbranden, vivien.didelot,
jonmason, netdev, linux-kernel, devicetree, robh+dt,
bcm-kernel-feedback-list, rjui, linux-arm-kernel
In-Reply-To: <20170430.224852.172293736555378453.davem@davemloft.net>
[-- Attachment #1.1: Type: text/plain, Size: 850 bytes --]
David Miller <davem@davemloft.net> writes:
> From: Eric Anholt <eric@anholt.net>
> Date: Fri, 28 Apr 2017 15:22:03 -0700
>
>> Cygnus is a small family of SoCs, of which we currently have
>> devicetree for BCM11360 and BCM58300. The 11360's B53 is mostly the
>> same as 58xx, just requiring a tiny bit of setup that was previously
>> missing.
>>
>> v2: Reorder the entry in the docs (suggestion by Scott Branden), add
>> missing '"'
>>
>> Signed-off-by: Eric Anholt <eric@anholt.net>
>> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
>> Acked-by: Rob Herring <robh@kernel.org>
>
> The second patch with the DTS file update doesn't apply cleanly
> at all to net-next.
>
> So I'm dropping this series.
DTS updates go through arm-soc branches through Florian. The first
patch is the one I would like you to apply.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
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 v11 03/10] devicetree: power: bq27xxx: Add monitored-battery documentation
From: Sebastian Reichel @ 2017-05-01 15:10 UTC (permalink / raw)
To: Liam Breck
Cc: Andrew F. Davis, linux-pm, Matt Ranostay, Rob Herring, devicetree,
Liam Breck
In-Reply-To: <20170320094335.19224-4-liam@networkimprov.net>
[-- Attachment #1: Type: text/plain, Size: 1516 bytes --]
Hi,
On Mon, Mar 20, 2017 at 02:43:28AM -0700, Liam Breck wrote:
> From: Liam Breck <kernel@networkimprov.net>
>
> Document monitored-battery = <&battery_node>
>
> Cc: Rob Herring <robh@kernel.org>
> Cc: devicetree@vger.kernel.org
> Signed-off-by: Matt Ranostay <matt@ranostay.consulting>
> Signed-off-by: Liam Breck <kernel@networkimprov.net>
> Acked-by: Rob Herring <robh@kernel.org>
> Acked-by: Sebastian Reichel <sre@kernel.org>
> ---
> Documentation/devicetree/bindings/power/supply/bq27xxx.txt | 11 ++++++++++-
> 1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/power/supply/bq27xxx.txt b/Documentation/devicetree/bindings/power/supply/bq27xxx.txt
> index b0c95ef..cf83371 100644
> --- a/Documentation/devicetree/bindings/power/supply/bq27xxx.txt
> +++ b/Documentation/devicetree/bindings/power/supply/bq27xxx.txt
> @@ -28,9 +28,18 @@ Required properties:
> * "ti,bq27621" - BQ27621
> - reg: integer, i2c address of the device.
>
> +Optional properties:
> +- monitored-battery: phandle of battery information devicetree node
> +
> + See Documentation/devicetree/bindings/power/supply/battery.txt
> + If either of the referenced battery's *-full-design-*-hours properties are set,
> + then both must be.
> +
> Example:
>
> -bq27510g3 {
> +bq27510g3 : fuel-gauge@55 {
> compatible = "ti,bq27510g3";
> reg = <0x55>;
> +
> + monitored-battery = <&bat>;
> };
Thanks, queued.
-- Sebastian
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v11 01/10] devicetree: power: Add battery.txt
From: Sebastian Reichel @ 2017-05-01 15:09 UTC (permalink / raw)
To: Liam Breck
Cc: Andrew F. Davis, linux-pm-u79uwXL29TY76Z2rM5mHXA, Matt Ranostay,
Rob Herring, devicetree-u79uwXL29TY76Z2rM5mHXA, Liam Breck
In-Reply-To: <20170320094335.19224-2-liam-RYWXG+zxWwBdeoIcmNTgJF6hYfS7NtTn@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 2240 bytes --]
Hi,
On Mon, Mar 20, 2017 at 02:43:26AM -0700, Liam Breck wrote:
> From: Liam Breck <kernel-RYWXG+zxWwBdeoIcmNTgJF6hYfS7NtTn@public.gmane.org>
>
> Documentation of static battery characteristics that can be defined
> for batteries which cannot self-identify. This information is required
> by fuel-gauge and charger chips for proper handling of the battery.
>
> Cc: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Signed-off-by: Matt Ranostay <matt-sk+viVC6FLCDq+mSdOJa79kegs52MxvZ@public.gmane.org>
> Signed-off-by: Liam Breck <kernel-RYWXG+zxWwBdeoIcmNTgJF6hYfS7NtTn@public.gmane.org>
> ---
> .../devicetree/bindings/power/supply/battery.txt | 43 ++++++++++++++++++++++
> 1 file changed, 43 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/power/supply/battery.txt
>
> diff --git a/Documentation/devicetree/bindings/power/supply/battery.txt b/Documentation/devicetree/bindings/power/supply/battery.txt
> new file mode 100644
> index 0000000..53a68c0
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/power/supply/battery.txt
> @@ -0,0 +1,43 @@
> +Battery Characteristics
> +
> +The devicetree battery node provides static battery characteristics.
> +In smart batteries, these are typically stored in non-volatile memory
> +on a fuel gauge chip. The battery node should be used where there is
> +no appropriate non-volatile memory, or it is unprogrammed/incorrect.
> +
> +Required Properties:
> + - compatible: Must be "simple-battery"
> +
> +Optional Properties:
> + - voltage-min-design-microvolt: drained battery voltage
> + - energy-full-design-microwatt-hours: battery design energy
> + - charge-full-design-microamp-hours: battery design capacity
> +
> +Battery properties are named, where possible, for the corresponding
> +elements in enum power_supply_property, defined in
> +https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/power_supply.h#n86
Since Rob did not reply, I queued this with this paragraph removed
and whitespace errors fixed to speed up things. You can always try
persuading Rob in an incremental patch ;)
-- Sebastian
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v11 02/10] devicetree: property-units: Add uWh and uAh units
From: Sebastian Reichel @ 2017-05-01 15:06 UTC (permalink / raw)
To: Liam Breck
Cc: Andrew F. Davis, linux-pm, Matt Ranostay, Rob Herring,
Mark Rutland, devicetree, linux-kernel, Liam Breck
In-Reply-To: <20170320094335.19224-3-liam@networkimprov.net>
[-- Attachment #1: Type: text/plain, Size: 1257 bytes --]
Hi,
On Mon, Mar 20, 2017 at 02:43:27AM -0700, Liam Breck wrote:
> From: Matt Ranostay <matt@ranostay.consulting>
>
> Add entries for microwatt-hours and microamp-hours.
>
> Cc: Rob Herring <robh@kernel.org>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: devicetree@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Matt Ranostay <matt@ranostay.consulting>
> Signed-off-by: Liam Breck <kernel@networkimprov.net>
> Acked-by: Sebastian Reichel <sre@kernel.org>
> Acked-by: Rob Herring <robh@kernel.org>
> ---
> Documentation/devicetree/bindings/property-units.txt | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/property-units.txt b/Documentation/devicetree/bindings/property-units.txt
> index 12278d7..0849618 100644
> --- a/Documentation/devicetree/bindings/property-units.txt
> +++ b/Documentation/devicetree/bindings/property-units.txt
> @@ -25,8 +25,10 @@ Distance
> Electricity
> ----------------------------------------
> -microamp : micro amps
> +-microamp-hours : micro amp-hours
> -ohms : Ohms
> -micro-ohms : micro Ohms
> +-microwatt-hours: micro Watt-hours
> -microvolt : micro volts
>
> Temperature
Thanks, queued.
-- Sebastian
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v5 00/20] net-next: stmmac: add dwmac-sun8i ethernet driver
From: Andrew Lunn @ 2017-05-01 14:45 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Corentin Labbe, Rob Herring, Mark Rutland, Maxime Ripard,
Russell King, Catalin Marinas, Will Deacon, Giuseppe Cavallaro,
alexandre.torgue-qxv4g6HH51o, devicetree, linux-kernel,
linux-arm-kernel, netdev
In-Reply-To: <CAGb2v67qGqswdz_JcDaD5jTkcvtBuzqqP8KZh=S_5pkp=o6cUQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Mon, May 01, 2017 at 10:28:46PM +0800, Chen-Yu Tsai wrote:
> On Mon, May 1, 2017 at 10:01 PM, Andrew Lunn <andrew-g2DYL2Zd6BY@public.gmane.org> wrote:
> > On Mon, May 01, 2017 at 02:45:00PM +0200, Corentin Labbe wrote:
> >> Hello
> >>
> >> This patch series add the driver for dwmac-sun8i which handle the Ethernet MAC
> >> present on Allwinner H3/H5/A83T/A64 SoCs.
> >>
> >> This driver is the continuation of the sun8i-emac driver.
> >> During the development, it appeared that in fact the hardware was a modified
> >> version of some dwmac.
> >> So the driver is now written as a glue driver for stmmac.
> >>
> >> It supports 10/100/1000 Mbit/s speed with half/full duplex.
> >> It can use an internal PHY (MII 10/100) or an external PHY
> >> via RGMII/RMII.
> >
> > Hi Corentin
> >
> > Sorry if this has been asked before....
> >
> > Does the internal PHY have a phy driver? It seems like
> > tx-delay-ps/rx-delay-ps are properties of this internal PHY, and so
> > should be in the phy driver, if it has one.
>
> Nope. These affect the delay lines for the external PHY interface.
Oh, yes. I understood the patch wrong.
None of the patches actually use these properties. Are they actually
needed? We should avoid adding vendor specific properties, if they are
not used.
Andrew
--
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 00/20] net-next: stmmac: add dwmac-sun8i ethernet driver
From: Chen-Yu Tsai @ 2017-05-01 14:28 UTC (permalink / raw)
To: Andrew Lunn
Cc: Corentin Labbe, Rob Herring, Mark Rutland, Maxime Ripard,
Chen-Yu Tsai, Russell King, Catalin Marinas, Will Deacon,
Giuseppe Cavallaro, alexandre.torgue, devicetree, linux-kernel,
linux-arm-kernel, netdev
In-Reply-To: <20170501140133.GD31281@lunn.ch>
On Mon, May 1, 2017 at 10:01 PM, Andrew Lunn <andrew@lunn.ch> wrote:
> On Mon, May 01, 2017 at 02:45:00PM +0200, Corentin Labbe wrote:
>> Hello
>>
>> This patch series add the driver for dwmac-sun8i which handle the Ethernet MAC
>> present on Allwinner H3/H5/A83T/A64 SoCs.
>>
>> This driver is the continuation of the sun8i-emac driver.
>> During the development, it appeared that in fact the hardware was a modified
>> version of some dwmac.
>> So the driver is now written as a glue driver for stmmac.
>>
>> It supports 10/100/1000 Mbit/s speed with half/full duplex.
>> It can use an internal PHY (MII 10/100) or an external PHY
>> via RGMII/RMII.
>
> Hi Corentin
>
> Sorry if this has been asked before....
>
> Does the internal PHY have a phy driver? It seems like
> tx-delay-ps/rx-delay-ps are properties of this internal PHY, and so
> should be in the phy driver, if it has one.
Nope. These affect the delay lines for the external PHY interface.
These have existed since the A20, when the GMAC hardware block and
glue layer controls were introduced.
ChenYu
^ permalink raw reply
* Re: [PATCH 1/3] ARM: dts: rockchip: Move cros-ec-sbs to rk3288-veyron-chromebook-sbs
From: Heiko Stuebner @ 2017-05-01 14:07 UTC (permalink / raw)
To: Paul Kocialkowski, briannorris-F7+t8E8rja9g9hUCZPvPmw,
Doug Anderson
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Mark Rutland,
Russell King
In-Reply-To: <1493585812.6493.4.camel-W9ppeneeCTY@public.gmane.org>
Am Sonntag, 30. April 2017, 22:56:52 CEST schrieb Paul Kocialkowski:
> Le dimanche 30 avril 2017 à 22:37 +0200, Heiko Stuebner a écrit :
> > Hi Paul,
> >
> > Am Sonntag, 30. April 2017, 20:30:52 CEST schrieb Paul Kocialkowski:
> > > This moves the cros-ec-sbs dtsi to a new rk3288-veyron-chromebook-sbs
> > > dtsi since it only concerns rk3288 veyron Chromebooks.
> > >
> > > Other Chromebooks (such as the tegra124 nyans) also have sbs batteries
> > > and don't use this dtsi, that only makes sense when used with
> > > rk3288-veyron-chromebook anyway.
> >
> > That isn't true. The gru series (rk3399-based) also uses the
> > sbs-battery [0]. And while it is currently limited to Rockchip-based
> > Chromebooks it is nevertheless used on more than one platform, so
> > the probability is high that it will be used in future series as well.
>
> That's good to know, but as pointed out, other cros devices are using a sbs
> battery without this header, so such a generic name isn't really a good fit.
>
> Note that &charger has to be defined (after my subsequent patches), which it is
> for devices that also include rk3288-veyron-chromebook, but not necessarily
> others.
>
> Overall, I think having one -sbs dtsi file makes sense here because there is
> already a rk3288-veyron-chromebook dtsi that veyron chromebooks use. That file
> cannot contain the battery bindings because minnie has a different one and it
> would be a bit silly to copy it over all devices. That definitely makes sense.
>
> As for other devices, I don't see why we should have a separate include file for
> the battery instead of having it in the device's dts. I think this should be the
> case on gru/kevin.
>
> Also maybe not *all* gru-based devices will turn out to use a SBS battery, so it
> seems early to include this header in the gru dtsi. One last point, gru/kevin
> currently don't define a charger, which will break my subsequent patch (that is
> however needed for the veyrons that use this file).
>
> To me, it seems that there's little advantage and major drawbacks in keeping
> this file the way it is.
I don't have any set opinion right now but after looking through the
other uses of the sbs-battery the cros-ec-sbs.dtsi snippet really seems
somewhat veyron/gru-specific - especially wrt. the retry-count values.
What I'm not sure about is whether it is actually better to keep the include
around under a new name or just move the (rather tiny) sbs-battery node
into the relevant devicetrees directly, when there aren't that many users
anyway.
Heiko
>
> > Also, it might be nice to also include some Chromeos people (there should
> > be some in the git logs, like Brian who submitted the Gru patches), as they
> > might be able to provide more detailed input.
>
> That's a good point, thanks for including them.
>
> >
> > Heiko
> >
> > [0] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/a
> > rch/arm64/boot/dts/rockchip/rk3399-gru.dtsi#n886
> >
> > >
> > > Signed-off-by: Paul Kocialkowski <contact-W9ppeneeCTY@public.gmane.org>
> > > ---
> > > .../boot/dts/{cros-ec-sbs.dtsi => rk3288-veyron-chromebook-sbs.dtsi} | 0
> > > arch/arm/boot/dts/rk3288-veyron-jaq.dts | 2
> > > +-
> > > arch/arm/boot/dts/rk3288-veyron-jerry.dts | 2
> > > +-
> > > arch/arm/boot/dts/rk3288-veyron-pinky.dts | 2
> > > +-
> > > arch/arm/boot/dts/rk3288-veyron-speedy.dts | 2
> > > +-
> > > 5 files changed, 4 insertions(+), 4 deletions(-)
> > > rename arch/arm/boot/dts/{cros-ec-sbs.dtsi => rk3288-veyron-chromebook-
> > > sbs.dtsi} (100%)
> > >
> > > diff --git a/arch/arm/boot/dts/cros-ec-sbs.dtsi b/arch/arm/boot/dts/rk3288-
> > > veyron-chromebook-sbs.dtsi
> > > similarity index 100%
> > > rename from arch/arm/boot/dts/cros-ec-sbs.dtsi
> > > rename to arch/arm/boot/dts/rk3288-veyron-chromebook-sbs.dtsi
> > > diff --git a/arch/arm/boot/dts/rk3288-veyron-jaq.dts
> > > b/arch/arm/boot/dts/rk3288-veyron-jaq.dts
> > > index d33f5763c39c..f217a978e47a 100644
> > > --- a/arch/arm/boot/dts/rk3288-veyron-jaq.dts
> > > +++ b/arch/arm/boot/dts/rk3288-veyron-jaq.dts
> > > @@ -45,7 +45,7 @@
> > > /dts-v1/;
> > >
> > > #include "rk3288-veyron-chromebook.dtsi"
> > > -#include "cros-ec-sbs.dtsi"
> > > +#include "rk3288-veyron-chromebook-sbs.dtsi"
> > >
> > > / {
> > > model = "Google Jaq";
> > > diff --git a/arch/arm/boot/dts/rk3288-veyron-jerry.dts
> > > b/arch/arm/boot/dts/rk3288-veyron-jerry.dts
> > > index cdea751f2a8c..bec607574165 100644
> > > --- a/arch/arm/boot/dts/rk3288-veyron-jerry.dts
> > > +++ b/arch/arm/boot/dts/rk3288-veyron-jerry.dts
> > > @@ -44,7 +44,7 @@
> > >
> > > /dts-v1/;
> > > #include "rk3288-veyron-chromebook.dtsi"
> > > -#include "cros-ec-sbs.dtsi"
> > > +#include "rk3288-veyron-chromebook-sbs.dtsi"
> > >
> > > / {
> > > model = "Google Jerry";
> > > diff --git a/arch/arm/boot/dts/rk3288-veyron-pinky.dts
> > > b/arch/arm/boot/dts/rk3288-veyron-pinky.dts
> > > index 995cff42fa43..c81ad5bf1121 100644
> > > --- a/arch/arm/boot/dts/rk3288-veyron-pinky.dts
> > > +++ b/arch/arm/boot/dts/rk3288-veyron-pinky.dts
> > > @@ -44,7 +44,7 @@
> > >
> > > /dts-v1/;
> > > #include "rk3288-veyron-chromebook.dtsi"
> > > -#include "cros-ec-sbs.dtsi"
> > > +#include "rk3288-veyron-chromebook-sbs.dtsi"
> > >
> > > / {
> > > model = "Google Pinky";
> > > diff --git a/arch/arm/boot/dts/rk3288-veyron-speedy.dts
> > > b/arch/arm/boot/dts/rk3288-veyron-speedy.dts
> > > index cc0b78cefe34..8aea9c3ff6e2 100644
> > > --- a/arch/arm/boot/dts/rk3288-veyron-speedy.dts
> > > +++ b/arch/arm/boot/dts/rk3288-veyron-speedy.dts
> > > @@ -44,7 +44,7 @@
> > >
> > > /dts-v1/;
> > > #include "rk3288-veyron-chromebook.dtsi"
> > > -#include "cros-ec-sbs.dtsi"
> > > +#include "rk3288-veyron-chromebook-sbs.dtsi"
> > >
> > > / {
> > > model = "Google Speedy";
> > >
> >
> >
>
--
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 00/20] net-next: stmmac: add dwmac-sun8i ethernet driver
From: Andrew Lunn @ 2017-05-01 14:01 UTC (permalink / raw)
To: Corentin Labbe
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8, wens-jdAy2FN1RRM,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, catalin.marinas-5wv7dgnIgG8,
will.deacon-5wv7dgnIgG8, peppe.cavallaro-qxv4g6HH51o,
alexandre.torgue-qxv4g6HH51o, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170501124520.3769-1-clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Mon, May 01, 2017 at 02:45:00PM +0200, Corentin Labbe wrote:
> Hello
>
> This patch series add the driver for dwmac-sun8i which handle the Ethernet MAC
> present on Allwinner H3/H5/A83T/A64 SoCs.
>
> This driver is the continuation of the sun8i-emac driver.
> During the development, it appeared that in fact the hardware was a modified
> version of some dwmac.
> So the driver is now written as a glue driver for stmmac.
>
> It supports 10/100/1000 Mbit/s speed with half/full duplex.
> It can use an internal PHY (MII 10/100) or an external PHY
> via RGMII/RMII.
Hi Corentin
Sorry if this has been asked before....
Does the internal PHY have a phy driver? It seems like
tx-delay-ps/rx-delay-ps are properties of this internal PHY, and so
should be in the phy driver, if it has one.
Andrew
--
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
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